PM心得談 (上)
Preface
按照實驗室的傳統，碩一都得承接計畫或產學案。在今年五月，這份大獎終於落到自己身上。但和以往不同的是，技術工作轉由專題生執行，其他研究生則是輔助開發，自己則是擔任 PM 的職位。
雖說在大學專題時，就擔任過組長的職位，但對比帶領一個多人團隊，且需要向合作公司負責，就更為正式許多。對我來說，這是難得能成長的機會之一，便開始努力學習其中的眉角！
Team
團隊成員：4 位專題生、3 位研究生、1 位博士生
工作崗位：爬蟲、前端、後端和 PM
專案內容：無法細述太多（已簽 NDA）
開案至今已過一半的時間，雖然這類工作的經驗，難以透過文字三言兩語表達，但還是盡可能地分享出來供各位參考。
Schedule
在專案中，最基本的工作便是訂定「開發進度表」，針對每一工項評估開發時長，並提供給客戶瀏覽，透過進度表，各單位都能即時掌握開發狀況，客戶也方便預約交付項目與日期，格式如下：
對各崗位需負責的工項，按照數字條列式安排，再附上開始、結束時間、進度數值、進度條和整體進度條，這樣就能一覽大家的工作狀態。
在進度規劃上，理想上是都希望能on track，但還是有延宕的情況，因為產學案的組員都是學生，能開發的時間少之又少，若碰上期中期末考，進度掛蛋只是家常便飯，於是在日常開發上，進度就會跟催比較緊，稍微壓榨一下（?）。如果某崗位進度已經落後一周以上，就會彈性安排人員配置，並協助調度需要的資源，以避免進度差距不斷擴大。
Issue tracking
在開發上，多少會遇到技術或非技術上的困難，如：需求再確定、功能與版面呈現等。為了讓雙方能同步掌握問題，便建立了問題追蹤表單，根據交付區塊或頁面來新增子工作表，此時雙方就能在指定的表中描述問題，其中包含：編號、項目、問題說明、示意圖、提出人員、提出時間、處理狀況。
使用問題追蹤表單有三大好處：
- 減少雙方的溝通成本
- 避免因工作量大而疏於記錄
- 日後驗收若有疑問，能根據表單內容來佐證說明
可謂是一兼「三」顧，摸蜊仔兼洗褲！
Meeting minutes
在每周的固定時間，會舉行Sync Meeting，由各崗位報告進度、開發問題和未來進度，這時便能最清楚地掌握大家的開發狀況。在會議結束後，我會製作「會議紀錄」與「進度投影片」，一方面是讓開發人員確認工作內容，另一方面是提供給客戶檢閱。
會議紀錄就不多加贅述，在進度投影片中，除了圖文並茂的描述，我會另外加上 Git commit，客戶能根據投影片的 Git commit，來追蹤 Github 的內容。（前提是要加入協作 XD）
Acceptance testing
當專案開發一定的進度後，就得交付給客戶驗收，所以交付前的黎明，總是特別的漫長。雖說不用進行開發工作，但為了確保交付時的順暢，我會先進行內部驗收，包含功能操作、畫面顯示和開發文件等。
關於驗收用環境，我們使用 Google Cloud Platform (GCP) 來架設網站，在驗收前，會先將前後端資源整合在一起，再透過後端將內容 Push 上去。
在原先的其他方案，曾考慮「影片拍攝」，但驗收效率過差，且無法實際操作，難以進行效能測試（回應速度、壓力測試等）。我們也同樣考慮過 AWS 的 EC2，但因為需要額外花費來購買資源，然而，GCP 有提供一定的免費額度，待用罄後才會再收費，對我們來說是更為實惠的方案。
Opinion
上面的內容，僅是簡單描述進行專案的形式，接著分享目前對這份工作的心得。
以專案的技術問題來說，多數都是有資源且可被解決的（Google, Stack Overflow…）。所以這一次，我將重心放在學習如何與團隊、客戶和教授三方進行溝通與協調，如：
- 技巧性延長驗收時間（替團隊爭取開發時間）
- 釐清客戶需求可行性（避免出現無效需求）
- 協助客戶與教授瞭解專案全貌（減少溝通成本）
原先以為，脫離技術工作後，只需要專注於處理文書報告即可，但後來發現，不可能完全忽略技術…，因為在進度報告中，若掌握度不足，很難快速瞭解開發人員所講的內容。如此一來，可能會錯估專案的完成度，或是理解錯誤，導致專案延宕（若遇到會閃事情的 RD，可能會唬爛 PM 做不到，再把需求原封不動推回來）。
雖說 PM 不需瞭解所有的技術細節，但至少在功能可行性上，要有一定程度的掌握，不然推動專案時，勢必會遇到困難。面對客戶多如繁星的需求變動時，PM 也需要站穩底線，不能客戶丟什麼就吃什麼，要能辨別需求的緩急輕重和可行性，否則只會徒增開發團隊的負擔。
對於開發團隊，除了基本的工作調度和溝通之外，自己花了許多心思培養合作關係（革命情感）和凝聚向心力，讓團隊成員心甘情願為專案付出，而不只是「得過且過」的心態，當心態正確了，就能鼓勵成員追求更好的系統品質，在面對客戶時，驗收及交付上自然就能順暢許多。
在專案管理上，偶爾會碰上阻礙與爭執，PM 在工作本質上，就很容易成為夾心餅的角色，就像是基層主管一般，上有長官下有部屬，兩者間的利害關係與矛盾，更是難以平衡，要處理得面面俱到著實困難。
在很多時候，我會利用空閒時間與成員聊天，釋出善意並說明原委，即便對方不一定能全盤理解，但至少能軟化雙方因工作本質不同所產生的對立。
但是，與開發成員的關係，也應當保持適當距離，若是關係甚密，也許會讓開發成員的態度變得輕浮、散漫。在建立權威和培養關係的過程，得拿捏適當的「距離感」來平衡兩者間的關係，才能讓專案建立在穩固的合作基礎上持續前進。
對我來說，目前最大的心得：
專案最難的不是技術，而是「人」。
帶人不難，帶「心」才難。
