方法论-需求管理checklist
曾经遇到许多case，在产品管理中总是会遗漏某些部分，造成相关利益方不知产品改动而造成系统运行错乱，或者一线客服无法回答顾客来电等情况。
慢慢的，自己在需求管理中整合了自己的一套需求管理的checklist——思路来源于《清单革命》。根据这一清单跟踪需求生命，基本可以保证管理的完整性。当然，这个清单仅适用于一线产品经理（实操型、执行层）的工作范畴。
需求管理checklist.png
1.需求梳理
根据“紧急-重要”四象限辨识需求紧急程度，管理需求；同时根据需求的实际业务价值，对需求进行优先级排定。
- 优先选取重要紧急的事情完成
- 同步进展重要不紧急的事情
- 紧急不重要的事务，一般是琐碎的小事，做好便签/提醒功能，挑零散时间完成
- 不紧急不重要的事务，凭个人心情，但是要记住deadline，再随便不能拖延完成
重要-紧急 四象限.jpg
2.PRD撰写
了解清楚需求背景，想清楚产品方案后，产品经理就可以撰写PRD/需求文档了。
（一份好的需求文档，应该考虑到哪些因素，稍后我专门撰写另一篇文章来说。）
虽说，在实际场景中，开发们能认认真真看产品文档的少之又少（泪奔。。。），但是做人最起码要对得起自己内心啊！！所以产品汪们。。。为了避免今后被开发/测试们说“谁让你PRD里没写”，大家还是好好写PRD吧。。。
这里我要说重要的一点：PRD需要标注业务方、业务背景、业务目标、业务价值等内容——这个作用是帮助开发了解功能实际起到的作用与应用的场景。这样的好处在于：如果遇到资深的，有用户思维的开发，他会基于产品的维度给到你自己的建议，在实际工作场景中曾经帮过我几次忙。
3.资源确认
此处的资源确认包括开发前需要的所有业务/非业务的资源。
- 业务资源：业务资源是指需要业务方留证确认的行为结果。比如：确认资金可到位的邮件、确认方案上线后不更改的答复、业务方高层的授意邮件等。拿到这些信息，并不代表业务方一定会按照他所说的做，你其实还是很有可能要帮业务方擦屁屁的。但是，拿到这个的好处是在于，万一出错追责起来，你是站在道理充分的那一方的。在执行任务的时候，也有充分的信心去推动。否则：一件连业务都不确认的事情，你做起来不会心慌慌么~~
- 非业务资源：非业务资源指的是在技术开发前，需要完成的技术任务，比如UED设计，比如跨开发团队沟通，预留联调/接口沟通时间。这一点在大中型公司特别重要——不同于小团队，大公司需求的开发往往会牵涉多个团队支持，不同的上线时间、不同的迭代周期，对于一个功能的完全实现存有很大的不确定性。所以务必提前去和相关团队的产品经理或者技术领导沟通好，并且邮件留证！邮件留证！邮件留证！便于跟踪，也便于留证。
4.因材施教
这个说的是在实际工作过程中，你的合作方（开发、测试等）会存在能力、经验、性格、工作年限上的差异，所以在分配任务以及实际执行过程中，你需要针对每个人的特点去给予必要的关注和帮助。
比如：对于上线时间较近的需求，建议分配给开发经验丰富，和多个团队有过合作经验的开发；对于倾向于遇到问题优先自己研究解决从而可能对整体进度造成延迟的开发，必须关注其每天日报，并且及时给予询问，帮助开发一起进行对外沟通。
5.功能报备
在开发过程中，我们往往会因为时间点、实现难度等问题变更/延迟实现部分功能点，那么这个时候，产品人员务必做好因上线时间原因造成的功能取舍记录，在功能上线后邮件发出告知大家，避免遗忘与无人跟踪。
6.上线宣导
功能上线后，及时发送上线通知给到客服、业务等相关人员；并做好产品快照留存。这一点对于相关方达成一致是非常有用的，对于顾客体验而言，也是重要的。
7.反馈迭代
跟踪产品数据，总结与回顾产品表现情况，及时分享，及时改进。
通过这样的方式，保证了需求推进与管理的全面性，将从运营、业务到功能、技术的说明全部整合在一份文档中，减少沟通成本，方便各个角色的同事了解其他同事思考问题的角度与方式。
