去年，我們要讓軟件開發團隊管理上臺階。
我們由於處於企業管理軟件開發領域，而對日外包大部分接的單子都是管理軟件之類的單子，但是人家的項目管理、進度、質量都比我們好，如果他們再配合管理諮詢公司作爲合作伙伴，再加上大規模的服務呼叫中心，像我們之類豈有出路？
於是我們就想到了引入對日外包的開發過程管理。
大家一想起對日外包，就想到了大量的文檔和大量的代碼工人，想到了詳細設計說明書甚至到函數級、僞代碼級。
要不要引入的時候，我們內部也做了爭論。覺得對日外包，人家接的單子額比國內客戶大，所以也能招聘大規模的員工，而且對日外包，日本人是很理性的看待項目 週期的（國內客戶要求一個月開發完上線），而且日本人都做了半年到一年的調研和設計分析（國內調研幾乎只是一個上午，坐在一起瞎聊，根本不成方法）。所以 對日外包不適合咱們。咱們沒有錢招聘一定數量的人（即使我們只需要普通員工，而不是人才，我們也沒多餘的錢），當然我們也無法分離那麼多專職的項目管理、 開發、測試、文檔、配置管理崗位。我們的客戶對於軟件的認知決定了我們無法在調研、設計上下太多功夫（單子額就那麼大，客戶認爲軟件就值那麼多錢，當然無 須對軟件生產各個環節進行重視）。
不過，我還是堅持進行引入。是騾子是馬，咱們拉出來遛遛。還沒遛，就說不行。這不是小時候的小馬過河了麼？
引了進來，合作伙伴給我們派了一位質量控制部的人員。
一入手，發現有個很關鍵的問題，方法的源頭。
因爲對日外包，都是接單生產，主要是編碼、測試，保證生產進度和質量要求。但編碼之前的所有環節，對日外包公司並不清楚。他們只知道拿人家給的設計書開始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。
我沒有研究過測試驅動。我一直提倡的是全程測試，從需求到設計到代碼到文檔到打包，都要經過測試。只有每個環節都能保證正確，結果纔會正確。如果到了代碼
編寫完後才發現了不對，甚至是需求一開始就理解的不對或有矛盾流程，這就糟糕了。許多人喊需求總變，項目進度無法保證，不僅僅是沒有配備需求調研人、業務
開發組組長、測試人，更是研發流程方法上有問題，沒有采取全程測試。
文檔編寫完畢一個整塊（不是全部的一級功能編寫完畢後），我們就會交付給業務開發組去開發。具體開發人員任務安排，由業務開發組組長來決定。需要由公共開 發人員來開發的，業務開發組組長都會根據自己的開發計劃和公共開發人員的任務列表（我們用需求管理系統來安排每個人的開發任務），告知公共開發人員預期的 實現完畢時間。
這樣，公共開發和業務開發在並行，設計編寫和功能開發在並行，設計和設計測試在並行，代碼和代碼測試在並行（我們採取的是版本管理和每日構建）。這樣的情 形就跟流水線工作一樣，頗有點像豐田的流水線生產，一旦發現某個環節出現問題，理解集中人力來解決，而不會讓這個問題的這個人延期鑽牛角尖，否則，所有的 項目進度管理都成了一句空話。沒有了實質的進度，也就沒有了實質的項目預算管理。那到底能不能賺錢，真成了一個鬼才知道的問題。
很多朋友在開發當中沒有寫過文檔，一旦有想法要正規化研發管理，就動輒要求全程文檔，這文檔，那文檔，把開發人員累的，最後產品質量和產品進度都沒有保證。一看試驗失敗，就全盤否定編寫文檔，再回歸到一無所有的狀況。真是走兩個極端。
希望這篇文章能夠給大家以平和的心態看待編寫文檔。我們並不是爲了正規才編寫文檔，我們寫的每一個文檔都有作用。我們也在力求能少寫就少寫，根據團隊的、客戶的磨合理解共識程度，哪個文檔或哪個環節不需要寫，我們就砍掉。
我們並不在乎正規不正規，我們也並不在乎我們看上去很美，那沒有用。我們只是商業開發，我們要的是可控，在有限的人力資源、合同額、合同週期內交付出客戶認可的質量產品（不是高質量，是客戶能接受的質量，我們從來不爲沒有利益回報的東西多付出）。
來源：huawen的blog