全程測試，從需求到設計到代碼 軟件測試
去年，我們要讓軟件開發團隊管理上臺階。
我們由于處于企業管理軟件開發領域，而對日外包大部分接的單子都是管理軟件之類的單子，但是人家的項目管理、進度、質量都比我們好，如果他們再配合管理咨詢公司作為合作伙伴，再加上大規模的服務呼叫中心，像我們之類豈有出路?
于是我們就想到了引入對日外包的開發過程管理。
大家一想起對日外包，就想到了大量的文檔和大量的代碼工人，想到了詳細設計說明書甚至到函數級、偽代碼級。
要不要引入的時候，我們內部也做了爭論。覺得對日外包，人家接的單子額比國內客戶大，所以也能招聘大規模的員工，而且對日外包，日本人是很理性的看待項目周期的(國內客戶要求一個月開發完上線)，而且日本人都做了半年到一年的調研和設計分析(國內調研幾乎只是一個上午，坐在一起瞎聊，根本不成方法)。所以對日外包不適合咱們。咱們沒有錢招聘一定數量的人(即使我們只需要普通員工，而不是人才，我們也沒多余的錢)，當然我們也無法分離那么多專職的項目管理、開發、測試、文檔、配置管理崗位。我們的客戶對于軟件的認知決定了我們無法在調研、設計上下太多功夫(單子額就那么大，客戶認為軟件就值那么多錢，當然無須對軟件生產各個環節進行重視)。
不過，我還是堅持進行引入。是騾子是馬，咱們拉出來遛遛。還沒遛，就說不行。這不是小時候的小馬過河了么?
引了進來，合作伙伴給我們派了一位質量控制部的人員。
一入手，發現有個很關鍵的問題，方法的源頭。
因為對日外包，都是接單生產，主要是編碼、測試，保證生產進度和質量要求。但編碼之前的所有環節，對日外包公司并不清楚。他們只知道拿人家給的設計書開始coding，設計書怎么來的，前面環節產生過哪些文檔，不清楚。
幸虧我們過去有系統的調研方法，從調研描述現狀、然后分析優化的組織結構、工作流程、考核報表、崗位職責四大塊來描述需求�？蛻魞灮蟮牧鞒�、工具中包含手工紙張信息、EXCEL信息、軟件信息。
把這些轉變為軟件中的功能、權限、報表也一氣呵成。組織結構和崗位職責決定了功能點和功能權限、工作流程決定了軟件流程、工作流程中使用的紙張信息、EXCEL信息、軟件信息就是數據輸入，報表就是數據輸出。這就是一個企業管理軟件的四大塊：組織權限、輸入、處理流程、輸出。
所以說，企業管理軟件的開發是有方法和規律的，比較容易，就連最難的調研和需求管理也有方法。所以企業管理軟件的開發，現在主要集中在大規模開發團隊的組織、任務調度、人員培訓(大規模的開發，必然需要的是一般素質的人員，而非高級人才，否則不可能有那么多資金來實現大規模開發)、大規模開發團隊的質量和進度(人多了，各個層次各個水平的人都有，理解都不同，如何保證質量和進度是很關鍵的，否則很容易項目預算失控。一般素質的人多了，對于管理的要求是很高的，很容易成為烏合之眾，只消耗不產出)。我特羨慕KFC，不管我們在大江南北哪里，遲到的KFC是一樣的口味和品質，享受的服務和環境也差不多，這很難。那么多店，而且都是授權店而非自主經營店，那么多一般員工，而且員工流失和臨時員工也非常多，居然能保證一樣，管理水平實在了得。所以我經常學習KFC和豐田，如何使一般員工大規模配合工作。
對于企業管理軟件開發過程中的文檔，我們一般有需求分析說明書，其編寫格式和思路，和我們的需求調研方法一致，也就是說，我們的需求調研的結果，落實到紙面，就有需求分析說明書，另外還有一份需求調研報告，是偏向于項目過程敘述的。
需求分析說明書回來，研發部內部會進行大家一起學習理解，然后討論。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
