补充在前面：
1、需求管理其实是对用户预期和公司业务策略、节奏的管理。所以，一不小心又把课题写大了，从产品团队的沟通协作延伸到了业务需求方（公司层面）的沟通协作。
2、沟通协作的目的是提高团队效率，但在业务协作之外，我们也需要关注团队中不同成员对个人成长的诉求，毕竟，团队成员才是最终的生产力。所以，我也融入对团队管理和成长的部分内容。这下内容更大了……????
3、借鉴上次分享的惨痛经验，最终还是决定把这次作业分两篇来写完。给大家阅读带来不便还请见谅。
沟通，是所有团队最常见的两个主题之一（另一个是吐槽老板的各种傻X）。工作一段时间（多交流几次）之后，你会发现：每个公司（团队）沟通问题和沟通机制都不同，但大家遇到的问题基本相似。这也算是一种殊途同归吧，下面几种情况，相信所有的互联网公司都会遇到：
1、需求冲突，资源不足
用户、客户、老板、运营、营销、客服、甚至关联业务团队的需求，一个比一个急；可开发永远就那么几颗人……怎么办？
2、需求变更
产品开发到一半了，需求变了。此时，产品经理就算心里是一万只草泥马奔过，也得想尽办法说服开发团队实现新的需求……此处被虐千万遍。
3、开发时间评估不准或者延期
产品经理（尤其是不了解技术的产品经理）经常会有疑问，为什么同样的功能有的人2天能实现，有的人要3天甚至4天？……
好了，问题（需求）明确了。接下来我们就用“5W2H”方法尝试分析如何解决：
What：需求冲突（目标分散，协调不一致）；需求变更（目标不明确，或原方案周期太长成本太高不能满足时间需求）；研发延期（需求理解偏差、系统设计方案偏差、研发效率问题）。
Who：市场部（营销、BD）、运营部（活动运营、客服、运营支撑）、法务财务（合规）、产品、设计、研发团队共同造就了这些问题。
When：产品设计前，需求采集和确认过程中，各业务方都认为自己的需求优先级高；产品设计时，大家又都认为自己更懂用户或自己的建议也代表了部分用户，so，每个人的建议（需求）都应该被考虑。产品开发中，要么技术发现原来的评估不准确，要么需求变了……
Why：为什么会导致这些情况，各需求方都有各自的目标（屁股决定脑袋）。大家对需求理解不同表述不一致；产品方案设计不严谨，系统设计分析不完整……
Where：不展开了。
How：如何解决— —沟通/开会。
How much：做到什么程度，需要多少成本（大公司能承受更大的时间和经济成本，所以沟通机制严谨，会也多；小公司则是要力求实用）
前面铺垫（废话）那么多，主要是和大家一起梳理思路，达成思路和目标的共识。现在终于到正题了，今天分享的沟通计划根据沟通层级和规模主要分了四级：
一、业务规划（计划）会议。
二、产品研发管理流程。
三、业务（产品）数据报告。
四、月度（季度）总结/项目总结。
第一级：业务规划（计划）会
这是把公司战略拆分成战术计划的过程，也就是细化Road Map的过程。根据公司不同阶段确定开会的周期和形式。公司初期一般会一个月一次，后面就会变成每季度一次（还没来得及变成半年一次，公司就挂了……）。
主要目的：统一各部门的阶段性目标，协调跨部门的业务节奏。解决需求扎堆或因目标不明确导致的需求变更。
参与人员：各业务线（部门）的负责人/核心人员。
会议形式：必须是正式会议。会前发提纲，会中做记录，会后发纪要和结论。
为快速实现目的推荐三个沟通工具：
1、业务/产品线商业价值流转图
通过价值流转图，可以清晰的分辨出产品的商业价值（营收点）在哪里。避免各业务需求方不必要的争论。
上图是众包物流平台最简单的价值流转：商家付费给平台，平台支付配送费给配送员，配送员想要拿到配送费就得通过平台为商家提供配送服务。实际中，商业价值的流转不可能这么简单，这里推荐源自《商业模式新生代》的工具：商业模式画布。
商业模式画布把业务模式中的价值流向和核心要素（资源和商业角色）清晰的展示出来，然后，聚焦当前的业务阶段、确定公司目标后，分析当前阶段需要做的事情 ，比如引入新的渠道合作伙伴、进一步细分客户群体……。这就引出下一个工具：Road Map。
2、Road Map
其实就是公司（产品线）的阶段性目标拆解。制定Road Map必须具备三个核心要素才能发挥作用。1）阶段性目标；2）阶段性目标的指标项和具体数值；3）完成这些指标需要做的事情。举个栗子：
众包物流平台的商家愿意为准时、安全的优质配送服务支付更高费用，平台想要提供优质配送服务必须为配送员制定更高更严格的管理标准，但是，配送员不这么想。更高更严的管理势必带来配送员的流失，当平台只有一两千甚至更少配送员的时候，平台敢推行严格的管理标准么？
so，推行严格管理标准的一个明确前提就是配送员人数要达到一定数量（比如三千、五千），此时，公司（产品线）的阶段性目标就变成了明确的业务指标。指标明确了，做事方法（业务内容）也就明确了。此时，就会引出第三个工具：核心指标数据。
3、核心指标数据
此时，离达成一致的to do list就差一步了。
上一步已经确定本月（季度）业务目标为发展五千配送员，但当前只有三百，通过什么刺激配送员的加入呢？如果当前已经有三千配送员了，又做哪些事情招聘配送员？这两种情况下具体的操作方式会有明显不同，市场部需要的系统功能也不同。
与此同时，配送员的违规数量、作弊手法也有差异，运营管理部门对于配送员的审核、合规管理力度也是不一样的，同样也需要不同的功能。
会议成果：本次会议必须就阶段性业务计划达成一致结论，包括：
- 业务目标：必须是量化的指标，比如新客数、商家数、留存率、销售额等等
- 主要策略（措施）：明确了具体的量化目标后，还要跟相应团队确定具体的策略方法。以新客为例，是通过线上引流还是线下引流：是通过朋友邀请还是通过优惠吸引？同样是优惠吸引，优惠券、优惠码、首单优惠不同的方式对系统功能的需求也是不一样的。
- 执行时间：各业务需求方就各自的主要措施明确大概执行时间。对产品经理（总监）而言，一来，可以根据业务计划安排产品研发计划；二来，也是明确其他业务部门对产品研发部门的支援节奏（很多产品功能的上线节奏是受业务发展制约的，产品版本迭代管理中有一个因素就是业务现状）
PS：对于产品总监或创业公司来讲，可以通过会议形式推动业务需求方的沟通协调；对于一线产品经理来说，就只能以其他沟通方式（比如参加业务需求方的部门会议）来沟通协调。虽然方式不同，但要达成的目标都是一样的，这也是需求管理的一部分。
第二级：产品研发管理流程
通过第一级的沟通，老板和各业务方就阶段性目标、执行策略、时间节奏达成一致后，产品经理们就可以愉快的开始产品需求分析、产品设计和研发的工作了。可以说已经进入产品项目环节了。需要解决的重点是：
- 给出具体的实现方案。其实，是要解决产品项目团队成员之间的价值认同问题。产品设计中，产品经理、交互设计师、视觉设计师、研发经理（RD）之间的分歧很多时候是针对产品设计方案价值的认知差异，即对某个设计是否满足用户需求（体验）、是否能实现业务目标有异议。
- 在指定的时间里，保质保量的完成产品研发工作。此时，需要有一套能保证执行效率的项目管理机制。
产品研发管理流程框架大同小异，但具体操作时却要因人因时而异了。下面分享一下我在创业时用到的一个管理流程。
这个管理流程的环节感觉并不比大公司的正式流程少多少，但在具体操作方式上却做了最大简化：
- 各节点原点的大小代表了执行方式的正式程度，圆点最大的环节都是需要有正式会议的，而圆点小一些的环节可能只要几个人的立会就能完成。
- 在产出文档方面也做了极大简化，比如用产品业务流程、规则和功能列表代替了MRD；用功能的系统流转流程和交互稿代替了PRD……
为了节约本文的篇幅，我在本周另一篇作业《本地化极简产品研发流程》中详细讲述这个流程执行的具体细节和某些鲜为人知的坑。
第三级：业务/产品数据报告
这一级其实就是跟进产品的线上运营。数据对于产品和运营的重要程度，是不言而喻的；另外，不同的产品有不同的业务指标、分析方法和使用方式，多数人都比较熟悉（网上资料也多），这里不做介绍。
强调两个关键点：
1、新产品上线后的前两周，必须做数据分析报告。
至于为什么是前两周？主要是因为用户对产品的新功能/优化的新鲜感基本维持两周左右，此时用户数据受运营干扰较小；更真实的反应了用户的诉求。两周之后，用户对新功能的热情度降低，而且运营活动会慢慢丰富，运营因素对用户决策的影响会大于产品因素。
另外，报告中必须包括数据情况分析、原因、后续行动计划。很多时候运营和产品对数据会有不同的认知判断（初创团队或产品新人更明显），所以产品经理要把这个报告传达给所有相关团并形成统一认知，具体沟通方式可灵活操作。
2、产品经理必须向研发团队共享数据分析报告。主要是因为：
一来，满足研发团队的成就感。通常，产品研发上线后后，对产品和研发团队来讲就是完成了一个里程碑，技术团队很在意自己的努力付出获得了什么样的成就。在没有高深技术攻关的情况下，研发对业务的帮助就成了他们最大的成就来源。而作为产品经理，告知他们劳动成果实现的业务指标。可以很好的安抚、激励他们的动力；另外，技术人员很注重规范性，项目/产品上线后有明确的产出结果，也符合他们做事有始有终，周而复始的习惯性思维。
二来，产品经理通过分析数据、给出产品后续的方向和计划；比较容易确立自己的专业权威。数据好的时候可以明确告知技术团队为什么好，产品功能在这其中发挥了多大作用（精神兴奋剂）；数据不好的时候可以找出原因，告诉他们下一步优化的方向和计划是什么（指路明灯啊！）。
这一来二往中，产品经理就慢慢在研发团队确立了自己的“无授权领导力”……
第四级：季度（月度）总结
在实际运作中，产品研发项目的延期，并不仅仅是需求变更、需求理解偏差造成的。运营/营销/BD等业务条件的变化甚至局限，都会影响产品实现方案的变更；而前期的系统（设计）架构（也就是所谓的技术债务）、研发人员不同的技术水平限制导致的实现方式变更，都会引发项目的延期和研发质量的降低。
因此，这一级沟通的主要目的是形成共同的工作模式/习惯、调和业务、产品、研发的协奏，磨合研发团队内部技术水平、提升团队效率。
一般情况下基本是产品总监在推动。当然，产品经理也可以定期跟自己对接的团队做总结报告或项目总结，具体形式也可以灵活一些，但需要注意以下要点。
主要目的：总结经验传承，改进不足，快速提升团队协作效率。
参与人员：协作团队所有成员。
会议形式：项目/季度总结会
主要内容：业绩（比如完成什么项目，业务数据有什么提升）、过程分析（哪些做得好、哪些需改进）
注意事项：褒贬平衡、集体参与（要避免过度吐槽会和个人攻击的情况）。否则，不管是项目总结还是季度总结，都会造成团队的不稳定
构建这四级沟通计划后，基本就能保证业务和团队同步的螺旋式上升。
转载请注明：好现场 » 团队的沟通计划和协作方法