為什么企業(yè)內部的軟件開發(fā)部門，做不好為本企業(yè)開發(fā)的軟件呢？ 本文嘗試分析其中的奧秘。 ==============================================

　　最近有一個長期客戶，汽車行業(yè)排名前列的，開始進行自建軟件開發(fā)部門，逐步代替原有的每個項目挑選軟件供應商、談合同的合作方式。此客戶是我們公司的主要客戶，對我們的影響也很大。作為乙方，我們只能嘗試逐步向外開拓其它業(yè)務，同時觀望其后續(xù)結果。
　　一年多下來，據(jù)了解，其成績并不理想：項目完成周期長、質量也堪憂，交付的軟件，都要多次修改，才能逐步向能接受的質量靠攏。

　　當然，我個人來說，我從一開始就不看好"非軟件行業(yè)公司自建軟件開發(fā)部門"。

　　作為 1996 年大學畢業(yè)的 IT 業(yè)資深人士，耳聞此類事情不少，也親身經(jīng)歷過一次。之前在某美資500強 IT 公司工作，其建立了一個軟件中心，用于對公司內、外提供開發(fā)軟件服務。對外的軟件項目，限于軟件行業(yè)合同的規(guī)定(大多是先完成軟件、后付款，能爭取的最有利的不過是分階段付款)，不得不爭取做好，以便獲得客戶的認可，期待客戶及時進行確認收料(收貨)，按計劃收款。對內部服務的軟件項目，則質量只能說是湊合，勉強能用罷了。

　　為什么會有這種差異呢？為什么企業(yè)內部的軟件開發(fā)部門，做不好為本企業(yè)開發(fā)的軟件呢？

　　本文嘗試分析其中的奧秘。

　　首先，現(xiàn)代工商業(yè)的發(fā)展，導致行業(yè)工作細化，其結果，則是很強烈的“學習、模仿、創(chuàng)新、超越”模式。
　　舉例來說，開飯店的老板，一般都是原來在其他飯店里做廚師、經(jīng)理、招待員或學徒，有了一些工作經(jīng)驗，加上自己平時學習、琢磨所得，在合適的機會，然后自己出來開飯店。這樣比較容易成功。
　　原本做司機、泥瓦匠工作的，智力與上述差不多的人，直接轉行開飯店，比較容易失敗。

　　究其根源，在于“從無到有”是很難的一件事，需要非常聰明的頭腦、加上大量的時間，才能琢磨出一個陌生新行業(yè)的可能正確運營模式。相比較而言，單純的"學習/模仿"則是比較省時間的。

　　新創(chuàng)業(yè)的，如果花大量時間去想廚師和切菜是否要兩個人的問題，則可能來不及開張賺錢，已經(jīng)在不停支出各種費用情況下破產(chǎn)了。

　　"地球繞太陽轉"，這個道理從無到有，歷經(jīng)了很長時間(很多年)。而學習這個知識，只需要很短一點時間(幾天)。

　　結合本文的問題來說，一個非軟件行業(yè)公司的管理人員，想從頭建立一個軟件開發(fā)部門，從零摸索，跳過"學習/模仿"階段，憑空想出一些規(guī)則，是不管用的。見過電視上高級廚師炒菜，并不等于能直接學到、直接拿來用。這里面包含的學習、練習，時間、精力、成本是省不掉的。
　　且外行的總管人員，所設想的規(guī)章制度，是否有效，需要時間來驗證(這里面如有浪費，浪費的是公司的錢。但非軟件行業(yè)公司自建軟件開發(fā)部門，本就難以考慮自負盈虧之類的事情)。

　　當然，如果是一個全新的行業(yè)，若干競爭公司，都從零摸索，則沒有問題。

　　其次，不同的工作模式及要求，會導致最終做事方式及質量的很大差異。
　　軟件公司有盈利的生存壓力，需要在滿足客戶質量要求、時間要求、成本投入等方面進行管理與平衡，而企業(yè)內部軟件開發(fā)部門則相對壓力小。這會導致兩者做事方式千差萬別。

　　軟件公司一般分軟件產(chǎn)品研發(fā)、軟件項目合同開發(fā)、特定技術的年度支持/服務等，撇開冠冕堂皇的說辭，時間管理、成本管理是優(yōu)先考慮的，質量管理則因人而已，看各公司的重視程度與能力；企業(yè)內部軟件開發(fā)部門，以項目、變更類居多，"避免弄出大事情"是首要考慮的，時間要求相對寬松，成本方面如果無特別管控則會很夸張的失控。相對而言，純軟件公司在成本費用控制上，很少導致"很夸張的失控"這種程度。
　　企業(yè)內部軟件開發(fā)部門以"避免弄出大事情"的原則與心態(tài)去工作，各方面人員遵守公司規(guī)章與紀律，看上去沒什么問題，實際上導致"人人負責、無人真正負責"的狀態(tài)。

　　家庭主婦做菜很少有餐飲行業(yè)那樣”哆哆哆．．．”快速切菜的，家用炒鍋、湯鍋等工具的選擇，與餐飲行業(yè)差別很大；兩者人員分工、操作流程之類的，完全不同。這也導致最后的成品質量差別很大。之所以有這么大的差異，在于其要求不同：家庭即便炒菜不好吃，只要不太難吃，一般不會要求換人做。有時即使想換也因各種因素換不了(老媽炒菜難吃就要求換成老爸炒菜？你一個娃有多少說話的權利？)。"企業(yè)內部軟件開發(fā)部門"也會有類似的情況。
　　基本要求不同，導致工作方式及相關規(guī)定都不同，項目中采用的軟件技術也很可能不同。隨時間的推移，非軟件行業(yè)公司自建軟件開發(fā)部門與純軟件公司，能力與效率的差距越拉越大。

　　第三，"企業(yè)內部軟件開發(fā)部門"往往以企業(yè)原有人員，作為核心人員，組建軟件開發(fā)部門。
　　這些人員，未經(jīng)歷在“純軟件公司”以乙方人員身份參與市場競爭，很難以了解軟件公司／行業(yè)是如何運行的。基于"領導英明、領導賞識我、讓我負責我就負責”的簡單邏輯，不顧自己的能力與經(jīng)驗，也容易導致失敗的結局。

　　至于為何以企業(yè)原有人員作為軟件部門核心人員，而不是從已有運行良好的軟件公司，挖項目經(jīng)理、架構師、高級軟件工程師、軟件工程師、測試經(jīng)理、測試人員等有經(jīng)驗者，一方面非軟件行業(yè)公司薪資上未必有吸引力，只能去招聘新畢業(yè)人員，另一方面，負責招聘人員未必有足夠的能力，去挑選這些技術或管理人員中的優(yōu)秀者。國內有名的某度公司還招聘到一個極不靠譜的設計什么總監(jiān)。
　　除招聘之外，正常企業(yè)運行過程中，提拔優(yōu)秀的軟件項目管理、技術人員，在非軟件行業(yè)公司，是一個難以完成的事情。

　　第四，獎懲制度上，非軟件行業(yè)公司的靈活性相對差一點。
　　"獎功罰過"(獎勵有功的，處罰有過錯的)，純軟件公司容易實現(xiàn)，非軟件行業(yè)公司很難實現(xiàn)。
　　軟件公司對外做軟件項目，如果客戶提出要求換項目經(jīng)理、技術架構師，對軟件公司來說，如果有人可換，并不是一件很為難的事情。項目里的角色，本就是臨時性的。這個項目的某個乙方成員，與甲方吵了，換到另一個客戶合作的軟件項目，對乙方軟件公司來說毫無壓力。
　　非軟件行業(yè)公司做類似事情，難度大很多。組織架構/部門組成，期望相對穩(wěn)定，不能隨意變動。業(yè)務方不滿意，就換項目經(jīng)理或架構師？好難操作啊。

　　第五，軟件開發(fā)行業(yè)，關鍵人員的差異性非常大。
　　軟件公司往往能很快意識到這一點，而非軟件行業(yè)公司，往往意識不到這一點，或者需要很多年、吃過很多教訓后才稍微了解一點。
　　非軟件行業(yè)公司很容易把它們已有的行業(yè)經(jīng)驗"招聘新手、培訓兩周、發(fā)員工規(guī)章手冊/注意事項，開工！"套到軟件部門。這種思維是如此的根深蒂固，即使他們發(fā)現(xiàn)有的項目做失敗，只更換少數(shù)幾個關鍵角色，就可大幅改進，他們還是很快就會回到原有的思維模式上。這也許就是企業(yè)的基因吧。

　　第六，項目中使用"資源池"的做法早已被證明是低效的。
　　早些年，IBM 等大公司，憑借自身的名氣，在國內承接各種大的軟件項目，然后召集與其合作的小型軟件公司，以“全包”(IBM不出項目經(jīng)理及架構師) 或者“半包” (IBM出項目經(jīng)理及架構師，合作軟件公司出低級別角色的人員)的形式，進行軟件開發(fā)。這些參與合作的小型軟件公司，對于IBM 來說，也就是“資源池”。
　　事實證明，此做法往往不如將軟件項目交給一個中小型軟件公司以全部自有人員進行開發(fā)。
　　究其原因，在于其中的角色分工，導致責任分離，一旦出現(xiàn)故障，難以區(qū)分問題在哪一方。誰來調查問題？IBM 來調查？它很有可能都把問題推到合作的小型公司身上。甲方來調查？甲方未必原有投入足夠的人力資源去調查，且未必有足夠的能力去區(qū)分IBM及其合作伙伴各負擔多少責任。
　　非軟件行業(yè)公司自建軟件開發(fā)部門成立"資源池"，也會有類似的問題。
　　這種事實上是轉包的方式，往往存在層層轉包，費用逐步大幅下降、工期逐級壓縮，最后真正干活的公司，拿到的錢非常少，難以派出高水平的人員，只能以低水平的人員勉強完成項目。

　　不僅是很多企業(yè)，相關法律也在竭力避免這種轉包方式。

　　我很奇怪的是，此汽車公司，以前對于乙方軟件公司，承接項目后引入外部人力資源公司的程序員/測試人員，非常反感，極力要求乙方以自有人員來完成項目，減少不可控因素。現(xiàn)在輪到自己的軟件開發(fā)部門來承接軟件項目，卻主動規(guī)劃使用“資源池”的方式，來提高整體靈活性。如果甲方自己的軟件開發(fā)部門使用“資源池”的方式可提供整體靈活性，為何以前要反對乙方軟件公司使用“資源池”的方式承接項目？

　　使用"資源池"的合作方式，有一個管理上的假設前提：資源池里，人與人的差異可忽略，只看每個項目借用的人天數(shù)，折算成相應的費用金額。現(xiàn)在的技術發(fā)展導致技術多，技術人員在經(jīng)驗上往往有所偏重，比如某人連續(xù)幾個項目都做報表模塊，下個項目中，換一個從未做過報表模塊的新手，可能工作效率不如此人的一半。只看人天數(shù)不看具體人員是不妥當?shù)?/strong>。唯一看上去理論上可行的是，對“資源池”里的每個人，進行逐個項目打分，進行打分，不同打分對應不同單價，對后續(xù)主持項目的負責人可見，其在挑選“資源池”里的人時，可借此打分/單價來選定人員。這個做法的實際可操作性太小。

　　甲方管理人員所不知道的是，寫軟件，如同作家寫文章。也許小學畢業(yè)以上的，人人都會寫文章，但不同的人，最后的完成質量與效率，差異很大。乙方純軟件公司，往往以“能者多勞”的方式，讓最能干的人，多干一些活，實現(xiàn)其項目時間計劃，不偏離太多。其背后的激勵機制，在于獎懲制度的靈活性。甲方“資源池”方式，想以“能者多勞”的方式，借以掩蓋管理人員的技術外行及計劃的不合理，因甲方激勵機制的局限，難度大很多。

　　第七，期望以傳統(tǒng)行業(yè)的流水線分工位的方式來進行軟件開發(fā)，則更是不可行。
　　傳統(tǒng)行業(yè)的流水性方式，分工位，在于其一旦發(fā)現(xiàn)缺陷，可向上追溯問題根源在哪一個環(huán)節(jié)，且其追溯具有快捷、內部局部范圍內公開的特性。軟件分步驟開發(fā)，計劃是A隊，需求調研是B隊，設計是C隊，開發(fā)是D隊，測試是E隊，部署是F隊，這樣一旦系統(tǒng)運行出故障，能很快追溯到哪個環(huán)節(jié)么？追溯很費力，難以局部范圍內公開。且一旦發(fā)現(xiàn)某個環(huán)節(jié)頻頻出問題，甲方自建軟件開發(fā)部門、“資源池”，能否及時進行人員調整，也很難說。乙方純軟件公司里，項目角色是臨時性的；甲方自建軟件開發(fā)部門，項目角色與其行政級別/部門是強關聯(lián)的，基本無法做到“某人這個項目里做項目經(jīng)理，業(yè)績差勁，下個項目轉為測試人員”。這種差異是致命的。

　　問題一旦沒有追溯追究的習慣，則后續(xù)難以提高各隊人員的責任心。“有錯不罰”，還想帶好隊伍？哪有那么容易的事情。

　　另外，使用外部純軟件公司進行項目合作，可以很輕易地把那些極不合格的乙方公司，排除在未來的采購供應商名單中。對于非軟件行業(yè)公司自建軟件開發(fā)部門，如何處理類似事情？把水平很差的人開除？或列入黑名單？都有為難之處。