需求评审

我们多少都是站在自己的立场上进行设计，可能由于知识面、能力、牛角尖、盲区等原因，这些设计存在这样或那样的问题，甚至于这些问题无法让团队的其他人认同，为此我们要进行需求评审，充分发挥公司里每个人的能力，来评审产品需求。然后改正问题。 各个身份的人，站在自己的立场和公司的立场上评论需求功能，进行可行性的讨论，尽各自所能挑问题，最终形成统一的意见。对，就是撕逼大会，而且要撕的淋漓尽致，还要撕到别人找不到撕下去的理由，真正的勇士的就是要敢于直面被撕的人生，并爱上这种酸爽。 为什么进行需求评审？ 1. 以各自的立场，去看待这件事，尽量找出所有问题，来解决它，否则留着问题到用户手里，你的产品会失去信用。 2. 达成统一意见。这点非常重要。我们无法保证每一个人的意见都能被采纳，也无法保证所有的看法都能最终保持一致，实际上经常会遇到谁也无法说服谁的情况。如果保留分歧去执行，结果可想而知。 需要怎么做？ 1. 形成统一的意见很重要！ 2. 跟产品有关的所有人员都要参与。 3. 最怕撕太淋漓尽致，更怕别人都不撕。 4. 撕逼的时候，你抛出你的观点，若你有上一步测试验证的数据作为论据，只要你测试手段合理，试问还有谁能撕的动你？还有谁？ 5. 在需求评审大会之前，你一定要进行很多小范围内的需求评审和商议，每个环节的同事都要涉及到。和上司、和技术团队、设计、运营、销售等等进行很多接触。那些大的分歧一定要提前就解决，否则开大会时会浪费很多时间。也就是说开大会之前要让大多数人觉得这个功能有必要，并就功能的规则进行通气；至于具体的按钮啊、布局、流程可放在大会上进行探讨。 6. 每个身份的人都要对产品经理评论，毕竟具体实施时，每个人都需要解决各自需要解决的问题。讲真，有些人真的不喜欢说话，不喜欢发言，尤其是人多的时候，技术人员尤其明显。这里也体现提前小会的重要性。 7. 统一意见。统一意见。统一意见。当一些争论好像并不会影响特别重大的情况下，上司要进行最终的拍板（还是之前的小会，要达成尽量的一致）。有意见可以暂时保留，评审会上最终确定的内容要坚决执行，除非你在操作中真的发现影响过于巨大。 8. 有时候需求评审会可能不止一次，有些问题还需再讨论，有些问题返工后需要再次评审。