记一次不算成功的大型项目的失败点——引以为戒

     前段时间刚做完一个项目，公司定义为大型项目，我们使用的C语言编写的。我统计了代码量500w+总行数，300w+有效行数，总共5个单独业务单元，假设5个业务单元代码100%重复，那么就有60w+有效代码；这个项目从立项到TR6评审总共耗时13个月；项目做完时开发人员9人（含领导），假设领导也都写代码并且代码量与主力开发相等。计算得到我们项目工作量约为190有效行/人.天，不算专门的测试人员。

项目背景：

      该项目最初是个改造项目，是把一个已有的传统的嵌入式设备改造后，做成一个所谓的云服务平台。立项时应该是4个月完成， 实际做了13个月。可想而知本项目的问题有多严重了。

    本人希望以我的观点对这个项目做一下总结分析，为毛项目延迟率高达300%？

项目总结：

     1.人员流动过高：

      项目初期研发（不包括测试）一共13人参与，包括技术预研，方案设计，代码实现。初中期时离职5人，而这4人中有1人单独负责设计一个功能模块，1人负责整个管理模块的需求及概要设计；中期由于人员骤减又补充了三名成员（别的部门借调2人，自己部门其他项目1人），同时一名主力离职，离职的同事负责一个主要业务单元的设计及实现；中后期，新补充的两位同事离职；后期又招聘到一位新人。

    从人员流失来看，项目从立项到TR6一共有16人参与，走了8人，占参与总人数的50%（不算后期加入的新同事）。那么人员流失率为什么这么高呢？包括被借调过来的人都离职了呢？我统计了离职的各位离职的原因（主要因素）：1个追求更好的平台（做设计的同事，入职5年）；2个人干着不爽（一个是主力写代码的一个是独立承担业务功能的，入职4年）；4个追求高工资的（都是年轻人，入职2年左右）；1个不符合要求劝离的，从别的部门借调来的（新手工作1年）；

    我想说的是：项目启动之初就应该对项目成员的稳定性做基本的评估，如果遇到减员一定要及时变更项目计划，避免项目本身产生巨大的压力，压力太大会加大剩余项目成员离职的概率，这样持续的话会是一个恶性循环。

    2.项目需求变更太大：

    该项目立项之前基本都做了项目分析，目的是清楚的，改造以前的产品做一个云化的服务平台。对需要修改的地方都做了评估，理论上4个月足以。

    第一次需求变更：领导认为最早的需求过于简单。以前业务模块之间都是都是内部接口通信，现在需要改成Restful接口；最早是使用sqlit数据库和自研数据库，现在要改成mysql数据库；以前的数据设计有问题，最好重新设计；以前的配置管理不好，换成netopeer接口的；嗯，本来只需要在业务测进行删减，在管理测进行适配，在部署上进行优化的东西，相当需要重做。

     第二次需求变更：最早我们做的东西只是放在共有或者私有云上，实际上也就是服务器上运行就行。领导觉得我司自己既然也在搞所谓的云平台，那放在自己的平台上也是必须的。他们也不想想自己做的是个毛线的平台，其他部门都没人用的东西，强推我们使用。最后TR6结项时还不是把这种部署（在自研的云平台上部署）作为一个选项，不正式发布？自己的云平台太烂，领导最后意识到外面没人会买。。。然后废了在自研平台上部署。

    其他业务功能上的变更都不必提了。

    我想说的是：需求变更可以有，本来也是不可避免的，但是需求变更时不能拍脑袋，要分析需求是不是伪需求，是不是必要的需求，这个需求是不是可以推掉？不能由着老板或者客户来，变来变去最后还是变成了最出的需求，这谁TM都受不了。

    3.项目计划制定太激进：

    领导的心比天大，嘴也比天大，“吞天兽”这个动物最符合对领导的比喻及描述。领导今天有个想法，恨不得明天就能做出个产品，后天就能卖钱。所以，项目开始时，即使需求有变更也没有改变项目计划。虽然后期改了，不改没办法啊，人都给走完了。我们的项目计划大概是这个样子：一个月的需求分析加总体设计；一个月的概要加详细设计加技术验证；一个月的编码；一个月的测试；然后顶多延期一个月就上线卖钱。

     领导完全没有考虑人员流动的风险，可能考虑了但是没想到走了一半吧。这么激进的计划会更进一步的逼走员工的，领导都不想么？可能你们都没有见过一个月一个人写10w行代码吧，嗯~我见过。

     领导也可能没有想到技术预研做出来的demo并不能保证实际使用时的正确性吧。我们就遇到了，有一项技术，初期认为我司有部门使用，并且我们自己也做了demo，发现没问题，但是实际使用时，我们使用场景完全不同，使用的数据量要大于我司其他部门一个或者几个量级，最后发现不能用，而且做该模块该技术的同事由于受不了这个工作环境要离职，你可以想象当时领导的脸有多黑。最后对要走的同事使了多少绊子，导致人家错过了一个工作机会，不得不重新找。

     我不是想贬低领导，只是想说，项目计划要制定的靠谱，该变更计划时就要变更计划，不要强逼你的兄弟去996，意义不大，在大家都疲惫的时候，会有人走的。

      4.测试因素

     我司的测试能力一向较弱，就算好不容易招几个好点的，锻炼两年后基本都走了。。。本次项目中也走了一个测试。

     我司测试不会自己研究协议、设计文档，然后根据这些设计测试用例，而是等我们这些开发挤出来的丁点时间给他们讲解该怎么测试。大写的尴尬。但是总体上比较敬业，能把我们这些开发讲到的东西都测试到位。但是我认为这不是一个合格的高级测试人员，稍微高级点的测试应该尽早学习相关知识，尽早参与需求、概要、详细设计的评审，然后从这些文档中先过滤出一些设计不合理的地方，提出疑问或者建议；再者，需要根据需求设计自己的测试大纲，然后分解测试大纲写测试用例，这样的话，就算开发在详细设计阶段设计漏了也会在评审测试用例阶段发现自己的疏漏然后改进设计方案。最终达到bug的尽早发现。

     测试过程中，由于开发时间仓促（30天10w行代码），问题当然会很多多到可能测试不下去，测了几轮后测试同事发现这样不行啊，版本质量太差测了没效果，然后协商定义了一套测试准入用例，开发在发布前先依据测试的准入用例测试一轮准出，然后测试再执行一遍准入，准入通过进入正是测试过程。那么问题来了，我们在13个月项目期间一共提测了α八个版本，β六个版本，共14个版本，还不算其中有几次有临时版本。从第一次提测到最后一次提测用时7个月，相当于没两周一个版本。如果每个版本都要进行准出和准入测试则需要28个工作日，相当于多一个月的工作量。

     最后几个版本提测有好多问题其实应该在α版本就测出来的，竟然到最后才发现，然后就需要重新修改、自测、准出、提测、准入、回归、稳定性等过程。。。。嗯实在是(╯▽╰)好香~~。这种情况的出现，一般都是用例覆盖不到导致的，能侧面证明一件事：测试的同事并没有将最基本的使用场景分析完全，可能对异常测试也测的较少，用例的积累也做的不好。我在测试看过他们测试，有些测试根本就是想到哪就测到哪，测试策略，按自己的用例一个一个测试都做不到。。。

    我想说的是测试是软件开发过程中的重要组成部分，一定要重视，重视，重视。不是嘴上说的，必须人员得给够，招聘时也得有基本要求，当然工资也得和开发差不多。不能不把测试不当开发啊，而且测试也要自己争气啊，提升自己的业务能力，学习些测试理论，都是好的。

     5.沟通成本

     以前我在的项目同事之间配合时间较长，所以沟通交流基本无障碍。随着公司壮大，部门成立，新员工加入，带来了各种各样的我认为不好的习惯或者做事方法。首先，是邮件沟通方式，说实话我很不喜欢，有事当面说，然后发邮件确认就ok了，现在不了，全部改用邮件沟通，一个屁大点事就要交互好几次，面对面几分钟能说明白的问题，邮件需要个把小时，甚至半天；其次，是定了工作量后，屁大点事都要经过直属或者更高级领导的批准或者任务下发。美其名曰，要让领导记工作量，嘴恐怖的是怕两个领导关系不好，一个想给一个使绊子，领导本不想让你做这个事你做了，那岂不是不给自己领导面子。真是操蛋，屁大点公司就搞这套，真是可以。

    从前我工作时不用计算沟通成本的，现在必须得算啊，一算吓一跳。正常工作的时间估算至少要提高2倍以上。假设俩程序员直接沟通需要一个单位时，现在需要先请示你的领导A，然后在两个领导AB沟通，然后B领导再下任务给你的同事，然后你们在沟通真实需求，这不得多两个单位时。。。。

   沟通成本不是简单的时间成本增加还有其他成本也会跟着增加，具体得自己体会。

    我想说的是，沟通成本其实很大，一定要想办法降低沟通成本，因为这些增加的沟通成本毫无意义。

综上所有，在提到环节上都有时间上的浪费，开发周期不延期都不符合事物固有的规律了。