軟體團隊的崩壞與求生筆記 (中)

在找出有意願合作的對象團隊後，雙方真正投入合作時，軟體開發團隊也會面臨到不少挑戰。就我的經驗裡這些挑戰有：

1. 不清楚自己想要什麼：

對方可能在初期並不清楚自己真正需要什麼；作為軟體的開發者，難免會聽到需求提出者說做出來的不是他想要的，讓人感到挫折。經歷幾次後，我認為不能夠就直接認為對方沒有誠意要合作；需求提出者就像想要裝潢房子的屋主，在沒有完工前，鮮少屋主能肯定按自己主導的設計圖完工後就真的是自己想要的，屋主的想法也可能會隨著施工的過程而有所改變，這都不表示屋主沒誠意要裝潢；我想人本來就是這樣，這很常見，尤其對於不夠了解的事物，雙方更需要深入討論與互相體諒。

2. 擠牙膏式的提出需求：

對方的需求一次都只提供一點點，當需求能被滿足後，才再提供一點點，這種作法有時被戲稱為「擠牙膏」。推測原因有可能是對方還不夠信任軟體團隊，也可能是對方負責談規格的人並不能掌握自己團隊的全部需求等等的原因都有可能。較可怕的是，如果軟體團隊要滿足的需求是要從構思計算機演算法開始，只要增加或改變一個條件，通常就要重新構思算法，這很快就會消磨完軟體團隊的熱情。

3. 需求是個無底洞：

對方的需求可能非常龐大，是需要投入超出預期的大量資源。

4. 完成後未使用：

有時候，即便軟體開發完成，再三催四請，對方仍沒有要使用，這對團隊成員而言是相當令人憤慨的。這種情況有很多種可能性，可能是因為對方已經不需要，例如這件事每年只需要做一次，而今年度的已經完成；或者是對方的業務內容發生了變化也說不定。

5. 政治關係影響合作：

在開發過程中，由於公司內部政治因素，可能需要停止合作。就我的認知，這通常是組織結構有了變動所導致的；所以也可以說，平時偶爾觀察對方或己方組織結構是否有調整，都是有助於提前發現這樣的情況。

6. 高估自身能力：

有時軟體團隊可能高估自身能力，最終無法提供預期的服務；例如團隊可能以某論文技術為立足點，根據論文的實驗結果，預估可以有加速的效果，但實際做出來並沒有這個效果，甚至實作不出來。

在面對這些挑戰時，我只有一個建議，那就是要在初期討論階段，依據開發的規模大小設定幾個階段性目標。除非開發規模很小，否則不要期望一次到位。每當完成一個階段目標後，就請需求提出者進行試用，這樣可以確保開發朝著預期的方向進行。除此之外，倘若在後期開發被迫中止，也不會缺乏成果可以用來呈現給上級管理層。

當合作的對團隊大幅增加時，開發需求就會不斷地湧現，那怎麼樣取得工作與生活平衡，又成為是一個新的挑戰。

起初的我真的是來一件事就做一件，很快地就忙不過來。每次我老闆問我狀況，我都是告訴他我事情很多，我很忙。印象最深刻的是有一次在我寫程式的時候，我隱約聽到辦公區自動門開啟的聲音。我恰巧好奇地站起身來，遠遠地看到老闆與一位我們軟體的使用者一同走進門，他們一邊對話著一邊朝著我的右前方方向走來。我猜想他們必然在談論新的功能設計，要來找我提出新的開發需求。我真的撐不住了，當下我立刻轉身往左邊的方向走，再迅速地從我座位左前方的另一個自動門離開辦公區。

後來當我回到座位時，只看到我老闆一人。他劈頭就問我剛才怎麼突然走掉了。既然被發現，我索性理直氣壯地回答說：「事情都做不完了，那當然就逃了啊！」現在回想，我可能就像古時候的某些守城將領，發現敵軍逼近，人數又過多時，就會選擇立刻棄城逃走。

在這段忙碌的時期裡，我老闆其實並不是沒有作為，相反地，他陸陸續續地教了我四個做事的方法。當我掌握了這四個方法後，令人意外的是，我的工作日常竟然又開始有了些許餘裕：

1. 不要做完一件事就立刻呈報：

處理不同需求的時間不可能相同，必然有長有短。若習慣每次做完一項任務就馬上呈報，可能會面臨沒有成果可報告的情況。舉例來說，若每週一次的會議週期中，你恰好遇到一項需要花超過一週時間處理的任務，下次開會時就可能沒有成果可以報告。這時工作壓力會上升，又為了要產生出成果來報告，可能會迫使自己要加班，影響身體健康。因此，在處理可以快速完成的任務時，應適度保留一些成果，而非一次性全部報告。

2. 盡可能要量化抽象的事物：

每當我描述處理某件事需要花費很多時間時，我的老闆總是反射性地問我：「那究竟是需要幾天、幾週、還是幾個月呢？」久而久之，我也漸漸習慣了這樣的問題，甚至開始以相似的方式向別人提問。量化抽象的事物是非常重要的，我感覺到以量化的方式進行說明能夠更有助於對方深入了解情況，或者做出更準確的判斷。

舉例來說，如果我們說某人在校成績很好，這聽起來相當抽象；但如果我們說他是全班第一名，就會更清楚地了解他的優秀程度。同樣地，當客戶委託我們分析資料，檔案的每一行都是一筆完整的資料，如果客戶只是聲稱給我們的檔案會很大，這就有點抽象。畢竟，對於數量級的不同，我們在開發上可能會選擇不同的方法，因此我們就可以追問：「那大概是幾千行、幾萬行，還是幾百萬行呢？」這種量化的手段有助於引導客戶描述地更具體，進而提供給我們更精確的資訊。

3. 確保需求清晰記錄：

記得在某次我抱怨很忙的時候，老闆以平和的口氣建議我使用Excel來詳細記錄每個問題的細節，包括提問者、提問日期、開發需求概述、需求的使用目的等等，像這樣的細節。他坦白地說他無法只是向上級報告我們很忙，透過這樣的資料記錄，他能清楚向上級解釋我們的工作內容，他也會更了解我的狀況，看看能否提供我協助。

記錄需求對我產生了巨大的影響。隨著我不斷記錄需求，並標註已完成的工作任務，我逐漸感受到一股成就感湧現，居然開始期待有新的需求進來；即使數年後的現在，我仍然記得在一次大型簡報中呈現的兩張圖。第一張圖是以時間為橫軸，需求數量為縱軸的折線圖，我報告說，現在平均每週我能解決1.4個需求，但每週卻有1.7個新需求進入，顯現出我是有在做事的。第二張圖則是一張圓餅圖，清楚標示每位使用者提出的需求數對於總需求數的占比。當我看著圓餅圖指出哪幾位同事是我們現在最大宗的需求提出者，台下傳來一陣笑聲，夾雜著一句：「你提太多了啦！」

不過需要提醒的是，像我呈現的圓餅圖未必是恰當的。我之所以使用這種方式，是因為我知道這些人提出的需求都是針對使用者友善的修改，不是必要的，又數量實在太多到有點超過，我才以這方式暗示這些提出需求的同事要有所節制。另外，除了Excel之外，市面上還有免費且專業的軟體可用來記錄需求，如Redmine；但如果要導入這種需求記錄習慣到整個團隊中，我個人仍建議先以Excel開始，因為門檻較低，內部成員的阻力也較小。只是務必要記得要為每個需求建立唯一的編號，這樣未來討論需求時才會更方便識別在講哪一個需求。

4. 優先處理較多使用者提出的需求：

老闆建議我優先處理比較多使用者提出的需求，原因是同時有越多人提出的需求，通常表示這個需求是越重要的；而另一個角度來看，透過滿足這樣的需求，有助於有效地減少那些可能會催促進度的需求提出者人數，進而降低心理壓力。

透過這四個方法，可以減緩大量需求帶來的壓力，同時也使需求的處理更加有條理。然而，這並不代表我們一定能夠滿足所有需求，因為時間終究是有限的。如何在眾多需求中取捨，是一項相當大的挑戰。即便是上述提到的第四個方法，也只是個參考。三個使用者的需求必然比一個使用者的需求重要嗎？對於「重要性」的定義也是個令人困擾，對你而言某需求重要，是否對我也同樣重要呢？

接下來，我將提供一種以能見度為基準的方法作為參考。雖然這種方法對某些人（包括我在內）可能會引起一些異議，但在實際執行了兩年多之後，我開始理解取捨可能就是這樣一種過程。