努力、拼搏是为了自己活的更有尊严

【产品需求】-管理执行

发表于

产品需求管理

每个团队的研发周期是不一样的,具体还会根据团队人员配置情况来制定每期的研发计划的。对应上篇文章讲到的需求收集分析,我们需要进行分析需求的真实性、一致性、价值性和可行性。

比如我们可能会在研发中收集到50个需求,但是目前研发团队每期的消耗需求能力基本在25个左右。确保这25个需求经过验证后是用户真实需求,进行优先级排序。(这些需求是包含领导boss、用户、竞品、市场、合作伙伴、团队成员、产品自己分析所收集的。)

为什么要进行筛选需求,一部分原因是因为这块会在后续需求评审的时候,评审人员对需求的价值性上提出意见的时候进行回答用得上。此时建议整理份【本期产品需求表】发给领导BOSS份,保证需求与他们没有大偏差并获得支持。(有时候领导BOSS也会参与需求评审会)

产品需求执行

对应敏捷开发团队最好的研发衔接方式是,当研发人员在完成本期需求最后2天的时候,产品需要把本期的需求结构、流程、原型、需求说明文档整理完毕。避免出现本是研发的时间,产品需求还未整理完毕,这样大大减少了开发时间。比如敏捷研发周期为二周一次那就是14天,除去周末4天,集测时间2天,需求评审会1天,留给研发的时间其实只有7天。

20161030

在限定的研发时间内,如何减轻研发人员的压力?
1.对应确定的页面,可以提前与UI进行沟通,在开需求评审会之前设计完毕。
2.对应需求必要的结构图、流程图、原型图、需求说明必须及时给到,有改动需要及时说明。
3.产品每期的版本上线当天,你最好搬张椅子与测试研发人员一起完成上线前的测试工作。

对应确定要做的需求,如何描述清楚?
1.除了需求评审会上的逐个细节讲解外,这就牵扯到产品经理的基本功了:产品结构图、流程图、原型图设计已经需求说明文档编写能力了。你的用心,考虑周期绝对会让你的队友对你的可靠性暴涨。
2.当需求评审会议结束后,需求文档已经给队友了,如果整的够细,中途研发测试人员与你沟通的次数就会减少,你只需每天跟进当日需求完成情况,进行验收即可。这样自己就有更多的时间研究下期的需求,让下期的需求考虑的更加周全,这是一个产品的节奏。

注意:
此时必须保证需求要提前与核心的研发人员进行沟通需求的可行性,这样可以使得在需求评审会议上被喷需求难度大,无法实现性,如果此时提前与核心研发人员进行沟通,他们会告诉你需求实现难度,也会过滤调整部分需求。开需求评审会前多余研发沟通,你会在需求评审时更加顺畅获得更多的支持。

当我们的产品已经上线后,我们还需要与运营、推广、客服同事提前打好招呼,我们大概会在何时更新版本、更新什么内容。此时必须要他们及时接入,免得与产品团队脱轨了。因此推广运营人员可以提前做好活动、内容资料、客服人员可以提前整理更新FAQ。

 

 

Share Button

文章评论
共收到 0 条评论

无觅评论,优化体验,加强品牌价值