好人難為
這是一個專班學生的故事。
他的工作是跟物料管理系統的開發相關。公司用的實作框架中包含一個 tree 的 model。有一天，因為使用者的需求變更，他的上司決定把 tree model 改掉以快速的解決顧客的問題。他仔細的看了這個方法，知道一定會對後續的成本計算產生問題，因此請主管不要改 tree model。
但是顧客的問題必須要馬上的被解決，所以主管決定還是要改。有軟體工程概念的他，瞭解這個問題的嚴重性，他深深的知道這個東西一改，以後的程式都會以這個基礎下去開發，到最後成本計算穩死無疑，因此堅決不可以改，兩個人於是吵了起來。
其他的組員覺得他很奇怪，沒事為什麼要跟主管過不去，還跟主管吵架。在一個保守的組織中，他的『雞婆』並沒有受到肯定，也沒有人有時間深入瞭解他所說的道理，只是覺得他很『機車』，他只好閉上嘴巴照做。
過了三個月，這個問題浮現了，大家忙得雞飛狗跳。但是，沒有人知道他們所遇到的問題是主管所造成的，也沒有人想到他。大家忙著找一個可以立即解決成本計算錯誤的方法。也許，再把 tree model 亂改一通吧。
大家覺得這個故事有哪些啟示呢？
如果溝通無效
回覆刪除1.忍氣吞聲一輩子(公司薪水夠高)
2.默默的忍受到自己當主管(公司還算有未來)
3.打包走人(公司沒救了)
粗淺的想法@_@
1. 擇善固執本來就很難。有時候硬碰硬並不是好方法，需要有跟長官溝通的技巧。
回覆刪除2. 公司的同仁也不挺你有點奇怪，一般而言公司總是有一群對長官不是很喜歡的人聚集在一起，所以你應該會有些支援。EQ 也很重要吧！
3. 從技術的角度來看，元件或底層的東西不太應該去改他，這是一般常識，這個解法會不會太誇張了？
4. 理論上，重大設計變更需要一群架構師討論。不過現實上，老大說了算。
這是一個典型 it 人走不出象牙塔的例子。
回覆刪除充滿專業術語。而不會用生活中的例子去說服別人
前面三則意見我都贊成，不過我希望提供一點書生之見供參考。我想這位專班學生碰到的尷尬事，在我看來並不希奇，做為軟體工程師，碰到這種事，其實是希鬆平常，不足為怪，書本或文件也都常常提到「需求改變」這件事，不過這位軟工師似乎沒有注意到發展軟體的一些「原則」，其中有一項原則叫"Open-Closed Principle"，這項原則簡言之，就是設計的軟體「可延伸但避免修改」，完整的定義可見諸於各種物件導向軟體工程的書本或文章，不在此地多說，這位專班學生或許可研究一下如何運用這項原則，如果他設計軟體之初能夠運用這項原則，或許不必如此委屈，也可大大提昇他的EQ。「註」這位學生如有興趣可參考：Bertrand Meyer著"Object-Oriented Software Construction", Prentice Hall, 1988, pp.23，因為OCP是他首先提出，不妨看他怎麼說。
回覆刪除文章的張貼者薛教授問到，這則故事有那些啟示，我想，我們教軟體工程或物件導向軟體工程的人，似乎沒有盡責，沒有讓這位專班的學生體會到，設計軟體系統時其實有許多「原則」可以運用，例如我2/21意見箱內談的Open-Closed Principle可能就可避免他的窘境，不過他或許不知如何運用這項原則，對我而言，這則故事讓我心有戚戚焉，好像教書的有點失職。
回覆刪除