文档介绍：某部门机构改革方案建议

部门已经发展到40多人的规模，如何完善与战略相匹配、责/权/利/流程相统一的组织架构，已经是迫在眉睫的事了。为了建立高效的专业的战略驱动的责权利与流程相统一的组织架构，提出初步建议方案。概述如下：
当前机构的主要问题：
1、大多数人员从事简单重复的研发工作，业务分析不深入，使系统难以充分满足客户需求，造成项目难以验收；
2、部门规模扩张快，在建项目多，资源没有得到有效利用；项目范围、进度、成本和质量没有有效的控制；
3、产品和项目的复用缺少平台的有效支撑，产品与项目之间、项目与项目之间难以有效复用；
4、大多数研发人员疲于应付多个项目开发和多种角色的切换，开发质量不高，
形成恶性循环。
5、员工技能得不到有效提升，看不到职业发展方向。
组织机构改革的要点是：
1、由系统分析师和业务咨询人员组建业务与分析组，打通从业务到系统转换的通道；
2、成立强力的项目管理办公室，强化多项目开发过程管理，持续提升项目按期保质保量交付能力，统一调配项目资源；
3、平台研究和产品开发按项目组织，强化管理与控制，防止目标偏移，促使战略目标的有效达成，保证平台的优先实现；
4、专业化分工，构筑干扰防火墙，使员工专注于专业工作。
5、为有管理潜力、有技术潜力、有业务潜力的员工提供专业化的发展机会。详细建议如下文。
现状分析
目前部门的组织架构如下图所示：
1、平台组负责平台研发，有五名成员，Delphi高级开发工程师一名，UI开发工程师两名，Java开发工程师两名，虽然有五名成员，但技术分散，难以快速研发出适应产品和项目需要的技术产品，难以解决项目和产品棘手的难题。由于不是以项目型运作，日常大量时间投入在支持项目和产品的具体技术问题的解决，战略型的平台任务进展缓慢。进而使产品和项目的复用缺少了平台的有效支撑，项目与项目之间、产品与项目之间难以有效复用。
2、产品组负责标准产品开发，同时担负多个产品型项目开发，有七名成员，组长一名，高级开发工程师两名，开发工程师3名，开发员一名。产品可以为项目开发基础，但项目的定制开发工作量还比较大，产品的可配置性、业务成熟度、稳定性还有待提高。产品只针对了单种业务模式设计，与客户需求有较大偏差。而产品中的最佳实践传递到项目的周期长。一方面，项目不能充分理解产品设计思路和可以应对的场景，另一方面，产品不能从项目得到快速有效的反馈，来改进产品。目前产品虽然承担了部门产品型项目开发，但这对产品改进的投入带来了冲击。产品无法按计划发布版本。
3、项目开发组：两个项目开发组均有9名左右成员（含实习生），在建项目一组14个，二组9个，由18人承担着23个在建项目。其中一半的人员是软件经理，项目组织往往是一位软件经理和一名开发工程师开发。项目开发组人员大多承担重复性的缺乏新意的工作，而项目迟迟不能收尾，不能被客户运行起来，进行使开发人员广泛缺少成就感。没有成就感对软件工程师而言，是令人沮丧的。这是部门潜在的重大风险。急须找到有效的应对措施。疲惫之师，难以为战。太多的软件经理，太小的开发团队，不利于技术人员的成长。
4、维护组：维护组承担历史项目和项目开发组压力太大而基本完成编码工作项目的维护