迭代中的研发资源管理

在迭代优化过程中，产品经理要充分调动并利用研发资源，通过对人员的合理调配，保障不同项目之间无缝衔接，避免因为时间窗口不匹配导致研发资源闲置。

有一种很简单实用、也是传统项目管理中常用的方法，就是制作一张研发人力资源安排图。通过这张图，可以清晰地看出每个研发人员的不同需求、项目上的时间规划和时间投入规划，并据此安排后续工作。

维护好这张研发人力资源安排图，也是对研发人员的一种保护，避免他们蒙受工作不饱和的怀疑和指责。

软件的代码需要不断优化。如果软件升级迭代过程中只实现产品功能需求，而不做技术优化，随着功能的积累，软件系统会变得越来越脆弱，运行速度越来越慢，甚至频繁宕机。因此，在日常的迭代升级里，必须给技术优化预留足够的资源。

对于一套甲方自研自用的系统，在业务发展的不同时期，研发资源分配的思路也完全不同。

初创阶段，业务还处于探索试错期，业务本身不一定能成功。在这个阶段，系统从无到有地构建起来，研发团队要开足马力支持业务。本阶段的重点在于活下去。所要构建的系统是一套全新的、干净的系统，没有任何历史包袱，所以团队可以卯足劲开发业务功能，而不用太在意代码架构的合理性。此时可以只预留 10% 的资源做技术优化，甚至不做技术优化。只要研发团队靠得住，一套全新的系统在全力运转的状态下，对业务支撑一年的时间应该是绰绰有余的。

一年后正是验证业务能否存活下去的关键时间点，这就进入了瓶颈阶段。经过一年的探索，证明了方向是正确的，业务取得了初步成果，并继续保持高速发展，业务对新功能的渴望持续强劲。产品研发团队依然要开足马力，但此时系统已显现出疲态，技术债问题开始出现。对于产品研发来说，一半的资源被用来修复 bug，并被迫在眉睫的技术优化占用；另一半资源被难以维护的老代码拖住。产品研发团队既不能痛快地满足业务需求，也不能爽快地一次性解决系统结构问题。此阶段可能会持续 1 年到 1.5 年，可谓整个产品研发团队的噩梦时期，这也被称为瓶颈阶段。

到了重构阶段，业务继续发展并且相对稳定，业务需求依然络绎不绝，但系统已崩溃，已濒临崩溃的边缘。此阶段可能会安排 80% 的资源做技术优化和重构工作。

到了稳定阶段，业务发展稳定，系统运行平稳，bug 少、不宕机，业务需求依然不断提出，但此时研发工作显得井井有条。即便如此，依然需要预留 10%~20% 的研发资源持续做技术优化，这是保证系统持续稳定的秘诀。

虽然商业化产品一开始也不能做得太重，应该首先快速验证市场。但相对于自研系统，商业化产品对产品和技术架构的合理性、规范性要求更高一些。毕竟它是企业的主营售卖产品，而非某个业务的辅助支持工具，所以一开始的设计投入需要更严谨、更充分。