一、界定需求
需求的来源是为了解决某个问题，也许用户提出的多个需求是为了解决同一个问题，也许提出的需求并不是必须的，所以要找到产生需求真正的原因去判断这个需求是不是真的，我一般会问以下几个问题：
1. 谁提的需求？谁是需求的实际使用者？
提需求的人和需求的实际使用者可能不是同一人群，针对同一个需求他们角度不一样，中间可能会产生别样的需求。例1：在建筑装饰行业就物料的粒度和计量单位来说，采购希望以物料SKU最大单位为计量单位，而仓管希望以SKU出库单位为计量单位，成控希望物料粒度可以自行控制，同仓管的计量单位。
2. 这个需求解决什么问题以及涉及的业务场景有哪些？
就例1的需求，实际上由不同角色基于自身的业务角度提出，因为分散提出，很容易让人定义为只是为了解决单个业务场景下的问题，对问题的定义也同时会影响解决方案，这时候需要去了解需求变更涉及到的所有业务场景（什么人在什么情况下怎么使用此功能），站在上帝的视角把需求整合，会发现真正要解决的问题是：怎么解决不同业务场景下物料的粒度和计量单位不同的问题；而不是局限于解决某个场景下的某某问题。
3. 可不可以不解决？
是不是必须解决，即：不解决会产生严重的后果
4. 操作顺序是怎么样的？
结合业务场景理清楚用户操作路径、涉及的各个处理人的职能和一些分支条件
5. 提需求的人和实际使用者对此需求的想法是什么？
例如：有哪些关键字段，以及字段的用途是什么？他们希望的解决方案是怎样的？
6. 需求的使用频率和使用人数
B端需求，结合产品定位和以上的了解大致可以判断出
二、思考需求
以上可以清晰的知道要解决什么问题，接下来要思考怎么解决问题，市场上有哪些竞品解决了这个问题，综合考虑确定方案后输出需求变更说明文档：
1、 竞品是怎么解决的？为什么这样解决？
2、 竞品解决方案优势和劣势是什么？用户反馈如何？
3、权衡是解决问题的根本还是暂时只满足用户需求？
权衡两者各自可能要花费的人力物力和时间以及对现有流程、数据的影响，还有考虑后续的扩展性等问题
三、设计功能
在设计功能时，需要考虑到几点：
1、需求变更对产品的影响范围
例如：影响哪些功能模块，影响历史数据、影响权限，影响流程状态变更
2、单个功能的闭环和流程的整体闭环
例如：采购订单的闭环可能会触发付款单和采购申请单一系列状态变化
3、反向检查遗漏的业务场景
用户给的业务场景可能会有遗漏，在设计功能前我会在草稿纸上或者脑袋里面基于已有方案检查产品功能是否满足所有场景，并反向思考产品功能会不满足哪些场景，而这些场景出现的概率有多大来调整设计方案
网友评论