這次我們來談談delay。
delay對專案來說，是件非常容易發生的事情，就算是經驗豐富的專案經理與專案團隊，還是很難避免delay的命運。可是當我們參閱許多專案管理的書籍，確實有許多關於專案時程控管的知識，諸如：甘特圖、WBS、PERT、Critical path…等，但卻很少提及應該如何面對delay，又該如何處理delay，這方面的課題確實為一般專案管理書籍所忽略。
分類彙整: 管理
專案外包的衝突與兩難-引言
過去，Mr PM都是處在發包專案的角色，現在因為自行創業，必須將30%的力氣拿來接案來養公司，所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者，或許有些經驗可以來分享給大家。
我們這邊來看看，最理想的軟體接案流程是什麼？
- 客戶很清楚Spec或User Scenario，詳細的告訴接案公司，雙方就依此簽約
- 接案公司設定了Schedule與Milestone，每個Milestone要交付的事項也被清楚且具體的定義
- 完美且準時達成了Milestone交付的事項，沒有拖延或爭執
- 客戶完成專案，而接案的公司也撐到專案保固結束，尾款也順利領到，皆大歡喜
Domain name想破頭嗎? 不妨試試下面網站
(本篇轉自筆者發表在另一個blog的文章)
想Domain name真是個超級困難的任務，一群人鎖在辦公室裡面一籌莫展，有時候好不容易想到個名字，但是卻早已經被人家註冊了。
英文畢竟不是我們的母語，要想個好名字，自己在那邊空想是沒用的，得需要有一些Input，除了翻字典外，或許可以借助一些英文名字產生器來幫忙。
產品經理該怎麼發bug report
bug report，這是產品經理在做完User Accepet Test（簡稱UAT）後的產物，就是根據產品經理手上的Test Case，一樣一樣測試，然後把測到的問題整理成一份報告（格式或許是Excel檔），然後給研發部門參考，也可以當作產品經理與研發單位之間的Tracking List。
看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。
把「毅力」外包，解決沒時間看書的問題
俗話說：一個人的職場競爭力取決於他怎麼利用下班的時間。
說的很有道理，不過筆者下班以後，都是累癱在沙發上，哪還管什麼進修啊、競爭力。難得想打起精神來看點書，發現確常常精神力不集中，看沒兩下子又想回到沙發上，當個不需要動腦袋的人。
很多想增強自己競爭力的人，但是本身的個性有可能跟Mr PM很像，非常不具備Hard working和堅持到底的毅力，只要和職場工作的比較沒關係的進修，通常都會草草了之。到底我們這種人該怎麼辦才好？是否有那些社會上的典範，可供我們這種人一些啟發。
如何面對鬼打牆的會議溝通
產品經理很重要的一塊工作內容，就是溝通。和研發部門溝通、和生產部門溝通、和業務部門溝通，最常見的溝通場合就是會議，但是令產品經理最「OOXX」的也就是所謂的「鬼打牆會議」。
什麼是鬼打牆會議，就是討論個老半天，好像都圍繞在主題上，但是又不算是個會議結論。舉個例子就明白。（以下是真實案例，為保護當事者，人名皆虛擬，案例內容也馬賽克修正過）。
除了「議而有決、決而必行」外, 還需什麼會議技巧?(二)
再換個角度來看「會議內容」，也可以從「會議發生的頻率」來分類各式各樣的會議內容，探討每種不同會議的本質與管理重點：
閱讀全文
除了「議而有決、決而必行」外, 還需什麼會議技巧?(一)
關於開會的技巧大家應該都滾瓜爛熟了，這邊也不需要再炒冷飯。簡單的摘要大家所知道的會議技巧：
大致上就是「要準備議程」、「要有決議」、「要追蹤決議施行結果」。其中的管理原則就是要「會而有議、議而有決、決而必行」。
這邊要換個角度來看會議，因為大家所熟知的「避免會而不議、議而不決、決而不行」的會議管理原則，並沒有碰觸到會議的「組成元素」和「會議內容」兩個重要項目。事實上，會議的「組成元素」和「會議內容」，也是影響會議品質的重要因素之一。
閱讀全文