專案思維 vs 產品思維
專案思維關注產出（output），產品思維關注結果（outcome），兩者各自有適合的領域。今天，光澗實驗室（ID：lightstream0）和大家分享 Kyle Evans 在 Medium 上非常受歡迎的文章，這篇文章講述專案思維和產品思維的區別，以及為什麼產品思維更有利於創新型網際網路業務。
一個產品經理（或組織）面臨的最大挑戰之一就是如何將思維模式以及文化特性從專案層面提升到整個產品的高度。
專案思維
專案思維相當普遍。特別是對於從事軟體開發的工作人員，他們職業生涯的大部分時間都專注於專案執行以及專案管理。大型組織通常有PMO部門——專案管理辦公室，專注於專案管理。這並不奇怪，因為專案管理已經存在了很長時間。且我們人類傾向於從專案角度思考：依次做完那些需要我們完成的事情即可。
那麼專案思維是什麼呢？
專案思維的重點在於交付。可以是對於特定功能或軟體的交付，或者說實際上是對任何東西的交付。從飛機到房屋亦是如此。那麼由於專注在交付上，主要的衡量標準就是時間軸和日程表。
專案管理專注於輸出，並通過我們先前對時間軸估算的準確程度來衡量，再按照日程表交付指定「產量」。在這樣的情況下，能否成功很大程度上取決於，是否預先制定產品規格，設定具有一個個節點的日程表，以及按照這些日期完成交付。
產品思維
產品思維則採用了完全不同的方法。產品思維並不關注產出（output），而是關注結果（outcome）。
與專案思維相比，這是一個重大的思維轉變。我們並不關注時間表和日期，而是關注想要實現的目標或要完成的工作。由於我們專注於結果而不是產出，所以在前期，對交付時間做出約束會比較困難。這主要是因為前期我們不太需要知道我們將如何實現目標。
這種思維方式可能是一個很大的轉變，特別是對於那些花費大量時間專注於專案執行和專案管理的人。對於沒有定期監控的時間軸和日程表，許多人可能會因這種不確定性而感到不安。
產品思維的好處
那麼放棄專案時間表改為關注結果會帶來什麼好處呢？
首先，無論我們做出什麼努力去實現目標，從根本上來講我們都要向著結果去前進。產品思維的主要好處是我們確保我們更高效地獲得結果。
而專案思維，則需要在一開始時就假設，我們已經知道如何去實現預期的結果。根據這一假設，我們建立一個具有目標要求和工作節點的專案計劃和時間軸，然後開始執行該計劃。如果我們做的正確，且我們最初的設定在事後被證明是正確的解決方案，那麼我們就會得到好的結果。我們要做的也只是執行計劃並取得成果。
但如果我們最初是錯的該怎麼辦？我們確定下來的解決方案無法達到我們渴望的結果要怎麼辦？
這就是專案思維讓我們陷入各種麻煩的地方。一旦我們制定了計劃，尤其是在大型組織中可能就很難轉移和改變。在確定好日期並且每個人都對計劃表示同意的情況下，不管我們盡多大努力學習和適應，這樣的計劃通常會根深蒂固於每個人的大腦中。且如果我們最終錯過了某個日期，那麼它可能會給團隊和業務進度帶來很大的影響。
但是，使用產品思維，我們能夠隨時學習和適應。我們不去確定日期和工作節點，而是專注於研究和實現結果。如果某些事情沒有成功，或並沒有得到使用者積極的反饋，我們就去處理這件事，去適應並仍朝著我們預期的結果努力，而不用擔心破壞了所有人的美好計劃。
更重要的是，問題出現時（不要自欺欺人，問題總是會出現的），產品思維使我們能夠學習和適應，並專注於我們要努力實現的結果。相反的，問題出現時，當處在被時間表困住的專案思維中，我們常常會陷入無休止的會議，並試圖搞清楚為什麼我們的初步猜測是錯誤的，以及我們如何重新按計劃進行下去。這最終會導致犧牲產品的質量，工作與生活的平衡以及最終結果，因為我們不得不繼續專注在交付最初商定的產出上，不管這是否仍然是正確的事情。
專案示例
我們已經討論了很多概念的東西，那麼現在讓我們看一些例子來更好地理解這些概念。
△ Photo by roya ann miller on Unsplash
關於專案的一個很好的例子是建造房屋。我妻子和我去年建了我們的房子。我們經歷了包括從選擇平面圖到選擇房子裡的所有飾面和細節的整個過程，之後也投入了很多錢來推動這項工程。
當我們開始時，我們的施工經理（絕對優秀）給了我們估計的完成日期。大約6個月。顯然，這個估計並不會完全符合現實，通常可能會出現導致工期拖後的事情，但由於房屋的建造是一個具有明確輸入的且可重複的過程，一個好的施工經理可以逐周檢視計劃並確定他們何時可以完成工作。
我們的房子大約比預期晚了一個星期建完，完全符合我對專案日期的看法。其中一項交易拖延了，因此工程擱置了幾天，並且產生了一些連鎖反應。但那沒關係。這是在預料之中的。
對於這種型別的建築工程，非常適用於專案管理。每個人都知道需要做什麼，按時完成是關鍵，尤其是當我們考慮的不僅是要居住的房子，而是整個開發過程。
產品示例
但是這種專案管理在任何地方都有效嗎？
並不是這樣。
雖然我們很想把軟體開發看作是建築工程，但事實並非如此。無論我們多麼努力，明確定義的計劃和工作都不能轉化為產品開發。雖然在明確的時間表可以帶來很大的舒適性，但這並不符合我們進行新產品開發的情況。
在我一直做的一個產品中，我發現了一個關鍵問題，並且知道我們需要解決這個問題，以便繼續擴大我們的受眾範圍並接觸到更多的使用者。傳統的方法是收集需求，確定工作範圍，然後構建特性。但令我所在組織的許多人感到震驚的是，我並沒有採用這種典型的方法。
Photo by Brooke Lark on Unsplash
在我瞭解了這個問題後，我便開始研究解決方案，從構建特性到整合第三方軟體。當我這樣做的時候，我發現解決方案實際上是不開發任何東西。與其構建新功能或整合其他人的軟體（在本例中，是為了展示學生的作品集），解決方案是改變我們要求學生做的事情。與其專注於做作品集的工具，我們可以簡單地要求他們建立作品集，然後利用他們想用的任意軟體來展示他們的作品。這對每個人都有很大的好處。學生們可以為自己的作品集做主，我們也可以不用侷限於構建軟體或使用任何特定的供應商。
用專案思維永遠不會解決這個問題。這個解決方案產生的原因是我關注的是問題及其結果（在我們的應用程式上獲得更多使用者）。而不是構建另一個特性。
這種結果通常是在產品思維下所產生的。且任何時候都有可能發生。在我上面的例子中，我們避免做任何開發工作。但通常需要用幾個設計原型來弄清楚什麼是可行的。或者我們可以做少量的開發工作來學習哪些特性將真正驅動我們得到想要的結果。無論我們在哪個過程中學到東西，最關鍵的是我們在這個過程中學習到了東西，而不是預先決定程序並遵循專案計劃。
正確的處理方式
那我們怎麼做呢？如何保持產品開發專注重點？
所有產品和產品管理都涉及一定程度的專案管理。我們必須讓工作進行下去，並且（不幸的是），我們的利益相關者以及合作伙伴一定還是會期待某些日期或承諾。
關鍵是隻有在我們高度自信的情況下才可以做出承諾和專案計劃。因此，我們要在驗證了我們正在做的事情並且有機會真正理解它將採取什麼措施的情況下，作出承諾，而不是事先承諾特定的路徑。通常是在進入工作的衝刺時段。看起來可能有點遲，但正是在那時估算和計劃才真正有意義。Marty Cagan 在他的書《啟示錄：打造使用者喜愛的產品》中稱這種承諾是「高度誠信的承諾」。我們允許團隊在要求承諾之前有時間進行適當的探索和研究。
我們還需要讓其他人瞭解採用產品思維的好處。有很多人要求提供日期和時間表是有原因的。部分原因是因為舊習慣。對於業務和預算來說是必要考慮時間的。因此，在這些情況下，我們需要搞清時間軸的作用。如果是為了幫助銷售產品，我們應該將重點從特定功能提升到更高級別。如果是為了管理風險，也許我們需要幫助人們理解真正的風險並不在於錯過日期，這完全忽視了我們試圖提供的價值。
最後，我們要明白產品開發的目的就是為使用者和消費者創造價值。大多數情況下，我們並不確切地知道什麼會帶來這個價值。如果你在做年度計劃和預算編制時，認為我們可以預先一年提出正確的解決方案，那是非常不現實的。
專案思維的重點是預先提出解決方案，然後按計劃進行交付，但產品思維會將重點放在結果上。這涉及一定程度的不確定性和對學習能力的要求，這可能相當困難。但是，如果我們想要獲得好的結果，而不僅是準時產出，那麼它實際上是唯一的工作方式。
原文： https://productcoalition.com/product-thinking-vs-project-thinking-380692a2d4e
標題：Product Thinking vs. Project Thinking
作者：Kyle Evans
翻譯：趙一凡
（來源：創業孵化機構「光澗實驗室」，公眾號 lightsteam0）