项目收尾之艰难

这一年做了几个项目，发现屡屡在项目最后收尾阶段整个项目组会陷入痛苦的挣扎，甚至出现心力憔悴，畏惧和客户开会的情况。但是在项目开始阶段，大家都激情四射，快速的学习相关知识，闪电一般的完成自己模块下的功能开发和调试，如同打了鸡血一般。结合我这10年的技术经验和其中几年的管理经验，我发现这是当前做项目无法躲开的一个问题。

客观原因

这里讨论下客观存在的原因以及我的经历来看，什么样的项目不存在这样的问题。

项目特性导致

很多的项目的需求是从粗到细的，那么从整个模块的功能如：wifi bt audio bsp pcie等。这些从bring up阶段开始都是非常明确简单的，只需要开发人员付出时间和阅读资料的成本就可以完成。遇到难题也终归可以通过各种途径解决。那么接下来呢？以我熟悉的wifi为例，需要接入到平台上的特性，如：热点 p2p 投屏 扫描 链接 加密方式等，这些也是有经验的工程师可以轻松解决的。

以上都完成，这个项目也就进入中后期了，开始面临困难。这时候项目经理或客户开始要求一些他们关注的能力，如：性能，功耗，发热。这个时候就需要投入大量的测试、优化、再测试、再优化，面临客户挑战和友商竞争。这一阶段即便有经验的工程师也会相对痛苦，主要是工作繁杂而且前景不明。比如管理人员最喜欢问的，这个功耗上升3mA的问题本周能否解决？开发人员往往是不清楚的，而管理人员往往只关注结果，所以对他描述目前的困难并没有意义。

千辛万苦的上面的数据都完成了，开始补文档(本人还算擅长写资料，但是ASPICE差点把我写死)。有些工程师是不擅长写资料的，所以会反复修改，一些工程能力全面的工程师反而会比较轻松的输出文档，画出逻辑性强的图纸。最后就要面临非常细微的问题，如:耗电量突然增加，性能不稳定，低概率稳定性问题。这个时候就会进入最艰难的时期，出现log不足，问题不明确，无法复现问题等情况。研发人员需要绞尽脑汁研究问题的路径和如何自动取得log的机制。

什么样的项目没有这种困难？

需求非常明确的项目。公司已经做过很多次类似的项目了，对于细枝末节非常清楚，从项目开始就将所有工作梳理的很清楚，工作量是项目初期可见的，哪怕功耗上升0.1mA带来的影响都能做到心里有数。

客户也不怎么懂的项目。本人真的遇到过这种客户，自己做这个项目的定位也不怎么清楚，就是先做出来看看啥情况，所以要求也不高。这种优质客户现在不多见了。。。。

项目非常难

这里项目难是相对的，但是有时候项目难是由于制定了不合理的目标。比如让一个做wifi的工程师去做bsp性能功耗优化，这相当于变相增加了项目难度和项目风险，虽然有时项目组为了利用人员而不得不做，但是这种影响可能会导致项目整个阶段都十分混乱。工程师不懂这部分技术，管理人员只关注deadline，客户要求很多细节的功能和数据。

这种情况在大厂就比较难出现，因为即便再小的模块也有2个以上的工程师负责，不会出现技术上的短板。

客户一知半解

这部分是最最痛苦的，客户一知半解会导致项目需求不确定，甚至在项目中后期出现代码重构的情况。少部分客户是从项目开始糊涂到项目结束，这就是我上边说的优质客户。但是很多客户会在整个项目周期中主动或被动的吸收相关知识，突然明白过来这个项目是啥。这也是为什么经常出现20个需求的项目后边变相增加30个需求。

这种情况的规避需要公司腰杆比较强硬，照章办事，增加需求就要加钱。但是商务经常挂在口头的为了长期合作考虑，这些需求免费诸如此类的话。

团队原因

大部分团队都是一个萝卜一个坑。即便公司比较成规模，一个模块分配4 - 5个工程师，那么也难免出现混日子的老油条。所以团队的能力总是不稳定的。

团队结束栈不全

一个团队的技术栈往往可能存在意料之外的短板。还是以我比较熟悉的wifi为例，作为一个wifi工程师可能需要懂得主题就是802.11协议，station，p2p, softap以及平台(android/linux).但是进入某些项目后，可能客户会提出wifi之上的网络的疑问，那么这个时候wifi工程师变身网络工程师；如果客户提出了硬件限制上的问题，wifi工程师还要客串和设备供应商之前的桥梁工程师。如果涉及到carplay等应用功能，wifi工程师可能需要假装应用工程师。

这一情况还是比较乐观的，往往wifi工程师可能需要客串android framework工程师或者网络安全工程师，那么这部分的工作就会进展缓慢。如果让wifi工程师客串了bsp工程师，那么会出现什么样的情况似乎难以预料了。

技术能力不足

理想状态下，一个项目在承接时团队的技术能力最好是溢出的。整个团队做这个项目最好是类似高射炮打蚊子，整个项目轻松写意，客户在见识到团队的能力后基本会听从技术团队的意见。但是现实往往是软件做出来到处漏水，被客户挑战到自闭。所以越到项目后期，技术点更加深入和细化之后，能力不足的团队会陷入泥沼，团队化身测试或百度小能手。

对于整个团队而言，只要存在某一领域出现这种状况就会非常被动。所以为什么一个公司的项目组总想找一个万金油的工程师用于到处救火。

工程能力不足

一个项目的完成，对于技术人员而言不只需要技术能力，还需要工程能力。这里我说的是：读写文档，英文能力，沟通能力以及逻辑思维。

研发人员非常容易陷入一个自我表述的惯性中。比如管理人员询问问题进展或功能可行性时，技术人员会认为管理人员已经知道相关的背景知识或问题的上下文而自顾自的直接说问题点，更有甚者会前言不搭后语的表达问题。这一情况如果伴随整个项目的进展，难免会出现管理人员理解的情况和实际情况存在偏差，一个挖井的需求被做成排烟管道也并非不可能。

逻辑思维能力似乎是所有研发人员默认具备的能力，但是真的存在很多研发人员逻辑思维能力不健全的情况。逻辑思维是一个整体的能力，而不是数学上的逻辑。拥有逻辑思维能力的开发人员的特点：

1. 善于抓住问题重点
2. 善于切入问题要害
3. 输出的资料前后逻辑清晰
4. 表达问题有自己的成熟套路
5. 学习知识可以沿着从粗到细或一点见面方法

工程师如何越做越轻松

在我做工程师的初期，我笃信知识和代码能力的提升能够让自己的工程能力明显提升而大量的阅读书籍、代码、博客等，又做了大量的coding，但是这部分技术的提升仅仅对面试有非常明显的益处。得益于我人生的第一个项目的甲方是非常成熟的跨国企业，被动的让我获得了额外的文档能力和沟通能力以及思维能力。

总的来说，知识量终归会随着工作的时间慢慢积累起来的。如饥似渴的学习知识确实可以让自己跨入更高的平台，但这不代表自己进化为了更高级的工程师。

换位思考

作为工程师，特别是一个提供软件服务的工程师最最重要的一点就是能够跟随甲方的思路去换位思考当前问题。这最大程度决定了自身的服务品质和团队的服务品质。比如点咖啡要求少冰是减少50%的冰还是80%？如果是高端的咖啡馆，咖啡师可能需要考虑季节、性别、咖啡风味来决定；要是瑞幸的话那么直接标准化的减掉冰块的数量就可以了。这取决于对自己的定位。

产品公司要求用户导向，软件服务公司要求客户导向，这都是要求工程师和管理人员跳出自身惯性视角来思考问题的方式。当这部分能力培养起来，沟通成本就会降低很多，有经验的技术人员应该都会清楚反复确认一个事情的过程有多消磨人(这里不得不吐槽一句我供职过的一家公司，一个问题我解释的非常清楚，但是由于中间人思维能力处于哺乳动物阶段导致又被上一层的人打电话询问，然后这个事情居然继续向上层转述不清而继续询问，最终演变的结果是一个问题被相同业务组的各级人员询问了10多次。所以为什么有些管理人员总会给人一种智力低下的感觉？因为他只关注结果而不在乎过程，所以他只能向上提供结果，而分析过程中每个节点昭示的影响他是不考虑的)

文档习惯

看到这个不得不说一下，以前的同事大多喜欢先写代码后补文档。现在有所改善，管理人员会强制要求工程师在每个阶段输出文档，但是上有政策下有对策，文档里几句话一个代码截图，这种文档就是一坨shit。

一篇文档我的习惯是从宏观到围观，从逻辑到时序，从过程到结果来完成。根据我的经验，文档可以有自己的特色，随后公司的要求只是把上述资料扩充、重组、润色的过程，是非常容易调整的。如果是我上边所说的那坨shit，你就有的改了。审核人员看到第一页基本就会给你打回来，连第二页都不会看。你改好后，审核人员继续从第二页打回来，如此往复。然后工程师还会抱怨为什么不把所有的问题一次性列出来(跑题的作文你让我怎么给你改错别字？)

但是国内的一些企业(同样的上家公司)，写文档只是提供了一个参考，不论你写的多么详细看的人都是惰性的打电话问你他这个功能或是需求怎么套用。

开放思维

作为技术人员和客户或者用户沟通时，不要第一反应就是对方是弱智。特别是当对方处于高平台的公司，这些公司都是有独属于自己的方法论的。例如：如何看代功能，如何分析问题，如何挖掘深层次的原因等。工程师在沟通过程中要保持客观理性，思考对方的方法论对比自己目前的思维模式的优势。

这一点就我个人的经历来看，国外的公司普遍成熟一些。一些不懂技术的项目经理也可以对问题进行深入的挖掘，就是因为深入一个问题需要的不是知识而是逻辑。学会这种逻辑某个模块的工程师也可以快速切入新的领域。

总结

个人认为，以上这些能力会让项目的收尾的难度降低。作为工程师，还是要相信过程，完全相信结果导向会让技术人员陷入泥潭。