敏捷產品開發:過程vs模型?PM不應該只是照搬硬套
你必須把精力集中在那些你必須要做的事情上,不要只盯著模型。
統計界有句老話:
所有模型都是錯誤的,但有些是有用的。
一直以來,這句話都引起了我的共鳴。雖然概念模型從來都是不完美的,但我發現它是解釋重要概念的一個特別有力的工具。但人們過于隨便地接受概念模型,或者在模型中進行過多的規劃,并將其解釋為一個約定俗成的過程是有風險存在的。這種風險偶爾會發生在分析連續的產品識別和交付過程中。
我很早就使用了概念模型來表示這兩個并行的活動:
這個概念模型實際上有許多名稱。事實上,我認為這正好表明了該模型的構造能夠代表事實情況,以至于很多人用不同的術語來引用這個模型。我見過這個模型被稱為“正確產品/產品正確模型”,“預假設模型”等等?,F在很多人引用這個模型為”雙軌敏捷開發”或通稱“雙軌產品開發”。
Jeff Patton最近發表了一篇很好的文章,涵蓋了“雙軌”短語的起源(文章鏈接見文末)。在他的文章中,您可以看到Jeff是如何努力在概念模型中捕捉更多產品挖掘和實施過程的。我們能看出這個簡單的概念模型是如何演變成復雜的流程圖的。
應用敏捷思維和產品思維在同一過程中
這些年來,很多人鼓勵我擴充簡單概念模型,以突出此類問題:
- 基本產品規劃和/或用戶研究工作,這些工作通常要在更多的戰術發現工作之前完成。
- 描述在交付過程中要完成的工作活動
- Scrum與看板交付過程的差異(文末有相關資料)
- 在生產和發現學習中出現的反饋回路
我拒絕了這些建議,不是因為其中哪一個都是錯誤的,而是因為人們總是希望能輕易從一個簡單的概念模型轉到一個更詳細的具體產品開發中,如文章開始所述,這樣容易出現差錯。更重要的是,我比較喜歡這個簡單的模型,因為它不是面向過程的。有許多不同的識別過程和技術,正如會有許多不同的交付過程和技術。
對我來說更高階的問題是:
- 產品識別和交付活動是平行進行的,它們并不是“階段”。
- 在產品識別中,團隊正面臨著巨大的風險——價值、可用性、可行性和可存活性。
- 在識別中,產品團隊正在協作解決的問題——產品管理、產品設計和工程。
- 產品團隊要對業務結果進行度量,而不僅僅是輸送功能。
這就是一個產品團隊對產品識別和交付的責任(顯然,產品經理和設計師將大部分時間花在探索活動上,而工程師則把大部分時間花在交付活動上)。
我一直對產品人強調,沒有孤立的產品開發過程,也沒有孤立的產品識別/交付過程。照搬硬套,只能是依葫蘆畫瓢。許多不同的產品識別過程,都是針對不同的情況。此外,重要的是要認識到這并不只是個過程。它更重要的是投入必要的文化理念,并在關鍵技術上訓練你的團隊。
在最近的(必讀)股東信件中(《亞馬遜CEO Jeff Bezo:如何讓團隊保持活力?》),Jeff Bezos談到了一些同樣的問題:“良好的過程為你服務,這樣您就可以為客戶服務?!?。但如果你不注意,這個過程就會成為一個東西。這在大型組織中經常發生。過程成為了結果的代替品。你不看結果,只是確保你在正確地執行這個過程。
如果你要在前面解決風險、真正地與工程和設計結合,并提出好的解決方案;如果你要確保正在解決潛在的業務和客戶問題,而不僅僅是在輸送功能,那么你就得把精力集中在那些你必須要做的事情上,不要只盯著模型。
拓展閱讀
雙軌產品開發的始末
http://jpattonassociates.com/dual-track-development/
Scrum簡介?
- 把組織細分成小組、跨功能、自我組織團隊。
- 把工作細分成細小、實在的交付成果,交排人員負責需求清單以及跟據重要性排優先級別,由團隊估算每個項目相對工量。
- 把整個開發時間分成固定時長的短迭代(通常于一至四星期),在每個迭代后演示新增可發布功能。
- 優化發布以及跟客戶一起更新優先級別,基于每個迭代后發布的觀察。
- 優化過程,在每個迭代之后進行回顧
看板開發方式簡介?
- 看板開發方式是近年引起很多討論和注目的一種敏捷開發實施。
- 工作流程形象化
- 把工作細分成任務,寫在卡紙上,貼在墻上
- 把欄命名好,來顯示任務在工作流程中的狀況
- 限制“在制品”(work in progress,簡稱 WIP) – 明確設定限制在每個狀態下同一時間能有多少工作任務。只有當前的某項工作被交付,或是有了來自于下游的拉動,新的工作才能開始。
- 度量生產周期(即完成一個任務的平均時間),優化開發過程,縮短開發周期和使它更易于預測。
翻譯:盯襠貓
原文作者:Marty Cagan
原文:https://svpg.com/process-vs-model/
本文由 @盯襠貓 翻譯發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
- 目前還沒評論,等你發揮!