对需求做决策
　　论证了需求的存在，以及必要性，下面是对需求的优先级交付开发，有些需求，因为优先级低，可能永远处于被砍掉的部分，或者一直呆在to do list直至天荒地老。
　　需求优先级：
　　需求永远是做不完的，而研发资源永远是不够的，怎么办？所以PM需要对所有需求的优先级进行分类，研发按照需求优先级列表，一个个进入开发队列。如何划分优先级：MVP（小化可用产品），快速迭代，迅速论证需求及产品的合理性。当每个需求出现在列表中时，不停的问，这个需求有必要么？有必要优先级这么高么？不做用户会不会发狂？不做产品是不是能run？不做是否不通过产品线下也有解决方案，成本和线上比怎么样？经过这一系列论证，某些是必须要做，而且立马要做；有些是必须要做，但是并没有那么紧急；有些甚至是必要，但是却不是当前阶段需要的。少即是多，所有功能的累加并不难；难的是只提供用户核心的功能和产品，并让用不离不开他，再在这样的功能上，轻松调整和扩展产品。
　　那些被砍掉的需求：
　　从参与工作的第一个月，整理了一个feature list，都是大家脑暴，或者研究竞品给产品未来做的规划，现在回头来看，里面所描述的功能，绝大部分都没有去做。一方面的原因是产品还很小，没必要大而全；另一方面部分功能，完全拍脑袋决定，根本没有必要在产品中增加。
　　feature list是产品规划方面的需求，具体执行层面，每次需求评审，会故意放进很多需求；老板可以砍，技术可以砍，QA可以砍；需求多研发肯定会叫，象征性地砍掉不需要的需求，适当的把部分需求延期，只要保证你所要的核心需求，在这次迭代完成好了，毕竟已经砍了一部分需求，不好意思一直砍。具体怎么交付技术需求，跟技术沟通会专门再写一篇。
　　交互视觉和重构
　　让专业的人做专业的事情，虽说PM应该是个70%的交互设计师，但是公司既然有了交互设计师，那交互的工作十分信任地让他们去做；PM做的只是跟交互设计师描述清楚用户使用场景。当然作为新人，我经常犯的错误是，我这里需要加XX功能，而不是我要解决XX问题。视觉重构同理，PM是要利用好这些资源，并充分地信任他们。
　　关注用户体验：产品要么给用户带来利益，要么方便用户使用；脱离了这两点的产品都是耍流氓。若一款产品既给用户带来利益又有非凡的体验，才是成功的。用户体验为啥重要，因为体验会影响用户口碑，口碑影响产品成败，产品成败决定一切。用户体验包含用户所看到的一切元素，以及交互过程，除了显性的特性外，体验上隐性传递给用户的信息，会给造成暗示，如某处金额现实为负时，传递出的隐性情感肯定是偏向负面的。
　　PM要学会讲故事：这里讲故事的意思，是跟UED的童鞋进行沟通，感性的传达肯定比理性的说教要好。某天交互设计师发了这样一条微博：我总是忽略一件事，PM同学提出的究竟是需求，还是ta出于对需求的认知而拟定的一种解决方案。老大回复的是：往往是后者，junior PM因为junior所以会是后者，senior PM因为senior所以还是后者。
　　作为一个刚刚入门，还在摸索阶段的junior PM，反思下平时的工作，面对所有需求时，第一直觉都是想到，如何去解决这个问题；而不是描述用户的使用场景，在这样情况下用户所表现的焦虑和拙计，并将此问题抛给交互，让他以专业的知识来解决。交互设计师不是单纯的画原型图，他们能赋予产品生命和灵感，让用户体验到，所以让他们发挥ownership来解决问题，远比执行要好。
　　需求文档
　　刚刚开始实习时（不是在点评），写过半年左右的需求文档，当时因为瀑布模型开发，一期需求写一个月，评审后交付开发；然后二期需求文档同时进入编写。当时情形不做评价，对个人的锻炼是文档算是入门鸟，正式工作后，文档方面也没有任何专门培训，写过几个之后，老大、技术、QA表示还行，半年时间，项目的大部分需求文档都是我产品，当然需求也是我在跟，少说也有几百页，正当我粘粘自喜的时候，发现......
　　发现啥呢，研发基本不会关注的文档，他们都是按照他们的想法和思路进行开发，只有在进行不下去的时候，才会去关注下细节；或者在出现争议的时候，通过需求文档来check；可能文档的读者只剩下QA了，因为他们要写测试用例；看了我们敬业的QA的case，我回过头看我的需求文档，瞬间汗颜。
　　之前犯的错误是，觉得需求文档一定要按照格式来写，当然了这对新人上手有好处；写多了会发现，其实是没必要的工作。文档只需要清晰传递要完成的功能，以及详细的描述够了，具体啥形式，是无所谓的。
　　以前犯傻，写过的一篇关于如何写需求文档。
　　那些年犯过的错误
　　1、替技术思考问题：因为在学校专业是计算机和软件，所以会不由自主地帮技术思考问题，前两个月在需求评审时，会说这个需求工作量不大；甚至会说这个可以这样实现；这是个不好的习惯，还好慢慢改掉了，主要伤害了他们的ownership。
　　2、忽视用户体验：在App端，擅自做决定，界面看似更简洁，但是实际增加了用户的操作成本，这件事情被狠P了一顿，从此长记性了。
　　3、需求没有详细的论证：拍脑袋想一些需求，或者论证的数据不够全面，只看到表面数据，并没有深挖背后实际需求。
　　4、过分强调文档的作用：刚刚入门的PM，对于所有人都忽视你的PRD，那种惆怅是无法言语的，调整好自己心态好了，一切为了产品。
　　5、木有传递业务价值：不是所有技术都关注业务，但是在传达需求时，需要讲清楚需求的背景、数据、以及原由；如果不做这些，技术沦为彻底的码农，接受需求，然后开发出来，具体的价值体现，以及自我满足，需要从产品这里得到。
　　犯过的错还有很多很多，这里不一一列举
　　此外，再翻一遍身边产品的书，发现大多会讲产品规划，很少讲需求如何具体执行。产品规划确实不是我这个level所需要花精力考虑的，所以这篇主要目的是需求执行、论证，以及交付技术，下一篇准备详细写，如何跟技术沟通并保证产品上线。