有哪些產品經理認為很簡單，實則開發很難的技術？

11-24

總有一些產品經理在跟技術溝通的時候，說這個不就是調用一個什麼方法，那個按鈕不就是添加個監聽事件嗎，有什麼難的。但實際開發中要比產品經理想的困難、麻煩得多，有哪些比較典型的例子？

老夫來分享一些人僧驚艷。

對於產品和開發，兩支天賦我都基本加通了。產品（遊戲策劃）方面的天賦點，是因曾經被坑了太多，失去了找到高契合度產品合作者的信心，於是自行轉職修鍊而成。作為一個二轉角色，這題還是可以答一下的。

在分辨需求方靠譜度這方面，公司豢養的程序員是遠不如宅家接外包的soho狗們的。被不靠譜的發包方坑乃是soho狗成長路上所必經的磨礪，於是就逐漸總結出了一些分辨不靠譜需求方的常識。

其中最重要的常識就是，在闡述時使用「簡單」二字，是需求方不靠譜的標誌。有不少接外包的同學，甚至一看見「簡單」二字，直接就不再繼續聊。

因為在提技術需求的語境中，「簡單」有三種隱含含義：

第一種「簡單」，沒釐清技術點

出現「簡單」一詞，很可能是因為相關技術點沒有釐清。沒釐清技術點，貿然開工會導致研發過程中溝通頻繁、研發目標難以明確以使交活時有較大幾率陷入扯皮風險、具體研發時間無法估算。

例句：（對著UE示意圖講）這個位置，用來擺放用戶頭像，簡單做一下就好。

分析：將需求點轉化為技術點的能力，是產品經理與遊戲系統策劃的基本功。隊友基本功不行，這單需求也未必就沒救，關鍵就看需求點是否明確。針對需求點明確的情況，如例句，可以用追問的方式細化以挽救。如：

頭像多大，多少乘多少？
——大概400*400吧。
目前定不了是嗎？
——是的。
你剛說400*400，長寬比例固定是1:1嗎？
——我想想……不一定，具體要等界面Demo出來後再看易用性。
大小不寫死，我清楚了。只在這一個界面用嗎，其他View會有頭像展示嗎？
——可能會。
那寫的時候還要照顧下復用性，清楚了。看你畫的是矩形，確定是矩形邊框嗎？
——不，是圓角。
圓角弧度多少？
——額，我要再確定下。
好。頭像上有可能會疊其他東西嗎，比如，加個V？
——會有類似的。我本來是想做到VIP系統再提。
現在提，後面再加會有坑。
——現在需求還不明確，總之就是有可能會在頭像上擺會員標誌。會員標誌可能會有好幾種，但還沒設計出來。每種會員標誌的出現邏輯還沒定，VIP系統文檔還沒出完。
會員標誌圖片資源是從伺服器得還是從本地得？
——這個……都差不多吧。
換個問題，會員標誌有熱更新的需求嗎？
——沒有。
好的。用戶頭像的圖片來源是？
——用戶自己在本地相冊里選的。
要和伺服器同步嗎？
——要。
這方面的後台API有嗎？
——……沒。
什麼時候能有？
——不確定，需求還沒提。
用戶選取頭像的操作是？
——點擊頭像，彈出系統自帶的照片庫，選擇圖片，確定。
任何情況下點擊頭像都執行照片庫彈出和選取的邏輯嗎？
——額……不是，應該是進到主頁里。
這塊設計還不明確是嗎？
——……是。
那你先簡單設計一下把，玩了之後簡單畫一個交互流程圖給我就好了。
——……
好的。我總結下：用戶頭像控制項，圓角矩形邊框，長寬可配置，圓角弧度可配置，頭像上有疊加子控制項用來顯示會員標誌。會員標誌圖片資源來源於本地Bundle。子控制項有多個顯示狀態以對應不同的用戶身份。頭像圖片可由用戶選擇，選擇流程邏輯欠缺。頭像圖片需要與後台同步，相關API欠缺。有缺漏和疑點嗎？
——沒有。
好的。我先簡單找張圖意思一下簡單做著，圖片選擇部分等你設計，圖片同步部分等你們出API，除這兩點之外，周五做完。

以上，算是把一個「簡單」的頭像顯示組件釐清了。遇到不會拆需求的產品經理，只能我們來幫他理，也就是幫他干本該他來做卻沒沒有足夠能力去做的活。

不靠譜度：☆☆☆☆ —— 起碼知道要的是什麼

第二種「簡單」，缺設計

對於入行不深的人來說，應用程序=腦洞+程序，遊戲=腦洞+美術+程序。很多工種與工序全然被無視，於是就誕生了——

「就差一個程序員了！」

第二種「簡單」，與上面這句話的誕生背景類似。

例句1：（同行介紹來的土豪）你好，我要做個股票分析軟體，就是根據我的演算法給指定股票打個分。演算法是明確的，我用Excel實現的有，你給做個手機版的就好了。界面無所謂，你就簡單做一下就好了，重點是功能。

翻譯：我啥都不懂，手裡有個需求，聽說你是做手機應用的，就先來問問看。我只負責掏錢，其他全都不管。你們程序員那麼厲害，界面也給一塊兒畫個吧。

分析：做外包的碰見這種2白，一般就是問個對方心理價，合計下看夠不夠再雇倆人一塊兒干，一個做UE，另一個負責跟丫溝通，明確他的每個需求點。

例句2：（公司領導）小李，你上個項目做的不錯，年底了，咱們也不會有大的立項。組裡有個小需求，交給你去做吧。就是在手機上做個簡單的小程序，接上公司的CRM系統，有重要事項時給相關負責人發個推送就行了……

分析：

可能性1

看你工作不飽和，隨便給點活做做。什麼，你管我要產品經理？本來就是隨便找點活給你你還敢找我要人？
你管我要案子？流程邏輯？界面圖？後台API？自己解決吧！

可能性2

項目做完了，年景不好接不來啥單子，後面倆月沒你事兒了，年底要發獎金了。找個東西噁心噁心你，識相點自己辭職吧，別耽誤大好前程，部門裡也省點錢，這就是我開會時經常說的「雙贏」。
（媽的，引起了一些噁心的回憶）

不靠譜度：☆☆ —— 還是讓你的人「簡單」出個案子然後我們再聊吧

第三種「簡單」，沒錢

「我有一個簡單的小需求，很容易實現，一千塊做不？」
「就這個簡單的小功能，你報五個工作日？」
「僅僅是簡單的Flash移植H5並套個殼上傳Appstore而已，你好意思要這麼多？」

分析：沒啥可分析的……無非是想打免費炮，約不約就看自己了。

不靠譜度： —— 「幫個忙嘛，請你吃飯！」

結論

並沒有特定的「看起來簡單實際上難以實現」的需求。非項目開發者，無法評判具體實現的難易。即便是同項目組的程序員之間互相提需求，在不清楚對方代碼結構的前提下，也沒有足夠的信息量去評判實現難易度。

妄談「簡單」，多為需求提出方Too simple。

與「簡單」類似的不靠譜需求關鍵字，還有：

「戰鬥系統Demo，主要驗證一下感受，角色技能你就稍微做幾個，關卡隨便做一下就好。這塊先就只做單機，應該還是比較簡單的。」

我就是這麼從一個程序員被逼成策劃的。

請珍視這樣的產品經理。能和你說監聽事件的，至少是了解過一點技術的人。
請花一點時間，和產品經理深入探討一下相關的開發成本。我相信他是很樂意的。
（另外，我建議任何時候都要在你心中估算的時間之外加個百分之30，就算領導不插需求，無論是產品經理還是你，都沒有辦法在寫代碼之前把時間估算得很精準，除非你一直在某一領域工作，否則就算10幾年經驗都未必能掐准，問題不光在技術上，還有你對業務的理解程度問題）

如果一定要鄙視產品經理，搞嚴格的專業隔離，對雙方的成長都不利。
最後難免會演變成：明天就要上線，我不管你怎麼實現。

大部分人，無論是程序員還是產品經理還是設計師，其工作難度都沒有到達外行完全無法置喙的程度，也沒有達到需要拼智商的地步。
很多時候，大家坐一起能在短時間內把一個業務流程縷清楚就很不容易了。但是在一起縷還是好過嚴格隔離嚴格分工。
溝通成本再大，也大不過不溝通事後撕逼的成本。
當然，我說的只是it行業最普通的大多數，高科技我就不懂了。

_______________________
補充一個正面回答此題的小答案。

不過這個答案還是偏的，在這個案例中，一開始技術和部分產品人員都覺得簡單，當然，也有產品人員知道不容易，知道不容易的那個人就是我，我知道不容易是因為我老早就研究過。

在微信提供正式的js api之前，在微信中用web上傳照片是個很麻煩的事。

裡面大概有如下幾個坑：
1、大部分人可能會要求提供照片預覽功能，但有意思的是，考慮到用戶手機流量問題，很多人都覺得預覽應該是預覽本地圖片，而不是先上傳再預覽（都上傳完了還預覽個屁啊）
然而，大部分程序員實現的時候就是讓用戶先上傳後預覽的！
為什麼？
因為pc端的上傳通常要麼是用原生的html4的控制項，沒有預覽功能或者是先上傳後預覽（因為pc端不擔心流量），要麼是用flash插件實現對本地文件的訪問。
他們並不知道html5中對file input api進行了升級，完全可以做到js讀取本地文件內容。但需要程序員研究清楚。

2、圖片壓縮功能
這年頭手機拍的照片放在過去都屬於殺貓大圖，直接上傳可不光是耗流量，還有可能坑死微信，直接導致微信內置瀏覽器崩潰！！！（當然這是兩年前的事了，現在手機和微信都已升級可能好點了）
說到這裡，圖片壓縮這個需求有的程序員仍然會把它解讀為"伺服器端壓縮"！！！當然，伺服器端壓縮可以節省空間利於顯示，這是不說大家都知道要做的事，但僅僅是伺服器端壓縮肯定是不夠的。
事實上，早有人利用html5的canvas實現了在上傳之前壓縮圖片，具體怎麼做，傳統的web"全棧"程序員還是要研究研究。

3、分段上傳，斷點續傳。
基於前述技術，把圖片變成base64編碼的串進行上傳，這樣可以分段了，成功概率更高了。

說了這麼多，這個事情解決了嗎？
然並卵！
不少主流國產手機遇到大文件的時候一樣崩潰，幾m就崩，在本地選擇時直接就崩。
當時我甚至機智地想到，可以利用這個特點實現退出微信瀏覽器返回聊天窗口的功能（一崩自動退了），不過這個想法現在沒意義了，因為微信的js api已經提供了退出瀏覽器返回聊天窗口功能。

這件事里詭異的問題還有很多。

所以我當時想到的終極解決方案就是使用微信聊天窗口發照片，可惜被人以用戶體驗不好為由pass掉了。

所以微信的js api還是很重要的，以前是沒有，現在有了，能用就用。

1.富文本編輯器

我說的就是像知乎這種你回答答案時候用的編輯器，市面上有很多現成開源的，但你們有沒有嘗試自己寫過？這玩意不只沒有很多人想像中的那麼容易，甚至坑到絕對不是一個人能搞定的，我曾經嘗試寫過 Javascript 和 Objective - C 的，均是寫到一半發現這個輪子比造車還困難。

2.推薦系統

推薦系統不只是難開發，更重要的是很多產品經理其實都沒想明白究竟要推薦什麼，我聽過很多有趣的反饋，說希望給每個用戶推薦他們想看的內容，或者推薦他們關注的熱門內容，這個想看或者熱門都不是隨便說說而已的 ……

3.搜索

你就看知乎和豆瓣這兩家都是創業公司的巨無霸了，他們的搜索做好了么？

4.絕大多數的動畫效果

很多產品在動畫效果上都會給設計師一個模稜兩可的要求，然後設計師又拋給程序員一個非常酷炫的效果，但其實多數都非常耗工時。有興趣的人可以試著從零寫寫 QQ app 裡面那個拖拽小數字小紅圈消除所有未讀提示的效果，就是那個帶著數字小紅圈拖拽時候的膠裝效果。

5.支付

我見過不下三個團隊的 boss 要求自己產品里加入自己的支付系統，不應用支付寶等第三方，但又要達到第三方的功能，我估摸著沒有20倍以上的員工數量就是開玩笑。

6.跟效率有關的絕大多數內容

絕大多數要明顯降低用戶等候時間或者提升處理能力的都不是一般人能寫的。

所以我強調過非常多次，產品經理的技術背景非常重要，不要求你多牛，但至少懂點 ……

獲取手機殼顏色改變主題顏色

猜你喜歡，來來，我們推薦兩個用戶可能喜歡的東西吧。
搜索，不用太複雜，簡單的搜索框就成，沒啥規則，就全文搜索吧。
咱們加個勳章成就系統吧，跟微博一樣就成。
加個私信功能吧，就點對點能發消息就可以了。
……

這就是為什麼人人都可以是產品經理，但是真的不能人人都是產品經理。

一段文字
它可以很簡單，可能只需要改後台上的某個欄位，APP端就變化了
它可以很複雜，對所屬框架UI影響、考慮文字長度超出邊界、超出多少字元是否自動縮小字型大小、字重是多少、是否允許用戶複製等等

一個按鈕
它可以很簡單，可以只是在message上加個option
它可以很複雜，考慮iOS的自適應、考慮Android的.9png、考慮它是否是OS本已支持的UI element

一張圖片
它可以很簡單，例如只是增加了一張引導頁
它可以很複雜，鎖定比例拉伸還是固定高度/寬度拉伸？考慮它的彈出/收回的動態效果、考慮它是否對覆蓋頁面有遮擋

一個頁面
它可以很簡單，例如只是用webview展示某個h5頁面
它可以很複雜，需要提前和UI形成高保真原型、考慮改變現有的用戶體驗流程、考慮頁面上每個元素對原流程的變更

產品經理都有一個隱藏的血槽，當你每做出一個錯誤的決策，開發都會在你的血槽上劃一刀，當你的血槽所剩無幾時，就是開發不再相信產品的時候...

利益相關：汪！

下周我們要做三個需求，磊哥你先別激動，聽我說完。這次的都很簡單，我們文檔都才兩頁，放心。

第一個是搜索，只要實現能搜到東西就行啦，只有一個框，輸入文字，點擊搜索，輸出結果。容易吧？也不用實時顯示搜索結果、不用有什麼歷史搜索記錄啥的功能，能用就可以。毅哥你也先別說話。

第二個是聊天，這個也是要求能用就行，界面上咱們不要花哨的東西，就是對話氣泡、下面有個輸入框就可以啦。當然能發語音和圖片最好。聽說有那種第三方平台和開源代碼可以用，你們隨便弄弄應該就行。林林你也坐住，馬上就結束。

第三個是社區，你看咱們產品還沒有地方給大家討論交流，多不合適。就完全仿照貼吧做就好啦，能發帖、看帖、評論就行，當然，如果有提醒和推送通知也最好啦。咱也不要求太多，知道你們都不容易。是吧。

這三個需求你們看下周能做完不？

哎？你們別走啊？...啊，就是說嘛，我就相信你們會回來的。哎？你們手裡拿著掃帚拖把幹嘛？啊！別打我啊！我哪有問題你們說，不要使用暴力......

數據同步

看了一下，我補充4個跟支付相關的吧：

0. 支付
「咱們在這加個付款按鈕，消費者點了之後就會購買咱們的XXX了。」
1. 消費者/商家餘額，可充值也可自動提現。
「你看人家支付寶做的好……」
2. 取消訂單自動退款
「美團的團購券點取消就自動退款了，咱們也做一個吧。」
3. 優惠券
「滴滴這個優惠券做的真不錯，咱們也搞一個吧。」

4.支付SDK
「說的好像很難一樣，然而接SDK分分鐘而已。」
感謝評論區的朋友

濾鏡！
曾經too naive的我對演算法蜀黍說，我就要美圖秀秀的濾鏡效果。
然後他說，你告訴我怎麼實現的。。。
然後我才知道，美圖秀秀的演算法壁壘到底有多高！
沒辦法，我跟演算法蜀黍兩個人開始各種專研，我甚至翻牆去看國外的文獻，蜀黍甚至想要去破解某國外產品，最後發現並沒有什麼用。只好老老實實的從開源的演算法上進行優化和效果疊加，最終花了快一個月調出了10個還能用的濾鏡。
我曾經以為濾鏡就是PS調一下的效果，當我看到蜀黍在寫各種矩陣的時候，我就知道我錯了。

作為產品經理回答一下。所有涉及線上資料庫修改、高存儲問題、高並發問題、修改為個性化、涉及長鏈接或者輪詢。我經歷過的我列幾個：
1.訂單表當時說要加個欄位，從我的角度很簡單，但是顯然不可能停機加欄位。
2.消息盒子的紅點實時更新，可以做，但是比想像中麻煩。
3. 首頁從靜態化到個性化，不就是換個數據流么？實際上整個首頁緩存量都大量增加。
4.個性化搜索，搜索裡面加個相關性係數。搜索不可能索引一份巨大規模的用戶*商品表格。後來我直覺給出的建議方案是搜索索引隱語義的用戶*特徵，和特徵*用戶，再計算，後來就用了這個方案。
最後是告訴產品經理和工程師的話：
RD要珍惜這樣的PM，這種願意了解技術的PM，多和他聊聊技術原理，他是可以幫你在合理範圍內爭取排期的。
PM話不要說太死，在自己的非專業領域可以參與討論，但不要說太死，容易被人本能地厭惡和懟。
都是上班的小員工，大家還是相互理解下。

所有和AI相關的：圖像、語音、推薦等等。產品覺得憑自己肉身超級簡單的（讀圖聽音等）的問題，其實對技術都超級難。

原本可以是一個好問題
可以順便科普一下有哪些看似簡單有效的實現方案其實背後需要付出較高成本
但多數答案變成了對產品的吐槽……跑偏了。
這道題能提供好答案的技術和產品不多，能有耐心和較好表達的回答就更不多了……

一句話需求後面，常見的需要考慮更多的有：
1、anti-spammer
2、智能排序
3、用戶激勵（勳章、VIP、等級……）
4、用戶自建分組/版塊/類貼吧
5、支持聊天
6、加個push
……

3.13更新
從評論里可以鑒別身份

----------------------僅僅做一個網頁的賬號登錄功能夠簡單了吧？

前端輸入賬號密碼，後端進行驗證；
上面是PM視角。

但是
總要加個驗證碼吧？
不然暴破怎麼辦；（此處省去數百字驗證碼實現方案）
另外還要加個錯誤次數記錄，前幾次就別讓用戶輸入驗證碼了。

總要有些基礎的校驗吧？
用戶名格式判斷，電話郵箱用戶名等；
密碼長度判斷；
以上新手還不一定能寫得出正則匹配。

總要支持下第三方賬號登錄吧？
各種開放平台申請開發許可權，創建應用獲取key；
讓後啃哧啃哧寫好久；（你用第三方全平台解決方案也行，誰用誰倒霉）

總要至少做兩個頁面吧？
一個是獨立的登錄著陸頁，一個是浮層登錄區塊；
AJAX登錄驗證總要有吧

總要有登錄狀態的存儲和分發吧？
用用ucenter這些通行證，要麼搞個oauth也行；

到現在為止，程序員已經折騰至少三天了；

//這僅僅是登錄哦，下高速了，不寫了。

在線聊天
推薦演算法
富文本編輯器

拉一下關係鏈做個性化推薦唄。
然我們的用戶有幾億。

看到上面的答案，不得不感嘆，每一個看上去簡單，實則開發很難的技術，都是一個創業機會。於是就有了很多第三方去實現這些功能。

在線聊天

極光IM-移動IM雲服務
融雲即時通訊雲
環信-IM雲
網易雲信|真正穩定的IM即時通訊雲服務

支付

Ping++ https://www.pingxx.com/
https://beecloud.cn/

站內搜索(國內類似的服務比較少)

Swiftype - Site search and mobile app search
Algolia | Hosted cloud search as a service

濾鏡

Camera360 SDK

富文本編輯器
這個太多，不再提

產品經理提這個需求，沒有說一定要從 0 開始寫呀！有現成的服務就用現成的，對於大部分產品來講，在最短時間內驗證需求，才是最重要的事。

更多類似的第三方應用合集：APP 創業者必知的產品和服務

很多人都說富文本編輯器難，但是其實需要的計算功能都被文字渲染的API實現光了，你也不可能越過這個層自己來一個，性能肯定不如native的。所以其實還好啦，花個個把星期，做出來支持東南亞和中東文字的，其實不是什麼大問題。GacUI都可以（要使用GuiDocumentw+類，也有單行控制項；不能使用Guiw+TextBox類，後者是沒有排版功能的）。

技術上最難的事情，就是處理錯誤的數據了，譬如要給正在閱讀C++Primer的人的C++程序彈出智能提示，難度暴增（逃。

有多少人工，就有多少智能。

謝邀。

題設里的調用啊事件，聽起來這不難啊，程序員在技術上竟然忽悠不過產品經理，奇恥大辱啊題主。

做一個Facebook一樣的「Like」按鈕，可以嵌在任何第三方網頁上那種。

有一陣子，在面試中如果候選人表現不錯，最後我會拿這一題來考驗候選人的架構觀，但是，沒有一個候選人能給出像樣的回答，所以後來我也不問這題了。