B端产品工作不易，尤其是没有相关经验的新人，难免会踩坑。为了不在同一个坑摔倒两次，就需要及时复盘思考，针对问题给出解决方案。本文作者总结了自己在B端工作中的项目经验，与你分享。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　做B端产品并不是件轻松的事，没有相关经历的我们难免踩坑，但最好我们要争取相同的坑不踩两次。这就需要我们在踩坑后及时复盘思考，思考问题出现原因，并针对问题制定解决方案，想办法降低下次踩坑的概率。

　　想要控制好项目的需求范围，需要我们深度参与到项目实施的过程中，不让自己被产品经理的角色限制，把项目保质保量地交付作为我们的目标。

　　不轻易承诺不只是对自己负责，也是对客户负责，更是对公司负责。承担责任并不轻松，但是只有承担更多的责任后，后我们才能有更多的成长机会。

　　其实生产问题并不可怕，因为它一定会出现。保持平常心能让我们更好地定位问题以及解决问题。

　　最后我想和你说，文中说的这三点并不只是在交付项目过程中会遇到，在做其他B端产品的时候也会遇到，希望文章中的方法能给你一些帮助，内容较多，感谢你阅读完。

　　本文由 @树园聊B端 原创发布于人人都是产品经理，未经许可，禁止转载。

　　题图来自 Unsplash，基于CC0协议。

　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

　　在搭建组件库时，组件设计师和其他设计师之间，应该怎么配合呢？组件设计的工作模式又是怎么样的？本文作者从独立生产、集中生产、联合生产这三个方面，对搭建组件库的模式进行了分析，希望能给你带来帮助。

　　一位同学和我说她最近也在尝试搭建自己产品的业务组件库，但是有一个困惑：

　　“搭建组件库并不是一个简单的工作，甚至可以说是很繁重，那么是不是我应给专职只做设计组件库这一件事情呢？但我现在还需要做产品需求，感觉时间已经很紧张了。

　　我想知道，组件设计师和其他设计师之间应该怎么配合呢？组件设计的工作模式应该是怎么样的呢？”

　　搭建组件库的工作模式有很多种，我在本文会为你介绍三种模式：独立生产、集中生产、联合生产，相信也会对你有帮助。

　　“独立生产”是指对于一个团队来说，安排某位业务设计师作为唯一的组件生产者；或者对于一个企业来说，安排某个业务设计团队作为唯一的组件设计团队。

　　这种模式下，这位业务兼组件设计师做出来的组件既在自己做业务需求设计时使用，也服务于其他的业务设计师或团队。而其他的业务设计师或团队则会提供组件设计需求给这位业务兼组件设计师，进行组件库的更新和优化。下图以一个团队的独立生产模式为例：

　　这种协作模式看上去可行，但也有一些弊端：

　　由于是这位设计师根据自己的业务需求来做组件，做出来的组件资产可能适应不了其他设计师的业务需求。他人在使用的时候，可能会需要大量的修改和定制，或是提出组件优化和调整的诉求。

　　由于这位组件设计师也需要做业务设计，所以必然没有办法分出太多的精力去研究和细化组件的细节；也不太可能去编写完整的规范约束组件的使用方式；甚至是接到其他业务设计师提出的组件新增和优化的需求也未必会全部受理。

　　工作任务：

　　“独立生产”的模式比较适合相对成熟和稳定的业务组件库，没有太多组件需要从 0-1 进行新增设计，各业务线及设计师也已经对组件有了较高认可并能够熟练应用。这种协作模式对于这位业务兼组件设计师的能力要求比较高，对组件库需要兼顾设计与管理。其工作职责包括：

　　负责组件需求的收集、评估和排期组件需求的定义、分析与研究组件设计成果和使用规则的产出组件在开发上线后的质量验收组件和规则的评审、发布与信息同步等

　　“集中生产”是指对于一个团队来说，安排专职设计师作为唯一的组件生产者；或者对于一个企业来说，安排某个专职设计团队作为唯一的组件生产团队。这位专职设计师或专职设计团队不依附于任意的一条业务线，不承接业务需求。下图以一个团队的集中生产模式为例：

　　这种协作模式的好处是：

　　1）组件专业度高

　　由于设计师是专职做组件，组件的生产质量和设计深度就得以提升。不论是在组件设计的质量还是在使用组件的流程上，都可以做得更好。

　　2）组件通用性高

　　由于不参与任何业务需求，组件设计师可以更加平等地审视各个业务的组件沉淀和优化需求，一般不会偏重某个业务，而是站在通用性的角度做组件生产。

　　但这种协作模式也有弊端：组件业务性弱。

　　由于不接触业务需求，专职的组件设计师做出来的组件可能并不“务实”，过于理想化。组件在实际业务应用中可能会“不接地气”，没有那么贴合业务需求，或者在解决实际业务过程中仍然考虑得不够周全。

　　工作任务：

　　“集中生产”的模式比较适合从 0-1 刚刚搭建的组件库，或者是业务属性不强的通用基础组件库。专职的组件设计师的工作职责不仅仅包括以上我们提到的几点工作内容，还包括：

　　对于组件库做建设管理和发展规划主动提升组件自身的设计质量主动思考如何从组件侧如何赋能业务，提升产品易用性和使用体验主动提升组件的使用体验，以体验度量和检测等方式确保组件被高效、正确地使用

　　“联合生产”是指对于一个团队来说，安排几位业务设计师同时承担一部分组件生产的工作；或者对于一个企业来说，其中的几个业务设计团队都需要派出 1-2 名业务设计师组成一个组件生产团队，大家一起建设组件库。

　　这也需要找一名有组件库建设及管理经验的设计师作为负责人，来统一协调和安排组件的设计工作。下图以一个团队的联合生产模式为例：

　　这种协作模式的好处是：组件专业度、通用性、业务性得以提升。

　　业务性：组件库可以和业务进行深度绑定，设计沉淀来源于实践并赋能于实践。专业性：每位业务设计师或每个业务团队可以均分组件设计的工作量，组件的设计质量和研究深度可以得到一定的保证。通用性：增强各业务设计师和团队之间的联系，大家协同配合，也可以避免组件设计偏重某个业务。但这种协作模式也有问题：需要建立清晰的协同机制。

　　这种协作方式涉及到的相关人员数量更多，因此需要更强的统一协调和管理机制，也需要有一位能够对此负责的设计师进行全局协调和统筹。

　　工作任务：

　　“联合生产”的模式较为通用，可以适用于不同阶段的组件库建设工作。这对于组件库负责人的能力要求比较高，需要根据实际情况，兼顾我们上文提到的所有工作内容；尤其是在管理和协调组件工作进展上需要有一定的经验。

　　在我所经历过的团队中，目前还没有遇到过专职的组件设计师。因为对于业务组件库来说，组件作为一种为业务提效的工具，是不可能脱离业务单独存在的。业务设计师通常既是业务组件的设计者和管理者，也是使用者。

　　还有一些经验和建议分享给你：

　　1）组件协作模式没有绝对的对错，主要看是否适合你的业务和团队特征。

　　你可以根据自己的能力、团队的实际协作情况和业务属性，选择一套适合的协作方式，也可以创造出新模式。如果你是执行者，也可以先给出一套协作方案，找领导商量如何将方案落实。

　　2）组件协作模式不是一成不变的，在不同阶段要适时作出调整。

　　组件工作的协作模式是管理和设计组件、保证组件库持续良性发展的一种手段。在组件库和业务不断发展的过程中，可以根据不同阶段的变化以及模式运行的情况适时作出调整。

　　专栏作家

　　元尧，微信公众号：长弓小子，人人都是产品经理专栏作家。一线互联网大厂B端体验设计师，清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作，目前负责国际业务线B端产品体验设计和组件库的搭建工作。

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

　　题图来自 Unsplash，基于 CC0 协议。

　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。