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