4
看到这个标题，作为工程师或者曾是工程师的您是不是很想说点什么呢？一个项目，从立项到实施，中间涉及到市场、研发、生产、品质还有销售多个部门，合作的团队少则几人，多则几十几百人……
作为项目中的一员，您可能要辗转出差，可能要整天开会，甚至可能要通宵加班，来确保项目按schedule正常运行……
但是客户需求不停变更，产品设计不断出现bug，部门与部门间相互扯皮……这些似曾相识的经历是否曾让您在项目执行中感到抓狂，感到无语呢？
面对那些最终没成的项目，曾作为当事人的您，肯定是想说些什么吧！经验也好，教训也罢，抱怨愤恨也行……让我们一起聊一聊“那些胎死腹中的项目”。
本系列的首篇，将由朱玉龙来讲一讲他的一个不算成功的项目。
谈这个项目，其实持续的时间已经很长了。早期的策划是在2011年3月份，就已经开始了。这包含了很多的早期的策划、筹备、预算和启动，真正的涉及技术方面的内容是在2011年的11月份左右开始，时至今日，我还在挣扎着一点点去解决层出不穷的问题，当然就像一个轮盘，哪天一个意外就是转到另外一位工程师，然后心急火燎的去解决问题。
我细细想想，这并不是一个很奇怪的项目，而是一个很正常的项目。从它的范围和投入来看，预期稍高但是定义好了也是可行的。从大的层面上，现在看来，有以下的几个原因可能是：
1）领导们对问题的考虑还是简单了
2）工程师们没有很好的系统协调
3）资源和时间的考量少了
首先谈第一点，为什么考虑简单了呢？
这其实有点类似于更改，在一个现有的东西上，去做优化和更改，对于领导可能觉得整个进度是100%，原有的已经是60%，只需要40%的努力就可以达到了，但是实际的情况其实并不是这样。两个设计目的不一样的东西，需要的内核也大相径庭，有着诸多预设好的限制，往好了说是给你预先做了决策；往差了说的话，就是带着镣铐在跳舞。而这个心目中的40%的工作量，意味着领导的耐心也是不同的。所以后续的发展，往往需要去了解原有设计的一些细节，在原有设计的限制上去腾挪转移。
其实这个问题，还有另一层，为什么没有反馈？在组织的层级里面，工程师、工程经理和工程总监，三级的组合，是单线条的。对比美国这里，大量的技术委员会，可以提供一个相对独立也被认可的结果。但当一技术问题的质疑，让一个工程师来承担的时候，谨慎的工程师最大的可能是给出一个较坏的分析结果给经理；乐观的直接截留了。到了经理层面，就更存在疑点的，然后传着传着就没有问题&风险了。反正留着工程师就是解决问题的嘛，解决不了，铡刀不是在那里么？
第二，工程师之间的系统协调
由于有了上面一条，对于系统的功能描述和对每个部件的情况的交流，也就相当的匮乏了。前者，让部件很难在设计的时候，就能保证非常顺畅的协同工作，特别是完全没有一定的系统冗余度；后者，就让功能的分配在初期留白。相对理想的情况下，在一组系统架构（电气和通讯）需要做细致的协调，而系统级别的功能，根据架构的确认，在各个部件，是天生需要各个子系统／部件级别进行分配。你既可以把功能放置在A里面，也可以放置在B里面，分配的理由是按照一定的评判标准来确定的。
而我们实际在做这个的时候，时间上就晚了很多，都是已经开始做了开始协调，这么一来设计初期就面临大量的工程问题和工程更改。
1）部件工程师各自交流问题和分享材料
2）某个部件工程师发现自己部件和其他部件不兼容问题
3）提出问题至各自的工程经理
4）开各个部门碰头会，各自陈述
5）书写会议记录，等待下一次开会
在整个设计和样品试制的过程中，我们错过了机会。而在出来之后，便周而复始这样进行半死循环状态，项目的前进状态也导致整个项目的拖延。
最糟糕的，其实是在都装上去以后，进行验证的状态。你可以想见，当出现各种不良的症状的时候，一堆人的疲于奔命去解决问题的情况会让人有多沮丧。
第三，资源和时间
对于资源和时间的问题，我倒是想的太简单了。我一开始以为，只要主导的工程师能够脑袋清楚，供应商能够精明干练，配合五件，那做事情的成本和代价就会小很多。但事实给了我一记耳光。没有资源，也就是没有人和没有钱，真的就是很难将一个部件做的很好，一分价钱一分货在部件领域也是被无数次印证的。部件的开发，最开始的就是需求，需要工程师对需要部件的功能、接口、性状和其他特性有清晰和明了的定义。在这之后，就需要对需求和问题充分沟通和交流，以确保文字的理解。随之而来的就是报价，定点和开发的开始。
一般而言，报价贵的供应商，对负责的工程师而言，要考虑的东西往往大部分都在前面；因为只要功课做好，供应商会充分考虑了你的需求，对此进行问询和探究，这种做法肯定是优先的；报价便宜的供应商，前期并不注重需求分析和方案的仔细核对，为了争取得到项目，前面的响应速度会快的惊人；但是往往后面才是混乱的开始。对个人而言最具挑战性的事情，是你管的东西后面有个供应商；与你非常相关的部件后面有个供应商，这两个供应商是两种不同办事风格和价位。当冲突发生，需要协调的时候，就是很考验人的时候了。人是考虑责任的，尽可能将安全留给自己，将风险留给他人是本能，从博弈的角度来看问题，往往在职场的现实中并不容易。
基于前面的叙述，由于领导的偏见，对系统和要求的看重程度，最无法克服的往往是钱的事情，项目组能总是将各个大系统给了优先级以及基本预算，分到每个部件又是一个数字。一个50W预算的和500W预算的部件，分配到开发、验证和样件数量上面各个方面的多寡显而易见。所以你很难在较少预算下面，要求供应商按照功能安全的流程走，也没办法让他制定一个完整的验证计划涵盖机械、电气、环境和化学甚至是耐久和电磁兼容。这个里面加入了质量和安全需求，一般小型的国内供应商还没有到那个层次。没有这个的本身意味着一种赌博，但是那种必定会输的，到了最后是难以接受。
谈谈其他的因素：
平心静气的回顾所发生的一切，没有人不努力，哪怕前面有点心不在焉，但是后面为了饭碗总是被赶着走的。我们整个项目的人为因素，比较重要的部分就是我们开发过程的项目经理。他的性格上有着傲慢、自大、多变和健忘等，统统都在我们展开项目之中遇到了。他几乎就是随心所欲制定他心中所想的那些事情。在安全、预算、功能、时间管控和开发难度几点上，几乎是连哄带骗的把整个设计带到了死胡同里面了。
对于我个人而言，这个项目还是受益颇多的。从成功中学习固然很好，但有哪件事情是完美的呢，从做成做不成的事情中提取要素，记录过程，反馈和总结，我还是得到了不少的思路:
a）项目的开始：做的非常不顺心。这个阶段正是，想要定需求的时候，没办法协调，眼睁睁看到可能的问题会发生。
b）部件定点和实施：既然已经在坑里面了，多少学些东西。这个时候努力在和相对应的工程师，进行单独的探讨，多干点事情和多负点责任，从小系统来说基本都覆盖到了。
c）部件测试和整合：这个阶段做的很辛苦，主要是好多别的部件没到，单独测下来好多内容并不完整。
d）解决问题：这段时间确实是比较麻烦，三天两头有和预期的功能不一致的问题冒出来。一点点把这些给处理掉，考验耐心和毅力。
这个项目从大范围来看，也不知道是不是最终会失败。对我而言，不算是一个特别成功的项目吧，先写到这里吧。
与非网原创内容，未经许可，不得转载
如果您想与朱玉龙有更深入的交流，可以关注他的与非博客：https://www.eefocus.com/yulzhu/blog/
如果您也想与大家分享自己曾经不成功的项目经历，欢迎与我联系，我的邮箱 yuehao@eefocus.com，QQ 406039590。详细征稿要求可点击【征稿启事】
