|
[原创]软件公司组织结构变更引发的客户信任危机某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月了......新的组织结构能不能确保年内目标的落实呢?去年这个时间事业部是盈利的,现在账面却是亏的......
责编:张赛静
微信扫一扫实时了解行业动态
微信扫一扫分享本文给好友
|
|
|