与业务方的六大分歧

主导权分歧

在B端产品领域中常常由业务方主导需求。之前做C端产品的产品经理，心理上会非常不适应，想当年大权在握，指点江山，如今却成了一个工具人，天天听别人使唤，一点成就感都没有。

专业性分歧

“人人都是产品经理”这句话的字面含义已经出圈了，这句话在人们心中造成了产品经理门槛很低的错觉。导致业务方对产品经理这个岗位存在认知偏差，甚至有些人不再信任产品经理的专业性，不愿接受产品经理的意见，破坏了合作根基——信任。同理，如果产品团队在合作中开始质疑业务方的专业性，那后续的合作也很难正常进行。这就是双方的专业性分歧。
不过，我们也不能因此就完全否定业务方的这个观点，因为一方面这个岗位确实存在浑水摸鱼的南郭先生，坐实了对业务方的偏见；另一方面，从主导需求这点来看，他们也确实承担了一部分产品经理的工作；再者，不同公司对产品经理这个岗位的定义本来就不同，所以无法从定义上裁定业务方的认识是否正确，只能从工作内容上做区分。
【PS：工作内容也不好切割】

合理性分歧

是指双方对需求的合理性存在分歧，公说公有理，婆说婆有理，争执不下，这是多个参与方共同制定需求时必然会面临的问题。由于双方立场、认知的巨大差异，仅仅通过讨论无法确定孰对孰错，双方都很难完全接受（甚至理解）对方的观点，最后只能按照业务方的要求进行产品设计，等待用户和数据的验证。

变更分歧

产品经理随意变更需求是大多数开发人员的梦魇，到了B端产品领域中，产品经理终于也体会到了业务方随意变更需求带来的痛苦。
无论是业务方还是产品经理，都知道随意变更需求对项目进度、质量，以及开发人员的心灵造成伤害，但很多时候这其实是因为一些客观因素导致的无奈之举。

需求思考不充分。制定需求时思考不够细致、调研不够充分，导致需求有Bug，这是需求变更最常见的原因。
业务调整。B端产品作为业务赋能的工具，自然要随业务调整而改动，而且越不稳定的业务，变动风险越大，这是业务方需求变更“最硬气”的原因。
领导要求。有的需求业务团队和产品团队都确认了，但可能半路杀出个程咬金，因为业务方领导的一句话而改变需求，而且我们大多数情况下还改变不了领导的意图，这是需求变更最无奈的原因。

工作量分歧

每次将各个需求评估的耗费时间同步给业务方时，总会听到他们抱怨：“这么小的一个改动，为什么要那么久？”以至于每次迭代做不了多少需求，有的业务方甚至可能会怀疑我们在“忽悠”他们，但苦于他们没有自己评估需求工作量的能力，只能眼巴巴地看着干着急。

节奏分歧

无论是敏捷迭代还是瀑布式开发，产品更新都有一定的“版本节奏”，即每个版本的上线时间是有要求的，但很多业务方则希望的是今天提的需求，明天就上线，希望开发团队能够快速响应，随时修改、随时发新版，这就是版本节奏与业务方期望时间的分歧。
在这六大分歧中，有的是无法避免的，如节奏分歧；有的通过沟通是可以达成共识的，如工作量分歧。为了降低这些分歧对合作造成的影响，我们应该与业务方建立良好的合作机制，共同推动项目顺利进行。

共建合作机制

合作中需要多方共同参与和努力，必定人多事杂，所以一定要提前制定好清晰明确、可落地的合作机制，才不会在执行过程中乱了阵脚。这个机制用一句话概括就是：事前定原则，事中建机制，事后细总结。

事前定原则

在确定了合作关系，合作正式开始前，双方应该就合作中的基本原则达成一致。
1）平等尊重，相互信任
平等尊重，相互信任是所有合作的基础。一方的高姿态容易导致另一方的态度消极，即使双方在职级上虽有高低之分，但在合作中，应该平等相待，否则难以让另一方充分发挥其主动性和专业能力，最终在合作中“隐身”。信任是对对方最大的尊重，如果连信任都没有，合作就无从谈起。
2）目标一致，倾力投入
业务方与产品团队有缘组成一个新团队，自然是因为一个共同目标，双方应该基于这个目标，携手同行，在力所能及的范围内为对方提供帮助，积极贡献力量，不应因为某些利益、立场的冲突而把对方推向对立面，这对共同目标的实现有百害而无一利。
3）管理预期，兑现承诺
与其前期承诺太多做不到，不如承诺得少，并全都做到。在与业务方沟通时，无论是产品经理还是项目经理都不要因为业务方给的压力或为了显示团队实力而向业务方承诺太多，合作中最重要的不是满足多少需求的问题，而是信誉问题，爽约比做得少更严重。所以在合作中要学会管理对方的预期，慎重承诺，以免失信于人。
4）预估风险，提前告知
在需求开发过程中，有的需求会因为某些原因无法及时上线，尤其是在需要依赖第三方支持时，就会存在较大的不确定性和很多未知的风险，针对这类需求，我们需要提前准备，提前与第三方沟通，了解细节，并提前告知业务方可能存在的风险点和应对方案。同理，当业务方有需要配合的事情但可能存在风险时，也要提前预估并告知产品团队。
5）调节心态，积极面对这里的调节心态包含两个方面。
（1）保持谦虚和敬畏
拥有对产品的主导权，确实能给人很强的成就感，满足人的控制欲，这是人之本性。但主导权越大，意味着责任越大，产品经理制定的每个规则、确定的每个需求，都会对团队和用户产生很大影响，这就要求产品经理时刻保持敬畏之心，在制定这些规则时将其中的利弊分析得足够清楚，但要想做到这点不仅需要极强的综合能力，还需要足够丰富的信息辅助决策，如果业务方明显更有优势，那我们就应该以谦虚的态度，接受业务方的建议，这才是真正对产品负责的态度。
（2）直面困难
合作的过程不可能是一帆风顺的，难免有些磕绊，作为产品经理除了要找到问题并加以解决，还要能够保持良好的心态，以应对合作中的种种困难。

事中建机制

双方就合作原则达成共识后，到了执行阶段，就要用具体的机制来落实之前制定的合作原则。
1）紧密沟通机制
及时有效地沟通是合作中最关键的部分，也是决定合作成败最重要的因素。为了保证双方对沟通的重视、信息能够及时互通，我们需要制定“灵活+定期”并举的沟通机制。
灵活的沟通机制是指双方就工作中遇到的各种问题、要求随时同步、随时讨论；而定期沟通机制则是更为正式的多方会议，如每周例会，目的是让相关方每周预留出固定的、足够的时间就一个或多个议题展开详细深入的讨论，避免各方的时间不同步，同时也是通过这种形式，向各方暗示这项工作的重要性，以免时间长了心理上产生懈怠。在达成“里程碑”后的例会中，还可以邀请各方主管领导参加，汇报项目的阶段性进展。
我们定期沟通的时间可以根据产品阶段进行调整，如产品从0到1的阶段可能一周需要开两次会，产品比较完善后，可以每周开一次会，并逐步降低定期沟通频率。
2）事项跟踪机制
在双方合作过程中，并非所有事情都是需求问题，还有很多其他需要跟进的事项，如在HRM系统上线前，需要HR准备好人员信息，初始化时批量导进系统。当双方事情比较多的时候，很容易遗忘，而一旦重要事件遗漏，就会直接影响项目进度。所以日常事务要建立专门的跟踪机制，便于双方跟踪记录，形成约束力。项目的每个里程碑，都可以记录在事项跟踪表中。
在这份《事项跟踪表》中，需要区分事项、需求、Bug三类，这里特别说明一下需求和Bug。

需求：这里的需求与我们需求池中管理的需求不同，是记录业务方着重关注的需求，目的是与其他对业务方而言比较次要的需求进行区分，告诉业务方这些重要需求的进展情况。 Bug：这里特指正式环境中的Bug。虽说每个产品或多或少都有些Bug，尤其是刚上线的产品，但它其实是最影响用户满意度的因素，每个Bug都是前文提到的“峰终定律”的低谷区，所以需要特殊对待、优先处理。

3）需求评估机制
需求确定后，业务方通常就会问某个需求需要多久完成，或者到某一个时间点，产品能做到什么程度？遇到这类问题时，产品经理一般都无法直接回答，即使有开发经验的产品经理或是项目经理，也不建议当场答复，因为同一需求，理解不同、经验不同的人完成时间是不同的，而且很多“隐藏的坑”只有开发人员才最清楚。
所以对于这类问题，我们可以采用精益敏捷中集体估点的方式，由开发团队在需求评审时对每个需求集体评估工作量，同时，根据现有人力，评估一次迭代的需求总容量，最后结合优先级、迭代节奏来答复业务方。针对需求评估已经有非常成熟的方法了，此处就不过多叙述了。
这种方式的好处是，产品经理不仅能清楚地知道完成每个需求所需的时间，还能在后期与业务方结算时有数据支撑，增强说服力。
4）需求变更机制
产品进入开发阶段后，最怕的就是业务方随意变更需求，这不仅会影响开发进度，还会影响团队士气，打乱迭代节奏。但想完全禁止业务方变更需求也不现实，无论他们多么了解业务，也无法保证提出的需求一定是其最后想要的，所以我们的原则是允许他们变更需求，但不允许随意变更。要想做到这一点，就要建立需求变更机制。
仅上线确定需求。如果部分需求无法在迭代前确定，那么宁愿这部分需求延期，也不要匆忙上线，因为这些需求常常隐藏了太多未知的风险，匆忙上线不仅浪费开发资源，还容易产生未知的Bug，影响用户体验，损害产品形象。

建立变更窗口。需求未进入迭代前，是可以随意变更的，一旦进入迭代，原则上就不再接受需求变更请求，所以我们要及时与业务方同步迭代计划，让他们知道在哪个时间段可以变更哪些需求。
填写《需求变更申请》。如果变更内容对正在做的需求有比较大的影响，通常按照第一条原则处理，即作为不确定需求延后。但如果这个需求的优先级很高，如这个功能下周要向上级领导演示了，对于这种特殊情况，出于维护双方关系的目的，我们可以允许其变更，但需要业务方填写正式的《需求变更申请》，这么做的目的一方面是增加变更成本，让业务方在填写时对需求思考得更清晰，更加慎重；另一方面是为了存档，作为以后“讨价还价”的筹码。变更申请主要内容包括变更时间、变更人、变更前需求、变更后需求、变更原因、变更影响等，形式上可以是一封全员通知邮件，也可以是一张表格。
争取时间。需求变更常常会增加额外的工作量，对上线时间产生影响，所以需求变更后我们要尽量向业务方争取更多的时间。
预留变更空间。为了应对可能的变更，我们在每次迭代中要设置几个中优先级的需求，当有需求变更时，就可以将中优先级的需求顺延，腾出时间做变更需求或修改紧急Bug；当没有需求变更时，就正常完成每次迭代的任务。

5）信息存档机制
在与开发人员的合作中，有时会听到开发人员吐槽产品经理说话不算数，自己曾经信誓旦旦对他们承诺的都不记得了，导致产品经理在开发人员心中的形象不佳。
笔者曾经合作过的一位开发人员就比较聪明，为了抓住我的把柄，他在吃过几次亏之后，每次线下跟我沟通确认一个需求后，会在聊天工具中把这个结论写下来发给我，让我在线上再确认一遍，以此作为信息存档。
与这个例子相似，这个问题在产品经理与业务方合作时同样存在，有时业务方开会时随口一提，产品经理就照做了，等功能上线后却被业务方质疑没有按照要求来做，这时如果没有证据证明业务方曾经提过这种要求，哪怕你一肚子委屈也无处申辩，所以为了避免这种情况，双方在合作中要建立信息存档机制。

形成会议纪要。每次会议结束后要形成会议纪要，抄送相关方知晓并确认，它不仅能帮助我们回顾、记录信息，还能训练我们从冗杂的信息中抓重点和逻辑梳理能力，这两个能力对产品经理来说很重要，所以各位产品经理不要因为偷懒而忽略这一步。重要信息电子化。在沟通中有些重要决定是通过线下或电话确认的，为了避免后患，可以通过邮件或线上沟通渠道再次确认存档，如果关联方较多时，最好通过邮件告知，这样会更加正式，也容易查找。

事后细总结

每个合作都是独一无二的，每一个过程都是值得回味的，每一份付出都是需要买单的。到了一个阶段结束时（不是项目结束），我们就要对内、对外细致地总结一番，为新的合作阶段做铺垫。

对内，经验沉淀。将在合作过程中做得好的地方当作经验沉淀下来，形成方法论，对于复用性强的，还可以推广到更大范围中，供其他团队学习；对合作中待改进的问题，分析问题原因，找出解决方案，并争取在下一阶段中改正。对外，投入结算。定制化阶段的产品，无论是否有直接买单的业务方，都要根据投入进行结算，以衡量投入产出比，其中很重要的基础就是前面提到的需求评估机制，它可以帮助我们量化投入。

业务方的分类及应对方式

根据业务方的强势程度、配合程度两个维度，可以将他们分为头狼型、绵羊型、“和稀泥”型和“鬼见愁”型四种类型。

强势程度，是从业务方在产品发展、功能设计、需求、迭代排期等方面要求的强硬程度、可商量余地及介入产品深度这些方面进行考量。配合程度，是从业务方是否愿意接受、听从产品团队的专业意见，沟通、协助响应是否迅速、及时这些方面进行考量。

头狼型的业务方

1）特点
这类业务方在合作时虽然比较强势，但也愿意配合你的工作。
他们控制欲强，喜欢根据自己的专业背景引导产品发展，会主动思考与产品相关的问题，提出很多好点子，同时强调团队合作，愿意与产品经理协作，听从产品经理的建议，就像狼群中的头狼，凶狠坚定而又强调团队精神。
虽然你与他们合作时会感到压力比较大，但从最终目标来看，这类业务方其实是最理想的，因为他们的强势对应的是一种高要求，能够帮助团队克服人性中的惰性，从而提升产品质量；同时他们的强势也可以帮助产品更好地推广，是最容易出成果的一类业务方。这类业务方多见于一些比较开明的管理者。
这类业务方的不足之处是，在合作中容易越界，挤压产品经理的决策空间，给团队比较大的压力，有时因为不了解产品的相关细节，做出一些不合适的决策。
2）应对

提升专业性。通常来说，业务方的强势程度与产品经理表现出的专业性成反比。产品经理表现出的专业性越强，业务方的态度就越柔和，所以你想让头狼型业务方让渡更多的决策空间，就需要更强的专业性做支撑，这是你平等对话的基础。这里的专业性并不是指在业务上的专业性，而是作为产品经理专业能力方面的专业性，如需求分析、用户分析、产品设计等，是你作为产品经理的核心能力。
定原则，树边界。在具备专业性的基础上，我们需要跟头狼型的业务方确定原则，确定双方的工作边界，以约束对方的行为。

绵羊型的业务方
1）特点
这类业务方在合作时相对比较弱势，也愿意配合你的工作。他们不会强硬地要求你做一些事情，如某个功能不好实现，他们不会逼迫团队必须完成。在合作中会将主导权交给产品经理，同时会根据产品经理的引导提出需求，配合做相关工作，对产品经理来说是合作起来最舒服的一类业务方。
这类业务方的不足之处在于，需要产品团队主动、频繁地引导，以保持其对产品的热度，否则容易变成第三种——“和稀泥”型的业务方。
2）应对
积极主动引导。为了保持这类业务方的合作积极性，我们需要经常通过线上方式和线下方式与对方沟通，建立联系，这也是前文提到的建立定期沟通机制的原因之一。
提升对方的重视程度。业务方表现出的弱势除了与业务代表的性格有关，还与业务方对合作的重视程度有关，如果是因为业务方不够重视产品发展而表现出的弱势，则要想办法适当提升他们对产品的重视程度。

“和稀泥”型的业务方
1）特点
这类业务方在合作时不强势，但也不太配合。他们的控制欲望不强，但因为工作太忙，或个人意愿不强等原因，也不愿意被产品经理带领，对合作会显出“和稀泥”的态度。
这类业务方是不太理想的，面对此类业务方，产品经理大多都会显得有心无力，难以推进合作进程。
2）应对
强化责任意识。对于这类业务方，需要特别强调双方的责任范围，以强化他们的责任意识，使其共同推进合作进程。
说明风险。很多业务方之所以在合作中和稀泥，是因为对合作不重视、不上心，甚至有排斥心理，此时产品经理要和对方说明利害关系，通过警示促进双方合作。
上升风险。对于直接沟通仍没有改进的合作方，需要尽快将此作为重大风险，上报双方领导，共同解决，如果对方领导也不重视这个问题，那么最好先暂停这个项目，否则这个项目最后极有可能变成“烂尾项目”。

“鬼见愁”型的业务方
1）特点
这类业务方合作的方式就是——我不要你觉得，我要我觉得。他们不仅强势，还不愿听取产品经理的建议，喜欢一意孤行，做决策时不考虑客观情况，只要结果，不管过程，对产品经理来说是最不理想的业务方。
2）应对

尝试沟通。这种业务方多见于不懂产品开发又不愿放权的管理者，遇到这种业务方，可以尝试与之沟通，耐心说明产品设计、开发过程中的难点、客观限制，甚至可以邀请其参与迭代过程中的某些环节，如需求评审、工作量评估，让这类业务方更深入地了解开发中的难点，以便相互理解。
要么忍、要么撤。如果有的业务方不愿沟通，或即使了解了难点也不愿转变态度，那么开发团队只有两条路：要么忍到项目周期结束，要么及时撤离。如果你选择了忍让，就尽量避免与之正面冲突，否则费力不讨好，这就不划算了。
及时排解负能量。人非圣贤，当遇到不太理想的合作伙伴时，难免会积压一些负能量，所以为了你的身心健康和工作，最好找到适合自己的方式排解。

与业务方的协同