为什么会有方法论这么一个大概念

研发和产品天生的是冤家,产品和研发的工作职责就注定了这两个角色就是一对相爱相杀的主。

产品的工作职责就是提出问题,而研发的工作职责是实现问题,但是不同的人有对于事物不同的看法,所以平时工作配合中才需要需求宣讲、研发反讲、需求拆解等等一系列工作流程来保证双方对于事物的认知统一。

当然,这篇文章并不是去布道工作流程,这篇文章是我在多年摸爬滚打中提炼出来的一种在产品勉强“装逼”的对于需求“事物”的分析方法。

如何处理

拿到一个新的需求后我会按照顺序问一遍产品这些问题来帮助我理(zhuang)解(bi)需求:

1
2
3
4
5
6
7
8
9
1. 这个需求提出的背景(原因)是什么?
2. 为什么要做这个功能?
3. 如果实现这个需求,能有什么收益
4. 这个需求有没有替代方案
5. 定义完成需求(验收)标准是什么
6. 完成后期望的规模能有多大
7. 这个功能完成后对公司、部门有什么有益的意义
8. 完成后对于其他兄弟部门、其他业务团队是否有不良影响,如何消除
9. 长期(三年、五年、更久)来看会有什么变化

这样一个原始需求可以拆分成4类问题来重新提问:

  1. 原因

    1.1 这个需求提出的背景(原因)是什么?

    1.2 为什么要做这个功能?

  2. 结果

    2.1 如果实现这个需求,能有什么收益

    2.2 定义完成需求(验收)标准是什么

    2.3 这个需求有没有替代方案

    2.4 完成后期望的规模能有多大

  3. 正向收益

    3.1 这个功能完成后对公司、部门有什么有益的意义

  4. 负向收益

    4.1 完成后对于其他兄弟部门、其他业务团队是否有不良影响,如何消除

    4.2 长期(三年、五年、更久)来看会有什么变化

这样提问的好处

这样提问并不是要为难需求提出方,只是可以让你更清楚的知道这个需求对于整个研发部门、整个业务部门、整个公司的意义,根据需求的提出期望可以更好的设计系统的架构复杂度。

对于需求提出者也可以在回答问题时候能再一次梳理自己的逻辑。