言語的力量:說對話讓事情進行更順利

在2009年七月號的快樂工作人雜誌,有個主題是「10個狀況題大考驗:我該怎麼說?」,在文章中舉出許多範例,教大家利用言語的力量,來讓自己更有說服力,相當的實戰且受用。

筆者在這邊也有深深的感觸,有時候專案的成敗,跟PM是否能妥善運用言語的力量,有非常大的關係。同樣的一件事,能不能妥善的表達,對團隊的士氣、腦力激盪會議的成效、專案的進度…等,都有著非常大的影響。
閱讀全文

錯誤的期待是爭吵的開端

假設你要找一個朋友來幫你寫網站,你問了兩個朋友。

A: 喔!我最近有點忙耶,不知道做不做的完,不然我盡量幫好了。
B: 我沒辦法幫忙。

結果到後來,A因為真的太忙了,網站一直做不完,一直delay,最後甚至說不做了,把你氣的半死,碰到朋友就抱怨,A這個人做是怎麼這樣,這麼不負責任,這麼沒義氣。

等等,這個故事有點奇怪,明明A幫你比較多,但是你對B反而不生氣,對A反而比較生氣,到底是為了什麼?A明明一開始有說他很忙,他也不知道做不做的完。
閱讀全文

專案外包的衝突與兩難–到底什麼是需求變更

一份軟體的規格書,包含了白紙黑字的規格和Common sense,譬如說好了,註冊功能是屬於需要白紙黑寫在規格書上,但註冊時使用者要輸入兩次密碼以作確認,就是屬於commone sense的範圍,通常不需要寫在規格書上,外包商也應該實作給客戶。

但是問題就出在,客戶認為理所當然的事情,外包商可能會因為文化、背景與domain knowledage的不同,造成對common sense的理解不太一樣。舉個例子來說,簽約時只提到登入功能,但是客戶的common sense可能還意謂著可以用Open ID來做登入,但是外包商的common sense可能就不含這項功能。
閱讀全文

專案外包的衝突與兩難–delay的處理

「專案外包」的過程當中,除了硬體成本之外,時間就是最大的成本來源,而Delay所造成的影響,不但是客戶滿意度的降低,更是承包商成本的提高。所以,當Delay這件大家都最不願意的事情發生後,所謂的解決之道,就是在成本和滿意度中間求取一個平衡。
閱讀全文

用Google doc來做腦力激盪會議

傳統而言,腦力激盪會議的型式都是要大家排排坐,頂多桌上多了些甜甜圈。

但這樣的一個腦力激盪會議,通常都得強制要求大家參加,並且要事先準備ideas,而且在會議當中,常常大家都會因為還有事情要忙,腦袋會卡卡的,效果會很差。
閱讀全文

專案外包的衝突與兩難-先講感情再講問題

了解了delay的成因之後,筆者來分享一些自己在delay過一些專案之後,所整理的心得。其中最主要的轉變,就是把面對「專案外包」這項工作的態度,從「代工」的思維轉變成「服務業」的思維。

心得一:承包商是服務業而不是代工業,重視的是滿意度而非進度
閱讀全文

網路世代求職的壞習慣

進入網路世代之後,大家很習慣的就會去104、1111..等人力銀行,在上面刊登自己履歷,或者是尋找自己心儀的企業自己投履歷,這幾乎已經是現在網路世代最主要的求職方式。

不過這樣的求職方式卻有個缺點,以筆者的例子來說:若是在網路人力銀行針對「產品經理」進行搜尋,馬上會出現上百個選擇,在這麼多選擇之下,大家就通常只會針對自己熟悉或有聽過的公司投遞履歷,至於其他沒聽過的公司,我們就可能連點選都不會點選。在這種行為模式之下,往往我們都會錯過我們意料之外的好工作或好公司。

閱讀全文

跟IDEO學新產品提案方法

最令PM扼腕的事情就是,明明已經知道市場的機會就在眼前,好不容易在會議中做了新產品構想完整簡報,結果被同事和上司做了以下無情的批評:

  • 認為市場規模預估模型有缺點,對於新產品的未來太樂觀。
  • 認為很多時候產品要放到市場上才見真章,焦點團體或問卷調查只在封閉環境內測試,外部效度不夠。
  • 舉市場現有類似設計的產品做為反例,來佐證這樣的產品不會大賣。
  • 上司以自身過往類似驗來作為反駁,說明新產品並不會有市場。
  • 專注於找出新產品的缺點和問題,但是給的支持卻很少。

閱讀全文

專案外包的衝突與兩難–delay的成因

這次我們來談談delay。

delay對專案來說,是件非常容易發生的事情,就算是經驗豐富的專案經理與專案團隊,還是很難避免delay的命運。可是當我們參閱許多專案管理的書籍,確實有許多關於專案時程控管的知識,諸如:甘特圖、WBS、PERT、Critical path…等,但卻很少提及應該如何面對delay,又該如何處理delay,這方面的課題確實為一般專案管理書籍所忽略。

閱讀全文

專案外包的衝突與兩難-引言

過去,Mr PM都是處在發包專案的角色,現在因為自行創業,必須將30%的力氣拿來接案來養公司,所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者,或許有些經驗可以來分享給大家。

我們這邊來看看,最理想的軟體接案流程是什麼?

  1. 客戶很清楚Spec或User Scenario,詳細的告訴接案公司,雙方就依此簽約
  2. 接案公司設定了Schedule與Milestone,每個Milestone要交付的事項也被清楚且具體的定義
  3. 完美且準時達成了Milestone交付的事項,沒有拖延或爭執
  4. 客戶完成專案,而接案的公司也撐到專案保固結束,尾款也順利領到,皆大歡喜

閱讀全文

Domain name想破頭嗎? 不妨試試下面網站

(本篇轉自筆者發表在另一個blog的文章)

想Domain name真是個超級困難的任務,一群人鎖在辦公室裡面一籌莫展,有時候好不容易想到個名字,但是卻早已經被人家註冊了。

英文畢竟不是我們的母語,要想個好名字,自己在那邊空想是沒用的,得需要有一些Input,除了翻字典外,或許可以借助一些英文名字產生器來幫忙。

閱讀全文

產品經理該怎麼發bug report

bug report,這是產品經理在做完User Accepet Test(簡稱UAT)後的產物,就是根據產品經理手上的Test Case,一樣一樣測試,然後把測到的問題整理成一份報告(格式或許是Excel檔),然後給研發部門參考,也可以當作產品經理與研發單位之間的Tracking List。

看起來很簡單的事情,不就是按照Test Case上的操作步驟,一個一個做,然後把結果不正確的找出來,就這樣而已。雖然僅僅只是如此,但是加上一些辦公室政治與人性在其中的話,那事情就會變得「不簡單」了。

閱讀全文