继写了一篇产品汪必须要懂的技术文章之后，产品汪和程序猿的故事继续娓娓道来~本文将介绍一下产品汪要如何优雅的提（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）确定什么要什么不要

1. 影响主要核心目标用户的问题应优先解决；
2. 线上出现的致命Bug，影响业务主流程，应优先解决；
3. 插播一条硬广：老板需求应优先解决，不接受反驳；
4. 用数据说话，运营好用户行为分析，如果较小的改动，能促进高收益的迭代需求，应优先解决；
5. 技术团队承载的需求本来就多，若新需求花的时间要很长，导致上线有压力，不应优先解决；
6. 新功能对开发团队影响重大，但会给产品带来巨大利益的，让主要责任人决定是否插队加入开发版本；
7. 现有框架的重整和优化，对性能有轻微提升的，不影响业务主流程的，不应优先解决；
8. 时间、人力、资源难以支撑的需求，解决所花费的时间或成本会大大影响现有进度，导致工程延期，不应优先解决；
9. 产品UI的调整，围着开发改UI，调UI有时需要耗费很多时间，投入产出比超低，不应优先解决。

一系列烧死无数脑细胞自我搏斗筛选需求后，产品汪不要自以为就大功告成了，稳住，这事没完。

从需求到落地，我们还要考虑资源困难这个破坏因子，说白了，就是：缺人、缺时间、缺钱。

解决方法有一个

动用政治力量-领导，不要怕麻烦领导，不要担心领导会认为你没有能力。

很多时候，遇到问题，产品汪别总是自己憋出内伤，来不及解释了，快找领导吧。你遇到的坑他也可能亲生经历过，你何苦自己单枪匹马还不一定能杀一条血路出来，这时候需要领导指一条明灯。

获得领导和相关人员的支持的需求，你会觉得一路开挂。

况且领导可以动用你动用不了的资源，比如：缺人的时候，领导可以想办法去做部门之间的沟通与协调，看看是否可以从一些不紧急的项目之中抽离一些开发资源。缺钱的话，产品汪更需要跟领导说明情况了，申请资金，经济促进生产。

缺时间的话，你更需要和领导博弈了，给出领导适当的排期，考虑整个团队的工作量饱和程度、项目开发周期因素，一味的使用方法施压、硬压也不是办法，时间太短，有些功能只能从简。

比如：能不能先把基础的功能实现，一些锦上添花的需求就放一放或者用其他简单的功能先替代，后续再进行迭代，好用的产品都不是一步到位的，要给后来者留点活儿。

接受批评、直面挑战

需求被拒未必不是一件好事

如果技术不认可我的需求，首先质疑下自己的需求是不是本身就不合理。

技术不同意你的意见，研究清楚是为什么，因为你要承认术业有专攻，在技术层面上，他们一般是比你有话语权，虚心请教他们，听听他们的权威解释，适当的还是要自我批评。

• 你要让一个web前端在微信上，实现各种原生底座的功能也是强人所难，你只能使用微信提供的API进行开发；
• 操作系统、浏览器、第三方工具本身的权限和接口受限，比如：你要让前端去做评论右对齐功能，这根本就不行，因为是浏览器自动处理的；
• 业务逻辑本来就自相矛盾的需求，你要开发去给你实现。

实现成本太高、维护成本太高，不可做

•  实现这个需求，需要对整个系统进行大的重构、前后端颠覆性调整；
•  会带来额外的冗余的代码；
•  后续维护工作量巨大。

产品汪的作用，是填坑，不是挖坑

你要明白产品汪是要带领开发团队做出好的产品，首先得好好利用团队的资源，让每个人的能力得到最大的发挥，不要指手画脚，胡乱要求，到处挖坑。

学会做减法，适当的砍需求！适当的时候跟需求方拖

曾经有人跟我说过：如果你想找程序猿做三个需求，你可以跟他说要实现五个需求，然后他会和你砍需求，砍到三个却正好满足你的要求。我只想说一句：“城市套路深，我要回农村”。

我坚信：彼此还是要以信任为主，路会走得更远更平稳。

产品汪要扛得住压力，给团队一个完善的可执行方案。人的精力都是有限的，不要强人所难，面对需求方大佬的压力，承认自己的无能为力，告知我们的难处，一哭二闹三。

能否换个解决思路，要帮助技术来避坑，变相解决&迂回战术&延后解决也是一种思路，以往做过的每一个项目事后都要要复盘总结，看看自己都踩过什么坑，要有自己的积累和沉淀，不要犯同样的错。

高情商会带给你不一样的体验

你要跟程序猿套近乎，说白了，要有自己人的感觉。不要让他们看到你就躲，像兄弟一样。

与人方便，自己方便。

不断学习才是最好的办法，不求什么都会，但求什么都懂

多学习，这是最重要的一点，自己缺什么就补什么。不管是产品感还是技术层面，拓宽相关的知识面，也不是说你要当全栈产品汪，只是要明白：如果你什么都不知道，除非你美若天仙，不然谁要搭理你。

作为产品，如果不是某个领域专门的人，你是做不到和他们侃侃而谈的，你要明白各个领域衔接的流程方式，因为只有这样才能将你的想法无障碍的传递给他人。

变强变大，至关重要

举一个熟悉的栗子：

某程序猿工程师：这个呢，技术上可能不太好实现。

马XXCEO：你说什么？

某程序猿工程师：好，我在想想办法

一周之后，功能上线~~~~

里面的各中滋味，大家慢慢揣摩，自行消化。

写在最后

本人产品汪：与天斗，与地斗，与程序猿斗，其乐无穷。

最后一点：遇事冷静，脸小三分。保护好身体，没有好的身体怎么干的赢呢。

工作是一场接着一场的博弈战！

作者：黄丽嫦，公众号：野生派产品录

本文由 @黄丽嫦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议