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

1.關注需求 vs 關注任務

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

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

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

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

2. 流動效率 vs 資源效率

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

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

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

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

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

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

3. 關注問題 vs 關注活動

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

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

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

圖片

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