jim yeh on 三月 14th, 2007

鳥毅想要說服主管推行 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 時候還未到,不妨坐視開發出來軟體的功能失常,等到它們實在多到令人窮於應付時,主管就會來找大家想辦法,到時自然有人會比我們更積極呢,正所謂道可致而不可求呀。



     

5 Responses to “創造 software review 的需求”

  1. 鳥毅 說道:

    問個題外話,兩位互稱學長,到底是什麼關係呢?

  2. jim yeh 說道:

    Hi 鳥毅,

    看了這篇回應您就可以了解了。

  3. [...] vs. Inspection — 亂談軟體工程的正名運動〉中對〈創造 software review 的需求〉有所回應,他提道: [...]

  4. 喲哪桑 說道:

    Hi 同人學長:

    我個人不是很同意, 依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的. 我的理由在:
    Review vs. Inspection — 亂談軟體工程的正名運動

    Hi 鳥毅:

    我們讀過一所很有趣的學校台科大,不分年級或年紀,彼此都叫學長,因為大家在各自的領域,都是學有專長。有點怪,但還滿有道理的! ^^

  5. [...] software review,在看了喲哪桑學長對我的文章所寫的回應後,發現學長對我想要表達的意思有些誤解。學長提到: [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">