提需求的正確姿勢是什麼？

開發大哥，我代碼寫的少，你可別騙我……

在論壇、知乎上經常看到一些「年輕的」產品經理發的引戰帖，大意是：「開發大哥，我代碼寫的少，你可別騙我，這麼簡單的需求，明明一下午可以搞定，你跟我說一個星期？如果讓我來的話，巴拉巴拉巴拉…」。看到這種論調，一些沒耐心的程序員就會一笑了之，甩下一句「You can you up，no can no bb」，或者「你這麼屌，你咋不上天咧」之類的回復瀟洒走人，但是作為一名愛管閑事的程序員，我怎麼能放過這個絕佳的「站在制高點上俯瞰眾生」的機會呢？

先來反駁一下這位「年輕的」產品經理。寫代碼是一個典型的「紙上得來終覺淺，絕知此事要躬行」的事情，往往一些看似很簡單的需求，實際上會遇到很多坑。你看過「人在囧途」吧？一段很簡單的回家路，誰知道會有那麼多的坎坷。就是這種感覺。

舉個例子，你要實現一個「視頻播放的時候，用戶可以設置屏幕亮度」的功能。實際上系統提供了「設置屏幕亮度」的程序介面，你只需要去調用就可以了，核心代碼可能就一兩行，夠簡單吧？但是，一運行你就會發現各種問題。如果用戶在我的APP里提高了屏幕亮度，退出之後要不要給人家還原呢？如果用戶只是暫時離開了我的APP，退出又回來，我是不是要給人恢復成原來設置的亮度呢？這些都是產品邏輯問題，你們溝通之後很快就解決了。但是後來測試發現，「設置屏幕亮度」的介面是一個很耗時的介面，可能會造成整個APP的卡頓，這時候你就得考慮用多線程來解決。引入多線程之後，線程之間的資源共享問題如何解決，誰先誰后的問題如何解決，等等…

「年輕的」產品經理不會想這麼多，自己爽完提上褲子就跑了，留給程序員一堆爛攤子，程序員能開心的幫你幹活嗎？還有就是，程序員寫代碼可不光是完成功能那麼簡單，代碼寫的規範不規範，魯棒不魯棒，擴展性怎麼樣，都是需要事先下功夫去設計的。我一開始寫代碼的時候，就喜歡那種實現一個功能的快感，迫不及待的要秀給別人看，後來體會到並不是那麼回事。寫代碼就像談戀愛，一開始轟轟烈烈，海誓山盟，談的久了，你會發現往往一些簡單的小事，要完全負起責任，才是最難的。

說了這麼多，就是想讓你理解程序員寫一行代碼，究竟要「熬過多少患難，濕了多少眼眶」。這是動之以情。接下來我們談談如何正確的提需求，就是要曉之以理了。

提需求要有節奏感

不要誤會，這個節奏感不是啪啪啪的節奏感，而是說你提的需求，要跟著項目的版本周期走。一般一個不是太拖沓的互聯網產品，每個版本會經過功能開發、單元測試、集成測試、beta驗證、上線幾個階段，我們分別來看一下。

功能開發階段，簡直是程序員的美好時光。下午懶散的陽光打在臉上，泡一杯濃香的卡布奇諾加一點點糖，戴上女朋友送的Beats大耳機循環一首輕音樂，手指在機械鍵盤上跳來跳去，噼里啪啦的，就像腦海中忽閃忽閃的靈感，根本停不下來，對對，就是這樣的感覺。

這期間程序員要麼做產品經理提的需求，要麼悶頭做一些技術需求。這是產品經理提需求的最佳時期，程序員剛剛結束了上一個版本緊張的發布期，急需要一些新鮮的需求來壓壓驚。技術需求是一些性能優化、代碼重構之類的事情，這個雖然是程序員自己給自己提的需求，但是你一定要給他時間去做，不然程序員每天總覺得自己寫的代碼亂糟糟的，沒有安全感。

單元測試是一個功能模塊的需求做完之後，提給測試同學去找bug。集成測試時所有模塊的需求都單元測試完成之後，整體來一輪測試。這時候程序員天天在改bug，你奇思妙想來一個新需求，他可能要象徵性的反抗一下，但是大多數會乖乖去做。

到了beta和發布階段，大家都繃緊了神經，天天盯著用戶反饋和線上的各種指標。這時候你突然被一塊石頭砸中，有了一個絕妙的需求，請hold一下，一定要hold住，因為你提任何需求都是會拉仇恨的。

先自己嘗試評估一下需求難度

這個就有一點技術含量了。有些需求天生是很難的，比如智能推薦、智能識別、搜索引擎這種，需要很強的技術能力。還有些需求，需要前後端聯調，後端開介面，商量協議，這些時間算上去總時間要翻倍。除了這些，剩下的就是相對的了，取決於是否有現成的輪子。程序員常說，「不要重複發明輪子」，就是說如果有現成的代碼，就直接用不要自己再花時間寫了。現成輪子可以來自開源社區、自己項目的積累、還有系統平台提供的支持。如果某個需求有現成輪子可用，那它的難度應該至少要減半。

你想知道開源社區都是有哪些輪子，可以平時多看一些別人整理的技術博客，你可能並不需要知道裡面技術上是如何實現的，你只需要記下，這個功能是有輪子可以用的，就夠了。你想知道自己項目積累了哪些輪子，去問你們的開發吧，找他們抽支煙、吃個飯，很容易就套出來了。有些項目比較成熟，像推送、埋點上報、自動更新這些都有輪子可以用，但一些年輕的項目則不然，建立這一套東西也要花不少時間。你想知道系統平台提供了哪些輪子，就買一本介紹你們產品平台的技術書，比如《瘋狂Android講義》、《iOS Programming》，大體翻一下就行了，主要是了解一下這個平台到底可以做哪些事情。

沒有輪子可以用的需求怎麼評估呢？少俠，你眼光不錯哦，每天進來看看，你就知道答案啦。

下點功夫做準備

這是個普遍的道理，你讓別人給你辦事，吩咐半天講不清楚，別人肯定不耐煩。如果你的需求是抄的別人的，可以拿別人做好的效果演示一下，這是最直接了當的。你的需求是業界首創的，可以簡單畫個流程圖，如果這時候你能用上一兩個技術上的術語，程序員肯定覺得你碉堡了。需求講清楚了也要順便讓人理解為什麼。這時候不要留情，把程序員帶到你的產品世界里，用你豐富的經驗打敗他，他就會乖乖的跟你走了。

還有一點很重要，產品經理要給開發協調一些其他資源，像設計、測試這些，如果能提前準備好，那麼即使是beta甚至上線階段加需求，程序員也會十分感動然後再拒絕你的。

最後忍不住吐個槽。有些產品經理動不動就拉老大來給程序員施壓，我覺得這種是最low的，連文章開頭那些「年輕的」產品經理，水平都比他們高到不知道哪裡去了。就好比兩個小朋友打架，你打不過人家，喊的不是「放學你等著，有種操場見」，而是「我要告老師，看他怎麼收拾你」。哎我說，不要慫啊親。

PS：以上建議只是我自己的胡思亂想，是一家之言。你千萬別有「快來看啊，這傢伙又在裝逼教我們做人啦」這樣的想法。如果你覺得我傷害了你，我希望你分享出去讓更多人受到傷害。如果你覺得我說的好像是那麼回事兒，我也希望你分享出去讓更多人來聽我叨逼叨。

#專欄作家#

給產品經理講技術，_teacher），人人都是產品經理專欄作家。資深程序猿，專註客戶端開發若干年，對前端、後台技術略懂，熱衷於對新的科技領域的探索。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於CC0協議