創造 software review 的需求

鳥毅想要說服主管推行 review 的計劃，喲哪桑學長提了一些建議可以供鳥毅參考，不過我認為要說服主管不是一件簡單的事，如果沒有樣學長那樣的辯才無礙，反應敏捷，可能很難畢其功於一役，不過這個 argument 倒讓我想起了丹娜左哈爾的服務型領導者的概念，也就是仰賴機會與才能不如創造內在需求。

記得在多年前在做李國光老師所教授的策略知識管理課程的期末專題報告，題目是某科學園區的實務社群時，過程中學到一個重要的觀念，就是推行任何的計劃，與其告訴別人他需要什麼東西，不如創造他的需求。這真是一個 key point，對於工程技術背景出身的我而言，向來習慣先提出解決方案，結果常常費盡了唇舌，卻還沒有辦法讓人家採納我們的意見，甚至造成許多不必要的誤會。因為我們不知道對方真正的需求，卻天真地以為我們的解決方案可解決一切問題，我們所做的只不過是誘導對方採納我們的意見而已。

因此，要成為（being）一個服務型領導者，必先傾聽對方的心聲，要先清楚問題是什麼，才可能發展出正確的方法及解決方案，具體實施以求成效（doing）。先把推行 review 計劃放一邊，運用兩大招式，第一招是心智互動，運用(O)觀察－觀察對方的觀點與我有何不同。(A)評估－評估為何會有這樣的不同。(D)設計－根據評估設計出如何改進自己的心智模式。(I)實施－根據設計實施改進心智模式；第二招是知識轉化，即運用知識螺旋－社會化、外化、組合化及內化由他人身上取得問題的知識，並且用 3K1C 來思考問題的不同層次：先思考問題的關注焦點（Care what）及所需形成之概念（Know what），以打破框架，然後才是掌握解決方案的流程（Know how）及理解其原理為何可行（Know why），以落實常規。 我想這些是現在可以做的事。

對於一個軟體開發組織，是否採用某個流程其實與其軟體品質文化有關，對於一個開發流程未慣例化的組織而言（即未達 CMMI ML2），推行 review 可能會遭受極大的反彈；而對於一個開發流程未針對現況做回饋控制的組織而言（即未達 CMMI ML3），review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。然而，做不做 review 不應把它視做是一種軟體流程的道德性問題，而是應該思考它對組織所要解決的問題及客戶的要求有多大的影響，如果推行 review 時候還未到，不妨坐視開發出來軟體的功能失常，等到它們實在多到令人窮於應付時，主管就會來找大家想辦法，到時自然有人會比我們更積極呢，正所謂道可致而不可求呀。