其實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的工作內容，相信我，你一定會有很不同的體驗。
沒有留言:
張貼留言