新媒易动态
NEWS CENTER
NEWS CENTER
2021-03-21
产品经理编好了需求文档，视需求大小，决定是否需要开需求评审会。通常，当需求是全新业务、开发量较大、对原系统改动较大时，是必须开需求评审会的。
很多产品经理害怕开评审会，觉得自己写的需求被开发测试当着很多人的面指出不足，甚至吐槽，是一件很丢脸的事，面子上过不去。事实上，每个产品经理都会经历这个阶段，而是否有所成长，最关键也是这个阶段。
如果的确是你的方案不足，你的自尊心会促使你快马加鞭的学习，提升自己，会逼迫你在开会之前做好万全的准备。
如果你的方案没问题，面对开发测试老板的质疑，你要学会拆解他们的质疑。如何拆解，前提是你已经考虑过他们会针对这个方案提出什么质疑，以及已经思考过你的方案，与他们的方案对比，有哪些优势。
如果你一开始还没有具备这样的逻辑能力，那就听，摆正心态，耐心的听别人的质疑，但不要马上否定自己，你需要经过深入的思考，来自主判断。
没错，心态。这个部分我并不想过多强调产品经理的能力，方案写的多么好，口才有多么好，我想强调的是，好的心态，有多重要。我认为优秀的产品经理，必须有一项品质，那就是兼容并包。承认别人的优秀，承认自己的不足，但绝不自贬，而是想办法学习优秀的人。
相信我，这个品质会让人上瘾，不再因为别人质疑而觉得抬不起头，不会因为别人的优秀觉得自卑，不害怕别人嘲讽，你会觉得心胸开阔，可以容纳更多的事物。我尝试过一些办法，不去想，或者心里暗示自己要接受要认可，但都收效甚微。
后来，我终于找到了有效的办法，那就是开口夸赞。当你遇到了优秀的人，当你的评审会上有人提出了的确不错的方案，你要敢于开口赞许，“我觉得这个想法很好”，“我觉得他的方案比我的更好，我的方案还有xxxx这些不足的，他很牛”。
一方面，可以在团队中树立你客观、兼容并包、善于赞许他人的好形象；另一方面，你的心胸切切实实可以发生改变。
通常我们会先让开发、测试、设计都各自熟悉一遍需求文档，有个基本的了解，以及产生各自的问题，再开评审会。为保证评审会的效率，产品需要挑重要的部分讲解，而一些细节的逻辑细节问题，则不多赘述。
在评审会过程中，产品经理要学会把控进度，开发人员在评审会中容易陷入思考如何实现的旋涡，导致他们在会上可能会花时间讨论技术问题，产品要及时喊停，让会议回到正轨。
需求评审会最重要的意义，就是将绝大多数的需求上的变数，扼杀在摇篮里。避免开发进行途中，由于方案的错误，需求变更，导致项目延期，甚至方案要推到重来的情况出现。
这个部分，产品经理除了修改文档，更重要的工作是反思，是什么原因，导致了方案的缺陷，归纳总结，分析是哪个步骤出现了问题，是自己的哪种能力不足。
每个公司可能都有自己用来管理员工任务的工具，我比较推荐teambition，分享下我目前用teambition管理项目的方式：
以产品线为单位，一条产品线创建一个项目管理。
一个项目中，可以根据项目的需要，选择功能插件，我比较常用的几个是任务、概览、统计、缺陷、迭代、Wiki、版本管理。
1）任务
即管理成员工作任务的地方，以面板的形式存在，面板可以自定义，一个任务有认领人、参与人、时间等等。
2）概览
清晰记录项目的关键信息，支持字段配置，并且可以后期搜索和统计。适合短期的，有阶段性的项目。
3）统计
提供项目范围内不同成员任务、工时的计划总量和完成情况的可视化统计。可以看到一个项目中，各个成员的工作占比以及各自完成的任务数量。
统计项目中各个状态任务的数量，如已经完成了多少、延期的有多少。有助于产品经理把控项目的风险，以及团队的效率。
4）缺陷
这个功能主要由测试人员使用，用于记录缺陷的生命周期数据，可以对缺陷进行全方位记录与跟踪。
当测试中 / 项目上线后发现bug，由测试人员提起，并指派执行者，同时编辑缺陷的相关信息，开发人员修改后，由测试人员跟踪，及时更新缺陷的状态。
5）迭代
这个功能由产品经理使用，即规划该产品线的迭代计划。属于这个迭代的功能，参与人员创建后任务后，都关联到这个迭代。即可根据任务的完成进度，可见本次迭代的总体进度。