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

在前一篇 軟體團隊的崩壞與求生筆記 (中) 提到，在面對大量湧現的需求時，建議在記錄清楚需求後，優先處理較多使用者提出的需求。然而，這一建議在實際應用中仍存在一些模糊的空間，例如當每個需求僅由單一人提出時，或是多個人的需求是否真的比較重要等問題。我後來加入了另一個軟體團隊，其以能見度為導向，擁有較明確的規範處理順序。他們優先處理事宜的順序如下：

1. 程式錯誤：不論是自行發現或使用者提出，只要可能影響結果的正確性，都需優先處理。畢竟若使用者基於錯誤的資料進行後續作業，可能帶來難以預測的後果。
2. 新客戶的需求：為提高能見度，新客戶的需求被視為優先滿足的對象。若新客戶提出的需求很多時，則要盡量說服客戶設定階段性目標，即里程碑。當開發到滿足到客戶的需求低標的階段時，就讓客戶開始試用，確保開發方向正確，並確認客戶是確實有意願要使用的。隨著客戶需求逐漸滿足，其餘需求就漸漸地不再屬於「新客戶的需求」了。
3. 多個團隊共同提出的需求：多個團隊提出的需求通常表示其重要性，處理這些需求能有效減少總需求數量。
4. 必要的需求：需求可以為必要的需求與非必要的需求。這種判斷基於需求的目的，是否注重強調使用者友善的操作。如果需求的目的是提升使用者體驗，則為非必要的需求；反之，則為必要的需求。要先處理必要的需求，以確保基本功能的正常運作。
5. 非必要的需求：在實務上，除非是由新客戶或多個團隊提出的需求，否則這類功能的開發機會相對較低，通常不會被處理到。

這樣的處理順序考量了不同層面的重要性和實際需求，以確保團隊在應對各類需求時能夠有條不紊、有效率地進行。不過順序並非是不能違反的，老闆給了我三個要納入考慮的影響因子：

• 公開場合的感謝度：如果需求提出者常在公開場合表達對軟體團隊的感謝，這將有助於提升軟體團隊的能見度。因此，這樣的需求可能值得優先滿足。
• 頻率估算：可以向需求提出者詢問，完成後預估功能的使用頻率。對於使用頻率高的需求，可能需要優先處理，以確保對使用者的實際需求進行有效滿足。
• 信用度：考慮需求提出者的信用度，即對方是否真的使用新開發的功能，以及功能的使用頻率是否符合當初的陳述。信用度低的提出者就不需要過度關注其需求。

在實行這樣的處理規範時，有些舊有的合作對象難免會產生不滿，曾經有人當面向我抱怨說：「我們就像進了你們家開的餐廳吃飯，可是餐廳在漏水你們不處理，上菜也越上越慢！」我很清楚，若非有這些舊有的合作對象，我們或許難以走到現在這裡，更沒辦法吸引到新的客戶。然而，我無法輕易地違反這樣的規範，在面對相處比較融洽的合作對象時，我會說實話，當面告訴對方這是我們求生存的手段，若我們因能見度不足而倒下，對他們也是有害的。

實際上，我會盡量讓每個合作對象的需求都有機會能被處理，同時也會參考平時與對方的交情，大家互相幫助；這時我可能會對老闆說這需求是我過往開發時沒處理好的，或是我自己造成的程式錯誤，即便事實並不是這樣的也沒關係；有時候我也會在檯面下悄悄完成某些需求。

一次深刻的經驗是，有使用者希望我們加快網頁的顯示速度，我想這對商業軟體至關重要，不過對於我們內部軟體並非迫切的。老闆也明確告知我這是非必要的需求，不需要處理；但是我發現我們已擱置那位使用者太多的需求，我仍私下進行修改，結果被老闆發現，我就尷尬的和老闆說這是我出於自我滿足而做的。老闆只說了「對」這一個字後就頭也不回地離開了。確實，做這樣的事還是有風險的。

最後，我想分享一個老闆提到的思考方式。老闆認為，當每個需求浮現時，最理想的情況不是自己處理，而是思考是否有辦法讓對方自行協助處理。舉一個例子來說，如果對方頻繁要求軟體團隊新增或更新某些規則進入程式中，或許可以考慮為其建立一個獨立的空間，使其能夠自行上傳規則，進行新增或更新。若是需要進行程式撰寫的，或許可以讓對方按照我們訂定的標準撰寫程式，再將其程式傳到在我們指定的空間，以便我們自動採用。這樣的方法既能滿足對方需求，又能減輕我們軟體團隊的工作負擔。

總結來說，在公司裡經營一個軟體團隊充滿著許多挑戰，這裡分享的是我所觀察到的和所學習到的，不見得是對的，或許也沒有所謂的對與錯，就供參考囉。