人人都是产品经理|如何让PM完成需求评审而不被打?( 三 )


如果是稍微复杂的问题 , 或者被问住了的问题 , 要及时认怂 , 承认自己事先没有想好 , 先记录下来 , 会后考虑清楚以后再同步给大家 。
在评审过程中 , 作为会议的主讲人 , 不仅要传达完整清晰的传达需求 , 还要控制会议的节奏 , 不要让会议陷入抠细节的状况 , 更不要让会议跑偏 。
发现有的同学喜欢抠细节 , 要及时制止 , 并建议在会后和他详细讨论 。 如果是跑偏 , 要及时将大家的注意力拉回来 。
会议最后要形成会议结论 。
会议结果无非两种 , 成功和失败 。 若会议成功 , 那大家就分配下一步工作 。
若会议不成功 , 有一些需求逻辑待进一步梳理 , 那就约定由谁来梳理 , 什么时候完成并重新组织评审 。
一定要有结论 , 谁干什么 , 什么时候交付 , 交付物是什么 , 都要定义清楚 。
如果只定义了负责人 , 但是没有定义交付时间 , 就会造成拖延 , 大学生综合征就是典型 。
如果没有定义负责人 , 到最后 , 这件事大家都不会去做 , 三个和尚没水喝 。
如果没有定义交付物 , 那他到底做还是没做 , 就没有一个可以衡量的结果 , 容易变成嘴炮 。
三、需求评审后
需求评审后还不是结束 , 需要做两件事:
1. 将会议上记录的问题 , 一个一个落实
需求该修改的地方修改 , 该找人落实细节的找人落实细节 , 并且修改好以后 , 要以邮件的形式及时同步给大家 , 并且在群里进行简要提醒和说明 。
必要的话 , 可以组织小范围的二次需求评审 。
2. 需求评审复盘
记录每次需求评审 , 大家提出来的问题 。 将这些问题进行分类统计 。
哪些是自己经常忽略的问题 , 哪些是自己经常被问到的问题 , 哪些自己明明说了 , 但是大家还是会问的问题等 。
对自己的每次需求评审都做一次复盘 , 总结自己没有讲好的地方 , 讲的好的地方 , 下次该如何改进等 。

人人都是产品经理|如何让PM完成需求评审而不被打?
本文插图

有的同学说 , 需求评审的时候忙着回答问题 , 哪有时间进行记录 。
办法总比困难多 , 你可以每次找一位产品同事帮忙记录(他评审的时候 , 你帮他记录) , 或者买一只录音笔录音 , 这都是好方法 。
最后 , 总结一下:
需求评审前 , 尽量先进行一次预评审 , 并提前发出会议邀请 , 将需求文档等资料提前发给大家熟悉 。
需求评审中 , 会议一开始就要明确本次会议的主题和目的 , 需求讲解 , 要从整体到局部 , 具体的功能讲解从背景开始 。
最后 , 会议一定要形成结论 。 另外 , 谨记:一定不要陷入细节!
需求评审后 , 将会议上的问题一个一个解决 , 将分配给或需要自己配合的任务一项一项推动 。
另外 , 坚持对每一次需求评审进行复盘 , 明白自己的问题和优势 , 有针对性的改进和提高 。
本文由 @Jarvan 原创发布于人人都是产品经理 。 未经许可 , 禁止转载
【人人都是产品经理|如何让PM完成需求评审而不被打?】题图来自Unsplash , 基于CC0协议


推荐阅读