五、需求评审怎么过？
需求到了文档这一阶段，就不再是存在于产品脑海中的事物了，需要通过沟通把需求传递给相关人员，这就是需求评审会。
需求评审涉及的人员极多，老板，产品，交互，视觉，开发，测试，运营，每个人所站的角度都不同，对需求的理解水平也相差极大。
所以需求评审会，是产品推进的一道坎，这一条坎过的好坏，直接影响后续工作的推进。
那需求评审应该怎么进行？功夫都在会外。
1、提前发出
把需求文档，原型提前一定时间发出，确定参会人员有时间查看，思考。要考虑项目的时间进度，发出的时间不能太早或太晚。太早，有的人看的早，忘得也早，有的人觉得时间还早，晚点看，就忘了。太晚，大家不一定抽的出足够的时间来看，来思考。
2、提前沟通
会前需要找关键人员进行一对一的沟通，
一个是确保大家都看了文档，这样不会一头雾水的进入会议室，这样就会导致会议的效率大大降低，相信我，这样的会议会出各种幺蛾子。
二是提前沟通，可以让大家有什么疑问可以提前提出，如果你已经有思考过，可以提前解释，节省会议的时间；如果没有想到（这是很有可能的，毕竟一人计短）那就可以提前做好准备，思考完善。
再者开会时，你是一对多，而且是不同职位的同事，在会议上进行有效说服的成本会很大。一个人提出一个质疑，经常会引起其他人的共鸣，这样你就要努力说服多个人，这是很痛苦的一件事。
因为一个理由可能只能说服一个人，每个人的思考角度不同，出发点不同，搅在一起，是很难理清的。当然，口才好的，觉得自己能舌战群雄的同学可以无视这个。
我不希望产品的通过口才来说服同事。很多时候，一个一般的需求也能在产品的妙语如珠下通过。这个真的不是好事，因为产品不能靠口才来打动不能见面的用户。
在阐明了强有力的理由后，通过事实来说服同事，这个才是需求评审的意义。窃以为，这点也是为什么很多优秀的产品经理都是内向的，因为内向的产品经理，只能通过更加完善的需求来打动同事。
3、确定会议时间，参会人员
开会前的准备工作还有就是，协调参会人员，参会时间，参会地址，确认大家都知道这些信息。可以在会议开始前再通知一次，不然到了点再催就是组织上出了问题。
同时，开会前也要确定下，相关的会议室，设备和材料准备完全。这些事都是细节，但还是挺有用的。
5、会议过程
讲解的流程我一般按照需求文档的内容，可以参见上文《需求文档该怎么写》。如果前面的工作做到位，会议更多的是统一思想同步进度。但需要注意以下的几个易犯的问题：
1）离题万里
需求会议一看，大家经常会由一个点，无限的延伸开去。这点其实是好事，说明大家对产品的参与感强，是把产品当做自己的事。但时机不对，导致需求会议是要确定需求，优先级。新的需求不是在这里产生的，不经过仔细的思考，研究，拍脑袋的需求大都会误导大家的思路。
产品经理作为会议组织人，要发现这个的苗头，做个扫兴的人，在大家谈性正高的时候，把会议拉回正题。但需要一定的技巧，比如，”大家的建议都很有价值，我这边都记录下来了，以后可以专门做些调研，研究。接着我们再确定下个需求吧。“
2）纠结细节
对于交互，界面，大家都有自己的使用习惯，理解，反映出来就是大家都能对这些提一些主观的看法。很多时候，这个也代表一部分用户的意见，很有参考意义。但也只能作为一个参考意见，产品如果在这里过于纠结就会因小失大。
这时候，还是得让产品说出自己这么做的理由，并总结他人的理由，做出最后的决定。
3）难以确定
在一些需求上，大家最后都有自己的看法，无法统一，这时候再怎么纠结也不能做出最后决定。产品可以站出来，搁置需求，会后产品综合意见，沟通后再做确定。一定要确保会议的顺利进行，不能浪费大家的时间。
4）维护自己权威
在看需求会议的时候，在讲的一个个需求都是产品经理经过不断思考，挖掘的需求，可以说每行文字都有产品经理的心血所在。当产品听到别人的质疑时，总是想说服别人，维护自己的观点和权威。产品有一定的权威有利于产品项目的推进，但不是靠固执，执拗，反对听取他人的意见来维护。
在需求会议上，产品一定要记得带上耳朵和开发的心态，让大家一起参与到需求确定上来。大家的每一个看法都是促进产品完善，用户体验上升的机会。
5）问题反复
当一个需求确认后，已经推进到下个需求，然后又说着说着又回到了上个需求。这时候，要及时制止，把会议拉回到进度上。还有意见，会后再议。
6、会议结束
会议结束后，要及时整理会议的记录，并把大家的意见收集到需求文档中，附上最后的处理方式，相关修改。
有些悬而未决的问题也要及时找对应的人员确定。
确定的需求也要及时的推进到交互，视觉和开发人员，确定估时，排期。
六、需求变更怎么办
需求变更这种事，大家都不想的啦，无辜脸~千辛万苦的把需求推进下来，这里面产品花的心血也不少。但作为掌控需求的人，需求变更的锅只能产品经理背。
1、需求变更的原因
1）产品战略，市场环境，外部条件变化。这种客观条件的变化，大部分时候不以产品经理的意志为转移，只能适应，只是要注意传达好原因，不要因此影响了团队士气。
2）老板又开始拍脑袋。人家是发工资的，很多时候，你费尽九牛二虎之力也说服不了老板要改主意。既然反抗不了，那就闭上眼睛享受吧。
如果无法说服老板，或者被老板说服，你就要尽可能的执行，完善。即使老板的想法你觉得非常不对，但讲清楚你的意见后，你还是得顺从。在公司，不要把产品经理这头衔太当真，恶了老板那就去坐冷板凳吧。
（这个想法我也不知道是不是正确的，只是自己在一个创业公司得到的一些教训。大家姑且一听吧，我觉得这个应该也是因人而异，因公司而异，大家姑且一看，付诸一笑。）
3）产品前期工作没做扎实，尤其是需求分析这一步。这一点虽然坑，但对于新手产品其实是必然要踩的一个坑。对于有经验的，也只能说尽量避免。产品与技术的矛盾很多时候就来源于此。
4）产品设计出问题。这个也挺常见，一些逻辑流程，交互设计，边际状况没考虑好，或者觉得有更优的方式。到了上线前的测试阶段也会出现一些。这种变更就要评估改动的成本和带来的效益了。
5）在需求确认会，开发觉得能做，随后也估了时。然后某天，开发溜过来，
“嘿，我觉得这个需求这样不好，用户肯定不会这么用户我们的产品，这样做对用户体验不好”
“说人话”
“原先的方案有问题，这个需求实现起来会非常麻烦，需要改需求”
一番探讨后，撸起膀子改需求呗。
二、需求变更的应对
1）重新分析需求
当变更的时候，不要着急改变，重新思考原有需求的思路，对比新旧需求的变化，变化原因。要对自己原有的思路有信心。对新需求一定要慎重，再慎重！如果新需求提出后再对其变更，非常损害团体的士气，对后续的工作展开会非常麻烦。
2）更新需求文档
按照需求流程及时更新相关内容，并在文档注明索引，方便大家查找和后续追溯。并且根据需求变更大小，通知相应人员同步信息。这里的人员不要仅限于开发，还有测试，运营，视觉等。要做到信息的及时同步！相信我，这里有坑，泪目。
3）项目进度更新
需求变更大都会带来项目进度的问题，在需求变更后，需要及时对其产生的进度影响做评估。
4）需求变更的复盘
这一步其实是产品自身的提高所必须的，前车之鉴后事之师。
讲真，需求变更其实是产品与开发最容易产生问题的地方，盗的一张图，大家可以引以为鉴。
1C6C.tm.jpg
2、需求跟踪
随着项目进行及时更新项目状态，从新建-进行中（记录目标版本）-已解决（上线），特殊情况如关闭，重开，延期。并在上线后做好需求对应的功能上线后情况，做好数据和用户反馈跟踪。
产品到一定程度后，需求库，及每个版本的需求量都是极大的，一般都是采用一些管理系统来管理，如redmine，禅道等。这之间的差别倒也不大，只要成员之间用的来就行。
不过需要注意，这个只是工具，充分有效的沟通才是最有用的，这里更多的是一个记录提醒作用。
网友评论