谈谈软件部门组织架构

组织架构往往说的是人员的功能组成结构,通常是根据完成功能不同,将整体功能分块成各个功能小块,然后在可能的情况下各功能小块继续划分下去。一般大型的现代企业,往往都有相对独立的软件部门,有的甚至以公司的形式运营。这个部门或公司的主要功能就是为整个企业提供信息化支持,支持业务发展的需要,完成业务部门的信息化需求,为企业提供信息化解决方案,促进企业高效的投入到现代化的市场竞争中去。

企业信息化往往会需要完成很多现实的业务功能,我们将此称之为项目,比如往大了点说:有销售系统,HR(人力资源系统),财务系统,客户关系管理系统等等各个项目,而负责这些项目的需求分析,设计,开发,测试,支持整个软件周期的统一负责人我们称之为项目经理,他全权掌握着这个软件进度,人力资源的调度使用,对使用这个软件的用户负责。这样的项目组织架构有以下几点好处:一,责任明确,项目经理是这个项目的全权负责人;二,需求与开发紧密结合,项目经理能将最先得到的需求资料通知到开发人员;三,在项目内部不存在推诿,项目组的目标统一就是完成整个项目,所有的开发,测试,及支持人员都对项目经理负责,内部沟通通畅。在企业庞大,信息化项目多的时候也会有以下几个需要面对的问题:一,很多情况下多个项目的项目经理是同一个人;二,项目之间也有闲时与忙时,闲时的项目开发人员无法及时分配到忙时的项目中去,某种意义上讲增加了软件开发的人工成本。

 一般情况下,软件开发的重点及难点往往在需求分析和代码开发阶段,投入的人力与时间成本往往也是最多的。相对而言软件的测试及支持的人力成本会少些。多数情况下,测试人员往往会负责测试多个项目,同样支持人员也是如此。在项目繁多的情况下,可不可以有这样的组织架构:一,统一所有的开发人员组成开发团队,由开发经理协调调度,负责所有项目的开发工作;二,有专门的需求团队,由需求团队的经理负责所有项目的需求收集与分析,并将需求提至开发经理;三,测试团队负责所有项目的测试工作,四,支持团队负责所有的支持工作。上面的组织架构方式就是将软件工程的各个阶段划成各个团队,分别完成各个阶段的所有工作。这样的组织架构有这样的好处:一,需求团队可以将需求做的更加细致;二,开发团队中的成员可以在各个项目轮转,以团队方式完成所有开发任务。这样组织架构,我需要提出几个问题:一,项目的实际负责人是谁,开发经理肯定不是,需求经理,可以当做是,但是,需求经理往往有多个项目,且无法控制开发团队,无法掌握项目的根本开发进度,另外,需求团队中并不是所有人都是经理级别,在与开发经理沟通过程中会不会存在理解上的误差;二,如果在开发上存在沟通不畅造成错误的情况下,谁承担责任,会不会有扯皮的情况;三,开发人员不对需求经理负责,因此所有的开发变化都需要经过开发经理,在项目众多的时候,开发经理的任务及工作量会相当的大,这对整个开发团队并非好事。

 如果从项目经理架构方式转变到软件工程阶段的架构方式,会有两点明显的转变。一,需求经理需要了解所有项目的需求信息,二,开发经理也同样需要知道所有项目的开发情况,这个转变需要很多的时间成本,三,团队中的开发人员也需要进行角色的转变,需花时间去了解其他项目适应各种开发任务。当项目少时,这两种方案没有太多的区别,如果项目有十几二十个之多,这对需求经理,开发经理都是个非常大的挑战。当然,就如上面所述的根据软件工作周期安排的组织架构值得去尝试一番。特别是在需求都很明确,清晰的情况下,开发经理可以通合理的工作安排,时间分配,将所有的开发任务尽可能早的完成。另外,需求经理需要承担项目经理的角色,更多的参与业务的讨论,并需要更多的监控项目的质量,将更好的软件为用户和企业提供最完美的服务。

您可以选择一种方式赞助本站

支付宝转账赞助