想做好产品,软件产品化道路到底有哪些困难?

原创 admin  2022-09-01 09:51  阅读 93 views 次

与其他行业类似,国内的大部分软件公司都是从开发一、二个软件项目起家的,而且项目规模和复杂度也不大,依赖某几位高手(或创始人),他们能够在客户适度满意的状态下成功完成项目。

面对这种定制化项目,成功的因素主要有如下几点:

需求明确且范围不大,变动不多:要么客户方需求明确,要么企业对需求足够了解,于是,双方至少有一个人对需求有全面并且细致的了解,双方合作氛围很好,这可以减少需求变更的量和避免冲突尖锐。
创始人都是技术或业务的高手,或者手下有1-2名得力干将。
项目使用的技术涉及面不广,往往一两个人兼而关注就可以把握。
一点运气:正好选对了技术平台;正好高手没有离职……

企业发展后环境的变化

随着时间的推移,企业承接的项目多了,人员多了,企业规模也扩大了。这时候,企业的内外部环境都发生了很大的变化。

1.外部环境来:

需求增多和变化:

客户行业发展迅速,需求在宽度、深度、变化频度上发生了持续的变化。具体来说,要求软件系统支撑的业务多了(需求宽度增加),并发使用软件系统的人多了、时间长了,业务过程复杂了(深度增加)。客户需要经常进行业务的调整(变化频度多了)。这种变化,往往会使客户的需求管理成为一个专业、持续、并且工作量相当的过程。也就是说,企业具有需求管理与软件开发进行分工的需求。
技术更新迭代:

软件系统开发使用的第三方技术平台种类多,且复杂,更新换代也快,如果软件系统在性能、持续稳定性有要求,并且软件使用周期设计要求满足一定的年限,就要求企业对第三方技术平台的发展进行跟踪,并寻求有效应用的实际经验(最佳实践规范)。这样,企业就逐步有将集成应用技术(含软、硬件集成应用技术)进行专业分工的需求。市场技术竞争的重要性增加,关系竞争弱化,企业发现为了获取合同,他们需要有研发能力的保障,并且要在技术竞争考察中胜出。迫使企业对客户关注的重点专业技术进行投入。
2.内部状况来看:

企业同时运作软件项目数量增多,但依赖于高手的项目模式没有改变。各项目都需要高手来保障,如果没有高手,项目就停滞不前,而且往往以非正常手段结束。
随着软件项目的深入展开或软件的升级换代,企业会发现有些模块的开发总是在重重复复地做,上一个版本做了,这个版本还要继续做,同时开展几个项目,都有类似的事情在重复做。但要直接使用之前的内容,又不行。
技术人员总是有很多理由不去写文档,如果不是一个人将一个模块从分析设计负责到代码,后一个环节的人总是得意于自我创新,并容易发生设计人员和开发人员的扯皮。
软件项目在前期开发时候是一路凯歌,到了快要交付的时候,却又难产,总是达不到要求,改改代码重新测试,没完没了。而技术人员又非常辛苦。甚至出现部分或大全部返工现象。
软件项目开始的时候,谁也不知道什么时候能完成,领导说三个月就三个月,半年就半年,实际上,没有按期完成的,延期3-5个月是常事,1-2年也是有的,甚至不得不换班子重开炉灶。

面对以上变化和问题,企业的解决办法之一是延续原有项目的成功模式——高手主导的项目模式,即给每一个项目配备高手。但这样问题来了,如果没有那么多高手,就让把所有的项目压在有限的高手身上。如果高手有限的话,实际上企业是将问题转移给相对低资源能力的高手去解决。当然,有限的高手也同样可以使用同样的手法进行问题转嫁。

但这种解决办法由于将所有的问题转移到高手身上,企业管理就研发方面的决策难以形成明确的方向和目标,在研发方面只有用人的战略。尤其在互联网时代,如何留住高手,如何在符合企业价值观(薪资)与战略的前提下,找到高手,都是世界级难题。显然,以上并非根本性的解决方案。一旦高手动荡,企业业务发展就受限,而且这种方式面临的风险很大,过度的项目定制开发不但影响项目的交付进度和质量,也使成本居高不下,侵袭了企业本来就比较有限的利润。那么,出路只能是走向产品化。

系统软件产品化的道路

然而,软件产品化是一件相当困难的事情,企业在各个方面都将面临挑战,并必须作出相应的改变。

企业需要转变经营理念和思路。

其实不管是项目化还是产品化,都要坚持客户导向,但是就客户导向的内涵和实现方式上,很多企业往往是被动地满足客户需求,甚至迁就客户五花八门的需求。我们到底选择什么样的客户?这是企业成长中必须作出的回答。即便已经明确了这个问题,对客户各种需求也不是不加区别的满足,而是需要抓住目标客户的核心需求和偏好,并认识到客户只要在核心利益上得到足够的满足,他们愿意牺牲一些个性化的特性——这正是产品化的前提假设。

根据以往经验,产品平台化实施过程中将面临各方面的困难。

面对外部一些新的市场机会和客户特殊需求,营销人员总是倾向于把握新机会和响应客户的新需求,如果高层在增长压力下没有确定相应的战略原则去约束产品决策,则很可能使既定产品定位和产品化方向的努力付诸东流。即使公司界定了产品定位和方向,在具体操作时,到底用户的某个特性是否需要加入产品规划中,到底某个需求是否应当纳入到产品功能开发中……

如何在标准产品与客户最终产品之间取得平衡,这仍然产品化开发模式下最为头痛的问题。比如,有些需求一旦纳入标准产品之中,对产品可能是致命的打击。

在平台化开发模式下,产品架构和模块/组件设计将更多地考虑开放性、通用性和冗余设计,从局部来看会影响产品开发的进度和效率,尤其对新产品系列的第一个产品,将需要更长时间才能推向市场,这是企业必须认识和接受的代价,但换来的是后续产品开发速度的大幅提升。

另外,产品平台化开发还会来自内部高手的挑战和开发人员习惯的阻力。高手们总是希望按照自己的思路规划和开发产品,要让大家都统一到一致的平台架构和开发模式下绝非易事。开发人员也不喜欢条条框框,总是想弄点什么新的东西,但平台化则需要更多的标准化和规范要求。

综上,要解决这些难题,企业需要足够的决心和耐心。

显然,软件产品化不仅仅是技术上的问题,然而技术也是其中关键的一环,包括架构设计、技术平台、模块化构造、数据结构、函数/算法、接口技术等。例如技术平台的工作一般包括:

第三方技术平台选型 技术使用研究,确定软件项目技术路线和技术架构;
制定开发规范,并形成开发案例和模板,扫清开发队伍大规模开发时的障碍;
开发技术控件,提高开发队伍大规模开发的效率等等;

本文地址:http://www.moonpm.com/1049.html
关注我们:请关注一下我们的微信:扫描二维码产品设计研究与产品经理交流中心 (鼠标移入红色字)
版权声明:本文为原创文章,版权归 admin 所有,欢迎分享本文,转载请保留出处!

发表评论


表情

  1. admin
    admin 【农民】 @回复

    博主,交换友情链接吗?