黑先生

PM（專案經理）沒有好壞之分，但專案管理的方法有好壞區別。畢竟不會有人一開始就以把事情搞砸為目標，拿石頭砸自己的腳，喜歡讓自己痛苦的是吧！ 那為何PM有時會被抱怨的要死? 明明就很努力做了大量溝通，需求書內容也寫不少，但就是不得工程人員的心呢？ 答案很明白，只是我們PM自己沒看懂，然後拼命地流血流汗地做那些無效的努力，尤其是夾在中間，需求來自於上隔兩層，不是自己能掌控說變就變說翻就翻，滿滿無助又無奈感，大概是PM這職務的普遍現象。 依據自己過往工程歷練和接觸過許多工程師的經驗，工程倒也不是要求PM給出一個百分百不會變動的需求，反而更多在意的是：執行著連自己都困惑的任務，以及身處令人感到混亂不安的流程之中。 關於任務，試試這樣解決： -需求承接時，習慣進一步詢問任務目的與優先順序 -現實中，需求可能得不到明確的目的和為什麼要做(因為市場本身就是個模糊不定的狀態)，這時PM不妨在理解產品上下鏈的關係後，大膽假設驗證。這絕對會比一句“不知道不清楚”更能讓工程師接受 -需求描述中，以“使用者故事”的方式來揣摩描述任務，可以讓PM和工程師有機會抓到一開始忽略的事 -PM在開案發案表達時，要給團隊的感受是“我們的事”，而非“你的事” 關於流程，不妨試試這樣建立： -透明團隊所有資訊與狀態。當別人不知道你在做什麼，就會以為你沒在做什麽，然後拼命讓你什麼都做 -釐清與盤點團隊目前與未來要執行的任務目標。方向錯誤的任務，再怎麼努力拼命，也得不到正確的結果 -了解你的利害關係人。及早認清誰是可以把不確定點頭做確定的人，否則你做的努力，可能都是一場空 -熟悉產品規格。很基本但是最重要，即使是小小需求，也可能因為產品功能的連動，而需要許多相關部門的協調合作 -需求的流動與專案的流程，不外乎就是在團隊、目標、利害關係人、產品這四個地方轉換呈現 那麼，一位PM剛加入到流程混亂度高的新團隊，第一步會是什麼呢? 最好不要直接套用你過去在其他公司的專案流程，每間公司的文化和每個團隊的體質不盡相同，對你有用的解藥，到了別人身體很可能會起嚴重的過敏反應。 前一陣子我是這樣做， 不急著改流程，第一步是觀察理解團隊成員和產品業務後， 試著建立在團隊原習慣上做出小改變，讓夥伴能自然而然地透明自己的資訊。 將原本每週對上匯報的工作進度習慣，轉換成團隊的即時任務板，成員只要有更新自己的任務資訊，就會自動彙整成原本...