最新文章

Agile常見疑難系列(三) 撰寫使用者故事常見的問題

使用者故事(User Story) 是敏捷社群用來描述需求的 practice. 它非常容易上手, 但是也容易犯下錯誤, 以下便是常見的問題:

Agile常見疑難系列(二) 關於會議

很多人不喜歡每日立會, 覺得他很無聊, 很浪費時間. 可是為什麼會這樣呢? 我想請大家思考幾個問題

專案管理五原則,讓你避開不合格PM

有人問我怎麼在面試時去找出真有經驗與能力的PM?我沒有絕對的SOP,很多時候從他的回答與提問中去看看他怎麼看問題,會在意哪些事情。但我有幾個絕對能避免掉不及格PM的面試原則:

考上PMP後的下一步(3) - 我的公司沒有在用PMIS,我該先學嗎?

上一期我們聊到PMIS在管理規劃上的一些好處。 比方說,它讓PM更快完成專案規劃、方便做兵棋推演、以及在面對變動時可以很快執行假設分析。 這些都是紙本或是EXCEL等工具較難達成之處。 但有人可能不免疑問:「我的公司沒有用這類工具的習慣,或是我的專案很小。 加上紙本或Excel規劃其實也不麻煩。 那我是否還值得學這些工具呢?」 我的回答通常是,『就算如此,你還是值得學習一套這類工具』。 主要的原因在於,你不會永遠都只當個小PM,之後可能是大PM(如Program Manager)甚至負責好多案子。 你的案子也不會永遠都很簡單,遲早你會開始面對複雜的案子。

如何面對不合理的專案時程?

"當你接到一個時程極其不合理的專案時,你首先該做的不是哀嚎抱怨,而是去了解為什麼這個案子會來的又快又急,是因為公司面臨了很大的困難或挑戰?還是因為策略的急轉彎?又或者是老闆純粹等不急了?了解原因你才有可能知道如何去解決當下的問題,也許你的老闆是因為看到競爭對手推出了某項服務,所以希望自己最少不要輸人,要快點把這個功能(後稱A功能)加上去,而在本來的產品規劃中,A功能是包含在1.05版裡,老闆只知道1.05版裡頭有A功能,在他的心裡認為『1.05版=A功能』,所以他是直接跟你說:「一個月內把1.05版做完上線。」"

敏捷轉型其實是一種創業

很多人問到, 在公司或是團隊中, 要如何推廣敏捷? 是否有些公式可以 follow? 可惜的, 敏捷轉型的過程是非常不可預測的. 中間會發生什麼事情不知道, 結果會是如何不確定. 因此, 如果你是以傳統專案計畫的方式, 也就是大規模, 且詳細的方式來規劃, 這通常是徒勞無功的.

Risk Analysis中Duration Sensitivity與Schedule Sensitivity Index的差異

Duration Sensitivity 指的是 作業的工期與專案工期間的關聯性 - 數值會介於+100%到-100%- 百分比無實質意義,只是一個計算出來用以排序的數值,目的是顯示一串作業關聯度的高低。- 因為是公式計算,可能會有負值。 但負值表示關聯度很低,原則上在大部分時候是可以忽略。 只有很小的狀況代表該作業增加會導致專案總工期的縮減。 Schedule Sensitivity Index 指的是 作業對於專案時間變化的關聯性 - 最可能造成專案時間變動的作業排最上面- 百分比無實質意義,只是一個計算出來用以排序的數值,目的是顯示一串作業

Agile常見疑難系列(一) 關於團隊

今年很多好友的公司都開始要導入 agile, 他們花了不少錢去上課, 很積極地想把 scrum 實施好. 在上完課程後, 他們都不約而同問了這個問題: 如何開始在公司內推廣 agile?

新創公司中的兩種 PM:Project Manager vs Product Manager

說到 PM 有兩種,我想大部份很多人直覺會說:有腦和沒腦的,後者佔 90%。恩… 或許在某些工程師眼中,或許是如此吧。 但今天我們要討論的是另外真正的兩種 PM:Project Manager 和 Product Manager。因為我剛好本身都有經歷、又剛好都在是新創公司裡,或許可以和大家分享一下這兩種 PM的差異。

我的Scrum新體驗 - 測試策略篇

在規劃測試時, 我們一開始面臨的問題是, 整個開發時程分成哪些階段. 也就是說, 是否要都是要由 iteration 組成呢? 可是我們公司有所謂的 alpha 和 beta 階段, 尤其是 beta 階段, 我們必須把產品交給外面客戶去做測試, 這可能是無法廢除的, 那要怎麼配合呢?

我的Scrum新體驗 - 回顧會議篇(Retrospective Meeting)

回顧會議是 Scrum 中最重要的一個會議, 它讓你有機會反省在上個 sprint 所做的一切事情. 老中很努力工作, 可是卻不檢討做事方法, 所以工作的很辛苦,卻不見得有效率.

考上PMP後的下一步(2) – 學套模擬工具吧

我在上一篇的文章最後提到說:取得PMP證照並不表示達到巔峰,僅表示踏到專業上的一個起點。 這是因為書裡的東西終究只是原則與公式,若要讓我們的老闆與上司覺得我們真的具備專案管理知識,那最簡單的方法就是「活用」這些知識在我們現有的專案中。 當然,這不用我說,大家都知道要活用才行。 但很多人也確實有這樣的困擾:雖然知道專有名詞的定義,可是到底該怎麼跟實際專案連結呢? 又該怎麼展現自己專業知識呢? 對此,我在此會建議,當你考上PMP後,其實下一步最好是去學套PMIS。 這是讓你整合理論與實務CP值最高的一條途徑。 甚麼是PMIS

我的Scrum新體驗 - 每日會議篇(Daily Scrum Meeting)

我的專案開始採用 Scrum 的方法來開發專案, 這是一個新的體驗. 一開始時是工程師們說要這麼做, 我的想法是一則以喜, 一則以憂. 喜的是終於有機會可以嘗試 agile 的方法了, 憂的是在這麼短的時程內, 用新的方法似乎風險很大. 不過既然大家都願意這樣做, 那就豁出去了. 因此, 接下來我將會分享這幾個月來(開始於2009/2中), 使用 Scrum 的風風雨雨.

組織向下沉淪,你我都推了一把

一間公司或一個組織的文化是如何形成的?是靠著組織中的每個人堆積出來的。文化會影響一個人的思考模式與行事風格,而這些人的思維與行為的集合,就成了這家公司的文化,很多人以為公司的文化是老闆造就的,但我想說的是,文化不太可能由單一個人決定。

為什麼我不推薦敏捷開發

當專案成員越多,我越不推薦敏捷開發,原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前,就跳下去玩敏捷開發,那和比通靈還慘,通靈起碼還有個目標物在前面,搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。 敏捷開發 - MBA智库百科 最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟體開發 - 維基百科。 誤解一:敏捷對人的要求很高 說高不高啦,撇開實作技術不談,你覺得要找到清楚專案開發流程、知道每位專案成員的工作內容、職責範圍、產出,並清楚專案目標、需求、使用者需要的開發人員(含設計師)很容易嗎? 如果上述條件無法達成,又