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

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

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

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

如何处理

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

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 长期（三年、五年、更久）来看会有什么变化

这样提问的好处

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

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