事件风暴-协作探索复杂业务领域

本文是个人理解，并不一定准确，仅供参考，想吐槽也可留言

        事件风暴可以用在业务分析和技术分析，如果你做的业务已经有人做过了，那肯定会有这方面的专家，请来或者模仿去做一个公司特色的产品，事件风暴最合适不过，如果是从0到1的创新，不好意思打扰了请绕行（这种创新型业务一般不会有公司去搞，但是要是搞成了像微信那样，就会是垄断般的存在）

        实际上大多数开发人员技术架构很难有机会去做业务可行性分析，这种工作一般是老板直接请来一个很牛的业务大佬直接开搞

        作为技术人员使用事件风暴一般在设计阶段，分析设计是否准确、完整、减少bug、后期扩展性等等

业务分析事件风暴主要干什么事的？

1、在现有业务的基础上探索新的可行性或者有价值的改造

2、探索新业务的可行性

说白了就是：业务可行性分析

        一群人（各个部门，业务，产品，架构，测试）通过事件发散（就像树的主干和枝叶一样）通过不断的提出问题，解决问题，最终成为一颗完整、有闭环的业务树，让所有参与的人员达成共识

        分析的时候为了避免像无头苍蝇一样乱撞，最好先由对业务相对熟悉的人做一版主线业务的概述，比如画一张主线业务图，把大概核心点描述一下，这样大家都跟着这个主线发散思维效果会更好

        发散思维后要学会总结，学会取舍，毕竟这是可行性分析

        如果是在现有业务的基础上必须有个相对熟悉的人来把控全局，毕竟越熟悉想法就越多，但不是每个想法都是成熟的

        如果是新业务，如果有业务领域专家当然是最好的，先给大家普及业务，然后再讨论，各个参与者在自己擅长的领域查漏补缺，要是没有熟悉的就去模仿，如果是无先例那就是从0创新，难度太大了，但如果成功了将是垄断性的（类似于头脑风暴）

作为技术人员，在设计的时候同样适合用事件风暴去分析

        在设计阶段，肯定是对业务已经有了全面了解，产品已经定项，这个时候架构师会针对某个局部业务出详细设计文档，然后对设计文档进行评审

        这个阶段更多的是将相关知识传播给开发人员，开发人员熟悉之后可根据自己负责的模块去理解去发散思维，查缺补漏，这个阶段不仅要梳理正常流程，还要梳理异常流程，最终让开发人员对该领域的设计达成共识

        细想，其实在写代码过程中也是通过这种自问自答的形式去一步一步实现逻辑的

针对业务分析和设计分析，它们的参与人员、达成的目标、范围都不尽相同

人员：

        业务分析：主要是各个部门的业务熟悉者，架构师，产品等人

        设计分析：主要是开发部门的开发人员，测试，架构，产品等

目标：

        业务分析：让各个部门（运营、财务等）在主业务中补充自己擅长领域的知识，让业务更加完整

        设计分析：让开发、测试人员熟悉业务，理解设计理念，讨论具体功能的细节、可实施性

范围：

        业务分析：重点在整个大的业务范围

        设计分析：重点是某个子领域的局部业务范围

一个人的分析叫事件风暴吗？

        很多时候我们入职一家新的公司，然后领导扔过来一堆文档和一堆代码让你先熟悉一下，这个时候可以来一场一个人的事件风暴。同样先提出问题，再解决问题，最终将业务及代码整理成属于自己的一颗树

        比如：

        1、先通过熟悉app或者网站或者业务文档，了解一下业务主流程---画出树的主干

        2、从代码中找到主业务入口，先读一遍主流程，将分支（分支流程）的地方标记到主干

        3、将分支业务按重要程度排序逐个攻破----产出流程图，时序图等----画出树的枝叶

        4、记录不懂的地方，对照文档，请教同事

        5、记录好的地方充实自己的知识库

        6、记录不熟悉的知识点，自己学习

        7、记录你认为不好的地方，如果是你该怎么做---这将是未来某个时间点你发光的地方

        8、循环往复

个人觉得在做业务的过程中，只有了解了业务的全貌，了解了系统的全貌才能有站稳脚的可能，不然人家讨论问题都不带你，和大佬站在一个层面考虑问题工资才能靠近大佬