當產(chǎn)品經(jīng)理和后臺開發(fā)提需求時，本以為小迭代、小需求簡簡單單，但在后臺開發(fā)眼中卻有些麻煩。那么在需求實現(xiàn)的角度上，是什么原因?qū)е碌哪?？我們又該如何從后臺開發(fā)的視角去理解需求的實現(xiàn)過程呢？

在產(chǎn)品同質(zhì)化嚴重的當下，競爭的主戰(zhàn)場早已從產(chǎn)品價值轉(zhuǎn)移到了開發(fā)效率與運營策略。

運營策略經(jīng)過幾番摸爬滾打總能找到節(jié)奏，但開發(fā)效率卻是很難在短時間內(nèi)提升。因為作為一個產(chǎn)品經(jīng)理，你不僅需要了解技術(shù)，用開發(fā)小哥能聽明白的話語描述需求，更重要的是讓技術(shù)團隊與你一條心一起走。

所以一個略懂技術(shù)的產(chǎn)品經(jīng)理會非常占優(yōu)勢。無數(shù)個夜晚，你會不會在月光前發(fā)愿，要是技術(shù)小哥每次對我說這句話就好了：這個需求很清晰，我們隔天就能上線。

可殘酷的現(xiàn)實，就像你的丈母娘一樣總在啪啪打你的臉：

• 你認為“很簡單”的小需求，開發(fā)小哥評估至少要N天才能完成；
• 明明別人都已經(jīng)實現(xiàn)的功能，怎么在我們這里就實現(xiàn)不了了？
• 你認為只是優(yōu)化的小迭代，在開發(fā)小哥這里怎么就變成了動架構(gòu)了？

今天麗莎阿姨就要帶著你一起走進后臺技術(shù)小哥的內(nèi)心世界，一起去開悟之坡~

01 一個需求，后臺到底在做什么？

舉個例子：一個英語學習的APP，我們希望用戶發(fā)布了錄音后，可以讓他的粉絲也能看到他發(fā)布的錄音。

在這個看似簡單的需求里，后臺開發(fā)會如何處理這些數(shù)據(jù)呢？

• 第一步，將流程里包含的信息拆解為：用戶（小A、小B）、行為（錄音、發(fā)布、收聽）、數(shù)據(jù)（讀音）
• 第二步，維護好用戶數(shù)據(jù)，確保在需要的時候可以快速地訪問到。

這下你明白了嗎？當你在表達一個需求的時候，其實是在描述一個現(xiàn)象，而后臺小哥就會把這個現(xiàn)象結(jié)構(gòu)化地拆解為：用戶、行為、數(shù)據(jù)以及之間的運轉(zhuǎn)邏輯。

所以在今后的需求溝通中，我們不妨也可以提前做一下這樣的拆解，這樣溝通效率就會大大提升了。

02 這個需求很簡單，為什么要開發(fā)N天？

某一天，你跟開發(fā)小哥說：既然我們已經(jīng)實現(xiàn)了粉絲可以聽到錄音，那么再增加一個粉絲可以看到視頻的功能吧，這個需求應該很簡單，交互邏輯之前都是一樣的，是不是很快就能上線呀？

開發(fā)小哥一番評審告訴你：2天~

此時在你心里是不是覺得：不是一樣的東西嗎？好像半天就能搞定的事情，為啥要花兩天？

那么這兩天后臺小哥到底在做什么呢？

在我們看來錄音和視頻現(xiàn)象都是一致的，但在后臺小哥的開發(fā)中是非常不同的。前文提到，后臺開發(fā)主要是處理用戶行為，維護用戶數(shù)據(jù)，這個不同就是在于數(shù)據(jù)上。

如果最開始開發(fā)沒有考慮擴容性，那么錄音數(shù)據(jù)與視頻數(shù)據(jù)就是兩個截然不同的接口，所以開發(fā)周期當然是一樣的。

但是，如果我們在一開始就告訴開發(fā)小哥，未來業(yè)務(wù)的邏輯是需要支持錄音也有可能支持視頻的，這種情況下，數(shù)據(jù)接口就可以在一開始的時候就做好適配設(shè)計。

什么叫適配設(shè)計，其實就是增加一個數(shù)據(jù)適配器（類似電腦的轉(zhuǎn)接頭），讓功能可以支持更多類型的數(shù)據(jù)。

這樣一對比，我們就知道了：

• 同樣的需求，如果開發(fā)方式是，來一個需求做一個需求，那么開發(fā)時間是：2 天錄音 + 2 天視頻 = 4 天
• 如果一開始就告訴開發(fā)小哥未來業(yè)務(wù)可能的擴展性，一開始就考慮了數(shù)據(jù)接口適配，那么總體的開發(fā)時間是：2 天錄音 + 0.5 天擴展性 + 0.5天視頻 = 3 天

怎么樣？以后不要再抱怨你們開發(fā)小哥能力不行或者效率太低了哦。最根本的原因還是在于產(chǎn)品經(jīng)理是否足夠有預見性與規(guī)劃性。

03 為什么同樣的功能，體驗總是不盡如人意？

還是前面的例子，讓粉絲聽到關(guān)注者的錄音的功能。有時候你發(fā)現(xiàn)，完全一樣的功能，在人家的產(chǎn)品上和自己的產(chǎn)品上體驗怎么會差很多？好像我們的頁面總是不那么順滑，那真正的原因到底是什么？

其實主要的問題就出在開發(fā)方式上：

開發(fā)方式A：用戶點擊發(fā)布錄音，后臺保存錄音，并為每個粉絲逐個生成數(shù)據(jù)，然后通知用戶發(fā)布成功。

從邏輯上來看流程很簡單，速度應該很快?？墒?，一旦這個用戶擁有百萬粉絲，那么② ~ ④ 的過程變?yōu)樾枰o百萬粉絲都生成完數(shù)據(jù)后，再反饋用戶成功，這中間的等待時間非常非常非常長，這個時候你不慢誰慢？

而開發(fā)方式B：用戶點擊發(fā)布錄音，后臺保存錄音，立刻反饋用戶發(fā)布成功。然后，再逐個為粉絲生成數(shù)據(jù)，通知粉絲。

妙就妙在，這個過程中，我們將粉絲收到錄音過程的實時性舍棄掉了，而發(fā)布錄音者卻能很快得到反饋，在使用感官上，體驗就非常棒了。

明白了嗎？同樣的功能，如果你能清晰的交代清楚，哪些場景是需要實時的，哪些場景是不需要實時的，用戶量的情況等等，開發(fā)小哥就可以引入異步化或者其他的開發(fā)方式，極大地優(yōu)化產(chǎn)品的用戶體驗。

04 功能剛上線響應還很快，后來怎么逐漸變慢了？

還是這個錄音數(shù)據(jù)的例子，這個功能上線一段時間之后，突然某一天有用戶反饋說，怎么加載越來越慢了？前兩天還好好的呀，問題又出在了哪里？

其實，主要的問題是出在數(shù)據(jù)量上。我們再回歸到功能本身，一個有百萬粉絲的大V發(fā)布錄音，那么產(chǎn)生的數(shù)據(jù)量 = 錄音數(shù) * 100萬，這個過程中數(shù)據(jù)膨脹是非?？斓摹?/p>

如果你要去查詢數(shù)據(jù)，就必須從1~100w一個一個去查，就算你把數(shù)據(jù)進行了分類檢索，還是會不可避免的慢。

如果，我們改變一下開發(fā)方式，同樣的錄音，我們只把數(shù)據(jù)推給近期活躍的用戶，而對于不活躍用戶，我們在他上線時再推，情況會不會好很多呢？

根據(jù)早些年新浪微博和騰訊微博的用戶分析結(jié)果，大V的僵尸粉或不活躍用戶占比均達到16.96%和56.73%，這部分僵尸粉基本不上線，或者不查看信息。使用這種方案，可以極大地減緩數(shù)據(jù)膨脹的速度，實際產(chǎn)生的數(shù)據(jù)量會指數(shù)級下降。

所以，明白了嗎？一個功能慢或者不慢，其實主要差距就是在對數(shù)據(jù)的處理方式上，一個優(yōu)秀的產(chǎn)品經(jīng)理，如果能了解這部分原理，就能與開發(fā)小哥一起設(shè)計一款體驗良好，并且維護成本極低的產(chǎn)品。

05 增加一個小功能，開發(fā)小哥怎么看起來很為難？

有沒有試過，當你與開發(fā)小哥提一個你看起來覺得很小的需求時，他們會滿臉畏難：這不好搞啊~代碼改起來非常惡心。

惡心？why？

其實就像下面這兩個例子，A、B分別代表了兩個功能的代碼邏輯，這時有一個需求，需要在流程結(jié)束前，增加一個操作。

這個時候你會有什么感受？哈哈哈~~

在代碼流程A里，需要在4個不同的部分增加這個操作，而代碼流程B，只需要增加1個操作，這就是為什么代碼改得很“惡心”的主要原因。因為如果一開始代碼流程邏輯就是混亂的，新需求會變得非常復雜且繁多。

同樣是開發(fā)功能、寫代碼，為什么會導致這樣的差別呢？主要原因以下3點：

1. 功能設(shè)計不合理，代碼邏輯不清晰，擴展性差
2. 業(yè)務(wù)迭代，功能不斷更新，模塊逐漸臃腫
3. 時間不夠，先上線、后優(yōu)化

對，你想的沒錯，其實就是代碼寫得“差”，敞開你的嗓子，放心地懟開發(fā)小哥就好，哈哈哈哈~

相信阿姨，把這篇文章看明白，拿著需求好好評審，“怒懟”開發(fā)小哥一百遍。

孫子曰：用兵者，役不再籍，糧不三載。一次把事情做對，一次搞定，不返工，就是最高的效率，一起加油哦~

作者：Lisa?Deng；公眾號：麗莎D的產(chǎn)品手記

本文由 @Lisa?Deng 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議