前言：
这是IT修真院自问自答系列第十篇，同样是干货和硬广混杂。https://www.zhihu.com/collection/77083735
顺手推荐一下修真院的专栏，各种IT行业的真实小故事https://zhuanlan.zhihu.com/jnshu
正文
以敏捷开发为例，基本上会分成以下几个阶段。
1.设计需求
2.需求评审
3.需求讲解
4.接口评审
5.方案评审
6.每日晨会
7.CodeReview
8.性能测试
9.Demo
10.打Tag&测试环境发布
11.Bug修复
12.线上环境发布
第一阶段 设计需求
参与人员：PM 1人
预计时间：2~3周
产出物：PPT，Story，原型图
一般而言，一个PM就够了。天下PM一大抄，需求的来源往往源自以下几种：
1. 1%来自用户的反馈
2. 5%来自运营部门的要求
3. 1%是PM抽疯了自己想做
4. 93%来自老板的要求
来自用户的反馈往往是来自各种吐槽和抱怨，什么这个看不懂了，那个不明白了，为什么没有这个功能了，为什么没有那个功能了。会哭的孩子有奶吃，多多少少会影响PM的决策。
顺便说PM分成两种。一种是PM，一种是画原型的。
来自运营部门的要求多数跟推广宣传或者是内容管理有关系，最常见也最Low的往往就是抽奖，积分，活动，兑换，推荐。能做出一个小游戏一样，或者是一个真正的活动的很少很少。
PM自己抽疯的时候很少，往往是对这个行业，这个功能，这个需求有很直观的感受，这个东西做不出来他就会死。
最后一个，老板的要求往往是最常见的，也是最烦的。老板往往是压根就不懂技术的，但是往往会比较懂行业，或者是经常虚心的听从行业专家的建议。
本篇吐槽功能自动衰减，所以减少这方面的篇幅。主要讲PM拿到需求之后要做什么。
PM拿到需求之后，第一步就是要去抄别的网站或者是App。呸呸呸，是参考，或者是竞品调研。
总之就是要扩展视野，去看看别人怎么设计的。看了一圈，各种乱七八糟的东西观摩一圈，大概就知道要怎么做了。
PM本身应该具备的能力就是在半小时之内了解一个不熟悉的行业的需求，大致知道他们要做成什么样。
这个时候，强烈反对直接画原型-如果你想成为一个真正的PM，画脑图也好，做PPT也好，拆解Story也好，一定是先去做这些事情，不要把自己局限在一个画原型的怪圈里-我说过，PM分成两种，一种是PM，一种是画原型的。
拆解Story真心是一个好的梳理需求的办法，它能帮助你理清楚优先级，每一个Story的意义和价值。怎么拆解是另一个话题。
拆解Story之前，最好是做PPT，把你的产品设计思路表达清楚，把你看过的别人的PM描述出来，讲清楚背景，讲清楚自己为什么要这么做，讲清楚自己做的东西背后的逻辑。
PPT，Story做好之后，再去做原型。原型的意义在于展现出来Story的价值。
另外，做原型的时候，不要犯以下三个错误：
第一，把所有的交互都画在原型上，做各种点击跳转。
这样开发人员根本不知道原型上哪些能点，哪些不能点。就算是Axure支持了显示热点，也很烦，特别是层次比较深的。
所以，请遵循一个最简单的规则。原型下面分模块，模块就是文件夹，文件平下面是各个独立的页面。
不要在文件下面挂文件，看着很烦。
第二。一个文件里面画很多张页面，各种拖拖拽拽的烦死个人了。
不知道从哪里开始，画原型有这种风格了，一个大的页面里放一堆页面。很多少时候都是觉得这样看起来，用箭头标注起来更方面看跳转，有点理解不能。如果要看各种转跳转，直接画一个页面跳转图就好了，折腾原型图干嘛。
同样的道理，还是导致各种分不清有多少东西，而且画布太大拖拽好烦的。
第三。如果有分期的需求，在做第四期需求的时候，请不要把之前三期的需求全部混在一起。
马丹完全分不清倒底哪个是新需求，哪些是已实现的。单独的把四期的需求列出来就好了。
为什么时间是2~3周呢？这跟两个因素有关， 一个是跟PM的设计周期有关系，一个是开发周期有关系。如果你有两个8人团队，能保证都按照这个正确的节奏走，那么一周发布一次版本轻轻松松，而且，完全不是各种赶需求。
不对以上言论负任何责任，纯属自己扯淡。
好的需求设计完成，我们进入需求评审阶段。
第二阶段 需求评审
参与人员：AppLeader PMLeader，后端Leader，QALeader，前端Leader UILeader 6人
预计时间：2H
产出物：需求评审结论，预计完成时间，开发团队成员，需求讲解时间
需求评审要注意的就是，一定是要评审完整的需求，一定要评审细节。
如果拿出来评审的需求并不是一个真正的，马上就能开始做的需求，这个叫做头脑风暴或者是内部评审，都成，叫之不是一个需求评审。
挨个去思考每一个需求的含义，每一个Story的价值。
如果说大家对某一个功能有意见，把意见反馈给PM，让PM最终做决定，这是对PM这个职位的尊重。
如果大家提到的一些疑问，如果PM能想到了，这是PM考虑周全，这次评审完美。
如果大家提到的这些疑问，PM完全没想到，这就是PM考虑不周，需要再加强内评。
需求评审要关注三个点，
第一个，哪些功能有难度。
第二个，哪些功能价值低，又耗费时间长。
第三个，能否在一个迭代周期（2~3周）内完成。
怎么拆需求，如果不确定的需求怎么做，这是另一个话题。
参与的各开发组Leader，接着要做的事情就是安排好开发人员。
这也是对Leader的要求，提前预估好人手。
此外，就是要确定需求讲解的时间。
QA组也可以开始着手准备测试用例，UI组可以去画UI图了。
评审结束，我们进入需求讲解阶段。
网友评论