Tech Lead 作为软件开发团队的技术负责人，对内对外都起到至关重要的作用。Tech Lead 对外是团队技术能力的展现窗口，需要将团队的技术能力呈现给客户或业务团队。对内他需要和各个角色紧密协作，给非技术角色技术角度的建议及支撑。

软件开发团队底层支撑是技术，团队一半以上成员是开发。由于 PM、BA、QA 对技术了解不多，而大多数开发沟通能力一般，对全局认知也有限。开发成员和非开发成员间会形成天然的沟通壁垒。此种情况之下，Tech Lead 是串联起各个角色的不二人选。Tech Lead 技术和沟通能力自然没得说，此外 Tech Lead 对技术的全局观、从客户得到的第一手信息，都支持他能够代表开发团队做出更合理的建议和决策。

软件开发团队中的角色

不同项目模式，虽然软件团队构成略有区别，但大体构成是类似的。软件开发团队一般有如下角色：

1、项目经理

2、产品经理

3、用户体验设计师

4、测试工程师

5、开发工程师

其中产品经理、用户体验设计师都和需求相关，类似的角色还有业务分析师、UI设计师等等。

除了开发工程师，这些角色中和Tech Lead 合作最为紧密的是项目经理，其次是产品经理，然后是测试工程师。下面我们来重点看看 Tech Lead 和以上三种角色的协作。

和项目经理的协作

Intel 的 CEO 基辛格曾说过，每家科技公司都应该有一位技术 CEO。同样软件团队的项目经理如果懂技术，对团队帮助会非常大。懂技术的项目经理可遇而不可求，大多数项目经理非技术出身。不过没有关系，项目经理通过和 Tech Lead 紧密协作，便可以让团队拥有一位技术出身的 “项目经理”。

Tech Lead 和项目经理的协作非常多。我们一个一个来看。

组建团队

项目组成立时，最先被确定的肯定是项目经理和 Tech Lead，他们肩负着搭建团队的责任。团队需要什么技能的成员、如何搭配，需要Tech Lead 有自己的想法，能够给项目经理专业的建议。尤其是开发团队的组成，Tech Lead 更有发言权，有时候需要 Tech Lead 更加强势，争取到关键成员。

制定开发计划

制定开发计划毫无疑问是项目经理的职责。但是合理的计划一定需要 Tech Lead 参与制定。

Tech Lead 需要从开发角度将需求做粗粒度的拆分。然后对每个需求给出粗略的估算，理清需求间的依赖关系。这些工作PM无法独立完成，但却是制定开发计划的必要输入。

风险把控

Tech Lead 应该是项目中对技术风险最敏感的角色。碰到了什么技术难题、技术方案哪里不够完善、外部的变化影响有多大，Tech Lead 一定是最先接触并识别到风险。

很多时候，在项目经理还觉得一片向好的时候，Tech Lead 已经嗅到了风险。此时需要 Tech Lead 尽快将风险传递给项目经理。项目经理才能在第一时间尽快做出安排。

我们不要惧怕风险，更不要试图掩盖风险。将风险尽早暴露出来，制定应对策略，是识别到风险时唯一正确的选择。

进度跟进

Tech Lead 也需要关心项目的进度。你可能会觉得这是PM应该关心的事情。我们换个角度讲，Tech Lead 需要关心开发团队的效能。让开发团队高效工作是 Tech Lead 最为重要的职责之一。

当团队的进度不理想时，项目经理的手段可能只有右手加班、左手加人。简单粗暴，效果还不一定好。Tech Lead 可以从更深层次入手，分析是团队成员能力不足，还是搭配不当，或者有阻断开发的难题需要解决。技术相关的问题，Tech Lead 此时会采取更有效的办法，提升开发团队的研发效率。例如组织学习、调整任务的优先级、集中攻克难题等等。

项目经理协作小结

Tech Lead 作为开发团队的技术管理者，必然需要和项目经理紧密配合。Tech Lead 这个角色本身也携带非常多的项目经理属性，千万不要技术之外的问题不闻不问。不夸张地说， Tech Lead 就是半个项目经理。Tech Lead 来补全项目经理缺失的技术版图。项目管理的各个角度，只要需要技术判断的地方，都应该由 Tech Lead 和项目经理协作完成。

和产品经理的协作

产品经理提出的所有需求，最终都需要开发团队来实现。Tech Lead 代表了整个开发团队，自然少不了和产品经理的协作。

需求的合理性

开发一定抱怨过自己开发的是个什么烂需求，这东西做出来怎么可能有人用。产品经理固然专业，但是也有自己认知的局限。产品经理提出的需求或者设计并非一定合理。Tech Lead 会比其他开发人员更早接触到产品经理的需求设计，需要在早期识别出不合理的需求。此时回头的成本最低，也避免了后面产品经理和开发的摩擦。另外由于 Tech Lead 也会参与需求的前期讨论，所以和产品经理的信息更对等，更容易沟通、达成一致。

需求拆分粒度

在敏捷开发的实践中，需求会被产品经理转化为一张张 Story 卡。控制每张 Story 卡的合理大小是非常优秀的实践。如果 Story 卡过大，会造成很多开发一起合作开发。这种情况下，自己的工作完成后还需等待所有人完成工作，此时才开发完整个需求。这导致很多敏捷实践都无法推行。

产品经理对每张卡的大小虽然有自己的判断，但是由于对技术不够了解，往往会不够准确。如果等到迭代计划会议估点时才发现 Story 过大已经太晚了，无法回头。

Tech Lead 需要在产品经理刚开始写卡的时候就关注 Story 的拆分力度，如果发现 Story 有过大的情况，需要立即反馈给产品经理，并阐明理由和原因。在这个沟通的过程中，产品经理也慢慢会培养出从技术角度判断 Story 大小的感觉，从而拆解出对开发更为友好的 Story。

给产品经理技术加持

产品经理在做产品设计的时候，需要考虑技术上实现的复杂度，一般会选取性价比更高的设计方案。Tech Lead 需要给出专业的建议。这些建议会在很大程度上影响产品设计。工作中我经常会听到产品经理这么说：

此外，Tech Lead 可以结合技术给产品经理更好的设计建议。甚至可以 “卖弄” 一下最新的技术，拓宽产品经理的设计思路，没准和业务结合起来，能产生更大的价值。这个场景也经常发生，比如我们也会听到产品经理这样说：

“这个新技术太厉害了，和业务有很多可以结合的地方！在产品上设计上能做很多事情。我要仔细想一想。”

业务知识和技术知识的流动

产品离不开技术知识，技术也离不开业务知识。技术知识掌握在开发团队中，业务知识掌握在产品经理手中。Tech Lead 可以通过和产品经理的紧密协作，让不同知识在不同角色间流动。

Tech Lead 可以向产品经理输入技术知识，培养产品经理的技术感觉。另外，我一直深信只有深入了解业务的开发才是优秀的开发。作为开发团队对外的桥梁，Tech Lead 需要创造更多机会，引入产品经理为开发团队赋能，培养开发团队的业务知识能力。

和QA的协作

优化开发效率

软件开发并不是开发完成就做完了。还需要经过QA的测试，整个需求才真正完成开发。在敏捷团队中，QA 和开发的工作结合非常紧密。因此，Tech Lead 对团队效率的优化一定要考虑 QA 的工作，否则很可能只优化了局部。例如可以通过测试左移，让质量问题更早暴露在开发阶段，提升质量的同时，让QA有精力做更高价值的工作。

质量数据

Tech Lead 需要关注QA提供的各种质量数据，如Bug 率、Bug 分析等。这些数据能够帮助Tech Lead找到团队当前的问题。可能是团队的能力有短板，也可能业务不熟悉，还有可能是团队有阶段性的松懈。这些问题都往往隐藏在数据后面。根据数据我们找到蛛丝马迹，然后深入分析予以解决。

给予QA支持

QA在测试过程中会遇到各种各样的技术问题或者环境问题。Tech Lead 需要找到合适的开发人员协助解决问题，尽量保证 QA 能在一个稳定的环境中进行测试，这是QA保持高效的前提。在支持QA的过程中，应该为QA赋予基础的技术能力，让其有能力自己定位和解决基础的技术问题。

总结

如果把软件开发团队比作一台机器，技术除了是核心动力外，还是这台机器的润滑剂。也许部分零件没有润滑剂也能运转，但一定磕磕绊绊，问题频发。想让机器运转顺畅，那么就要让润滑剂出现在该出现的地方。而 Tech Lead 就是为机器注入顺滑剂的人。