明道实施与需求的耦合

文/明道云实施顾问 陈江浩

明道云是一个 APaaS 平台,帮助企业快速搭建个性化业务应用，而实施顾问们工作的核心就是将企业需求与明道云产品功能进行匹配落地。

关于企业的个性化需求如何处理，这是明道云每位实施顾问都要直面的重要问题。通过不断地探索与发现，我逐渐提炼出了一个通用方法。

一、需求收集

明道云的客户来源于不同行业的企业，需求对接的负责人既会有企业的产品经理、也会有部门的业务员、亦或是技术开发人员等。需求来源的复杂度决定了我们要因人而异地去用不同的沟通方式来获取客户的真实需求，因为不同的角色人员往往会在需求阐述的过程中进行不自觉性的加工。

收集的需求是应用系统规划的基础，也便于我们去鉴定需求层的范围。后续的搭建阶段和维护阶段的需求收集则是对需求层的再认知和补充。

二、需求分析

上文提到的需求层一共有三层，从下往上依次为：业务需求层、用户需求层、产品需求层

个性化需求分析是对需求层的确定和补充，也是对需求的处理和定义。通常需求处理有以下几步步骤：需求定义、属性归纳、需求判定

需求定义

需求往往是复杂混乱的、并且需求间可能会有重叠，对于不完整不清晰的需求我们更加需要进行加工处理，来判断客户的真正需求痛点。在理解需求时我们要铭记一句话：没见过汽车前，用户只想要更好的马车。

筛选：筛选掉错误、无效的伪需求；

定义：定义问题背后真正的问题，还原需求下面真正的需求；

挖掘：需求常常不是一个点，而是业务和场景的一条需求线（用户、目标、场景、任务）。

属性归纳

定义后需求是明确清晰的，这时候我们可以给这些需求制定一些标签来进行多维归类，由于我们的需求是在明道云上搭建的，可以直接利用明道云的六大模块（工作表、工作流、用户、视图、自定义页面、统计）成为一些大标签，当然大标签下面我们还可以细化出一些小标签。

需求判定

在客户购买产品前，可以用 Kano 模型来对客户需求做分类和优先排序。以分析用户需求对客户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

Kano 模型 5 类

基本（必备）型质量——Must-be Quality/ Basic Quality

期望（意愿）型质量——One-dimensional Quality/ Performance Quality

兴奋（魅力）型质量——Attractive Quality/ Excitement Quality

无差异型质量——Indifferent Quality/Neutral Quality

反向（逆向）型质量——Reverse Quality

明道云提供的功能可以满足客户前三类的需求度越高，那么客户的购买意愿也就越高了。

在客户购买产品后，需要我们去实施搭建的时候，我们可以利用四象限法则去进行需求落地，这样可以最大化我们的输出效率：

三、需求匹配

需求有了详细的定位分析后，我们则需要到明道云平台上做需求匹配实现。而需求在明道云上的落地结果，总结下来有 4 类：直接实现、间接实现、未来解决、不支持。

直接实现：明道直接包装好的中间件或功能模块，例如：数值控件，用户只能输入数字相关内容；

间接实现：明道本身没有或者需要以委婉的方式去实现，例如：查看一个城市的天气情况，我们需要通过 Webhook 去访问对应的 Api 来获取对应城市的天气内容，最后呈现在记录上；

未来解决：明道的产品迭代上有计划的功能，当前不能解决，但会在版本更新后解决；

不支持：对应功能不在明道的产品路线上，也无法用间接方式去解决。

基于以上 4 类需求匹配，需要判断人作为对明道云产品本身熟悉度较高的人员去处理。

四、需求池建立

衡量一个实施人员的资历，很多时候是跟他的需求池挂钩的。那需求池如何建立呢？

需求无处不在，也许是一次会议沟通、一次售后提问、一次功能调整。这就需要我们有随时记录需求的能力，在明道上搭建一个需求池是个不错的选择！

需求池上的基础信息中要包含的信息有：行业、模块、功能点、需求描述、场景描述、需求层次、需求类型、商业价值、提出人、提出时间、明道上的实现状态。当然，我们不是产品，不需要对产品的规划与设计负责。但是与需求有关的产品功能一旦有变动，我们还是需要及时更新需求池上的【明道上的实现状态】这一栏。

需求池的建立实际也是为了让我们在面对客户时心里有底，让我们与【需求收集】、【需求分析】形成闭环。