2016年9月9日 星期五

無法標準化的職務 ( Unable standardization duties -- PM)


以工作來說,每個人或多或少都會希望能夠依循著特定的SOP來執行任務,如此一來,除了降低自己的風險外,同時也能以最短的時間讓自己能夠融入工作群體當中,但是,有一個工作職務,很多人有興趣,但是也有人不願為之的工作,那就是 ─ 人見人愛(哀?)的PM吧?現在就回頭來看看這份工作為什麼很難有SOP吧?

其實PM這個詞經常會被混用,先不論是產品或是專案的管理,基本上只有戰線長短的問題,要處理的面向不會因為產品或專案有太大的差異,除非是既有的成熟產品,同時接近它產品周期的尾聲時,才有可能只剩下維護的既有工作,對於PM來說,第一件要認清的事就是,這個專案(產品)究竟是從何而來?表面及背後的實質目的為何,如果這點沒有先認清的話,基本上PM之路應該會走的很艱辛。

目的決定一切

為什麼會這麼說呢?只要接過專案的人,一定會知道專案的來源千奇百怪,有的是不得不接、有的是為名、當然絕大多數是為利,畢竟一個專案,動輒要動用的資源,都不是個小數目,但是,這彼此之間的微妙關係,身為PM的你,就要看清背後的真相,千萬不要有認知上的落差。

因為對於開發人員來說,或許每個專案只有技術層面及架構上的不同,但是PM的責任卻不局限於技術面而已,其它的事,也都得要了然於心,同時,這也是許多人不想觸碰這項職務的主因之一。

當然,這不代表技術核心的部份就不需要理解,畢竟很多PM還得兼Pre-Sales之職,所以對某些技術的理解絕對可以為溝通上加分,若是說得天花亂墜,最後卻無法收斂時,丟單事小、嚴重一點,還得賠著對方走完一遭可大可小的冤枉路。

基於自己有過FAE的歷經,對於業務跟PM的差異也有一定頗深的體驗,有時PM反而是更適合去談案子,因為,機會為公司獲取更大的整體利益,當然會有對等的風險,會因此少了許多斡旋的空間(因為PM的角色,如果要在最前端處理業務相關的事,常會因為最終的目的,犧牲掉必要的利潤或是其它條件)

由此可知,「實質目的」往往會是決定一個專案如何進展的必要條件,也是為何PM得對此具備其敏感度,有時甚至會凌駕在其它專業之上的主因,接下來我們就回到正題,談談為什麼PM是種無法標準化的工作?

沒有絕對正確的選擇

為什麼PM的工作是無法標準化的主因就如同標題所示,針對一個能夠執行專案的團隊來說,可能會有下述幾種角色,PM、開發人員、SA、UI/X、業務、行政及會計,至於老闆的角色就暫先不論,雖然在初期人事精簡的狀況下,有可能會身兼數職,但是以專業分工來說,這樣的配置應該是比較健康的作法,而且也比較能接受波動的風險。

一般來說,最常見的專案流程來說,業務把案子談進來,至少在最後要成案之前PM應該就已經開始參與,然後接下來PM就得開始成為業主跟內部技術資源間的橋樑,光在需求及規格書的確認,就會有很多需要折衷的部份,這時候就算有SOP也只僅限於流程的部份,實務上幾乎沒有一定的規則可以依循。

舉例來說:開發前除了確認規格需求外,其它的文件也會依續產出,無論是SA、SD文件,但是每一個案子都有機會照這個流程進行嗎?

其實不盡然,很多時候根本來不及做完這些文件,甚至連前端的UI/X都還沒有備齊,就得先讓開發人員參與,當然,不一定是指著手開始Coding,而是先理解規格書來進行準備,畢竟在人力不另外添加的狀況下,時間是公平的。

不過,有人會想為什麼不在前面就擋掉這種時程相對較短的開發案呢?

理想狀況下,如果每個案子都能夠有相對高的毛利時,這麼思考當然可行的,但是,實務上除非開發流程能夠像工廠般的流水線來進行,才有可能完全沒有時間壓縮的狀況出現。

縱使每個人的分工都很明確,也會因為專案需求使得原本的分工有所變動,這也是為什麼專案開發,本身成本較高的主因,為了滿足各種需求及使用行為,在前期與業主進行需求確認時,PM仍得要適度提醒過於特別的要求,要衍生對等的代價。(不過這又常會回歸,最初這個專案的目的為何,而有所差異)

如果真得在文件尚未備齊下進行開發時?

這時候就得回到最根本的人力特質,就會決定開發的進展及狀況,如同先前提到,縱使在只有一份跟業主確認過的規格書,一般而言,會是PM理解業主的需求後,進行功能的規格撰寫,有些特別的狀況下,會由資深開發人員撰寫,不過那會比較類似SA文件。

若是開發人員本身理解能力夠,只需PM與開發人員進行初步的解說,資深且有經驗的開發人員就能藉此抓到此專案的相關需求,就算未得到完整的技術文件,亦能進行必要的內部分工,進行底層架構的規劃及開發,如此一來,待後續UI/X所提供的素材到位,開發人員就能夠著手進行前、後端的串接,可以有效的降低開發時程。

從這一點也可看出,若是無專職的SA時,通常都是PM或資深開發人員兼任或共同擬定相關規範,畢竟SA對於規格書的解讀,若與實際需求落差過大,浪費的時間可能還不是功能做錯這麼簡單,很有可能得要花三倍的時間來補救。

雖然說分工明確是組織管理上必經的流程,但是,許多開發人員基於分工及效率的訴求,已習慣"只"看技術文件,縱使已完成既有架構的建置之後,也不見得會想要多理解規格書內相關功能的因果關係。

這時候若因SA的疏忽,提供了有落差的文件,開發人員也很真實的呈現其內容,最後開發出來的功能,是有可能與規格需求上有邏輯的牴觸,這部分卻可能得要等到功能做完,進入產品驗證或測試時,才會驚覺怎落差如此之大,這也是為什麼會說,在無專職SA前,往往都是PM及資深開發人員共同兼任這個角色的主因。

但是,以實務上來說,除非這個專案夠大,團隊中有多名PM,不然往往一個PM經常手上都有二、三件以上的專案在進行,光是應付業主的各種需求及釐清相關功能,就會忙於奔命。

相較於處理人的問題,若是這個PM具備對應的技術能力,能夠與資深開發人員共同擬定SA文件的規範,PM可能會更加願意,但是,絕大多數,最後可能還是由資深的開發人員主導SA文件居多。

況且,相信每個當過PM的人都會知道,要負責的工作真的包山包海,有更多時候,識人以及必要的管理能力,需要比一般主管來得更為複雜,因為PM往往要整合是不同領域跟背景的人,所以不太能以一種思維來管理全局。

在事務繁瑣之外,也相當花費心力,若是公司文化對於PM職掌給予對等的尊重及權責,PM或許會更容易掌控專案的走向及品質,不然就會覺得自己很像專業打雜,這也是會成為許多技術人員不太願意當PM的主因之一。

除此之外,其實現在也有各種敏捷開發法,可以達成一樣的結果,但是,許多方法論的前提,都是建立在人力資源及技術能力均在一定水平時,才能發揮它的最大效益吧?

不然很有可能會走更多冤枉路,況且,以人力培育或資源的風險控管來看待它時,優化原有熟悉的流程,比貿然採取什麼敏捷開發法會更為實際。

永遠保持學習的欲望及彈性

看到這理,我應該不用再特別說明為什麼PM沒有SOP能夠遵循,就算是同一種類型產品的PM,只要在不同公司或部門,都有可能得要重新接受實際流程上有所不同。

況且專案管理本身,很有可能需要在很短的時間內,理解業主的商業流程或開發上的需求,甚至在討論時也得將專案本身導向雙贏的局面,這也是為什麼PM經常得要跨領域涉獵不同內容的主因。

若想把既有流程原封不動的套用其它場域,除非你是老板或建立制度的人,基本上PM就是要能夠隨時在各種變動中進行風險評估及調適工作心態的職業,所以,你是一個想要在工作內容上有所挑戰,而且自覺對於與人溝通有一把刷子的人,或許能夠來嘗試看看PM的工作內容,相信我,你一定會有很不同的體驗。

沒有留言:

張貼留言