点击▲关注 “CU技术社区” 给公众号标星置顶

更多精彩第一时间直达

本文转自 | 吃草的罗汉题图 | from Zoommy

在 #“我，80后，曾经靠副业的收入买车买房”# 的评论区里，有读者问，十几年前，圈内有不少软件公司，规模大小不一，遍布各个行业，但这几年似乎都没动静了，他们还活着吗？

我说，撇开纯做 “劳工” 输出的外包公司，或者有后台背景的机构，除非产品化转型成功，那些做项目的，尤其是那些曾对客户信誓旦旦保障 “你说什么，我都能实现” 的软件公司，几乎全死了，而且死相还挺难看的。

为什么这么说呢？

有句话说得好，能靠堆机器突破的瓶颈，通常都不是瓶颈，能用钱解决的问题，几乎都不是问题，但可悲的是没机器、没钱。

在我已知的范围里，假如你不惜成本，基本没有招不到的人，也没有解决不了的技术问题，但这是伪命题，无论是互联网公司，还是软件公司，在技术上都是成本驱动，任何技术研发的投入必须对业务产生正向收益，反之，投入和收益一旦产生逆差，这场戏就很难唱的下去了。

本来嘛，你搞软件的，距离 “一次投入，多次获利” 这项标准越近，那就越赚钱，离得越远，那就越亏钱。

十年前，我在某金融软件公司工作，刚开始，一个团队才2-3个人，只做一家客户，只维护一套代码，你要啥，满足你就是了，你高兴，我也嗨皮。渐渐地，随着客户数的增多，研发人员的增多，变成了“一堆人，同时维护几套代码”，这样一来，Bug增多，客户投诉越来越多，成本与效率/质量的矛盾日益凸显。

面对这样的困境，当时的老板分别采取过3种应对措施：

一对一服务 - 项目制：多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债。
一对多服务 - 标准化：一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别来某某标准来引导我，叫你咋做，你就咋做，不愿意？那您走，我找别人家做。
一对多服务 - 产品化：一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。

显然，这是一个悲伤的故事，虽然主动寻求改变，但结果却不尽如人意。

于是，业务每况愈下，抱怨也随之变多，幸福感下降，效率打折扣，再加上甲方挖人，最后老板顶不住，逃去了香港，团队土崩瓦解，Game Over……

或许是天生爱总结的癖好，前几年，我曾对 “软件产品化” 这个话题进行过一些调研和分析，下面与大家分享一些思考。

关于软件产品化的几点思考

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

在我看来，面对这种定制化项目，成功的因素主要有如下几点：

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

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

先从外部环境来看：

客户行业发展迅速，需求在宽度、深度、变化频度上发生了持续的变化。具体来说，要求软件系统支撑的业务多了（需求宽度增加），并发使用软件系统的人多了、时间长了，业务过程复杂了（深度增加）。
竞争加剧，客户需要经常进行业务的调整（变化频度多了）。这种变化，往往会使客户的需求管理成为一个专业、持续、并且工作量相当的过程。也就是说，企业具有需求管理与软件开发进行分工的需求。
软件系统开发使用的第三方技术平台种类多，且复杂，更新换代也快，如果软件系统在性能、持续稳定性有要求，并且软件使用周期设计要求满足一定的年限，就要求企业对第三方技术平台的发展进行跟踪，并寻求有效应用的实际经验（最佳实践规范）。这样，企业就逐步有将集成应用技术（含软、硬件集成应用技术）进行专业分工的需求。
市场技术竞争的重要性增加，关系竞争弱化，企业发现为了获取合同，他们需要有研发能力的保障，并且要在技术竞争考察中胜出。迫使企业对客户关注的重点专业技术进行投入。

再从内部状况来看：

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

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

当然，有限的高手也同样可以使用同样的手法进行问题转嫁。

但这种解决办法由于将所有的问题转移到高手身上，企业管理就研发方面的决策难以形成明确的方向和目标，在研发方面只有用人的战略。

尤其在互联网时代，如何留住高手，如何在符合企业价值观（薪资）与战略的前提下，找到高手，都是世界级难题。

显然，以上并非根本性的解决方案。一旦高手动荡，企业业务发展就受限，而且这种方式面临的风险很大，过度的项目定制开发不但影响项目的交付进度和质量，也使成本居高不下，侵袭了企业本来就比较有限的利润。

那么，出路只能是走向产品化。

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

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

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

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

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

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

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

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

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

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

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

好了，就扯这么多吧，有些零碎，凑合看吧。

软件产品化还与行业发展状况、企业产品形态成熟度、企业管理成熟度、软件技术发展、人员职业化程度等因素相关，所以还有很长的路要走。

边走，边看，边改进吧。

END

由ITPUB社区主办的第11届中国系统架构师大会（SACC2019）隆重启动，本届大会继续延用四大主线并行的演讲模式，设置业务系统架构设计、大数据平台架构设计、数字化转型实践和开源架构设计，共1个主会场，21个技术专场，100+来自互联网、金融、制造业、电商等领域嘉宾。8.5折优惠购票限时进行中，点击【阅读原文】进入大会官网。

你「在看」吗？

点击进入官网立享购票8.5折优惠~

ITPub博客

当年“你说什么，我都能实现”的软件公司，后来都是怎么死的？

最新文章