作为产品经理,如何有效应对需求变动和技术开发?

创业公司所要求的是快速迭代产品,从而找到精准用户,进而开始谋取商业利益,这是一个非常简单且容易理解的流程(实际上情况要复杂的多),那么便来说说这第一步的操作,在迭代产 品的过程中 产品经理 如何去应对需求变动和技术开发。

企业情况

创业公司当中,是独裁还是群策,很大程度上取决于老板的心情,每个人对于公司的产品都有1-10 分的看法,这里的看法指的是员工对产品的认可度。有些人进来只是抱着看看的心态、有些人是抱着学习的心态、有些人是做事的心态、有些人可能只是混日子的心态。毕竟,对于创业型的公司,能招到个差不多的人也是很难的,招到愿意接受低工资还愿意不断加班,保持产出的更难,招到认同企业文化并愿意与之奋斗的(精神层面),难上加难;所以,在创业公司,要想完成一件事,最终还是要看企业的整体情况,分清楚哪些人可以做什么事情,并保证这些事情能够执行下去。

需求来源

需求来源于老板、总监、(用户反馈)、产品经理、同事(前面说了,在创业公司的员工的心态,以及对产品的看法)。  老板的能力很大程度上决定了产品的一个走向,但是当老板对于产品都没有一定的把控,并且由着自己的感觉来安排工作,那可就要十分当心,老板的点子是找到了社会上的一个需求,可是在实现的过程中经常会变味,那么这些需求就变得十分鸡肋,首先便是要将老板的需求放在最上,并找到理由来证明需求的真假。  总监的需求,几乎每个老板都会有几个合伙人,总监往往承担着产品的走向,就好比掌舵人,指引着前进的方向,他的需求往往更加贴合实际,能够切中问题的本质,但总监也不一定是对的,尤其是创业公司,一个牛逼的总监可以从“ 点 ” 推测出 “ 线 ” 甚至推广成 “ 面 ” ,俗称 “ 见微知著 ” ,而一些可能只是 “ 管中窥豹、可见一斑 ” 了,对于总监的需求,我们不需要考虑太多的方向,但是要将这些需求完善,达到一个可以执行的层面。 用户的需求,不是我说用户需求不重要,而是创业期用户对产品的改进真的没有那么大,对于他们的需求,既不能不管不问,也不能全盘接受,合理的去安排一部分的实现要根据用户的群体来进行划分。 同事的需求,每一个同事都代表着一个用户,一个不经常使用却实打实的用户群体,他们分别从各自的角度收集问题、看待问题、发表建议,技术说这样实现用户根本不会去使用;运营说,做了这个才能让用户用的舒服;交互说,这样的操作根本是反人类,要这样设计;测试说,哇这样问题真的好大。 产品经理是要根据他们所有人的需求,汇总整理,然后根据公司的情况、软件的核心、团队的水平来对需求进行分类划分,然后根据实际情况来去安排工作开展。

需求变动

上面已经说了需求的来源,但在实现的过程中,变动需求是一件很平常的事(但却是十分不好的一件事),改动一个需求可能会延长技术的开发导致前期工作白做、或是将现有的需求砍掉、甚至延长开发周期,总之一句“ 很难受 ” ,可是偏偏就得这样,你又没有办法,因为这些每一次变动都涉及到了用户(多说一句,不管怎么撕逼,只要搬出来用户,那就是占据了天时地利人和,好比搬出了天王老子来),谁能 “ 更 ”代表用户,谁就占领了主动,所以往往技术同学在这里最吃亏。 一个好的变动,在开发初期,制定的需求,经过需求评审可以通过,每个人也照常执行,但在当前版本中,一些需求没有满足用户(不好用),或是核心用户群体产生新的需求、或是产品的某个不起眼的功能得到了广泛的使用,这时为了保证用户的增长,变动一些不重要的功能,是十分必要的一件事。 一个 bad 变动,某些人异想天开,说这样可以可以,所有人脑子一热,都觉得可以,于是乎涛涛声响盖住了涓涓溪流,原本的计划走岔了方向,最终走进了死胡同。

如何保证需求变动兼顾技术开发

数据说话,哈!但是没有数据,怎么办。我的建议是“ 锯箭法 ” ,箭扎到了肉里,先把外面的杆给割了,留个箭头在里面。一个需求往往带动很多需求,求其一做之,并保留剩余。同时告诉需求来源,你看我已经做了最核心的了,再告诉技术,你看他们要求这么多,我应经帮你们挡下来这么多了,只要这一个开发出来就 OK ,所以安心干,我这边尽量不去干扰你们。 第二,去发现问题本质,为什么要这么做!这个时候,你要比别人先行一步,用长远的目光来看待这个问题,即使他是有错误,也要拿出东西来证明,无论是给出数据还是给出一个 MVP (最小可行产品),让他们意识到实际的情况。如果要照旧执行下去,最终的锅还是要产品来背。 第三,考虑技术实力,创业公司的技术人员,一般有一个牛就很好了,多数只是才毕业的大学生,写出来的东西也只能实现最基本的功能,想要跳多高,还要看看脚底下踩得的什么,而技术就是这块基石,特别的功能技术也会很懊恼,多次变动需求,最终也会逼走一个又一个的开发,毕竟每个人都希望开心的工作 最后,产品经理就好比一个阴阳,此起彼伏,而你要做的就是一个平衡。发现问题是一个产品经理成长的过程,错了不要紧,不管是到公司还是小公司,都会给你错的机会,只要你不怕出错,有改进和改正的能力,下次想法就会更加成熟。

记住,创业公司在最终只能有一个声音,如果有两个声音,那么必然会消失一个,所以在自己还没有到达那个位置之前,多学学韬光养晦、明哲保身的处事原则,适当的表示一下自己的存在感,这样才能在一个时期,一鸣惊人。

来源:网络

时间: 08-07

作为产品经理,如何有效应对需求变动和技术开发?的相关文章

产品经理如何做好需求挖掘

一.什么是需求 产品是用来解决用户的问题的,那么这些问题就是需求 例子:饿了么,解决用户不想出门吃饭,节省吃饭时间的需求 从互联网产品角度出发,需求就是:用户真正需要的,而不是用户想要的. 例子:我想要一匹更快的马,真正需要的其实是一个更快的交通工具. 二.为什么要做需求挖掘 挖掘到有价值的需求产品才更有前景 需求挖掘不够,容易产生拍脑袋需求,对公司发展不利 三.如何做好需求挖掘 来自用户:挖掘用户内心的想法和意图 来自竞品:竞品的功能给我们产生的启发 来自文献:文献提供的数据和趋势指明产品改进

如何向外行解释产品经理频繁更改需求为什么会令程序员烦恼?

你去饭店,坐下来.“服务员,给我来份宫保鸡丁!”“好嘞!”——————这叫原始需求 大厨做到一半.“服务员,菜里不要放肉.”“不放肉怎么做啊?”“不放肉就行了,其它按正常程序做,不就行了,难吗?”“好的您稍等”——————中途需求变更 厨房:大厨:“你大爷,我肉都回锅了”服务员:“顾客非要要求的嘛,你把肉挑出来不就行了吗”大厨:“行你大爷”然而还是一点点挑出来了——————改动太大,部分重构 餐厅:“服务员,菜里能给我加点腐竹吗?”“行,这个应该简单.”——————低估改动成本 厨房:大厨:“你

产品经理思维模型拆解——需求篇

文章地址:http://www.woshipm.com/pmd/357813.html.产品的设计就是产品思维的一种体现,通过场景化的需求分析方式.可以让你从面,到线,到点,去逐个做好每一块分组的功能.每一个分组里面,考虑会有哪些东西,为什么会有这些东西,然后再考虑,每一个功能事件,会引发什么样的后果,应该给用户怎样的一个反馈. 一.产品经理是个啥? 一句话:在平衡商业目标与用户体验的情况下,解决某些用户,某些场景下的某些需求的人. 再简单点说,产品经理就是解决问题的人. 二.一款产品的立足点是

收藏 | 产品经理不可不知的 7 种技术思维

我们常说,作为技术人员要有产品思维,从产品和运营的角度去思考技术方案.是的,我们也这样做了.然而,从我多年的需求沟通及项目协调的经验来看,产品人员其实也可以有一点技术思维. 所谓技术思维,并不是让你真的用技术人员的思考方式看待问题,那样肯定做不出好产品,两种思维方式是不可调和的.这里所说的技术思维,只是让你从某种程度上更加缜密地思考与技术相关的问题,如此既可以在技术相关的知识面上有一定积累,也可在一定程度上降低与技术人员的沟通成本. 互联网的产品人员,可能整个职业生涯都要与技术人员打交道.有些产

产品经理之待办需求

 计划2015年每天写一篇文章 由于文章编辑器的效率实在太低,所以选择演示文稿导出成图片 部分内容直接使用我在曾经北京航空航天大学开设的<移动终端用户交互工程>的演示文稿,同样效率原因因而直接贴图片 提问请移步 http://weibo.com/p/1001603812444957988505 计划2015年每天写一篇文章 由于文章编辑器的效率实在太低,所以选择演示文稿导出成图片 部分内容直接使用我在曾经北京航空航天大学开设的<移动终端用户交互工程>的演示文稿,同样效率原因因而

漫画:程序员,你能“管理”好你的产品经理吗?

一.第三选择 在工作中,你面对产品经理的各种需求变动.项目经理对关键点的 Deadline,总会有一些冲突发生.而对于事情最终执行的开发人员来说,如果这些冲突处理的不好,可能就会变成你个人的问题. 做为最终实现功能的程序员,你总不会想被贴上一个 "无法按时完成任务的开发" ,这样的标签吧? 这些问题,其实都可以借鉴第三选择的思想来解决.<第三选择>是一本书,作者是 史蒂芬·柯维,我想说到该作者的另外一本书,应该更多人能知道,<高效能人士的七个习惯>.而在<

产品经理如何与强势的技术沟通? 技术比较有资历,会以技术无法实现等方面的原因拒绝处理产品提出的需求。 你们是否遇到这样的技术? 产品懂技术的话,是不是会好一些,因为可以和技术说“行话”了,并且产品懂技术就不会被忽悠了。

PM在YY...作为强势的技术来回答一下吧.说明白WHY,HOW,WHAT就好了. 我想点两个赞,u can u up,no can no bb 什么的. 微软的win8之父年轻时候也是一个PM应该是微软最伟大的pm之一了吧.他有一天和程序员起了冲突,程序员说必须有两周才能干完,他说项目等不及了.就这样冲突一直没有一方让步,直至一周后,这个PM带着自己写的code给程序员看,他只用一周就可以这些功能.所以产品经理还是要懂一些技术才能和程序员更好交流 我觉得碰到强势的工程师是一件好事.同时,别人拒

产品经理的战场:需求评审会

因项目需要做需求评审,之前没有参与过类似专题工作,特地在网上找了些资料,感觉这篇还不错. [转载自互联网的壹些事] 你还记得自己参加过多少场「需求评审会」吗?不管自己是作为主机主导,还是作为僚机配合,「需求评审会」的现场都是让人不明觉厉.而产品经理就是在这一个又一个的「需求评审会」中磨练过来的,是一个真正刷怪升级的过程.据说「需求评审会」又名「撕逼大会」,你可以感受下这其中的画面感. 产品经理组织的「需求评审会」类似多方会谈,与会人员很容易进入角色后产生「自主」情绪,形成正反两派甚至是多派,最后

产品经理三大忌:瞎猜、自嗨和傲慢

本文和大家分享的主要是产品经理的三大禁忌,期望能帮助各位产品小伙伴们解决你们遇到的类似问题,或者避免类似问题的发生. 昨天,有一个入行不久的产品小伙伴,咨询了这样我一个问题: 自己在思考问题和提炼需求的时候,总是会自诩站在用户的角度去看问题,最终通过多次思考.梳理,提出自认为有效的针对性解决.实现方案,或者灵机一动想出一些点子觉得可以讨好用户,就非常高兴的排期实现了. 结果上线一段时间后,使用率很低,甚至有用户觉得是产品经理在自嗨.这让我觉得很沮丧,但是又无法反驳--因为即便是大公司,在做出来用