新手PM入門

棒球教我的專案管理:團隊的合作意願,來自堅實的信任

棒球是一個分工細緻的團隊運動,每位選手在場上的位置固定,投手就好比前線作戰人員,是直接與對手鬥智、鬥力的角色,捕手就像幕僚,適時提供引導。除了守備位置不同,每場比賽出場擊球的次數也略有不同,例如前幾個棒次可能獲得多一次打席。這些差異不僅製造了當英雄的機會,同時也代表著需要藉著分工合作才能取得勝利。一個再厲害的投手,即使完投完封,若沒有隊友打下分數,也無法贏球。

不想再被眾多需求滅頂:產品經理要如何定義需求的優先級

曾經有段時間,我常會面臨到一個尷尬的狀況:不缺需求,但是迷失在眾多需求中。覺得這個需求很緊急、那個需求也很重要,想實現的需求很多,但每次迭代的開發資源有限,不可能一次全都做完,所以,這時決定需求的優先級就變得非常關鍵,不然團隊會不知道各項事務的輕重緩急,資源和精力都無法集中在最重要的目標上。那麼該如何定義需求優先級呢?

【給PM】產品,應該要定期砍功能,人生也是

做為一個PM,我們常常在想要「加什麼功能」,但你有沒有固定回過頭檢視,什麼功能已經可以「砍掉」了呢?「什麼?為什麼要砍掉?即使沒人用,放在那邊也不虧呀?」 當然虧,功能一直加上去的結果,產品會變得越來越複雜,其實會造成一些問題...

你的專案裡,卡了許多現金嗎?

我最近隨手拿起書架上一版多年前的商管漫畫看,裡面的主角遇到的問題是,她負責的公司面臨倒閉危機,這間公司一條龍從成衣的設計、製造,到銷售,都一條龍包下來。但是由於銷售狀況不好,現金流不足,快要無法償付銀行的貸款利息。銀行端要求主角在半年內想辦法生出十五億現金還貸款,才不抽銀根,不然公司就要破產了。主角嘗試了很多方法,最後,她在實地探訪工廠時,找到了藏在裡面的「現金」,這個現金就是:半成品庫存。

進階的管理人才,是怎樣解決困境的?

初階的管理人才,會希望一切都準備好了才開始做事。他們會希望流程要建好,系統要弄好,其他部門要好好配合,他和團隊不要有太多雜事干擾,若是平台還缺少了什麼功能、系統有不穩的狀況、其他部門無法配合,他們就變得負面,認為時不我予,公司制度不佳,甚至開始「等待」一切變得完善的一天。追求流程、系統的穩定無可厚非,但是,進階管理者會這樣想。

【專案管理書摘】關於利害關係人管理-集體開會,只會讓你的產品走向平庸

專案執行中,利害關係人的管理,始終是個麻煩的問題:他們界定專案成功與否、他們管理資源,但他們也常常因為意見紛歧、或是需求變動,而導致產品走向平庸,甚至難產。因此,有經驗的都知道,控制好利害關係人的需求,會是專案成敗的關鍵。但要如何在專案的初期,有效接觸利害關係人?又該如何了解這一堆人的不同想法?一個一個聊天,也太浪費時間了吧?

【專案管理書摘】為何產品專案會失敗?團隊一開始就該避免的十個經典地雷

踩到地雷超痛的啊!如果想避免踩雷,最好一開始就先注意幾件事。像是產品路徑圖(product roadmap)一頭熱的那時,我看過無數的路徑圖,絕大多數的路徑圖,基本上是按優先順序來排列功能和專案。行銷部門需要那份圖推出宣傳活動,業務部門需要那份圖招攬客戶⋯⋯但問題就出在這裡,我稱為「產品的2 個麻煩真相」。

只理解規格是不夠的!你認同自己的產品嗎?

專案管理告訴我們,只做範圍內的事情,超出範圍外的叫鍍金,但若你做的是產品,你要記得這句話適用的範圍是在當某個版本的功能與時程已經被押上,且你沒有多餘的時間多做時,要知道,對一個產品來說,功能不可能停滯下來,一定會不斷的演進,但專案則是這個產品開發過程中的一個版本階段,所以專案是有明確的範圍與時程的,但產品發展不能這樣畫地自限。

客戶提的需求不精確時,如何拆解出客戶的真需求?

客戶提的需求大部分不是真的!並不是客戶刻意要騙人,而是他真以為這就是他的需求。人們經常自以為是的把心中所想,大多時候是錯誤的解決之道,當作需求來提出,而不是說出希望被解決的問題或是想被滿足的情境。這就造成了誤把規格當需求,對於一個不專業的人所開的規格,又怎能期待最後真能滿足需求,必致客訴抱怨。那麼,真正的需求又該如何釐清呢?

為何報告時,老闆總是不耐煩?怎麼抓到報告關鍵點

不少部屬很怕跟主管報告事情,因為總是講沒幾句話,主管就不耐煩的聽不下去,要不就是主管根本就聽不懂部屬在說些什麼,經常還聽錯了意思;嚴重時甚至還會把好事報告成壞事,有功報告成有過。 明明就想好好的報告清楚,但結果卻經常適得其反。這又是怎麼回事呢?

我沒有技術背景,如何成為PM?

最近跟朋友聊天,他們問到,我是從財金系畢業的,沒有任何技術背景,但是卻能在監控產業擔任大型系統的產品經理,還一路受到重用,負責越來越大的專案技術性一定會越來越強,也會遇到許多專業資深的RD,我是怎麼做到的? 面對這些問題,我想來分享幾個在這趟奇幻之旅上學到的東西......

專案管理中最大的風險,通常躲在「邊界」

大家覺得,在專案進行的過程中,可能造成最大風險的部分是什麼呢?是技術難度?市場需求改變?利害關係人的支持?我認為最大的風險來源,總是躲在邊界。由外往內,是公司內部與外部合作夥伴的邊界;是不同團隊之間的邊界;也可能是不同人合作,負責各自事務時,分工的邊界,由於是邊界,所以容易被忽略,容易以為對方會做或權責不清,就會掉球。尤其邊界越往外,風險越大,而將這一切串連起來的,是溝通。

產品經理的關鍵力:技術腦v.s.商業腦間的轉換

任何一家公司都有研發部門負責產品與技術研發的「技術腦」,好的公司懂得把「技術腦」轉換成「商業腦」,這個轉換過程在許多公司是通過「產品經理」來完成的,也就是說,優秀的產品經理更是在企業內部懂得如何將「技術價值」轉換成「商業價值」的關鍵角色。

專案預估無法精確時,你還是能從排程中找出價值

「Joe,我參與的專案因為過去從沒做過,所以很多工作的預估沒辦法精準。這樣排程不就沒意義了嗎?有什麼方法能提高工期的預估程度嗎?」大家對於工期預估這檔事,常過度把重點放在「提升預估準確度」這部分了!但準確度其實沒有大家想像的這麼重要。有人看到這邊可能就會問:「如果預估就只是猜,那排程不就一定不準?我要一個不準的排程做甚麼呢?」這倒是整個概念裏頭大家最該扭轉的地方:做時程預估的主要目的,是讓我們在專案面臨變動時,對於怎麼調整有一個比對的基礎。能精確當然很好,但不精確不表示就不能用。但不精準是要怎麼用?

高效能會議的七個習慣,不能只是開會前準備資料而已

有時候開會變成聊天,結果一件事情討論了很多次,最後專案卻還是沒有什麼進度。有時候開會時大家都很努力,但討論的時間拉得太長,講的話失去焦點,讓會議變成一件累人的事情。我自己也是上班族,每天面對許多公司內行政會議、客戶專案開會,甚至有時需要談判決策的會議。回顧自己親身經歷過的各種冗長會議、高效率會議,兩者對比,或許可以從我自己的經驗,整理出讓會議變得「高效能」的七個習慣。