世界愈複雜，我們就更需要簡單。簡單讓我們看清楚事物的脈絡，掌握重點，以協助做出選擇，並在適當時機採取行動。然而，簡單其實是困難的，因為要做到簡單，意味著我們必須清楚事物的全貎，行動必須要更有原則。尤其是在複雜多變的環境當中，簡單不能只靠直覺，而是有紀律的思考與行動。 那麼，用有紀律的思考與行動，以做到簡單，我們該怎麼做呢？前一陣子，同人閱讀了《越簡單越有力量》，我覺得這本書的觀念與方法，剛好可以提供我們複雜世界簡單之道的思考方向與指引。
朋友的分享讓同人看到，她的主管用一些不大精確的語言來讓她感覺問題不大。比如說用「c++、vb 都只是工具而已，不管你用那一種工具來開發系統，其實都不會有太大的差異，所以我們大可不用擔心」的說法，正是用不精確的語言來表達不當的概念，這其實是相當要不得的簡化。
系統分析師該如何思考與學習的方法以展現其專業。然而，許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」，使得系統分析師陷入了過度簡化設計與過度工程化，也就是所謂過度設計的兩難情境。
在台灣，品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外，以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」，讓開發人員認為品質是品質部門的責任，而品質部門則認為提昇品質不是他們的責任，以為最多只能做到知道產品有問題，而不知道如何改善它們，只能退回到開發人員那邊來解決。
從事軟體開發的工作中，同人也常觀察到一些開發者不懂藏拙的智慧，意欲表現自己很有能力，但卻總是被人看到他們虛有其表的黔驢之技。我們當然很希望這樣的人，不要出現在工作經驗當中。但很不幸地，世事總是難以如我們的預期，如果不幸在工作碰到這樣的人，我們應該如何自處呢？
專案經理利用軟體缺陷的創造信用來進行短期信用的流通，把 bug fixing 變成 feature request 的好處就等同於創造增加軟體開發修改 bug 代價的貨幣。然而，把 feature request 變成信用商品的後遺症，正是讓信用生產結構的迂迴，使信用崩潰延遲發生。
本篇文章是投稿 ZDNet 的文章原稿，並以〈專案不確定導致焦慮與迷失〉與〈專案不確定性導致焦慮與迷失(下)〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。 專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化，變化總是比不上老闆的一句話」之時，許多專案經理總是會擔心專案無法如期完成或害怕資源不足，而拒絕或延後專案變更的要求。但這樣的行為，卻往往造成工作成果無法符合專案實際需要的結構性因素，而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言，當然並不會樂見專案發生這樣的事情。 筆者前一陣子看到喲哪桑在〈換了屁股，我也換了腦袋〉的分享，提到他在時間緊迫的情形下，接受了專案的功能變更要求。那個變更要求原來是由他所提出，當時前任專案經理以時程緊迫為由而答應延後處理，而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生，於是決定不要再讓這個專案變更要求再次拖延下去，並在當下對專案進行變更。 筆者認為喲哪桑的作為令人激賞，並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定，而是欣賞他在決策過程中，展現出面對自己的勇氣與解決問題的思考。不過，卻有其他讀者對那篇文章抱持相反的意見。 某位網友對喲哪桑的分享，批評他是靠感情衝動來管理專案，甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念，實在有不可思議的謬誤，並且擔心那篇文章會透過 ZDNet 的報導，將不正確的知識與觀念誤導一般社會大眾。 然而，他對這篇文章的批評卻使人感到困惑，那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤，但看在專業人士眼裡，這樣的觀點又何嘗不是相當嚴重的偏頗呢？筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感，進而對改變的抗拒而產生無知的迷惘。 專案變更的基本原則 身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中，但在對專案缺乏可供客觀評論資訊的情況下，只憑專案經理接受專案變更的決定，就加以批判其決策感情衝動是否真的恰當？專案管理並不是神學或是玄學，而是屬於管理科學的範疇。因此，如果有人要批評某個專案經理是用感情衝動來管理專案，必須提出具體的事實根據，否則那只是無憑無據的推論而已，而這樣的推論多半只是源自於自我的偏見與扭曲。
今天早上在上班途中買早餐，在早餐店內看見新進店員因為尚未進入狀況而發生溝通問題。不過，雖然當下同人覺得很好笑，但經過事後深入思考之後，卻讓我學習到在溝通過程中，避免語意瞹眛的重要性。
新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力，他應該如何領導團隊來進行成功的改革呢？
許多採用使用案例建模方法進行需求分析的開發者，對於不需要使用者介入的系統自動作業，通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動，這對系統開發者而言，可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能，這樣看起來是可行的需求塑模手法。 不過，工作排程者牽涉到系統設計的觀點，如果我們不想讓需求相依於系統設計，那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢？我們不難理解，工作排程者也只不過是實現時間概念的具體設計。因此，照理時間才是系統自動作業的主要參與者。 然而，當我們把時間當成系統自動作業的主要參與者時，我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統，使用案例應該是以使用者或外部系統來看系統，瞭解如何系統與互動而達到特定目的或產生價值。很顯然地，系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。 換句話說，我們並未找到系統自動作業的真正使用者，即使我們把工作排程者當成使用者，以使用系統的組織觀點來看，我們將會無法了解系統自動作業和組織目標的達成有何關係，而遺漏了相當重要的使用案例觀點（use case view）。
最新迴響