聊聊IC应用工程团队的管理

当我思考这个题目时，脑海中回想起了2006年我的上司对我说的一句话：Manager is Management, not technical job. 正是由于这句话的启发，我才逐步转型到真正意义上的技术管理职角色。
我的上司是技术出身，最早是在日本三菱从事4-bit MCU的应用开发。他40岁时转职到瑞萨（中国）工作时，已经是优秀的管理者了。
2005年，我是作为通用MCU应用团队的Team Manager入职瑞萨（中国）的。由于团队是全新成立的，而我之所以能以Team Manager的身份入职瑞萨电子，得益于自己的英文交流能力和丰富的MCU应用开发经验，无论软件开发、硬件Layout、还是产品的EMC性能提升，都具备实操经验。而团队成员大多是刚从大学毕业的本科生和研究生。因此，为了确保工作成果的品质和日程，每个项目开发的前期，我都是深度介入的。正式由于这个历史背景，在和日方上司一起合作一年多后，他对我说了那句对我有重要启迪的一句话。
本土IC公司，特别是初创公司，技术团队的Manager，尽管头衔是Manager，但工作内容更像是Senior Engineer。那么，作为IC应用工程团队的管理者，应该管理什么，如何管理呢？本文试图从实操的角度剖析、探讨这个问题。

管理者应该从开发流程、参考资源、时间规划、人力分配、成果存放、品质管控的几个方面着力，目标是输出高品质的工作成果。

什么样的开发流程是高效的？
多年的工程开发实践证明，先定义规格、后开发实现是高效的开发流程。首先定义清晰的目标规格，然后根据既定的规格着手软件、硬件的开发，后续开发的过程就是对规格的实现过程。加入瑞萨之初，日方资深技术人员给我们做了大量的训练，学习什么是规格、如何制定规格。在瑞萨电子工作期间，每个开发项目的规格定义，是需要反复论证、完善的，尽可能预想到各种可能的应用条件以及可能发生的异常条件和对策。最终确定的规格一定是具体、明确的。当然，规格也有不同的层次：系统级的规格、模块级的规格、甚至软件函数的规格。因此，制定规格也是花费工时较多的一项工作。但是，正如谚语所说，磨刀不误砍柴工。清晰的目标规格确定后，后续的开发过程就是开发者按图索骥、实现规格所定义功能的实现过程。
反观本土公司，特别是初创公司，更多是采用“先上车后买票”的开发方式。工作实践中经常听到的一句话是“先干着”。其本意是尽快着手开发，但结果往往是欲速而不达。即使定义了规格，也常常是方针性的、粗线条的规格，不够具体，或者说对后续的开发不具备确切的指导、约束作用。其后果是在后续的开发过程中，根据开发实际不断调整规格，软件到处补丁，硬件多次飞线、改板，造成开发成本、人力的浪费和开发成果的质量低劣。
作为技术团队的管理者，其职责之一就是对规格的掌控。深度参与规格的制定，利用自身的技术优势、经验，协同项目成员在着手开发之前，制定出指导项目后续开发实现的技术规格。

开发新项目时，哪些既存的技术资源是值得参考的？
作为团队管理者，在新项目开发之前，需要确定哪些既存的技术资源对新项目是值得参考的。特别是有新人参与的项目，确定参考资源对新人快速融入是非常必要的。如果有既存的资源（之前已经完成的开发成果）可以参考，那么对于制定合理的开发日程、提高后续的开发效率、以及强化不同项目之间类似功能模块的一致性，都是有益的。对于功能类似的新方案、新产品的开发项目，参考既存的、经过验证的开发成果，可以极大地提升开发效率。当然，这就对管理者提出了要求：需要熟知既存项目的成果。因此，保持技术团队管理者的稳定性，就显得非常重要了。如果管理者频繁更迭，那么管理者不可能对既存成果了然于胸。当然，对每个项目的开发成果实行按规则、有序保管，使之容易检索，是从制度方面对技术资源易检索的保障。关于这一点，在后面的成果管理中会进一步说明。

如何使新项目的人力投入和开发日程规划是准确的？
首先，对于新项目，管理者需要正确地评估项目所需的人力/工数。那么，如何尽可能准确地估算新项目的所需工数呢？这是基于对过往项目实际所用工数的统计分析而实现的。因此，在管理实践中，每个项目都需要记录最初的计划工数和项目完成后的实际工数。项目结束后，如果工数偏差较大，分析产生工数偏差的原因（允许存在合理的偏差）。统计、分析这些数据的意义，不仅是反思项目计划不准确的原因，更重要的是为将来的项目计划提供参考数据，使得后续项目的计划工数趋于准确。

开发工数-日程.png

对于每个项目的工作成果，为什么需要规划存放规则？
首要目的是为了每一个项目参与者，能够把自己承担部分的开发成果，保存到指定的位置，以便项目管理者检查、统合项目的整体输出成果。其次，按照统一的规则保存成果，方便检索，有利于本项目的成果转化为其他项目的参考资源，这一点我们在前面已经提及。那么经过几个项目的实际历练，团队成员基本都能熟知存放规则，也就能高效检索既存项目的各类参考资源了。另外，使用既定的规则保存工作成果，还有助于管理者执行多项目的一致性核查，通过对比不同项目中类似功能单元的开发成果，找出最优的解决方案并推广到同类的开发实践中，从而实现团队成果的一致化、提升整个团队的开发品质。

开发成果保存.png

首先，技术团队的管理者，自身需要具备足够的技术储备和很好的学习能力，对初创型公司这一点尤为重要。如果管理者能够整理、优化一个项目的开发成果，使之成为其他人参照的高品质标杆，那么高品质的要求就非常具体了。至少，管理者可以组织团队的资深工程师，一起打磨出一个可以供全员参照的高品质项目成果。
其次，管理者需要对团队成员的开发成果做深度检查。当然，管理者不可能检查所有项目的开发成果，但是工作实践中，至少深度检查每个团队成员的两个项目的开发成果，并详细指出需要改善的地方。通过这种深度检查，使团队成员树立自觉向标杆品质看齐的意识。此外，尽量使用交叉对比的检查方法，同时检查多人的类似项目成果，遴选出最优的解决方案，作为其他人改善的标的。在我过往的检查实践中，交叉检查是非常有效的方法。甚至有的团队成员会感到惊讶，为什么能发现那么细节的问题。究其原因，其实就是交叉检查的功效。
最后，改善全员的开发质量，最终需要团队成员素养的提升。因此，在团队内部定期分享高品质的开发成果给全员参照，请优秀成员分享开发心得，对改善团队整体开发品质也是行之有效的方法。

结束语
IC应用工程团队的管理，对于初创公司而言，需要管理者自身具备丰富的开发实战经验，并能够从具体的开发经验中提炼出可以指导他人开发作业的普适性规则。对于成熟的技术团队，团队管理者更多着眼的是一致性管理。特别是开发团队规模达到数十人时，一致性管理得好，就能输出高品质的工作成果。