软件公司组织结构变更引发的客户信任危机

转自：http://www.amteam.org/k/PM/2008-7/612551.html

 

某IT公司软件事业部，原先是项目团队式的组织结构，按业务区域分4个业务团队，每个团队20余人，拿项目、跑合同、项目研发与实施、维护都是各团队自行包干，另有一质量部做项目质量管理。原先团队的主要问题：

 

1、业务团队因为是按年度考核，因此想做好只能在经营上急功近利，项目开发质量不受重视，一切向钱看；

2、各业务团队存在工作量不均衡现象。有些团队项目多得做不完，有些闲的没事干；开发人员资源浪费严重；

3、质量管理很难执行。因为各团队的技术人员都是由业务团队经理负责考核，质量主管考核权很小，而且即便落实考核了业务团队经理也能在年终用年终奖给“补”回来。

 

年初，为了有效解决上述问题，该事业部打散业务团队，改为销售支持部－咨询服务部（含项目经理、软件项目经理）－开发服务部（都开发人员）－维护服务部（运维人员，但不做开发）－质量部的矩阵式结构，当前已经运作半年有余。

最近间接得到一客户的反馈，她对新的组织机构变更持不认可、不信任态度。认为有以下几点问题：

 

1、针对客户的需求，响应变速度慢了。必须要先找销售，销售再找咨询服务部确认软件项目经理，由软件项目经理落实设计方案，最后才能交到开发部确认具体开发人员执行实施。 以前她直接到对口的业务团队办公室，业务团队经理会立即安排成立对应临时项目组落实执行，甚至她直接找对口的技术人员都行，而现在开发人员她根本接触不了（不认识、不确定、即便认识了确定了也不会直接听她的安排）；

 

2、团队间存在断层－很奇怪她怎么知道这些扯皮的事情，可能哪个项目经理给她抱怨过。如咨询服务部作出的系统整体设计，开发服务部可能不认可（比如开发达不到设计要求、设计报告写的不明确不予接收、软件项目经理要求的进度无法保证）；或者是销售支持部提出的报价方案，咨询服务部不认可，等等之类。

 

3、开发水平不足。现在开发服务部基本都是工作不足3年的员工执行编码（而且对相应业务不一定熟悉），而原先客户有直接对口的固定业务团队，都是由团队内5年以上的软件项目经理直接实施开发，而且这些技术人员都是常驻在客户处，对客户业务很熟，偶尔有新加入的开发人员，因为常驻客户那边，因此感觉也和现在大不一样；

 

4、小型任务处理麻烦。以往开发个简单的报表、开发个数据库接口之类的任务，直接找到业务团队经理，会安排个人立马1～2天就搞定了，不用签合同，下次做项目多算1~2天的费用就ok。现在这样的基本没法做－基本上是必须签合同，要么就要协调一堆人，而且往往一周能完成就不错了。

 

由此，这个客户今年引入了一家本地小型软件公司，这个公司基本就和软件事业部以往的那种服务方式差不多......

......我认为该公司新组织结构的调整带来了以下好处：

 

1、质量管理提高了。开发人员当前的计划、实际工作量可以核算到天，各类项目文档齐备；

2、用户界面、系统底层框架等开发风格统一了；

3、项目整体的技术水平比以往有了很大提高；

4、开发人员冗余、工作量不均衡情况少了；开发人员可以招聘单纯的代码人员了；

5、身兼数职的人少了，各部门专业化程度得到了体现，具备了承接大中型项目实施的基本条件。

 

当然也有缺点：

1、各团队有扯皮现象，这个是矩阵式组织结构的通病。以往的业务团队经理，在协调项目各环节上的能力相当于现在的事业部总经理；

2、用户因为需求变化较快，所以项目质量的提高好像用户体会不到（一个项目周期最多就1～2年，你做的再好－BUG率<95%又怎么样，项目文档再完整又能如何?）；

3、没有流程管理或项目协调推进之类的岗位。原先设计了一个，公司没批。于是100人的事业部基本是自己内部在整，内耗～海了；

4、项目质量要求的提高、项目管理水平的提高，近期直接造成了对外项目报价的提高。

已经7月了......新的组织结构能不能确保年内目标的落实呢？去年这个时间事业部是盈利的，现在账面却是亏的......