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

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

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

当然这些都是快速入门并了解业务的好办法，能够帮助产品经理进行系统原型的搭建，但在大型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. 字段映射关系

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

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

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