B端中后台产品，如何平衡业务和产品的系统设计？

产品破壁人老杨 2024-07-22 13:53:01

都说B端产品经理都需要懂业务，但是懂业务的深层次含义又是什么呢？

只知道业务流程和术语，保证流程设计和功能不出问题就可以了吗？

在我看来，一个产品经理懂不懂业务，在接到需求的时候就已经高下立判了。

厉害的产品是既能懂业务当下在急什么需要什么，又能通过产品思维去反问业务方。

倒逼业务方做到更深层次的思考，而不是满足一时的方案。

与C端相比，B端行业的需求更加复杂、个性化和多变。

这就要求产品经理需要从不同的视角来进行功能设计和架构规划，确保能够满足各个相关方的预期。

在这种背景下，业务视角和产品视角必然会有一定的冲突。

核心原因在于业务视角强调需求价值和短期问题的优化，而产品视角则更加关注功能覆盖面和产品方案的复用。

所以产品经理如何在实践中平衡这两种视角，成为了功能设计和架构规划中的一大挑战。

结合自己的实践，希望可以探讨业务视角和产品视角的具体应用，分析这两种视角在功能设计和架构规划上有哪些区别，并通过实际案例来说明如何在实际操作中融合和应用这两种视角。

一、业务与产品视角的定义

中后台产品设计中，业务视角和产品视角在功能设计或架构规划上的区别主要在于关注的重点不同。

主要关注的是公司的业务运作和目标。简单来说，就是从公司的业务需求和目标出发，考虑现在产品应该具备哪些功能，如何帮助公司实现这些目标。

往往更侧重于通过产品支持公司的业务运作和目标，它们通常是具体、明确且有时限性的，同时受到市场和竞争环境的影响。

在我遇到的需求中，总结了以下几类特征：

主要看中如何设计能够更加易用、直观和长远。会较为完整地考虑架构、功能、交互等各个方面，考虑如何在满足当下需求的同时兼顾到未来发展。

通俗来讲，我认为有以下特点：

总的来说，在架构规划上，业务视角可能会更多地考虑如何支持现有的业务流程，如何适应业务的快速发展。

而产品视角可能会更多地考虑系统的可扩展性、可维护性，以及如何为未来的产品迭代和升级留下空间。

如果业务视角占主导，你就会发现所有的中后台逻辑和功能模块都是叠加的，没有架构的美感可言，一切讲究所见即所得，极致的效率至上，往往到后面就连自己做过哪些需求都想不起来。

如果产品视角占主导，你就会发现中后台功能比较分散，有时候不是按照部门和角色进行功能模块的划分，对于新员工来说，学习的成本是比较高的。

所以在实际的产品设计中，需要平衡这两种视角，既要满足业务需求，又要考虑到用户体验和产品的长期发展。

这就是产品经理的价值所在。

从现实角度出发，功能设计需要紧密结合业务流程和商业目标，确保每个功能模块都能为业务运作提供明确的价值。主要侧重点包括：

业务流程支持：功能设计需要支持和优化现有的业务流程，例如自动化处理、流程集成等，以提升业务效率。最好一个业务流程做在同一个功能或者模块内进行配置。
定制化需求：针对不同企业客户的个性化需求，设计定制化功能，满足特定业务场景的需求。这些业务逻辑往往是临时的，只适用于特定的场景。
性能和安全性：确保功能模块的稳定性和安全性，保障业务连续性和数据安全，他们最常见的说法是，我要改动整个下单流程，要百分百保证订单不出问题，但不需要进行整体的回归测试。

从完美主义出发，功能设计更注重用户体验和功能完备性，确保每个功能高内聚低耦合，能够最大可能适配未来的需求变化，主要侧重点包括：

平衡业务视角和产品视角，我认为关键在于理解和管理预期。也就是理解对方需求找到交集，然后不断迭代和调整。在我的实践中通常是这样做的：

了解全貌：我会花时间与业务团队沟通，确保我真正理解了他们的需求和痛点。会尝试去挖掘他们对于这个环节的看法和未来业务的形态。当下是怎么解决这个问题的，未来想怎么解决，是不是有更好的解决方案。
制定共同目标：寻找业务目标和需求的共同点，比如提高效率和提升用户体验，然后围绕这些共同点设计功能，并且要将目标定在往后一点的节点，有时候业务是不会去多想的，这就要求产品经理一定要多问，多了解。
排优先级：根据业务的重要性和对用户的价值来决定功能的优先级，如果影响比较大的改动，甚至需要要求业务方先按照目前的手工方案去执行，避免因为临时的需求对业务稳定性带来影响。
快速迭代：我会先设计一个MVP，预留好未来可能会影响的字段和配置项，然后根据用户和业务团队的反馈进行快速迭代，不过度设计但也不会啥都按照业务方提供的要求进行原模原样进行设计。
价值驱动：我一定会提前说明这个功能带来的改动代价会是哪些，要求业务方制定上线后的价值指标，不管是按照效率提升、流程简化程度还是直接的收益，必须有个反馈，不能做完了就结束了。