【原创】【必看】谈谈软件行业普遍存在的一些问题

权当是本人10余年从业经验以及所见所闻的一次复盘。从大局观的角度阐述与软件项目研发相关的种种问题。这些问题非常常见，几乎所有的团队多多少少都会存在这些问题。这些问题会严重降低工作效率、降低产品质量、降低用户满意度、提高项目成本、损害企业名誉等等。

1、产品经理极为不专业，输出的需求存在各种各样的问题，比如含糊不清、不完善、逻辑矛盾、有二义性等等。需求分析的目的就是解决这些问题。需求分析会产生分析模型，例如数据流图、。UML等。然而几乎没有产品经理做了这项工作。在我的职业生涯中接触了大约20个产品经理，无一例外他们都没有做需求分析。他们甚至不知道数据流图是什么，UML是什么。或许是因为他们不是计算机相关专业毕业的吧。

就拿二义性来说吧。本人曾经经历过一次，需求描述存在二义性，不同的人有不同的理解，而且都认为自己的理解是没有问题的。转测之后发现产品经理、开发人员、测试人员的理解都不一样。后来做了统一，花了5天的时间返工，而且每天都加了班。这是因为自然语言本身就存在二义性。而使用建模语言传递需求信息就不会出现二义性的问题。

在我的职业生涯中，只看到了几次产品经理绘制的业务流程图，但是平心而论，几乎处于看不懂的状态。一是逻辑矛盾、内容缺失、业务不闭环等等各种问题。二是未使用技术标准，造成沟通障碍。可以说，所绘制的图形完全没有参考价值，甚至会误导人。不同的人绘制出来的图形效果也会有差异的。因为建模不仅仅需要语言，还需要方法、思想。就好比是你写文章，把一些单词和句子胡乱拼凑在一起，别人能看懂吗？？

团队其他成员的工作都依赖于产品经理的工作输出。如果产品经理的工作输出存在各种问题，那么其他成员的工作一定会存在问题。

对于项目经理来说，工作任务分解会变得很困难，工期的估算也会很困难。就算能估算出个结果，那也是极为不准确的。给后续的项目推进埋下隐患，比如项目大幅延期。为了追赶进度不得不采取加班、牺牲质量、增加人员的方式。

加班如果是发放加班工资还好。但若是采取调休方式，同意调休会影响到项目进度，使项目容易延期。不同意调休会使员工感到不人性化，从而产生管理障碍。但是请记住，企业要想成功，就必须尊重人性规律。这是因为几乎所有的工作任务都是由人去完成的。如果员工不满意，可能会故意使坏或者降低工作效率和质量，从而使客户不满意，对于企业的名誉和盈利是极为不利的。

质量包括内部质量和外部质量。内部质量通常是指项目开发过程中产出的工作制品的质量，例如需求文档、设计文档、程序代码、测试用例等等。降低内部质量会使项目难以维护，提高项目成本。外部质量通常是指用户能感知到的质量，例如APP好不好用。降低外部质量势必会有损企业的名誉和收入。

增加人员不是最优解，这是因为团队成员越多，沟通的口径就越大。假设你身处在团队中，如果团队有10名成员，那么你的沟通口径就是9。如果团队有20名成员，那么你的沟通口径就是19。从全局来看，沟通口径越多，效率越低。事实上，沟通成本是企业最大的成本。很多事情不顺利就是沟通引起的。

对系统架构师、技术经理的工作开展也是不利的。例如系统架构师要根据用户需求，结合用户应用领域的实际情况，设计正确、合理的软件架构，维护系统构件及其接口，并确保系统构架具有良好的性能......系统架构师是需求与技术实现之间的桥梁，也是需求与项目管理之间的桥梁。

对于程序员来讲，需求的问题会导致返工以及程序代码难以维护。举一个很常见的例子，产品经理提供的需求是显示列表，但没有提供排序方式。程序员在实现之前认为此用户场景按照A排序最合理，于是按照A排序去实现功能。然而在测试阶段，测试人员与产品经理沟通后，认定应当按照B排序。于是程序员不得不返工，浪费了时间，提高了项目成本。另外，若要想复用程序代码，根据我个人的经验，绘制用例图和活动图是复用的前提条件，要从大局观着手。不然你是很难把所有可以复用的功能点全给挖掘出来的。

对测试人员的工作也会产生负面影响。例如系统测试人员在理论上应当测试每一条可能的操作路径。然而产品经理并没有提供流程图，也没有提供关于用例的详细文字描述。他们甚至不知道“用例”是什么意思。 导致测试人员不能充分测试流程，项目上线后被用户发现BUG。

国际上众多名校均采用的教材《软件工程（第4版·修订版）》中提到了一些数据：

1. 在中型软件项目中观察到的48%的故障“归因于不正确的或错误解释的功能规格说明或需求”。
2. 79.6%的接口故障和20.4%的实现故障都是因为不完备或者遗漏的需求所致。
3. 所有系统故障的44.1%是在需求规格说明阶段出现的。
4. 安全相关的功能故障的主要原因是认识（或理解）需求时所犯的错误（这类故障的62%~79%）。

书中还描述：

如果在开发过程的早期没有检测到并且修复需求错误，那么，这些需求错误的代价可能会很高昂。如果在需求定义过程中找出并修复一个基于需求的问题只需花费1美元，那么，在设计过程中做这些工作就要花费5美元。在编码过程中就要花费10美元，在单元测试过程中就要花费20美元，而在系统交付后要花费200美元之多！

本人工作10余年，在公司遇到的产品经理不下20个。如果将书籍《软件需求（第3版）》中讲述的知识体系作为判定标准，至今还没有遇到一个专业的产品经理。普遍处于业余水平。

2、项目没有定义业务需求。需求有3个层次，业务需求、用户需求、功能需求。它们是一环扣一环，层层递进的关系。用户需求定义的目标是实现业务需求。当你定义了业务需求，你才能把握好项目的方向。比如，业务需求是实现在线问诊，那么如果你加入了游戏板块，会显得多余，提高了成本，降低了投资回报率。因为游戏并不有助于实现在线问诊这个目标。就算没有游戏板块，依然是可以实现在线问诊的。

3、项目实现了大量的伪需求。所谓的伪需求是指用户需求并不是来源于用户，可能是产品经理抄袭来的，可能是老板的某个朋友提出的。但这种样本量太少了，不具有参考价值。需求也是众口难调的，应当遵循少数服从多数的原则，所以应该做大样本的调查再下结论。需求还可能是团队成员臆想的，虽然自己不是用户，但是却假设自己是用户。就算是想到了一些可能的需求，在没有做用户调研的前提下，是无法确定所实现的需求是不是用户真正所需的。如果不是用户所需的，会浪费大量的时间、资金、人力资源等等。

4、团队忽视配置管理，以及对配置管理的误解。部分团队成员没有基线的概念。基线就是程序员们所说的分支。基线的作用是记录和追踪软件的演化。和项目有关的信息都应当放入基线，比如需求文档、原型、UI设计、程序设计、测试用例。针对每一次迭代每一个版本，都应该建立基线，用版本号区分基线。如果没有基线，你如何管理你的需求？？如何管理你的原型？？

5、需求和设计被混淆在一起，造成项目返工。最典型的现象是，在需求评审的时候，你会发现文档里面既包含需求信息又包含界面设计。这个界面设计就是通常所说的界面原型。原型是用来澄清需求的，针对复杂的、模糊的需求。所以在需求开发的阶段，原则上不应该有界面设计，如果有，那也应该是少量的，低精度的，不应考虑界面的布局。需求定义的是做什么，而设计定义的是怎么做，两者有明显区别。正确的流程是，先定义需求，再评审需求。等需求修改完毕确定无误后，再设计界面。如果把需求和设计混在一起评审，势必会造成设计的返工。

6、技术架构复杂化。良好的架构应当是简洁，所用到的技术越少越不容易出问题。有的公司的项目，同时用到了多种技术，比如多种编程语言、多种数据库、容器、微服务等等。一但出现问题，是难以排查的。而且就当前业务的体量，单一的技术架构就足够满足需求了。架构越复杂，管理成本就越高。现在国外有些大厂开始去微服务化，就是因为他们意识到，微服务成本高，而且还不能产生经济价值。

7、使用不成熟的技术、非主流的技术。这些技术没有经过长时间的大量的验证，其本身可能存在各种各样的问题，质量问题、安全性问题、易用性问题等等。而一旦出现了问题，你是很难解决问题的。也许官方文档并不完善，提供不了解决办法。上搜索引擎找了半天也没有查找到解决方法。加入开发群或论坛也没人能提供有效的解决办法，毕竟用的人实在太少了。所以技术选型，不到万不得已，尽可能避免新技术。日本IT界就普遍不喜欢新技术，他们更喜欢把老技术用到极致。一是技术本身风险低，二是老技术就可以解决问题，三是把老技术发挥到极致的学习成本其实是很低的，四是人员招聘更容易，你想想，你想招聘一个会使用非主流技术的人，是不是要招聘很久都还不一定能招到。

8、敏捷开发被误解被滥用，成了逃避流程和文档的接口。敏捷不意味没有管理，也不意味着不写文档。许多团队声称自己在搞敏捷，但实际的做法和真正的敏捷是不一样的。敏捷开发确实有一些实践方法，虽然不多，但是要做到甚至做扎实是很难的。例如每天开站立会议、结对编程、客户方全程参与、客户随时执行功能测试、每个项目小组不超过10人、每周工作40小时。试问一下，以上这些你的团队都做到了吗？？大部分公司搞敏捷，最终都是失败的。一方面是对敏捷的认知不够深刻，另外一方面是团队成员综合素质问题。敏捷要想成功，必须每一名团队成员都是精英分子。然而这样的团队是难以搭建起来的。就好比是上楼梯，一格一格上去是比较稳的。但如果你跳着跳着上去，就很容易摔跤。而一旦摔倒了就会落后，耽误时间。

敏捷在实践的时候，容易遇到各种各样的问题。在书籍《术以载道——软件过程改进实践指南》中，作者汇总了一些经验教训，摘抄几个问题如下：

1. 【需求】故事、任务的目标不清晰，导致开发前期存在迷茫。
2. 【设计】通过评审代码，感觉有些功能是在完全没有理解设计思路的情况下，直接编码的，有点想当然的感觉。
3. 【编码】维护老代码很痛苦。
4. 【测试】演示时还有不少问题。
5. 【估算】估算得不是很好，有些问题没有考虑，超出预期。
6. 【计划】整个团队陷入BUG怪圈，忙于BUG修改和查找新的BUG，团队其他成员忙于修改BUG。
7. 【任务分工】事情优先级划分不明确，导致几件事同时压着做。
8. 【站立会议】每日晨会效率需要提高，往往开成半吊子会议：讨论，讨论不清；决策，决策不清；叙述，叙述不清。
9. 【沟通】Team缺乏主动与Product Ower沟通，产品设计的细节做得不够到位。自己与他人沟通不多，导致一些工作做了无用功或简单的事情复杂化。
10. 【人员激励】加班过多，作为敏捷开发方式，是不用加班的，可是感觉每晚都有不少成员在赶工。
11. 【团队协同】团队合作时，协调和交流有待改进。
12. 【文化】项目组时间和压力意识不足，认为本轮做不完就下一轮做的思想存在，没有充分意识到本期迭代产品开发的压力以及进度和质量要求。很多人热衷批评前人代码太烂。

9、忽视了培训、自我学习、技术预研。社会发生变化、市场的需求也会发生变化。要想适应社会变化，抓住市场机遇，企业必须持续调整政策。改变的可能是管理模式，也可能是技术方法。为了实施改变，员工必须持续学习，包括培训和自我学习。既然是学习，那一定是有成本的。然而很多企业讲降本增效，自己却不知道成本包含哪些。把成本和工资划了等号。这个成本属于看得见的成本的一部分，然而还有一些看不见的成本，例如沟通成本、试错成本、决策成本。这些看不见的成本甚至高过看得见成本。就拿试错成本来说吧。一旦出了差错，对企业的名誉势必产生负面影响。而且这个损失是难以估算的，可不仅仅是几个人的工资。另外，没有考虑到学习曲线之后的生产率的提升，忽视了投资回报率。

10、不重视生产率。可以举个例子。就我个人的经验，完成接口代码的编写，初级工程师每天完成5个，中级工程师每天完成10个，高级工程师每天完成15个，当然他们的薪资是不一样的。很多企业声称做产品要抢时间，但是他们自己却不关注生产率。招聘初级工程师和招聘高级工程师，哪个更容易抢占市场先机？？软件工程七原则中有一条原则是使用少而精的人员：

（1）人与人之间的效率差别达10倍甚至25倍以上，因此要使用精英团队。（这个我多次深有体会，曾经同事7个小时也没有完成的任务，我只花了1个小时就完成了。这就好比是做数学题，有的人5分钟就做出来了，而且算对了，还有的人30分钟也没有做出来，就是胡乱写一通，没有正确的思路。）

（2）采用多种方式提升沟通的效率和质量，包括：不要通过加人的方式解决进度问题；项目初期不要太多人员；为高性能提供高回报；淘汰低性能者。（这里的“性能”就是通常所说的绩效，也可以理解为生产率。）       

11、技术领导和人力资源不清楚如何选拔人才，提出奇葩的招聘要求以及和工作能力无关的要求。

导致：一是长期招聘不到人，使客户和领导层不满，错失市场机遇。二是无形中提高了岗位门槛，降低了岗位的可替代性，提高了管理风险。三是即便招聘到了人，也不一定是好的人才，捡了芝麻丢了西瓜。

比如就技术的层面，假设市面上有3个开发框架，A、B、C。公司项目使用了框架A，于是提出的招聘需求是熟悉框架A。乍看之下是没有问题的。然而这些框架严重同质化。当你熟练使用B后再去学习A，只需要一两天的时间就能达到熟练的程度。

再比如，把空窗期和工作能力用因果关系关联起来。实际上这是一种偏见，二者没有必然的因果关系。你看看公务员的招录会对空窗期有要求吗？？即便你几年不上班，只要考试成绩优异，照样会被录用。

再比如，把年龄和工作能力用因果关系关联起来。实际上这也是一种偏见，二者没有必然的因果关系。你看看获得诺贝尔奖的人是不是普遍大龄。平均年龄58，最高年龄97。美国总统的年龄超过80岁。将近80岁依然能参加总统竞选。

用AMD来举例。AMD公司在2012年的时候是濒临破产的，当时公司的股价还不到3美元。随后苏姿丰和吉姆凯勒加入了AMD公司。当年苏姿丰是43岁，吉姆凯勒是53岁。在两位大咖的带领下，经过了大约7年的努力，公司的股价涨到了160多美元，足足涨了60余倍。目前AMD的市值比Intel的两倍还多。Intel一直是AMD的强有力的竞争对手。近期Intel业绩下滑严重，已经宣布了一系列自救措施，包括暂停公司股息支付、裁员15%等。可能还会中断或彻底叫停公司在德国投资320亿美元建设芯片工厂的计划。现年55岁的苏姿丰依然在AMD任职，而65岁的吉姆凯勒则进入某初创公司主导芯片设计。这就是人才对企业带来的影响力，不仅让公司扭亏为盈，还让公司成为了业界首屈一指的佼佼者。

12、忽视学历和专业的重要性。学历代表的是学习能力和努力程度，比如一项新的技术方案，如果你给本科生讲解，也许2个小时他就能懂了。但如果给专科生讲解，也许讲了6个小时他也不明白。211和985的优势将会更明显。比如你让一个经济学专业毕业的人从事软件开发工作，他能最好吗？？连基础知识都不具备。即便有学习经历，也很可能基础不扎实。

13、忽略了一专多能的重要性。在软件工程七原则中有一条原则是使用少而精的人员。对应的敏捷实践是采用一专多能，交叉职责的人员。因为这样可以提升工作效率。这就好比是很多人说的全栈。全栈从字面理解就是全能，一个人把所有活都干了。而一专多能则没有那么夸张。

14、团队成员缺乏专业的科学的训练，脱离软件工程。上个世纪有很多软件项目以失败而告终。而这些项目组的成员均是技术专家。人们开始反思，提出了“软件作坊”和“软件危机”的概念。随后逐渐发展起软件工程的知识体系，旨在消除软件危机。

15、企业不重视过程改进，甚至没有过程改进的概念。绝大多数公司的开发过程至始至终没有发生过变化，开发水平原地踏步。《软件工程（第4版·修订版）》中描述：根据CMM“成熟”度等级改进其开发过程，Hughes飞机制造公司的生产率提高了4倍，并且节省了数百万没有。类似的，雷神公司的生产率增加了2倍，并且过程改进中每1美元的投资都有7.7美元的回报。在某空军基地，工作人员注意到其生产率提高了6.35倍。

16、不愿意在人员招聘方面提高成本。招聘就好比联姻，人没选对痛苦半辈子。选对人了快乐半辈子，能省很多烦恼。然而很多企业不重视招聘，不详细浏览简历，捡了芝麻丢了西瓜，错过人才。有些职位的描述也不正确，是从其它地方抄过来东拼西凑的，显得不够专业。比如公司明明没有使用XX技术，却在职位描述中写上“精通XX技术”，有一种应付的感觉。

时间有限，暂时就想到这些。

以上种种问题造成的结局就是企业裁员甚至倒闭。即便是大公司、知名企业，也会有大面积裁员的情况发生，屡见不鲜。企业要想成功，必须尊重4个规律：科学规律、人性规律、市场规律、经济规律。