本篇重点向产品上游（多指代运营同学）如何优雅的向产品团队提需求。我们知道需求描述越精准、需求的逻辑层次越分明、需求的上下文等关联考虑越到位，这份需求的可评估性越高、下游接盘者不遗漏考虑的风险越小、落地执行的效率也是最高的。

本篇重点向产品上游（多指代运营同学）如何优雅的向产品团队提需求。我们知道需求描述越精准、需求的逻辑层次越分明、需求的上下文等关联考虑越到位，这份需求的可评估性越高、下游接盘者不遗漏考虑的风险越小、落地执行的效率也是最高的。

最重要的是，能提优质需求的同学也是团队中最优秀的parnter，我们经常讲团队协作，其实“富有同理心，不对下游挖坑，交付产物质量高”是最大诚意的团队协作，您说是么？

除此之外，产品、研发同学对运营需求的“热爱度不够”与“平台的发展一定绕不开出色的运营”之间的矛盾，希望通过此次分享，将供需双方拉到一起，统一共识，明确角色边界，促进良性协作，将矛盾在萌芽状态提前化解调，做到产品运营是一家O(∩_∩)O哈哈~

阅读对象：运营同学、产品同学；

第一讲：需求之坑：产品与运营的爱恨情仇

故事1：开始机械传达领导的指示、中途绑架领导垫背、结果乌烟瘴气

视觉稿设计完，需求方没有领导发话不确认，前端干完了要大改，前端工程师吐血，下游测试档期错乱~

1. 小张，尽快确认~
2. 小张，尽快确认~
3. 小张，我在等领导的信（兄弟，你在绑架领导）~

结论及危害：提需求者机械的传递领导交办的任务，自己不下功夫调研、思考、梳理需求或浅尝辄止的蜻蜓点水，把自己也当领导以“任务式”或“简陋表面描述式”向下游提需求。

除此之外，面对下游对某些细节的确认或产物的确认时，把领导拉出来当挡箭牌，直接绑架领导。

由此可见，此类员工看似好人一个，实则危害极大，是团队中最大的败类，如有可能，应立刻“斩立决”，从团队中清除。

备注：上面的场景多指不专业的运营同学，不少产品同学有时候也容易机械的执行需求。如果把上述运营同学和产品同学放在某个需求开发中，后果可堪设想——“四不像需求”+“鸡肋功能”+“团队裂痕”+“士气受挫”。

故事2：只管张嘴要、其它都不管了

活动已上线，APP的logo闪屏活动页未替换，还是上个活动的。

1. 需求方自己不用，提的需求是“岗位应酬”，所有工作都依赖“产品-研发-测试-客服”保姆式服务；
2. 产品和测试组没有作业list，靠经验和记性，想到哪算哪，导致最后两环的防线未防住。

结论及危害：产生这种结果一般有如下几个原因：

• 其一：时差原因，项目交付距离提需求日已过去一周或更长，需求方对当前交付需求的重视程度（考虑细节）降低了（容易忘考虑）；
• 其二：前送后紧、前期很重视，后面用时放松了；
• 其三：思维懒惰，以为需求上线后就完事大吉，而忘记运营需求会伴随很多运营的运营配置工作在其中；
• 其四：团队真空，产品同学和运营同学相互指望对方或者产品未尽培训提醒之责任或者运营团队缺乏基本的作业流程（上线前相关配置项要统一发布）。

其危害是“平台乌龙”被用户、被客服、被老板diss整个团队。

故事3：错把自己当领导 or 业余外行

某天运营说领导让上个邀请撒钱活动，该活动需要在几号前完成，活动的页面长这个样子。产品经理蒙圈了，你这需求完了？？？下面这些东西是我自己拍板后，和你或者你的领导想的不一样，咋办？

（1）登录、未登录场景？

（2）薅羊毛防刷策略？

（3）相关业务场景的入口设在哪里？

• 入口1（发起方）
• 入口2（查看方）
• 入口3（账户中心）
• 入口4（管理方）
• 入口5：通知
• 入口6：客服
• 入口7：运营公告
• 入口8：现有活动是否冲突
• 入口9：老活动安排下线
• 入口10：渠道合作是否影响
• 入口11（追踪）

结论及危害：和上面故事一多少有些相似，但和故事一有本质不同，故事一是“他懂+他偷懒+他怕担责”；故事二是“他外行或把自己当领导了”。

这里的场景多是极其复杂的业务需求，提需求者多是外行，朋友圈或某个竞品看到个活动页，就误以为很简单，咱们也马上搞一个。其危害是容易造成团队裂痕，产品团队给出的工期评估与之相差甚远，自己以为产品团队在忽悠或放水，久而久之会产生裂痕。

正向想，逆向想、框架想、现有想、执行想、反馈想，想清楚再提

相信产品同学在日常生活中都会经常遇到上述几个场景，故事场景中运营有时候是运营，有时候就是产品自己。

这些低质挖坑需求一般都难逃如下几个：

1. 职业外行，且不下功夫提升自己；
2. 职业内行，你说的都知道，就是习惯性偷懒；
3. 习惯把自己当领导，习惯用任务的方式提需求；
4. 只管生孩子（提需求），不管养孩子（把运营配置等活也指望产品或技术团队都包了，提需求就像每月例行过度，走个邮件而已）。

第二讲：正确的认识需求

1. 什么是需求

在软件研发领域，需求可以用“3+1”分层讲解：

1. 目标需求：提出一个目标，给一个指导原则（可有可无），适用对象：业务领导；
2. 业务需求：针对上述目标在业务上需要考虑的方方面面，适用对象：运营人员、某某业务岗（如财务、如风控）；
3. 运营策划（运营场景）：设计运营业务流及活动方案；
4. 产品需求：将上述1、3转化为产品需求，逻辑需求，输出给研发，并基于“有限的研发资源”、“确定的时间边界”在业务需求方、研发可实现能力、必要的迭代扩展能力三个维度给出专家决策意见。

各种需求的适用场景说明示例：

1. 能不能做一个***， 这是探讨，探讨后形成思路……
2. 你们做个***，这是boss的特权，不适用与职能岗……
3. 咱们要实现这个活动，大概需要多少工作量，这是预沟通，为了进一步详细提需求做准备……
4. 我这个着急，很急？事故前提下优先处理，否则你的很急耍了别人的正常渠道的需求（火车站排队）……
5. 我的需求方案已整理（流程图、页面图、文案说明、关联影像、特殊说明、优先级、上线时间等等），你看下还有哪些忘记考虑~ 这个需求不错，兄弟，相见恨晚，产品同学最喜欢和你这种需求爸爸打交道了~

实战复盘：

实际上，优秀的队友无论出处，即便不是IT行业从业者，你严谨的做事风格也值得IT从业者敬重！譬如下面两个case分别是来自“某从业多年的运营同学”与“某风控同学”，我们可以清晰的看出两个需求的差距——其对下游的“内耗沟通”或者底层对应的“企业成本浪费”有时候很惊人，所以我前面提到，对“低质需求”是团队的搅屎棍，是企业成本的第一个隐形杀手。

低质需求case：依猫画虎、粗制滥造。

高质需求case：目标明确-思路清晰-考虑全面-方案合理-同理心。

这是一份非互联网行业的需求说明，但当事人很用心，远超过从业多年的运营同学或者不少产品同学。这份需求除了有邮件的详尽说明外，还附带着台下大量的调研、沟通和攒局讨论。

当事人除了很下功夫投入外，其工作方法也很专业，更值得我们致敬，我们将其解构，细细品味如下：

表达背景：根据合规报送承诺提取需求；

1. 前置沟通：找产品沟通实时细节；
2. 课下功夫：制定需求方案；
3. 文字功夫：详尽分明、逻辑严谨；
4. 澄清需求：组织发起讨论；
5. 穷追猛打：修改优化；
6. 锁定预期：研发排期；
7. 闭环习惯：上线验收（备注：如下截图无法体现此工作）；

Demo期的产品或者说产品体系内的原生需求，沟通链条短或者说产品内部沟通即可，考验的是产品经理自身的知识素养、执业能力、和业务的系统理解。

运营类的需求，沟通链条长或者说存在交叉部分，如果考虑缺失较多，产品过多代劳会导致极大的沟通内耗和效率风险（立场不同、经验不同、思路就会差异）、工作边界模糊（相互指望的考虑真空）。

2. 要什么 VS 怎么做

活动类的更多是要什么? 所以运营的重心在活动类需求。

换句话说，运营类的需求需要有运营同学主控，其不光需在大的运营诉求、策略设计、流程设计方面下下功夫，还需在入口设计、文案设计、数据统计、业务闭环等方方面面都要系统考虑。如果只是以老板自居，简单粗暴的参考同行的几个界面就当以为自己可干运营了，会亵渎运营岗位的神圣性和严肃性，会对团队生态造成严重的内耗，也会让运营策划活动流于形式而非最核心的一击必中的“效果”诉求。

功能类的更多设计怎么做？ 所以产品的重心在功能类需求。

功能类的需求当有产品经理扛起大旗，哪怕是运营类的需求也应当有产品经理负全责，譬如运营红包发布工具、运营活动管理发布工具、运营数据统计分析工具、运营广告位投放工具等，这些都需要产品经理与使用人员（运营、财务等）充分沟通，挖掘需求背后的诉求，解构重构需求，形成自己的产品思路、并充分调研同行的最新解决方案及实现方式，结合自己团队的资源情况和产品建设现况，给出相对最优的需求实现方案。

3. 不确定带来的痛苦

人世间最大的痛苦之一是“不确定”+“猜测推断”+“出事连坐”带来的害怕参与。所以，一场优雅的需求，首要是“澄清需求”，需求不澄清，后面会出大事。需求澄清了，能否实现就是团队能力和时间设定的问题了。

第三讲：如何组织一场优雅的需求

1. 酝酿需求：需求前奏-做什么？

第一步：思考为什么要做？

第二步：业务场景（涉及节点、涉及角色）是什么？

第三步：预期攻击目标是啥？

第四步：现有基础都有啥？

第五步：怎么做，初步思路：找本部门、领导、产品 沟通可行性；

第六步：有没有更好的攻击方案？同行都怎么用？他们这样做是否有特殊的背景？历史上我们是怎么做的？

第七步：成本代价预估；

第八步：内部是否达成共识了？

第九步：内部过会论证可行性、形成共识：优先级、时间点；

方式：走路带风的口头沟通+敏捷速决的共识小会；

2. 发起需求：需求设计-怎么做？

第一步：撰写需求文档；

第二步：自查需求文档；

第三步：内部过会；

第四步：提交给外部执行；

方式：严谨文档+邮件召会+共识小会

3. 受理需求：产品组-做研发第2道干扰拦截

第一步：需求了解；

第二步：参与需求评审；

第三步：细节确认；

第四步：实现策略层设计、排期统筹、资源组织； 不可能三角概念；

第五步：前置研发资源协调、前置工作准备；

第六步：排期准备：产品排期、视觉排期、测试排期；

方式：严谨文档+邮件召会+共识小会

4. 启动需求：产品-视觉-技术

第一步：产品设计（如需产品岗介入：如底层逻辑、整体合并考虑、项目综合推进等）；

第二步：需求方沟通及细节确认；

第三步：需求评审、需求立项；

方式：严谨文档+邮件召会+共识大会

关于此模块，我在“产品从业干货-基础技能篇：如何优雅的驾驭需求？”一文中有更系统的讲解和实力说明，此处不再累述，产品从业者有必要阅读一下。

5. 运营输出：注意事项

1. 竞品调研及结论输出（如需要）；
2. 现有的数据分析及本需求的价值（如需要）；
3. 业务流设计；
4. 页面标题；
5. 页面内容、含交互；
6. 视觉传达重点诉求；
7. 短信及APP推送配套（如需要）；
8. Banner配套（如需要）；
9. 分享节点（如需要）；
10. 老活动衔接连贯配套（如需要）；
11. 公众号文章配套（如需要）；
12. 关联影响及注意事项；
13. 数据初始化说明等（如榜单干预等）；
14. 客服前置培训配套及值班匹配配套（如需要）；
15. 资产供标配套（如需要）；
16. 上线时间节点；
17. 流量监控（如需要）；

6. 视觉输出：注意事项

1. 需求解构、交互稿解构；
2. 整体考虑：活动周期、研发工期、研发资源
3. 技术实现成本；
4. 字体运用；
5. 图片大小；
6. 移动端效果；
7. 稿件移交方式；
8. 需求自查；
9. 需求方验收确认。

7. 产品输出：注意事项

方案具备扩展性；

文档不给研发、测试挖坑。

8. 研发输出：注意事项

略

9. 测试输出：注意事项

一个原则：用户发现的非极端场景遇到的问题测试组未发现都是测试组失职的问题。

10. 不同的需求 不同的处置流程

数据类需求：

1. 先看后台能否交差组合出；
2. 简易需求 直接对接DBA；
3. 必要的升级为【功能】——数据中心 通过“京沪高铁”模式在6月份之前分批建成。

数据需求样例：

为配合运营活动，需要调取2019年1月份房宝贷出借人回款明细。

表头如下：

数据需求应答样例：

受理人收到邮件后直接给需求人进行邮件反馈：

1. 收到，立即处理，预计***点完成；
2. 收到，忙完**处理，预计**点完成。

Ps：如未反馈，直接当面找上述两位看邮件并口头沟通交付情况。

活动类需求：

1. 运营直接与视觉对接、验收视觉产物；
2. 产品参与实现方案支持、项目组织交付。

功能类需求：

1. 各需求方提需求；
2. 产品组采集需求后，全包设计；
3. 需求设计完后与需求方确认需求是否 满足预期指标；
4. 确认无误后启动研发。

故障类需求：

1. P1类：研发立即解决，不解决不下火线（吃饭睡觉都让路）；
2. P2类：产品纳入需求池，统筹排期。

口头应急类需求：

1. 需求方有限度的、处于用户体验和业务安全考虑的；
2. BoSS交办紧急的；
3. 商务需要紧急的。

第四讲：工具装备

武器1：自己走一圈（案例略）

武器2：思考一圈

武器3：竞品捋一捋

武器3：百度搜一搜

武器5：纸和笔画一画

武器6：Excel+Visio+RP

武器7：邮件+口头+钉钉+评审会

武器8：自己尝试走一走

结语

1. 当成自己的事，如无必要，勿增实体；如有必要，要做到极致；如未极致，也不能失格；
2. 如果搞砸了，这个事除了浪费成本外，更浪费时间窗口和 参与者内心受伤；
3. 流程走一走，顺一顺：自左向右，自上向下复查。

作者：九天牧人，个人微信unifarm

本文由 @九天牧人 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议