产品汪和程序猿的相处之道:以身作则,以德服人

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

如今的互联网有个传说中很神奇的职位,叫做「程序猿鼓励师」,据说都是童颜巨X的妹子;今天看到一个文章,某公司程序猿过生日,请了好几个身穿比基尼的俄罗斯外模(如下图所示);更不用说某互联网公司年会请岛国女优的事情了。

QQ20160120094837

好像程序员给业界的印象通常都是:死宅,萝莉控,难以沟通,通常非常难以合作。特别是对于产品经理来说,好像必须哄着程序员干活,得用尽各种办法哄,否则程序员不配合。我其实一直很奇怪,程序员群体究竟怎样被妖魔化成这样的。

前几天carol写了一篇非常棒的文章:「技术人员愿意亲吻怎样的运营?」,这篇文章从运营人员角度去谈怎样和程序员合作,我也推荐给产品经理看,因为道理都是一样的。我就从产品经理角度再补充一些建议:

产品经理和研发共同参与产品设计

一般的产品流程都是从产品需求搜集,到产品原型设计,这个阶段都是产品经理来执行,然后产品经理把原型交给视觉设计,视觉设计出高保真的设计稿,最后交给程序员开发。

在这个产品经理,视觉设计,程序员共同参与的产品生产过程中,程序员是最后的环节,当程序员在代码实现的过程中发现了产品逻辑的错误,或者产品设计的问题,是非常被动的。这个时候程序员再要求产品经理更改设计,修正产品交互逻辑,产品经理通常的反应就是:「程序员又和我讨价还价,产品deadline又要延后了」,跟着双方就开始剑拔弩张的对峙。

我在带团队做产品的时候,从产品立项一开始,就召集产品经理、视觉设计、研发负责人、运营负责人、运维工程师一起参与,把产品的目标定下来,然后让大家各自从自己工作分工的角度去讨论产品需求,产品功能,产品应该采取什么视觉风格,产品实现是否有难点,产品部署需要预先考虑些什么等等。之后每周产品例会都会召集大家一些开会讨论产品进度。

尽管产品立项之后,是由产品经理负责搜集和定义产品需求,整理产品逻辑规则,设计产品原型稿和交互,这个阶段并不需要程序员开始写代码,但是从一开始就让程序员,运营,甚至运维工程师都参与进来,是非常有益的:

  1. 程序员从一开始就了解了产品的来龙去脉,对产品需求和产品要达到的目标非常清楚,这样在和产品经理的配合中,就非常容易理解产品经理提出的很多功能要求,沟通起来非常顺畅;
  2. 程序员从一开始就参与,并且持续参与产品设计的过程,最大的好处在于从一开始就可以纠正可能出现的产品设计逻辑错误,以及评估技术难以实现的产品功能。这样等到真正进入开发阶段,研发周期是非常可控的,基本不会出现延误。
  3. 一些有良好产品意识的程序员,可以帮助产品经理从一开始就完善产品逻辑,从实现上修正产品可能遇到的问题,让产品开发过程变得更加有保障。

很多产品经理犯的一个重大错误就是:直到原型稿交互稿定稿之后,才交给程序员,之前全无沟通,然后逼着程序员立刻评估一个精确的开发周期。

这个时候程序员内心是非常抗拒的。一来我完全不了解这个产品,不知道做这个产品是干啥的?能够解决什么问题?是否有更好的替代解决方案;二来我也不清楚这个产品逻辑是否有需要调整和修正的地方,以及有些技术上需要投入很多资源但是不划算的功能。

所以程序员通常只能硬着头皮估一个时间,然后实现过程当中一旦出问题,就是双方互相扯皮,互相推卸责任。

产品不是产品经理的,而是大家的

互联网公司通常是产品经理负责制,产品经理往往认为我是这个产品的owner,你们其他人都是配合我工作的。但其实除了创业者CEO自己就是产品经理之外,通常大公司的产品经理并不真的是产品的owner,不具有对产品最终负责的权利。这个时候就产生了认知的错位和工作对抗:

产品经理认为:你们都应该听我的指挥,我是产品的owner,你们都要配合我的工作。但是程序员会想:我凭什么听你指挥?我还有我的上级领导呢。我和你就是平级关系而已,我又不是向你汇报,你凭什么对我颐指气使?

在这种情况下,产品经理应该传递一个信息:产品是大家的,需要大家共同合作,一起努力把产品做好,无论是产品,视觉,研发,还是运营,大家都是为了一个共同的目标而努力。我作为产品经理并不天然具有命令大家的权力,如果大家愿意听从我的意见,那也是因为我更加努力,更加专业,做出的贡献能够得到大家的认可。

你真的需要这个功能吗?

产品经理面临最大的自我拷问就是:「你确定你真的需要这个功能吗?」。产品经理提出一个功能需求是很容易的事情,不浪费什么资源,可是一个功能一旦确定需要做,后面跟着的就是大量的设计,开发,测试,以及产品上线无休无止的维护工作。

另外一个特别常见的现象就是一个功能开发出来以后,很快又抛弃掉了,改过来改回去。而产品经理通常又不需要为此决定而买单,擦屁股的都是程序员,所以这也是非常招人恨的原因之一。

好的产品经理总是在思考应该再去掉哪些功能,而不是毫无节制的添加产品功能。即使添加一个功能,也要再三拷问自己,真的需求吗?真的必不可少吗?

不需要懂技术,但是逻辑要严谨

其实产品经理并不需要懂技术,很多优秀的产品经理也并非技术出身,但是产品经理必不可少的一项基本功就是:逻辑要严谨。因为一旦产品经理思考不周全,或者产品逻辑出现了自我矛盾,最终都是程序员要为此买单,要么产品功能实现不下去,要么到处都是漏洞,程序员变成了救火队长。

产品经理犯的错误,最后买单的都是程序员,这也是为什么一个差的产品经理通常很招程序员恨的主要原因

以身作则,以德服人

产品经理可以是很忙碌的,也可以是很清闲的。

什么叫做清闲的产品经理:等着用户(或者客户)反馈bug和问题,整理到工作任务列表,指派给程序员,然后定期监督程序员工作完成状态。新的产品立项,画个简单的原型线框图交给视觉,然后催着程序员定deadline。

什么叫做忙碌的产品经理:主动找用户(或者客户)做访谈,搜集产品反馈,根据产品反馈,思考产品未来的改进方向;将用户的反馈和自己的产品规划定期和程序员沟通,大家一起商量制定产品迭代改进的roadmap;仔细钻研产品界面的每个元素,动手画出高保真的产品原型和交互,罗列产品每个分支逻辑,以及异常处理流程;整理产品的所有功能点,设计完备的测试用例,并且在产品的每个发布点做详细的完备的测试验收工作;和程序员每周定期沟通,互通有无,推进产品开发进度。

如果你是一个清闲的产品经理,只是动动嘴皮,敲敲键盘,那么你的价值在哪里?你怎么可能取得程序员的信任?如果你是一个忙碌的产品经理,你承担了产品大量的工作,成为一个产品事实上的灵魂,程序员怎么会不喜欢不配合你呢?

一个产品经理如果能够做到以上几点,我相信一定能够成为程序员非常喜欢的产品经理。其实程序员这个群体和任何其他群体没有什么特别的不同,也不是真的需要什么程序猿鼓励师,需要产品经理哄着才能干活。说到底其实就是一条:踏踏实实做好自己的本职工作,才能赢得程序员的尊重。

 

作者:范凯(robbin),微信公众号:技术创业空间(ID:itstarter)

本文由 @微信公众号:技术创业空间 授权发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 想起以前凡二项目,就是这样的模式,此外,作为leader的产品经理,同时也是技术的老大,因此技术GG们都是灰常配合,其他项目的人都羡慕我们的技术脾气好;技术真的赞 :roll:

    回复
加载中