胡言乱语谈产品管理(5)-我是如何对待需求的

最近两篇的文章都是在讲我对需求的一些认识和想法,在第三篇中讲了“需求的来源和分类”,在第四篇中讲了“如何进行需求管理”,有朋友通过站内短信给我留言,说“想了解的更详细一些,希望能让我举一些例子”,我看了看第三和第四篇文章,确实是,太过于表达自己的想法而缺少实例了,那今天这篇文章就重点以讲述亲身实例为主,说一下我经历过的公司在对待需求时的现状都是什么样子的。

大家就当是看故事就可以了,如果大家有类似体会,就留个言,谢谢支持我的朋友们。 

实例一:当市场端面对需求时……

有一次,有个用户向市场部门提出了一个他在产品使用过程中遇到的一个问题,这个用户算是我们的重点用户吧,市场也非常重视他的意见,因此,立即就过来人把这个意见反馈给了我们产品部,我们负责这个产品的产品经理也进行了记录和说明,早上市场部提的问题,刚到下午,就打过来电话,问“问题是否解决?”

那个产品经理很纳闷,这才多大一会功夫,那能解决呀?于是就告诉市场的同事,说“这个需求已经记录入库,在分析、排级后会和技术部门沟通进行解决的。现在正在进行别的项目,暂时无法解决。”

市场那边没说什么,然后一个电话直接打到了我这里,向我阐明了各种厉害关系,然后非要我定一个明确完成的时间,否则会向上面投诉。

说真的,我不是一次遇到这样的事情,每次最终的解决方法就是上面出面,然后临时调整资源来解决这个问题,闹的研发的兄弟们抱怨不断,因为他们是按项目制来走的,临时加入的一个项目少则1、2天,多则4、5天,会对正常进行的项目产生很大的影响,虽然他们会填单来说明这个事情,但是这种对研发兄弟心理上的影响不可低估,他们总和我抱怨“以后不要随便加项目进来好不好,工作思路总是被打断”,我说“我有什么办法,难道我不知道对全局的影响!”

这是一个明显的例子,尤其是在市场端的需求中,很普遍。我分析了一下,主要是几种情况造成的:

1)针对的直接用户不一样:市场面对的直接目标是客户,就是说,客户是他们的“衣食父母”,因此,你可以看到,每天市场部的同事,大部分的工作就是在维系客户,发展客户,尤其是在一些直接做企业客户的公司里,更为明显,例如B2B企业,一个个sales对客户就像亲人似的,而对于产品、技术的同事,则一个个板着脸,他们当然有牛的资本了,按照他们的话说“我一个月能给公司拉几十万的单子”。而我们呢,直接的目标客户其实是市场部门,例如BD,例如sales等,我们把可销售的产品给他们后,通过他们的工作来为公司换取利润。

因此,市场部的同事对于客户的意见简直奉若圣旨,用户提一个P大一点的需求就马不停蹄的要求产品、技术部门放下手头任何工作去给他解决,无论你现在手里有什么工作。

2)不懂产品,不懂项目。当然了,这是部门职责和职位要求决定的,市场人员的根本目标就是把产品卖好,一可以为公司挣钱,二可以自己挣钱,因此,获利是他们最直接的想法,而产品和技术呢,没错,我们做出的产品要靠市场的同事去完成交易,因此,我们考虑的第一目标是推出一个好的产品,这种在直接目标上的思想差异就造成了,我们是在从产品和项目的全局在考虑问题,而市场则是从是否会影响公司和个人收益来考虑问题,当然,我个人完全可以理解市场同事的压力,我也做过一段时间市场,确实压力很大,因此,他们把全部的精力投入到市场工作中就和我们把全部的精力投入到产品上一样,但这恰恰就成了问题,同一个问题的看待角度不同,必然会造成分歧。

3)看表面而不看实质:做产品的朋友经常会遇到这样的情况,市场提出了一个问题,然后在最后总会问一句“今天能做完吗?”

因为在他们眼里,在用户提交数据的时候加一个表单项,不就是多一个文本框吗,很容易做的呀?这就是他们对产品和技术的真实认识,我接触了不少这样的市场人员,有些人还仗着自己懂一些互联网技术知识,非常肯定地告诉你“这个问题一天时间绝对能搞定”,你和他解释一下吧,他还说你托推责任,别欺负他不懂。

我真的没办法了,他说什么是什么了,因为这个时候,你去和他多说一句,他都会认为你在讽刺他。甚至包括一些市场部的高层都是这样认为的。真的很无奈。

我不止一次的被叫到老大办公室,告诫我要一定配合市场部的工作,老大说话了,我还能说什么呢?

谁让人家市场部天生优越感就强,全公司这几百号人就指人家给挣钱呢。

实例二:当技术端面对需求时……

我承认,在我们公司,产品部的任何一个人在技术层面上,尤其是在实现细节上确实不如研发部的兄弟们,毕竟各自部门的工作侧重不一样,因此,每次和研发的兄弟们讨论需求时,我更愿意多听他们的意见,毕竟这方面,他们是专家。

但是,在我接触的公司里,有这样一种情况,不知道大家经历过没有,就是:研发部的兄弟普遍认为技术造就了产品,因此,他们在听取产品部的需求时,总是漫不经心,觉的说的都是废话,他们早已对要做的产品胸有成足了,在最后表态的时候,他们会说信誓旦旦地说“没问题,技术上没有问题,只要你们想得出,我们就能做得出”。

既然都表了这态了,咱们产品部的还能说什么,毕竟实现的技术细节不是咱们要考虑的,于是,我们非常放心地把PRD交给了研发的兄弟。

但是随着研发的不断进展,各种问题开始出现了,一会说这个功能实现起来可能会有问题,一会说要达到设计的目标,可能要延误项目周期,我想,这个时候产品经理就是最麻烦的时候了,因为项目周期已经报到了高层,市场部的同事都已经开始按照研发完成的时间做市场准备了,如果到时候完不成,第一个跑不了的就是产品经理,理由有一个就够压死你了:为什么一开始的时候不和研发沟通好?

这可真是冤枉死了,在开发之前,会没少开,话没少说,文档没少修改,大家都是签字画押的,为什么出现问题的时候,把主要的责任推到产品经理身上了呢?

研发最初在讨论产品需求的时候,说的话到现在还在耳边萦绕呢,可惜的是,没拿录音笔给录下来作为陈堂证供。

怎么办呢?这个时候的主动权已经在研发手里了,只能根据研发的要求要么缩减功能,要么增加人手,要么凑合做出一个不符合PRD定义的产品来,但不论如何做,最终出来的产品都和PRD无法报纸一致,甚至市场期望的特点都不能充分满足,这下市场的牢骚就多了,“什么烂产品,让我们怎么推呀?”,见了你,还不冷不热的讽刺几句,那个时候,产品经理还能说什么呢?谁让你是产品经理呢!

这绝对不是个例,大家回忆一下,在大家的工作中,尤其是做软家和互联网产品的朋友,有没有最终出来的产品能和PRD定义的完全一致的,哪怕是90%一致的都算你成功了。

几乎没有,我承认这是一种普遍现象,并且也是无法完全改变的,就连VISTA都不能如期上市,微软的开发规范和流程算标准了吧,也不能完全避免。

但是在这里,我要强调的问题是“研发的同事对待需求的态度是否可以再认真一些。”

是的,没错,产品经理想的再好,也要靠研发兄弟的辛勤工作来实现,产品经理在技术层面上也确实没有你们专业和精通,但是,千万不要简单的认为“产品=技术”,认为对技术的熟悉就是对产品的熟悉,认为经常提出一些专业性的知识问住产品经理就说明比产品经理更懂产品。

我想,正是出于这种想法,才让研发的兄弟对产品经理提出的需求满不在乎,不以为然,“连产品的技术实现细节都不知道,还和我谈产品”,当产品经理想问一下“为什么”的时候,他们通常的态度就是“简单的说几句,然后告诉你‘你不用了解这些,告诉我做什么就行了,我来考虑。’”。

实例三:当全公司面对需求时……

我之所以来这家公司,就是因为我看到他们对产品管理体系的重视,希望我能建立并运作起来,我也尽了我的力在做,通过一段时间的工作,在部门规范,工作流程,工作制度上都有了起色,从我的想法来看,我倒是不奢望能在几个月时间里有什么翻天覆地的变化,当然,这也是不可能的,只希望能首先在公司几个主要业务部门里有一种规范的思想即可,改变现状,首先要改变的是思想的认识。

还说需求,在第三篇中,我讲到,我们公司需求的来源主要是三方,因此,我设计了一个需求来源接口,就是要求需求的来源一定是“文档化”的,这样有几个好处:

1、可记录:每个需求来源文档都是明确的,谁提交的,提交时间,需求类型,需求说明,产品经理可以根据提交的需求文档来找到源头。

2、可继承:如果说产品经理发生了变化,那么,这种需求不会因为人的变化而发生中断,后继者可以很快地知道要负责产品的需求都有那些。

3、易管理:需求的提交,我要求产品经理是进行分类管理的,这样,就不会使需求杂乱无章,一旦需求多的时候,也能迅速找到各个需求。

但实际的情况真的很糟糕,虽然规定统一的需求反馈入口,但是就好了几天,然后就和原来一样,打电话的,发邮件的,面对面的,当然了,也有用文档提交的,但通常都是通过其它方式反馈了,然后才想起来用文档提交,还不好意思地问我一句:是不是需要补个文档呀?

真是哭笑不得,当然,通过这些现象,也更让我意识到,公司的规范化建设还任重而道远,不在思想上让全公司重视起规范的重要性和必要性,建立产品管理体系只能是一句空谈而已。

而这种阻力既有上面的,又有下面的,怪不得我党经常要开整风大会,开统一思想大会,毕竟“只有认识一致了,思想统一了,才好办事”。

上面提到的几个实例,分别是从市场端对需求的认识,技术端对需求的认识,和需求的规范化来说的,后来我发现一个有趣的现象,就是“市场部对需求太重视,研发部对需求太轻视”,搞的我们这些做产品管理的人,里外难做,你和市场的同事解释需求吧,他们会说你“千万不要轻视用户的需求,用户就是上帝”,当你和研发部的同事解释需求的时候,他们就会说“用户的需求能有多复杂,他们懂什么!

一人一把号,各吹各的调,我们做什么,拿起小棒当指挥,音调一致响彻云霄。

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址