上一次，寫了一篇文章《三五個人十來條槍 如何走出軟體作坊成為開發正規軍》，反響異常激烈。
我的一個朋友也看到了我的博文，他是做某個行業企業管理軟體的。他說：你這個方法，在我從事的行業不適用。
我對他從事的那個資訊化的行業還是有一定了解的。
他們的實施模式是：
1一個實施專案，大約50萬的簽單額，做完驗收後給最後的20%-30%的尾款。
2他們是一家小公司，為了多做專案多賺錢（企業都希望利潤保持的很高，如果毛利低，做軟體就不合適了，受的苦和壓力和不規律性比其他行業多的多），所以一個專案只派一個人去，而這個人需要培訓、輔助匯入舊系統資料、清洗合併資料、規範化資料、報表製作、需求協調、推動切換上線、現場執行監控、個性化定製修改程式碼。
3如果不能推動客戶上線，就無法驗收結項。不結項，就無法去追尾款。
4一個專案這個人，身兼專案經理、開發員、需求調研、軟體設計、功能測試、實施培訓、定製化開發，還有時候寫培訓文件。因為公司裡都是這樣的人，根本沒有分工出專門的文件人員，所以產品根本沒有培訓手冊和幫助手冊。除非客戶必須要，這個專案的這個人才寫一份草稿應付。而公司又沒有人來做文件管理工作，所以各個專案各個人寫，也沒有人合併，也沒有人來統一收集。每個文件都在專案每個人的行動硬碟裡。
5由於專案就老哥一個人全活兒，所以自己答應了客戶修改什麼需求就自己修改，根本沒有啥需求調研方法和版本管理方法，就看這個老哥和客戶之間的博弈了。每個專案一套原始碼，而且都在各個專案的各個人手裡。返回公司後，往公司的伺服器上一扔做個備份。以後誰的專案出了問題或需求，就誰負責繼續修改。但是，很有可能這個人已經在做其他專案了，還需要修改前幾個專案的需求或BUG，還需要接聽前幾個專案的支援電話。如果這個老哥是在頂不住壓力和焦慮而跑路了，只能把這些所有的活交給現存活的人的手裡，啥也沒有。無法交接也得交接，反正人要跳槽。
6由於每個人都是這樣一人擋一攤或數攤專案，而且專案週期長，每個專案都需要2-3個月的時間。老闆也想把公司做大，但是每個專案能去實施的人，要求都非常的高，新人來了一年也上不了前線幹不了活。所以，對招新人也是不願意招，乾花錢沒見起作用，小公司培養不起人。而對專案遊刃有餘的人，都是跑單幫跑慣了，帶著個新人，還幹不了活，還浪費出差費用，真是氣死人了，還不如自己親自動手三下五除二搞定爽。
於是，公司五六年了也就那麼大規模，老闆員工都乾的很辛苦，當然老闆得到的錢要多一些，賺個500多萬沒啥問題，自己後半輩子算是有靠了。所以，老闆也得過且過，反正現在賺錢速度已經比較滿足了，這樣也熟練習慣了，經驗路徑依賴，就這樣順坡下驢做吧。
我的朋友是個理想和現實總是不斷衝突的人。一方面，他確實想把專案做的很是順暢，另一方面，他卻覺得一切都像是被各種因素牽扯，根本無法轉變模式，於是只能認命繼續現在。
我說，你這種情況其實在中國很普遍。中國大部分軟體公司都是從事行業資訊化，因為這塊技術難度最低，而且只要有人脈關係就可以做銷售開幹。而很多軟體公司的成立，就是由於老闆有一個關係，接到了某個專案，於是拉住了某個客戶，小活不斷，於是成立了公司。這是很多老闆成立公司的原因。既然這類公司成立就沒有目標，其目的就是認識幾個人多拉一些專案多賺一些錢，所以如何複製模式，他們其實關注性也不大。原因很明白，就是自己不認識的客戶，要想打入這個單子，很難，每個客戶廟前都有N多關係戶。對於自己有關係的客戶，也就那麼多個，有多大關係就能做多大的攤子，那就儘量從現有客戶中持續做專案。維護好客戶關係是最重要的。這類模式非常常見，並不是你這個行業特殊。
老闆的生活已經趨向於小康穩定，而你呢？你還在掙工資。你也在一線客戶那裡天天呆著，要麼你把老闆的客戶搶過來你做，要麼為了你自己工作能輕快些，你必須自己給自己找方法。
我的朋友說，搶過來不可能。自己雖然天天在第一線和客戶天天在一起，關係也處的不錯。但現在人先認的是錢，後認的是感情。而老闆給他們這幫人都持續吃喝玩樂送東西分回扣，自己只是一個幹苦力的。自己只能找方法。但你說的方法是針對一個公司的變革，不是針對我個人而言的，所以不適用。我想有一個方法能幫助我自己的方法，你幫我想想。
我想了想我過去寫過的文章，確實是，自己一直從事職業經理人操盤產品研發管理，也統管諮詢、實施、培訓、支援，但都是在公司管理的層面上看問題分析問題解決問題，而沒有從一個個體上去思考。而中國，大量像我這樣的朋友，他們需要幫助，而我寫的卻是公司層面的，無法幫助他們，所以他們老說我的文章空洞、理想。
我說，我們們倆一起分析解決。也是給大量像我朋友這樣辛苦的人帶個福音。
我們們首先先說一下你想達到什麼效果。
我朋友說：我現在在這裡待的很煩，出差時間太長了，我就想早點回家。
那你什麼地方費時間了，需要2-3個月在客戶現場？
我朋友說： 嗯，我看完你的那篇文章，我也做了一下反思和總結。我感覺有三個方面特別費時間：客戶需求，資料準備，報表製作。
一去客戶那裡，你是見不到客戶老闆的，也是看不到使用者的，你主要面對的是客戶資訊科的人。他們一開始要求你先做演示，看看是否符合他們本企業使用。在這個演示過程中，就不斷提出需求讓你修改。而且，你不修改完，他們沒法接受你以下的演示，說想象不出後來的樣子，對著你畫的介面圖想象以後的功能變化，有點紙上談兵的感覺。而且，往往演示的時候必須資訊科科長在，否則底下的科員都做不了主，演示了也是白演示。而資訊科科長卻老不在。而他們上班時間也極為規律，該下班時立馬下班，根本不加班。所以邊演示變修改再邊演示。好容易修改完了，也演示完了，時間一倆個星期就過去了。
資訊科算是通過了，就需要錄入基礎資料了。問題又來了。現在大部門企業都已經上過一套軟體了，可能是Foxpro的，也可能是PB的。人家要求你把資料倒進新系統中，但是一看過去的資料，都亂七八糟的，過去上線都是沒經驗，後來也用的亂了，積腋成疾了。現在要匯入，真是要把垃圾輸入，得出來的也是垃圾。你苦口婆心的說服讓他們重新錄入，但是他們一看都好幾千條，不想錄入，讓你能導多少導多少，然後在基礎上再維護。這一鬆口不要緊，你不僅忙活了一個多星期寫各種SQL導資料，而且往往舊系統也沒有文件，資料結構需要你自己理解，理解有誤也是你的事。好容易導完了，再維護，發現資料是通過SQL匯入的，在介面上卻不能維護，因為很多校驗都是寫死在程式裡的，而不是約束在資料庫。磕磕碰碰，自己邊後臺修改資料，邊讓他們資訊科維護。他們資訊科首先先檢驗導進去的資料對不對，沒有填寫齊的欄位填寫齊。然後把沒有導進去的資料錄入進去。然後再列印出來，統一對一遍，看看哪些資料錄入的有錯誤。這樣折騰，一個月，22天工作日就過去了，使用者還沒培訓呢。
第二個月開始使用者培訓了，但一培訓就發現了問題。使用者的需求和資訊科所的需求，根本不是一碼事。原來一個企業，資訊科也和業務科室是兩張皮，就和在軟體公司一樣，開發部和銷售部是兩張皮。於是，使用者和資訊科開始吵架，各說各的道理，誰都在維護自己的利益。而且使用者部門有業務在身，也不可能天天大部分時間泡在IT討論上面，開會不來人，或者要來人也來了個小兵充數，根本起不了決定，還提自己的意見，過幾天開會，使用者部門的主任來開會，又把需求再推翻。業務部門主任是站在主任的層次上看IT管理， 而業務部門科員是站在自己輕鬆使用的角度上提需求，而資訊科是為了自己以後維護著想。不斷的討論不斷的推翻不斷的扯皮。
討論扯皮推翻再討論再修改。終於消停了。開始培訓了。但問題來了，使用者上機一操作，發現基礎資料很多不是平常現實那樣的。計算機資料過去就和現實資料脫離了，現在想借新系統上線再回到計算機管理上。於是，一邊培訓一邊修改資料，有人報告資料錯誤就修改。而培訓沒有文件，培訓也沒有課程，培訓也沒有專業訓練。培訓如何層層開展，培訓如何組織，都不知道。反正就老哥一個被訂在這裡了，只能這麼上手了。人沒有來齊，也得開始。等來了再重新講一次。一次不會，再講一次。有人年齡大打字不熟練，有人看不清螢幕，需要調整大字。一調整，介面發生錯位了。有人不會用滑鼠雙擊和單擊，有人不會控制印表機。過去是UCDOS系統，還沒用過WINDOWS的，用不慣。從基礎培訓起吧。否則怎麼辦呢？人家不上線用起來，人家不給驗收結項啊，尾款回不來啊。
使用者也培訓完了，該上線了，就需要初始化庫存了。先得現實盤點，然後再錄入計算機，還必須一邊得繼續營業。於是，真實庫存和計算機庫存肯定對不上去。由於品種太多，所以只能一批批盤點一批批錄入。
由於操作不熟練，特殊業務不知道如何處理，只能瞎處理。處理完後發現不對，想衝抵回去。沒有衝抵功能，只能修改資料庫中的資料。
由於前期修改，根本沒有測試，就是老哥自己一個人改。改完了有時候煩了連自己都不想測試。於是上線用著用著就不能執行了，需要當時就立即修改，中午晚上的連續作戰緊急解決，否則第二天一早還需要開門迎客。
好容易業務錄入了，但是報表不對。一檢查，原來是前段時間錄入的非法業務資料造成，功能沒想到沒攔住。怎麼辦？偷偷自己修改資料，然後使報表平賬。過段時間，發現報表又不平了，發現還是非法資料進入造成。怎麼進來的呢？想不明白。只好蹲點現場，直到客戶都執行正常了才能走人，算是上線成功。
這個累呀，兩三個月都是緊著過的。好不容易回來休息會，另一個專案就要啟動了，就這麼幾頭能幹活的蒜，老闆笑著臉讓你去。於是，遭遇再次上演，日子就是這麼過來了，一月又一月，一年又一年。頂不住的就跑路。
我聽完了我的朋友的訴苦。我說我們們一件件事情的排查。
第一件事，邊演示邊修改，還得資訊科長在，還得他拍板。這段時間的浪費如入縮短。我過去也作過燈塔客戶的實施，我過去一去了客戶那裡，並沒有一開始就這麼做。我先是調研此次專案組的人員構成、能力、職責、上線時間、使用者計算機能力、使用者部門對上一套系統的最突出的抱怨，資訊科對上一套系統的最突出的抱怨，現在還有哪些系統在持續執行，上一套系統使用者部門和資訊科覺得哪裡好，上一套系統的功能結構和操作流程。這樣，我就確定了我該如何開展專案實施。這就是專案調研階段。人往往很眷戀自己已經習慣的事情。而且人的想法，人的能力，各個部門的利益衝突，人和人的私人關係和恩怨，都有助於專案的推進。亞洲人做事，需要面上的和麵下的都得下功夫。純粹都是正式的或者都是不正規的，都無法做好一個專案。我會在專案調研後，重新建議專案組人員構成、職責、流程、專案階段時間、各方面負責人、本專案的最突出要解決的前5個目標問題。
人常說，上下同欲者勝，廟算者勝。你一開始必須界定好專案的邊界和目標和執行標準和責任人，否則大家誰都想管或者誰都不管，大家沒有目標，或者大家各有各的目標，肯定無法專案很好的推進。
有了目標，責任人、標準、時間計劃，就要按照這個目標來分解做。基礎資料的校驗，需要使用者參與先來校驗原有系統的資料。不要認為使用者現有這套系統就沒有問題。如果沒有問題，企業也不會用你這套來代替他現有這套。所以校驗現有基礎資料很有必要。沒有的資料，先讓他們做準備，但你要書面把要準備的規範寫好交給要參與的各個使用者，而且要做好培訓工作，不能講講就認為他們理解了。有了的資料，需要校驗。地基打好，才能上面很快蓋房子。而且，資訊科和使用者對老系統很熟悉，校驗資料比你快的多，而且準確的多。只有經過他們的確認，你可以導資料，也可以不負責導資料。其實，基礎資料，雖然多，但只要有5-10個人，2-3天就能錄入完畢。比你導更快更準確。
在使用者嚷嚷需求的時候，一定要以系統目標為約束。因為每個人看法不一樣，站的利益角度不一樣，每個人的計算機應用水平也不一樣，所以每個人都有看法。你讓百家爭鳴，而且什麼需求都可以提，沒有目標沒有邊界，就讓你一個人修改，那麼你結果不會好而且你會心身疲憊，你會很快就厭煩了專案。吃力不討好，就是方法不對。需求，一定要圍繞時間階段和目標為約束，大家要一個目標。
還有你剛才講到的沒有培訓方法、培訓文件、培訓素質，說明必須要有專人來做培訓。這塊是專案實施非常重要而且工作量大的一塊。這才是真正的專案實施。專案實施不是讓你來修改需求來了。培訓做不好，上線會出一堆麻煩，軟體再約束不強，報表就是平不了。而培養一個培訓的人員還是容易的。如果想培養一個會協調推進來事的、會修改軟體的、懂得業務需求的、會SQL語句導數的、會培訓的，這樣的專業神人確實很難。而且這樣的神人一定不專業。所以，要帶人，先要讓他搞培訓，而且讓他編寫針對不同使用者的培訓手冊，有培訓時間課程、培訓規範、考試考核、模擬練習環境、模擬資料。這是這個培訓專員可以做到的。
軟體修改，尤其專案型軟體，不修改是不太可能的。我不贊成在客戶處修改軟體。因為不僅僅你只會以事論事的修改，容易陷入到這家客戶具體的需求中，而不會考慮其他客戶的需求相容，所以你修改的軟體有很大侷限性，最後形成只能一家維護一套程式碼，最後客戶越多越累成本越高越不賺錢，被客戶多而拖累死。而且你在現場那麼多事情，那麼多人打擾，你根本無心踏實下來修改軟體，只想著趕快改完上線回家，你急躁，潦草，應付，軟體質量就沒法保證了。你想改變這種現狀，你必須把需求整理好，交給在家裡專門編寫程式碼的程式設計師。你在現場，你也很懂業務，你和你本公司的程式設計師溝通肯定比客戶溝通要順暢的多。
這樣，你在現場，你的任務就是當好一個專案經理，專門協調，控制，理順，制定流程、規範、目標、時間，保證執行到位。現場還有培訓專員分擔你的培訓工作，可以幫助你校驗資料，測試功能。公司裡還有專門coding的程式設計師分擔你的開發測試工作，而且人家寫的程式碼更加多家客戶相容使用，而且質量穩定性比你高。
只有專業分工合作，才能轉成正規軍。否則，你只能把自己熬倒了，心力交瘁，最後心灰意冷，跳槽而走。
從民兵，到武工隊，到土八路，到正規軍。這條路有好幾個階段。不能想著一步到位。現實情況也不容許我們一步到位。我們只能是能改進什麼就改進什麼，天天進步一點，我們就會大變樣。
如果從心裡就認為不可更改，直到心冷不想改進，那麼我們永遠不會進步。
為了我們自己心身愉快，我們也要進步。
記住，你是專案經理。你是這個專案的領頭人。你決定這個專案的成敗。
如果你連這個定位都沒有，那麼你什麼都決定不了，你這個專案的成敗只能隨波逐流，那樣你真的很失敗了，你什麼作用都沒有，要你幹嗎