起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品和研發的一點反思：斷裂與分歧、連接與共識、閉環與共享
本文主要是作者反思了他所在團中產品和研發的工作模式與關系，來談談產品與研發中的斷裂與分歧、連接與共識、閉環與共享。
最近，讀了二爺邱岳的《產品手記》專欄，相比較而言梁寧的《產品思維》主要講「道」，而二爺的則主要講「術」。
其中有兩篇講到產品和研發如何打交道，談到了產品和研發不知怎么就形成了一種矛盾與對立的關系，讓我反思了下我所在團隊中產品和研發的工作模式與關系。
斷裂與分歧
一反思我們團隊中產品和研發的關系，幸運的是整體還是比較和諧的，但其中并非不存在問題。
先說一個產品和研發打交道最多的場景 —— 需求評審。在需求評審中，雖然大家并不是針鋒相對、劍撥弩張，搞得像談判一樣，但卻有點像菜市場一般就某個需求點進行討價還價。一旦進入「討價還價」模式，就意味著雙方站在了各自獨立的立場，而非共同的價值和利益出發點了。
產品站在價值方，研發站在成本方。產品代表業務與用戶，對產品功能進行價值判斷并轉化為研發需求。而研發中的個體，也就是程序員會習慣從自身開發成本（好惡、難易）去評估需求，而感覺自身開發成本高（麻煩）時，就容易進入和產品的「討價還價」模式。
這里面的問題就在于——研發沒有習慣優先從需求的價值出發去考慮；而產品的問題在于——絕大部分產品并沒有程序開發背景和經歷，所以有時很難評估清楚，甚至理解完成一個功能需求的研發成本。
產品價值的評估相對主觀，產品有時也可能面臨無法很好評估某個（些）需求的價值，甚至根本就不是從價值點出發，而是對標市場競品，達到別人有的，所以我們也要有的效果。
研發的成本則相對客觀，但研發在評估需求時過于注重個人開發實現的方便性，路徑依賴性，對不確定的技術實施成本有抵觸。
結果，就在這里產生了一個斷裂帶，進而分歧滋生。在這種情況下，如果溝通不當，壞的結果就是：雙方變得對立；而好的結果也不過是各讓一步，妥協折中，變得中庸。
連接與共識
面對這樣的斷裂帶，有沒有可能重建連接與共識？
對于這個問題，套用梁寧《產品思維》中提出的一個用戶體驗 5 層次模型框架來分析下，這個 5 個層次包括：
- 感知層
- 框架層
- 資源層
- 能力層
- 存在層
其中產品的日常工作，大多發生在「感知層」和「框架層」。產品邏輯，交互結構，信息架構等都屬于框架層的工作內容，感知層是產品的展現形態，和五感直接相關，而互聯網產品最重要的感知是視覺。
而研發的日常工作，則大多發生在「資源層」和「能力層」。研發不斷的積累資源、拓展提升能力。具體到研發個體上，資源可以是個人的技能，能力則是解決問題，開發功能的效率和品質。
產品和研發的共同連接點在于「存在層」。存在層研究每一個功能需求的價值與意義，換言之，它確定正確的事。
那何謂正確？
我的答案是做的這件事要有經濟效率，經濟效率即價值大于成本。
按如上正確標準，我們在分析競品的對標功能點時，就需要仔細研究其存在的意義與價值，再來對比我們實現它的成本。有時，完成同樣的功能需求，對于不同的公司、不同的團隊、在不同的階段，其價值和成本都是變化的。
我們只在其具備經濟效率時才去完成它，正所謂：用正確的方式，做正確的事。
但評估是否正確其實是一件極具挑戰的工作，產品經常抱怨的一件事是研發估算工期從來沒準過，基本總延期超時。這體現在對成本的估算上是不準確的，有時搞不好估算和實際的時間能差一倍。
如果用程序算法的時間復雜度來說，一兩倍的時間誤差，基本還算在一個量級的準確度內，不算夸張。
但對業務和產品價值的評估，一開始是非常主觀的，估算誤差搞不好就是量級的差距。比如說吧：業務方有時估計業務上線后，能有百萬日活躍，但最后上線了僅有幾萬日活，這種數量級的估算誤差帶來的研發一次性投入成本浪費也是蠻大的。
對于創新業務，模糊的價值評估，最好的研發投入方式也許可以參考風投的思路。剛開始總是從一個切入點進入，少量資源完成一個最小集的產品形態，上線驗證業務發展情況。
每過一個階段，業務如果發展超預期，第二次迭代就加倍投入；每一輪迭代，只要業務發展超預期，都繼續加重投入比例，最后的結果將是最多的資源，進入發展最快且前景最好的業務上。
所以，進入高階的研發人員（架構師、技術負責人）對成本的估計會更客觀和準確，這時，就需要更多去看那些模糊的價值，考慮研發實施的經濟效率問題。
閉環與共享
有時，某些需求價值和時間有關，要么隨時間衰減，要么在某個時間點前有價值，之后可能就沒價值了。
這樣的需求價值變化，通常和創新業務與市場競爭格局變化有關。面對這類需求，研發去應對的經濟效率問題沖突會更明顯。
在這個過程中，研發形成了兩種協作模式：閉環與共享。
- 閉環：就是和業務需求方綁定，專門做此類變化快的需求開發，其他的都不做；而共享則相反，將研發資源共享成一個池，所有的業務需求也匯總在一個或多個優先級隊列里，排隊開發。
- 共享：有利于充分利用研發資源，規?；?、專業化，提升吞吐，但可能也降低了平均響應時間，更適合于進入成熟期，穩定漸進發展的業務。閉環，優先考慮專屬業務需要的響應，但也失去了規模與專業化效應，更適合快速發展期的創新業務，而過了業務高速期，專屬的研發就會形成資源浪費，對個體的成長也有不利因素。
而在一個大的組織中，很可能就同時存在閉環與共享兩種模式。在這兩種研發模式下，產品和研發該如何做，才能符合經濟效率原則？
先說一個不好的例子：
面對共享模式，大量的業務方因為經常產生需求開發排期沖突。所以，業務為了更多的占住研發資源，會自然產生一種驅動因素——先不管那么多盡量多提需求，而需求本身的意義和價值反而放在了次要位置。
當研發被永遠開發不完的需求隊列壓住，就會本能的拒絕需求，進入「討價還價」模式。而業務熟悉了這套模式后，就會開更高的價等你來還。產品居于其中，需要篩選出符合經濟效率的正確事情，難度則進一步加大。
閉環和共享，沒有絕對的好壞之分，都是相對階段的選擇。如果業務必然走向成熟，那么閉環就會走向共享。共享，依然是能力和資源層的建設，組織的標準化研發輸出能力的形成。
無論研發的組織形態如何變化，我們都要警惕進入「討價還價」模式，它太容易帶來負反饋循環，而負反饋的循環一旦積累成型，要破解它就變成了一個很復雜的系統性問題。
需求似乎永遠開發不完，我們只能努力提升完成的需求中「正確」的比例。
作者：mindwind
原文鏈接：https://www.jianshu.com/p/db06264523d6
本文由 @mindwind 授權發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
現在一個MVP產品很難滿足現在用戶“更”的需求～_～