《我的專案筆記 #31》六步驟，讓你在維護專案活下來 – 數位產品功能這麼多，要怎樣安排時程？(2/4) — HeroMi

在上一篇《如何進行專案時程規劃？》中，我們有聊到，當我們加入一個軟體的開發專案時，可能會有下列三種情況：
1. 維護舊產品
2. 開發新產品
3. 研發新技術

理想上，我會希望我可以先待在一個「正在開發中的新產品」，然後這個產品，有應用到目前最流行的「主題」，數年前是區塊鏈、或者是VR/AR，而現在就是「ChatGPT」或「AI」。然後這個團隊有一位資深的前輩，可以手把手的教我，跟我說整個系統架構、軟體開發會遇到的狀況。緊接著，完整經歷產品上線的過程，接下來學習產品營運，遇到的各種奇妙狀況，並解決他。

當有了完整的產品開發週期體驗後，安排去主導一個全新的專案，題材有趣、新穎，幻想著上線後取得巨大成就，成為知名的製作人、大PM或產品總監，從此過著幸福快樂的生活。

要發生這種狀況，可能上輩子累積了很多的福報...。

實際狀況應該會是這樣，

你加入了一個專案，而這個專案似乎需要常常加班，加班的理由常常都是有著許多「緊急插件」，也因為如此，導致工作量很多很雜，所以增加了一些缺額，希望可以降低加班的情況。往往加入新人後，加班的狀況並沒有改善。

過了一陣子你會發現，為什麼某位資深的員工突然消失了？原因當然有很多，而你也會意識到，自己好像是來「抓交替」的。但是，你好像不能就這樣離開，因為走了這個專案似乎就掛在自己的手上，基於一個「勇於承擔和負責任的心」，說甚麼也要抓下一個交替後再走...。不是，是讓他有個好結果後再離開。

而這通常會發生在哪一種專案？沒錯，就是「維護舊產品」的專案上。

因為，「開發新產品」和「研發新技術」的開發節奏，始終是慢慢的，不管這個世界運轉的速度多快，只要產品還沒上線，就不會有立即感受的壓力，也就不容易產生各種「緊急插件」，所以只要是軟體開發的同仁，很少不喜歡「開發新產品」和「研發新技術」的。然後，一旦產品上線維運後，就都會想急著下車...，修正，是挑戰下一個專案。

不過，這邊有一個矛盾又有趣的現象。

事實上，產品上線維運後，團隊需要更多有經驗的人才，不管是PM或是工程師，才有足夠的經驗應對緊急狀況。但是，公司還是需要開發其他產品，於是A產品上線後，很多時候都會把A產品的開發工程師，或是負責的PM，調去協助新產品B，反正工程師和PM都還在嘛，有事再問就好了。

於是，後續接手的團隊，就這樣開始了A產品的維護。

正當一切都還在美好的想像時，維護中的A產品開始受到一些駭客攻擊，或是來自老闆和客戶的需求需要處理，後續接手的團隊，在無法掌握整個系統架構或資料流程的狀況下，要處理這些問題，就會耗費更多的時間。接著，老闆或客戶就會開始執意，為什麼處理時間這麼慢？為什麼需要這麼久的時間？

就這樣，內部開始各種檢討會議，討論著要如何改善？客戶的需求要如何滿足？還有，各種的抱怨與不滿。

往往會得到一個答案，那就是「系統掌握度不夠」，接手的團隊對於原本的系統架構，常常是不清楚的，而且產品功能也不一定有人可以全盤掌握。追問下去後，也常常會發現兩個因素「交接不足」和「缺少文件」。

「交接不足」和「缺少文件」往往是一體兩面的。

在傳統的開發思維《瀑布式開發》下，多半有「詳盡的文件」後才開工，但是要先弄出「詳盡的文件」，可能需要花上大半年的時間在寫文件，這段時間又不能讓開發團隊閒置，於是邊開發邊寫文件。

※註：這邊的文件指的是產品的需求文件或是規格文件。

《衍生閱讀：搞懂規格書，讓你的團隊再也不用通靈》

那工程師的技術相關文件呢？不好意思，我普遍知道的工程師，都是不善於寫文件的。加上工程師寫程式都已經會花上許多時間，要讓工程師寫文件，那真的會要他們的命。如果專案過程中，把開發時間也納入工程師寫文件的時間，那可能會花上兩倍的時間...。

於是，《敏捷式開發》的出現，似乎讓工程師有了一個救贖，從此就可以不用寫文件了。但是，這是一個美麗的誤解，雖然《敏捷式開發》強調的是「可用的軟體重於詳盡的文件」，但是不代表就不用寫文件，而是寫「剛剛好的文件」，那什麼是「剛剛好的文件」呢？這就跟看食譜一樣，每次都寫「鹽少許」，什麼是「少許」？於是又多了很多的想像...。

總之，有各種原因，導致「剛剛好的文件」，始終難以產生。

當初始成員逐漸離開團隊，系統掌握度就從100%變80%，80%變60%...。
接著，回過頭來檢討，就又覺得「交接不足」。
但是，原始團隊成員都在其他專案，或已經離開公司，也無法接交。
最後，矛頭就指向「缺少文件」。

團隊就必須面臨「處理上線遇到的緊急狀況」、「開發老闆或客戶新需求」。
然後，還要補上「缺少的文件」，避免團隊每經歷一次調動，就失血一次...。
很不幸的，大多數我們加入的專案，往往都是這種狀況。

那身為一個涉世未深的小小PM，我們該怎麼辦？
看到這種狀況，是不是都有種衝動，重新去開履歷了...。

坦白說，就算換到下一個團隊，狀況其實也是差不多，不如留下來好好觀察這個團隊到底發生什麼事。

■ 好好活下來第一步 - 專心聽，並謹言慎行

其實這一步蠻簡單的，就是「專心聽，並謹言慎行」。
但是要做到，不容易。

這是什麼意思？

因為身為一個PM，多半的時候都在「需求端」和「技術端」的中間，於是需求一直來，技術一直抱怨，越是混亂的團隊，需求越多，技術壓力越大，當然衝突也就越高。

在這種狀況下，

需求來，就好好地記錄下來，忍著，不要為了滿足需求方，就一直轉發需求單給技術。
當技術反映，也好好的記錄下來，依然忍著，不要拿著技術的回饋，直接拒絕需求方。

「忍」與「耐」，在這個階段是很重要的心理素質。

■ 好好活下來第二步 - 專心聽，拆解技術端抗拒的原因

還記得有一次，客戶希望在後台裡面，有一個頁面可以顯示用戶的「全部」資訊。
當時的需求會議裡，技術也有參與，當技術聽到這個需求時，臉色瞬間就沉重了起來。
然後表示說：「要顯示全部的資訊的話，到時候後台畫面會開不起來，會當掉喔。」
當然，客戶也就直接反應：「為什麼做不到？」
此時，技術就說：「因為!@#$%^&()(*^%*...所以做不到阿。」
客戶就更糊塗了，因為根本聽不懂技術在說什麼...。

會發生這個原因，通常都是需求端以為自己的「需求很簡單」，然後技術端以為自己的「說明很清楚」。

然後，
討論前，雙方都覺得「你應該聽得懂」，
討論後，雙方都覺得「你好難溝通喔」。

這個時候，提供一個工具，可以讓雙方快速對焦，方便說明執行的困難點，這個工具就是「循序圖」，又稱「時序圖」。

《衍生閱讀：搞懂系統功能流程，讓循序圖幫幫你》

個人很喜歡用「循序圖」來思考一個系統的流程，也可以請技術用「循序圖」來說明「困難點在哪裡？」只有先找出困難點，才有機會進一步地解決問題。

以上述提的例子「有一個頁面可以顯示用戶的全部資訊」。
困難點就是在「顯示全部資訊」，其實這個需求看起來很清楚，實際上是很模糊的。

所謂的「全部資訊」是指哪些？
是用戶創建帳號以來的全部資料嗎？
登入紀錄也要嗎？
如果是經營10年以上的大平台，那10年以前的資料也需要嗎？

如果要滿足客戶的需求，那技術就是要把全部的資料通通拉取出來，然後進行整理，才能顯示在畫面上。很常聽到的說法就是：「要顯示全部的資訊的話，到時候畫面會開不起來，會當掉喔。」

透過一個「嚴重的後果」，來讓客戶放棄。
有效，但是粗暴。

這時候要做的，其實是「拆解」技術上的難點，好好地跟客戶說明。

■ 好好活下來第三步 - 專心聽，挖掘需求端背後的真相

最近因為ChatGPT很紅，導致大家開始覺得「AI」萬能，於是開始各種天馬行空的想像。當然如果出得起錢，也願意投入時間，這個想像也許就不是想像，可惜，客戶常常給不起時間，也沒有足夠的預算。

前陣子有聽到一個需求，客戶希望可以拍一張照片，透過繪圖AI，可以生成各種不同角度的照片，這樣就可以大幅縮減拍攝、取材的時間，也不用之後還要去補拍。

舉例來說，就是拍了一張「滷肉飯」的照片，然後透過AI，生成各種不同角度的「滷肉飯」的照片。看起來好像不是太困難，難就難在「滷肉飯」只要一旋轉，飯粒、滷肉、醃蘿蔔的角度、位置、透視都會跟著改變。要實現，投入的成本可能不低。需要進一步確認的，是這樣需求背後的「目的」？

原來，客戶希望的是要做到「量產影片」，所以需要大量類似的素材，不希望都用同一張照片，於是希望透過AI來協助產生大量的素材。那如果目的是「量產」的話，也許透過各種濾鏡、特效、素材，或是剪接方式，都可以達到類似的結果。

回到上一段提到的「顯示全部資訊」這個項目。

這邊分享兩個我最常用的兩句話：

1.請問你是遇到怎樣的問題，需要被解決，可否讓我們了解？
2.請問這個需求是想要達成怎樣的結果，可否讓我們知道？

通常問了這兩句話後，客戶才會開始去思考他遇到的困難，有些時候可能「工作流程改善」，就可以解決。

回到上一段提到的「顯示全部資訊」，這件事情上。

後來從客戶那邊了解後，其實是當他們發現可疑的用戶時，希望可以快速的查詢這位用戶的過往資訊，來初步判斷是正常用戶，還是「可疑用戶」，例如登入、儲值、各種操作...等，方便進行是否能進行「封鎖」的判斷。

也就是說，其實客戶的需求主要是針對「資訊安全」提出的需求，這樣的話，未必要提供一個「全部資訊的頁面」，反而重點是在各種操作的監控。

例如：
1. 從非經常性登入區域的IP進行登入
2. 連續輸入錯誤的帳密資訊達5次
3. 非平常習慣登入的時間
4. 連續儲值失敗次數達3次

於是這個頁面要顯示的資訊就可能如下所列：
1. 基本資訊 (帳號、暱稱、最近一次登入時間及IP…等)
2. 登入/登出紀錄 (時間、IP、裝置...等)
3. 儲值紀錄 (訂單編號、儲值時間、金額、IP、裝置...等)

其中顯示的資料也未必要全部，需要的是「有效資料」，也就是說顯示足以判斷的資料量即可，可能是7日、也可能是15日，甚至是30日的資料，再多，就未必是有效資料了。

如此一來，技術也不會因為要顯示過多的資料，而拚死反抗。

■ 好好活下來第四步 - 建立「需求追蹤表」，並定期追蹤

其實我們都知道「需求」需要被追蹤，但是，常常是「需求來自四面八方」，有老闆的、有大客戶的、有臨時被駭客攻擊的，我們要怎麼安排這些需求？

最常被拿來用的工具就是「時間四象限」，如下圖(A)：
將事情分成四種組合「重要且緊急」、「重要但不緊急」、「不重要卻緊急」、「不重要且不緊急」。

確實，我自己在安排工作時，是很經常透過這樣的概念在安排。
只是這邊有一個地方要理解，如果這項工作是「自己可以全權決定的」，那使用這個概念安排工作是沒問題的。但是，如果這項工作是「要大家決定的」，那就不一定了。

因為我覺得的「重要」，你可能覺得「不重要」，而我覺得「不緊急」的，你卻覺得「緊急」。於是，團隊如果沒有對「重要」、「不重要」、「緊急」、「不緊急」，有一個判斷的基準的話，這個工具的效果就會大打折扣，甚至會變成爭執的來源。

而我個人更喜歡用圖(B)的概念去思考，我自己命名為「價值四象限」，畢竟產品會被誕生出來，就是要取得「商業價值」，講白話就是「要賺錢」，怎樣的需求優先度是高的？當然是「做了會賺錢、不做會賠錢」，所以優先順序如下(建議)：

1. 做了會賺錢、不做會賠錢
2. 做了不會賺錢、不做會賠錢
3. 做了會賺錢、不做不會賠錢
4. 做了不會賺錢、不做不會賠錢

當然，用「賺錢」和「賠錢」來思考，只是一種例子，目的是要界定出「什麼是重要？什麼是緊急？」

我們也可以用「老闆生氣程度」當X軸，「需求方講話分量程度」當Y軸，目的就是要找出「重要和緊急的標準」，並讓團隊有一個「共識」或「基準」。

注意，工具是死的，團隊是活的。

另外，這邊提供一個「需求追蹤表」的範本，如下表：

■ 好好活下來第五步 - 不是什麼需求都要寫到「需求追蹤表」，你還需要「事件處理紀錄表」

當我們知道要「追蹤需求」後，往往會發生一個令人困惑的點，那就是「PM要追蹤全部的需求嗎？」

因為在「維護舊產品」的專案上，需求的來源大多數都是「客戶」。而通常接收需求端的最前端，不一定是PM，反而是和客戶有較密切關係的「客服」，或要經營客戶關係的「商務」，如下圖。

要填入「需求追蹤表」的，大多是無法當下處理的需求，可能是「新功能」、「數據分析」，還有「修BUG」，當然也是有些嚴重的BUG是需要當下立即解決，不是所有的BUG都可以放個好幾天才處理。

另外，有一些需求，則是必須當下處理的，因為客戶的需求是24HR的，一款維運中的產品，也需要考量24小時的人力，但是，在這種狀況下，PM並無法24小時協助處理，於是有些「事件」就必須授權讓客服及維運工程師處理。例如：突然無法登入、畫面打不開、查無資料、畫面突然跑版...等。

而這些需求則會被填入一份叫做「事件處理紀錄表」中。一方面可以管理事件處理的效率，另一方面更重要的，是要來分析「都是哪種類型的事件」，經常性發生的問題，就需要提出改善計畫，安排後續的優化。

例如：如果無法登入的次數太過於高，需要專案討論發生的原因，是因為流程有問題，還是系統有問題？分析完之後，安排在後續的版本進行處理。而這種就是屬於「做了不會賺錢，但是不做會賠錢」的類型。

■ 好好活下來第六步 - 盡可能地了解你的產品

通常我們加入一個新的團隊，對於當下的產品，肯定是不熟悉的，前台有哪些功能、後台有哪些功能，掌握度也不會太高，突然有一個客戶，希望說可以在A頁面的B功能，擴充C選項，這個時候如實轉達這樣的需求，但是你連A頁面長怎樣都不知道，請問該怎麼辦？

當你理解A頁面的B功能後，想要擴充C選項，於是你問了甲工程師，甲工程師說他是前端工程師，這個要乙後端工程師負責，於是你去問了乙後端工程師後，乙後端工程師回說，這個要去找丙資料庫管理師(DBA)處理。

後來你找到了丙，結果丙跟你說他只負責執行，所以要擴充什麼東西需要有人告訴他。好吧，到這邊你可能心想，「煩死了，怎麼這麼麻煩，都推來推去的。」

於是請客服再次和客戶確認，想要擴充的C選項的具體內容。再次和丙討論，也確認好要擴充的項目。再次跟乙後端工程師確認，乙後端工程師也說沒問題。緊接著，和甲前端工程師確認後，也說沒問題。

到了驗收的那一天，突然發現出問題...。

什麼問題呢？擴充的C選項，不支援多國語言，也就是切換成英文時，還是顯示中文。
於是，被客戶退件，請問你該怎麼辦？更重要的是，下次該怎麼辦？

其實很多時候是這樣，我們接手別人的產品，對於產品的結構、系統架構、資料流程、資料結構都很不清楚，這時候又有很多需求和BUG一直迎面而來，又有時程壓力，如果沒有軟體架構的概念，真的會很想死。

而「軟體架構的概念」，也不是看一本書，隔天就能應用，需要的是思維的轉換，更要換成工程師的思維，我們卻常常不知道要轉換，反倒是覺得工程師的思維很奇怪...。

在這個階段，建議盡可能的「研究產品」並嘗試畫出「系統架構圖」，畫系統架構圖並不是專屬於技術的工作，反而是了解一個產品結構最快的方式，在接觸一款產品時，我第一時間會執行的，都是畫出「系統架構圖」，透過畫系統架構圖的過程，讓自己了解整個系統，和技術討論才不會雞同鴨講。

《衍生閱讀：搞懂系統架構，讓你知道工程師在說什麼!!》

■ 結論

其實在「維護舊產品」的專案上，最麻煩的就是「需求」、「修BUG」和「緊急事件」同時來。剛加入這種專案的年輕PM，最常的困擾就是「沒有方法」面對這樣的狀況，搞得壓力爆棚，只能找同為PM的朋友，一起取暖。

站在老闆立場，總是希望產品穩定、滿足客戶、盡快交件，這樣才能有穩定的收益。在談擴大客群之前，先求的應該是穩定。不過現在大家心裡想的，應該是「老闆就是又要馬兒好，又要馬兒不吃草」，老闆就是想要「需求」、「修BUG」和「緊急事件」都可以瞬間搞定。

但是我們能做的，就是盡可能在「需求」、「修BUG」和「緊急事件」持續湧來的狀況下，透過上面提到的六招方法，好好的排出你的「優先順序」，讓老闆知道「需求持續在解決」，盡而讓老闆心安。只要老闆心安，很多問題就都不是問題。

某天我們從長輩那邊接手一台15年的二手老爺車，請問你接手的時候是希望「可以跑很快，但是常維修」，還是「可以穩穩開，不要常維修」，哪一種？重點應該會先放在「維修」，對吧？總是希望開出去兜風的時候，不會突然卡在路邊。你什麼時候覺得這輛二手老爺車可以讓你安心，那老闆期待的，就是這個專案什麼時候可以讓他安心。

—

大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。

如果有任何想法，歡迎留言或發信給我，希望可以幫到你
我的信箱：[email protected]
我的LINE OA：@hero-mi
歡迎加入粉絲團：數位產品開發教練 – 陳俊聖/廣三/HeroMi

*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。