2B软件产品的主体功能设计流程

　　就如项目管理有多种模型一样，产品的从无到有也有多种可选方式，不同的方式适合于不同实际情况，这里主要介绍一种更适合2B产品的管理方式，总体上产品管理可以分为产品功能的确定、产品使用方式的确定、实现过程管理三部分。

1. 产品功能的确定

　　首先，如果说2c产品的核心是洞悉人性，那2b产品的核心则是理解业务价值和业务流程，新时代2b产品在大多数情况下的本质是在深入、透彻理解一种场景的运行逻辑与规则情况下，结合新技术及其成本，构建出的一套整体上能使资源利用更有效率、局部上能使各环节更便捷的体系，并尽可能使原客户在新体系中的体验优于原体系。因此，决定2B产品功能的底层要素包括客户，业务，技术方案，所以产品设计一般都始于识别用户和理解业务。

　　理解业务：虽说已经是老生常谈的话题了，但本着重要的事情说三遍的原则，还是要再提一下：理解业务可以说是2B软件设计中最重要的部分，是后续一切活动的基础。每个人都有不同的方式去理解业务，方法其实没有好坏之分，只要有效即可。熟悉的领域检验是否理解业务的标准是代入业务负责人的角色，是否知道应完成哪些工作、如何完成、各部分工作的价值。对于不熟悉的领域，个人喜欢使用业务目标、业务流程、业务价值、业务操作方式框架，分别对这几部分进行针对性理解。但是其实上述过程完成后只能算达到了业务理解的及格分，只能满足设计照章办事类的信息系统的需求，接下来还需要扩充业务理解的深度和广度。深度是指需要了解这部分业务的“输入”和“输出”部分，“输入”是指完成工作的前置业务包括哪些、会如何影响当前业务，“输出”是完成工作的产出物都影响哪些部门以及如何影响，例如一个运输管理系统的输出影响方包括司机、发货点（仓库）、接货点（门店），评估如何影响时能实际理解和代入此三方角色的感受。大多数情况下，对于一个不熟悉的领域，很难短时间内兼顾“输入”和“输出”两部分，此时应分配主要精力在“输出”上，其重要性比“输入”更高，会直接影响产品的落地。广度是指日常业务中往往会存在大量“bad case”，即与标准业务场景、流程不同时的情况，对此类场景的提炼往往会形成产品的“魅力型需求”，能较大幅度提升用户体验。除以上几部分外，业务理解还有一个额外的加分项，即业务理解的高度。业务理解的高度来源于对所处公司商业模式、市场趋势、营销策略、竞争特点、商品特点等等一系列商业信息的综合判断，往往是可望而不可求的，能够大幅增加产品的前瞻性和创新性，也大幅增加产品推广时的说服力。

　　识别用户：B端产品往往采用划分角色的方式区分使用者的特点和诉求，值得注意的是不应该只把有可能会使用产品的人作为产品的用户，某些角色虽不直接使用产品，但会受到产品的影响，也需要被一并视为用户，在后续的需求分析和产品设计时考虑其感受，例如计划系统中所有需根据计划展开工作的人都应被当做产品的用户。

　　

　　完成上述环节后，就可以进入产品功能确定的第二个阶段，即需求分析了。在需求分析时一定要明确的是用户说的不等于用户做的不等于用户想要的。福特汽车创始人说过，如果你问人们想要什么，他们会说想要跑的更快的马。避免陷入表面需求的办法也是一个老生常谈的环节，即根因分析。一个常见的根因分析的技巧是对需求连续问五个为什么，挖掘潜藏在表面之下的真实需求和痛点。但其实如果上一环节能够扎实的完成，根因分析其实是可以像呼吸一样成为内化于心的习惯的。此外，进行根因分析需要对用户足够了解，需要能代入用户的认知、技能、工作决策过程，从而设身处地的为其思考。完成根因分析后就可以进行需求合并、需求冲突性评估、需求价值评估并与相关人员进行确认验证，明确以上内容的正确性后开始需求取舍和排序，决定产品要完成的所有功能。

　　当然不同企业业务细节不同，但其业务价值是相同的，事物越向其表面越是纷繁多变，理想的方式是做产品价值的传道者，改进用户认知，通过业务理解对灵活程度进行收束，通过核心方案的创新来以简驭繁。但适度的二开是难以避免的，所以关键环节要进行适度灵活化。

　　2.产品使用方式的确定（用户旅程/用户服务地图/……设计）

　　关于这部分，市面上一直没有个统一的名字，个人还是习惯于称用户旅程。用户旅程即用户在系统上通过怎样的一步步操作完成自己想要的功能，同时在用户可视线以下，系统是如何配合用户的操作实现其功能的。这个环节最重要的但也是B端产品中经常被忽略的环节是how might we……，即针对之前确定的需求，我们可以怎么样满足其需求，需要进行一系列的发散——收束——再发散——再收束的思考，最终确定每个需求的实现方式。一般这个阶段也会确定最小可行性产品（MVP），用于进行产品核心功能是否有效的验证，通过完成产品的最小需求功能集缩短进入市场的时间、降低实验成本。

　　完成用户旅程后，还会有一个UI设计+交互设计的环节，UI设计中各类组件一般可以直接参考热门前端框架的文档，在其中直接选择，如element(https://element.eleme.io/#/zh-CN/component/layout)。这部分需要多看多积累，对于非美术/动画类专业的产品经理而言，原创出具有酷炫视觉效果和操作感受的交互设计的几率偏低，不过好在B端产品其实来来去去都是那些基本套路的组合嵌套，注意积累一些表格、功能区、面板、图形的基本元素根据交互原则合理搭配也能做出75+左右的交互设计来，本人更擅长系统逻辑设计，视觉和交互方面就不班门弄斧了。可以掌握一些根本原则，通过代入用户来评估视觉/交互小姐姐们（大多数情况哈哈）给出的各种方案的优劣，一些重要原则如下：

• 让用户本能的找到他应该操作的地方。
• 考虑用户的认知负荷、视觉负荷、行为负荷
• 优先使用已被广泛接受的逻辑框架，降低学习成本
• 要考虑功能分类、前后置关系、关系密切程度、使用频率
• 界面、构件、构件位置、关系的一致性
• 设计好总纲：导航架构，用户不迷路
• 大后台，小前台。用户负荷越低越好，信息通知越精确完善越好。核心还是代入用户。

　　额外还需要提一下的就是系统的颜值。。这个B端软件其实不应该那么重要的东西很多时候在国内相当之重要。。

　　3.实现过程管理

　　懒得写了。。。跟项目管理很像，就是怎么写需求、敏捷/非敏捷方式，工作量估算那一套。

　　写需求时有用户故事、UML用例等等很多方法。我比较喜欢的是开发面向对象那套方法，就是在整个体系里找所有实体，然后列出来实体都干了什么，算法模块当成实体对待。给开发讲明白最重要，架构和设计还是架构师比较专业。理解了大框架再进入每个页面说说都是干啥的和细节功能，文档作为笔记只记要点。描述性语句用说的，免得写的人烦看的人也烦。