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

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

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

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

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

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

提需求要有節(jié)奏感

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

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

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

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

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

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

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

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

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

下點功夫做準備

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

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

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

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

#專欄作家#

給產品經理講技術，微信公眾號（pm_teacher），人人都是產品經理專欄作家。資深程序猿，專注客戶端開發(fā)若干年，對前端、后臺技術略懂，熱衷于對新的科技領域的探索。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議