PM三問


2015.12.10 在微軟BizSpark分享的「PM三問」
2015.12.10 在微軟BizSpark分享的「PM三問」

摘要

本文為2015.12.10於微軟BizSpark分享關於專案經理這個角色我認為最核心的三個問題,以及這兩年左右在新創圈擔任Project Manager角色對於這些問題的想法和當天與會朋友們的一些見解和討論。


 

專案經歷

過去領導過的大型專案主要是2011年的首屆台大創業週,業界的經驗則從2014年擔任Sharelike的PM與COO開始,後來到資安公司承做小型資料中心的建設,小型的專案包含KPpointGEEP、以及共創廚房等短期的實驗性專案等等。


 

第一問、何謂專案管理?

我想探討任何問題都應該可以從最基本的定義或是認知開始,因此用這個角度來開場,坊間對於專案管理有相當多的書籍或是學派可以參考,但我在這次分享當中想要把這個問題回歸到最根本的本質,到底「專案管理」是什麼?

會中朋友提到包含「被時間追著跑」、「要在對的時間把事情做完」等等,我想應該都是一般PM常常會需要去面對的問題。對我來說,每一次的旅行、每一次的聚餐、婚禮、甚至是每天的生活,都是可以被管理的專案,也因此可以說專案管理基本上是無所不在,只要你想要控制事情的發生與結束,就可以是專案管理涉入的範圍。因此,我的答案是「在四度空間裡面玩樂高積木。」

2015.12.10 PM3Q_JPG.004
PM這個角色對我來說就像是一個能夠在四維空間裡面玩樂高積木的人,圖則為2015年進行的微型資料中心設計概念圖,透過仔細的事前模擬與完整的評估,可以大幅的降低施作時的成本以及預期與成果之間的落差,足夠細緻的模擬是規劃專案時相當重要的過程。

我想應該大部分的人小時候都玩過積木,玩積木這件事情本質上是透過組合不同的元件,讓這些物質表現出內心想法所應該具有的性質或是樣貌,那麼在四度空間玩樂高積木像是什麼樣的概念呢?想像你今天是在一個可以任意在三度空間裡面定位所有積木的玩家,而這些積木會像是坐在迴轉壽司的火車上不斷的往前飄移,能夠在四度空間裡面玩樂高積木的人會像是能夠在火車開始跑之前,預先把應該要組合上去的積木定位在適當的位置,當火車駛過整圈軌道之後,積木就完成了,但有時候可能需要在火車行駛的過程當中調整一下火車的行進方向或是積木的擺放方式,因此這個玩積木的人必須要時時注意火車行駛的狀況,避免發生意外的情形,或是在不對的速度之下撞上相應的積木導致嵌入失敗。不管你使用的是甘特圖、Google Doc、或是Excel表來做專案的管理,目的都是為了要做到拼出完整的積木這件事情,因此專案的管理應該是為了專案的完成而需要管理,而不是為了管理專案而管理,有些團隊的執行效能會不彰,很大程度是因為管理過度而不是管理不足。

 

第二問、是領導還是管理?

我過去在擔任專案的領導人時經常會為這個問題困擾:「我到底應該叫做Project Leader還是Project Manager?」為了這次的分享會,我又再次仔細的思考這個問題,在分享會當中也許多人都提到,領導往往是跟「人」有關,而管理是跟「事」的關係比較大,而我自己的觀點是:「領導是為了使人成長,管理是為了使績效成長。」

2015.12.10 PM3Q_JPG.006
圖為2015年進行「共創廚房」專案的留影,透過結合startup weekend與烹飪的過程,可以在短短四小時內練習從組成團隊、構思產品、爭取支持與實際做出產品與分享成果的過程,同時透過同伴之間的互相學習,可以在短時間之內促成大量的合作、交流與個人成長。

這件事情可能在軟體新創公司裡面會特別的被放大,因為大部分的時候並沒有明顯的績效可以管理,比起過去製造業強調生產效率與精準度,以人類智能為主要產出的軟體業更偏重人的素質與成長,而人的成長則能反應在績效上面的成長。在分享會當中我特別提了Google的70/20/10法則,我想,任何一個想要建立具備足夠程度影響力組織的人都應該思考一下人力資源這件事情,組織的運行當中,任務的管理與績效的追求是必然的方向,但如果要在人的成長與績效的成長當中做取捨,我想我會盡可能的去選擇人的成長,這才能夠為組織帶來長遠的利益,但前提也必須是組織能夠承擔短期的壓力,這便是要成為領導者必須要能夠承擔的責任之一,Google把10%的人力產出放在看起來沒有意義的事情上面,為的其實也是能夠讓員工有更高的生產力與產出隨機性創新的可能性,如果組織把所有的執行項目都框架好了,那麼員工的創新空間也就消失了,就如同被暑假作業佔據的暑假是無法讓人有創造力的一樣。

 

第三問、如何評估PM的技能水平?

這部份主要取材自Jeff Sutherland的《Scrum:用一半的時間做兩倍的事情一書,雖然主要是談軟體工程,但其實當中核心的概念相當值得去探討,尤其是敏捷開發宣言的部份。在活動中我主要探討的事情是前些日子被問到的問題:「一個PM要怎麼去評估他的技能水平?」,相較於工程師的生產力可能可以用程式碼或是可用的軟體片段來衡量,一個PM的生產力或是技能水平應該如何衡量往往是一個不容易回答的問題,或許很大程度是因為PM的產出是必須要透過團隊合作才能夠完成,因此要衡量產出的因果關係就變得相當的困難,但我覺得Jeff在書中引用的「守、破、離」三境界用來描述PM的能力層次是一個相當值得參考的方式。

2015.12.10 PM3Q_JPG.008
《Scrum:用一半的時間做兩倍的事》一書中,對於專案管理者能力境界的描繪

還記得我2014年剛從矽谷回來時,在公司導入軟體工程的工法以及Scrum的合作模式,由於一開始對於整個系統的運作相當不熟悉,因此只能盡可能的按照《深入淺出軟體開發》裡面所敘述的方式去運作,使用了包含Kanban、Burndown chart以及導入一點點的TDD與CI,還好當時因為不熟悉,所以是漸進式的去導入,否則以當時只有3名工程師要同時負責Android App與網站前後端系統的開發,要硬導入完整的軟體開發工法會使得產品的迭代速度大幅下降。後來離開團隊之後我自己出來組織團隊做KPpoint專案,就重新思考了整個軟體開發的運作模式應該為何,雖然當時還沒有搞懂Agile與Scrum之間的異同與關係,但經過省思之後大略也掌握了關鍵其實是在人的溝通上面而不是採用繁複的管理系統,因此把過去習慣的規則大幅的簡化,只使用Slack搭配Googledoc與Google hangout,透過每日10~30分鐘的視訊會議,在短短兩週內就開發出了完整可用的系統,並且開始接觸使用者,發送我們的貼紙並累積資料,快速的迭代系統與我們的表達模式,最後順利的在選舉前完成我們的心願,做出一點小小的貢獻。到了今日,當我再回頭去思考應該怎麼進行專案管理的時候,首先浮上我心頭的就已經不再是任何的管理方式,而是「我應該要怎麼去創造價值?」「我怎麼樣讓團隊的成員能夠創造榮耀?」「我怎麼讓團隊成員能夠有效率、紀律的溝通與合作?」然後再回頭去思考我應該採取怎麼樣的管理模式,進而選擇適合的工具來達成我的目標。

我想很多技能的學習都會經過這樣的過程,先從臨摹開始,然後累積實際的經驗,接著透過經驗的檢視與反省,去思考背後的哲學脈絡與本質,進而能夠做出屬於自己的選擇,而能創造出自己的風格。因此,要衡量一個PM的能力,或許可以用管理或是領導風格的程度來做一種方式,一個具有自己哲學的管理者,某種程度上可以說必然是經歷了許多的實務累積之後才能夠擁有的成果與歷練。有些人或許在這個領域相當資深,但缺乏了反省與思考的過程,那也不過就是個操作管理方法的工匠,對我來說,能夠發展出一套管理哲學的人才算是真正累積了經歷,而能夠知所進退,領導眾人往正確的方向前進。


 

參考資料:

[1] Scrum:用一半的時間做兩倍的事

[2] 深入淺出軟體開發

[3] 第五項修煉

[4] 匠人精神

[5] Pretotype it

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s