軟件公司組織結構變更引發(fā)的客戶信任危機

申請免費試用、咨詢電話：400-8352-114

某IT公司軟件事業(yè)部，原先是項目團隊式的組織結構，按業(yè)務區(qū)域分4個業(yè)務團隊，每個團隊20余人，拿項目、跑合同、項目研發(fā)與實施、維護都是各團隊自行包干，另有一質量部做項目質量管理。原先團隊的主要問題：
　　1、業(yè)務團隊因為是按年度考核，因此想做好只能在經營上急功近利，項目開發(fā)質量不受重視，一切向錢看；
　　2、各業(yè)務團隊存在工作量不均衡現象。有些團隊項目多得做不完，有些閑的沒事干；開發(fā)人員資源浪費嚴重；
　　3、質量管理很難執(zhí)行。因為各團隊的技術人員都是由業(yè)務團隊經理負責考核，質量主管考核權很小，而且即便落實考核了業(yè)務團隊經理也能在年終用年終獎給“補”回來。
　　年初，為了有效解決上述問題，該事業(yè)部打散業(yè)務團隊，改為銷售支持部－咨詢服務部（含項目經理、軟件項目經理）－開發(fā)服務部（都開發(fā)人員）－維護服務部（運維人員，但不做開發(fā)）－質量部的矩陣式結構，當前已經運作半年有余。  
　　最近間接得到一客戶的反饋，她對新的組織機構變更持不認可、不信任態(tài)度。認為有以下幾點問題：
　　1、針對客戶的需求，響應變速度慢了。必須要先找銷售，銷售再找咨詢服務部確認軟件項目經理，由軟件項目經理落實設計方案，最后才能交到開發(fā)部確認具體開發(fā)人員執(zhí)行實施。 以前她直接到對口的業(yè)務團隊辦公室，業(yè)務團隊經理會立即安排成立對應臨時項目組落實執(zhí)行，甚至她直接找對口的技術人員都行，而現在開發(fā)人員她根本接觸不了（不認識、不確定、即便認識了確定了也不會直接聽她的安排）； 
　　2、團隊間存在斷層－很奇怪她怎么知道這些扯皮的事情，可能哪個項目經理給她抱怨過。如咨詢服務部作出的系統(tǒng)整體設計，開發(fā)服務部可能不認可（比如開發(fā)達不到設計要求、設計報告寫的不明確不予接收、軟件項目經理要求的進度無法保證）；或者是銷售支持部提出的報價方案，咨詢服務部不認可，等等之類。
　　3、開發(fā)水平不足?，F在開發(fā)服務部基本都是工作不足3年的員工執(zhí)行編碼（而且對相應業(yè)務不一定熟悉），而原先客戶有直接對口的固定業(yè)務團隊，都是由團隊內5年以上的軟件項目經理直接實施開發(fā)，而且這些技術人員都是常駐在客戶處，對客戶業(yè)務很熟，偶爾有新加入的開發(fā)人員，因為常駐客戶那邊，因此感覺也和現在大不一樣；
　　4、小型任務處理麻煩。以往開發(fā)個簡單的報表、開發(fā)個數據庫接口之類的任務，直接找到業(yè)務團隊經理，會安排個人立馬1～2天就搞定了，不用簽合同，下次做項目多算1~2天的費用就ok?，F在這樣的基本沒法做－基本上是必須簽合同，要么就要協(xié)調一堆人，而且往往一周能完成就不錯了。考試大收集整理
　　由此，這個客戶今年引入了一家本地小型軟件公司，這個公司基本就和軟件事業(yè)部以往的那種服務方式差不多...... 
　　我認為該公司新組織結構的調整帶來了以下好處：
　　1、質量管理提高了。開發(fā)人員當前的計劃、實際工作量可以核算到天，各類項目文檔齊備；
　　2、用戶界面、系統(tǒng)底層框架等開發(fā)風格統(tǒng)一了；
　　3、項目整體的技術水平比以往有了很大提高； 
　　4、開發(fā)人員冗余、工作量不均衡情況少了；開發(fā)人員可以招聘單純的代碼人員了；
　　5、身兼數職的人少了，各部門專業(yè)化程度得到了體現，具備了承接大中型項目實施的基本條件。
　　當然也有缺點：
　　1、各團隊有扯皮現象，這個是矩陣式組織結構的通病。以往的業(yè)務團隊經理，在協(xié)調項目各環(huán)節(jié)上的能力相當于現在的事業(yè)部總經理；
　　2、用戶因為需求變化較快，所以項目質量的提高好像用戶體會不到（一個項目周期最多就1～2年，你做的再好－BUG率<95%又怎么樣，項目文檔再完整又能如何?）； 
　　3、沒有流程管理或項目協(xié)調推進之類的崗位。原先設計了一個，公司沒批。于是100人的事業(yè)部基本是自己內部在整，內耗～海了；  
　　4、項目質量要求的提高、項目管理水平的提高，近期直接造成了對外項目報價的提高。
　　已經7月了，新的組織結構能不能確保年內目標的落實呢？去年這個時間事業(yè)部是盈利的，現在賬面卻是虧的。