産品經理，尤其是B端産品經理，是需要懂技術的，否則在方案設計和方案取舍上以及和RD的溝通上，都會吃虧。下文模拟了兩個場景對話，向大家演示了這個問題。

情景對話1：RD和不懂技術的産品經理小王

小王：一名工作1年的初級産品經理，非計算機科班出身，不懂技術。

老李：一名工作5年的RD，經驗相對豐富，做事相對保守。

（在老李工位前面，對話開始了。）

小王：“老李啊，找你聊個需求。咱們的分銷運營管理後台上線了，業務人員中的新人比較多，我們想在管理後台的知識搜索功能中（畫外音：案例中後台系統的搜索功能調用的是知識庫系統的搜索引擎，分銷運營管理後台本身沒有搜索功能）加一個熱詞推薦的功能，也就是點擊搜索框後，會彈出一些推薦的熱詞，這些熱詞是管理員在後台配置的。你看看，效果圖類似這樣（見下圖的右上角）。”

老李：“嗯嗯，聽起來比較合理，功能也是一個常規标準功能。後台怎麼管理呢？”

小王：“我已經設計好啦，有一個熱詞管理頁面，你瞅瞅，就是這樣的（下圖），能添加、删除熱詞，還能調整熱詞的順序，功能強大！”

老李：“嗯……看起來設計得中規中矩，但是有必要這麼複雜嗎？”

小王：“這個功能設計得多講究啊，絕對好使。做這個大概需要多久啊？”

老李：“呃，那就這樣吧。這個功能想要做出來，預計前端開發需要5人日，後端開發需要10人日，測試需要5人日，總共預估20人日。”

小王：“啥？這麼簡單的功能，要20人日，你在坑我嗎！？”

老李（有點生氣）：“什麼叫坑你，我是實事求是地評估！”

小王：“不就是配幾個詞，然後用戶搜索的時候提示一下嗎？怎麼需要20人日？你給我講講憑什麼，講不清楚我就找你領導！”

老李（愠怒）：“愛找不找随便你，不過我跟你說清楚，實現你這個設計就需要20人日。首先實現熱詞配置表需要設計數據庫表結構，然後要做各種代碼讀寫數據庫的處理，還有，前端要實現完整的增删改查操作，交互點非常多，編輯按鈕、删除按鈕、調整位置，這些都要處理！”

小王：“我不管，我的訴求很簡單，就是能配置熱詞，能調順序，為什麼這點訴求都要開發20人日！”

老李（歎了口氣）：“你是不是想盡快上線？”

小王：“當然！多簡單的功能！”

老李：“小夥子，是否簡單，不是你說了算的，你都不理解背後需要做哪些工作。我問你，不就是配一張熱詞表麼，你看這樣做行不行，就一個文本框，一行一個詞，要調整順序什麼的直接編輯這段文字就可以，想要增加或删除熱詞，都通過編輯這段文字來實現（下圖）。”

小王（遲疑并思索）：“這個，好像也可以，操作也不複雜，并且完全滿足訴求。這樣做需要多久？”

老李：“這樣做的話，不需要設計數據庫，隻保存一個文本文件，前端控件也非常簡單，預計前端開發需要2人日，後端開發需要1人日，測試需要0.5人日，總共3.5人日吧。”

小王（有點不好意思）：“那要不就按您這個設計來吧，咱效率第一。”

老李：“小夥子，可以可以，知錯就改，聽得進去建議。”

小王：“還有一個問題，可以統計不同熱詞的點擊量吧？”

老李：“呃，按照我給的設計方案，有點麻煩。因為這個方案中熱詞的配置是按照文本存儲的，如果想記錄每個詞的點擊數量，必須對文本進行解析，并且記錄每個單詞及其對應的點擊量，處理邏輯又會變得非常複雜。”

小王：“那怎麼辦？我要統計熱詞點擊量啊！”

老李心想：你咋啥都不會，都讓我幫你想方案，那我直接和業務對接好了，要産品經理幹啥？

但是，老李嘴上說道：“哎！年輕人，要麼就按照你說的方案做，那樣可以統計。還有一個辦法，你去确認一下搜索框跳轉的知識庫系統，能不能識别出訪問來源，我們可以通過對訪問知識庫的URL做一些處理，讓知識庫系統能夠識别出搜索跳轉的來源和詞語。如果知識庫系統有類似百度統計那樣的功能，就可以通過知識庫系統來統計熱詞來源和搜索量。”

小王一臉暈菜，心想：還能這樣！URL怎麼配置？怎麼就能識别出來源和關鍵詞呢？媽呀，我需要學的東西好多！嘴上說道：“好的好的，我去找知識庫系統的産品經理了解确認一下，再來找您。”

上面案例中的類似場景在日常工作中很常見，産品功能的過度設計會導緻技術人員進行無謂的開發工作。如果是負責任的RD，可能會刨根問底，和産品經理一起修正方案；如果是工作很被動的RD，可能就直接排期開發了，造成開發資源的浪費。如果産品經理對技術有基本的認知和理解，則可以避免這類問題的發生。

下面是第二個場情景對話，不懂技術的小王換成了懂技術的小劉。

情景對話2：RD和懂技術的産品經理小劉

小劉：一名工作5年的高級産品經理，非計算機科班出身，自學了很多技術知識。

老李：一名工作5年的RD，經驗相對豐富，做事相對保守。

（在小劉工位前，小劉在思考。）

小劉（思考中）：嗯，實現這個需求需要增加熱詞搜索功能，需要有一個熱詞配置界面。嗯，業務人員不需要查看熱詞編輯曆史，隻希望能夠每周調整一次熱詞内容，并且希望能夠統計熱詞的點擊情況。熱詞配置界面可以盡量簡化，一個文本框加一個保存按鈕是個好辦法；至于統計功能，已經和知識庫的産品經理溝通好，可以通過跳轉知識庫的URL做一些格式調整，知識庫可以識别并記錄檢索來源和關鍵詞，這樣就能統計出熱詞的檢索量。好了，想得差不多了，拿着原型圖去找開發人員吧。

（在老李工位前，對話開始了。）

小劉：“老李啊，我這兒有個需求，給你大概講一下。”小劉講完上述想法說道：“你看開發這個功能需要多久，大概估一下呗。”

老李暗想：這小子前段時間給我的需求積壓了不少，我得緩緩。他咳嗽了一下說道：“這個嘛，你這個還是比較複雜的，這個搜索框要改，還有這個配置頁面，看起來很簡單；但是後台設計很複雜。我預估前端開發需要3人日，後端開發需要5人日，測試需要2人日，一共10人日。”

小劉（驚詫）：“啥！？實現這麼個玩意兒要10人日，你别忽悠我！”

老李：“我咋能忽悠你呢？這個後台設計可麻煩了，要有數據存儲、處理、編輯啊，複雜得很！”

小劉（詭笑）：“得了吧，就這麼一個文本框，沒有任何處理邏輯，寫啥存啥，改啥存啥，後台要麼就一個文本文件，要麼就在數據庫中找一個表維護一條數據的事兒，你這個評估好像不太合理哦，要麼你再琢磨琢磨？或者我們讓老楊（老李的leader）一起看一下？”

老李（一驚）：“呃……你等等，我再看看，嗯，好像可以做得簡單點，估計兩三天搞定吧，也别找老楊了，就這麼着吧。”

小劉（微笑）：“好嘞，那我大概知道了。”

在本案例中，小劉自己對産品功能的實現複雜度有充分的判斷，并且因為老李預估的水分太大，所以拿老楊稍微壓了一下老李，老李最終重新給出合理的工時預估。

結語

以上兩個情景對話，列舉了不同能力層級的産品經理與RD，在方案設計和方案取舍上的溝通。 兩個例子說明了，産品經理一定要懂得一些技術基礎，才能在方案溝通上避坑避雷。

作者：楊堃，《決勝B端》作者，微信号公衆号：goYangKun，11年互聯網研發、産品設計經驗，曾就職于傳統外資保險公司、百度，現就職于vipkid。

本文由 @楊堃 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部