注意软件开发的成本

我一直觉得，搞软件开发，应该是个脑力活，而不是个体力活。比如，有个需求过来，得先理解业务背景，然后思考解决方案，再评估成本和收益，最后才是软件实施。这其中的思考，很大程度上决定了软件开发的效率、质量和效果。

而实际情况是，一堆需求在排队，做都来不及，哪有空思考。于是脑力活变成了体力活，就像流水线上的劳工。

要知道，体力活按工作量算，干得多拿得多。但问题来了，软件开发却不是这样，工作量差不多，有人拿得多，有人却拿得少。

我举个例子，有两个产品团队（简称 B 和 C），其中 B 团队面向公司内部，而 C 团队面向外部客户。B 团队做了个流程审批系统，给内部流程提效；C 团队做了个订单管理系统，给公司挣钱。

B 是成本中心，C 是利润中心。假设两个团队规模一样。哪个团队拿得多？正常情况下，当然是 C 团队。

讲这个小故事，就是想提醒大家，不要只关注开发效率，还要关心成本（和收益）。

无论你是一个团队负责人，还是个开发者，请不要被动接需求，更不要脱离业务。否则你会发现，事多钱少责任大，开会扯皮氛围差。

有人可能不信，接下来我讲更多的例子。

效率问题

下面这些问题，你有没有遇到过？

1、明明按照需求做了，但业务反馈产品不好用。

2、产品上线，但是不稳定，隔三差五出问题。

3、排期紧张，然后仓促上线，最后效果达不到预期。

4、一个内部软件，做了好多年，一直在小修小改。没技术含量，也没成就感。

5、团队的人离职频繁。

6、前人挖坑埋后人。祖传代码不敢动，一动就出问题。

7、开发周期越来越长，尤其是测试和调试费时间。

8、老板为了提高研发效率，开始抓流程，搞项目管理。

理想情况下，你想要快速迭代，得到一个好产品。实际情况是，你迭代得很快，很快做出一个烂产品，而且越做越烂。究其原因，很大程度上是“只看效率”惹的祸。

看起来做了很多需求，效果却不尽人意，维护和升级成本高，还搞出一堆问题。然后发现人不够，招了更多人，接着搞出更多问题，业务上一团糟。这个时候，只好去抓流程，搞项目管理。

最后没办法了，重构产品，一切推导重来，开启新一轮“效率循环”。

这样的软件研发模式，跑得很快，但成本很高。

原因分析

追求效率本身没有错，但是应该讲究正确的方法。如果不顾实际业务情况，盲目追求效率，就会南辕北辙。比如，开发时间长，需求做得少，系统不稳定，然后就说效率低。这样不仅伤人，还会让结果更糟。

下面分析一下原因。

不做设计

按我个人的经验，设计方案和验证方案很花时间，而且产出是文档，不是代码。有些时候，做着做着，还会把之前的方案推倒重来。这个时候，等于啥也没产出。在有些人看来，这等于啥也没干，等于摸鱼。

当然，我不这么认为，我觉得这些探索非常有价值，一是理解业务，二是避免浪费研发资源。

当然，领导不一定买账，如果领导不买账，就先把代码写了交差，做设计是不可能的。

不管质量

“倒排”有没有听过？简单来说，就是倒着排期。先定上线日期，再定开发节点的交付日期。一般来说，倒排会压缩开发时间。

时间不够怎么办？

不写文档和注释，不做抽象，不管代码规范，不搞代码评审，甚至不测试。搞算法的同学，你们咋测试的，来说说看？搞后端开发的同学，有几个写单元测试的？

出了问题怎么办？

各职能团队要记得互相甩锅。这不是互相伤害，而是互相帮助。因为老板一看，原来是流程问题，这样大家都没责任。

没成就感

搞软件开发，是一个技术活。同一个功能，不同的人去实现，写出来的代码可能天壤之别。好的代码容易读懂、维护和扩展；而差的代码恰恰相反，给后续的开发带来巨大的成本。

实际工作中，提高开发质量几乎没有收益，不如做一个合格的码农（Coding Peasant）和调包侠（API Caller），因为出活快。称号还可以再细分，CRUD 宝宝（CRUD boy）送给后端开发，SQL 宝宝 （SQL boy）送给算法和数据。

这是自嘲，体现的是不满。很多技术人，想做好技术，想写好代码，奈何环境不允许。

没归属感

业务提需求，产品经理过一道，然后丢给技术排期。做业务的不懂技术，做技术的不懂业务。产品经理有时候是粘合剂，有时候搅浑水。

很多时候，搞开发的是个工具人。当然，开发也要从自身找问题。这里不检讨，只描述现象。

结果就是，各职能之间，目标不同，立场不同，收益也不同。这种情况下，别说效率，能把项目搞上线已经是万幸。

面向成本

想要提高产出，不应该堆砌需求数量，而是去理解需求，去研究低成本（高收益）的解决方案。归根到底，还是成本和收益问题。

下面分享一些我的设计理念，主要从成本角度考虑，包括使用成本、研发成本、维护成本、协作成本和项目收益。

使用成本

做一款软件，是给人用的，就有使用成本。如果使用成本太高，用户就不会接受。

我举个例子。在电商行业，把两个商品打包在一起卖，叫做组合装。

现在要做一款产品，来生成组合装。看起来很简单，是不是？

现在要把衣服和裤子组合，其中衣服有五个颜色、四个尺码，裤子也是。那么衣服和裤子各有 20 种规格。

两个款衣服组合在一起就是 400 种规格！

我见过一款产品，它一次性生成 400 个表单！你要逐个处理，把需要的留下，然后填写基本信息，比如名称、描述、价格等等；把不需要的删掉。

这样的产品，笛卡尔见了直呼过瘾，用户见了绕道走。好产品要想办法降低用户的学习成本和使用成本。

研发成本

有些技术方案听起来很不错，但是研发成本非常高，比如线上化和中台化。

线上化就是把一些线下业务流程，比如 Excel 报表、邮件审批等等，搬到线上系统；中台化就是做企业内部的平台，常见的是数据中台。这些都属于基建工程，但基建搞到最后，还是要服务业务。

基建投入是个无底洞。应该搞到什么程度？去解决什么业务问题？

能不能用更低成本的方式去替代？

好的技术方案，应该可以用低成本去验证，使得业务风险可控，业务收益可评估。

举个例子。我有个朋友，在某个电商公司，有段时间用户投诉率比较高。为了改进用户体验，这家公司做了一个工单系统，作用是让客服把收集到的问题，提交到工单，然后反馈给商品开发团队。

先不讨论这个工单系统能不能提升用户满意度。至少可以想一想，是否可以通过发邮件验证效果？

我的思路是，首选不写代解决问题，其次是用策略解决问题，再次是用算法解决问题，最后才是用产品解决问题。有些人动不动就上模型、上产品，我认为这是一条昂贵的思路。

维护成本

因为业务多变，所以软件要维护。

为了降低维护成本，要设计方案、明确规范、定义接口；要考虑业务变化，可扩展性，以及软件的生命周期；要有必要的文档。

如果不搞这些，重写代码有可能比维护老代码还容易。

协作成本

一个软件产品，往往涉及多个职能，比如业务、产品、设计、前端、后端、算法、数据、测试和项管。需要考虑团队之间的协作成本，比如提升开会效率，用文档沟通，明确目标和分工等等。

举个例子。我曾经见过一个大场面，十个人开会，最后一个人干活，这个人就是我。你说这协同成本高不高。

我斗胆提出一个指标，叫“搬砖率”，用干活人数除以开会的总人数。你不妨算算自己公司的搬砖率。搬砖率太低也不是个好事。

项目收益

软件开发不是体力活，它不按劳动量分配收益，而是按价值。即使当前的研发流程是流水线，我们作为其中的参与者，始终要思考项目产出的价值。

如果预估的业务价值低，应该想办法降低投入成本，或者用技术手段去创造更大的价值。

总结

前面啰嗦了一大堆，就是想让大家更多地关注软件研发的成本和收益。避免吃力不讨好，避免掉进陷阱。

最后再强调一遍，软件开发，是个脑力活，不是体力活。