Vol.10 如何进行一个业务模块的产品设计

前面我们用了几篇文章来讲基础的技术知识和规范性的内容，这块虽然和产品架构设计没有直接关系，但是和团队沟通和产品质量息息相关。这也是我们做产品设计需要注意的，不能只关注产品的本身的设计，还需要思考如何改善团队协作机制和提高产研团队的效率和产品质量。本篇我们继续基础性质的内容，讲讲设计一个业务模块的时候，需要注意哪些方面。我们后续的业务模块设计都会遵循这一篇介绍的原则，以形成相对标准的业务模块设计流程。

这个是设计一个业务模块最核心的点，如果一开始没有明确业务目标，那么我们的产品设计其实就类似一个脱离了太阳系的“流浪地球”，不知道会飘向何方。而现实里，这种情况非常常见。比如，领导说能不能加个某某功能；客户说竞品有这个功能，你们能不能也做一下；我们自己有时候也会“自嗨”，给产品“添砖加瓦”……然后，等我们隔一段时间回头看时，会发现这个业务模块很乱，缺乏主线，这就是典型的产品设计偏离业务目标的情况。

因此，在开始具体的产品设计之前，我们先要多问几个“为什么”，搞清楚业务目标，后续的所有产品设计工作都应该围绕这个业务目标进行。

在明确业务目标后，我们可以对接各个业务条线的用户进行需求分析。通常我们会先收集需求，需求收集对象会是各个业务部门基层员工、部门负责人，有时候会对接高层管理人员。对于基层员工，则侧重于具体操作（功能）、体验层面、工作效率提升等方面的调研；对于部门负责人，更多偏向的是业务目标和业务管理方面的调研；高层管理人员则更多的是数据指标、如何利用业务数据辅助决策。

汇集需求调研结果后，我们需要进一步分析，具体来说，可以按下面几种方式进行分析：

• 共性与个性：哪些是共性需求，哪些是个性需求。通常我们会优先做共性需求，个性化后续可以考虑通过配置实现或者不做。
• 需求分类：这块我们在需求优先级划分有介绍过，同样对于收集回来的需求也可以划分为必备需求、期望型需求、兴奋型需求、无差异需求和反向需求来决定优先级。
• 需求分期：评估满足需求需要投入的资源，以及需求优先级来对需求进行合理的排期，决定先满足哪些需求，后满足哪些需求。

这里面需要提一下，有些业务对象之间的关系我们不确定的，最好是再进行一次需求确认。举个例子，一个客户到底是有多个联系人还是一个联系人，这在产品设计和数据层面设计都有比较大的差别。这个时候可以收集多个相关业务人的意见，并且把其中的区别讲清楚，然后再决定具体怎么设计。此外，我们也可以邀请开发人员一起参与业务对象梳理，因为业务对象梳理实际上会对应到开发工作中的数据库设计。提前梳理清晰业务对象和数据层，更有利于提高系统的稳定性和可扩展性。