偉大的工程團隊專注於里程碑而不是專案 - Jade Rubick

banq發表於2021-12-17

大多數工程組織都專注於交付專案。他們應該專注於里程碑。
管理專案很困難。公司會為了做好這件事而扭曲自己。與其下棋，不如改用跳棋。里程碑是一個更簡單的遊戲，你會得到更好的結果。
在這篇文章中，我描述了：
  1. 我建議您採用一種特殊的里程碑。
  2. 為什麼人類很討厭專案。
  3. 為什麼我們實際上非常擅長里程碑。
  4. 基於里程碑的交付使一切變得更好的無數種方式。
  5. 如何切換到基於里程碑的交付。

里程碑應該如何定義？
我使用了一個特殊版本的里程碑，並建議你也這樣做。這些里程碑具有以下屬性：
  1. 小。里程碑是一到三週的工作，而不是更多。一個或多個里程碑形成一個專案。
  2. 高品質。每次完成里程碑時，都要讓事情比開始時更好。程式碼庫和使用者體驗不應降低。一個例外是如果您正在製作一次性原型。這可以保留您隨時間交付價值的能力。完成里程碑後，它應該可以以某種方式釋出。您可以選擇不將其釋出給所有客戶，但應該以某種定義的方式完成。
  3. 可以理解。選擇傳達您正在交付的價值的里程碑名稱。公司中的任何非工程師都應該瞭解里程碑的作用。我喜歡使用“[價值交付]透過[方法]”。這會與工程和其他業務進行交流。例如：“透過實施 ElasticSearch 加快列表頁面上的搜尋結果”。商界人士瞭解價值部分。工程團隊將從方法部分了解我們正在做什麼。
  4. 有價值的。每一個里程碑都會帶來價值。如果您正在處理具有許多里程碑的專案，您應該能夠中途停止。即使您沒有完成所有里程碑，您也應該已經交付了價值。

對於最後一塊，該值可以是
  1. 客戶價值
  2. 商業價值，或
  3. 資訊。

里程碑的這些屬性的首字母縮寫詞是 SHUV。
為什麼要使用里程碑？好吧，讓我們先談談為什麼不使用專案。
  

人類在專案管理方面很糟糕
專案管理令人著迷。它提供了一種控制非常混亂的過程的錯覺。
專案管理似乎很有價值。你確實需要某種結構。您確實希望考慮風險、審查進度並跟蹤依賴項。
專案管理的一個更好的替代方法是里程碑管理。你所做的就是“用里程碑取代所有關於專案的談話”
讓我解釋一下為什麼這個簡單的改變是可取的。

  • 工程師通常不擅長增量設計

工程師傾向於以整體方式設計和排序工作。經驗豐富的工程師知道如何逐步工作。但是工程組織的重心是在水平層上進行設計。
以下是您的工程團隊將如何設計典型功能。這假設工作有前端和後端部分。
  • 有一個你正在工作的對話或設計文件。設計師提供模型。
  • 在專注於前端和後端的工程師之間就 API 的外觀達成一致。
  • 後端工程師開始處理 API。他們設計資料模型，建立 CRUD 操作，然後在其中新增有趣的業務邏輯。為其啟動一個新服務。
  • 前端工程師開始構建 UI。他們從模擬中構建它，為每件事建立元件。一頁一頁地做。模擬後端直到它可用，然後將其連線起來。
  • 解決前端和後端之間不可避免的問題。

全棧工程師通常會以相同的水平設計方式構建事物。
這種方法有什麼問題？
  1. 它根本不是增量。
  2. 所有的價值都在最後交付。

稍後我們將討論一個更好的方法來做到這一點。
  • 設計師也不擅長增量設計

設計人員在增量交付方面也面臨著類似的挑戰。為了設計好東西，你必須考慮最終狀態。因此，設計師將製作代表您正在努力實現的最終狀態的工件。
這是必要的。設計師需要做的工作是考慮最終狀態。但這進一步使您的交付偏向於整體。這是一個陷阱！
  • 產品經理考慮長期的最終目標。

同樣，產品經理從最終狀態的角度考慮事情。他們擁有想要交付給客戶的能力，因此他們可能不會考慮到達那裡的途徑。所以他們加入了所有偏向於整體交付的人群。
  • 有效的專案估算幾乎不存在

我們的領域以不可靠的估計而臭名昭著。這太糟糕了，NoEstimates 陣營中的許多人認為你根本不應該估計。
這是有爭議的，因為瞭解構建能力的成本很重要。如果您無法計算成本，那麼您就不可能找出最有價值的工作（價值/成本）。
問題是我們渴望不必要的精確度。我們不需要知道確切的估計來確保工程專注於最重要的工作。產生精確估計的成本是浪費的。它甚至不會產生您正在尋找的結果。您無需假裝該功能將在 6 月 20 日完成。無論如何，這個日期肯定是不正確的。
里程碑降低了將高階估計放在一起的複雜性。它們提供了一個速記，對於大多數決策來說已經足夠好了，而且沒有嚴格估計的開銷。
有時，我看到人們在嚴格的估計上取得成功。但它很少是系統性的——通常是一個人擅長它。它依賴於他們。如果他們去度假一週，沒有人能夠餵養他們的模型，然後它就會崩潰。雖然這是一項很棒的技能，但對我來說，這是證明規則的例外。可以這樣想：如果二十分之一的人可以在高度複雜的情況下進行估計，那麼在不太複雜的情況下有多少人會更成功？
  • 專案往往對人不利

專案交付感覺就像是一個艱難的過程。通常你會為一個可能不切實際的目標工作數月。或者目標可能一直在變化。你工作了幾個月來交付一些東西，卻發現它沒有達到目標。
這些是疾病的症狀：專案是其背後的邪惡。
 

人類實際上非常擅長里程碑管理
專案和里程碑之間的區別就像玩雜耍三個球和六個球之間的區別。處理六個球需要更多數量級的技巧。大多數人可以在二十四小時內學會玩弄三個球。學會玩弄六個球可能需要數年或數十年的時間。
專案管理是一項比里程碑管理更難的技能。為什麼不玩最簡單的遊戲，尤其是當結果可以好得多的時候。讓我們列舉所有這些方法。

  • 估計一到三週的工作很容易

一到三週足夠短，人們可以推理範圍。他們可以估計所涉及的工作量並且相當準確。一家公司發現他們的團隊大約 97% 能夠達到他們對這種規模專案的估計。
設定目標的最佳時間是一週到三週。人類在這種規模的工作中做得更好。他們對具有這種複雜性的工作的估計要準確得多。
  • 將專案分解為里程碑可讓您塑造專案

當人們分解一個專案時，他們通常會將其分解為技術任務。一些更有經驗的團隊可能會將其分解為使用者故事。
如果您首先將專案分解為里程碑列表，您將獲得更大的價值。專案是一個或多個里程碑的列表。您的專案高階計劃是要交付的里程碑的有序列表。
這更有價值，因為人類可以比技術任務列表更好地推理里程碑列表。列表更流暢。與此相反的是一系列技術任務。他們將鞏固您的方法，並使改變計劃的工作量很大。
使用者故事雖然比技術任務好得多，但也更難推理，因為你可能有很多。
里程碑位於您可以與它們一起玩的合適高度。
您可以透過多種方式交付能力。產品交付中最未開發的方面之一是處理分解工作的順序和方式。時間最有價值的用途之一是考慮多種方法來構建專案。
我喜歡讓團隊想出三種不同的方法來對專案進行排序。我讓他們討論權衡並選擇最好的一個。
要考慮的權衡包括：
  • 客戶什麼時候會接觸到你的作品？向前移動它可以更早地提供資訊。您將在成功專案中看到的一般模式是早期的客戶反饋，然後隨著時間的推移增加與客戶的聯絡。
  • 你會學到什麼資訊，什麼時候？您可能會盡早完成風險更高的里程碑，以探索您不太自信的領域。或者你可能會做一個里程碑，明確地在早期測試一些假設。
  • 什麼時候可以完全整合？經驗豐富的工程師將從鋼螺紋開始，並使其始終保持工作狀態。對依賴於稍後合併工作的訂單持懷疑態度。
  • 你給未來的自己多少選擇？使我們能夠轉向新的優先事項的排序可能非常有價值。如果您能夠對專案進行排序，以便在專案結束時價值會隨著時間的推移而減少，那麼您可以透過不實施可能價值較低的事情來保持專案的精益。隨著時間的推移，這也可以減少技術債務。當您只交付一部分時，請確保您早期交付的內容實際上是有價值的。

  

里程碑鼓勵探索性和執行性專案的分離
里程碑有助於將可交付成果分為兩類：

  1. 執行。可以分解的工作，以及
  2. 探索。有很多未知數且無法分解的工作。

這允許您將購買能力與購買資訊分開。
我們使用的里程碑定義的一個好處是每個里程碑都提供價值。有些專案將無法分解為一組完整的里程碑。當對該專案的瞭解還不夠時，就會發生這種情況。那很完美！因為里程碑旨在傳遞的價值是資訊。
提供資訊的專案會帶來價值。例如，假設您想為客戶構建一些東西。新功能依賴於貴公司中沒人熟悉的技術。您採用的方法很大程度上取決於技術細節，而這些細節是未知的。
在這種情況下，您可以讓團隊進行調查。里程碑的可交付成果可以是簡報，也可以是原型。團隊還應該致力於提供三種不同的方式，他們將排列未來的里程碑以提供能力。
當面臨對提供資訊的里程碑進行優先排序時，產品經理可以做出理性的選擇：這些資訊是否值得團隊花費幾周的時間？
  

里程碑自然地鼓勵垂直、增量設計
當使用里程碑的團隊交付功能時，我們將採用的方法與我們之前描述的方法大不相同。

  • 您將有一個正在工作的對話或設計文件。也許設計師提供了模型。
  • 您將同時考慮完整功能和功能的第一個里程碑。如果該功能足夠複雜，那麼您就有了整個事物的技術設計。如果您可以逐步完成，那麼您只需設計下一個里程碑。
  • 設計師有一個最終狀態的設計，但也必須為里程碑做一個設計。
  • 您將專注於第一個里程碑，它具有一個狹義定義的功能子集，您可以構建這些功能並提供價值。
  • 前端和後端工程師共同構建里程碑。
  • 後端工程師可能不會構建完整的 API。他們構建了里程碑所需的東西。他們設計資料模型，建立 CRUD 操作，然後在其中新增有趣的業務邏輯。為其啟動一個新服務。但他們遺漏了目前不需要的部分。
  • 前端工程師開始構建 UI。他們工作的模擬比最終狀態更苗條，所以他們構建了一個更苗條的特性。他們為每件事建立元件。如果他們沒有完成，他們可能會在幾天內模擬對後端 API 的呼叫，但是當他們完成時，他們應該能夠快速提供反饋並與後端工程師進行迭代。
  • 他們一路演示他們的工作，在里程碑結束時，他們可以一起演示一組完整的工作。

正如您所注意到的，這並沒有什麼不同，只是前端和後端工程師更緊密地合作，共同交付里程碑。他們更加同步。
儘管這樣做的好處似乎很微妙，但它們很重要。漸進式設計的結果是在每個里程碑之後都能產生價值。您不是每三到六個月就交付大量不可靠的價值，而是每隔一到三週交付一次價值，並在未達標時學習和調整。您必須投資於學習和適應以利用增量設計，但回報是巨大的。

 

如何分解專案里程碑
當您處理里程碑時，僅分解當前里程碑。使用使用者故事而不是技術任務。垂直切片可以是分形的，也可以在里程碑內向下延伸。您可能會發現可以刪除、推遲或更改的使用者故事。
例如，假設我們從我們的第一個里程碑開始：“為我們自己的團隊建立一個硬編碼的 Slack 機器人，用折線圖顯示有用的指標。​​”
有很多方法可以做到這一點，但讓我們列出一些潛在的使用者故事：

  • “當團隊成員輸入 /happybot test 時，他們可以在 Slack 的my-team 房間中看到顯示的‘hello world’訊息”
  • “團隊成員在輸入 /happybot test 時，可以在 Slack 的 my-team 房間中看到當前顯示的幸福度分數”
  • “當團隊成員輸入 /happybot line 時，他們可以在 Slack 的 my-team 房間中看到一個折線圖”

如果有幫助或必要，這些中的每一個都可以分解為技術任務。
 

具有里程碑的優先順序就足夠了
在確定優先順序時，您將大致瞭解基於里程碑數量的功能成本（對於執行專案）。您可能不需要像您認為的那樣對功能進行優先排序的準確性。
但是關於里程碑的一件好事是，您可以透過優先順序來發揮創意。例如，您可能會檢視一個專案，並決定您可以完成前半部分里程碑，並交付該專案的大部分價值。這種規劃中的流動性是我們在產品開發過程中所缺少的主要因素之一。
正如產品開發流程原理（我最喜歡的產品開發書籍之一）的作者 Donald Reinertsen所說：

偉大的工程團隊專注於里程碑而不是專案 - Jade Rubick
當團隊始終提供價值時，他們就會蓬勃發展
每隔幾周就為企業創造價值的團隊感覺很棒。他們有源源不斷的成就。當你為世界創造價值時，工作就會變得有意義。人們會發展出一種動力感和自信感，這有助於將團隊凝聚在一起並培養相互批評和改進的能力。
 

里程碑是敏捷的，從某種意義上說，變化是自然的
有了里程碑，你每隔一到三週就會有一個自然停留的地方。這意味著團隊可以改變他們的優先事項，這樣做不會讓人覺得很痛苦。而且因為交付了一些價值，所以不會覺得您的工作被浪費了。對於專案，優先順序更改感覺就像放棄工作一樣，並且可能令人沮喪。有了里程碑，你通常可以完成你正在做的事情。
在某些情況下，您會想要停止里程碑：如果某些事情真的很緊急。但如果你這樣做，你就會有意識地選擇承擔放棄工作的成本。而且它不太可能發生，因為里程碑的結束更有可能臨近。

相關文章