企業專案治理 初探

所以如果你打算只開一間店，我猜你的經營重點，恐怕會擺在找個有能力的廚師、找個人潮聚集的地點、想辦法壓低經營成本、好好訓練服務人員等相關事宜上。 就算你完全不會煮菜，只要願意花錢雇個有能力的大廚，你就可以把一切事情都仰賴在他身上。 不過這位廚師可忙了。 他需要設計菜單、採買食材、並在廚房實際烹飪，所有流程可能也搭配著他來設計(送菜、跑堂、點餐等)。 換句話說，他大概是整間店的靈魂人物。 有甚麼資源，都應該投資在這個角色身上，所有人都應該配合他來演出。

改革要成功，你該先搞定這三件事

我們是商業顧問，所以不可避免常常會有人來找我們諮詢管理問題、請我們去上課、或是協助內部改革。 多年的觀察下來，我的結論是：任何改革要成功，其實有幾個關鍵的前置準備。 換言之，講師與顧問不是魔法師，在你的組織還沒有準備好之前，外部顧問其實幾乎不會產生甚麼決定性的作為。 但甚麼是該事先準備呢？ 我覺得有三件事。

沒有資訊背景與經驗！ 該如何委託外包商開發軟體？

這幾年認識許多軟體創業的朋友，他們在找尋不到合適的技術合夥人且自己不懂程式的狀況下，會轉向委託軟體外包商開發產品，可是軟體外包涉及的層面非常廣，如果沒有外包的經驗，就算是專業的軟體公司也很難與外包商磨合，更別論沒有資訊背景的朋友了。

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

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

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

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

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

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

為什麼我不推薦敏捷開發

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