软体工程师如何做好专案技术负责人的角色？

在之前文章中，我们谈了 软体工程师如何做好技术设计？。而在这篇文，我们将进一步来谈，如果今天你被交派负责一个专案，你要如何担当好这个技术负责人的角色？

我们会试着展开一个专案从开头到结尾的各个阶段，并讨论在各个阶段，做为技术负责人的角色，应该要注意什么。

谁能当技术负责人?

在往下讨论如何做好技术负责人的工作之前，想先聊一下「谁能当技术负责人」这点。假如你目前是初阶或中阶工程师，想往技术负责人的角色发展，推荐可以用以下的点来自我检视：

• 技术层面：你是否对于模组 (例如前端的元件、后端的服务) 了若指掌? 有遇到问题时，你是否比其他人更清楚如何用最佳的方式解决?
• 行为层面：你是否有沟通与协调的能力? 特别是在跨组沟通 (跟上下游团队沟通)、跨部门沟通 (跟产品、QA 等其他职位的人沟通) 的能力?
• 思维层面：你是否有自己是负责人的主动思维? 当有任何问题时，是否有「由你来扛」的心态?

了解需求：确保解决对的问题

在一个专案的最开始，最重要的是确定好需求是什么。一个常见的误区是认为「确定需求是产品经理的工作」。基本上想成为资深工程师，特别是专案的技术领导 (tech lead)，确保有解决对的问题这件事，也是在技术领导职责范畴之中。

先前有机会跟一位 L7 职级的资深前辈聊，他提到不要一看到需求就开始想技术。更关键的是先从使用者的角度出发，跟产品端一起把要解决的问题定义好。

事实上，产品经理想不完整，是很常见的状况。想要把专案带起来，称职的技术负责人，不会抱怨产品经理这个没想到、那个没想到，而是会主动跳出来，一起把产品端没想清楚的地方厘清好。唯有在厘清好需求后，才回过头来思考需要什么技术解决方案。

一般来说，在大一点的专案，要思考的需求可能不限于自己负责的团队，会需要进一步去想到上下游的需求、彼此的关联。不能只想对方要为自己做哪些改动，而是要站在合作方的解度去想如何跟他们对接，这样会让后续要推进比较容易一些。

有一个特别重要的点，是在这阶段要追着产品端确定的，那就是预期效益。在目前科技业的现实下，开发出的成果有没有收益，会是特别被看重的。

2023 到 2024 年间，国际上许多优秀的工程师被裁员 (有些甚至在全球开发者社群活跃)，不是因为能力不好，而是可能该组做的成果被公司认为相对效益不高。

很多时候，产品经理可能自己也没搞清楚，对于预期效益讲不出个所以然，这时候身为技术端的负责人，一定要追着产品经理，确保有合理的效益评估，不然后面做的都可能变成白工。

技术分析与比较

在厘清完需求后，接着就可以针对需求来发展解决方案。在发展解决方案时，除了自己想之外，有一些能够协助想的更完整且透彻的方法，以下四个是推荐实际撰写技术设计文件前，可以做的事情：

• 找人请教：比起在汪洋大海的资讯中收敛，直接找已经在该领域有一定耕耘的专家会更有效率。假如是在大公司工作，可能其他团队已经有解决过类似的问题，这时直接约 30 分钟的 1:1 来请教，会快非常多。在请教时，也可以问该专家有没有推荐其他的专家，有的话也约来请教。
• 社群中找启发：除了找人问之外，上网找也是一个方式。举例来说，假如今天你要负责带的项目是一个生成式 AI 客服，目前网路、开源社群已经有很多解决方案，这时可以从别人的设计中找到一些启发。此外，也可以善用自己待的公司的内网，来找相关的技术设计方案 (不过如上面提到，假如有找到相关的团队有做过相关内容，直接约一个请教的会议会更有效率一点)。
• 寻求回馈：在 软体工程师如何做好技术设计？ 一文中，我们有谈到 Figma 工程团队的 Engineering Crit 的环节，这个环节的主要做用，是进到正式的技术评审之前，先向相关人士寻求想法与回馈。Figma 团队会邀请其他团队的专家，提供对于不同方案的观点；在有了初步的方案选择后，团队又邀请专家给予想法上的输入。最后基于这些不同团队与专家的观点，该团队才决策出要往下的方向。
• 第一性原理思考：上面提的两种方式都是参考过往的人的经验，这能加快速度。然而，别忘了在 高效工程师都要懂第一性原理思考 (First Principles Thinking) 一文中，我们谈到跟从过往经验有其危险性；因此比较好的做法，会是除了参考现有的方案的同时，也试着回到本质思考如何设计这个系统会比较好。

把整体架构、分工、时程定下来

在厘清完需求、探索完不同的技术解决方案后，最终需要确定下来要往哪个方向走，这时做为专案的技术负责人，就需要去确定下整体的架构设计，并且在有了整体架构后，要有各个细部的分工，确保每个部分都有负责人。

一般来说各个公司的习惯可能不同，但普遍比较常看到的，是在有了架构、分工后，由各个子部分的负责人，进一步提出细节的设计，然后再进到子部分的技术评审会议。这阶段整体专案的负责人的角色，就会是确保每个子部分没有偏掉，有照着整体架构来进行设计、不同子部分彼此能顺利整合。

虽然在前期确保架构正确很重要，但这阶段也不宜拉太长。先前有听过比较夸张的例子，是某大厂因为技术设计时乔不拢，导致一个专案过了一季还没有进到实作阶段。除非是学术研究机构，不然在一般业界，总是会有来自市场的压力，当一直卡在这阶段，技术领导的能力可能会受到质疑。

特别是不同产品阶段，速度与严谨度的取舍也会不同。一般在早期阶段，以验证市场为主，先把东西做出来验证会比较重要，这能避免花一堆时间设计，结果最后发现市场不买单的窘境；反之，如果是已经有大量的使用者，每个改动的影响都很大，这种阶段就会更偏向技术设计花多一点时间打磨。

回到细部分工来讨论，当各部分的细节设计都完成后，这时务必要把时程定出来。在现实世界中，经常可能遇到要赶上线的状况。用严谨的做事方式，肯定会需要多一点时间，但是从长远的角度来看，有时候前期求快导致后面要收拾，反而会让总体成本增加不少。

关于时程预估的掌握，没有标准答案，专案负责人要有办法判断，现在该用什么样的节奏。一个大原则是在不牺牲品质的状况下，确保能尽早完成，让开发完的成果能尽早转换成收益。

阅读更多

如果你对于「如何做好专案技术负责人」这主题感兴趣，我们在 E+ 有写更深入详细的内容，包含落地执行、监控与追踪收益、持续迭代专案等具体细节。有兴趣的读者，欢迎加入 E+ 成长计划。

本文为 E+ 成长计划的深度内容，截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)