獨立執行者模型:產品工程團隊避免相互依賴的銀彈?- Jade

banq發表於2021-11-18

需要其他團隊合作是很自然的。等待他們或依賴他們為您提供一些東西可能很誘人,發生這種情況是因為他們擁有您需要工作的區域。例如,您可能需要一個團隊將一個欄位新增到他們的 API 中。或者您可能需要它們為您構建新的 API。有時,如果沒有這些更改,您就無法交付所需的內容。
這是一個組織陷阱。它會導致痛苦。
 

獨立執行團隊規則
為了避免這個絕望的坑,請不要指望其他團隊為您工作。遵循以下規則:

  • 您可以制定計劃,讓其他團隊為您工作。
  • 與其他團隊溝通您想要什麼,並確保他們瞭解它的重要性。
  • 但是永遠不要指望任何其他團隊為您工作。
  • 當您依賴其他團隊時,請始終制定備用計劃。這樣,如果他們的優先事項與您的優先事項不一致,您就可以繼續並提供價值。
  • 盡一切努力向客戶提供您的體驗。

  

產品工程應該如何處理依賴關係?
一些組織試圖透過跟蹤來解決依賴關係。這不起作用,因為問題是依賴關係,而不是跟蹤依賴關係。在 Jira 中新增跟蹤需求的系統無濟於事。一切的基礎是每個團隊都有相互競爭的優先事項。這些優先事項會發生變化,因此您不能依賴它們。
任何雄心勃勃的專案都會有依賴關係。依賴關係越多,您就越處於危險區域。您擁有的依賴項越多,風險就越大。乘以每個依賴項的變化機率。很快,這是不可避免的。你的計劃正在制定中。
轉向一種模式,在這種模式下,您堅持始終制定不依賴他人的計劃。當你這樣做時,你總是有一個能帶來價值的計劃。將您的需求傳達給其他團隊,以便他們為整個公司創造最大價值。但要在您的控制範圍內提供最大的價值。
據我所知,這是在產品工程中保持理智的唯一方法。
有些人會認為他們可以透過使用經驗豐富的專案經理來避免這個陷阱。但問題不在於專案管理不善。即使您管理依賴項和風險,您也將面臨無法接受的風險。具有依賴性的計劃是有風險的。當你總是有一個後備時,你保證你可以提供一個價值基線。
 

何時使用此模型

  • 這應該是產品工程團隊的預設設定。不以這種方式運作會導致專案失敗的風險更高。
  • 這比產品工程更適用。基本原則適用於所有工程團隊。

  

何時使用本模型

  • 評估破解hack和遷移的成本。通常圍繞其他團隊的優先事項工作意味著您必須保持混亂。當您沒有在正確的地方完成工作時,它會使您的解決方案變得不那麼優雅。首先,檢查您的團隊是否可以在正確的地方完成工作。您可以使用 Away Team 模型來執行此操作。見下文。如果您必須使用破解hack不走尋常路,那麼您的成本是建立 hack、維護它,並在準備好後遷移到新的解決方案。不要忽視這些東西的成本。您可能會認為成本不值得,而您應該做其他事情。請務必將這些費用傳達給您提出請求的團隊。但是您可以根據您提供的價值和您承擔的成本來決定是否值得。
  • 不要忘記你的影響力。儘管您無法控制其他團隊可以做什麼,但您可以影響他們。一定要傳達你的需求,並解釋為什麼它很重要。為他們提供評估全球優先事項所需的背景資訊。
  • 密切關注組織結構。如果組織結構不正確,您可能有過多的依賴關係。最常見的例子是前端和後端工程團隊。每個前端專案都依賴於後端團隊。雖然團隊找到了解決依賴關係的方法,但它們並不理想。他們可能會同意 API 合同,但會錯過一些東西並且必須迭代。通常最好一起工作。當您看到這些依賴項時,通常您的組織設計是不正確的。(我稍後會寫一篇關於前端和後端團隊模式的更長的文章——我對此有很多想法)。
  • 良好的系統級優先順序是必不可少的。如果沒有良好的產品管理,您將無法解耦您的團隊。您需要一個產品管理(或整合商)傾聽全球需求並確定其優先順序。如果團隊根據本地需求確定優先順序,則您需要加強您的整合商。

 

獨立執行者與其他協調模型
獨立執行器是一種減少不必要協調的模型。當您需要增加協調時,您應該檢視其他協調模型。當您需要其他團隊的工作時,請考慮:
專案經理協調大型計劃

  • 當您需要協調一項大型計劃時,專案經理是理想的選擇。但首先需要將大型計劃作為優先事項。我很快就會寫關於集中/集中優先順序的文章。在那篇文章中,我將分享如何合理地確定優先順序。因此,專案經理並不能幫助其他團隊為您工作。

整合商傾聽並確定優先順序
  • 整合商傾聽人們的需求,並根據他們聽到的內容確定優先順序。產品經理通常填補這個職能。當您使用獨立執行器模型時,您需要整合器。如果您轉向獨立執行器模型,則應新增整合器。否則,您最終會遇到很多混亂的產品工程,以及一個無用的平臺。

客隊模式可以是一種自己動手的方式
  • 與其讓另一個團隊做這項工作,為什麼不自己做呢?亞馬遜有一種方法叫做離開團隊模型。你不能依賴其他團隊為你工作,但你可以在他們的職責範圍內工作。基本思想是你派一個或多個人到另一個團隊。他們在他們的程式碼庫中完成工作。這不是真正的嵌入,因為他們在有限的時間內在那裡工作。他們與其他團隊的互動方式也很靈活。他們可以完全獨立,也可以讓團隊中的某個人提供幫助。
  • 在您的組織中為此制定規範將有助於客隊取得成功。制定貢獻標準也會有所幫助。我發現讓其他團隊的某個人與客隊成員一起工作並指導他們很有用。但如果你有嚴格的規範和標準,那可能就沒有必要了。
  • 重要的是工作與其他團隊的目標相容。所以通常這需要對話。有時,其他團隊甚至可能沒有足夠的頻寬來進行這些討論。在這些情況下,您可能不走運。
  • 我稍後會寫一篇關於這個模型的更長的文章。

為關鍵專案組建一個工作組
  • 如果工作很關鍵,則可能需要一個工作組。透過工作組,您可以組建一個臨時團隊來跨幾個團隊完成工作。特遣隊有缺點,可能具有破壞性。所以你應該只在緊急情況下使用它們。
  • 工作組不會幫助您讓其他團隊完成您的工作。

說服老虎團隊為您做這件事
  • 如果其他團隊太忙,有時您可以說服一個老虎團隊來代替。這是一種凌亂的做事方式,但在某些情況下它可以工作。

如果可以,請加入實踐社群
  • 一些實踐社群開發了推動工作的方法。如果您需要的工作與實踐社群一致,您就可以利用這一點。



 

相關文章