编辑导语：随着企业发展的越来越成熟，B端系统逐渐受到了更多地关注与重视，市面上关于如何搭建B端系统的正向流程方法论已经有很多了，本文作者今天想从反向的角度，来讲讲从0到1搭建B端系统可能会出现哪些问题。

笔者曾负责过公司内多个B端系统从0到1的搭建，其中一些中小型系统由于业务相对清晰简单，能很顺利地开发上线。

但在做一个完整的大型系统时，由于业务领域专业、关联链路复杂、应用场景多变，踩到了较多的坑，虽然问题最终都解决了，但也付出了更多的努力。因此将这些问题分享出来，还未遇到的小伙伴要千万注意了。

如果稍不留神很容易在下一次搭建系统时又掉进同一个坑里，如果你已经也踩过这些坑了，那么我们共勉，如果你还未意识到这些问题，希望这篇文章能给你带来一些帮助。

一、稳定且靠谱的业务合作伙伴

大多数产品经理在做一个新系统的时候，很少已具备了完整的专业知识，因而为了补充必要的专业领域的知识一般会从业务咨询、理论学习、行业研究、竞品调研等几个方面获取必要的专业领域知识与经验。

当然这些都是快速入门并了解业务的好办法，能够帮助产品经理进行系统原型的搭建，但在大型B端系统的产品设计、研发阶段、甚至上线之后，依然有许许多多的业务问题会暴露出来，需要系统去解决。

这个时候只靠产品经理一人冲在前线，难免会力不从心，事倍功半。

其实在绝大多数搭建系统的时候都会有相关业务部门的同学一起出谋划策，承担责任，但在出现比如组织架构变化导致业务跟不上、又或者产品研发团队过于乐观时，仍有可能会想着依靠自己团队的力量自行解决大部分问题。

即使在寻找业务部门配合的时候，也经常只是一对多进行方案确认，即产品同学面对多个业务同学讲解系统设计方案，大家进行确认，但没有一个业务伙伴能够为项目的成与败、好与坏负责。

虽然能够指出零散的问题，但没有人对全局进行把控，产品经理还是会陷入在自己的认知当中。同时也很容易被片面的意见带偏，因此这种情况在大型项目中是非常危险的。

所以从0到1搭建大型B端系统的时候，一定需要挑选稳定且靠谱的业务合作伙伴。

关于如何挑选业务合作伙伴，我这里有一些选择的原则可以分享给大家：

1. 直接负责该业务的人员是合作伙伴的首选；
2. 如果没有直接的业务负责人，则与该业务强相关的人员优先；
3. 同样业务相关的情况下，可以与业务部门leader沟通，由leader指派一名合适的业务人员作为伙伴；
4. 同样业务相关的情况下，且没有leader指派，在该领域内专业知识、实操经验更丰富的优先；
5. 如果未来系统的使用会涉及到不同的角色，且相互间有一定的耦合，在有条件的情况下，可以在每个角色中挑选1名或多名合作伙伴（总人数不能太多），组成虚拟项目小组，大家共同来完成整个项目。

在挑选好了合作伙伴之后，产品经理需要定期或不定期地与合作伙伴保持互动与沟通，认真倾听合作伙伴的意见。

但作为产品/项目的负责人，同时也是更了解产品与体验的人，需要保持独立思考，不全以合作伙伴的想法为准。

二、对业务的理解偏差

由于B端系统往往都是紧密联系业务，解决业务问题的，因此在设计B端系统时需要产品深入掌握业务知识，如果对业务理解不深，或者想当然的做系统设计，很可能会做出不符合业务场景的功能。

比如搭建一个招聘系统，面试流程相关功能是其中非常重要的模块，在很多人的直觉认知里面，面试官在面试后认为淘汰，就意味着面试终结，因此可能在设计功能的时候，只要面试官填写了淘汰，系统就会自动的判定本次应聘淘汰，与之相关的状态也直接进行了流转。

但在一些公司中，一定是需要HR操作了淘汰才可以被认为真的淘汰。

因此如果按照产品自己的想法很容易做出错误的判断，需要和以上提到的业务合作伙伴多进行深入的沟通，甚至通过轮岗或者长期观察了解实际情况，保证自己对于业务的理解不要出现较大的偏差。

三、MVP也很大

一个新的产品，在设计阶段常常会考虑搭建MVP（最小可行性产品），但由于B端产品需要解决复杂的业务问题，尤其当公司内已存在一个旧版本系统或第三方系统的时候，就需要新的系统在主体功能上具备之前系统已有的功能。

如果没有以前的那些功能，业务人员会觉得还不如老系统好用而不愿意使用新系统，也确实会因为功能的缺失而无法应对一些特殊的场景，那么整个项目会处于非常尴尬的境地。

因此在产品设计之初，产品经理就不得不尽可能地覆盖之前的功能，搭建一个较为完整的系统，这样就非常需要产品经理在短期内摸透整个系统框架并给出具体的设计方案。

同时在产品进入研发阶段后也会加大开发的工期，而时间拉长后，在互联网这个飞速发展的行业会遇到更多的变化与挑战，无形中增加了更多的风险与压力。

四、寻求设计师的帮助

B端系统有公司内部使用或外部用户使用的区别，如果对外使用的商业化B端系统往往会有设计师对界面进行设计，但有时候纯内部使用的B端系统由于公司设计师人员紧张、无法及时支持项目的排期。

产品经理为保证项目进度可能会使用高保真原型配上公司既有B端系统规范就进入研发，但毕竟缺少设计稿后很多页面细节没法把控，同时在操作跳转等交互细节上也不够细致，在开发完成后会与预期的效果仍有一定的差距。

这时想改也因为没有设计稿无法进行调整，因此从0到1搭建系统的时候请设计师帮忙出设计稿还是非常有必要的，能保证系统上线的体验和质量。

五、其他项目插入

前面也提到，由于MVP也很大，导致了研发工期会比较长。

但在团队研发资源有限的情况下，如果还需支持公司内部其他项目，当有更高优先级的项目出现时，就会在本项目开发过程中穿插着做其他项目，进一步拖长了研发时间，同时也影响了本项目的研发节奏。

工期的延长又导致可能在后面还有其他新项目的插入，使得团队因为各种插入项目而疲于奔命。

因此如果一个团队负责多个项目的研发时，一定要管理好项目的优先级，并协调好各个需求方的预期，做好充分沟通。

六、数据同步

如果从0到1搭建的新系统，在公司内没有正在使用的老系统或第三方系统，数据方面更多地是与上下游的数据进行同步。只要上下游系统数据清晰，在研发时接口定义清晰准确，一般会比较容易的完成初始数据的迁移同步。

如果还有正在使用老系统或第三方系统，出于信息沉淀与数据价值的考虑，老数据必须同步到新系统中，那么请注意一下3点：

1. 时间工期考虑

数据同步将会占用更多的产品研发时间，这点务必在项目初期的估时中考虑进去，如果只计算了功能研发时间而忽视了数据迁移的工作量，会导致实际项目工期比预计的长，对后续的计划产生一定的影响。

2. 字段映射关系

产品经理与技术研发需要仔细地梳理新老系统的数据字段，整理出清晰地对照关系。

同时由于两个系统在功能上有一定区别，有些字段无法形成一对一的映射关系，如：老系统上有的字段，在新系统中已经去掉了；老系统的状态比较笼统，新系统的状态更加细分；新系统的业务模式升级，业务状态与老系统不一致等。

这就需要产品经理根据产品业务场景，对该部分字段的关系进行重新整理，尽可能合理的兼容新老系统之间的逻辑差异，使得老数据能同步迁移到新系统。

3. 数据同步形式

数据同步有接口实时同步、异步同步、以及表格导入这三种形式，采用何种方式进行数据迁移，主要取决于老系统/第三方系统能支持哪种方式的同步和迁移，以及双方所能投入的成本与获得的收益。

比如老系统/第三方系统没有接口能支持同步且无法配合开发，仅能导出，就只能在新系统中开发相应的接口，通过从老系统导出表格，然后上传到新系统，从而完成这类数据迁移。

七、寻找试用用户

在大型系统开发测试完成后，项目需要经过内部或外部小范围的试用，确保功能覆盖的场景没有遗漏，操作是符合目标用户习惯且高效的。

• 在寻找试用用户前：梳理系统的使用者群体，尽可能的覆盖各类用户角色。
• 在寻找试用用户时：可以发动业务伙伴的力量，协助找到每个角色需要的具体人员。
• 在试用用户确定后：通过启动会等方式明确试用目的，宣告试用的启动。

在试用过程中，可以通过建立微信群等方式进行实时反馈跟进，有条件的情况可以定期召开沟通会，通过试用人员的反馈了解系统在真实环境下的使用情况，发现的问题可以快速进行迭代解决，缺少的功能可以迅速进行设计开发。

在系统得到试用人员的认可后，就可以逐步进行全部用户的切换了。

八、老系统功能对比与习惯养成

如果搭建新系统之前，用户并没有同时在用一套老系统，那只要新系统能解决对应的问题，用户就能顺利的进行使用；但如果搭建新系统时，用户已经在使用其他的系统，那么在上线使用新系统后，难免会将新系统与老系统进行对比。

比如老系统中存在一些不合规范但能够灵活应对各种情况的功能，这时候用户也希望新系统提供类似的功能。但随着企业的发展，精细化、合规化的管理更符合未来的趋势，需要结合规范与便利做出平衡。

因此需要沟通利弊，让业务用户接受新的功能，指导他们合理的使用新功能。

九、上线运行不稳定

相信很多产品经理都遇到过，大型系统历经千辛万苦上线后，小问题时不时会冒出来，可能是系统设计不完美造成的，也可能是某处代码没写好，甚至可能是因为团队人员变动导致的。

因此需要对产品质量进行严格的把控，同时也需要和研发同学保持良好的沟通，尽可能快的解决问题。毕竟一些性能问题也会导致用户对系统信任度降低，从而会出现吐槽，甚至不想用系统的情况。

一般在持续一段时间高效地解决出现的问题后，新系统逐步满足各种场景的操作，以稳定、高效的状态更好地支持业务的发展。

最终，在系统上线投入使用后，由于大型系统面临的业务场景也非常复杂。因此业务人员会提出更多的需求，产品经理需要持续深耕，安排新的系统迭代，打造更强大的系统，支持业务的发展。

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

题图来自 Unsplash，基于 CC0 协议