如何处理公司内部开发资源不够的问题？
0
首先，我们要有一个基本的认知：资源永远是不够的，时间也是紧迫的！
我们常常面对的是一个在时间有限、人力有限的条件下，如何完成产品目标或客户需求的复杂性问题。所以，我们能做的其实是就是在有限的资源和时间下尽量完成高产出的事情，不要企图完成所有的事情。而处理这样的问题其实有很多不同的方向和方法，此处仅以产品需求的角度，给出一些抛砖引玉的参考做法。具体的处理步骤如下：
- 确定优先级，控制最小MVP闭环（小步快跑）；
- 控制成本投入，强调交付感，管控风险项；
- 重视复盘；
1
确定优先级，控制最小MVP闭环
无论是产品需求还是客户需求，永远是做不完的，所以我们面对开发资源不够的时候总归需要做取舍。通常的做法是先判断事情的优先级，然后根据事情的优先级进行安排，把优先级高事情先完成了。但我们如何确定一个需求的优先级呢？下面将简单列举一些常见的做法，详细的方法可以参考上一节的「我如何判断需求的优先级？」
四象限法：
四象限法通常会通过需求的重要程度和紧急程度，来判断一个需求优先级的高低。但用法不仅限于这两种，只要能够提出两个判断需求的维度，即可采用该方法，如实现的难易程度和见效的快慢，抑或是需求的使用频率和用户量，均可作为一组维度进行评估。
以FinClip举例，在最初做平台功能的时候，我们设想了很多功能，如小程序上架、数据统计、投诉反馈等，但由于研发资源有限，因此我们需按照四象限法则确定优先级，然后再排期进行研发。
如下，按照重要紧急>重要不紧急>不重要紧急>不重要不紧急进行排序得出的结果为
- 重要紧急：小程序上架、应用管理、账号体系—马上做
- 重要不紧急：数据统计—尽量多做
- 不重要紧急：通知中心—少做
- 不重要不紧急：投诉反馈—尽量不做
评分法：
评分法比较直观，其实就是针对每个需求，按照以下问题进行评分，按照得分高低进行优先级排序。
- 它对完成该阶段有多重要？
- 多少用户会使用它？
- 它使用的频率高吗？
- 它给用户带来的价值高么？
- 它存在风险吗？
评分规则：每项评1~10分，然后用前四项分数之和减去第五项的分数，总分越高优先级越高。
建议是根据评分法得出的优先级可以和四象限法的优先级进行对比，通过两者的结合变可以得出一个较为完备的需求优先级排序，然后从高优先级中筛选出最终的功能合集（即MVP闭环），即可安排到迭代中进行研发了。
2
控制成本投入，强调交付感，管控风险项
确定好MVP闭环的功能后，就可以开始进行研发实施了，但由于资源有限，所以在过程中需要对成本和细节进行把控，强调交付，避免出现高投入低回报的现象。
根据需求提前做好成本的预估，做好相关准备：
a. 评估完成需求需要参与的人员；
b. 评估完成所需的时间；
c. 评估完成所需要的其他资源（如机器、设计稿、文案等等）；
明确需求目标，强调交付感
a. 要与所有成员明确本次的目标和时间节点，目标不一致很容易导致效率低下；
b. 确定实施过程的关键节点，并把每个阶段的交付物明确好，周期越长的需求越要拆解和细化每个交付的节点，这样才方便管理，仅仅关注最终的结果往往是无法完成目标的；如需求阶段要交付需求文档，测试阶段要提供用例，上线阶段提交代码版本或APP包等；
管控风险项
a. 若发现约定交付节点上出现延期，则需要尽快召开会议，了解延期的程度并确定解决办法；
i. 若只是稍有延期，则尽量安排加班处理解决，减少延期的影响；
ii. 若是延期较长时间，则应明确延期的后果是否能接受，若能接受，则重新安排时间计划；若不能接受，则应尽快向相关负责人反馈，请求增加资源进行处理；
b. 若中途发现需求无法达到预期或出现技术障碍，需要调整，则此时应该立即停止所有相关的研发工作，并紧急召开会议，与相关人员重新讨论新的实施方案。
3
重视复盘
当一个需求或事项完成后，应该要对本次实施的过程进行总结和复盘，以更好地指导后续工作：
- 首先需要复盘本次需求的完成度和成本消耗，明确产出比；
然后，再根据产出的情况对过程中的问题进行复盘：
a. 若是时间不够导致延期问题，则后续应该加强时间预估或增加资源；
b. 若是因为需求不明确导致的延期问题，则应该加强需求的review和评审；
c. 若是因为技术方案导致的延期问题，则后续应该增加技术评审环节；
本节标签
【审阅】：王字
【作者】：孔令康
【公开范围】：公司内和公司外