研發(fā)也要管需求嗎？

因為職業(yè)和崗位的關系，產品經理和技術開發(fā)之間似乎是天生的冤家。我們經常聽說產品經理和開發(fā)之間的“恩怨情仇”，心情手機殼、刀砍產品經理等這些流傳的梗更給了這層微妙關系一些代入感。

雖然在現實中產品經理并不會提那么不靠譜的需求，技術開發(fā)也不會對產品經理恨之入骨，但工作的交集還是把雙方限定在“角斗場”內，任憑他們來回撕扯。而這其中拉扯的焦點就是產品需求。

網上流傳過這樣一個段子。

賓館老板發(fā)現最近大學生顧客越來越多，敏銳地發(fā)現了新的商機。

他深刻地“洞察”了用戶的需求。

最后成功地倒閉了。

你看到的現象可能是真實的，但總結出來的需求卻可能會說謊。如果你的產品經理是這樣的“敏銳”，還是非常有必要辨別需求的真?zhèn)巍?/span>

段子只是個笑話，相比現實過于夸張。但現實可能會更加復雜。

在程序員眼中，產品經理會更傾向于邏輯不強、天馬行空的類型。但隨著產品經理崗位專業(yè)度的提升，以及雙方長時間磨合，產品經理提出的需求并非像以前那樣一眼就看出是否靠譜。

那作為思維縝密的研發(fā)人員，怎么才能判斷產品需求是否靠譜呢？

產品需求的產生過程已經足夠成熟。需求工程中的業(yè)務調研、業(yè)務分析、業(yè)務架構、需求建模等都是需求產生的專業(yè)方法。越是龐大、復雜的需求越需要這些過程方法和標準產出物。

研發(fā)人員判斷需求是否靠譜，第一步就是判斷需求有沒有這些過程。

再專業(yè)的學科和方法在實際場景中都會產生偏差。即便經過專業(yè)的需求分析全過程，產品需求也不一定就是最完美的解決方案。

判斷需求是否靠譜，第二步是做需求驗證。

需求驗證就是將解決問題的設計方案放到實際場景中，看看原來的問題是否能被很好的解決。這其中包括需求原型驗證、產品MVP和快速迭代。

多數研發(fā)人員的邏輯思維強于感性思維。在需求驗證環(huán)節(jié)，需要研發(fā)人員跳出邏輯思維的限制，多考慮、模擬、體驗需求在用戶的真實場景。只有身臨其境，才能去偽存真。

除了常規(guī)的需求甄別方式，還有一種新技術驅動的偽需求。

2013年，手機QQ團隊推出了4.0版本。團隊經過徹夜奮戰(zhàn)，終于在5月份上線了4.0版本。但是上線后在 AppStore 新版本 3 萬多條用戶評論中，有 90% 的用戶給出了一星。這可以說是當時手機 QQ 團隊遭遇的最大一次用戶危機。

原來在新版本中，由于去掉了QQ在線狀態(tài)的區(qū)分顯示，曾經習慣在 PC 端 QQ 上看到在線狀態(tài)的用戶表示極度不習慣。于是就有了90%差評的一幕。

之所以去掉在線狀態(tài)的區(qū)分，是因為在新的技術加持下，移動互聯網的特征之一就是「Always Online」。即使一個用戶此時此刻沒有使用手機 QQ，但他依然能夠通過系統(tǒng)提醒方便地收取消息。因此，手機QQ就不再需要是否在線這樣的狀態(tài)顯示。

技術成熟，理念正確，符合場景，順應趨勢，為什么用戶還是不接受呢？原來在QQ這樣龐大用戶群體的產品場景下，團隊忽視了「用戶習慣」的強大慣性以及舊有體驗龐大的用戶基礎。

這樣的案例并非罕見。早在2000年，微軟研發(fā)Windows me 時也陷入了同樣的誤區(qū)?？梢詤⒖?a target="_blank" textvalue="《一款優(yōu)秀的產品是如何誕生的》" linktype="text" imgurl="" imgdata="null" data-itemshowtype="0" tab="innerlink" data-linktype="2">《一款優(yōu)秀的產品是如何誕生的》這篇文章。

原以為引入新技術、解決更多的問題是好事，但結果卻事與愿違。研發(fā)技術人員尤其要注意避免這種誤區(qū)。用戶需求的管理需要慎之又慎。

關注我們，辨別需求