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

1.關(guān)注需求 vs 關(guān)注任務(wù)

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

軟件交付的核心是持續(xù)、快速且高質(zhì)量地提供有效價值，而有效價值源于用戶需求和業(yè)務(wù)目標(biāo)。需求可以從業(yè)務(wù)目標(biāo)、場景和功能需求等不同角度進(jìn)行分解，保持其獨立性與可測性。每個需求交付都是驗證假設(shè)、創(chuàng)造業(yè)務(wù)價值的機(jī)會。

因此，在軟件交付中，通過精益交付看板可視化需求流動，才能實現(xiàn)價值驅(qū)動；唯有從整體視角出發(fā)，才能在協(xié)作中實現(xiàn)不同職能的聯(lián)通。關(guān)注用戶問題的提出和解決，就是要強(qiáng)調(diào)“結(jié)果優(yōu)于產(chǎn)出”，即在最小化產(chǎn)出的同時最大化結(jié)果。

老板更關(guān)注的是交付的特性需求，而非完成的任務(wù)數(shù)量，因此，協(xié)作應(yīng)以需求為單位，更重視業(yè)務(wù)價值，并通過可視化手段呈現(xiàn)交付過程。

2. 流動效率 vs 資源效率

資源效率是指將人視為資源，關(guān)注個人效能，創(chuàng)造局部繁忙的狀態(tài)。然而，局部資源效率的提升并不能提高整體效率，這是因為產(chǎn)品交付的全過程需要各職能之間的協(xié)同，包括業(yè)務(wù)、產(chǎn)品、開發(fā)、測試和運維等。

關(guān)注資源效率的兩大原因在于：

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

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

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

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

3. 關(guān)注問題 vs 關(guān)注活動

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

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

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

圖片

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