Team Ramp Up 是否保證提高特徵速度?
已發表: 2020-03-28增加團隊以提高發布速度的關鍵要素之一是將清晰度從產品團隊轉移到衝刺團隊
順利的衝刺執行是來自產品和衝刺團隊的顯著貢獻的結果
“一次成功(FTR)”的理念幫助所有團隊成員朝著一個共同目標
當初創公司從早期階段進入成長階段時,他們的優先事項會發生很大程度的變化。 其中,特徵速度作為優先事項脫穎而出,在他們追求增長的過程中發揮著至關重要的作用。
我與之合作的一家種子基金初創公司的創始人最近進行了 A 輪融資,他要求我將工程團隊翻倍,以便在六個月內發布新功能。 然而,這是縮短週期時間的唯一相關因素嗎? 為了回答,我決定解決這種普遍的“誤解”背後被忽視的方面。
儘管資源容量是推動頻繁發布生產的關鍵因素之一,但僅此一項並不能保證縮短週期時間。 在為超過 16 家初創公司構建產品的過程中,我多次見證了從早期階段到成長階段的轉變。 出於這種經驗,我分享了一些關鍵因素,供初創公司創始人考慮。
傳遞清晰:自上而下的基本要素
增加團隊以提高發布速度的關鍵要素之一是將清晰度從產品團隊轉移到衝刺團隊。 當 sprint 開始時模棱兩可或沒有足夠的故事開始時,sprint 交付率會受到不利影響。 模糊定義的故事或包含任務的衝刺中期會減慢步伐,結果衝刺團隊無法按計劃交付。
順利的 sprint 執行是來自產品和 sprint 團隊的顯著貢獻的結果。 產品團隊可以發揮自己的作用,至少在本季度準備和分享路線圖給衝刺團隊,以便團隊可以相應地計劃其可交付成果。
另一方面,衝刺團隊應繼續推動產品團隊獲得產品積壓,並每週/每兩週對其進行梳理,以確保集中交付。
自動化發布“無錯誤”
“效率就是把事情做對; 效率就是做正確的事。” - 彼得·德魯克
當您想到自動化時,它就是後一類的一個例子。 一旦功能開發速度加快,除非採用正確的流程,否則生產很可能會崩潰。 如果產品不夠穩定,無法處理新功能開發,那麼您的團隊會花費更多時間來解決問題而不是構建新功能。 因此,您的工程速度會下降。
這就是 CI/CD(持續集成和持續部署)發揮作用的地方。 在這裡,詳盡的單元、集成和自動化測試覆蓋確保任何交付的東西都不會破壞系統。
為你推薦:
不要只是建造更多,否則你會破壞更多
返工是一個很大的生產力殺手,可能是各種因素的結果,例如模糊定義的故事、缺乏開發測試、缺乏測試覆蓋率等等。 返工會消耗生產力,因為它會消耗 QA 工程師在測試和回歸中、開發人員在調試中以及發布經理在重新發布中的時間和精力。
稍微放慢速度可以幫助您的團隊更快地交付並增加價值,因為有效的速度總是比速度更有價值。
“第一次正確(FTR)”的理念幫助所有團隊成員達成一個共同目標——在第一時間交付健壯和穩定的代碼。 花一些額外的時間來確定代碼的質量總是健康的,而不是匆忙,然後陷入返工。
一些久經考驗的提高 FTR 比率的方法是定期梳理積壓工作、重複故事、定期向產品經理演示。 sprint 團隊不應僅僅收集需求,而應該更專注於闡明它們以提高 FTR 比率。
為並行沖刺構建您的團隊
當你的初創公司有一個小型產品團隊時,每個人大多同時開發一兩個功能(通常適用於 4-6 人的團隊)。 但是,隨著對交付多個功能的期望不斷提高,強烈建議您組建多個具有不同重點領域的子團隊。 通過這種方式,每個子團隊都可以運行其衝刺並定義其路線圖。
與一個大團隊相比,從“邏輯分離”框架中誕生的小團隊更有效,產生更好的結果。 微服務的各個團隊、不同的產品線和各種組件都是“邏輯分離”方法的幾個例子。
在重組過程中,始終必須在每個子團隊中至少包括一名來自早期核心團隊的成員,以維護 DNA。 儘管交付的跨團隊協調需要額外的開銷,但這是一個合理的權衡。
跟踪功能使用情況以及速度
用戶體驗是衡量新功能發布成功與否的最重要指標。 當您開始快速交付多種功能時,用戶體驗通常會退居二線。 當您的產品功能有限時,用戶交互仍然是平滑的不間斷曲線。
但是,當您開始發布新功能時,用戶很可能會不知所措,他們的體驗也會受到影響。
為了實現更好的用戶採用,跟踪用戶參與度和功能速度仍然是最好的方法。 雖然詳盡的用戶研究是一種行之有效的方法,但其他重要的方法最初是通過功能標誌、AB 測試以及在每個新版本發布後跟踪用戶旅程(通過幅度或類似分析工具)向選定的用戶推出。
不要失去你的核心成員
這可能是一個非常普遍被忽視的方面,但卻是一個非常關鍵的方面。 小團隊不一定需要流程,結構靈活,每個人的聲音都能聽到。 當這些團隊升級到建立流程並添加新的工程和職能成員的狀態時,健康的管理是避免混亂的唯一方法。
隨著您的工程團隊成功擴大規模,一個能力強的產品團隊對於持續為工程團隊提供支持至關重要。 當團隊成員沒有重要工作時,流失變得不可避免,但沒有一家初創公司願意失去其核心成員。 在這種情況下,高級管理層掌握著確保與人建立良好關係並很好地了解動態的關鍵。
我在這里分享的經驗來自多年來與多家初創公司的經驗。 我希望它對初創公司的創始人有用,他們已經有很多事情要做,而且他們最終不會重新發明輪子。