Blog 86 — 身為一個PM 新手，我可以如何快速上手工作(下)

專案管理的領域太廣太深，要用一篇文章說明白相當困難，因此這篇文章主要提供我在新創公司擔任「產品+ 專案」PM 職位時的經驗，主要有三個重點技能：. GetunlimitedaccessOpeninappHomeNotificationsListsStoriesWritePublishedin生活實驗室Blog86—身為一個PM新手，我可以如何快速上手工作(下)，專案經理技能篇前言在前兩篇文章我提到了一個新手PM在剛進入公司時，主要會碰到的“兩個困難點”以及“可嘗試的解決方案”，並以梁寧《產品思維30講》課程中提到的知識體系為基礎，提供PM新手可以持續學習與精進的方向。

可參考下方兩篇文章：Blog80—身為一個PM新手，我可以如何快速上手工作(上)？一、每個職位都有個起點chuhenry.medium.comBlog81—身為一個PM新手，我可以如何快速上手工作(中)，產品經理技能篇前言medium.com在台灣的軟體新創公司有一個有趣現象，那就是把「產品+專案」的工作都放在PM這個職位上，實際上他們需要的專業能力是不一樣的。

產品經理的能力著重在產品功能發想，關鍵在「透過產品來解決目標使用者的問題」。

專案經理的能力著重在時程安排與交付項目，關鍵在「利害關係人在意的時程點內交付成果」。

產品開發中有一個經典的例子是這樣的：使用者買鑽孔機，但是他的目標不是擁有鑽孔機，而是需要在牆上打個洞。

PhotobyMattAntoniolionUnsplash如果比較兩者的差異：產品經理的職責是解決「使用者想在牆上打個洞」的問題專案經理的職責是「在產品經理規劃好解決方案後，跟產品經理詳細核對解決方案的規格、安排資源、在特定時程點完成解決方案」。

這也是為什麼許多人會說「時程」是專案經理最需要掌握的事情，因為做一切的任務都需要明確的時程，沒有截止期限的工作等同於永遠不會完成，這個道理在日常生活中也處處可以發現。

專案管理的領域太廣太深，要用一篇文章說明白相當困難，因此這篇文章主要提供我在新創公司擔任「產品+專案」PM職位時的經驗，主要有三個重點技能：拆解問題整理資訊有效溝通一、專案管理的基礎工作—拆解問題1.先從生活經驗切入思考讓我們撇開工作上的專案管理，先來思考生活中的情境：最近你奮發向上，突然想要在網路上買一堂「UI設計入門：畫出有程式邏輯的設計稿」線上課程，請問你會如何安排自己的學習計畫？許多人的直覺行動是：「就直接買下課程，下班後抽點時間出來上課吧！…等等，下班後太累了還要運動跟追劇，那就安排週末來上課吧。

」真實狀況是，這堂課買下後最多只會開啟1~2次看看教些什麼，然後…就沒有然後了。

為什麼會發生這樣的事情呢？我想主要是：課程的內容多、時間長，上完一堂課程需要花費很久的時間。

當一件事情愈複雜時，我們愈難想像需要花費的時間。

要解決此問題，我們必須把課程進行拆解。

例如一堂5小時的課程假設有24個章節，可以先看每個章節播放時間多長，評估自己一周有多少時間上課，將課程章節安排到週間學習。

2.工作中的拆解任務工作中的專案其實也是一樣的。

一個大型專案可以拆解成數個大功能，每個大功能可以拆解成子功能，每個子功能又可以拆解成不同的任務(task)，在專案管理中這樣的動作叫做「Workbreakdown」。

將大功能拆成若干小功能，PhotobyAlvaroReyesonUnsplash這邊要特別提醒的是，實務工作中「拆解問題」不會有想像中這麼容易。

線上課程的進度安排可以由我們自己決定，但動輒數十人、百人的專案，想必同時有多個利益關係人互相干擾（跟專案的結果成敗有關係的人，通常是老闆或是外部客戶），拆解問題的難度會倍增。

那該怎麼辦呢？這時候專案經理的第二項能力就派上用場了。

二、專案管理的關鍵工作–整理資訊1.專案資訊來自四面八方在實際的工作場合中，資訊隨時會從四面八方進入到PM的耳中。

例如：後端工程師：這個功能因為前端工程師Delay，所以這個功能的估計時間需要延長行銷人員：請問專案是否可以提早1~2週讓我們做大規模行銷前的準備？老闆：這個專案客戶臨時有多加入需求，要記得納入整體時程中…這麼多、這麼雜的資訊都會影響到專案的進行，尤其當專案中的任務彼此有相依性時(dependency)，牽一髮則動全身。

那麼身為PM的我們該怎麼辦？2.從一張表格開始，和團隊約定將資訊存放的地方市面上有非常多的專案管理工具、非常多的專案管理方法，這些功能看起來酷炫、視覺化，一定可以幫助團隊進行良好的專案管理吧？其實酷炫的專案管理工具不等於「輕鬆的專案管理」，也不等於「保證有好結果的專案管理」。

我在實務上的經驗是：公司要導入一套功能多元但複雜的管理工具，需要耗費的時間往往是事前難以估計的。

因為其中包含專案管理者的學習、流程規則制定、團隊成員內部教育、團隊磨合、特殊狀況處理，這些摩擦都可能讓一套工具流於形式，進而拖慢大家的工作效率。

以上的現象在新創公司尤其明顯，因為新創公司的工作節奏是非常快速的，今天得到的資訊有可能在明天被更改，過多的專案流程與複雜工具操作有時候反而拖慢效率，造成團隊的整體產出是走下坡的。

我們需要回歸專案管理的本質—資訊整理。

工具只能作為輔助，真正重要的還是管理專案的人能持續的蒐集、歸納、傳遞資訊。

要做到這三件事情，其實只要有一張表格就夠了，我們要做的僅是將資訊彙整到這張表格中。

專案文件，將資訊統整在表格中整理資訊的關鍵在於：和團隊確認好專案文件存放的地方。

可以是GoogleDoc,GoogleSheet,Confluence,Coda,Notion…等，團隊成員必須以某個地方的文件資訊當作討論基礎，一有新資訊就必須更新在約定的地方。

最常見的問題是：團隊成員喜歡各自將資訊紀錄在不同地方，例如PM將資訊紀錄Confluence、工程師紀錄在開源的伺服器上、設計師放在個人的Notion…這其實是一個非常不好的現象，因為大家的資訊永遠都是不對稱的。

身為PM的我們可以先從自身做起，接下來再告訴其他人隨手將資訊紀錄在大家約定的地方。

很多時候大家不是不願意配合，而是這件事情沒有被提醒過。

那麼我們該怎麼提醒呢？這就要提到最後一個重要技能—「有效溝通」。

三、專案管理最常被提及的工作—有效溝通「溝通」是專案經理這個職位最常被提及到的工作，要跟老闆溝通、要跟團隊溝通、要跟客戶溝通、要跟所有跟專案有關的利益關係人溝通。

雖然溝通很重要，但我認為前提是做好此篇文章提到的前兩件事情—拆解問題、整理資訊，在弄清楚事情的來龍去脈後，溝通才變得有意義。

PM的工作就是不斷地溝通，PhotobyJoshuaNessonUnsplash那應該如何溝通才會有效率呢？溝通的本質就是在傳遞訊息，探討訊息傳遞本質的學科叫做「資訊理論(中國稱之為信息論)」，其中著名的就是克勞德·艾爾伍德·夏農(ClaudeElwoodShannon，也有人稱為香農)提出的「資訊熵」、「夏農第一／第二定律」。

這篇文章不會深入探討資訊理論，但其中的原理可以給我們日常溝通指引一些方向。

以「夏農第二定律」為例，夏農告訴我們「訊息傳輸率≦訊息通道容量(頻寬)」，也就是當我們想傳遞的訊息非常多時，如果訊息通道很窄，唯一的解決方式就是延長傳輸時間(或叫做降低傳輸率)。

套用到我們的生活/工作中，可以有如下的啟示：主管與下屬：對於訊息通道容量小的人，一次只說一件簡單的事情，尤其時主管在對下屬交辦任務時;對於訊息通道容量大的人，只要確認對方都有聽懂了，一次交辦多點事情也沒關係。

老師與學生：如果一個老師每講一件事，學生就理解了，表示彼此的訊息通道很寬，這時老師怎麼講都行。

如果老師有知識但不會教學，或者學生的理解力很弱，代表彼此通信的通道容量太低。

這時候，唯一能夠讓教學取得一些成果的方式，就是老師講慢點，確定學生聽懂了，再往下講。

男女朋友：做男女朋友，兩情相悅就好，但若要結婚，最好三觀要一致。

用資訊理論來看，三觀一致代表雙方的溝通通道的容量很大，先生說一件事情，太太一下就理解了。

反之如果三觀不一致，溝通通道容量小等於沒法溝通。

四、總結最後為大家整理這篇文章提到的重點。

拆解問題：專案規劃的第一步，將大問題拆成小問題。

整理資訊：將資訊統整在團隊約定存放的地方，這是溝通討論的基礎。

有效溝通：留意對方的理解能力，如果能力水準一般或偏差，那麼一次最好只交辦一件事情。

是朱騏，一個渴求新知、熱愛學習的產品經理。

也是一個喜歡研究各種生產力工具、熱愛將專案管理知識應用在魔術學習上的魔術愛好者。

如果有任何疑問、想聽的主題，歡迎留言給我📒你會看到這篇文章是因為我在進行365天寫作挑戰，詳情可參考《365天寫作挑戰第二季，關於寫作的新想法》。

如果想給我一點鼓勵，請給我1–10個拍手；如果覺得文章對你有幫助，請給我10–40個拍手；如果你覺得文章寫的不錯，請給我40+個拍手讓我知道👏🏻如果有任何想閱讀的主題請留言分享給我。

最後，謝謝你的閱讀！喜歡我的文章，可以點擊下方「Follow」我～|LinkedIn@ChiChu歡迎交流--Morefrom生活實驗室分享關於生活中新鮮事物的學習心得Readmorefrom生活實驗室AboutHelpTermsPrivacyGettheMediumappGetstarted朱騏2.9KFollowersSoftwareTechnicalwriter@OwlTing奧丁丁集團，我專注寫(1)SaaS軟體產品規劃(2)個人知識管理(3)線上寫作的文章。

擁有6+年的SaaS產品經理工作經驗，☕️歡迎講座邀約、諮詢或跟我喝杯咖啡聊聊天，我的信箱是muhenry608@gmail.comFollowMorefromMediumMartainCleevioHowtheSoftwareProductDevelopmentProcessWorks:ACompleteGuideUriValevskiEffectiveprocessdesignPhoenix-on-a-missionIdiscoveredtheDiscoverydocumentorhowtoformanideausingDiscoveryintheSoftware…BenjaminHansBeingaROI-DrivenSoftwareCompanyHelpStatusWritersBlogCareersPrivacyTermsAboutKnowable