最近，讀了二爺邱嶽的《產品手記》專欄，相比較而言梁寧的《產品思維》主要講「道」，而二爺的則主要講「術」。

其中有兩篇講到產品和研發如何打交道，談到了產品和研發不知怎麽就形成了一種矛盾與對立的關系，讓我反思了下我所在團隊中產品和研發的工作模式與關系。

斷裂與分歧

一反思我們團隊中產品和研發的關系，幸運的是整體還是比較和諧的，但其中並非不存在問題。

先說一個產品和研發打交道最多的場景 —— 需求評審。在需求評審中，雖然大家並不是針鋒相對、劍撥弩張，搞得像談判一樣，但卻有點像菜市場一般就某個需求點進行討價還價。一旦進入「討價還價」模式，就意味著雙方站在了各自獨立的立場，而非共同的價值和利益出發點了。

產品站在價值方，研發站在成本方。

產品代表業務與用戶，對產品功能進行價值判斷並轉化為研發需求。而研發中的個體，也就是程序員會習慣從自身開發成本（好惡、難易）去評估需求，而感覺自身開發成本高（麻煩）時，就容易進入和產品的「討價還價」模式。

這裏面的問題就在於，研發沒有習慣優先從需求的價值出發去考慮；而產品的問題在於，絕大部分產品並沒有程序開發背景和經歷，所以有時很難評估清楚，甚至理解完成一個功能需求的研發成本。

產品價值的評估相對主觀，產品有時也可能面臨無法很好評估某個（些）需求的價值，甚至根本就不是從價值點出發，而是對標市場競品，達到別人有的，所以我們也要有的效果。

研發的成本則相對客觀，但研發在評估需求時過於註重個人開發實現的方便性，路徑依賴性，對不確定的技術實施成本有抵觸。

結果，就在這裏產生了一個斷裂帶，進而分歧滋生。在這種情況下，如果溝通不當，壞的結果就是，雙方變得對立；而好的結果，也不過是各讓一步，妥協折中，變得中庸。

連接與共識

面對這樣的斷裂帶，有沒有可能重建連接與共識？

對於這個問題，套用梁寧《產品思維》中提出的一個用戶體驗 5 層次模型框架來分析下，這個 5 個層次包括：

• 感知層
• 框架層
• 資源層
• 能力層
• 存在層

其中產品的日常工作，大多發生在「感知層」和「框架層」。產品邏輯，交互結構，信息架構等都屬於框架層的工作內容，感知層是產品的展現形態，和五感直接相關，而互聯網產品最重要的感知是視覺。

而研發的日常工作，則大多發生在「資源層」和「能力層」。研發不斷的積累資源、拓展提升能力。具體到研發個體上，資源可以是個人的技能，能力則是解決問題，開發功能的效率和品質。

產品和研發的共同連接點在於「存在層」。存在層研究每一個功能需求的價值與意義，換言之，它確定正確的事。那何謂正確？我的答案是做的這件事要有經濟效率；經濟效率即價值大於成本。

按如上正確標準，我們在分析競品的對標功能點時，就需要仔細研究其存在的意義與價值，再來對比我們實現它的成本。有時，完成同樣的功能需求，對於不同的公司、不同的團隊、在不同的階段，其價值和成本都是變化的。

我們只在其具備經濟效率時才去完成它，正所謂：用正確的方式，做正確的事。

但評估是否正確其實是一件極具挑戰的工作。產品經常抱怨的一件事是研發估算工期從來沒準過，基本總延期超時。這體現在對成本的估算上是不準確的，有時搞不好估算和實際的時間能差一倍。如果用程序算法的時間復雜度來說，一兩倍的時間誤差，基本還算在一個量級的準確度內，不算誇張。

但對業務和產品價值的評估，一開始是非常主觀的，估算誤差搞不好就是量級的差距。比如說吧，業務方有時估計業務上線後，能有百萬日活躍，但最後上線了僅有幾萬日活。這種數量級的估算誤差帶來的研發一次性投入成本浪費也是蠻大的。

對於創新業務，模糊的價值評估，最好的研發投入方式也許可以參考風投的思路。剛開始總是從一個切入點進入，少量資源完成一個最小集的產品形態，上線驗證業務發展情況。每過一個階段，業務如果發展超預期，第二次叠代就加倍投入；每一輪叠代，只要業務發展超預期，都繼續加重投入比例，最後的結果將是最多的資源，進入發展最快且前景最好的業務上。

所以，進入高階的研發人員（架構師、技術負責人）對成本的估計會更客觀和準確，這時，就需要更多去看那些模糊的價值，考慮研發實施的經濟效率問題。

閉環與共享

有時，某些需求價值和時間有關；要麽隨時間衰減，要麽在某個時間點前有價值，之後可能就沒價值了。

這樣的需求價值變化，通常和創新業務與市場競爭格局變化有關。面對這類需求，研發去應對的經濟效率問題沖突會更明顯。在這個過程中，研發形成了兩種協作模式：閉環與共享。

閉環，就是和業務需求方綁定，專門做此類變化快的需求開發，其他的都不做；而共享則相反，將研發資源共享成一個池，所有的業務需求也匯總在一個或多個優先級隊列裏，排隊開發。

共享，有利於充分利用研發資源，規模化、專業化，提升吞吐，但可能也降低了平均響應時間，更適合於進入成熟期，穩定漸進發展的業務。閉環，優先考慮專屬業務需要的響應，但也失去了規模與專業化效應，更適合快速發展期的創新業務，而過了業務高速期，專屬的研發就會形成資源浪費，對個體的成長也有不利因素。

而在一個大的組織中，很可能就同時存在閉環與共享兩種模式。在這兩種研發模式下，產品和研發該如何做，才能符合經濟效率原則？先說一個不好的例子。

面對共享模式，大量的業務方因為經常產生需求開發排期沖突。所以，業務為了更多的占住研發資源，會自然產生一種驅動因素：先不管那麽多盡量多提需求。而需求本身的意義和價值反而放在了次要位置。

當研發被永遠開發不完的需求隊列壓住，就會本能的拒絕需求，進入「討價還價」模式；而業務熟悉了這套模式後，就會開更高的價等你來還。產品居於其中，需要篩選出符合經濟效率的正確事情，難度則進一步加大。

閉環和共享，沒有絕對的好壞之分，都是相對階段的選擇。如果業務必然走向成熟，那麽閉環就會走向共享。共享，依然是能力和資源層的建設，組織的標準化研發輸出能力的形成。

無論研發的組織形態如何變化，我們都要警惕進入「討價還價」模式，它太容易帶來負反饋循環，而負反饋的循環一旦積累成型，要破解它就變成了一個很復雜的系統性問題。

...

需求似乎永遠開發不完，我們只能努力提升完成的需求中「正確」的比例。

寫點文字，畫點畫兒，記錄成長瞬間。
微信公眾號「瞬息之間」，既然遇見，不如同行。

產品和研發，斷裂與連接