首页 > 其他 > 详细

1、大型项目经验分享——业务需求篇

时间:2018-02-15 00:38:18      阅读:172      评论:0      收藏:0      [点我收藏+]

标签:公司   注释   维护   书写   封存   避免   每次   进行   处理   

 

随着2018的临近,为期两年的大型平台项目终于看到曙光,趁着7天年假的休息调整时间,同大家分享下这段伴随着 信心与激情、痛苦与绝望压力与动力成功与喜悦的刻骨铭心的过程。

 

这是一个由我们近三十人的项目组来主导,与六百余人配合、开发、联调、测试的大型金融平台项目。

小到开发细节,大到业务场景,青鸟会在各个系列专题中逐一叙述,本篇先来分享下业务需求的分析、制定、审核、确认、变更、维护的一系列过程。

1、需求

先说下需求,值得一提的是,需求一个特别有意思的东西。因为,很有可能你都不知道它是怎么来的?!!!

现场调研、客户体验、业务场景 、竞争对手、凭空想象  都是需求的最初来源,而我们的工作却不仅仅是将这些梳理成一个完成的需求文档

因为,你面对的是四个整合平台,六个业务部门,还有一些更是身在异地他乡的同业务事。

同样的时间,不同样的地点,想的又不是同一回事儿,如何在一团乱麻中快刀斩下?如何在争论不休中一锤定音?如何在束手无策中乾坤一指?

一场八个月的身心历练,就这么开始了。。。

天天开会、扯皮、红脸、拍桌子,如同度过了一整个酣畅淋漓的雨季,开始酝酿下一个花满芬芳、春回故里的盛夏田园。

2、分析

尘埃落地后,需求分析也会水到渠成。。。(一开始还真这么想过)

天真!!!

假如这是一个相对较小的项目,凭借经验,修修补补或许可以。

如果这是一个四百余人的大型开发团体,研发阶段 同时进行,谁托谁一把,都将影响整个项目进度。因需求分析的疏漏导致的项目延期甚至难以掌控,将会使整个开发团队压力陡增甚至人员变动,进而人力成本超出预算、对公司信誉造成难以弥补的影响。

为避免出现大意失荆州的情况,将所有的分析结果进行落实,整理成一套分析明确、注释清楚、逻辑合理、流程清晰的详设文档。

谁来负责?

3、制定

以我们项目组为例,总共三十余人,其中开发人员超过二十,每人负责三个大的业务模块。(注:所谓大的业务模块,指模块开发时间超过两个月

每个业务模块要编写流程文档和接口文档,每个文档完成后需要进行组内评审,审核通过后作为开发文档封存定版。

待所有文档书写完毕后,将所有文档合而化一,于是一个长达一千五百页的接口文档便诞生了,我的天呢!

4、审核与确认

审核也是这一环节中相当有意思的一处,为什么呢?

要说简单,也很简单,只需要查看文档的内容是否按照商议的版本一致;

要说困难,是否大处留心,小处细心。切勿出现会上商议妥当之后,进行一些文字上的小动作,或许无心,或许有意,小变更,大麻烦。

5、维护

这项工作最好由专员来处理,而且每次变更都要有修订的记录。尤其是多系统平台配合的开发工作,标注鲜明,注释明确,避免扯嘴炮的情况,不留下点东西,怎么行?

 

至此就完了吗?

想多了!!!

这不是一条线,而是一个圈,甚至都不知道起点在哪里,一个新的圈圈就诞生了。

项目中,需求没有永远的定稿,业务没有静止的需求,并行时时刻刻都在,功能眨眼之间已不是从前。

 

1、大型项目经验分享——业务需求篇

标签:公司   注释   维护   书写   封存   避免   每次   进行   处理   

原文:https://www.cnblogs.com/stobird/p/8447197.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号