起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品汪要如何優雅的提需求？
繼寫了一篇產品汪必須要懂的技術文章之后，產品汪和程序猿的故事繼續娓娓道來~本文將介紹一下產品汪要如何優雅的提（gao）需（shi）求（qing）。
自我文章上榜了之后，我司程序猿時不時在一旁嘲笑著：你說你Y整天寫些PM修煉秘籍、寶典妙招的有什么用，培養更多的汪一起被我們懟嗎？你以為自己是下一個喬布斯了嗎？你不是真以為會幾個技術名詞就是自己人了吧？你是開發還是我是開發呀，我等會就要來寫個優雅的bug了。
怎么才能和程序猿友好相處呢，想想就好了，壓根就是個偽命題。你需求上能想到的有多遠，那些程序猿就可以給你跑多遠。
那怎么辦？產品汪？程序猿？
大家拔劍吧！多說無益！
背景
產品汪和程序猿的認知領域和實踐經歷本來就不一樣，你沒有像程序猿一樣為了隱藏一個bug，設法用另一個bug來遮掩的刺激體驗，他們也沒有像你一樣為了做一個注冊/登錄功能，要準備一份十幾個APP的競品分析的較真勁。
產品汪和程序猿對產品和技術的了解，相差太遠。大家的出發點和側重點都不同，天然就有一道鴻溝。
舉個栗子：程序猿和產品汪在某些時候就像小情侶一樣。
女生：喂，我最近胖了，這些衣服我都不想穿了。
直男：你不會又要買新衣服吧？
其實對女生而言，就是想讓男友說一句：你真的一點都不胖。
每當開需求評審會的時候：
產品汪吧啦吧啦說了一通
程序猿說：做不了。
程序猿的內心潛臺詞是：你Y是個傻子，我才不想加班，這個實現好麻煩哦，快放假了不想搞。
產品汪：殺一個程序猿祭天！
穩住，我們能贏！
走進程序猿的內心世界
其實程序猿大多數時候，簡單回應一句做不了，他們可能只是覺得這樣的表述更節約時間。
那作為產品汪呢，透過現象看本質，我們一一剖析下他們的心理歷程吧。
總而言之、言而總之，除了程序猿自帶的小情緒之外，其他的情況，產品汪都是有應對之道的。
其實，最有力的反擊就是找到一個已經實現的案例！或者自己來！I?can I Up！拿出證據會減少很多不必要的爭執。
直白的講：不屌不進步！
曉之以情、動之以理
作為產品汪：我告訴你，對程序猿提需求的姿勢要優雅。劃重點，一定要優雅?。?！
謹記：三要死不要。
- 要努力的讓程序猿理解你提這個需求的價值，重點闡述三大寶：What（做什么）、Why（為什么要做）、How（怎么做）。需求不明確時一定要明確，自查需求準備清單，寫一份圖文并茂的功能清單、PRD、原型和流程圖（開發最愛的）。如果你想讓你的需求一次性通過的話，face to face，面對面評審溝通，獻上一記重拳，你把你文檔里面的所有的配圖都換成長澤雅美，新恒結衣，應該是穩穩通過。哈哈，不信你試試。
- 要表明自己理清楚了所有需求的重要性和優先級，程序猿們都是理性思維，滿腦子的if、else、try、catch，你不能讓程序猿亂了陣腳。如果時間很充足，自然是可以實現很多需求，但是時間成本增加的同時，技術成本也在增加。
- 要盡可能的交代清楚，討論需求的每一個細節，別等到程序猿Coding的時候還帶著一大堆邏輯疑問。產品開需求評審會，講的那么隱晦，你讓那些就是一根筋的程序猿如何能聽得懂，就算某些高智商的Get到了點，他也會裝聽不懂。越是明白人，話就說的越清楚，明明白白才是王。
- 不要把程序猿當成你的工具：產品汪常常會說：我有個很棒的想法馬上就可以實現了，現在只差一個程序猿了，他們又不是你的機器人。話有三說：巧說為妙。很多時候產品汪要注意與程序猿溝通的方式、技巧，運用語言的藝術也好，動用個人魅力也好，堅持不卑不亢，不強勢不懦弱，千萬不要讓程序猿覺得這個功能只是滿足你個人需求，要建立合作關系，并非派活兒。
- 不要覺得他們加班是理所當然，不知什么時候起，整個行業風氣就是這樣，不加班反而不正常了。我很反感那些“你見過凌晨三點半的北京嗎”的文章，一個勁的販賣焦慮和制造恐慌，難道互聯網從業者就沒有睡覺的權力了嗎？難道只有加班等死才是好員工嗎？沒有健康的身體，何來穩定的代碼。你不要看起來很努力，結果又不會陪你演戲。在提需求前，你也假裝問下自己：開發有多久沒有正常下班了。
- 不要拍腦袋想需求：程序猿的每一行代碼都是他們的價值體現，產品汪不要自己yy二十多個功能點，逮著程序猿就是一股腦的交給程序猿去開發，這無疑像遛狗一樣，你把骨頭拋得老遠老遠，讓它拼了命去接。沒有業務價值、商業價值的產品需求是無法解決用戶痛點的，就更別提帶來用戶滿意度。真正有價值的需求是要深入你的產品用戶人群，對于用戶需求有準確的認知，去了解他們的使用痛點，才能真正滿足到用戶的需求點。做出受人喜歡的產品，打造產品自身的差異化和競爭力，不然就是浪費團隊時間，做些沒用的功能。
- 不要把所有的事情都丟給他們，“沒有解決不了的技術問題”這也要分情況，技術選型、原始架構可能原本就存在問題，比如說：在大家都遇到了很難解決的終極問題的時候，產品汪要展現出超出尋常的強大公關能力。不要拿程序猿當擋箭牌，什么刀子都拿他們來擋。
能文能武、能上能下
不打沒準備的仗
產品汪提需求之前要做足功課，除了你要對需求有深刻的認知，包括產品的業務目標、定位、當前用戶、運營情況分析，你還需要懂得一些技術基礎。
試著去找到其他產品已經實現的應用案例，最好是自己會去分析和理解別人實現的思路，了解最新的應用技術，更棒的是能自己對整體有一個合理的技術預估和一定的解決方案，然后再去找程序猿去溝通、去權衡，這個時候就有把握多了，產品汪不要整天只會文字游戲，要腦補一下0和1，有利于更好的解決問題。
了解業務流程>產品邏輯>實現方式>數據存儲>傳輸方式，這樣會減少后續需求變更的次數。
需求劃分優先等級，至關重要
基本上項目的開發周期是：收集需求->分析需求->確定需求優先級->確定目標->開發->測試->發布->運營
對于不同類型的產品汪，無論你是移動端產品經理還是后臺產品經理還是數據產品經理，需求的來源都是五花八門的，開發資源是有限的，程序猿Coding也是一個從0到1的過程，注重輕重緩急和工作速率。
- 不控制需求的優先級，需求可能永遠無法凍結。
- 不懂得把控需求，不會篩選需求優先級，那就會導致：自己又挖了個坑埋了大伙。
如何給需求劃等級，有很多方法：
（1）以目標和結果為導向，不浪費資源：時間、人力、物力
有數據的話用數據說話，數據驅動開發是趨勢，數據能更好的了解用戶群體行為，從而為拉新促活做有力的鋪墊。
（2）KANO模型
KANO模型是對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。
KANO模型將用戶需求分為5個維度：基本需求、期望需求、興奮需求、無差異需求、反向需求。
KANO模型優點是量化明確，從用戶角度出發，相對合理。不足之處在于，依賴用戶調研樣本，及調研過程中各種可能的差異。
（3）確定什么要什么不要
- 影響主要核心目標用戶的問題應優先解決；
- 線上出現的致命Bug，影響業務主流程，應優先解決；
- 插播一條硬廣：老板需求應優先解決，不接受反駁；
- 用數據說話，運營好用戶行為分析，如果較小的改動，能促進高收益的迭代需求，應優先解決；
- 技術團隊承載的需求本來就多，若新需求花的時間要很長，導致上線有壓力，不應優先解決；
- 新功能對開發團隊影響重大，但會給產品帶來巨大利益的，讓主要責任人決定是否插隊加入開發版本；
- 現有框架的重整和優化，對性能有輕微提升的，不影響業務主流程的，不應優先解決；
- 時間、人力、資源難以支撐的需求，解決所花費的時間或成本會大大影響現有進度，導致工程延期，不應優先解決；
- 產品UI的調整，圍著開發改UI，調UI有時需要耗費很多時間，投入產出比超低，不應優先解決。
一系列燒死無數腦細胞自我搏斗篩選需求后，產品汪不要自以為就大功告成了，穩住，這事沒完。
從需求到落地，我們還要考慮資源困難這個破壞因子，說白了，就是：缺人、缺時間、缺錢。
解決方法有一個
動用政治力量-領導，不要怕麻煩領導，不要擔心領導會認為你沒有能力。
很多時候，遇到問題，產品汪別總是自己憋出內傷，來不及解釋了，快找領導吧。你遇到的坑他也可能親生經歷過，你何苦自己單槍匹馬還不一定能殺一條血路出來，這時候需要領導指一條明燈。
獲得領導和相關人員的支持的需求，你會覺得一路開掛。
況且領導可以動用你動用不了的資源，比如：缺人的時候，領導可以想辦法去做部門之間的溝通與協調，看看是否可以從一些不緊急的項目之中抽離一些開發資源。缺錢的話，產品汪更需要跟領導說明情況了，申請資金，經濟促進生產。
缺時間的話，你更需要和領導博弈了，給出領導適當的排期，考慮整個團隊的工作量飽和程度、項目開發周期因素，一味的使用方法施壓、硬壓也不是辦法，時間太短，有些功能只能從簡。
比如：能不能先把基礎的功能實現，一些錦上添花的需求就放一放或者用其他簡單的功能先替代，后續再進行迭代，好用的產品都不是一步到位的，要給后來者留點活兒。
接受批評、直面挑戰
需求被拒未必不是一件好事
如果技術不認可我的需求，首先質疑下自己的需求是不是本身就不合理。
技術不同意你的意見，研究清楚是為什么，因為你要承認術業有專攻，在技術層面上，他們一般是比你有話語權，虛心請教他們，聽聽他們的權威解釋，適當的還是要自我批評。
- 你要讓一個web前端在微信上，實現各種原生底座的功能也是強人所難，你只能使用微信提供的API進行開發；
- 操作系統、瀏覽器、第三方工具本身的權限和接口受限，比如：你要讓前端去做評論右對齊功能，這根本就不行，因為是瀏覽器自動處理的；
- 業務邏輯本來就自相矛盾的需求，你要開發去給你實現。
實現成本太高、維護成本太高，不可做
- ?實現這個需求，需要對整個系統進行大的重構、前后端顛覆性調整；
- ?會帶來額外的冗余的代碼；
- ?后續維護工作量巨大。
產品汪的作用，是填坑，不是挖坑
你要明白產品汪是要帶領開發團隊做出好的產品，首先得好好利用團隊的資源，讓每個人的能力得到最大的發揮，不要指手畫腳，胡亂要求，到處挖坑。
學會做減法，適當的砍需求！適當的時候跟需求方拖
曾經有人跟我說過：如果你想找程序猿做三個需求，你可以跟他說要實現五個需求，然后他會和你砍需求，砍到三個卻正好滿足你的要求。我只想說一句：“城市套路深，我要回農村”。
我堅信：彼此還是要以信任為主，路會走得更遠更平穩。
產品汪要扛得住壓力，給團隊一個完善的可執行方案。人的精力都是有限的，不要強人所難，面對需求方大佬的壓力，承認自己的無能為力，告知我們的難處，一哭二鬧三。
能否換個解決思路，要幫助技術來避坑，變相解決&迂回戰術&延后解決也是一種思路，以往做過的每一個項目事后都要要復盤總結，看看自己都踩過什么坑，要有自己的積累和沉淀，不要犯同樣的錯。
高情商會帶給你不一樣的體驗
你要跟程序猿套近乎，說白了，要有自己人的感覺。不要讓他們看到你就躲，像兄弟一樣。
與人方便，自己方便。
不斷學習才是最好的辦法，不求什么都會，但求什么都懂
多學習，這是最重要的一點，自己缺什么就補什么。不管是產品感還是技術層面，拓寬相關的知識面，也不是說你要當全棧產品汪，只是要明白：如果你什么都不知道，除非你美若天仙，不然誰要搭理你。
作為產品，如果不是某個領域專門的人，你是做不到和他們侃侃而談的，你要明白各個領域銜接的流程方式，因為只有這樣才能將你的想法無障礙的傳遞給他人。
變強變大，至關重要
舉一個熟悉的栗子：
某程序猿工程師：這個呢，技術上可能不太好實現。
馬XXCEO：你說什么？
某程序猿工程師：好，我在想想辦法
一周之后，功能上線~~~~
里面的各中滋味，大家慢慢揣摩，自行消化。
寫在最后
本人產品汪：與天斗，與地斗，與程序猿斗，其樂無窮。
最后一點：遇事冷靜，臉小三分。保護好身體，沒有好的身體怎么干的贏呢。
工作是一場接著一場的博弈戰！
作者：黃麗嫦，公眾號：野生派產品錄
本文由 @黃麗嫦 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
運營轉產品，前幾個月被爆錘，干架難所在免，后面慢慢互相理解，開發會問“這是你老板逼你做的嗎？”，我設計產品方案也考慮實現成本、應用性能、后續擴展，只能說，與人斗，其樂無窮但也痛苦，追求互相信任與理解吧
產品小姐姐很少挨打的
寫得很不錯，很有感觸，多多學習
聞到了一股硝煙的味道
生動形象，精辟到位
小姐姐，看的我笑抽筋，求教求教