軟體研發的這些誤區，你中了嗎？

你可曾想過軟體研發過程中如何讓工作變得更簡單有效率？

1.關注需求vs 關注任務

在辦公室，常見的景像是每個人都在處理多項任務，忙得不可開交，卻頻頻延誤交付。事務性工作本質上是任務驅動，專注於基本的開發任務，但這些任務片段化，缺乏整體的產品需求和目標。儘管個體完成了許多任務，但缺乏與其他任務在需求層面的銜接，導致產品交付不及時。這就像倉鼠在滾輪上奔跑，始終原地踏步。

軟體交付的核心是持續、快速且高品質地提供有效價值，而有效價值源自於使用者需求和業務目標。需求可以從業務目標、場景和功能需求等不同角度進行分解，保持其獨立性與可測性。每個需求交付都是驗證假設、創造業務價值的機會。

因此，在軟體交付中，透過精實交付看板可視化需求流動，才能實現價值驅動；只有從整體視角出發，才能在協作中實現不同職能的聯通。關注用戶問題的提出和解決，就是要強調“結果優於產出”，即在最小化產出的同時最大化結果。

老闆更關注的是交付的特性需求，而非完成的任務數量，因此，協作應以需求為單位，更重視業務價值，並透過視覺化手段呈現交付過程。

2. 流動效率vs 資源效率

資源效率是指將人視為資源，關注個人效能，創造局部忙碌的狀態。然而，局部資源效率的提升並不能提高整體效率，這是因為產品交付的完整流程需要各職能之間的協同，包括業務、產品、開發、測試和維運等。

關注資源效率的兩大原因在於：

• 軟體交付受到短板的影響。
• 每個職能的局部效率優化容易形成「效率豎井」。局部看來效率很高，產出了許多中間製品，但這些豎井之間的交接形成批量，整體效能並未改善。

以流動效率為核心，意味著將需求作為流動單元，從用戶需求出發，快速流向用戶，加速需求的上市時間（Time to market）。流動效率的快慢直接影響使用者回應和回饋的效率。

要以流動效率為核心，必須拉通交付流程中的所有職能，打破組織壁壘。同時，聚焦流動效率可以幫助組織及時發現協作中的問題，如阻塞和等待等，這些問題可能是協作問題，也可能是工程能力問題。

軟體研發過程中的主要問題往往不是資源的閒置，而是需求的閒置。因此，關鍵在於：資源效率著重個人人效和人力利用率，而忙碌的局部資源效率並不能在整體上提升流動效率。

3. 關注問題vs 關注活動

殭屍式站會是指那些只複製方法論框架、追求形式主義的會議。在這種情況下，人們常常陷入「是站著開還是坐著？會議分上午和下午，還是集中在下午？」等細節中，忽略了真正的問題。這種本末倒置的做法違背了方法論的初衷，即促進交流和理解，而非生搬硬套。

在軟體專案協作中，關鍵在於解決問題和移除阻塞，專注於需求如何快速流動。從專案協作的角度，應關注以下幾點：目前存在哪些阻塞、哪些需求到期卻無法交付、交付的價值流中是否存在中斷，以及當前交付過程中的瓶頸是什麼。這樣的關注才能真正提升協作效率。

我們推薦的「6+1」站會模式，旨在引導團隊專注於協作中的問題。 「6」代表六個關鍵要素：瓶頸和隊列、關鍵缺陷、重點關注的需求、阻礙和問題、到期或即將到期的需求，以及中斷。 「1」則指未在看板上反映的問題。透過這種方式，可以更有效地識別和解決協作中的挑戰。

不建議複製哪個方法論的框架，方法論框架的目的是為了溝通理解的需要，而不是生搬硬套，照本宣科。