【PM學習誌03】在完成一件專案以後 （上）— 關於溝通這件事
不知不覺也在時賦待了4個月多，手上忙碌的專案剛好進到了尾聲，所以終於可以空出時間寫 medium （現在連打開 medium 都覺得很生疏 XD 有夠汗顏）總之！以下會分享我這 4 個月以來在專案內學習到的、關於專案內值得學習與思考的部分。
前情提要
開始之前，先介紹一下我參與的專案：簡單來說這是一個店家管理系統，PM 需要負責：(1) 跟客戶確認需求、(2) 撰寫需求文件、(3) 繪製系統流程圖、跟工程師過需求、(4) 反覆測試工程師寫出來的系統和 app、(5) 到最後的 demo 與正式上架。
這個專案對我來說最大的學習點在於：它包含了店家使用的後台系統和消費者（也就是店家的顧客）使用的 app，所以在前期設計上，我需要思考在不同介面上流程的不同（比方說，網頁內的搜尋功能和 app 中的搜尋功能雖然具有一樣的目的，但在介面設計上完全是天差地別）；在開發階段，因為需要和設計師、前端工程師、後端工程師確認需求，「怎麼有效的串接每個人的工作環節」就顯得非常重要；到了後期測試，完成某一個動作常常需要操作多台裝置 ，所以需要規劃出一整套流暢、能完整覆蓋所有情境的測試流程。
以下將會挑出我覺得重要的學習點和大家一一分享！
文章會分三個部分來講述我在專案中的學習。今天讓我們先談談「溝通」的重要性。
01 溝通啊，您怎麼能這麼重要
只能說，雖然我們一定都認同「溝通是最最最重要的 soft skill」、「要有效率的溝通」這句話，真正落實在專案裡仍然挑戰性十足，在這次專案裡，我就親身體驗了一輪怎麼清楚描述問題，以及如何靠溝通保持所有人的工作彈性這兩件事。
[怎麼清楚地描述一個問題？]
對於PM來說，可以快速解決「問題」是非常重要的技能，而這就相當仰賴PM如何和工程師溝通。記得我一開始很擔心如果自己很直接指出問題或提出要求會不會「不太有禮貌」，所以常常用很委婉但不明確的方式表達問題。但其實，對於工程師而言，如果一個 PM 對於自己的敘述都不太肯定，他們在開發上會更加無所適從，會認為：你是不是也還沒想清楚就要我改 code 啊？顯而易見地，在開發上，這其實會大大增加溝通成本（需要小心試探兼來回確認對方是不是那個意思），所以一個明確的問題敘述是相當重要的！
在時賦，我們通常都是用 Clickup 這個軟體來管理專案（相關文章請參考我們同事寫的文章：），Clickup 上有個重要的功能是「開卡片」，在每一個專案的卡片們大致可以分成「問題釐清」、「待處理」、「處理中」、「已完成」幾個狀態，可以想像「卡片 ＝ 問題清單」。通常，我們會把一個問題開成一張卡片，用拖曳的方式檢視這張卡片完成的進度。
而一個好的問題描述，具體的一些指標包括了：
a. 用圖片/影片輔助文字：開卡片時，文字是我們主要的溝通媒介，但有時光有文字是不夠的。比方說，一個畫面有bug，你除了描述那個bug是什麼以外，截一張圖 — 甚至錄下你操作的流程 — 對工程師們來講都會是更有效的溝通模式（眼見為憑嘛XD）。
b. 具體描寫問題的輪廓：在描述問題的時候，「定義問題」也是一個重要的輔助因素。「你是在什麼情況下需要某項功能？」、「或者在什麼情況下認定目前的操作有bug？」這個描述對一個新手PM更為重要。我自己在這項專案裡就有很深刻的體會：當時，我遇到其中一個問題是「結帳時會重複扣款」，所以我和工程師說「請幫我在按下扣款的時候加入一顆確認鍵，使用者按下確認後才進行扣款，並且在按完確認後就離開頁面，避免重複按到的問題」。嗯，這樣應該有解決到問題了吧？但工程師立刻打電話過來，和我確認：「如果你是想要不重複扣款，我其實可以在原本的扣款鍵上加入按一次就block住的功能就好。或者你想要加這個確認按鍵是基於什麼其他的需求嗎？」
其實會提出「加入確認鍵」這個解方，是基於整個系統的其他部分都是在「確認」過後才執行動作，當時只有結帳例外，所以為了追求更完整的一致性，我才會想說「喔好，反正就通通改成按下 [確認] 再執行動作吧」，但我在和工程師溝通時，只說了「我想要解決重複扣款」這個問題，而忽略「我希望可以達成系統一致性」這個訴求，這也會讓工程師困惑：「那其實有更快的方法B誒，為什麼不用這個呢？」由此可知，把問題定義清楚、完整表達問題輪廓是一件多麼重要的事！
c. 把測試步驟和預期結果寫清楚，條列呈現給工程師：每列出一個問題，工程師會期待你告訴他：這個問題是從哪裡來的？你是點了 A 再點 B 之後才有問題，還是只要點 B 就會有問題呢？清楚的步驟有助於工程師解決問題，像是：1. 點[A按鍵] 2. 點[B勾選框] 3. 按下[確認]，讓他們在修改程式的過程中有步驟可依循，確保修改後的 code 有解決到你的問題；PM自己在隨後的測試也才能follow自己羅列的錯誤步驟進行測試。
[如何靠溝通保持工作彈性？]
溝通還可達到一個重要目的，那就是讓整個團隊保持工作彈性。在這個專案裡，我深有感觸是對於Clickup的管理卡片方式。一開始我們整個工作團隊約定好：一個功能一張卡片、之後如果有問題（bug）會記錄在卡片裡的comment欄，示意圖大概長得像下面這樣：
後來，主管姊姊和工程師跟我說：「我們能不能換種方式？如果有新的問題，可以開一張新的卡片來記錄，就不要留在comment裡面了，不然同一個功能底下的問題，每次都要點進去一張卡片以後滑好久才找得到。」我才意識到：原來管理工具的使用方式不當，也會造成整個專案進度的延宕，因為會讓雙方寶貴的時間都花費在尋找問題在哪裡，而不是解決問題本身。在更換方式以後，雙方溝通起來就順暢許多，整個專案管理也有「在前進」的感覺，這是我在專案中第一個學到憑藉溝通保持團隊彈性的例子。方法不是訂死的，而是可以隨時靠提出問題與需求來改進的！
因此，我覺得PM有個很重要的點是：隨時關注工程師在你的專案管理下適應得如何，會不會花太多時間在不必要的事情上（例如尋找卡片）或者會不會有哪個環節可以更有效率？隨時保持這樣的溝通，才可以不斷迭代團隊合作的方式，也才能隨時讓團隊在快速的狀態上運作。
以上是我覺得在這個專案內學到的、跟溝通有關的兩件事！在最後也分享我的同事 Joanne 在她上一個專案結束時對「溝通」這件事情的想法 XD
