专业的需求分析团队应该如何建立？ - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

nunton 发表于 2013-3-20 19:31

我个人觉得，如果纯BA,也就是说作为一个沟通和翻译的机器，那么是可以放在科技部门，
但是指望BA直接和业 ...
--BA，业务分析，是项目中的角色，不是部门和条线的角色。在项目组织中，BA侧重的是的分析，不是用户。是项目的重要成员，也有可能由业务职能部门成员兼任。
--按项目生命周期参与，详细说明略，详见项目管理理论。
--方法论和支持工具就是需求管理流程，按项目生命周期走，主要是为了保障项目成功。
总之，BA在职能部门就是一个职称，在项目里就是一个角色。
就如某客户经理，在某分行，但还是零售条线，组织上是矩阵管理。
再比方，某条线总助，担任项目经理。
在IT企业里的角色，BA定位比较清晰：从分析银行业务需求，到系统业务架构设计，业务模块划分，数据模型，测试案例，甚至包括操作手册等工作；
在银行里，BA的存在有点尴尬，倒不如说成是产品经理。
从开发到需求分析，需求分析做了4,5年，现在带项目。还是感觉做需求分析更轻松，呵呵。
BA也好（业务分析）,SA也好（系统分析），最关键是看这个人干的是不是良心活，如果不是良心活，产出文档再漂亮，PM也会无比痛苦的一直擦屁股。
所以个人有个建议，不管需求分析团队，制度是怎么建的。需求分析产出需要有严格的考核标准，包括系统上线后有缺陷是因为需求分析遗漏导致，也要有对应的惩罚措施。
我接触的有将需求分析团队不能说放到技术部门我只能说是与科技部隶属同一个更大的部门。
需求组主要成员均是之前全程参加过开发的业务人员（这样的人数真的不多，我知道的部门也就几个人）；
我主要说以下目前比较多的需求变更的流程
现有系统的业务需求变更，做法是 分行或者总行部门按照统一模版提出需求，提交至需求部门，需求部门进行初审，将一些明显的错误或者无法实现的反馈至分行，下一步提交的技术部门相关的功能切分组，然后分配制各个相关业务系统的技术部门进行技术分析进行反馈，然后技术部门、需求部门、提交需求的业务部门进行评审后最终形成可开发的需求CR进入科技组进行开发。
现有系统的业务需求变更，做法是 分行或者总行部门按照统一模版提出需求，提交至需求部门，需求部门进行初审，将一些明显的错误或者无法实现的反馈至分行，下一步提交的技术部门相关的功能切分组，然后分配制各个相关业务系统的技术部门进行技术分析进行反馈，然后技术部门、需求部门、提交需求的业务部门进行评审后最终形成可开发的需求CR进入科技组进行开发。
----------
我多少有点担心效率问题。
对我们来说，类似的情况已经出现了
家住海淀 发表于 2013-3-25 13:23

现有系统的业务需求变更，做法是 分行或者总行部门按照统一模版提出需求，提交至需求部门，需求部门进行初审 ...
如果业务需求频繁的话，这个很折腾具体开发人员时间的，开发人员精力都花在评估上了
家住海淀 发表于 2013-3-25 13:23

现有系统的业务需求变更，做法是 分行或者总行部门按照统一模版提出需求，提交至需求部门，需求部门进行初审 ...
这样有好处也有坏处，一般对于普通业务需求，这个流程虽然慢，但是清楚而且不会出现胡提需求的情况，作为总行科技部或者开发中心，必须对每一个需求有计划去落实，开发人员就那么多，不可能无限制扩张只能按计划一个一个来，而且现在大多数银行系统都是总行集中式的，如果不做统一接口人或者分析，肯定会出现需求与需求之间矛盾的出现。
我的感觉是，总行集中式系统，测试-上线得按照每年几次季度版本进行需求优化，不然乱了。对于分行特色业务可以简化一些流程
nunton 发表于 2013-3-25 15:25

如果业务需求频繁的话，这个很折腾具体开发人员时间的，开发人员精力都花在评估上了
如果一个分行对于某个系统提出10个需求，9个被退回去，其中又有3个总行评定为无理需求，基本都是分批此按季度提出。我说这种情况是分行向总行提交需求的手段和方法，从分行看来比较繁琐，从总行看来至少是目前来看杜绝不合理需求的比较好的方法了。
分行提出需求，是要先到项目室，项目室再分配给总行对应业务产品经理，产品经理评估，退回部分无效需求，再提交项目室，然后再才到科技部