當產品經理和後臺開發提需求時，本以為小迭代、小需求簡簡單單，但在後臺開發眼中卻有些麻煩。那麼在需求實現的角度上，是什麼原因導致的呢？我們又該如何從後臺開發的視角去理解需求的實現過程呢？
在產品同質化嚴重的當下，競爭的主戰場早已從產品價值轉移到了開發效率與運營策略。
運營策略經過幾番摸爬滾打總能找到節奏，但開發效率卻是很難在短時間內提升。因為作為一個產品經理，你不僅需要了解技術，用開發小哥能聽明白的話語描述需求，更重要的是讓技術團隊與你一條心一起走。
所以一個略懂技術的產品經理會非常佔優勢。無數個夜晚，你會不會在月光前發願，要是技術小哥每次對我說這句話就好了：這個需求很清晰，我們隔天就能上線。
可殘酷的現實，就像你的丈母孃一樣總在啪啪打你的臉：
- 你認為“很簡單”的小需求，開發小哥評估至少要N天才能完成；
- 明明別人都已經實現的功能，怎麼在我們這裡就實現不了了？
- 你認為只是優化的小迭代，在開發小哥這裡怎麼就變成了動架構了？
今天麗莎阿姨就要帶著你一起走進後臺技術小哥的內心世界，一起去開悟之坡~
01 一個需求，後臺到底在做什麼？
舉個例子：一個英語學習的APP，我們希望用戶發佈了錄音後，可以讓他的粉絲也能看到他發佈的錄音。
在這個看似簡單的需求裡，後臺開發會如何處理這些數據呢？
- 第一步，將流程裡包含的信息拆解為：用戶（小A、小B）、行為（錄音、發佈、收聽）、數據（讀音）
- 第二步，維護好用戶數據，確保在需要的時候可以快速地訪問到。
這下你明白了嗎？當你在表達一個需求的時候，其實是在描述一個
現象，而後臺小哥就會把這個現象結構化地拆解為：用戶、行為、數據以及之間的運轉邏輯。所以在今後的需求溝通中，我們不妨也可以提前做一下這樣的拆解，這樣溝通效率就會大大提升了。
02 這個需求很簡單，為什麼要開發N天？
某一天，你跟開發小哥說：既然我們已經實現了粉絲可以聽到錄音，那麼再增加一個粉絲可以看到視頻的功能吧，這個需求應該很簡單，交互邏輯之前都是一樣的，是不是很快就能上線呀？
開發小哥一番評審告訴你：2天~
此時在你心裡是不是覺得：不是一樣的東西嗎？好像半天就能搞定的事情，為啥要花兩天？
那麼這兩天後臺小哥到底在做什麼呢？
在我們看來錄音和視頻現象都是一致的，但在後臺小哥的開發中是非常不同的。前文提到，後臺開發主要是處理用戶行為，維護用戶數據，這個不同就是在於數據上。
如果最開始開發沒有考慮擴容性，那麼錄音數據與視頻數據就是兩個截然不同的接口，所以開發週期當然是一樣的。
但是，如果我們在一開始就告訴開發小哥，未來業務的邏輯是需要支持錄音也有可能支持視頻的，這種情況下，數據接口就可以在一開始的時候就做好
適配設計。什麼叫適配設計，其實就是增加一個數據適配器（類似電腦的轉接頭），讓功能可以支持更多類型的數據。
這樣一對比，我們就知道了：
- 同樣的需求，如果開發方式是，來一個需求做一個需求，那麼開發時間是：2 天錄音 + 2 天視頻 = 4 天
- 如果一開始就告訴開發小哥未來業務可能的擴展性，一開始就考慮了數據接口適配，那麼總體的開發時間是：2 天錄音 + 0.5 天擴展性 + 0.5天視頻 = 3 天
怎麼樣？以後不要再抱怨你們開發小哥能力不行或者效率太低了哦。最根本的原因還是在於產品經理是否足夠有預見性與規劃性。
03 為什麼同樣的功能，體驗總是不盡如人意？
還是前面的例子，讓粉絲聽到關注者的錄音的功能。有時候你發現，完全一樣的功能，在人家的產品上和自己的產品上體驗怎麼會差很多？好像我們的頁面總是不那麼順滑，那真正的原因到底是什麼？
其實主要的問題就出在開發方式上：
開發方式A：用戶點擊發布錄音，後臺保存錄音，併為每個粉絲逐個生成數據，然後通知用戶發佈成功。
從邏輯上來看流程很簡單，速度應該很快。可是，一旦這個用戶擁有
百萬粉絲，那麼② ~ ④ 的過程變為需要給百萬粉絲都生成完數據後，再反饋用戶成功，這中間的等待時間非常非常非常長，這個時候你不慢誰慢？
而開發方式B：用戶點擊發布錄音，後臺保存錄音，立刻反饋用戶發佈成功。然後，再逐個為粉絲生成數據，通知粉絲。
妙就妙在，這個過程中，我們將粉絲收到錄音過程的實時性 捨棄掉了，而發佈錄音者卻能很快得到反饋，在使用感官上，體驗就非常棒了。
明白了嗎？同樣的功能，如果你能清晰的交代清楚，哪些場景是需要實時的，哪些場景是不需要實時的，用戶量的情況等等，開發小哥就可以引入異步化或者其他的開發方式，極大地優化產品的用戶體驗。
04 功能剛上線響應還很快，後來怎麼逐漸變慢了？
還是這個錄音數據的例子，這個功能上線一段時間之後，突然某一天有用戶反饋說，怎麼加載越來越慢了？前兩天還好好的呀，問題又出在了哪裡？
其實，主要的問題是出在數據量上。我們再回歸到功能本身，一個有百萬粉絲的大V發佈錄音，那麼產生的數據量 = 錄音數 * 100萬，這個過程中數據膨脹是非常快的。
如果你要去查詢數據，就必須從1~100w一個一個去查，就算你把數據進行了分類檢索，還是會不可避免的慢。
如果，我們改變一下開發方式，同樣的錄音，我們只把數據推給近期活躍的用戶，而對於不活躍用戶，我們在他上線時再推，情況會不會好很多呢？
根據早些年新浪微博和騰訊微博的用戶分析結果，大V的殭屍粉或不活躍用戶佔比均達到16.96%和56.73%，這部分殭屍粉基本不上線，或者不查看信息。使用這種方案，可以極大地減緩數據膨脹的速度，實際產生的數據量會指數級下降。
所以，明白了嗎？一個功能慢或者不慢，其實主要差距就是在對數據的處理方式上，一個優秀的產品經理，如果能瞭解這部分原理，就能與開發小哥一起設計一款體驗良好，並且維護成本極低的產品。
05 增加一個小功能，開發小哥怎麼看起來很為難？
有沒有試過，當你與開發小哥提一個你看起來覺得很小的需求時，他們會滿臉畏難：這不好搞啊~代碼改起來非常噁心。
噁心？why？
其實就像下面這兩個例子，A、B分別代表了兩個功能的代碼邏輯，這時有一個需求，需要在流程結束前，增加一個操作。
這個時候你會有什麼感受？哈哈哈~~
在代碼流程A裡，需要在4個不同的部分增加這個操作，而代碼流程B，只需要增加1個操作，這就是為什麼代碼改得很“噁心”的主要原因。因為如果一開始代碼流程邏輯就是混亂的，新需求會變得非常複雜且繁多。
同樣是開發功能、寫代碼，為什麼會導致這樣的差別呢？主要原因以下3點：
- 功能設計不合理，代碼邏輯不清晰，擴展性差
- 業務迭代，功能不斷更新，模塊逐漸臃腫
- 時間不夠，先上線、後優化
對，你想的沒錯，其實就是代碼寫得“差”，敞開你的嗓子，放心地懟開發小哥就好，哈哈哈哈~
相信阿姨，把這篇文章看明白，拿著需求好好評審，“怒懟”開發小哥一百遍。
孫子曰：用兵者，役不再籍，糧不三載。一次把事情做對，一次搞定，不返工，就是最高的效率，一起加油哦~
作者：Lisa Deng；公眾號：麗莎D的產品手記
本文由 @Lisa Deng 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議
