随着2018的临近，为期两年的大型平台项目终于看到曙光，趁着7天年假的休息调整时间，同大家分享下这段伴随着 信心与激情、痛苦与绝望、压力与动力、成功与喜悦的刻骨铭心的过程。
这是一个由我们近三十人的项目组来主导，与六百余人配合、开发、联调、测试的大型金融平台项目。
小到开发细节，大到业务场景，青鸟会在各个系列专题中逐一叙述，本篇先来分享下业务需求的分析、制定、审核、确认、变更、维护的一系列过程。
1、需求
先说下需求，值得一提的是，需求一个特别有意思的东西。因为，很有可能你都不知道它是怎么来的？！！！
现场调研、客户体验、业务场景 、竞争对手、凭空想象 都是需求的最初来源，而我们的工作却不仅仅是将这些梳理成一个完成的需求文档
因为，你面对的是四个整合平台，六个业务部门，还有一些更是身在异地他乡的同业务事。
同样的时间，不同样的地点，想的又不是同一回事儿，如何在一团乱麻中快刀斩下？如何在争论不休中一锤定音？如何在束手无策中乾坤一指？
一场八个月的身心历练，就这么开始了。。。
天天开会、扯皮、红脸、拍桌子，如同度过了一整个酣畅淋漓的雨季，开始酝酿下一个花满芬芳、春回故里的盛夏田园。
2、分析
尘埃落地后，需求分析也会水到渠成。。。(一开始还真这么想过)
天真！！！
假如这是一个相对较小的项目，凭借经验，修修补补或许可以。
如果这是一个四百余人的大型开发团体，研发阶段 同时进行，谁托谁一把，都将影响整个项目进度。因需求分析的疏漏导致的项目延期甚至难以掌控，将会使整个开发团队压力陡增甚至人员变动，进而人力成本超出预算、对公司信誉造成难以弥补的影响。
为避免出现大意失荆州的情况，将所有的分析结果进行落实，整理成一套分析明确、注释清楚、逻辑合理、流程清晰的详设文档。
谁来负责？
3、制定
以我们项目组为例，总共三十余人，其中开发人员超过二十，每人负责三个大的业务模块。（注：所谓大的业务模块，指模块开发时间超过两个月）
每个业务模块要编写流程文档和接口文档，每个文档完成后需要进行组内评审，审核通过后作为开发文档封存定版。
待所有文档书写完毕后，将所有文档合而化一，于是一个长达一千五百页的接口文档便诞生了，我的天呢！
4、审核与确认
审核也是这一环节中相当有意思的一处，为什么呢？
要说简单，也很简单，只需要查看文档的内容是否按照商议的版本一致；
要说困难，是否大处留心，小处细心。切勿出现会上商议妥当之后，进行一些文字上的小动作，或许无心，或许有意，小变更，大麻烦。
5、维护
这项工作最好由专员来处理，而且每次变更都要有修订的记录。尤其是多系统平台配合的开发工作，标注鲜明，注释明确，避免扯嘴炮的情况，不留下点东西，怎么行？
至此就完了吗？
想多了！！！
这不是一条线，而是一个圈，甚至都不知道起点在哪里，一个新的圈圈就诞生了。
项目中，需求没有永远的定稿，业务没有静止的需求，并行时时刻刻都在，功能眨眼之间已不是从前。
原文地址：https://www.cnblogs.com/stobird/p/8447197.html