今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

今天送走了梦想。。。WE还是输了。。。

水了一天，只研究了一下如何参加需求评审之类的

如何开好需求评审会？

就结论而言，就是四个字：做足准备！

首先，我们在写需求画原型时，要做足准备

第一，产品经理在做原型时，不要一开始就画交互界面，而是单独列一个区域，把这个版本需求的来龙去脉说清楚。包括为什么要做这个版本，要满足哪些人的哪些需求，做了这些后有什么价值，如何证明，以及大概要做的模块都有哪些，时间估算等等，让每个来开会的人一上来就有宏观意识。

第二，涉及业务流程的需求，也要单独列一个区域，专门绘制流程图，并把流程图中的“概念”解释清楚，然后才是针对概念的交互界面，这样也能方便开发迅速理解业务，再和交互稿对照查看，印象更深刻。

第三，在绘制交互界面时，也要尽量按目的、按逻辑分组归类。比如将“提升用户活跃”作为大分类，在这个分类下，“推送功能优化”作为小分类，在这个小分类下，我们要做哪些子模块，层层分解。

其次，我们在会议召开前期，也要做足准备

第一，在和全体开发开会前，尽量提前和开发各业务负责人召开一个小会，进行需求初评，目的是提前收集问题，沟通是否有技术难点，确认需求的开发成本，并从技术的角度看是否有考虑不全的逻辑漏洞等等。如果存在需求不足的地方尽快修改。当然还可让开发负责人向下简单传达要做哪些需求，让大家心里有数。

第二，在会议召开前，一定先通过邮件形式发布会议召开邀请，同时附上即将要讲解的原型文档，至少提前1天让所有参会人员了解需求。当然最好在发完邮件后到每个开发座位上再提醒一下，督促大家去阅读文档，有较大分歧的反馈尽早收集处理。

最后，在召开会议时，更要有备而来

第一，每一个需求点，产品经理自己要有充足的理由说服大家，无论是数据证明，还是市场调研，还是用户心理分析等等，尽量避免说出“我觉得应该XXX”这样的话，而是讲客观依据。

第二，每一种交互设计，都尽量有几套方案备选，如果大家对已画出的交互意见较大，就再摆出几种备选，让大家有目的地展开讨论。

第三，产品经理讲解交互稿时，可以先讲总体，再讲重要细节，再讲次重要细节，并层层确认。比如订单支付流程，先讲解支付顺利的主流程，再讲解支付失败的异常流程，最后再讲解支付成功、失败的交互效果。这样做的好处是限制讨论边界，避免理解偏差。

第四，对于会议上争议较大的问题点，有个“5分钟”原则，5分钟后还没有结论，就记录下来，会后再单独讨论。如果问题点太多，就说明产品经理还没考虑清楚，那就尽早结束会议，再重新修改原型，再召开一次会议，当然我们还是希望这样的情况不要发生，因为非常浪费时间和精力。

最后的最后，再介绍一个小经验

就是建议将PRD、需求FeatureList和原型都画在一起，统一讲解，这样能提高效率，减少理解成本。如下图所示：

好的需求评审流程该怎么走？

搞产品的人都会经历过无数次的挑刺，无数次的评审！

当大家对于产品提出一道道质疑时，这时候就要以专业的只是说服沟通他们！

很多产品人更多层面是在会议之前准备的不够充分，从而导致会议效率低下，甚至于需要好几次才能通过！

（需求评审会议的意义再次就不做讨论了，你们懂得！）

在召开会议前，内心要清楚的知道本次会议参与的人员类型，各自大概的需求点？

好了，开始直奔主题内容，说说好的需求评审流程该怎么走？

按照会议的流程来说，可以划分为 “会议前”，“会议中”，“会议后”这三大环节。

一、会议前

会议召开前

在会议召开之前，应提前准备好相关的内容，以及常见问题的应对措施。

1、了解会议目的

• 统一思想，了解需求意义
• 明确需求具体涉及范围
• 确定事项落实工期与责任
• 确定开展工作

你要清晰的知道为什么要召开这次会议。

2、提前准备好资料

需准备好相关的原型，交互设计稿，流程图，功能概要列表，PTT，PRD等，并在提前发送到环节涉及所有人。

3、提前通知责任人

• 除了正式渠道（如邮件，群等），还需再次口头告知确认，
• 通知内容需包含：需求资料，参会人员，会议内容主题，需要配合资源内容
  等

4、备好问题速救药

产品内部自行检查好：一般保证这几方面：（确定性，完整性，复杂性，熟悉性，稳定性，交互性）

• 确定要这么做？这么做会*，考虑清楚要这么做？
• 还有这种情况你没考虑到？
• 这个搞的话，太复杂了，能简单点不？
• 你要动这一块，有没有考虑到现有的流程？
• 确定定稿这些内容了，会不会再出现变化？
• 这个交互为什么要这样，主要的是这样？

划重点来了，在对接研发人员，他们要的不是你懂技术，要的是你不要改需求！

二、会议中

会议召开中

准备好相关的资料后，也提前通知责任人了，终于可以开始了。

1、召集小伙伴开会咯

时间点到了后，要及时拉上所有相关人员，由于人都有拖延懒惰的特点，记得在开会10分钟就要喊上他们，保证会议准时进行！

2、讲解前应先说说本次会议的内容范围

相关涉及责任人到会议室后，应在开会前明确表明确认：

本次会议目的，会议涉及内容，会议所需结果；

（不要一上来就直接讲原型！）

3、记得做好会议记录

除了记录常规的会议内容之外，还需要重点记录核心争议讨论点，以及讨论结果！

4、有争论不可怕，可怕的是方向偏，无效率

• 在讨论需求之前，要明确争论基点，不能无休止讨论，也不能啥也不说
• 出现争论是好事，证明哪些人有在看，有在听
• 会前一定要保证主流程，主方向，主内容OK没问题
• 非常细的内容，不涉及主流程环节下，建议会后解决
• 主流程环节出现争论，一定要在会议解决掉
• 不宜在会议争论太长时间在工期环节
• 明确本次开会目标，不宜偏题讨论

5、终于可以开始好好的讲解需求了

讲解答疑环节中应讲究条理性与节奏。

• 需求背景：概述需求从哪来，为何要做这块，
• 用户与需求概述：描述需求应该要做成什么样，
• 功能模块：需求涉及相关的重点大的功能点，
• 简要优先级：描述下当前的最重点内容，
• 流程讲解：讲解本次需求涉及主要流程，
• 原型与交互：开始讲解原型内容和交互，
• 数据指标：讲解本次需要哪些关键性的指标；

6、需要各各环节的配合

明确落实本次需求需要哪些人，哪些资源进行配合！

比如：需要运营协助处理文案；需要开发协助技术实现，需要行政协助开设激励奖等

7、总结概括本次会议内容

• 讲解沟通完成之后，应再次复述总体需求内容
• 咨询确认是否了解当前整个需求内容

8、责任人复述确认

• 让相关责任人简要复述确认理解层面是否一致
• 以明确了解需求内容为判断依据
• 是否签字画押确认由各自环境决定

9、争吵时间节点（工期与上线）

讲解沟通完毕后，就进行相关的初步定稿评估工期时间，以及告知计划上线时间；（会议定稿初步工期，部分争议则私下解决！）

三、会议后

会议召开后

终于熬过挑刺环节了，距离落地执行没多远了，可工作还有这些：

1、整理会议纪要内容

会议结束后，应当天总结处理会议上所有讨论的争议点，以及讨论的结果内容！

2、是否需要进行调整

立马处理在会议上未能讨论解决的内容：

• 应尽快确认是否应该调整？调整的范围是多少？
• 并且及时反馈告知处理结果。

3、是否需要再次召开

会议结束后，是否需要再次召开会议，讨论内容，

以落地责任人了解程度为判断依据！

4、发送会议记录

会议结束后，当天内应及时通过正式渠道发布会议纪要。

• 会议讨论设计内容
• 争议点及其处理内容
• 初步定稿时间与责任人

5、落实明确行动计划

会议定稿后，应推动落实需求前进！

再次确定定稿内容时间节点！

6、任务排期

内容/节点定稿后，则落实到具体的排期，开始项目跟进！

7、定稿内容发送

定稿确认之后，应正式发布通知相关责任人：

• 会议最终结果（排期，时间节点等）
• 本次涉及内容（有哪些内容，做到啥程度等）
• 需要谁进行配合，感谢哪些支持等等

当我们接到一个新需求点时，应遵循的需求分析步骤有哪些？

当我们接到一个新需求点时，应遵循的需求分析步骤有哪些？

首先，要根据需求设计功能，就要做到理解需求的来龙去脉。为此，需要搞清楚以下问题：

1. 为什么会产生这个需求？

当需求方向你阐述完某个需求后，向她询问：提这个需求的目的是什么？即为什么会产生这个需求？这个问题帮你完全理解需求，帮你辨别需求的真伪。

2. 什么场景下会使用这个需求？

即搞清楚什么人在什么情况下会用到此功能。只有明白了这个，才知道如何更好地设计功能来满足需要。

3. 是否有可能衍生出新的场景？

为了避免设计的功能因扩展性不足，后期推翻重来，在一开始，就应该做尽可能全面的考虑。通过需求方的场景，扩展思考，是否存在衍生的场景。思考的过程，也是帮助你抓住和理解需求本质的过程。

4. 技术层面如何看待这个需求？

接到需求，并充分理解了需求后，跟架构师或技术负责人花几分钟时间讨论一下，听听他从技术上对需求的考虑。通过此过程，你们基本会对需求点及实现方式达成共识，在后期正式开发时，阻碍会小得多。

5. 是否可纳入backlog？

确认需求为真实需求后，将其纳入到backlog中，并大致描述需求逻辑，方便项目组成员对待开发工作心里有数。（应注意backlog是已明确并经过去伪存真的需求，是指导项目组掌控项目的工具，而不是产品经理的备忘录。同时粒度不宜过细，否则非常不利于维护和沟通使用）

backlog表头及说明

6. 开启版本迭代，细化需求

当要开启一个版本的规划时，我们从backlog中挑出高优先级的若干个需求，并细化需求、制定迭代计划。

细化某个需求点时，需要做的事情如下：

A. 版本功能列表说明

在版本功能列表中交代清楚需求在此次版本中的优先级（高：必须做；中：进度紧张时，可不做）、类型（新增：此前没有，需重新开发的功能；修改：功能已有，需做调整的功能；删除：不再需要，删除的功能）、描述（交代逻辑）、详情（链接到对应的页面）：

附在PRD文档中的当前版本功能列表说明

B. 业务流程说明

若需求点story较大，有涉及业务的流转，则需首先梳理业务流程。流程的梳理不仅帮助项目组成员理解需求，也是帮助自己梳理思路。

C. 设计页面和交互

流程清楚以后，就可以着手设计原型了。此时，如下几点要素是必不可少的考虑因素：

（1）页面的名称是什么？

设计一个页面相当于创造了一个从来没有的新东西，为了与其他东西进行区分，总要给他一个标识。故，每做一个页面，应先给它命名，且这个名称是独一无二的。既然是名字，那么名词或动名词是最合适的，但贵在语义表达准确，即让阅读者看到页面名称，就能八九不离十的了解到这个页面是用来做什么的？

（2）页面由哪些功能组成？

系统功能由一个个页面承载。每个页面分担完成功能中的若干个功能点，因此一个网页就是由一个个的功能点组成的。当设计一个页面的时候，就要构思好，这个页面应包含的功能点应该有哪些？如“写文章”这个页面，大致应有：文字编辑、图片插入、文章发布、文章归类等几个功能点。

（3）完成功能需要哪些操作？

完成每个功能点，用户需要在系统上进行若干步操作。因此在设计一个功能的时候，应交代清楚用户使用这个功能，需进行哪几步操作？如完成“文字编辑”这个功能点，需要先点击操作“写文章”，再完成“书写”，完成“插入图片”，最后“保存”。

（4）执行某个操作的条件是什么？

系统上的每个操作，需要满足某些条件才可触发。否则，系统功能无法形成体系，处于紊乱的状态。如“当文章内容发生变化时”，才可做“保存”的操作。

一个需求从提出到设计实现，应该遵循特定的生命周期，否则极易出现遗漏、混乱的情况，极其不利于项目的质量和整体把控。

特别应注意的一点是，不要听到一个需求，内心就有一种莫名的冲动，想要马上实现此需求。静下来慢慢规划，想清楚，才是最重要的。

明天计划的事情：（一定要写非常细致的内容） 

画完逗你学二期原型，做完内评，修改好内评出现的问题，尽快需求评审和讲解。因为我给产品估的时间是5天，明天就是第五天了。。。
遇到的问题：（遇到什么困难，怎么解决的） 

暂无
收获：（通过今天的学习，学到了什么知识）

青春中感觉又送走了一个朋友。

s2的世界赛是我玩英雄联盟半年之后接触的第一个英雄联盟比赛，还记得当初IG没有突破小组赛，WE和CLGEU长达八小时的断线重赛，我都是看着直播过来的。特别是在3个月后ipl5 WE击败TPA和M5等强队夺得中国队的第一个世界冠军时，那时是我玩英雄联盟时最纯粹的游戏和比赛的回忆；

s3我冲上了钻一，还和几个朋友一起去杭州百脑汇打比赛，和他们一起在网吧看s3决赛，皇族0比3 SKT，那时候虽然也很失望，大家互相说着“我上我也0比3”，但并没有觉得是末日，我感觉我和英雄联盟都还有更加美好的未来；

s4的时候，身边的朋友依然在，我也随着惯性再次冲上了钻一，然后就是无尽的空虚感，那时候开始，英雄联盟对于我而言就不再是一个能够纯粹享受的游戏了，一般如果没有朋友一起玩，我也不会自己打开游戏了，s4的时候，依然是皇族对阵skt，结果皇族是1比3输了，大家又开始打趣，这一次你上就不一定会是1比3了，那时，我已经是大四了，周围的朋友渐渐地开始毕业离去，只有比赛，规模变得越来越大了；

s5的时候，我的记忆反而变得少了，只记得在离开大学前的3月，大早上躺在床上看着季中赛EDGBO5 3：2击败SKT夺冠，我都是看一局又睡过去一局，结果看的三局，除了最后一局，前两局都是skt赢了；然后是lpl第八名的WE在iem上击败lck的头名，使得国人对于lpl的膨胀到达了顶点。然后就是s5三只lpl战队的全线溃败，韦神的反向射箭；

s6的时候，更加没什么印象了，印象最深刻的，就是WE和IM在争夺总决赛资格时，第五局泰坦的绕后，如果没有那次绕后，那么WE就能够更早一年重返世界赛舞台了；

s7，我已经不玩英雄联盟好久好久了，但是比赛却还是熟悉的界面，装备还是熟悉的装备，出了几个新英雄，不知道他们的技能，但是比赛还是没有变。我甚至连小组赛都没有兴趣看了，唯一认真看完的，只有四强赛，但是，这就是结局了吧。

也许还会有下一个中国队夺冠，但我的青春却不会再来了，s2到s7，6年，时光不会再倒流，那么我也只好，全剧终。