小弟最近完成了終身大事，婚禮當天，我們設計的活動，效果還蠻不錯...而過了幾天，前往戶政事務所的時候，卻因為少帶了戶口名簿，又來回了一趟....
這讓我不禁想到，當把婚禮比擬成專案，婚禮當天可以相當於驗收完成，而真正的夫妻關係(結案)，可是得等我登記完成(結案程序)才算數哩...
(Read More...)

相信所有搞軟體的人都能深深的體會到 「上線...才是挑戰的開始啊」這一句話對最近系統上線的我們，感受更深，尤其是我們的平台都是以服務國外的客戶為主
半夜 On Call 是常有的事，恰巧之前看呦那桑和同人的文章，提到了「為了維護而設計」以及討論到軟體生命的週期的觀點，不應該只是把專案當做是「一次性」的任務看待。
我深深認同這樣的想法，並且覺得，當大家把專案的定義和特性唸得越熟，更容易陷入「一次性」「短暫性」等等的迷思.....
(Read More...)

自從換了新工作後，很久沒有這麼認真工作了....
新公司的團隊，都是以網羅較為資深的人為主，因此工作起來特別的爽快
也在幾次吃飯聊天中，看到大家經驗豐富的一面，也讓我感受到一些很重要的關鍵：「共同經驗」

因為大家都有從工程師一路爬到PM或是管理階層的經驗，因此，在面對許多議題時
我們會很容易在溝通時就建立起同人文中所提的「語意庫」，
緊接著在「優先次序」「解決問題的手法」上， 就會很快取得共識，然後可以放心的交辦和解決問題

很久沒有發表文章了...就來寫寫最近有趣的事吧
最近有一艘目前世界上最老的郵輪--忠僕號訪台...據說它比鐵達尼號小2歲,而船上總是載著100噸的文學作品,往來世界各地傳遞知識和福音
再過2年它就要退役了,看到這艘船...我深深被它的使命所感動,所以趁著這次機會,我也上去參觀了,在它的船上書店,也買了一本John Maxwell 的 The 360^O Leader
而之前也和各位報告過...最近在幫忙朋友起草一個新組織的年度計畫,所以,我對於 Vision 這件事特別的有感觸阿

看了喲哪桑的「章子怡教軟體度量」以及同人的「軟體度量與數字陷阱」
小弟我有些許的想法想補充一下，兩篇文章告訴我們
當你覺得有一定程度的重要性或管理上的意義，就可以量，而且有量總比沒量好；
但是吶，不要被數字迷惑，而失去了當初量測的目的。
這樣講起來，或許會對某些想要試著用量測手法做一些改善的組織失去信心，因此我在想，為何不多加入一個東西-- Facts 來輔助呢？

繼高鐵之後，又一個血淋淋的品質教訓「台灣彩卷」...
當然，說風涼話很簡單，不過看著這些經驗和教訓，學習自我省思會更重要
我在yahoo上搜尋了一下台彩的新聞，找到這兩篇
「工會促台彩拿出良心 別再省錢」、「台彩走鋼索 難保不會再當機」
讓我有蠻深的感觸，在軟體產業，通常都會有這樣的一個想法「先求有再求改善」，當專案時程壓力很大時，這的確是一個策略，但是，它通常隱含一個重要的前提，你必需要能夠確保在未來的某段時間和資源許可內，你是有辦法做改善的才行....
(Read More...)

啊？ 做專案而已，還要管有沒有願景喔
這不是沒事找事做嗎？ 且聽我慢慢道來~

首先再度感謝呦那桑的整理「我看獨孤木與kenchu大戰專案管理 」
他把我們幾個人的文章找了幾篇整理出來

而我上篇有談到PM是不是Team Leader，事實上我並沒有很正面的問答這一個問題，
因為Team Leader到底要Lead的Team是誰，這是個蠻複雜的問題，事實上，因時制宜很重要，沒有對或錯。
我實在很想用一個不負責任的回答：「都可以」，但總覺得講了會被網友罵。
而我用一個極端的問題(我是個徧激的雙子座)來說「管理」這件事在專案中很重要(我的管理定義有包含「人」「事」「物」)，但是PM是不是可以完全和技術切開？我覺得這是個極難回答的問題
但至少在軟體相關的案子，PM可以懂但不一定要會做；若完全不懂，可是有一個默契良好的技術達人，其實也並非完全不可。
而這一切的源頭，我覺得是在於「PM是如何產生出來的」

大抵不會有人質疑專案的基石是互信~ 不過說來簡單，做起來卻蠻難的
信任是一種投資報酬率很低的東西~ 可能你要做對10件事，才能交換到客戶一點點的信任；然而
你只要毀一件事，有可能全盤皆輸....
(Read More...)

這是一蠻深入的主題，值得為它寫一篇來研究一下
(Read More...)

最近發現有2位網路上我很尊敬的朋友 喲哪桑 和 同人 有引用我「Change Management」的文章，並提供了我一些很好的意見
其中針對「專案假設」上面，他們分別都給了一些補充，所以也讓我想針對「專案假設」這一個主題發表一些看法和整理，希望可以互相交流一下
對我而言，我把「專案假設」是當做一種工具在看，透過它，可以用來簡化某些問題或狀況，至於是不是非得這樣用，這是見人見智的問題。

在前一篇曾提到，我覺得軟體的專案大概是失敗率最高的專案了，撇開公司管理的因素不談，軟體專案有一個很大的特性，就是「變」。
客戶的需求會隨著專案的演進而產生更多新的想法；開發的技術會隨著時間的演進而產生更多應用的方式；團隊的架構會因為能不能忍受「死亡行軍」而產生去留
面對這麼多的變化，套句投資大師巴菲特說的，要「去繁就簡」，掌握少數的因素，並有效管理它，把問題減到最低，而面對專案這麼多的變數，要從那裡做起呢？從Scope開始是一個蠻不錯的想法....

之前有人曾這樣告訴我，專案管理有2大聖經「人月傳奇」和「與熊共舞」
「人月傳奇」列舉了許多軟體專案的問題和現像，看了也讓人十分感嘆，不過卻有點無能為力的感覺
因為很多是組織上的管理手段、觀念上的問題，身為一個沒有實權的PM，要做一些改變的確不易，而最近在研讀的「與熊共舞」，
它則是從風險的角度出發去看待專案，章節的設計讓閱讀的感覺蠻清爽的，今天就和大家分享一下「與熊共舞」的一些片斷吧。

前陣子去上課，聽到這一個授權的小技巧，覺得蠻不錯的，分享給大家參考一下。
它稱之為「181」法則。

剛好在等系統計算東西，順便在寫一篇駐點在客戶的經驗和想法，說到駐點在客戶端，我也算是經驗豐富了~
不管是用工程師的身份或是用PM的身份。
我後來發現一件事，在駐點時，是客戶會很仔細觀察你的時候，如果出槌個幾次，就很容易被人看輕吶~~
(Read More...)