前言
一个项目的成员可能会来自各个领域，包括材料、机械、硬件、软件、仿真、测试、电气、项目；不同领域的人知识背景不一样，认知方式也不一样，假设每个人都是专业性很强、在各自领域都是翘楚的存在，那么不可避免的存在一些思维定势：这个产品在我这个领域它是这么做的、其它领域的人要配合我这么做（简言之，我的方法论是经过实战检验的）……项目刚开始倒问题不大，一旦进展加快到了系统整合、需要多科学配合的时候就往往容易为一些配合问题争执不下：你必须要以我认可、最舒服的方式来跟我合作，这些gap其实就是工程项目中的系统性认知偏差，跟贪心算法很像，每个小团体都在不由自主的追求局部最优解，而放弃了整体的最优路径
不科学的想法
一些非软件学科、不科学的观点经常会在项目里出现，并尝试主导、影响软件项目的生命周期，比如：
① 项目人员觉得软件跟硬件、机械一样是可以逆向的，只要逆向出代码就能还原整个软件项目
② 软件自己进行测试验证就OK了，我们都是自己测试的，没必要有专门的测试人员
③ 软件可以像机械一样一版定型的，验证过就马上可以量产了，没有迭代的必要
④ 代码是不需要托管、做版本控制的，自己管自己的本地代码就行
⑤ 找个核心人才来面试，不需要JD，打点关系就可以把项目做成功
⑥ 硬件已经出来了，下个月项目验收
⑦ 客户需要这个功能，十万火急，做个定制版本给他吧
但事实上，软件项目有其固有的开发模型、迭代周期、工作流程，需求出了偏差也需要调整时间、计划、资源、人力来作为补偿，而不是一味地剥削软件工程师的剩余价值
相信谁
那么应该相信谁？
- 相信权威专家的判断，普通人”知之不全，往往危害不浅“
- 不要轻易妄言自己不擅长的领域，包括高谈阔论、不懂装懂，要有敬畏之心
- 实事求是，权力和责任往往是相匹配的，错误的决定往往和严重的后果挂钩
软件的声音
软件学科的一些比较好的观点：
① 客户提出额外需求，安排产品和项目人员进行进行项目变更评估
② 预留充足的时间去评估工作计划，软件工作包的分解尽量细致明了
③ 测试计划也需要十分明确细致，预留一部分时间给软件人员修复缺陷
④ 根据项目的复杂度安排相应的开发模型，如瀑布模型、敏捷开发、V模式、螺旋模型……
⑤ 一个复杂的产品最好由一个大而全的系统工程师统筹负责，由他来推动项目的方方面面
总结
每个人从不同的角度看到杨桃的样子都不一样的，正视偏差的存在，有的人看到的就是五角星，有的人看到的是果实……
只要是人都是依靠自己的知识与认知并且被之束缚生活着的，那就叫做现实。但是知识与认知是模糊不清的东西，现实也许只是镜中花水中月，人都是活在自己的执念中的。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
