實施GJB5000要求每個人都要有工程思維
在學習寶玉老師的《軟體工程之美》課程的時候，寶玉老師給出了工程思維的概念：
工程思維，本質上是一種思考問題的方式，在解決日常遇到的問題時，嘗試從一個專案的角度去看待問題、嘗試用工程方法去解決問題、站在一個整體而不是區域性的角度去看問題。
任何問題我們都可以把它看作一個專案，運用工程方法來解決。工程方法會把解決一個問題分為6個步驟：想法、概念、計劃、設計、開發、釋出。
-
想法階段要清晰地定義問題。只有問題定義清楚了，後面才能建立針對性的解決方案。
-
概念階段就是使用草圖、模型等建立多個概念性的解決方案，並從中選取最優的那個。
-
計劃階段是根據現有的資源、時間等的限制條件下制定出解決問題的實施計劃。
-
設計階段是將概念性的解決方案細化，作為分工合作和開發實施的依據和參考。
-
開發階段按計劃實現細化的設計方案。
-
釋出階段就是將結果釋出，並驗證問題是否得到解決。
所有的問題都可以通過以上6個階段的落實去解決。
但是並不是說不通過這6個階段就解決不了問題，也許你同樣能夠解決問題，但所付出的時間、成本、資源就未必能夠得到控制。因為沒有系統規劃，就沒有控制。
解決問題的這6個階段實際上給出的就是一套系統方法。任何一個工程專案，都是一個系統。所謂工程思維，實際上就是系統思維。
而系統思維，還有另一層意思，那就是做工程專案要有大局觀。不能因為你在專案中只是承擔了需求分析或者測試這樣的角色，就只管埋頭做需求分析或者測試的工作，而是要有大局觀，要看到專案的節點，要為專案的目標服務。
因為如果專案中的每個成員只考慮自己的職責範圍，不關注整體，那可能會造成相互間的矛盾和推諉扯皮的現象，就像某些問題討論會的常見場景那樣。這會給專案帶來無謂的消耗和成本的浪費。
在GJB5000A評價過程中的訪談節點常常反映出專案經理對專案中的各項軟體工程要求比較理解，其他的專案角色，特別是工程組的專案成員，對這些工程要求不太理解。所以，在評價組中也常有這樣的爭議：
作為工程組的成員是否要了解GJB5000標準？
基於前面的工程思維的觀點，專案成員不能囿於自己的角色和職責，而應該有大局觀，有專案整體的意識，才不會給專案帶來無謂的消耗和成本的浪費。
比如說，QA不理解開發的工作，會打出一些無意義的問題，由此產生爭議，影響開發的進度；開發不理解需求跟蹤的作用，可能會導致一些需求遺漏，直到後期發現才補充開發……
所以，實施GJB5000就需要每個人都有工程思維，需要每個人都理解GJB5000標準各個過程實施的意義。那些訪談時專案工程組對標準和體系根本不理解的組織，它實施GJB5000的有效性實在存疑。
這正是：
工程並非一人事，須知整體和大局
五千實施應如是，理解標準是根基
作者簡介：王小雙，長期從事GJB5000推廣、實施、評價、改進的工作，建立《軟體工程之思》微信公眾號，一直在《軟體工程之思》分享GJB5000、CMMI、軟體工程的知識和感悟。現致力於GJB5000諮詢以及軟體過程改進、軟體工程能力提升的研究工作。