項目思維 vs 產品思維
項目思維關注產出 output,產品思維關注結果 outcome,兩者各自有適合的領域。
今天和大家分享 Kyle Evans 在 Medium 上非常受歡迎的文章,這篇文章講述項目思維和產品思維的區別,以及為什么產品思維更有利于創新型互聯網業務。
一個產品經理(或組織)面臨的最大挑戰之一就是如何將思維模式以及文化特性從項目層面提升到整個產品的高度。
項目思維
項目思維相當普遍。特別是對于從事軟件開發的工作人員,他們職業生涯的大部分時間都專注于項目執行以及項目管理。大型組織通常有PMO部門——項目管理辦公室,專注于項目管理。
這并不奇怪,因為項目管理已經存在了很長時間。且我們人類傾向于從項目角度思考:依次做完那些需要我們完成的事情即可。
那么項目思維是什么呢?
項目思維的重點在于交付??梢允菍τ谔囟üδ芑蜍浖慕桓?,或者說實際上是對任何東西的交付。從飛機到房屋亦是如此。那么由于專注在交付上,主要的衡量標準就是時間軸和日程表。
項目管理專注于輸出,并通過我們先前對時間軸估算的準確程度來衡量,再按照日程表交付指定「產量」。
在這樣的情況下,能否成功很大程度上取決于,是否預先制定產品規格,設定具有一個個節點的日程表,以及按照這些日期完成交付。
產品思維
產品思維則采用了完全不同的方法。產品思維并不關注產出(output),而是關注結果(outcome)。
與項目思維相比,這是一個重大的思維轉變。我們并不關注時間表和日期,而是關注想要實現的目標或要完成的工作。
由于我們專注于結果而不是產出,所以在前期,對交付時間做出約束會比較困難。這主要是因為前期我們不太需要知道我們將如何實現目標。
這種思維方式可能是一個很大的轉變,特別是對于那些花費大量時間專注于項目執行和項目管理的人。對于沒有定期監控的時間軸和日程表,許多人可能會因這種不確定性而感到不安。
產品思維的好處
那么放棄項目時間表改為關注結果會帶來什么好處呢?
首先,無論我們做出什么努力去實現目標,從根本上來講我們都要向著結果去前進。產品思維的主要好處是我們確保我們更高效地獲得結果。
而項目思維,則需要在一開始時就假設,我們已經知道如何去實現預期的結果。根據這一假設,我們創建一個具有目標要求和工作節點的項目計劃和時間軸,然后開始執行該計劃。
如果我們做的正確,且我們最初的設定在事后被證明是正確的解決方案,那么我們就會得到好的結果。我們要做的也只是執行計劃并取得成果。
但如果我們最初是錯的該怎么辦?我們確定下來的解決方案無法達到我們渴望的結果要怎么辦?
這就是項目思維讓我們陷入各種麻煩的地方。一旦我們制定了計劃,尤其是在大型組織中可能就很難轉移和改變。
在確定好日期并且每個人都對計劃表示同意的情況下,不管我們盡多大努力學習和適應,這樣的計劃通常會根深蒂固于每個人的大腦中。且如果我們最終錯過了某個日期,那么它可能會給團隊和業務進度帶來很大的影響。
但是,使用產品思維,我們能夠隨時學習和適應。我們不去確定日期和工作節點,而是專注于研究和實現結果。如果某些事情沒有成功,或并沒有得到用戶積極的反饋,我們就去處理這件事,去適應并仍朝著我們預期的結果努力,而不用擔心破壞了所有人的美好計劃。
更重要的是,問題出現時(不要自欺欺人,問題總是會出現的),產品思維使我們能夠學習和適應,并專注于我們要努力實現的結果。
相反的,問題出現時,當處在被時間表困住的項目思維中,我們常常會陷入無休止的會議,并試圖搞清楚為什么我們的初步猜測是錯誤的,以及我們如何重新按計劃進行下去。
這最終會導致犧牲產品的質量,工作與生活的平衡以及最終結果,因為我們不得不繼續專注在交付最初商定的產出上,不管這是否仍然是正確的事情。
項目示例
我們已經討論了很多概念的東西,那么現在讓我們看一些例子來更好地理解這些概念。
關于項目的一個很好的例子是建造房屋。我妻子和我去年建了我們的房子。我們經歷了包括從選擇平面圖到選擇房子里的所有飾面和細節的整個過程,之后也投入了很多錢來推動這項工程。
當我們開始時,我們的施工經理(絕對優秀)給了我們估計的完成日期。大約6個月。顯然,這個估計并不會完全符合現實,通??赡軙霈F導致工期拖后的事情,但由于房屋的建造是一個具有明確輸入的且可重復的過程,一個好的施工經理可以逐周查看計劃并確定他們何時可以完成工作。
我們的房子大約比預期晚了一個星期建完,完全符合我對項目日期的看法。其中一項交易拖延了,因此工程擱置了幾天,并且產生了一些連鎖反應。但那沒關系。這是在預料之中的。
對于這種類型的建筑工程,非常適用于項目管理。每個人都知道需要做什么,按時完成是關鍵,尤其是當我們考慮的不僅是要居住的房子,而是整個開發過程。
產品示例
但是這種項目管理在任何地方都有效嗎?
并不是這樣。
雖然我們很想把軟件開發看作是建筑工程,但事實并非如此。無論我們多么努力,明確定義的計劃和工作都不能轉化為產品開發。雖然在明確的時間表可以帶來很大的舒適性,但這并不符合我們進行新產品開發的情況。
在我一直做的一個產品中,我發現了一個關鍵問題,并且知道我們需要解決這個問題,以便繼續擴大我們的受眾范圍并接觸到更多的用戶。
傳統的方法是收集需求,確定工作范圍,然后構建特性。但令我所在組織的許多人感到震驚的是,我并沒有采用這種典型的方法。
在我了解了這個問題后,我便開始研究解決方案,從構建特性到集成第三方軟件。
當我這樣做的時候,我發現解決方案實際上是不開發任何東西。
與其構建新功能或集成其他人的軟件(在本例中,是為了展示學生的作品集),解決方案是改變我們要求學生做的事情。
與其專注于做作品集的工具,我們可以簡單地要求他們創建作品集,然后利用他們想用的任意軟件來展示他們的作品。
這對每個人都有很大的好處。學生們可以為自己的作品集做主,我們也可以不用局限于構建軟件或使用任何特定的供應商。
用項目思維永遠不會解決這個問題。這個解決方案產生的原因是我關注的是問題及其結果(在我們的應用程序上獲得更多用戶)。而不是構建另一個特性。
這種結果通常是在產品思維下所產生的。且任何時候都有可能發生。在我上面的例子中,我們避免做任何開發工作。但通常需要用幾個設計原型來弄清楚什么是可行的?;蛘呶覀兛梢宰錾倭康拈_發工作來學習哪些特性將真正驅動我們得到想要的結果。
無論我們在哪個過程中學到東西,最關鍵的是我們在這個過程中學習到了東西,而不是預先決定進程并遵循項目計劃。
正確的處理方式
那我們怎么做呢?如何保持產品開發專注重點?
所有產品和產品管理都涉及一定程度的項目管理。我們必須讓工作進行下去,并且(不幸的是),我們的利益相關者以及合作伙伴一定還是會期待某些日期或承諾。
關鍵是只有在我們高度自信的情況下才可以做出承諾和項目計劃。因此,我們要在驗證了我們正在做的事情并且有機會真正理解它將采取什么措施的情況下,作出承諾,而不是事先承諾特定的路徑。
通常是在進入工作的沖刺時段??雌饋砜赡苡悬c遲,但正是在那時估算和計劃才真正有意義。
Marty Cagan 在他的書《啟示錄:打造用戶喜愛的產品》中稱這種承諾是「高度誠信的承諾」。我們允許團隊在要求承諾之前有時間進行適當的探索和研究。
我們還需要讓其他人了解采用產品思維的好處。有很多人要求提供日期和時間表是有原因的。部分原因是因為舊習慣。對于業務和預算來說是必要考慮時間的。因此,在這些情況下,我們需要搞清時間軸的作用。
如果是為了幫助銷售產品,我們應該將重點從特定功能提升到更高級別。如果是為了管理風險,也許我們需要幫助人們理解真正的風險并不在于錯過日期,這完全忽視了我們試圖提供的價值。
最后,我們要明白產品開發的目的就是為用戶和消費者創造價值。大多數情況下,我們并不確切地知道什么會帶來這個價值。如果你在做年度計劃和預算編制時,認為我們可以預先一年提出正確的解決方案,那是非常不現實的。
項目思維的重點是預先提出解決方案,然后按計劃進行交付,但產品思維會將重點放在結果上。這涉及一定程度的不確定性和對學習能力的要求,這可能相當困難。但是,如果我們想要獲得好的結果,而不僅是準時產出,那么它實際上是唯一的工作方式。
原文:https://productcoalition.com/product-thinking-vs-project-thinking-380692a2d4e
標題:Product Thinking vs. Project Thinking
作者:Kyle Evans,公眾號:光澗實驗室(ID:lightstream0)
本文由 @光澗實驗室 翻譯發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
產品:做對的事
項目:把事做對
作者把項目經理定位為to B/G的傳統項目經理就不會有誤導了
翻譯的真的很爛,讀的很累,感覺英語剛過6級的樣子
建議作者把文章刪掉,不要誤人子弟,浪費時間
兩個緯度的思考,項目產出的是產品或服務。
你是在diss項目經理?
互聯網項目管理思維要和產出結合,二者分不開
這么垃圾的文有6w,不是刷的
大哥,這么膚淺的文章!看了下項目思維的前兩句就懶得再看下去了
看來是鬧笑話了,這篇文章如果沒有翻譯錯誤,那就是作者根本不懂項目管理,尤其是不懂互聯網行業的項目管理,我尊重作者的觀點和譯者的辛苦付出,但真心建議人人都是產品經理以后嚴格把關,不要讓這種不專業的觀點誤導大家。
里面的項目思維我想作者主要說的是傳統項目管理思維,現在互聯網公司項目管理和產品、研發是緊密相連的,即使前期需求模糊階段,也是有一個需求探討明確的大概時間的,當需求以及方案都明確了,才是確定的時間軸。而且現在無論是產品思維還是項目思維,都要站在全局的角度考慮問題,兩者相輔相成,雖然各有側重點,但是都必須在一個全局的大前提下進行。但無論怎樣,這篇文章還是有一定警戒作用,特別是對于從傳統項目管理轉型到新型項目管理的同學,要經常跳出來,干預自我批判以及否定。