做项目的不确定性与风险把控

技术管理的⾸要任务是项⽬管理。就是如何带领⼀个团队完成⼀次次的产品迭代，⼀个个的项⽬开发。这⾥涉及的东西很多也很复杂，包括研发、测试、运维、产品、项⽬管理、数据分析……不同类型的项⽬、不同的公司⽂化，在这件事情的做法上都会有差异。

但⽆论这些差异如何，对于项⽬管理，有⼀个关键问题要⾯对：“不确定性”问题。从⼈的认知来讲，做任何事情，思路都是从⼀个“朦胧”到逐步“清晰”的过程，项⽬的进展也是⼀个从思路、到⽅案、到落地的细化过程。

在这个过程中，不可避免地存在各种“灰度”，或者说“不确定性”。⽽项⽬管理就是要提前防范各种“不确定性”，并采取相应措施，让整个团队、项⽬克服重重⼲扰，成功到达终点。

有哪些“不确定性”呢？总结归纳如下：

在做产品或项⽬时，产品经理、⽼板或其他相关⼈员都会有很多“想法”。有些想法很成熟、逻辑严密、很有系统性；⽽有些想法还不成熟，需要进⼀步优化；也有些想法，纯粹是头脑风暴，想想⽽已。

⽽由于各种外部条件，⽐如⼯期的约束、绩效的追逐、领导的压⼒……很可能项⽬在⼀个想法没有完全想清楚的情况下就开始了实施。

这就是⼀个重⼤的“不确定性”。遇到这种情况，作为技术负责⼈，需要和产品经理、相关业务⽅、上级领导等进⾏⼴泛的沟通，最终在这个事情上达成“共识”：到底哪些是东西清晰的，我们可以开始做，哪些还需要进⼀步思考和细化。

在做⼀个新项⽬时，可能会遇到技术选型的问题，团队中的成员尚未掌握某个框架、开源库或对接的第三⽅开放API等。对于这种情况，必须在项⽬早期做尽可能多的调研和测试。对于引⼊的技术框架，哪些特性可以⽀持、哪些不能⽀持；对于技术选型，不同⽅案的优缺点都是什么。

尤其是⼀些关键的技术细节，如果在前期不调研，等到中后期才发现某个框架⽆法⽀持或有问题，可能对整个的技术架构和项⽬进度造成严重影响。

例如⼀个系统耦合度⾼，有⼀个关键模块的开发⼈员突然离职，新成员又对项⽬不熟悉、然后慢慢摸熟、上路，等最后项⽬完⼯时，离预定⼯期已经差了⼀⼤截。

对于这种情况，⼀种应对策略就是：不要把项⽬最核⼼的部分让⼀个⼈开发维护，导致别⼈⽆法插⼿。要分摊风险，在技术的架构设计层⾯，保证整个系统耦合性不能太⾼，根据团队成员的⽔平，每个⼈都可以承担⼀块东西。这样即便某个⼈离职，也有相应的⼈可以补上。

公司越⼤，业务越复杂，部门越多。随便做⼀个项⽬，都可能与好⼏个业务部门打交道。这些部门可能还在异地，平时只能即时通信，或者远程电话沟通。

对于这种情况，在项⽬前期必须要做尽可能多的沟通，调研对⽅提供的业务能⼒，哪些⽬前有，哪些还在开发中，哪些还没有开发。

在充分沟通的基础上，和对⽅敲定排期表，不定期地同步进度，保证对⽅的进度和⾃⼰在⼀个节奏上。

⼀般当⼀个新⼈进⼊⼀家公司，除了创业型公司，很少会⼀上来就能做⼀个新项⽬。⾸先是接⼿前⼈留下的⽼项⽬，在此基础上进⾏迭代升级。

有些⽼项⽬的技术架构很清晰，⽂档清楚，业务清楚，还有对项⽬熟悉的其他同事；也有些遗留项⽬⽋了很多技术债，之前的开发⼈员也⾛了，业务⼈员很多都熟悉。

对于这种情况，需要对项⽬进⾏完整的梳理：从产品到技术，找各个接⼜⼈沟通，可能经过了两三个⽉，才对整个系统有了⼀个全局的把控。

要有“风险把控”的意识，在项⽬早期努⼒地想出各种各样的“不确定性”，未⾬绸缪。