原文地址https://www.zhihu.com/question/52525581/answer/130905959 来源：知乎
2.宣讲：产品经理驱动的团队，每个迭代，产品会设计好需求策划拉老板拍版，拍版完成PM会拉团队成员召开迭代启动会议，说明本次迭代工作和关键时间点，并将需求按照优先级排列；迭代会议后通过的需求会落地到需求文档，由视觉交互介入设计，完成后拉团队成员召开需求宣讲会议
3.排期：宣讲完成后pm会收集团队成员的工作排期，开发工作量和测试工作量，根据迭代版本关键时间点增加或减少低优先级需求，确定下来明确工作和关键时间点：开发联调时间、提体验时间、设计走查时间、提交测试时间、系统测试时间、上线时间
4.开发：开发按照需求落地技术实现、约定协议、联调，其中每天pm早上召开晨会确定进度是否符合预期，是否有风险有需要调动的资源，根据进度确定是否加班，开发完成进行联调和自测，完成后提交产品体验和视觉走查，通过后提测；一般新功能是在分支开发，测试稳定后合入主干进行集成测试和系统测试，其中包括一些兼容性测试、稳定性测试、专项测试、压测，涉及前后端流程长的还有全流程验证；测试完成后根据bug情况和风险确定是否可以上线
5.上线运营：如果功能较大质量存在风险一般涉及到功能灰度，功能灰度方式有多种：内部试用、外部用户报名试用、白名单配置、按地域灰度，灰度阶段收集质量数据修改；一般一个功能两种展示也会选择灰度来确定用户偏好和功能效果；灰度完成后全量上线，运营同学收集线上运营问题反馈，一段时间后产品收集功能用户使用上报数据
6.迭代总结：总结本次迭代做的好的和待提高的，以及产品show用户数据，如果有重大运营事故还需要回溯
此外，对于另一些产品：api、sdk、后台等流程没有这么复杂，少了体验等环节更偏重于稳定性。
- 定需求
- 出 PRD
- 开个会，定排期
- 各干各的，到时间，发测试
- 测试 & bugfix
- 发生产
链接：https://www.zhihu.com/question/52525581/answer/130893378
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
正文 以敏捷开发为例，基本上会分成以下几个阶段。
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图了。
评审结束，我们进入需求讲解阶段。