PM 與 PG - HackMD

--- lang: zh-tw title: 'PM 與 PG' tags: '看' --- PM 與 PG === 軟體需求 --- - 客戶想要(利用程式)解決得問題與滿足的需求。 - 客戶想要(利用程式)達到得目標或目的。 公司 vs 軟體需求 --- - 針對客戶所提出得真實需求 ➜ 轉成滿足需求的應用程式，順利收到錢。 ➜ 提供滿足需求的解決方案，順利收到錢。 PM ( **P**roject **M**anager )( 專案經理 ) --- :::success :::spoiler **善用溝通、討論、協調、管理、技術(有加分、有好處)能力，管控專案如期、如質的完成，順利收到錢，而且讓大多數參與者感覺是一次不錯的合作。** ==定義過程== ➜ 管控專案在時程內完成。 ➜ 管控專案在時程內完成，順利收到錢。 ➜ 管控專案如期、如質的完成，順利收到錢。 ➜ 運用溝通、討論、協調、管理、技術能力，管控專案如期、如質的完成，順利收到錢。 ::: - **大多數時間是要<code class="red">主動積極</code>處理人與人之間的連結問題，讓專案的參與者，可以認真負責、守本分且互助的把案子如期、如質完成**。 - 其中「人」對外是客戶或合作廠商，通常是承辦人員、相關單位人員與長官、終端使用者...等，對內是公司內部的分析師、設計師、工程師、主管...等 - 而「連結」指的是 : 與專案人員<code class="red">**進行溝通、討論、協調、達成資訊共識與同步。**</code> - **記得要聰明作事、腦袋要清晰、邏輯要強、要有耐心，而且在執行時很吃個人的 <code class="red">態度、語氣、表達方式</code>**<div class="newline2"></div> - **對客戶主要是接收合理的工作，擋不合理的工作** - **合理** ➜ 主要是指合約內的工作項，或經由雙方開會決議，且雙方認可，在時程內可完成的工作項 - **不合理，有能力作，屬於大幅度變動或需長時間才可完成的** ➜ 給錢，放到下一期作或分期作 - **不合理，有能力作，屬於小幅度變動且短時間內可完成的** ➜ 基本上為了有良好的關係都會答應，但有時候也會需要看人、看狀況給，這種狀況可證明我們有能力、以及對案子的重視，不過也要適時適度得強調其影響程度與所付出的人力時間成本 - **不合理，但真得擋不住、被凹了** ➜ 面對現實吧...那就只能作，不過一定要適時適度得強調其影響程度與所付出的人力時間成本 - **目前沒能力作或不同領域** ➜ 評估後如果想吃下來，就安排人去學來作，如果不想就放手 <div class="newline2"></div> - **對專案的參與者，要讓大家知道為何而戰? 目前戰況如何? 下一步為何?** - 讓大家知道專案需求內容(工作範圍)、方向與目標、時程與查核點(查核時間與項目) - 讓大家知道我們是要做什麼東西? 要做到什麼程度? 什麼時候要完成? 工作項目負責人是誰? 目前的進度如何? 下一步要做什麼? 這樣，大家才會有明確的目標、才會作的安心、才會有向心力 --- - <code class="red">**千萬^x3^不要只是客戶的傳話筒而已。**</code> :fire: :fire:<div class="newline"></div> - **每次交付規格時，不可以太晚給，一定要作到下列三項重點 :** - <code class="red">**1 開發時間要給足夠(最重要)**</code> - **開發是需要時間的，工作千萬不要擠到最後一刻才碰出來，然後要在短時間內完成 :fire: :fire: :fire: :fire: :fire:** - <code class="red">**2 規格要開明確**</code> - **明確規格指的是規格內容必須開得正確、清楚與足夠:fire::fire::fire:** - **規格書要維持同一份，當規格有異動時請回修同一份規格書，不要有多份規格書或只用口頭說明沒回修**:fire::fire: - <code class="red">**3 功能要定優先順序與預計完成日**</code> - **主要是有助於開發進度管控，避免事情都擠到後面做:fire::fire:**<div class="newline2"></div> - **專案執行過程中要主動積極與成員進行溝通、討論與協調，要適時的去了解、關心執行進度與狀況，並在有反映問題時給予適當的協助** - **專案執行過程中對於所討論的事情（即使是有經驗的事），最後還是有產生不確定或有疑慮的地方，要進行釐清與確認的動作，尤其是需要跟第三方(例如客戶)才可確認的事，那就跟對方連絡並進行釐清與確認吧！不要存在過多的自我猜測與自我認為，如不去釐清與確認要把原因說出來，讓相關人員知道，不然大家會產生不必要的困惑或誤解，例如 : 「啊～去確認一下是很難嗎？」、「確認一下比較好吧？」、「不確認，會不會雙方認知不一樣，我們又作白工？」** - **不要常常認為 : 這個東西應該很簡單吧！** :fire: - 可透過「PM 主動了解 PG 開發狀況」+「PG 主動跟 PM 說明功能難易度」來減少此錯誤得認知 PG ( **P**ro**g**rammer )( 程式設計師 ) --- :::success **將明確的規格 ➜ 變成可正確執行的應用程式 ➜ 變成可正確執行<code class="red">且有一定品質</code>的應用程式** ::: - **千萬^x3^不要真得只會寫程式，也要會與其他人類(PM、PG、客戶、使用者...)互動，也就是進行溝通、討論與合作。**<div class="newline"></div> - <code class="red">**規格如有不清楚、疑問或錯誤的地方，一定要說出來進行釐清與確認，不要在明知有問題的狀況下進行開發**</code> :fire: :fire: :fire:<div class="newline"></div> - <code class="red">**專案執行中要適時主動的回饋進度與問題給 PM，讓 PM 了解你的進度並給你適當的協助**</code> - <code class="red">**千萬^x3^不要認為收集/挖掘客戶的真實需求是很容易的**</code> :fire:<div class="newline"></div> - 提供技術相關的協助，尤其是需求訪談與開規格(含定工項管制表)期間的溝通與討論<div class="newline"></div> - 協助技術文件的撰寫<div class="newline"></div> - 工作會議如有需要協助，要去參與 :handshake: 需求規格 PM 與 PG 要達到共識與同步，減少落差、誤解 --- - **PM 對 PG ➜ 規格說明一定要「文件」+「面對面進行口頭說明與溝通」** - 如果只給文件都不說明，一定會因爲想法與經驗不同而產生解讀不同的認知落差與誤解<div class="newline2"></div> - **PM ➜ 一定想清楚、說明白** - **這個很重要，因為<code class="red">PG 是依 PM 所提供的資訊開始想與往下發想</code>，所以 PM 如果說得不清不楚、不正確或不完整，那就 GG 了，因為一定會產生認知落差、誤解(沒共識)，可怕的是...這個落差、誤解如果一直沒被填平與解開，只會越來越大，最後一定一定會產生 <code class="red">**要 A 給 B**</code> ~的結果** ，最後就是整個開發錯誤，導致 PG 又要重新開發，浪費大家的時間<div class="newline2"></div> - **PM ➜ 有異動一定要同步更新** - 讓規格資訊保持最新且一致性，避免開發錯誤，導致 PG 又要重新開發，浪費大家的時間<div class="newline2"></div> - **PG ➜ 也要問清楚搞懂來** - <code class="red">**聽完 PM 的規格說明，~~最好~~一定要當場就進行釐清跟確認，給它搞懂來**</code> - 如果真得有些當下沒想到，會後只要有想到任何疑問，就要趕快跟 PM 進行釐清跟確認，給它搞懂來 - 還有在開發前一定要再次回想並確認自己是否還記得與懂得 PM 所開的規格，一有任何疑問，就要趕快跟 PM 進行釐清跟確認，給它搞懂來 - <code class="red">**聽完 PM 的規格說明後，可以將自己理解得說一次給 PM 聽，進行再次確認，減少認知落差、誤解，達成共識**</code> :dart: PM 與 PG 合作的責任與期望 --- 實務上 PM 與 PG 在專案的合作過程中，<code class="red">**++雙方都有持續互動，進行溝通、討論與協調得責任++**</code>，以達到以下期望 : - **PM 要讓 PG 願意跟你合作** * 已知工作要考慮開發時間並早點規劃與交付，不要擠到最才後才一次交付給 PG ，然後要 PG 在短時間內完成 :fire::fire::fire: * PM 與 PG 在合作期間，<code class="red">**雙方一定要有互動^X3^，而且 PM 一定要比 PG 更主動積極的互動**</code>，在執行過程中一定要**適時或定時**得去了解執行狀況，**並主動了解或詢問是否有需要溝通與協助的地方**，不然時間久了會產生 **「PM 都不在乎這個案子，那我幹嘛在乎」、「這個案子是不是沒有 PM」、「要底誰才是 PM」**...等感覺，千萬不要等時間快到了 PM 才出現，然後再來說要如何如何...:fire::fire::fire: * 交出來的規格要開明確，更要**主動**確認 PG 有清楚且了解所開得規格 * 專案過程中的來回變動或難處，PM 要**主動**讓 PG 了解難處，PG 大多情況下是能諒解也願意幫助的，而不是突然交付一個任務，也不說明做這件事到底是要幹嘛? 為什麼要作這個? 就一個莫明奇妙...<div class="newline2"></div> - **PG 要讓 PM 想要找你合作** * PG 與 PM 在合作期間，<code class="red">**雙方一定要有互動^X3^**</code>，例如 : 規格開得不明確要跟 PM 說、有問題需要搞懂要跟 PM 說、有需要溝通與協助的地方要跟 PM 說 * 該有得規格、溝通與協助都有後，就要表現出高配合度 * 能讓 PM 掌握 PG 目前的進度，且幾乎都能如期完成 * 當問題發生，都有解決方案，給予 PM 信心 :link: 參考 --- [科技業常見的職務縮寫](https://mropengate.blogspot.com/2015/05/sa-sd-rd-pg-pm-dba-mis-qa-sales.html) <style> code.red { color: #e91e63 !important; font-size: 1.6rem !important; /*background-color:#FFFFBB !important;*/ } code.blackred{ color:#900000 !important; font-size: 1.6rem !important; } code.blue { color: #337AB7 !important; font-size: 1.6rem !important; } code.orange { color: #F7A004 !important; font-size: 1.6rem !important; } font.red{ color: #bd0000 !important; } font.orange{ color: #F7A004 !important; } font.pm{ color: #bd0000 !important; } font.pg{ color: #006700 !important; } .newline{ height:1rem; } .newline15{ height:1.5rem; } .newline2{ height:2rem; } </style>