好人難為

這是一個專班學生的故事。

他的工作是跟物料管理系統的開發相關。公司用的實作框架中包含一個 tree 的 model。有一天,因為使用者的需求變更,他的上司決定把 tree  model 改掉以快速的解決顧客的問題。他仔細的看了這個方法,知道一定會對後續的成本計算產生問題,因此請主管不要改 tree model。

但是顧客的問題必須要馬上的被解決,所以主管決定還是要改。有軟體工程概念的他,瞭解這個問題的嚴重性,他深深的知道這個東西一改,以後的程式都會以這個基礎下去開發,到最後成本計算穩死無疑,因此堅決不可以改,兩個人於是吵了起來。

其他的組員覺得他很奇怪,沒事為什麼要跟主管過不去,還跟主管吵架。在一個保守的組織中,他的『雞婆』並沒有受到肯定,也沒有人有時間深入瞭解他所說的道理,只是覺得他很『機車』,他只好閉上嘴巴照做。

過了三個月,這個問題浮現了,大家忙得雞飛狗跳。但是,沒有人知道他們所遇到的問題是主管所造成的,也沒有人想到他。大家忙著找一個可以立即解決成本計算錯誤的方法。也許,再把 tree model 亂改一通吧。

大家覺得這個故事有哪些啟示呢?

留言

  1. 如果溝通無效
    1.忍氣吞聲一輩子(公司薪水夠高)
    2.默默的忍受到自己當主管(公司還算有未來)
    3.打包走人(公司沒救了)

    粗淺的想法@_@

    回覆刪除
  2. 1. 擇善固執本來就很難。有時候硬碰硬並不是好方法,需要有跟長官溝通的技巧。
    2. 公司的同仁也不挺你有點奇怪,一般而言公司總是有一群對長官不是很喜歡的人聚集在一起,所以你應該會有些支援。EQ 也很重要吧!
    3. 從技術的角度來看,元件或底層的東西不太應該去改他,這是一般常識,這個解法會不會太誇張了?
    4. 理論上,重大設計變更需要一群架構師討論。不過現實上,老大說了算。

    回覆刪除
  3. 這是一個典型 it 人走不出象牙塔的例子。

    充滿專業術語。而不會用生活中的例子去說服別人

    回覆刪除
  4. 前面三則意見我都贊成,不過我希望提供一點書生之見供參考。我想這位專班學生碰到的尷尬事,在我看來並不希奇,做為軟體工程師,碰到這種事,其實是希鬆平常,不足為怪,書本或文件也都常常提到「需求改變」這件事,不過這位軟工師似乎沒有注意到發展軟體的一些「原則」,其中有一項原則叫"Open-Closed Principle",這項原則簡言之,就是設計的軟體「可延伸但避免修改」,完整的定義可見諸於各種物件導向軟體工程的書本或文章,不在此地多說,這位專班學生或許可研究一下如何運用這項原則,如果他設計軟體之初能夠運用這項原則,或許不必如此委屈,也可大大提昇他的EQ。「註」這位學生如有興趣可參考:Bertrand Meyer著"Object-Oriented Software Construction", Prentice Hall, 1988, pp.23,因為OCP是他首先提出,不妨看他怎麼說。

    回覆刪除
  5. 文章的張貼者薛教授問到,這則故事有那些啟示,我想,我們教軟體工程或物件導向軟體工程的人,似乎沒有盡責,沒有讓這位專班的學生體會到,設計軟體系統時其實有許多「原則」可以運用,例如我2/21意見箱內談的Open-Closed Principle可能就可避免他的窘境,不過他或許不知如何運用這項原則,對我而言,這則故事讓我心有戚戚焉,好像教書的有點失職。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

CRC cards - 非正規物件導向發展技術

課程改進