建议PM注意任务的延时分发



PM工作中有一个重头戏是各项突发或例行任务的分发。PM需要衡量各种突发事件的优先级，然后进行任务调配。把合适的工作，在合适的时间（这一点就是本文所要着重讨论的），分发给合适的员工。这是衡量PM工作能力的一个重要指标。很多PM都是一线研发工程师出身，对研发工程师的工作的甘苦应该是感同身受的。这里提醒各位PM注意几个事实：

1. 员工的工作效率在单线程的模式下是最高的。
2. 如果把额外的工作过早地压给研发工程师，对于某些AQ（逆商）、抗压能力不高的工程师而言，可能会因为手头有太多堆积着的工作未完成，给他们带来很多工作压力。
3. 如果一件事，已经分发给某个人，而某个人因为某些原因，迟迟不能处理，会造成工作的滞后。毕竟我们的工作反馈在周报中才有体验，对于一些羞涩的工程师，他们可能不会主动反馈自己所面临的困难，导致工期滞后。
4. 手头的工作太多的时候，一线研发工程师有时会陷入布列丹驴子的困境，每天都会浪费一些时间在任务的选择上。对于一些消极怠工的员工，他们也有了借口，借口别的项目干扰，导致某项工作延期。

所以，综上所述，我觉得任务在PM这里应该有一个缓冲的过程。各级领导，乃至PM应该建立一级一级的任务缓冲池。直到最终的执行人确认某项工作已经完成，或者即将收尾，这时才把新的工作分发下去，建议保持每个一线研发工程师同一时刻最多只有2个任务。

 

我相信这样做之后，企业的整体研发效率会有一定程度的提升；特别的，也会减轻一线工程师的工作压力；同时，PM的日常工作也不再只是一个传声筒，而是需要相当技术和管理难度和分寸感把握的任务调配过程。

 

此外，目前已经有相当数量的自动化工具支持团队的任务分发，比如国产的“青铜器”和国外的“mantisbt"，"readmine"等。不过即使使用这些任务分发器进行团队的任务分发管理工作。信息隐藏原则仍然需要发挥效力。各级领导和项目经理，需要限制基层程序员的任务可见范围，在他们完成了手头的工作后，才把额外的任务暴露出来，这样可以避免他们因为觉得任务全部完成遥遥无期而产生倦怠感。

 

这类团队使用的自动化任务分配器还有至少两个好处：1.变任务的分派为任务的拉取，对于某些任务，底层研发人员可以自己选择并完成他们，这种管理手法上的“反转”一般会大大降低传统的行政分派模式所带来的抵触心理。2.项目、团队、乃至基层程序员的工时和工作效率数据可以自然地生成。