快生活 - 传播价值、传递关注!

产品汪要如何优雅的提需求


  继写了一篇产品汪必须要懂的技术文章之后,产品汪和程序猿的故事继续娓娓道来~本文将介绍一下产品汪要如何优雅的提(gao)需(shi)求(qing)。
  自我文章上榜了之后,我司程序猿时不时在一旁嘲笑着:你说你Y整天写些PM修炼秘籍、宝典妙招的有什么用,培养更多的汪一起被我们怼吗?你以为自己是下一个乔布斯了吗?你不是真以为会几个技术名词就是自己人了吧?你是开发还是我是开发呀,我等会就要来写个优雅的bug了。
  怎么才能和程序猿友好相处呢,想想就好了,压根就是个伪命题。你需求上能想到的有多远,那些程序猿就可以给你跑多远。
  那怎么办?产品汪?程序猿?
  大家拔剑吧!多说无益!
  背景
  产品汪和程序猿的认知领域和实践经历本来就不一样,你没有像程序猿一样为了隐藏一个bug,设法用另一个bug来遮掩的刺激体验,他们也没有像你一样为了做一个注册/登录功能,要准备一份十几个APP的竞品分析的较真劲。
  产品汪和程序猿对产品和技术的了解,相差太远。大家的出发点和侧重点都不同,天然就有一道鸿沟。
  举个栗子:程序猿和产品汪在某些时候就像小情侣一样。
  女生:喂,我最近胖了,这些衣服我都不想穿了。
  直男:你不会又要买新衣服吧?
  其实对女生而言,就是想让男友说一句:你真的一点都不胖。
  每当开需求评审会的时候:
  产品汪吧啦吧啦说了一通
  程序猿说:做不了。
  程序猿的内心潜台词是:你Y是个傻叉,我才不想加班,这个实现好麻烦哦,快放假了不想搞。
  产品汪:杀一个程序猿祭天!
  稳住,我们能赢!
  走进程序猿的内心世界
  其实程序猿大多数时候,简单回应一句做不了,他们可能只是觉得这样的表述更节约时间。
  那作为产品汪呢,透过现象看本质,我们一一剖析下他们的心理历程吧。
  总而言之、言而总之,除了程序猿自带的小情绪之外,其他的情况,产品汪都是有应对之道的。
  其实,最有力的反击就是找到一个已经实现的案例!或者自己来!Ican 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:你说什么?
  某程序猿工程师:好,我在想想办法
  一周之后,功能上线~~~~
  里面的各中滋味,大家慢慢揣摩,自行消化。
  写在最后
  本人产品汪:与天斗,与地斗,与程序猿斗,其乐无穷。
  最后一点:遇事冷静,脸小三分。保护好身体,没有好的身体怎么干的赢呢。
  工作是一场接着一场的博弈战!
 
建站大全赚钱大全网站目录投稿:妙菡