去年，我們要讓軟體開發團隊管理上臺階。

我們由於處於企業管理軟體開發領域，而對日外包大部分接的單子都是管理軟體之類的單子，但是人家的專案管理、進度、質量都比我們好，如果他們再配合管理諮詢公司作為合作伙伴，再加上大規模的服務呼叫中心，像我們之類豈有出路？

於是我們就想到了引入對日外包的開發過程管理。

大家一想起對日外包，就想到了大量的文件和大量的程式碼工人，想到了詳細設計說明書甚至到函式級、虛擬碼級。

要不要引入的時候，我們內部也做了爭論。覺得對日外包，人家接的單子額比國內客戶大，所以也能招聘大規模的員工，而且對日外包，日本人是很理性的看待專案週期的（國內客戶要求一個月開發完上線），而且日本人都做了半年到一年的調研和設計分析（國內調研幾乎只是一個上午，坐在一起瞎聊，根本不成方法）。所以對日外包不適合咱們。咱們沒有錢招聘一定數量的人（即使我們只需要普通員工，而不是人才，我們也沒多餘的錢），當然我們也無法分離那麼多專職的專案管理、開發、測試、文件、配置管理崗位。我們的客戶對於軟體的認知決定了我們無法在調研、設計上下太多功夫（單子額就那麼大，客戶認為軟體就值那麼多錢，當然無須對軟體生產各個環節進行重視）。

不過，我還是堅持進行引入。是騾子是馬，咱們拉出來遛遛。還沒遛，就說不行。這不是小時候的小馬過河了麼？

引了進來，合作伙伴給我們派了一位質量控制部的人員。

一入手，發現有個很關鍵的問題，方法的源頭。

因為對日外包，都是接單生產，主要是編碼、測試，保證生產進度和質量要求。但編碼之前的所有環節，對日外包公司並不清楚。他們只知道拿人家給的設計書開始coding，設計書怎麼來的，前面環節產生過哪些文件，不清楚。

幸虧我們過去有系統的調研方法，從調研描述現狀、然後分析優化的組織結構、工作流程、考核報表、崗位職責四大塊來描述需求。客戶優化後的流程、工具中包含手工紙張資訊、EXCEL資訊、軟體資訊。

把這些轉變為軟體中的功能、許可權、報表也一氣呵成。組織結構和崗位職責決定了功能點和功能許可權、工作流程決定了軟體流程、工作流程中使用的紙張資訊、EXCEL資訊、軟體資訊就是資料輸入，報表就是資料輸出。這就是一個企業管理軟體的四大塊：組織許可權、輸入、處理流程、輸出。

所以說，企業管理軟體的開發是有方法和規律的，比較容易，就連最難的調研和需求管理也有方法。所以企業管理軟體的開發，現在主要集中在大規模開發團隊的組織、任務排程、人員培訓（大規模的開發，必然需要的是一般素質的人員，而非高階人才，否則不可能有那麼多資金來實現大規模開發）、大規模開發團隊的質量和進度（人多了，各個層次各個水平的人都有，理解都不同，如何保證質量和進度是很關鍵的，否則很容易專案預算失控。一般素質的人多了，對於管理的要求是很高的，很容易成為烏合之眾，只消耗不產出）。我特羨慕KFC，不管我們在大江南北哪裡，遲到的KFC是一樣的口味和品質，享受的服務和環境也差不多，這很難。那麼多店，而且都是授權店而非自主經營店，那麼多一般員工，而且員工流失和臨時員工也非常多，居然能保證一樣，管理水平實在了得。所以我經常學習KFC和豐田，如何使一般員工大規模配合工作。

對於企業管理軟體開發過程中的文件，我們一般有需求分析說明書，其編寫格式和思路，和我們的需求調研方法一致，也就是說，我們的需求調研的結果，落實到紙面，就有需求分析說明書，另外還有一份需求調研報告，是偏向於專案過程敘述的。

需求分析說明書回來，研發部內部會進行大家一起學習理解，然後討論。

討論主要由：需求調研人、業務組組長、測試組組長來參加。一個個的過流程。因為在需求調研期間，去的只是調研人，可能有想不全的地方。如果這樣就直接進行開發，無疑會有很多漏洞。這樣給開發、測試，都帶來了返工修改，給專案管理也帶來了專案進度、任務分配的調整，計劃的打亂也間接影響了質量管理。

根據大家討論補充後的需求分析說明書，就比較容易得到我們下面環節的文件。

首先我們會出功能點文件。

我們會把需求分析說明書中的業務功能都列出來清單，屬於組織結構建立、組織角色、許可權分配、登陸驗證、基礎資料維護之類的都歸類到系統功能中。系統管理，各個企業管理軟體差不多，我們又有公共的系統管理模組，就不需要重新發明輪子了。所以，我們主要重點是分析業務功能。

根據需求分析說明書中的每個流程，都先提出來成為一個功能點。然後針對現在整理出來的功能點，再一個個對照流程，如果這個流程複雜，就拆分，把這個功能點拆成幾個複雜性和預估工作量差不多的功能點。經過這樣的拆分，就形成了最終的功能點文件。

而功能點之間，根據上述方法的拆分，就形成了功能群。

功能點就成為功能許可權控制的最小單位。功能群就成了軟體選單中的一項。幾個相關聯的功能群就成為了一個業務子系統。

就這樣的方法，使子系統-功能選單-功能點（可能是某個功能視窗上的功能按鈕）三級分開，與組織結構-員工-角色-使用者-許可權結合。一個軟體，未來會成為什麼樣子，大框架就出來了。

做功能點清單，就類似於跑馬圈地，這個專案到底多大，我先把專案邊界框起來，而不要讓這個專案無邊無界，那自然也不會有可落實的專案進度和專案管理。知道了專案最大做到多大，就能決定是虧是賺，是做還是不做，能不能做了，有可用的時間和人力來做否。

然後，我們會根據功能點清單，為每一個功能進行優先順序的標示。我們通常會把優先順序分為三級。這就意味著一個專案，大致分為三個階段。一級是必須要做的，即使延期也要做，必須排程多加人手多加班也要完成。一級做完後，如果有時間，就把二級完成。如果時間超期，有適度的儘量去完成二級，可以延期，但也要根據預算和時間。如果適當延期也無法完成，我們會給客戶去上線實施，變實施邊並行開發，使實施團隊和開發團隊進行並行工作。所以，二級也是重要的功能。三級就是如果時間用完，三級的功能就要捨棄掉不開發。

一般是，按功能的重要性來劃分優先順序，我們在之前已經講過，我們調研需求的時候，就把常用業務和異常業務分開，把每天做的業務，和每週、每月、每季、每年做的業務分開。幾個結合特別緊密的，互相關聯的，我們也會把他們劃分在同一個優先順序，需要單獨開發的基礎資料維護介面，我們也會放在同一個優先順序。這樣，只要我們專案到期，或者我們迫於競爭突變，我們會隨時推出一個可以完整使用的系統。雖然這個系統可能功能簡陋，但可以完整處理整個常用業務流程，而不會造成中斷，無法處理下去。

很多開發團隊，開發的方法是先字典功能，然後是業務功能，然後是報表。這種開發方法就導致了很多業務系統，客戶上線使用了，光輸入資料，沒有輸出，業務系統成了一個悶葫蘆，使用者得不到使用價值，可能只是減輕了工作量，加快了工作效率，提高了部門間的自動配合。更有甚者，業務功能開發了一半，到處都是斷路，走不下去，無法成為一個完整的系統，就是個半成品，上不上下不下，無法適應競爭變化。

我們開始針對功能點清單編寫我們的功能設計說明書。

我們是按照優先順序來編寫功能設計說明書的。我們並不會把功能設計說明書都編寫完畢後才開始編碼。而是，我們先把優先順序為一的詳細功能設計編寫出來，就開始開發。二級的功能編寫會在開發人員進行一級功能編碼的時候並行。

功能詳細設計說明書由業務開發組的組長來編寫，屬於系統類功能或公共類的功能，都歸給公共程式碼人員來編寫，需要複雜的演算法，高效能，高安全，高資料量，需求一直未確定最終解決方案的未來未知變化的介面，也都由公共程式碼人員來編寫。所以，一個開發團隊，有高技術的公共程式碼人員，有深刻理解業務的業務開發組組長，有普通的coding人員。業務開發組的組長一般由熟悉客戶業務，編碼經驗較多但技術能力一般、踏實細心負責適合團隊管理的人擔任。

功能設計說明書，根據每個功能點詳細展開描述。一般一個功能點由一個EXCEL文件來詳細描述。

EXCEL文件第一個sheet中是版本資訊，每次修改都有變更記錄。第二個sheet是頁面佈局。我們通常會用PPT或開發工具建立個介面草圖，然後貼上去。第三個sheet是頁面上面的每個欄位的說明，如預設值、不可為空、輸入約束、主鍵唯一、輸入長度、參照錄入等等。第四個sheet，如果有必要，可以用VISIO畫出業務流程圖。第五個sheet是關於執行要求，如易用性、安全性、效能、資料量、併發性，這幾個特性都分為高中低三個等級。另外，對執行的作業系統、記憶體都做了最低要求。一個功能，必須考慮它的使用者的計算機水平，否則功能很實用，但就操作不習慣，客戶非要改成客戶習慣的方法，我們經常會面臨這樣的要求。與其那樣讓客戶趕著我們，還不如我們自己提前在設計的時候就要求我們自己。我們在需求調研的階段會調研客戶的資訊化現狀，如IT維護人員能力，資訊化應用能力，客戶老闆對資訊化認知理解，終端使用者資訊化操作能力。

我經常看見不少客戶沒有IT維護人員，不知道有伺服器這一說法，更不知道什麼是SQLSERVER，也不知道備份。對於資訊化的理解就是上套軟體，裝個XP還不知道WINDOWS要升級（很多上網的機器連XP SP2都不裝，什麼防火牆放木馬的都沒有），就知道裝個瑞星防毒，天天抱怨機器超慢。一看機器，也確實是老了，2002年的機器，128M記憶體。而且操作者打字和滑鼠都不靈光，讓他雙擊或滑鼠右鍵，他根本不理解。跟他電話裡說開啟某個功能選單，他很莫名其妙電腦中怎麼會有選單？如果你的軟體是基於.net的，他連.net 執行時都不知道到哪裡去下載。所以我們的軟體需要在什麼硬體上什麼基礎軟體上執行，資料量多大仍然可以執行流暢，我們的軟體要達到的易用操作程度，要達到的易用維護程度等等，我們必須在設計期考慮到。

很多做軟體開發的，尤其不注重這方面，所以我在這裡重點強調囉嗦一下。大家不要恥笑使用者，大家的工資都是他們給咱們的，而不是老闆。使用者不是計算機高手，他們不懂雙擊、滾動、滑鼠右鍵很正常。我們的衣食父母，我們要好好對待。我們不要和我們的錢作對。

EXCEL功能設計文件到此，其實還缺一塊。就是資料操作流程。

我們先不編寫資料操作流程。我們會先交給測試組的人員來校驗這個功能點的詳細設計，是否和需求流程和需求要求吻合，不符合的地方就整改。

整改後的功能設計文件，算是和需求說明文件一致，設計正確。這時候才涉及到具體的實現說明。

我們會讓公共程式碼人員出界面輸入輸出和業務流程圖中整理出資料結構。我們為什麼不讓業務開發組的組長來整理表結構，就是由於業務開發組的組長熟知業務卻對技術並不精通。資料結構很影響未來的效能、擴充套件，所以應該由公共程式碼人員來設計表結構，並且建立檢視和儲存過程。

公共程式碼人員為了考慮效能和擴充套件，表結構的設計可能就被打散成多個表，而不是業務開發組長自然理解的儲存結構。所以公共程式碼人員建立了檢視，保證在檢視的層面上讓業務程式碼開發組的人看到的是一個自然的業務實體資料結構，根本無須理解內部的表結構之間的關聯關係。而且有儲存過程來保證如何無須知道表之間的關聯關係就可以增刪改資料。

從這種分工配合來看，我們採取的是從後到前的開發方法。先有資料層，有基礎表結構、檢視、儲存過程，然後基於檢視和儲存過程進行業務流程程式碼開發，最終由普通的業務開發人員進行介面拖控制元件繪製介面。所以業務開發人員既不熟悉業務，也不熟悉技術。

公共程式碼人員把設計完畢的資料結構交給業務開發組組長，組長來編寫每個功能的資料增刪改查操作文件。增加這部分文件到EXCEL中，成為第六個sheet。

我沒有研究過測試驅動。我一直提倡的是全程測試，從需求到設計到程式碼到文件到打包，都要經過測試。只有每個環節都能保證正確，結果才會正確。如果到了程式碼編寫完後才發現了不對，甚至是需求一開始就理解的不對或有矛盾流程，這就糟糕了。許多人喊需求總變，專案進度無法保證，不僅僅是沒有配備需求調研人、業務開發組組長、測試人，更是研發流程方法上有問題，沒有采取全程測試。

文件編寫完畢一個整塊（不是全部的一級功能編寫完畢後），我們就會交付給業務開發組去開發。具體開發人員任務安排，由業務開發組組長來決定。需要由公共開發人員來開發的，業務開發組組長都會根據自己的開發計劃和公共開發人員的任務列表（我們用需求管理系統來安排每個人的開發任務），告知公共開發人員預期的實現完畢時間。

這樣，公共開發和業務開發在並行，設計編寫和功能開發在並行，設計和設計測試在並行，程式碼和程式碼測試在並行（我們採取的是版本管理和每日構建）。這樣的情形就跟流水線工作一樣，頗有點像豐田的流水線生產，一旦發現某個環節出現問題，理解集中人力來解決，而不會讓這個問題的這個人延期鑽牛角尖，否則，所有的專案進度管理都成了一句空話。沒有了實質的進度，也就沒有了實質的專案預算管理。那到底能不能賺錢，真成了一個鬼才知道的問題。

很多朋友在開發當中沒有寫過文件，一旦有想法要正規化研發管理，就動輒要求全程文件，這文件，那文件，把開發人員累的，最後產品質量和產品進度都沒有保證。一看試驗失敗，就全盤否定編寫文件，再回歸到一無所有的狀況。真是走兩個極端。

希望這篇文章能夠給大家以平和的心態看待編寫文件。我們並不是為了正規才編寫文件，我們寫的每一個文件都有作用。我們也在力求能少寫就少寫，根據團隊的、客戶的磨合理解共識程度，哪個文件或哪個環節不需要寫，我們就砍掉。

我們並不在乎正規不正規，我們也並不在乎我們看上去很美，那沒有用。我們只是商業開發，我們要的是可控，在有限的人力資源、合同額、合同週期內交付出客戶認可的質量產品（不是高質量，是客戶能接受的質量，我們從來不為沒有利益回報的東西多付出）。