【软件工程】如何让研发团队能定期“闲”下来

前两天robbin在他的博客上发表了文章：《建立学习型组织》。里面有这样一段话：

2、当研发团队处于比较空闲的研发周期的时候，安排比较多的学习任务，要求不光自己学习，还要做分享给整个研发部门，并且我会把学习任务也列入KPI考核当中；

观点我是同意的。我曾经也尝试在自己的研发团队中培养这样的学习环境，但最终效果并不足够理想。大概回想一下原因。首先就是"空闲时间"不够多: 平时的时间大多被项目任务占满，加班都忙不过来。有一段时间时间宽松一些，但也没有持续很久（这个想想其实是正常的，如果一家公司某个团队一直能闲到蛋疼就不正常了…）。这样看来，我想正常的情形应该是"经常忙，也经常短期地闲"，这样总的空闲时间也是有一定保障的。

 

对于一个靠做项目来维持营生的公司而言，想做到"经常忙，也经常短期地闲"，首先这就要求拉来的项目多且每个项目能很快完成。研发团队一般不需要负责"拉项目"，所以主要负责"快速完成项目"。这个说法仍不够精确: 在一家公司中负责具体"做项目"的是实施团队这个角色: 实施工程师们用研发团队开发出来的产品和各种实施工具去客户现场部署系统，并且在遇到技术问题的时候能得到研发团队的技术支持。研发团队要想"事儿少"，那么他们提供给实施团队的工具最好简单易用，一键搞定。如果无法简单易用（有的业务领域真得很复杂），那必须不容易犯错。对于容易犯错的地方，帮助文档一定要给予详细清晰的说明。这样当实施人员遇到问题时，他可以先自我解决，而不是立刻求助场外的研发，这样可以很大程度上减少研发的事情。

 

补充一点: 研发团队制作实施工具包这个事情本身，也应该是被充分简化的: 能自动化则自动化之，不能自动化的也要有指导文档能让别人快速手工制作实施工具包。

 

对于一个靠做项目来维持营生的公司而言，对研发团队影响最大的、也是研发团队最直接的责任，就是研发新产品或者开发新的定制项目。而如何在"可预测的进度下生产符合质量要求的产品"，是软件工程学探讨的终极问题。基本上，首先必然是提高任务估算质量。现在来看，建立估算数据库，认真跟踪每个人的每一次估算，一方面可以逐渐减少估算的随意性，让工程师在估算时会严肃对待此问题（即便最初期的拍脑袋也会去严肃地拍一下）。另一方面可以形成历史数据库，便于利用历史数据进行反馈以提高未来估算质量。这个思路的一个结论就是: 每次对某任务的重新估算都应该是严肃的流程（不仅仅是态度的严肃，还包括做法的严肃），包含了延误原因分析和可能的解决方案的探讨（并且应该记录到数据库中成为历史数据的一部分），最后才是重新估算。

 

事实上，任务估算是如此复杂的一项工作，以至于它已经把研发过程中的所有确定和不确定的因素都试图考量进来: 技术难度，技术的未知性，人员成熟度，外界的可能变故，等等。"重新估算"本身已经暗示了工程师一次完整的开发过程（从一开始的雄心勃勃要力争完成任务，到遇到问题的苦思冥想或者总被外界干扰的心烦意乱，到察觉可能无法按时完成任务时的焦虑不堪和加班加点，到最终"妈逼的老子就做不完了你爱咋咋吧"…），所以，很可能当我们*足够*深入地关注"估算"这项工作时，它可以起到穿针引线的作用帮助我们把一个具体的研发团队在一个具体的工作环境下的问题发现并解决。