起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識不懂技術的產品小王，聊聊他的日常囧事
產品經理，尤其是B端產品經理，是需要懂技術的，否則在方案設計和方案取舍上以及和RD的溝通上，都會吃虧。下文模擬了兩個場景對話，向大家演示了這個問題。
情景對話1：RD和不懂技術的產品經理小王
小王：一名工作1年的初級產品經理，非計算機科班出身，不懂技術。
老李：一名工作5年的RD，經驗相對豐富，做事相對保守。
（在老李工位前面，對話開始了。）
小王：“老李啊，找你聊個需求。咱們的分銷運營管理后臺上線了，業務人員中的新人比較多，我們想在管理后臺的知識搜索功能中（畫外音：案例中后臺系統的搜索功能調用的是知識庫系統的搜索引擎，分銷運營管理后臺本身沒有搜索功能）加一個熱詞推薦的功能，也就是點擊搜索框后，會彈出一些推薦的熱詞，這些熱詞是管理員在后臺配置的。你看看，效果圖類似這樣（見下圖的右上角）。”
老李：“嗯嗯，聽起來比較合理，功能也是一個常規標準功能。后臺怎么管理呢？”
小王：“我已經設計好啦，有一個熱詞管理頁面，你瞅瞅，就是這樣的（下圖），能添加、刪除熱詞，還能調整熱詞的順序，功能強大！”
老李：“嗯……看起來設計得中規中矩，但是有必要這么復雜嗎？”
小王：“這個功能設計得多講究啊，絕對好使。做這個大概需要多久?。俊?/p>
老李：“呃，那就這樣吧。這個功能想要做出來，預計前端開發需要5人日，后端開發需要10人日，測試需要5人日，總共預估20人日。”
小王：“啥？這么簡單的功能，要20人日，你在坑我嗎?。俊?/p>
老李（有點生氣）：“什么叫坑你，我是實事求是地評估！”
小王：“不就是配幾個詞，然后用戶搜索的時候提示一下嗎？怎么需要20人日？你給我講講憑什么，講不清楚我就找你領導！”
老李（慍怒）：“愛找不找隨便你，不過我跟你說清楚，實現你這個設計就需要20人日。首先實現熱詞配置表需要設計數據庫表結構，然后要做各種代碼讀寫數據庫的處理，還有，前端要實現完整的增刪改查操作，交互點非常多，編輯按鈕、刪除按鈕、調整位置，這些都要處理！”
小王：“我不管，我的訴求很簡單，就是能配置熱詞，能調順序，為什么這點訴求都要開發20人日！”
老李（嘆了口氣）：“你是不是想盡快上線？”
小王：“當然！多簡單的功能！”
老李：“小伙子，是否簡單，不是你說了算的，你都不理解背后需要做哪些工作。我問你，不就是配一張熱詞表么，你看這樣做行不行，就一個文本框，一行一個詞，要調整順序什么的直接編輯這段文字就可以，想要增加或刪除熱詞，都通過編輯這段文字來實現（下圖）。”
小王（遲疑并思索）：“這個，好像也可以，操作也不復雜，并且完全滿足訴求。這樣做需要多久？”
老李：“這樣做的話，不需要設計數據庫，只保存一個文本文件，前端控件也非常簡單，預計前端開發需要2人日，后端開發需要1人日，測試需要0.5人日，總共3.5人日吧?！?/p>
小王（有點不好意思）：“那要不就按您這個設計來吧，咱效率第一。”
老李：“小伙子，可以可以，知錯就改，聽得進去建議?！?/p>
小王：“還有一個問題，可以統計不同熱詞的點擊量吧？”
老李：“呃，按照我給的設計方案，有點麻煩。因為這個方案中熱詞的配置是按照文本存儲的，如果想記錄每個詞的點擊數量，必須對文本進行解析，并且記錄每個單詞及其對應的點擊量，處理邏輯又會變得非常復雜?！?/p>
小王：“那怎么辦？我要統計熱詞點擊量?。 ?/p>
老李心想：你咋啥都不會，都讓我幫你想方案，那我直接和業務對接好了，要產品經理干啥？
但是，老李嘴上說道：“哎！年輕人，要么就按照你說的方案做，那樣可以統計。還有一個辦法，你去確認一下搜索框跳轉的知識庫系統，能不能識別出訪問來源，我們可以通過對訪問知識庫的URL做一些處理，讓知識庫系統能夠識別出搜索跳轉的來源和詞語。如果知識庫系統有類似百度統計那樣的功能，就可以通過知識庫系統來統計熱詞來源和搜索量?！?/p>
小王一臉暈菜，心想：還能這樣！URL怎么配置？怎么就能識別出來源和關鍵詞呢？媽呀，我需要學的東西好多！嘴上說道：“好的好的，我去找知識庫系統的產品經理了解確認一下，再來找您。”
上面案例中的類似場景在日常工作中很常見，產品功能的過度設計會導致技術人員進行無謂的開發工作。如果是負責任的RD，可能會刨根問底，和產品經理一起修正方案；如果是工作很被動的RD，可能就直接排期開發了，造成開發資源的浪費。如果產品經理對技術有基本的認知和理解，則可以避免這類問題的發生。
下面是第二個場情景對話，不懂技術的小王換成了懂技術的小劉。
情景對話2：RD和懂技術的產品經理小劉
小劉：一名工作5年的高級產品經理，非計算機科班出身，自學了很多技術知識。
老李：一名工作5年的RD，經驗相對豐富，做事相對保守。
（在小劉工位前，小劉在思考。）
小劉（思考中）：嗯，實現這個需求需要增加熱詞搜索功能，需要有一個熱詞配置界面。嗯，業務人員不需要查看熱詞編輯歷史，只希望能夠每周調整一次熱詞內容，并且希望能夠統計熱詞的點擊情況。熱詞配置界面可以盡量簡化，一個文本框加一個保存按鈕是個好辦法；至于統計功能，已經和知識庫的產品經理溝通好，可以通過跳轉知識庫的URL做一些格式調整，知識庫可以識別并記錄檢索來源和關鍵詞，這樣就能統計出熱詞的檢索量。好了，想得差不多了，拿著原型圖去找開發人員吧。
（在老李工位前，對話開始了。）
小劉：“老李啊，我這兒有個需求，給你大概講一下?！毙⒅v完上述想法說道：“你看開發這個功能需要多久，大概估一下唄?！?/p>
老李暗想：這小子前段時間給我的需求積壓了不少，我得緩緩。他咳嗽了一下說道：“這個嘛，你這個還是比較復雜的，這個搜索框要改，還有這個配置頁面，看起來很簡單；但是后臺設計很復雜。我預估前端開發需要3人日，后端開發需要5人日，測試需要2人日，一共10人日。”
小劉（驚詫）：“啥?。繉崿F這么個玩意兒要10人日，你別忽悠我！”
老李：“我咋能忽悠你呢？這個后臺設計可麻煩了，要有數據存儲、處理、編輯啊，復雜得很！”
小劉（詭笑）：“得了吧，就這么一個文本框，沒有任何處理邏輯，寫啥存啥，改啥存啥，后臺要么就一個文本文件，要么就在數據庫中找一個表維護一條數據的事兒，你這個評估好像不太合理哦，要么你再琢磨琢磨？或者我們讓老楊（老李的leader）一起看一下？”
老李（一驚）：“呃……你等等，我再看看，嗯，好像可以做得簡單點，估計兩三天搞定吧，也別找老楊了，就這么著吧。”
小劉（微笑）：“好嘞，那我大概知道了?！?/p>
在本案例中，小劉自己對產品功能的實現復雜度有充分的判斷，并且因為老李預估的水分太大，所以拿老楊稍微壓了一下老李，老李最終重新給出合理的工時預估。
結語
以上兩個情景對話，列舉了不同能力層級的產品經理與RD，在方案設計和方案取舍上的溝通。 兩個例子說明了，產品經理一定要懂得一些技術基礎，才能在方案溝通上避坑避雷。
插播一條廣告
大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。
我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。
幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。
掃碼即可報名，還可為大家爭取到的專屬優惠~
立即搶座，報名成功后即可領取詳細課程資料！
作者：楊堃，《決勝B端》作者，微信號公眾號：goYangKun，11年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司、百度，現就職于vipkid。
本文由 @楊堃 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
爭當懂技術的小劉
我現在的能力還不如不懂技術的小王，B端產品實戰這課程適合我嗎？
來添加B端產品學習顧問Kate小姐姐了解下：微信/tel：13043427355
這場景太真實 太熟悉了0..0
不懂技術的產品經理遇到沒有責任心的開發，很容易背鍋
分分鐘被你點中穴位 ??
哦，對了，《決勝B端》已購入。正研讀。
你這個場景一和場景二的分析并沒有真正的區別，第一個場景是產品不懂技術，技術便隨意評估，很不精準，在一個產品并沒有合理有效的溝通，導致由于對技術的無知、可能導致被技術牽著鼻子走。放大了不懂技術的問題。場景二其實只是表面了懂技術不至于被技術牽著鼻子走，但是主要還是看自己的溝通方式方法，不管是產品還是技術，都應該積極的參與到需求的討論當中，而不是隨波逐流。這樣可能在開發的過程當中也并不能取得最佳的效果。
場景一明明是產品經理不會溝通
小王前來報到
這個是個好例子。但較真一點的話，其實第一套方案應該1人日就可以搞定，第二套就更快了。但從這個功能是一個可以擴展的功能，所以性價比來說第一套其實更劃算。不過文章要表達的意思已經很到位了，我就瞎扯扯
多溝通，用最小的成本，達到目的即可。懂些技術的話，降低溝通成本，提高溝通效率。
這場景太真實 太熟悉了0..0
這場景太真實 太熟悉了0..0
??
對技術了解少實在是太囧了，反思~