瀑布模型中的纠结

1 引言

就我了解大多数软件企业的项目管理模式，仍然采用瀑布模型。在传统的瀑布模型“需求——设计——编码——测试——发布”中，一些规模企业为了规范管理，将每个环节的每个角色的职责定义的非常清楚，通过工程的方式解决了分工和协作问题，使得大型软件研发和维护成为可能，但是也引入了新的问题——各种纠结。

2 时间 时间

时间就是金钱。在软件产品市场，时间就是客户满意，时间就是领先竞争对手！

在软件研发过程中，时间，很纠结。

对于大多数中国软件企业而言，都处在买方市场，买软件产品的企业都是大爷。为了更清晰的表述，请允许我把买方等同于甲方，把软件研发屌丝所在的企业称为乙方。根据甲方各种情况带来的时间节点，就很容易成为软件产品研发过程中的deadline。

就乙方来说，有两大类：

1） 做的产品比较成熟，甲方的需求变化小；做关系产品，基本能用即可，需求的偏差靠酒杯或者其他方式进行修正。

2） 做大量新产品；现有产品需求变化大。

当然，本文需要谈的是第2类，大部分苦逼屌丝程序员所在的软件企业。

OK，把思路理一下：甲方市场；签单时明确deadline；产品需求变化大。

这就很纠结了，一方面，甲方给的时间点是确定的；另一方面，产品需求变化大。或者即使产品需求变化不大，给的时间确出奇的少，还美其名曰体现乙方的实力。与此同时，就少量的几个程序员在吭哧吭哧干活，擦！

当然，这里出现的时间纠结，是对程序员而言的。

对于这种情况，仔细读过《人月神话》的同学可能会得出这样的结论：项目必然失败。但是，在中国，大多数类似的项目，虽然不能说是成功，但都是在deadline到的时候完成了交付，为啥呢？因为有我们最可爱的程序员——把青春与身体奉献给加班的人们！

所谓纠结，是时间不够，而又不得不完成项目。

所谓纠结，是企业的“收益”与程序员的“损失”。

所谓纠结，是年轻的程序员如何平衡“收益”和“损失”。

无论无任何，在时间上，乙方现在、将来都将处于弱势。而乙方的兄弟，又是弱势中的弱势。

所以，对于有节操的乙方企业，在这种情况下，尽量对员工，钱，给到位。一个项目告一段落或者工作间隙，尽量让员工爽一点（比如，灵活的换休政策，鼓励旅游等放松活动）

所以，如果程序员，你够遇到一个关心你这种纠结，理解你这种纠结的领导，你就从了吧。

3 割还是不割

当前版本交付deadline汹涌来袭，时间不够了，割功能吧。不行！因为甲方说不可以割。

那就割研发环节吧！

需求，可以写简单点；设计，可以把概要设计省略；编码，不讲究可维护、可扩展、可复用、灵活性，只要实现功能就极好了；测试，按照甲方验收手册来整，乙方企业原来的规范，都可以变成浮云。时间紧张的时候，割研发环节，当下是爽歪歪，V1.0顺利发布。

可纠结来了：软件产品，一般而言，不是一锤子买卖。还需要演进，还需要新增/变化功能。

V1.0上线，甲方既定的计划得到了保证，一堆甲方自家的KPI漂亮的像花儿一样。V1.1提上议事议程。

V1.1的需求来了，真的来了。乙方的程序员一手新需求，一手老代码，欲哭无泪！这是要闹哪样，需要重启炉灶啊……

那割还是不割呢？

割的好处显而易见，可以在有限的时间，尽快完成可运行的软件的交付。

不割呢，要么你增加研发资源（貌似又有人月神话的陷阱）；要么你搞定甲方，延长时间或者减少功能需求。

就本人的个人经验而言，甲方很难搞定，如果不能显著增加研发资源，在当下的版本眼中，最好还是把能割的割了。

割，新问题来了。

1）割掉的东东，要不要抽空补上？

2）割出问题来了，谁来担责？

对于问题1，一般来说，至少口头上，企业流程上都会选择补上。但是，实际情况是，一旦割掉，不是想补就能补得回来的。特别像有些企业，每个人都是有并行任务的。A产品V1.0交付后，可能B产品的V1.0又来了。总之，你会感觉有很多更重要的事情，去阻碍你补作业。另外，无论是对于搞需求还是软件的兄弟来说，比较倾向于搞新鲜东东。对于补作业这种没有啥新鲜感的东东，在潜意识里面的拒绝的。或者即使补，由于很多东西都已经实现了，会补得比较潦草——简单，跟不补也没啥两样。

要把这个问题解决，一方面企业要有这个环境来保证这个补作业流程，例如，企业的要求；另一方面，需要基层管理人员有能力把这个动作落到实处。更重要的是，不要把这种临时的割当成常态，一旦成为常态，研发人员就会习惯与裁剪或者弱化过程，就会给企业的软件质量带来致命的损伤。

对于问题2，责任的问题。这个问题比较好处理，就是领导负责制。谁给项目团队发钱，谁就有权拍板，有就担这个责任。对于这个问题，需要提醒一点的是，要避免掉入分权陷阱。因为不少公司，管项目和管人是两拨人。要避免除了问题推诿的情况。如果不幸出了这种问题，企业老总必须首先进行流程和权力梳理。如果流程没有问题，对不起，哪个部分人有问题，最好请他早走，或者至少要态度严肃的惩罚一下。

4 坚持还是放弃

割还是不割，是个短期的行为。

坚持还是放弃，我想讨论的是长期的行为。

某些研发过程，做起来索然无味，看起来真的没有必要坚持下去，例如，代码走查。当然，代码走查的必要性，我想只要有3年以上工作经验的兄弟，一定可以列举10条以上的理由。但是，你所在的企业，是否真正做好了代码走查，并且一直坚持在真正的做呢？

软件产品在交付给客户时，有两个方面直接贡献价值：一是软件产品本身，二是用户手册。隐藏在这两个东东下面的东西，间接贡献着产品价值：需求、设计、同行评审，测试以及上面提到的代码走查（实际上代码走查也可以看做一种同行评审）。

在什么样的情况下我们会降低对间接价值过程的要求甚至放弃呢？

可能有这么几种情况：

1） 重复劳动。部分工作在团队看来价值不明显。例如，对于数据维护类的WEB应用，大部分功能是增删改查，代码走查就和编程过程一样，显得有点重复并且价值不高。久而久之，做此类工作的开发人员就会降低对代码走查的重视程度，甚至认为代码走查没有必要搞。

2） 人员能力。对于客户来说，只关注是否可以按里程碑、按质量要求完成产品交付。我们的软件产品研发，也会以这个为最重要的目标。所以，有的时候，部分人员能力不够的时候，团队内部可能会选择容忍一下，也就是降低对间接价值过程的要求。例如，写需求的兄弟，可能对业务不熟悉（新招的）或者本身能力还达不到；同时这个事情为整个团队所共知。我们那么，在需求评审的时候，就会减低对需求的质量要求。我们当然可以选择干掉这个写需求的兄弟，但是这个要领导发话。我们目前最主要的是满足客户需求，而且还有里程碑在这里等着。所以忍一忍，也就过去了。我想，类似的事情可能其他团队多多少少遇到过。

3） 过程考核侵蚀。这个也比较麻烦。对于这些间接价值过程，做得如何，如何评判。一些有规模的公司就会弄一堆的过程考核指标来。对于过程考核，我觉得这样一种说服比较中肯“过程考核本身是好的，但是为了考核而考核，就会演变成无节操的追求数字，最后就变成了领导的自娱自乐和员工的无聊旁观”。比如说，需求的评审时的缺陷率。本身这个东东是希望推动需求质量提升。但是如果过分追求，就会出现不管需求文档本身好坏，大家一窝蜂的去找缺陷。这样的结果，就是在过程数据中遗留一堆分不清价值的缺陷记录。

4） 不合理的考核指标。例如代码行数。考核开发人员的工作量，代码行数可以作为参考，但是一旦作为考核（观察）指标，就变味了。搞开发的兄弟都知道，要想提高代码行数，那是so easy！但是，代码行数多的开发人员就是好开发？在类似的考核指标驱动下，本来大家追求优秀开发的热情就会搜到严重损伤。

面对上述种种，有些团队就会放弃对某些研发过程的坚持。当然，即使没有上述种种，能够把所有研发过程做到位的国内软件研发企业，应该可以称得上是凤毛菱角。

是坚持还是放弃，这是个问题。但是，对于有追求的团队来说，这就是挑战，就是理想。

上述的四种情况，除了第三种。我们都应该坚持做好间接价值过程。

第一种情况。应对方式是尽可能将简单/重复的工作交给工具做。例如第一种情况中的重复功能，可以考虑以模板的方式生成，将代码走查的重点聚焦到相对复杂的流程。

第二种情况。首先就是招聘的时候，用人单位能很好的参与。如果上下游环节也能参与一下就更理想了。当然，每个人加入一个新团队，都需要一点成长的时间。就个人的体会而言，敏捷团队运作方式，对个人能力的迅速成长很有帮助。但是需要小心敏捷团队的人员考评（据说360环评比较好，没有实际操作过，不做评论）。另外，对于不适合团队的人员，特别是经过一段时间培养，达不到要求的人员，该剔除还是得剔除，不能手软。

第三种情况。团队领导者要担负更多的责任，将无聊的过程数据对团队的影响降到最低，做好研发过程中最精华的部分。亲，如果你的团队领导是这样的，那你就幸福了。

5 对立还是统一

研发过程中，各角色：搞需求的、搞设计的、搞代码的、搞测试的、搞支持的本是同根生。却总会有那么一部分人，相煎的不亦乐乎。在一定规模的公司尤为突出。

公司大了，一起煮酒论英雄的场景少了，屁股决定脑袋的事情多了。

这事儿，良好的规章制度，清晰的角色分工好像都不太好解决。好像唯有超赞的企业文化，才是最优解。

回过头来看。理论上，如果分了这么多拨人，又有上下游“工序”关系，只要建立好各环节的输入输出质量标准即可。

可惜的是：

1） 需求，是自然语义，很难完全精确界定质量。

2） 代码。代码质量的评判，从来都是一个一直都存在，从未被解决的课题。

3） 测试。不是所有缺陷，都叫做BUG。只有测试出来的，暴露出来的才叫。有些可能在编码时就处于潜伏状态，甚至到产品退出市场可能还是这种状态。

正因为如此，为了进行质量管控，上下游“工序”的兄弟，在企业制度的号召下，某些时候就成了敌人：搞编码的人，提一堆需求缺陷；搞测试的人，提一堆代码缺陷。

那这事儿怎么玩呢？还得靠企业文化。当然，企业文化的背后，如要有给到位的薪水支撑，企业和员工共苦的氛围。如果有了优秀的企业文化，把研发团队的各个角色都整到像打了鸡血，大家都本着对最终用户负责的态度，并从这个态度出发，梳理各环节的目标和工作输出，最终做到各角色其乐融融，也不是难事。（当然，这里是作者在YY，实际上能做好这一点的，在大公司中屈指可数）

6 结语

在软件研发管理的实际工作，过去有，现在有，将来也必定会有各种纠结。但是，总有一些企业，可以超脱于这些纠结之外。这些，企业，无论大小，都有一个鲜明的特点，就是外面的人想进去，里面的人不想出来。如果你的公司具备了这样的特点，那就请兄台好好干吧。