說起來都是老生常談，不過溫故而知新，很多內容我自己都找不到哪篇舊文寫過，更不用說有很多新讀者。
我一直強調研發人員要具有產品觀，那麼偶爾在朋友圈看到一些創業團隊分享的經驗，也不斷地佐證這個觀點。
為什麼不斷提這個話題，研發人員為什麼需要有產品觀，因為很多情況下，研發效率低，並不是研發人員不夠努力，也並不是研發人員水平太低，而是他們在理解需求的時候出現了偏差，容易過度設計，或者無法做到抓大放小，在低價值的訴求上浪費了太多時間和精力。
對於創業公司而言，這樣的情況，往往是致命的，因為創業團隊並不具備高度冗餘的技術資源，如果無法實現高效率低成本的研發，那麼面對巨頭圍剿，勝算極低。
那有人會說，我就是一個研發，產品經理給我需求我就完成，如果存在需求不明，存在主次不分，難道不是產品經理的責任麼？
這就是我舊文不斷強調的另一個話題，所謂職場的容錯性，產品經理固然要強化自己對需求的精確描述能力和主次的區分能力，但如果研發也具有足夠的產品觀，溝通成本會更低，而且可以更好的對產品人員容錯，坦白說，對於大部分創業公司而言，一個具有非常成熟研發管理能力和經驗的產品經理幾乎是不太可能出現的（其實巨頭裡，能把研發管理做到位的產品經理也是鳳毛麟角的），大部分產品經理僅僅能從功能角度描述需求，而這，其實是遠遠不夠的。
那麼，研發人員如何才算擁有產品觀，或者說，我認為一個優秀的研發人員應該有怎樣的產品素質。
1、對業務好奇。
好奇心是驅動一切的基礎。
你做出的產品，在業務上表現是怎樣的，公司的產品，業務的邏輯是怎樣的。
能夠理解代碼邏輯，沒理由理解不了業務邏輯。
好奇之後才是探索，通過搜索引擎，通過財經網站，查閱行業內領軍企業的財報，業務構成。主要競品公司的業務數據，對比自己公司的業務數據，分析其中異同，尋找業務關鍵要素。
2、信息交叉。
這是一個很簡單的邏輯，你看到很多不同口徑，不同統計的數據，其實組合計算，會得到很多有意思的數據。
比如說，最簡單的邏輯，知道了收入，知道了活躍用戶數，就應該算出來單位用戶的價值對不對，如果你知道A產品的收入和活躍用戶數，B產品的收入和活躍用戶數，那麼是否有意識對比一下二者的活躍用戶價值呢？
很多有價值的數據是通過不同數據的交叉計算得出來的，不要什麼都等着別人餵給你，自己要有敏感度，不斷養成自己校驗計算的習慣。
網上很多第三方的數據一看就是錯的，因為很多數據禁不起交叉計算，算出來的結果很離譜。但很多人為什麼深信不疑，因為他們沒有這方面的意識。
信息交叉可以更好的認識業務的不同層面和不同表現，可以在互聯網上大量碎片信息的情況下，自行補全很多關鍵業務信息。
3、了解需求背景和目標。
這點非常重要，需求不只是功能的羅列，這個需求提出的背景是什麼，要解決的目標是什麼。
理解這些才能和更好的理解需求，並做出合適的處理，比如哪些是重要的，哪些是次要的，哪些是需要高精度高可靠性的，哪些是容錯空間比較大的，這個設計複雜度也會差很多。
4、了解需求邊界。
這個其實舊文也多次提到，什麼是需求邊界，產品人員說，我需要什麼什麼的數據，那麼有時候他們不會說，甩尾信息是沒意義的，什麼是甩尾信息，就是很多長尾數據沒有進一步分析的價值。比如一個遊戲產品單頁昨天的訪問量是5次，今天是10次，增加了一倍，但我需要關心麼，我不關心，這是長尾信息。但如果昨天是5000次，今天是6000次，只增加了20%，我可能依然要關心，因為這個可能是比較重要的遊戲產品。但很多時候，研發人員接到需求的時候，沒有意識到長尾信息是可以丟棄的，甚至是干擾正常分析的。
功能也有邊界，搜索翻頁的例子說的都想吐了，用戶需要搜索翻頁，但並不需要翻超過100頁。
其實這是3的延伸，當你更好的理解需求的目標和背景的時候，可以和產品人員進一步明確需求邊界，哪些是可以捨棄的，哪些是不需要過度細化的，這樣產品設計的複雜度，存儲的開銷，以及各種計算開銷，都可以指數級下降。
是的，當年我寫cnzz的時候，技術水平有限，但是我能用有限的技術實現足夠高的負載和應用表現，其實需求邊界的控制可以說是我擅長的領域。這就是跨界的優勢。
5、了解需求收益，並能正確評估實現成本。
當你確定一個需求，並準備實現方案的時候，問自己兩個問題，第一，你是不是很清楚這個需求對項目，對公司的收益預期是什麼；第二，你是不是很清楚這個需求的實現成本是什麼。
如果實現成本低而收益預期高，這是一個特別容易出成績，特別容易展現效果的工作。當然要儘快實現。但如果實現成本很高，而預期收益很低，那麼就要評估一下，這個需求是否值得，或者是否有簡化的方案。
比如說，產品人員只是臨時性的測試某種奇怪的想法，而技術人員卻制定了兼容性，擴展性都非常深度考慮的複雜方案，這就是常見的過度設計。最可怕的是，產品人員還沒意識到這裡存在溝通的偏差，不知道研發開銷，從而導致一些關鍵需求被壓制，被拖累。
6、了解你的產品經理，或者說需求提供者。
這也很重要，職場很多是人與人的溝通，有的產品經理思路明確，邏輯清晰；有的產品經理可能就欠缺一些。
有的產品經理有技術背景，溝通起來會容易一些，有的產品經理因為缺乏相關技術背景，很容易低估或高估技術實現成本。
有的產品經理的目標感很清晰，懂得抓大放小，懂得優先級順序；有的產品經理可能急於證明自己，容易過度加戲，用大量的需求文檔證明自己的努力和想法的豐富度，導致研發疲於應付。
有些時候，一些創業公司甚至根本就沒有所謂產品經理，業務人員直接提需求，更容易出現混亂的情況，甚至同一個基本需求，不同的業務人員會有不同的提法和訴求，隨着人員流動，需求也會隨之大幅度的變更，這種情況下，如果研發一昧的被動接受，更容易疲於應付，難以發揮真實的產品價值。
你面對的需求提供者是怎樣的人，他提供需求的時候，他自己的訴求是什麼，他的表達和描述是否是足夠準確的，作為研發人員，如果你能更好的去理解需求方，作為個體的訴求，（理論上，需求方的訴求就是業務上訴求，但在實際場合中，也會夾雜很多個人的訴求），那麼溝通過程可能會有不同的指向，在設計原則上也可能會有很多不同的處理思路。
很多時候，甚至可以說是大部分情況下，研發人員自以為已經了解了需求，但沒有深究一步，沒有更多思考這個需求定義背後的邏輯，那麼在實現過程中，就容易出現，依賴腦補，過度設計，或者放錯重心，甚至可能被一些含糊不清，模稜兩可的信息所誤導。
大部分研發的時間浪費在了不必要的事情上，是的，根據我的觀察，這是很多公司的常態，而這種不必要，第一來自於溝通的不充分；第二也來自於研發對業務訴求的誤判。
那麼擁有足夠的產品觀又如何，有人會說，你最後不還是要聽產品經理的？或者還會有人疑惑，研發有產品觀，還要產品經理幹什麼？
1、產品經理要提出正確的問題，找到正確的方向。這個要求是很高的，而研發的產品觀主要目標在於正確的理解需求。所以不用過於擔心懂了業務就會去搶產品經理的飯碗，當然如果你說有個例，研發成長為產品大牛，我不敢說我是，但我必須說這個路線是有的。
2、研發的產品認知與產品經理產生衝突的時候，在很多時候，是可以通過進一步協商處理的。實際上，一個公司有產品意識的老研發，比新來的產品經理更懂公司業務，是很合理的，新產品經理如果提出一些不靠譜的訴求，被老研發懟回去，並不是什麼壞事。
3、產品經理如何獲得研發的信任，如何讓研發更好的聽從自己的安排，這是另一個話題，本文不討論，不過有興趣的可以看看這篇 ->明明有本事，為什麼難升職？關於信任基礎，其實說的幾乎是一回事。
留言列表