软件研发的无效劳动2

2、设计，雾里看花!

当软件最终完成，实际编码往往已不是设计文档描述的样子了！

排除需求变化的因素，原有的设计根本无法指导真正的编码。接口制定错误、逻辑设计错误、算法效率问题等等等等，都是在后期联调测试过程中才暴露出来的。而设计质量的低下，对后期的指导意义自然大大降低，后期不断的修补，在固定的进度之下，质量自然可想而知。为了保证按时交付，设计文档们被匆忙赶出，应付着QA，急忙进入下一阶段。这个现象，很多项目组都存在。如果这样的设计文档继续存在下去，又谈何设计同实现分离？

3、代码，Freedom! Freedom!

好多人心中根本对流程毫无概念，他们会对坚持流程的人说：“灵活一些嘛。”而他们的灵活，就是直接修改代码，不提规格变更，不提设计变更。套着个先进的IPD-CMM外衣，里面却是个代码作坊。交付的文档只是为了应付QA审计，其实同代码根本不配套。后期维护时，大家面面相觑，这是哪儿来的规格？这是谁提的需求？这规格是象代码实现这样的么？还是代码实现有错误？全部，都变成了问号！可悲的是，持这样观点的，有很多人还是项目经理！

4、决策，“我死后，哪管洪水滔天”

项目要不要做？有没有衡量标准？经历了N个月，长假加班，春节加班，最终完成了项目。不久被告知，此项目客户不需要了，停掉！不仅对开发人员的信心造成了打击，也极大的浪费了资源。机会成本更加高昂！相比上面几种无效功，错误的决策造成的无效工作后果更严重，浪费更大。

5、规格，“你在哪里——在哪里啊？在哪里？”

存在这样的现象，没有人能从一个地方找到某个产品的所有规格！在维护过程中，需要确认规格，经常是原来的规格文档、CCB结论、会议纪要、讨论纪要、甚至邮件中一顿乱翻。找到还好说，找不到就按照自己的想法同人简单交流一下就下了结论。我们的质量靠什么说话？符合规格的就是高质量，不符合规格的就是底质量，而我们现在，连规格是啥都找不到，凭什么说质量？