永远缺人的产品开发阶段

作者：简水
原创发表于微信公众号：产品经理简水

产品设计完成后，PRD文档、交互设计稿和产品原型已经准备好了，接下来就要到开发环节了。

但是，想要让开发接受产品需求没有那么容易，因为开发和测试人手不够，没有时间。没有时间！没有时间！

大的互联网公司的开发和测试好几万人，为啥还一直喊着缺人？

其实真的是人手不够。

公司看起来人多，但是分摊到各个业务线，再到具体的业务组，就没剩下几个人了。

业界公认的产品经理和开发人员的比例是1：5。

你可以看看自己对口的开发人员有几个？产品经理再考虑一下自己身上背的KPI，就知道人员永远都是短缺的。

各个团队负责人的一个重要工作就是求简历，招人！

图片来自Unsplash

1 产品需求管理

产品是要做滴，开发团队的接收能力也是有限滴。

这个时候，我们就需要引入产品需求管理的流程。

产品需求管理，说穿了，就是推迟甚至砍掉一部分产品需求，而且是合理合法通过规范化的手段进行操作。

尽管这些产品需求已经通过了可行性评估和立项阶段，当时大家讨论认为是要做的产品，但还是有可能被砍掉。

1.1 产品需求会，一般是1-2周时间开一次。时间太短的话，开发人员手上的活还没有结束；时间太长，产品需求积压太严重。需求会上，主要确定哪些产品需求要做？哪些产品需求需要推迟？哪些产品需求要砍掉？这个一般也叫PK会，产品经理需要陈述产品定位，说明产品价值，为自己的产品代言。只有在PK中胜出，开发才能接受产品需求。

1.2 产品需求管理流程。这个主要是跟踪产品需求的进度，明确需求的状态，以及在状态变更时发邮件同步给相关的干系人。一般是一个公司内部的线上管理工具。如果没有专门的工具，使用excel表格维护，群发邮件也可以应付。

1.3 产品需求变更。是指项目开发或测试过程中，发生的需求变更的情况。这种情况有主观原因，也有客观原因引起。如：产品方案的逻辑或功能有问题；遇到技术难题无法解决；或竞争对手推出了新功能。需求变更是项目延期的一个很大风险，应尽量避免主观原因的需求变更，天马行空款的产品经理要记得控制自己要创造的欲望。

2 项目管理

2.1 PM vs PD，项目 vs 产品。PM是项目经理，PD是产品经理，两者关心的内容不同。PM只对项目负责，监督项目资源和项目目标的完成情况。PD关心产品开发是否按照设计不折不扣的执行，以及遇到问题怎么对产品进行微调。项目和产品是多对多的关系，一个项目可能包含多个产品，一个完整的产品也可以分多个项目完成。

2.2 项目kickoff。经过产品需求会，开发同意接收这个产品需求后，还需要进行产品需求评审、技术方案的评审以及测试用例评审。产品需求评审，由产品经理召集，主要向开发、测试人员把需求讲清楚。技术方案评审会，由项目开发负责人召集，介绍技术方案，评估所需资源，并给出具体的时间计划。技术方案通过评审后，项目正式kickoff。产品经理此时就会把主要精力投入到产品下一个迭代的设计中了。

2.3 项目跟踪和管理。很多产品经理同时兼任了项目经理的责任，而且是同时管理多个项目。因此需要查看项目进度是否正常，是否遇到了问题？技术人员每天会同步项目进度信息，但建议产品经理还是要多主动询问，便于及时发现问题。项目管理的工具，建议采用线上工具，这样大家都可是看到实时统一的信息。

图片来自Unsplash

3 敏捷开发

互联网产品的需求一开始并不明朗，需要经常的依据用户使用情况进行调整，敏捷开发可以加快开发进度，及时满足用户需求。

敏捷开发的不足：

1. 产品不稳定。产品更新升级频率太高，代码只要调整都会有风险，对产品的稳定性有一定影响。另外，开发和测试人员的工作压力大，流程简化后，容易出现问题。

2. 产品后期升级维护存在问题。敏捷开发的文档不完善，导致文档与产品实际情况不符的情况时有发生。在团队人员频繁流动的今天，这给产品升级和后续开发带来了很大麻烦，经常出现换一拨开发人员就要重构一次产品代码的情况。

敏捷开发的一些原则：

1. 团队要坐在一起，面对面的沟通效率永远都是最高的。如有必要，就找个会议室封闭开发。

2. 晨会。每天早上团队所有成员开站会，沟通项目进度、完成情况、遇到的问题以及今天的工作计划。晨会的内容需要记录下来，发布到在线项目管理工具中，方便团队成员和干系人随时查阅。

3. 有问题随时讨论。对讨论的问题一定要有结论、负责人和解决期限。

4. 下班前再开一次站会，同步今天的进展情况。没有完成的同事，还有时间加班赶一下。

5. 产品开发的同时，产品经理和设计师要开始后续版本的设计工作，一般需要领先1-2个版本。

6. 对于产品的线上问题，最好采用值班形式轮流负责。否则在后期会占用核心开发人员的大量时间，影响产品进度。

7. 在产品稳定期，产品需求不多的时候，开发人员要抓紧时间进行系统改造，打好技术基础以迎接下一轮的用户需求爆发。

图片来自Unsplash

4 测试

产品测试主要是对功能和可用性的测试，目的是为了检验最后做出来的产品是否满足之前产品设计的要求，另外就是检验产品是否有明显的缺陷和错误。

测试环节主要包含测试用例的设计和评审，bug管理和用户测试部分相关的内容。

测试是保证产品质量、维护产品良好口碑的最后一个环节，产品经理一定要对这个环节足够重视。

4.1 测试用例：可以用思维导图+文档的方式，思维导图保证覆盖面，文档记录测试案例。测试用例设计完成后，需要组织评审会议。产品经理一定要参加测试用例评审会，认真核对用例和具体的测试方案。

4.2 bug管理：使用在线工具进行管理，测试人员在这里提交bug，并同步给开发人员、产品经理、设计师等团队人员。有些bug需要产品经理确认是否为设计缺陷？

4.3 用户测试：有内测、公测、beta版本、A/B test等多种形式。

5 一句话总结

5.1 产品需求管理

• 产品需求会：PK胜出的需求才能活下来。
• 需求管理流程：不做这个需求，真的不是我的责任。
• 产品需求变更：能不变，最好别变。

5.2 项目管理

• PM vs PD：PD也要干PM的活。
• 项目kickoff：需求终于有人接了。
• 项目管理：你不盯着，资源就会被调走了。

5.3 敏捷开发

• 敏捷开发：催的急，不敏捷不行呀。

5.4 测试

• 测试用例：一定要面面俱到。
• bug管理：有bug？程序员说：不可能！
• 用户测试：一定要找小白用户测试。

全文完