項目管理之老系統維護
今天收到了老板給的一篇關于老系統維護的文章，本人讀后有了，了解了很多，也清理了本人諸多的模糊想法，現將此文章分享給各位，原文如下：
我之所以把這個主題放在過程管理篇的***部分，就是因為很多程序員每天干的工作，不是在開發新系統，而是在維護老系統。這個理兒大家都清楚，世界上哪有那么多新項目新產品開發啊。一個公司，也就是那么2~3個產品，也不可能老有新的產品出現。那么多程序員，只能做維護的事情了，不斷讓軟件升級，而這個軟件是誰寫的***版代碼，都無從查起了。一翻開源代碼，會看見各個時期各種風格的源代碼，甚至很多源代碼都沒有注釋，根本不知道某些代碼干嘛要那樣寫，到底是為了什么目的。
一天早上，有個網友給我發了一條消息：他是一個老產品版本維護開發人員。他應聘到這家公司的時候，這個產品已經賣了4年了。最初的開發者已經都在這4年中不斷流失走掉了。他來了，任務就是維護這套軟件，而且就他一個人維護這套臺面，有BUG改BUG，有需求改需求。
雖說這套軟件賣了4年，但真不知道是怎么堅持了4年。他接手的時候仍然是BUG百出。代碼沒有文檔，沒有注釋，連表結構說明都沒有。代碼莫名其妙，經常橫插一句代碼。顯然是客戶報告了某個錯誤，為了臨時決定這個錯誤而做的針對性處理，但到底是為了修補什么錯誤，代碼也沒有說明。所以他不敢亂動，但還要需求，只能硬著頭皮來。他也不知道自己修改的代碼是否還會引起其他的問題，只能憑空企求千萬不要出問題。老板還在到處吹產品很成熟，而他每天都在心驚膽戰，害怕這套代碼不知道哪天突然崩潰，出了錯誤自己都收拾不了，那只能自己被K掉。他能想象得出老板發怒的情景：這么穩定的產品你都搞不定？！
他希望我能幫他出出點子。
我想了想，能有機會開發新產品或新項目的程序員是很幸運的，因為沒有歷史包袱，白紙畫畫。而現在大部分的軟件公司都是拿一套已經有了型的代碼到處修改，客戶化為新項目。真正做一個新項目，從頭編寫這個項目的***行代碼，這樣的機會比較少。
對于修改現有代理適應新客戶新項目，這種情況非常多，也是大部分沒有文檔，修改定制沒有注釋?？蛻舸螂娫捳f一個需求，技術能達到就答應下來修改，修改完就給客戶覆蓋，根本沒有需求管理、版本管理。而這樣的代碼，還不是一個特定客戶一套特定定制化代碼，是要給其他客戶也更新的。很可能這個客戶好使，那個客戶使用其他功能的時候就出錯。按下葫蘆起了瓢，是很常見的現象。
我問他：“現在你改的代碼有注釋嗎？”
他回答：“沒有，自己修改的自己都記得，即使忘了，看看自己寫的代碼也能回憶起來，所以也沒有寫。”
我問他：“那以后你走了，其他人怎么辦？”
他回答：“反正也是一個爛產品，其他人怎么辦，他就管不了了，就應該讓這套爛代碼盡快死亡，省的禍害別人。”
我問他：“那你找我幫助的目的是什么？”
他回答：“在我工作的這段期間內，它不要崩潰就可以了。”
我無語了。
關于老系統維護這個話題，我喝許多開發人員都有過深入的交流探討。
許多從事開發的網友認為，一個老系統要維護好，必須具備以下關鍵因素：有責任心，有文檔，設計前做好詳細的需求分析，要有需求管理，要OO編程，要有專門的測試人員。如果沒有這些，干脆推到重來，如果不讓推到重來，那就趕快跑路，否則就容易當了冤枉替死鬼。
但現實中，往往維護老系統的就一個人。這是很矛盾的事情。一個軟件的開發，往往1~2個月就完成，而它的銷售、實施、升級周期卻長達4~8年。但每個老板好像都認為軟件已經開發完畢，修補修補都是小功能，所以一個老系統維護人員就OK了。殊不知白紙好畫畫，而要在別人的畫兒上再能點睛成龍就是難上加難了。
我在管理運營企業的時候，發現遇到的難題也和維護老系統面臨的很類似。都是缺這缺那，部門之間利益沖突，人的素質怎么也提不上來，員工和老板互相做貓和老鼠的游戲，不斷博弈薪水和付出勞動力平衡?？傆行┕镜臍v史---留下的人留下的勢力格局留下的客戶印象留下的做事方法不能改變，也無法推翻重來，但公司還要發展還要提高，就必須已目標為中心，不斷像駱駝一樣挺著風沙干渴饑餓領隊前進，有各種困難阻礙都要不斷清除，無法根除就想辦法平衡與緩解，時而讓步時而迂回時而強勢時而突然決策突然執行，公司就這樣不斷持續經營下去。
所以，維護老系統，也要想經營企業一樣，不斷繼承包袱，不斷細心剖析問題，剝繭抽絲理清思路，不斷改進，不斷漸漸從惡性循環走向良性循環，才能把一套爛代碼扭轉成可持續維護的代碼。
寫代碼的8項建議
1、 重點把控輸入數據的校驗。 你看見很多橫插進來的代碼，就是由輸入的漏洞進入，***引起后續數據處理出錯，所以以前的程序員不截源頭，在***爆發的地方堵漏洞?，F在Windows程序都是消息事件觸發式的，還說不準這個流程會走到哪里，他堵的了這個口，其余他根本想不到的觸發，能堵住嗎？所以，把控輸入數據的校驗，在保存按鈕***步代碼中寫好集中的詳細校驗。而且，這塊代碼要寫成函數，不要大流水，省得代碼復雜性會讓程序加速崩潰。
2、 以后的需求再往上加，都寫成函數。 遇到比較大的IF..else判斷，就從其中的代碼段再分出一個函數。
3、 以后再加功能，盡量不要做成聯動觸發的。 也就是說，保存，***是單表保存。即使是主從結構的單據，如果客戶不強烈反對，也先保存主表后再讓錄入明細表。而且錄入明細表要單獨的窗口，這樣功能和代碼都簡化了。如查詢一張單據，也不要上邊是主摘要，下面就是明細聯動。這樣會影響性能。更因為速度可能慢，用戶會連續點擊多次，觸發事件就會亂，莫名其妙錯誤就都產生了。***是雙擊主摘要，彈出獨立的窗口顯示明細。
4、 以后寫代碼，分離特殊處理業務和正常處理業務的功能代碼。 就好像你走路，老有人給你下絆子，你就感覺不爽。
5、 對不常用的功能做一些隱藏處理，將其放到一個不起眼的位置。 使用的人就會越來越少。到時候就適機真正隱藏掉，不讓它觸發了。
6、 寫代碼時，避免全局變量和大流水代碼。 其實很多時候，你覺得程序很爛，索性破罐子破摔，是由于以前程序員的代碼排版可能和你不一樣。你喜歡兩個空格，人家喜歡三個空格，你就覺得不爽。人家喜歡把{放在***，你喜歡新開一行。你可以使用代碼格式轉化工具重新排一次版。我看到很多老代碼維護人員，抱怨變量都是M、N、S、Button1之類，但其實你閱讀理解代碼，這些并不會使你理解有歧義或不懂，只不過你不爽而已。理解了這個不爽，你就會心平氣和一些，修改代碼會更加順利一些，你越和舊代碼生氣，你的工作越亂。看到這里，相信很多程序員都會會心一笑。真正的根源在此，老系統無法維護只是借口而已，可能是希望老板認為自己的工作很辛苦很復雜而加薪！真正危害大的是全局變量和大流水代碼。所以寫代碼，要嚴格避免這兩個壞因素。
7、 修改需求或BUG的時候，要按照模塊來源集中修改，而不要挑好改的先改了，不好改的就***改。 按照模塊來集中修改，你會通盤考慮所有這些需求和BUG，而不是糊窗戶式的補漏洞。
8、 多寫視圖，多寫存儲過程。 我曾今和很多做維護的開發人員都做過交流。他們都覺得一個軟件沒有文檔，沒有注釋，簡直就沒法維護。但確實是很多軟件沒有任何設計文檔，連幫助說明都沒有，代碼也沒有注釋。而這些軟件又出自他們自己之手。也就是說，他們一邊抱怨沒有文檔沒有注釋，一邊自己也不做文檔不寫代碼注釋，不知道在等誰來專門做。我問他們到底需要什么文檔才可以將一個軟件維護得越來越好，從一套爛代碼扭轉到一套良好漸進的代碼？他們說要表結構說明，要詳細功能設計書。表結構還好說，可以整理出來，詳細設計說明書就不容易出了。
我曾今也維護過別人的代碼，也是什么文檔都沒有，連操作使用幫助都沒有，更別提詳細設計說明書和表結構，代碼當然沒有什么注釋。我并沒有去整理表結構說明。幸虧這個人喜歡在數據庫上倒弄，寫了大量的視圖和存儲過程。視圖中有各個表之間的關系連接，也有各個表中重要字段的中文含義。這樣我就不需要表結構說明了。因為表結構說明不僅需要描述每個表中字段的中文含義，也得描述表之間的關系，這和視圖能表達的效果是一樣的。所以，我現在也建議開發人員寫代碼，多寫視圖，多寫存儲過程。有的老代碼，SQL語句都在代碼中執行，沒有視圖。對于這樣的老系統維護，就是把這些SQL COPY 出來，做成視圖，這樣就好維護了。
至于詳細功能設計書，其實對于程序員來說，其目的是想弄清楚業務流程的來龍去脈細節。光直接看代碼很難弄明白意思的，又沒有什么其他文檔可以參考，所以只能猜測代碼的意思。尤其很多維護人員，很多功能細節都是為了處理某些特殊需求和異常業務的，都是以前程序員寫的，但是以前的程序員已經走了，現有的維護人員連軟件中具體的細節功能是怎么回事，程序員都發蒙，嗯，還有這個功能？我也不知道呀。
要解決這個問題，我曾今做過的事情就是組織實施人員寫功能操作說明幫助。因為實施人員要給客戶去培訓講解，沒有幫助說明，只能一張嘴“叭叭叭”地干說，實施人員是最需要功能操作說明幫助的。但是實施人員認為這個幫助是軟件的一部分，而且是開發部開發的軟件，開發部最了解功能，所以幫助文檔應該開發部寫。而開發部認為開發部的職責就是編寫代碼，你自己培訓連個操縱說明都沒有，你怎么培訓，所以幫助文檔應該實施部門自己編寫。于是幫助文檔誰也不寫。
歸根到底，幫助說明是終究要寫的，主要是誰寫的問題。誰最有動力寫呢？實施人員最有動力，因為這和他們的工作息息相關，而程序員明顯沒有動力理由。而且實施人員熟悉***線客戶的素質，理解客戶的具體操作思路和理解思路，寫出來的幫助客戶都能理解，幫助文件才能真正為客戶服務。很多幫助文檔的寫作都是由從來沒有見過客戶沒有實施培訓過沒有給客戶支持服務過，連軟件測試都沒有做過的純粹文檔人員編寫的，可想而知幫助文檔到底能對客戶有多大的幫助性。
在寫幫助說明的時候，我要求實施人員把每個按鈕都要點到，每個GRID中的每一個字段數據來源和數據含義，每一張報表中的字段的數據來源和數據含義，每一個明細錄入中的字段數據來源、數據錄入要求和數據含義都要說明到。這一寫不要緊，發現了很多隱藏的特殊處理功能。很多功能很多人不了解，因為很多細節功能，都是為摸個客戶定制的，只有負責實施改客戶的實施人員才知道。于是，實施人員之間互相通氣，才算補足了不少功能細節的幫助說明。實在有寫功能，都不知道是哪家客戶提出來的需求，也不知道為什么要這樣處理，就留下空白，轉給開發人員，讓開發人員看看代碼是怎么處理的。就這樣，一份詳細的幫助說明在壓力艱難中終于出來了。從此，開發人員理解需求快了許多，當然也就明白了那些在過去自認為亂七八糟的代碼的含義，心情好了很多，修改代碼也輕松了許多。
原來，一切都是自己跟自己跟自己作怪。不盼望軟件工程，不抱怨一窮二白，不幻想加人手，從現實入手解決自己的問題，發現很多解決方案既簡單又有效，根本無需動輒就是團隊就是UML就是OO。
另外，需求也是維護人員很頭疼的事情。我的手下也經常問我：客戶必須讓咱們接他們的需求改，您看怎么辦？
客戶需求！客戶需求！
客戶需求，這個讓開發部最頭疼的字眼！每當想起客戶需求，就想起了一下這些話：
1、 程序員說：這是你們家個性的需求，太邪門，我們不做?？蛻粽f：不做我們找你們老板去，我們是花錢買了你們的產品的。
2、 客戶說：我們不會用鼠標，你給我做一個語音輸入吧。我們還想要一個類似QQ的東西供我們內部溝通，你們給我們做一個吧。程序員：我暈！
3、 程序員說：等你們內部斗爭完，你們協調完了，我再調研需求。
似乎，我們在需求上無能為力，我們永遠在追趕客戶的需求，滿足他們的現狀，把N多家的客戶需求都加進軟件中，只要能實現的，我們盡量咬牙實現了。
***，我們發現，我們的軟件無比復雜，誰也不會用了，連開發部門都不會用了，誰也不知道這個需求當時為什么要這樣做。因為無比復雜，所以實施、培訓、技術支持都成了問題，穩定性更成了問題。代碼互相交叉，根本無法理清有多少交叉影響點。維護的程序員都快崩潰了，天天在祈求，千萬別接到客戶電話，千萬別接到客戶電話！
一個業務處理，可以這樣處理，也可以那樣處理。你的軟件采用了你的處理方法，客戶采用了客戶自己的處理方法。兩種方法平分秋色，沒有優劣。但客戶用慣了自己的方法，所以必須讓軟件改成客戶自己的方法。
不改吧，沒有理由，因為兩種方案都差不多，單客戶就是客戶，客戶占上風，否則就不驗收不給尾款。改吧，又有什么意義？這家客戶習慣了這種方法，下一家客戶又不適應這家客戶的方法怎么辦？未必到一家改一家？
我們也曾經動用了這樣的技巧：
1、 客戶業務部門不能隨便提需求，必須集中匯總到客戶IT部門，由客戶IT部門匯總過濾完，再集中報給軟件公司。
2、 客戶IT部門的需求，必須由客戶方負責IT項目的老板簽字才能生效，才能報給軟件公司。
3、 不能隨時報，每3個月集中報一次。
4、 不能口頭報（即使在現場實施支持也不行），不能電話報，只能EMAIL或傳真來報。
5、 必須按我們規定的格式報，要嚴格寫清楚需要實現的功能的界面，輸入數據或輸出數據，輸入輸出數據的格式要求，誰操作，多長時間操作一次。
6、 軟件上線后只能免費修改3次。以后再有需求，就必須另簽合同另收費，否則不予修改。
經過這么幾招，客戶也疲了。需求是不提了，開發部歡呼雀躍。但我們真的做好了么？難道客戶真的滿意了么？并沒有。我們只是限制 了客戶的需求！本來，是因為客戶有需求，才找我們來開發軟件。我們現在拿了人家的錢后，又嫌人家的需求多。
需求，有很多方面。有關于功能的（尤其是每家客戶特殊的業務需求），有關于異常錯誤的，有關于性能的，有關于兼容性的，有關于易用性的，有關于特殊權限的，有關于美觀性的。
而有需求的來源也是多方面的，有的是客戶計算機室直接打電話，有的是客戶業務部門直接打電話，有的是實施人員，有的是支持人員，有的是市場人員，有的是銷售人員，有的是老板和客戶打單或開會突然想到談到就直接給開發人員打電話。
而需求的優先級也不一樣。有的客戶態度強硬，你必須盡快滿足他，否則他就給你老板打電話。
而正是這來自四面八方的各種層次各種看法的人的各個方面的需求電話，把程序員煩的要命，還要去開發。而且很多時候客戶都是以為一個電話程序員就能開發了。但往往程序員開發完后，客戶一看不是自己最想要的，于是再修改。很多人抱怨說需求老變來變去。其實，不是客戶需求在變，而是你對客戶的需求理解在不斷加深。
所以，需求多，其實是一個幻覺。那該怎么辦呢？我給出了這么幾個注、主意。
1、 把需求分類，做個EXCEL表格，量化解決。 這個需求管理表格會有下列這些項：客戶名稱，需求提出人，提出日期，需求關閉時間，功能模塊命名，客戶現在版本號，需求描述，需求分類（需求，BUG）。我在最初沒有需求管理系統的時候就使用過這種方法。過去沒有使用的時候，我得手下老叫忙死了。我就讓他把現在手頭的事情整理一下給我報個郵件。但一整理，肯定不超過10件事。有些事情是等待客戶給資料，有些事情是調試跟蹤不出來錯誤，有些事情是需求模棱兩可。我給他一分析，他現在正在進行的事情就兩件，而且都是他自己能獨立做的，根本不需要別人配合參與。他忙嗎？他瞎忙，或者故意說 忙。沒有工作效果就是這樣。帳不算不清，話不說不明，就是這個道理。
有了這個表格，要定期（可能是一周，可能是一月）給老板一份。這表明你的工作量，讓他看看你確實一直很辛苦的在工作，而且干了這么多活。而且，這也能看出你工作的仔細負責態度。
曾經有個客戶，光想占便宜，但不想每年掏維護費，軟件也不驗收，每次去催驗收，總給我們提出一大堆需求，說你們這個系統爛得不得了，還想讓我們驗收？你們必須把我們的這些需求滿足了，咱們再看能不能驗收。我們忍了，拿著需求低調修改，但如此反復了好幾回仍然沒有驗收的意思，我們到了他們現場，發現那些他們聲稱不滿意的功能他們還在繼續用，這就奇怪了，難道他們故意裝做不滿意是為了不想給錢？我們就把過去所提的需求都翻了出來讓他們看：什么時候提的，誰提的，提了多少條，我們是怎么滿足的，你們又是怎么把需求變更的，我們又是怎么安排修改的。整個過程一清二楚，我們的工作量都擺在這里了?？蛻暨€在狡辯說我們從沒提過這些啊，我們都不知道，我們怎么會提這么多呢？我們說這些需求都有你們的人名和時間的具體記錄，那還有假。***，客戶也臉上掛不住了，好歹做了驗收。
有些程序員不做這個表格，也不給老板報告。很多時候是程序員并沒有干那么多活，能推則推，能混則混，能拖就拖。怕自己有一天混不下去，所以心理壓力很大，每天不干活卻總覺得很累。這種累就是自找的。想必一些程序員看到此會想起自己。
2、需求描述不清晰。需求描述不清晰是反復修改的罪魁禍首。對于BUG，要有錯誤報錯整個的屏幕截圖，千萬不要就截那個錯誤消息框那么一小塊。對于需求，是報表需求，要給出表格格式，還有每一項數據的來源，有公式關系的要給出明確的計算公式。對于輸入單據需求，要給出單據格式，每一個輸入項的要求：可選值、默認值、不可為空、唯一性、約束輸入，數字要有小數點后精確度、日期要分辨精度是到日期還是時還是到分。
還有網友跟我求救，他跟我說了一種情況，說現在的需求壓力，不僅僅是來源于客戶，就連我們的實施部門也給我們提需求。老板說我們一天到晚坐在家里編程序，根本不了解客戶需求。最了解客戶的是每天和客戶待在一起的實施人員，所以要讓實施人員來給我們的軟件提需求加功能。但是，實施人員那叫什么需求啊，比如說XXX功能不好用，比如說建議更易用一些。老板不相信我們，怕我們把實施人員改得需求給屏蔽了，專門派了一個人每天收集各個渠道來的需求，每天還要上報給老板，而且還每天想老板要報告，今天修改了多少需求，還有多少需求沒有改，沒有改得需求什么時候能改完，都要我們開發部給答復。而且，隔幾個月，老板就把全公司人員都召集在一起，為軟件提需求。一群人坐在一個會議室，每個人都可以提，一個模塊一個模塊的提。當場打開軟件功能，演示，說明，闡述軟件應該做成什么樣。我們開發人員就跟開批斗會一樣，這個標題不要這樣叫，那個對齊不對，這里不夠明顯應該加粗體字或給一段紅色的提示。唉，活的真窩囊，天天修改這些亂七八糟的所謂需求，還要被人追著趕著問進度，還要忍受被所有人都罵開發的什么爛軟件。老板也覺得我們水平不行，需求也怠工不修改，兩天才改修改了3個需求。而且越修改需求越多，軟件越不穩定。我們哪還敢提漲工資啊。
我說：你的這種情況很普遍?，F在很多軟件公司都是老板開店，三五個人十來條槍，他有客戶關系，賣個軟件做個實施賺點錢。公司也不大，如果軟件做不好，實施做不好，多年積累的客戶關系就壞掉，以后不好再銷售了，這就等于把老板的命根斷了。所以老板肯定會盯死軟件開發和實施。客戶使用效果好才能以后有更多的單子做。而且你們作為開發人員，又不接觸客戶，怎么能理解某個需求真正意圖呢？當然老板的思維邏輯對，你們這樣，怎么能理解客戶需求呢？當然實施人員最了解，提的需求最有權威。換你做老板都會這么想。
我也經歷過這段日子。人和人的信任，都是在做事中不斷看人試人品人，才能取得信任，才能放權。我的老板也如此。
如何比實施人員更了解客戶需求？如何讓老板相信我比實施人員更了解客戶需求？這也是擺在我面前的一個問題。
我是把產品放在一個產業中看?？锤偁帉κ?，看業界標桿，看業內管理專家，所以我對產品的升級完善，是基于產品戰略的，是基于盈利模式和競爭力構建的。如何引出更多的盈利增值產品，如何保證產品更有競爭力，是我思考的重點。
而實施人員提的需求，都和他實施的客戶具體業務流程有關?？蛻艟褪沁@樣，咱們的軟件不能滿足客戶這樣做，就要改。不改，客戶就不滿意，實施就推進不下去，實施項目就延期，自己的實施就不力。所以，實施人員為了保護自己的利益，也要開發部必須改。而且一開口就是你從來沒有去過現場，你根本不了解客戶。
老板信誰？
我不是業界知識管理專家，我也不是業界明星CTO。老板怎么能信我對業界產品競爭的判斷呢？
而實施人員，天天真實地和客戶待在一起，他們反映的肯定是真實地。
***回合，一開發部門老老實實修改需求為結束。
后來，老板又親自主導了幾次實施人員需求會議，什么都可以提，都記下來，讓開發人員改，讓實施人員監督開發人員修改，確認修改的符合實施人員的要求，并且實施人員負責測試，每次大約都能記個上百條，從要求簡化SQLSERVER數據庫安裝（因為實施顧問都非技術出身，沒接觸過SQLSERVER之類的產品，用的最多的是EXCEL和WORD,因此用報表設計器給報表格式挪挪位置大部分人都不會）到把界面都換成綠色背景（說符合公司形象）。這種局面直到我在各個部門各個環節各個層次應用了多種策略才改變。
過了一段時間，老板看著實施人員都沒事情可干，很奇怪，就問為什么不測試軟件？實施人員回答說：開發人員沒有改多少需求，我們正在等待他們開發呢。
然后老板就找我：“為什么不修改？”
我說：“程序員一直在修改，但另一方面，我們已經修改了多次，滿足需求300多條，但是我們的產品競爭力增強了么？我們的特點在哪里？我們的亮點在哪里？我們的競爭力在哪里？”
老板說：“不管怎么說，這是客戶的需求，客戶買了我們的產品，我們就有義務為他們滿足需求。”
我說：“看這條需求，客戶要求在我們的管理軟件中做一套視頻會議。”
老板說：“那你找找網上有沒有免費開源的”
我不再爭辯。因為我知道，在他心中，做什么產品，叫什么企業管理軟件都無所謂，客戶需要在ERP中加入游戲，如果理由充分也是可以的，重要的是客戶不能得罪?？蛻絷P系是他的生存之本，而非產品。
我開始在網上寫對行業的觀點，因此也有幸結交了許多知名的行業內管理專家。他們稱贊我的觀點獨到，思考有遠見。文章也受到不少網友的追捧。
我會把我寫的一些文章的鏈接適機轉給老板，轉給喜歡思考提升的實施顧問。我也會經常把和我思想觀點相似的文章鏈接轉發給老板。
老板繼續組織全體人員需求討論大會，但這次他有了改變。雖然仍然是讓人統計未完成需求數，老追問什么時候才能完成，但顯然他不像過去那樣主導與控制整個過程了。他說：你也要跑跑客戶，不能老待在家里。
于是，我跟著實施顧問也跑了一些客戶，有時候，還帶上主力開發一起走訪。
過去，開發和實施沖突很大。開發覺得沒必要修改，實施覺得必須改，***實在不行就拿出老板來壓。而且，客戶有自己特殊的業務需求，有能人者還自己想解決方法。而實施人員呢，在現場實施，陷于此境此客戶，也覺得客戶的解決方法有道理。于是非要開發人員按照那樣的方法修改。但開發人員知道，按照那樣的修改軟件，那軟件就死住了，這個功能只能給這家客戶用了，其他客戶沒法用。于是開發人員罵實施人員胳膊肘往外拐，站在客戶那方對付自己公司的同事。
但是一走訪，開發人員也才認識到客戶原來面臨這樣的問題，客戶那樣提需求其實是為了解決這樣的問題。但很可惜，客戶的想法太局限，只為自己這個問題想解決方法。如果開發人員當時在現場，就能明白客戶面臨的問題根源，只看表面問題現象，還自以為是提***解決方法，還讓開發部實現。應該是，你提出你的需求問題，怎么解決是我們開發部自己的事，我們會綜合考慮平衡。
我走訪客戶，主要目的有三：
1、 改善一下老板和實施人員對開發部的認知。 他們都認為開發部只是一群不懂客戶需求，整天坐在電腦面前不用出差，說話神叨胡子拉碴的敲代碼者，“你們不懂需求”，讓這個理由一邊兒去。
2、 改善一下開發人員和實施人員的沖突。 讓開發人員也理解客戶的現狀。有些事情是不可改變的，有些事情是人為故意的，我們做為開發人員，不應該把軟件假設在一個理想的工作環境下，那樣的軟件是不適合現實使用的。改委曲求全還得委曲求全，罵客戶管理水平太次、罵客戶都是白癡 。我在開發團隊內部老是說：人家是白癡嗎？ 人家買你的軟件也是白癡。那豈不是反過來說你的軟件誰買誰就是白癡？那豈不是說明你的軟件很爛毫無價值么？咱們每個月的工資從哪里來？是老板發給咱們的嗎？老板又不是白癡，發錢給咱們？老板的錢也是從客戶口袋里掏來的。
3、 了解客戶現狀，想方法如何去引導與影響客戶。 客戶面臨最需要解決的問題是什么？客戶對軟件的認知程度如何？客戶怎么看軟件價值？客戶認為這套軟件應該是干什么的？（有的客戶認為我們的軟件應該帶上QQ）。實施人員是怎么給客戶講解軟件中得管理思想的？實施人員是如何培訓客戶的？
走訪回來之后，我做了兩件事情：
1、 發表了一篇我的走訪感受。發到網上，也發給老板，發給實施人員。老板看了以后說了一句話：“看來走訪走訪很有必要，以后要多做。”老板、實施、開發，三者之間的關系改善了許多。
2、 把走訪過程中確實應該改進的需求安排給開發人員。由于開發人員也是有切身體會，很快就改了出來。實施人員說這個功能做得不錯，很實用。
第二回合，開發VS實施，平手。
然后，我又把業界知名專家的一篇文章中提到的評價模型內嵌到軟件中。過去，我們雖然在產品PPT中老是宣稱自己的管理思想先進，但在軟件中卻很難看到落實。所以，實施人員在實施過程中只能講操作。而操作，客戶覺得還不如一個EXCEL表好輸入好修改好查詢好統計，所以客戶希望軟件修改成這樣修改成那樣。反正，客戶現有系統解決不了的問題就都提出來。而現在，終于有了一個可以講可以量化的管理模型。這套評價模型成了這個軟件的核心亮點。 客戶為了應用這套評價模型，也樂意錄入數據，維護數據。
第三回合，開發勝出。
然后我提出了需求管理系統，WEB型。不管誰在外面實施，或者是老板突然提出，或者是銷售提出，都錄入到需求管理系統中。把需求分類，分優先級，量化安排開發計劃，有的放矢吸收需求，改進軟件。
我還提出，每年召開用戶需求會議。邀請有思路有積極改進想法的客戶參會。大家面對面交流共同的問題。共同的需求，共同探討未來行業機遇挑戰，共同尋找解決方法。引導客戶，***老板和實施人員提高對產品，對業界，對未來，對競爭的認知。
現在在我得影響下，公司的IT咨詢業務、IT教育業務、IT服務業務、IT整合業務、IT產品發展戰略。集成合作伙伴，都逐漸專業發展起來，給公司提供了越來越多的盈利模式與收入渠道。
對于這位網友的現狀，我還建議他開始版本管理。
CVS、VSS之類就不必了。因為這是一個人的戰斗。連版本都沒有概念，一上來就是特正規的工具，大半感覺太麻煩，又退回到最初原始狀態，還對版本管理產生了不好的印象，覺得繁瑣還沒什么用。所以我們有一句話：一管就死，一放就亂。其原因就是缺乏一個 中間過渡解決方法。
所以，我建議先把版本意識提上來，按照版本管理的方法走，走順了就自然接受了正規的版本管理工具。版本管理工具可以分支，也可以合并，可以針對Bug進行補丁發布，而不發布還未完成的新功能，可以發布為某個客戶專門定制的版本，也可以回溯歷史版本，對比歷史差異，源代碼安全性也高。
有幾個過渡性建議特別實用：
1、有大的修改或沒有把握的修改之前，先把代碼備份到其他的機器上。備份目錄要跟上日期。
2、在大的修改前，先定一個穩定的版本發布出去。很多程序員沒有版本這一概念，每天都在持續修改。結果，給客戶的，每個都是半成品，有半拉子沒有修改完，還自己沒有做屏蔽處理?？蛻舨恍⌒挠昧?，產生了錯誤，再告知千萬不能用這個功能，還沒有完善。但晚了，錯誤數據進入了，以后報表平帳就是問題了，又得特殊數據特殊處理了。自己的孽障自己還得解決。
3、即使是瑣碎的修改，也要每天或隔天備份一份源代碼，別怕代碼多，現在的硬盤大的很，而且備份復制一下也就是5分鐘的事情。別怕每天備份太煩。我們經常會遇到這個客戶讓改了，另外客戶不讓改。一個功能改了又改回去，但過去的源代碼沒存備份，忘了怎么寫了，這時候你就想起代碼備份的好處了。尤其現在有不少免費的文件同步或文件自動備份的軟件，都能定時做。功能還強大，有些還有些差異備份的功能
4、現在有不少文本對比軟件，如WinMerge之類?？梢詫Ρ葍蓚€文件的差異，這個功能和版本管理工具中的源代碼差異對比一樣的效果。
5、如果每次發布新版本，就把從上一版本發布之日之后的關閉的需求列表都單獨摘成一個文件，附帶到這次新發布的版本之后。這樣即使沒有人寫更新說明文檔，根據追溯也能明白這次版本解決了哪些問題和需求。很多程序員沒有需求管理表格，版本發布要求寫更新說明文檔，這才從腦海記憶中想，想的就有些遺漏，甚至錯誤。好多程序員有過這些的情景：我記得改了呀。真正一翻代碼，一點沒動。大叫：我的代碼怎么沒了，我記得我改了呀。
我這些建議，從需求描述、工作量管理、遺留系統代碼重構技巧、備份管理、版本管理、更新說明文檔一整套說明了一個人如何維護老系統的工作方法，但希望能分享給大家，給大家以幫助。
有方法，你就不是一個人在戰斗
一切皆有可能。
原文鏈接：http://www.cnblogs.com/wisdomsoft/archive/2011/08/16/2140148.html【編輯推薦】
