我有一個以前的同事。過去他總認為能成事的人什麼時候都能成事，不能成事的人你再扶他也成不了事。所以他帶領人的方法一般是他以身作則，你如果有悟性，你就照著他做，如果你看不出來，那麼你就自己一個人玩著去，能玩成什麼樣玩成什麼樣。

我主張的是：普通人通過使用一定的方法和規則，做事情雖然無法做到優秀，但也至少能保持一定水準，不會把事情做爛。如果任由普通人自己去想自己去做，這要管理者何用？作為管理軟體開發公司，其管理思想，競爭不過管理諮詢公司，其技術實力，又沒有技術門檻，屬於那種規模化生產實施服務的型別。所以，管理軟體開發公司要想成長，必須走規模化路線。而規模化路線就需要依靠大量的普通人才，而非個別的英雄。英雄是很難找到大量人才的，而且優秀的人才其成本也高，更約束的無法規模擴張。這和規模化路線有悖。

所以，他帶出來的兵都是單兵作戰能力很高，都屬於那種能救火隊員型，有問題衝上去嘁哩喀喳就搞定。領導是很喜歡這樣的人才的，因為這樣的人是多面手，是特種戰士，把一個人隨便往哪一扔都能把專案完成的很好，很省成本。但是這樣的人才有個特點，沒有一年半載，這樣的人培養不出來。而且這樣的人往往都遊兵散勇似的，一遇到必須合作的事情就變扭，老覺得其他人辦事都不放心，都覺得別人做的沒他預想的那麼好，還不如自己一個人都包辦了快速且省事。

而我帶出來的兵都是團隊作戰型，每次做事，都需要好幾個各自發展專業的人配合，一個人還搞不定。就好像開發的時候用開源的框架，本來只想使用A框架，沒想到A框架使用了B框架，B框架使用了C框架，最後軟體沒多大，倒是框架很大。雖然我都是極力推行四套馬車4人一個小組，而且可以看專案進展安排不斷排程組合，但終究不如一個特種戰士那樣自由。但有一個好處就是做事專業，發揮穩定，培養成長快，好招聘好留人團隊穩定，薪資成本也低。

隔了這麼多年，我的電話也換了，他的電話我也沒記住。我們就這樣斷了聯絡。

突然，上個星期五，他給我發了封郵件。說他偶爾看到了我的部落格，寫的不錯（不知道是不是真的不錯，反正他以前一直反對我的這種思路），希望我能寫些關於需求管理的文章。

我趕快根據他郵件中留給我的聯絡方式聯絡到了他。

我問他：你怎麼找到我的部落格的？

他說：這幾年越來越不好做。客戶對開發對實施對服務的質量要求越來越高，一個人去現場邊修改邊實施，客戶覺得付那麼多錢不合算，怎麼著也得派一個團隊來實施。但是，團隊實施沒有人手啊。培養一個人一年都上不了手，對於我們來說團隊實施就不合算了。但客戶就要團隊實施，不團隊實施就無法接單。所以，我現在也在找一些如何團隊開發實施的文章，無意就找到了你的部落格。

我們現在也是文件化管理。從需求調研到需求確認到需求設計到需求開發，每一個環節我們都是和客戶文件確認，大家都覺得沒有問題了雙方看法一致才開發。一開始使用就發現需要修改的東西很多，而不修改又導致客戶無法使用下去，最後不斷修改，導致實施週期長，結果還跟過去一樣，質量也沒提高，週期也沒有縮短。所以，比較迷茫，是不是哪裡做的有問題？你一直挺注重過程管理，看你寫了那麼多文章，肯定這麼多年你一直在研究這方面，所以我估計你有一些好的方法。

我說：我這些天寫部落格，接到不少網友的評論，他們也強烈希望我能寫一篇關於需求管理的文章。我過去也有一些隻言片語的積累，所以這次我就準備寫一篇以了大家心願。

當我開始動筆寫這篇部落格的時候，我腦海裡直接的就是《人月神話》中最著名的一段話（不好意思，其實我沒有看過人月神話，不知道作者提供了什麼解決方法解決需求難題）：

人類史前史中，沒有別的場景比巨獸在焦油坑中垂死掙扎的場面更令人震撼。上帝見證著恐龍、猛獁象、劍齒虎在焦油中掙扎。它們掙扎得越猛烈，焦油糾纏得越緊，沒有任何猛獸足夠強壯或具有足夠的技巧去掙脫束縛，到最後它們都沉到了坑底。

這段話描寫的栩栩如生，和我們日常遇到的需求困境如出一轍。

中國人的需求很特別，好像事情都特別趕人都特別忙似的，都寥寥數語就以為他的需求已經說清楚而且你也肯定明白了，到底能不能實現，實現後能不能可操作可執行，都是匆匆一個見面一個電話幾句MSN幾句MAIL然後就等著軟體開發出來用。

我看到日本人花費一年的時間反覆和客戶討論需求，深入到生產一線天天蹲點，還派人拿專業的測量工具來記錄，如拿秒錶記錄操作的時間，拿攝相機拍攝操作流程，有大量的過程檢測指標需要15分鐘確認一次，很是認真，然後才設計解決問題的軟體功能。對於每個操作的軟體介面也是反覆和客戶確認，如何更容易理解更方便操作。

我見到許多國內專案經理調研沒個方法，東一榔頭西一棒槌，需求調研像是開座談會，一屋子人，有干係的人都請來開會。有最終操作使用者，有部門管理者，有大老闆，有二老闆，有計算機室，好幾個部門。每個人站的角度，層次都不同，關注的問題重點也不同，眼光長遠也不同，有人悲觀有人樂觀，有人不懂裝懂，有人不懂瞎嚷嚷，有的部門影響力大氣粗的不行，有的部門比較勢力小唯唯諾諾，有的部門不願意多幹就推來推去反正不是他部門的事情，到底是哪個部門的事情需要大領導來定，但可惜大領導沒來，有的部門怕自己那點內部發小財被破壞了就故意找各種各樣的困難還說的頭頭是道，於是一幫人嘰嘰喳喳，沒個結論。有時候開會開多了，實在說不過去了，必須要有一個結論，於是每個人的意見都上了需求本，回來一整理，沒法弄。

我曾經參與過一個專案就遇到了這樣一個情形，最後拖的時間太長，專案主導方認為沒什麼利益可賺，而客戶衝突利益太多，就放棄這個專案了。

“表面上看起來好像沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但是當他們相互糾纏和積累在一起的時候，團隊的行動就會變得越來越慢。”對於問題的我們很難看到本質，不過，如果我們想解決問題，就必須試圖先去了解問題。

這是《人月神話》中的一段話，我從網上找到的，估計那個專案經理很遺憾沒有看到這句話。

風水輪流轉呀。真不小心，新一輪領導換屆，新領導上臺。這個專案又被作為領導新政提了出來。（注意，不是政府換屆，而是企業領導換屆。我從來沒有做過政府的單子）

這回，專案主導方變成了我們。我成了專案經理。但是，除了這位新領導，過去的那幫人還是那幫人，我仍然要解決這幫人。（我的一位助手笑稱這幫人是成事不足敗事有餘。上一次我是掛名，他是真正參加了上一次的專案每一次開會。這次，我找他做助手，希望他的上一次經驗能給我提供幫助）

我這次沒有像我的助手上次專案一樣，讓計算機室幫忙到業務部門要這資訊那表格。

我首先向計算機室要了一份全企業的部門組織結構圖。我先看看這個盤子到底多大。我曾經剛出道的時候就遇到一次滑鐵盧，半路地殺出來一個部門領導竟然嚴重影響了專案走向。

這次，我把全體部門都納入思考範圍內，瞭解我這個專案和各個部門的關係。最後我按專案關係緊密程度把客戶各個部門排了一張表，每個部門的負責人的名字，聯絡電話我都要到，每個負責人的年齡，每個負責人的性格，我通過晚上請計算機室沒有結婚的小夥吃羊肉串瞭解了個一清二楚，誰說話算話，誰比較和事佬，誰比較見風倒，誰和誰不對付。想問問他們大老闆是怎麼看這個專案的，想達到什麼目標，他說他也不清楚。

我先去親自找最容易配合我的那個部門（我並沒有採用聚眾開座談會的形式，而是單個擊破法）。但他不是和我這個專案關聯最緊密的部門。但他最容易突破。

他和我發了一下午的悶氣，有對企業現狀的灰心與不滿，有對理想做法的想象，希望我能在這次專案中把他的想法全部實現了。

不過這次聊天我也受益匪淺，對這個企業的各種來龍去脈瞭解了許多，使我在以後的小心翼翼專案推進中避免了很多人為的障礙。

但這不是我這次找他談的真正目的。他絮叨了一下午，我臨走時才說出了我的目的：我需要把他這個部門的報表和單據收集回去。

他很配合，把他的得力干將叫了過來準備安排，我說別了，我跟著他去自己收集，這樣我對您的需求也理解的更深更直觀一些。

於是，我跟著他的得力干將，一位36-37歲的中年女士一一到每個重要的人的桌邊，我和每個人都講明瞭我的來意，他們將他們手頭的報表和單據全都拿給了我。有EXCEL的，有WORD的，有每月PPT述職報告，有紙張的，有電腦軟體上的報表都打印出來，有電腦軟體上的資料輸入，我就幫他們COPY螢幕列印放到我的U盤上。

我一個人一個人的邊收集邊問，通過他們給我的表格，我就大致知道了他們的工作崗位內容。

然後，我問：哪些表格是你最常用的。

於是，那個人就幫我挑出了好幾張。

然後，我依次把最常用的，次常用的，偶爾用的報表都分了類。

我又提出了問題：哪些報表影響你的考核和獎金工資福利之類？

他又幫我挑出來一些。

我又對著他挑出來的影響他的考核的報表，拿起每一張問他：在這張報表中，你最關注哪幾個指標？

他一一指出來。我順著他的指，邊和他交流這些指標的關聯關係。

然後我拿著這些指標問他，這些指標是怎麼的資料是怎麼得來的。

他就幫我從這一堆的電子的、紙張的單據中找了出來，並且解釋怎麼輸入的。

然後我對著每一個單據都問他這個單據的使用頻率，是每天、每週、每月、每季還是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、還是平時做？哪個頻率高？高到什麼程度？

這樣，我就明白了每個人主要真正做哪些事，怎麼做，最後怎麼考核，哪些事最重要，哪些事每天做，哪些事頻率最高。

常用的功能，重要的功能，效能壓力大的功能，穩定性要求高的功能、資料精確要求高功能，易操作性要求高的的功能，就是從這些提問回答中自然浮現出來的。

我的那個助手用筆在筆記本上不斷記錄，手累的最後回來都說手寫的都抽筋，告訴我下次不要這麼快，讓他好記錄全一些。還給我看，為了記得快，字都寫的有些現在不認識了，還得靠回憶，整理起來特費勁。我說，行，行，我一定注意。

我們回到賓館後，先製作了一份草稿，粗略的列出來這個部門的組織結構、人員崗位角色說明、業務流程圖、考核報表。第二天，然後針對這次專案，把這次專案相關的詳細描述出來，並且把核心業務流程和非核心業務流程分開。

第三天上午，我們又去了那個部門，針對每個報表間的鉤稽關係，每張單據錄入的每一項錄入要求、預設值、必填項、唯一約束、錄入校驗、單據狀態、可選值都做了詳細調研。

在交談中，我們又發現了一些流程，這些流程都是些特殊處理流程。我們也發現了一些異常的操作，是發生特殊業務時候的土處理，我們都如實記錄了下來。有時候，你專門問他異常流程的時候，他反而回答不出來。大部分人沒有系統性思維，都是以事論事，講到哪裡想到哪裡。所以發現異常流程，發現新流程，全靠調研人自己細心發現和甄別。可能，他無意的一句話，你直追著下去就會發現他日常處理的空白和漏洞和矛盾的地方。

第三天下午，我們繼續工作，單個人訪談，把每個人工作中認為最想解決的問題都提出來，但只能說5個，能想到哪些就說哪些，我們一一記錄。

第四天，我們把我們過去畫好的組織結構、人員崗位角色說明、業務流程圖，經過昨天的調研，又修改補充了一些，在整理的時候，我們用紅圈標好了業務處理漏洞和矛盾的地方，並且對這些地方都提出了改進建議。把他們每個人認為最想解決的問題都考慮進流程和業務單據報表中，建議增加什麼流程、建議增加什麼單據、建議增加什麼報表，誰來做，怎麼做，誰來監督，怎麼考核。

一份優化好的流程展現出來了。

第五天，我們又去了客戶那裡。這次，我們組織了部門座談會。我們給他們整個部門都講解了我們梳理過的流程現狀，給他們說明漏洞和矛盾，給他們說明我們提出的方案。

座談會非常順利，全在我們的意料掌控之中。他們非常驚訝我們能在短期內畫出這麼專業的流程圖，其理解透徹度比他們自己還要清楚。而且對他們問題的把握準確，對他們問題的解決思路之巧妙，都不禁讚歎我們。每個人的疑問和建議都融入了我們的流程改進思考之中。客戶部門給與了我們很高的評價。

接下來，我並沒有把這種方法擴充套件到其他客戶業務部門的調研。而是我把這份調查報告又給了他們大老闆演示了一次。他們的大老闆從來沒見過這樣專業的調研，趕快召集各部門頭頭都來開會，樂的喜笑顏開， 大讚這錢花的值，他們只想到上套軟體，沒想到上軟體講究這麼大，他們自己都沒有如此明晰專業的流程圖。他們的大老闆趕快讓我給他也COPY一份，如獲珍寶。

有了大老闆的肯定，我做一個部門的調研，就給他們的大老闆發一個報告郵件。郵件抄送給調研的業務部門負責人。

我所有的調研一帆風順，各個部門配合極好。上一次專案的扯皮推搡都不見了。

我的助手說：你這個人有點邪門。

我一笑。

後續記：

我寫完這篇博文後，引起了網友這樣的評論：其實這些事情都是管理諮詢公司做，你現在做了這些，其實是增加了你的工作成本。

我並沒有想過這件事該管理諮詢公司做，那件事情該軟體公司做。我只想解決我的問題，我的方法也是由此而來的。

如果我對客戶說：“你們還不規範，現在不能上軟體，需要你們先去找管理諮詢公司來梳理流程”。我不知道我們的公司會不會活到現在。

解決問題，這是你自己面臨的問題，你不去自己想辦法，沒有人會給你解決這個問題。能救你自己的只能是你自己。