B端产品经理如何掌握主动权，推荐你做好这三点

可能有些朋友不了解B端产品交付方式，我先给大家讲下目前主流的两种交付方式，B端产品提供给客户使用，目前主要有两种方式。

一种是最近几年非常火热的SaaS模式，它是基于云的应用，可以授权给企业、组织或者个人进行使用，通过公共网络访问使用。

另一种是较为传统的本地化部署模式，也就是把应用产品部署在客户的服务器，产品必须通过客户专属网络才能访问，确保应用以及数据的安全性。对于安全性要求比较高的企业，比如银行和政府等企业的核心系统基本会选择这种交付方式。

目前我在做的现场实施项目就是属于第二种，需要把本身具备一定成熟度的产品在客户现场的服务器进行部署，按照客户的规章流程进行办事，在产品本身的基础上再迭代客户定制化的需求，最终按照合同签订的项目功能范围进行项目验收结束。

从2021年3月底开始，我全程参与了我们公司活动营销平台项目的实施，如今项目一期实施已经完成验收，项目二期的合同已经签订并开始。

在这一年多的项目经历中，我踩了不少坑，踩坑的过程中难免痛苦，但回头想想也正是因为踩过坑的痛苦激励我进行反思，才加速了我个人能力的成长。

如果你问我踩过的坑里面，哪些是我最难忘的？我会和你说是需求范围蔓延、轻易承诺被打脸以及生产问题处理手忙脚乱。

下文中我会逐个进行分析，我相信这三点不仅是在现场实施过程中会遇到，在做B端产品很多朋友也有可能遇到。如果你也遇到了类似的情况，希望能给你帮助。

一、需求范围控制

可能有些朋友对于需求范围控制有点不理解，简单来说就是客户需求超出签订合同的约定范围，这种情况出现很有可能会造成项目利润减少甚至亏损。

针对项目制的产品交付，在双方达成合作意向后，会在签订的合同内明确需要交付的需求功能点清单以及系统要求等内容。可以说把合同内的功能点上线完成达到合同要求后，项目就可以进入交付验收阶段，验收通过后客户就会把合同尾款付给公司，那么项目也就做完了。

所以从负责项目实施的乙方公司而言，自然是想办法在合理的人力成本范围内，尽快完成需求功能点的上线，确保项目利润可观。

但是风险点在于在签订合同的时候需求大多只有几句话的描述，需要等到真正实施过程确认需求后，才能知道实现方式以及实际工作量。

需求是由客户方提出及确定的，受外部环境变化影响。

客户的需求并不会跟随合同一成不变，而是会在合同需求的基础上进行调整甚至变更，这本身是无可避免的，但是对于项目来说就会带来不可控因素，如果把控不好就会导致项目亏损。

说实话，项目成本以及项目实施周期这类问题大多是公司领导或者项目经理需要承担的事情，但是产品经理作为需求的具象化以及项目的关键角色，其实是需求范围把控的关键人员，我们需要关注这件事情并通过自己的方法把控需求范围，才能和领导以及项目经理进行顺畅沟通，也有助于自己未来的职业发展。

需求范围蔓延这种情况其实并非不可预见，往往在双方合同签订时，会协商预留一部分预算用于开发合同外的需求。

既然需求蔓延不可避免，那么产品经理作为把控项目实施范围的关键角色，可以做些什么呢？

可能大家会觉得控制需求范围是项目经理在开发阶段需要负责的事情，其实并不是的，从成本角度来控制需求范围必然会存在一定滞后性，而这种滞后性会增加项目的成本。

当需求确定后，往往客户对功能已经产生一定的预期，如果发现预期工作量超标再让客户调整需求，势必会让客户感觉不爽，甚至可能会口头说我们不专业。更不用说，实际工作量远超预期工作量的情况。

实际上应该由产品经理从需求调研时就开始控制，其次才是开发环节控制。

需求调研前，产品经理需要熟悉合同需求范围，如果知道需求大致工作量更好。只有我们自己了解合同的需求范围才便于进行把控，如果能参与项目合同范围拟定当然最好，如果是后期介入则需要熟读项目合同。

熟悉后便于我们在需求调研的过程中能对客户提出的需求进行识别，到底是合同内还是合同外，合同外的需求需要识别，与项目经理进行信息同步。

需求调研时，可以适当发散，但要具备可落地性。适当发散的关键在于不能过于限制客户提出需求内容，不能在最开始聊需求的时候就开始想着能不能实现，不能实现或者有难度的都建议客户调整需求，调研目的在于需要客户多提供些信息以便于我们挖掘需求真正的目的，而不是实现方式。

知道需求背后的目的后，便于我们针对目的提出我们的解决方案，而不是被业务牵着走。

具备可落地性是需要我们把控整体情况，不能任由客户漫无边际地提出实现方案，在进行具体需求设计的时候需要在具备可落地性的基础上进行讨论和细化需求。

在一次沟通需求的过程中，客户提出想要实现活动在小程序及手机App用户都能参与的需求，我当时评估需求实现难度较大，提出能不能只在手机端实现。

客户听后就不满意了，说为什么不能实现？目前已有的活动模板是在小程序进行的，而我们目前活动都支持在手机App参与，如果放弃小程序很多客户参与都不方便，那么活动的参与人数肯定会受到影响。

在我了解到客户的目的后，冷静想了下虽然实现有难度，但是并不是一定不能实现，客户的诉求并不过分，于是我便回复我明白了，我们继续沟通其他需求，具体实现在开发阶段进行评估。

需求调研后，发现开发难点及时沟通确认调整，给出理由及备用方案。前面提到了成本角度的滞后性，但是如果在开发过程中发现了问题需要调整实现方案。要敢于和客户进行沟通确认，很多时候客户虽然不爽，但是我们讲清楚原因和备用方案后大多都会理解同意调整。

在和客户沟通的时候，需要注意沟通方式。我总结的沟通框架是：目前遇到问题描述+问题导致的影响分析+调整方案描述+调整前后方案对比效果。

比如我最近做的一个需求，需求方案确定后需要调整方案。于是我找到客户说明，在开发过程中发现活动发布后编辑事件规则会导致数据错乱，这是需求设计过程中未考虑到的。

如果按照目前的方案上线后，可以预见会有很多客户的记录可能会丢失导致客诉。和开发人员讨论后的建议方案是限制运营人员在活动发布后修改事件规则，没有其他可行方案了。

这样调整虽然会导致活动发布后无法变更事件规则带来操作不便，但可以通过人工确认的方式规避问题出现，而且能够保证客户的数据不丢失，从而避免客诉。

客户听了我的描述后理解了出现的问题、解决方案以及影响面，同意进行需求调整。

二、不轻易承诺

如果要说在项目过程中踩过最惨痛的坑，那肯定是轻易承诺上线时间。

在和客户沟通完需求后，客户往往会追问一句，这个需求什么时候能够上线？当时缺乏”社会毒打”的我往往会根据自己对项目的了解情况，脑袋一拍给个上线时间。我想的是给个大概的时间，朝着这个目标去努力。后面我发现客户并不会这么认为，他会把我提供的时间当成确定的时间，甚至会上报给他的领导。

这种情况下我给的时间节点会成为上线的倒排时间，弄得自己和同事身心疲惫，这种情况下如果遇到难解决的生产问题就会打乱节奏，从而影响上线时间节点，整个项目的计划都会被打乱。

如果没有按时上线约定功能，客户会找到我们要个说法，为什么承诺时间做不到？这会给到项目组压力，催促我们尽快完成功能上线，于是项目成员往往需要加班加点完成工作，而往往这个时候更容易出现问题。

最后可以发现，因为我拍脑袋给出客户的上线时间，不仅让项目组上线压力增加，而且还让客户面临领导的苛责，会造成我本人信用度的降低，甚至影响后续项目的工作开展。

为什么客户会找我这个产品经理提供上线时间呢？

我想了下，首先是因为产品经理和客户的沟通频繁，客户对于产品经理的熟悉程度和信任程度较高。其次是客户需要了解功能上线情况做好工作安排，最后客户是想要一个保证，保证需求上线的时间节点和自己的预期一致，实际情况是我们没办法保证，因为具体上线时间由客户方项目经理确定。我在当时提供上线时间一方面是想满足客户的预期，另一方面是想证明项目组的能力，只是当时没想到会搬起石头砸自己的脚。

记得今年5月份有次项目晨会，之前我评估是5月底能上线的。因为时间评估有偏差，导致该功能要延期在6月的版本上线。于是客户就不满意了，说每次你们评估的工作量都不准确，我都通知客户在端午节进行领取了，结果你们说功能上线不了，这个责任我没办法承担，你们也承担不了。这个情况我不满意，你们最近加班赶下进度，务必要在5月底上线。

整个项目组经过持续一周的加班才赶上进度，虽然按期上线了，但是同事们那段时间都很疲惫，也影响了后续功能的开发效率。

经历过几次惨痛的教训后，我下决心改掉轻易承诺的毛病，想办法提高自己的专业性，经过一段时间的摸索后，我找到了自己的应对方法。

现在当客户问我需求上线时间的时候，我会按照以下三个步骤进行处理：

先反问客户的预期时间是什么时候，以及为什么是这个时间节点。如果是个人意愿的原因可以尝试进行说服，如果是外部不可变条件限制那就需要及时和项目经理同步信息，提前进行风险管理。
根据目前项目的计划告知预期的可实现性，如果存在风险我会和客户说明风险点，先降低客户预期，让客户提前做好风险预案，避免后续因为未按预期上线导致的手忙脚乱。如果具备可能性，我会和客户说，目前看具备可行性，具体需要和开发同事确认需求后进行工作量评估再给出答复。
客户如果再追问时间，我会说明即使我现在给出上线时间，也是我拍脑袋给出来的肯定不准确，而且还有可能会打乱项目计划。具体时间等我们明确需求后再评估相对可行的时间。

听起来可能会感觉有些圆滑，但是这确实是我踩过坑后总结和使用的方法，也确实有效。不轻易承诺并不是学会圆滑，而是在降低客户对于上线时间节点的预期，保持项目组的信用度，便于双方长期合作。

有次在沟通活动模板的需求过程中，在沟通完具体需求后，业务又来问我大概的上线时间。

我回复说你的预期是什么，是要配合某个大型活动吗?

客户说是的，最好是在10月份上线，我希望在国庆节用这个新的活动模板上线新的活动，这样既能满足节假日上线活动的目的，也能给客户带去新的玩法。

我回复，那我明白了。目前项目有两个需求推进中，如果按照目前开发进度10月份上线会存在风险，是否有其他备用方案呢？比如用现在的活动模板举行活动。

客户说没有备用方案，这也是领导要求的时间点。那按照目前的开发进度，你估计什么时候能够上线?

我说，这个时间我这边目前给不出来，你的诉求我基本了解。我整理下最近准备开发的需求，我们估计要调整下需求优先级，确定需求优先级后我和开发同事一起评估开发计划后，在本周三下午给你反馈具体时间。

这时候客户理解的具体情况，大多会接纳我的意见，后续只要我们按照约定的时间给出开发计划即可，有开发计划后便于进行具体的沟通。

三、生产问题处理规范化

生产问题处理无疑是我最头疼的问题。

因为生产问题它不可控，它出现的时候往往没有迹象，而且需要尽快解决，但是想要解决需要项目组成员花费时间和精力，遇到难解决的问题耗时较多无疑会影响项目后续的开发计划，影响项目整体进度。

经过这一年多在客户现场与生产问题的“交手”，我发现解决问题的最重要的并不是马上响应，而是对生产问题保持平常心，保持平常心的意思是对于生产问题的出现无需感到意外，更没必要因为生产问题手忙脚乱，内心急躁，只有对生产问题保持敬畏心和平常心我们才能冷静地分析问题，尽快查找问题出现原因并解决问题。

按照我个人的经验，我会把生产问题归为三类，分别是人为问题、设计问题以及系统问题。

第一类是人为问题，就是由操作人员错误的操作行为导致的。常见的原因是操作人员对于系统不熟悉或者操作过程不细心。如果分析问题后发现是人为问题，首先需要想办法修复数据，恢复系统正常。然后分析问题出现的操作过程，对操作人员进行培训或者建立操作检查规范，甚至可以增加审核流程用来规避人为的导致的问题。

第二类是设计问题，就是在需求设计或者开发设计的过程中影响考虑不充分，导致系统出现问题。这种情况常见的出现节点是上线后出现问题，这时候可以通过回退旧版本暂时解决问题，然后再针对出现问题的部分进行优化迭代。如果是上线一段时间后，因为功能设计不完善导致问题出现，短时间内就需要在开发层面先定位和解决问题，然后尽快优化需求或开发设计方案，安排版本更新解决问题。出现这种问题，就需要想办法在需求设计或开发设计阶段规范流程，增加设计方案考虑场景，提升项目成员专业程度从而避免问题出现。

第三类是系统问题，就是系统本身出现的问题。比如服务器压力较大或者数据库出现问题，那就大多需要从系统或硬件层面去定位和解决问题，通过增加服务器或扩充数据库容量解决问题，或者通过优化代码性能解决问题。这种问题大多是开发同事需要考虑优化的，作为产品经理需要了解问题出现以及解决情况，在后续做类似需求过程中进行考虑。

讲完分类后，和大家讲下我排查问题的思路。

当出现生产问题后，首先是对问题情况进行描述，了解大致情况。然后是和操作人员（或客户）确认操作流程，确认操作流程无误后，开发同事查询具体操作时的系统日志定位问题。大多数情况就能定位到问题出现的原因，如果查询不到日志情况那么定位问题以及解决问题花费的时间就会增加。

定位到问题后，首先可在测试环境尝试是否能复现，如果能够复现那么大多是代码问题，如果不能复现那么很可能是不同环境带来的问题，具体情况就需要排查。

其次是评估问题的影响面，有多少数据或者客户受到了影响，影响的结果是这样，会造成多少损失。

最后是项目组成员讨论给出问题解决方案，解决方案最好能在测试环境进行验证，验证无误后再安排版本上线。

如果是因为生产问题造成客户损失，需要进行道歉并做出相应的解释，如果损失较大还需要给出客户的补偿方案。

在问题解决后最好还与问题相关同事召开问题复盘会议，回顾问题出现的原因、问题排查和解决过程，降低后续相同问题出现的可能性，提升问题的处理效率。

出现问题并不可怕，怕的是手忙脚乱导致更大的问题。我们可以告诉自己，出现问题解决问题就好。当然每个产品情况不同，我提供的流程只能作为参考，推荐你按照自己产品的实际情况，制定解决问题的流程。