做过程序员的产品经理是一种什么样的存在? - 开源中国社区
做过程序员的产品经理是一种什么样的存在?
oschina 2015年12月02日

做过程序员的产品经理是一种什么样的存在?

oschina oschina 发布于2015年12月02日 收藏 121 评论 32

【编者按】本文作者刘飞,前锤子科技产品经理。

做过程序员的产品经理是一种什么样的存在?

记得之前参加团建活动,是真人 CS。我们一共没几个产品经理,但有几十个程序员。所以场面估计你也能想象出来了......并不是刺激的对战,而是惨绝人寰的群殴。

被 BB 弹打成狗(哎,原来不就是狗吗)的一个产品经理急中生智,大喊:『我以前也写过代码!我是自己人!』

其他正在施暴的程序员面面相觑,表示十分感动,但仍然拒绝了他的求情,继续按在地上打了半个小时。
......

我在哈工大读书,学的是计算机,写了六年代码,毕业后做的却是产品。

所谓对程序员和产品经理之间的调侃,主要原因无非就在两方经常有矛盾出现,而矛盾出现显然是因为双方一边是需求提供方,一边是需求实现方。矛盾的类型也简单,就是大家提到的这么几种。同时写过代码,又做过产品的我,实际上仍然没有很好的通用法则,能解决所有矛盾。

不过做过产品总监一职后,的确理解完全不同了。产品工作和研发工作都是我的管理范畴之内,看事情的角度就完全不一样。

做过程序员的产品经理是一种什么样的存在?

过去做程序员,总觉得提供的需求更改很烦、给的需求不合理很烦、给的截止时间不合理很烦。

做产品经理的时候,也会觉得程序员总是推卸责任、完成得不及时或者不够好。

其实从整体的工作配合上来看,出现问题是难免的,关键是如何预防、如何解决。

......

以下是一些切身体会得出的经验性建议:

对于研发人员:

1. 做好更改需求的准备

很多固执的程序员会把改需求当成错事。

改需求?你怎么不早想清楚?
改需求?你知道我工作量多大吗?
改需求?那我不干了。

实际上,在互联网产品这个领域内,改需求肯定会是家常便饭。

我没有做过统计,但我接触到的已经成立一年的公司,几乎都经历过大改版,也就是代码全部重写。这对研发团队来说自然很痛苦,但却是不可避免的。

互联网的需求更替是频繁的,一方面是大环境随时在发生变化,去年你还在刷微博,今年已经是朋友圈了。另一方面,需求获取的渠道也是多样的,产品经理可能会有新的发现和新的判断,未必都是之前没想清楚。

当然,如果需求都是老板从什么《易经》中得到感悟、从云卷云舒花开花落里得到启示,让你手忙脚乱给他改来改去,那也没意思了。

既然改需求是经常会出现的,那就要求还是得做好更改需求的准备有这么几种方法:

1.1 提高代码的可复用性、可扩展性等等

让一些产品中很可能会用得到的各种控件、功能模块做成可复用性很强的代码,在产品增加类似功能,或者修改原有类似功能时,将会大有裨益。

可扩展性则是各种接口、数据库以及底层结构不要写死,尽量用可扩展的方式写。比如现在有五个分类,不要写死就五个,要写成 n 个分类,目前是五个。嗯,这是常识了,但有的程序员还是会比较随意,写代码没有远见。

其他的代码特性,如果有利于降低产品的更改和优化成本,也要加深关注。

1.2 根据产品规划来做好充分准备

每个功能的实现方法都有很多,怎么选择并不是只看当下的成本如何,而是要关注未来产品的整体规划。

可能目前要完成功能 A,有 1、2、3 多种方案,方案 1 成本最小。但未来要完成 A、B、C、D 很多功能,方案 3 更有利于整体成本最小。那就要选方案 3 未雨绸缪。

多跟产品团队交流,了解未来产品要做成的样子、哪些功能会是必须的、哪些功能是可能会有的,多从长远来看。

1.3 合理预留出修整的时间

首先,不要把研发时间就当作完成时间。研发功能只是一部分,测试、改 BUG 以及处理意外情况的时间都要预留出来。

有两种情况要多预留出修整的时间。

一种是研发团队自己对功能没有把握,可能是全新的功能,可能是比较难做的功能,可能出现许多 BUG 和功能实现糟糕的情况,那就要多预留出时间。

另一种是产品团队表示对功能也有疑虑,比如在提供需求时表示这个功能很有可能要调整,或者对功能本身信心不足,那也要多留时间做调整。

2. 理解需求,防止返工

研发团队通常会缺少对需求的理解,尤其会出现这种情况的就是外包团队。我听说过太多花了几十万请外包团队,结果开发的结果特别不满意,不能拿来用。合同又已经签好,还得给钱,就是赔了夫人又折兵。

有的技术团队和产品团队都坐在同一间办公室了,居然都经常缺乏沟通。技术团队不知道当前做的功能是给谁做的、是提供什么功能、满足用户什么价值的。

这些不是很高深的理论,也不需要深入学习,只需要通过产品经理做些了解,就能少挖一些坑,也就不会轻易返工。

比如,有的产品页面可以是提前加载缓存,也可以是每次都刷新,但要看用户平常是在 WiFi 环境下用还是在移动数据下用,这是产品经理清楚的。产品经理在功能细节上不会想到实现层面这么具体,所以就需要研发团队去理解刚才说的需求,做一些判断。

另外,如果是在开发之前就意识到做出来的功能会跟产品经理想象的不同,那就必须及时提出来,千万不要等开发完成,大家都觉得不靠谱,再重做,那样不管对谁来说成本都太大了。

3. 善于用数据、理论以及通俗的解释来进行沟通

程序员最应忌讳的就是说『这个做不了,说了你也不懂』、『这个太难,懒得跟你解释』。产品经理听完肯定会觉得是推卸责任。

正确的方式是:用通俗易懂的客观事实来解释。

嗯,这个弹窗做不了。

为什么现在做不了?是因为代码实现可能要花三个月。

为什么这么久?是因为需要调用底层驱动层面的东西。

为什么要调用底层驱动的东西?是因为安卓系统原本的框架和协议就是这么定的。

如果想看协议,我可以给你找出来。

这样一步一步往下解释,把所有理由说明白,别没有耐心,只要产品经理是讲理的,他会理解你。

他听懂了你的解释,也会有利于他找出另外可接受的一种解决方案。

哦,我懂了,这个用弹窗形式太复杂。

那我们换作跳转到普通页面吧。

这样问题就解决了。

对于产品:

产品经理要在不断的迭代和更改需求的风险中被程序员认可乃至尊重,我觉得最重要的还是『讲道理』。切忌说出『我不管,反正得做完』或者『老板就这么定的,我也没办法』这样的操蛋话。

1、对产品功能有规划,并提供给研发

对自己的产品都没有大致规划,是产品经理的大忌,也是出现问题的主要原因。

一年后产品成熟了要给用户解决怎样的问题?
未来半年内产品要做成什么样子?
三个月内产品应该主要提供哪些功能?
这一个月的产品具体方案是做哪些?

这些都要认真去考虑并且规划。

当然,长远的产品规划在很多情况下(市场变化、团队更替、产品转向)确实用途不大,但越短期的规划,对研发团队越有帮助。

正常来说,预估三个月内产品的功能还是完全可以的,除非老板和产品经理都没想明白产品到底该做成什么。

把这些规划想明白,并传达给研发团队,让他们在现在的代码里就给未来的功能留下空间,是最好的避免代码重写的方法。

2、提供需求要足够具体

这要求产品经理做到两点:

第一,让产品需求文档特别特别具体。

具体并不是说,要按照大公司的 PRD 去完成。而是说,不要缺东西。对于需求文档来说,页面逻辑、页面布局、功能逻辑和每个功能的使用细节,都要存在。并不只是画个交互图就叫需求文档了。

你给了研发 5 个页面,结果研发做着做着,来问你,好像缺了个页面。你补完一个,研发做了一会儿发现又缺了一个...最后七零八碎的 10 个页面拼凑出来,发现根本不好用,所以又推倒重来。

如果研发经常来问你某个地方该怎么做时,你就要反思是不是需求文档写得不够好了。

第二,要说明每个需求背后的原因。

这个在上面表达过,程序员明白了需求背后的原因,会选择更合理的方案去完成。

千万别提『你别管为什么了』,而是不管他问不问这个功能为什么要做成这样,都要告诉他为什么。

3. 熟悉基本的研发背景和研发能力 

『产品经理到底需不需要懂技术』是我被问到的关于产品经理的问题中的 TOP 5。

这个问题我的回答是:要按照需求,了解基础知识,并不需要知道实现细节。

了解基础知识、不需要知道细节是指产品经理应当知道最基本的一些理论。

比如做安卓操作系统,要知道安卓原生提供了哪些控件,这样在设计方案时可以尽量使用它们。在代码实现时,调用一个控件可能只需要几行代码,但自己重写一个功能界面,可能就是成千上万的代码量了。

比如是在手机网页上的产品,要知道哪些交互是在 H5 上较容易实现的,而哪些交互是实现效果非常糟糕的。如果依照在 iOS 上的动画效果来要求 H5,开发成本可能会是指数级上升的。

按需,是说对于产品经理,千万不要买《iOS 入门指南》、《安卓开发手册》或者《H5 设计实例》来学习,除了装点下书架不会有别的意义。

因为本身开发的指南和手册,讲述的全是实现细节,对你清楚安卓的基本控件或者 H5 的常用交互完全没有帮助;同时,不同的产品有不同的特性,也有不同的代码特点,你只需要了解你负责产品的技术背景即可,有的同学居然决定从 C 语言先开始看,简直是让人扼腕。

以上是我的一些理解。希望对大家能有所帮助。

via 雷锋网

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:做过程序员的产品经理是一种什么样的存在?
分享
评论(32)
最新评论
0
你说的太对了,对于可扩展和可维护性强的代码成本是比较高的,但是后边的维护和扩展是一种幸福的感觉,而不是焦头烂额,需求沟通是第一部要做好的!
0

引用来自“AllenBlock”的评论

完成扩展性强的代码 花的时间比直接实现当前需求的代码 多好多啊...
虽然都知道,我现在花一大段时间,可以让以后节省很多段时间,但是时间不等人啊.
就好像,环境保护,官员知道很重要,但是,政绩的要求,执政的时间,凡事难以尽善尽美.
0
完成扩展性强的代码 花的时间比直接实现当前需求的代码 多好多啊...
0
文章不错,我居然全部看完了。
0
最蛋疼的,需求提出来,开发说这样做比较好,需求说按我的来你只管做,结果还没做完需求就说还是按你的来吧。
0

引用来自“blu10ph”的评论

有请 @小瓶盖儿 现身说法~
运气好遇到一群技术大牛就万事大吉
0
<p>程序员也很辛苦的,每天没完没了加班,不加钱谁做。</p>
0
好的产品经理不懂代码的有几个?我真想了解一下这些人。
0
银子给足了 都好说
0
上班总是要做事的,不论是改需求还是新功能。但是是一边改需要,一边催新功能,一边要修bug。加班加点,没加班费。管你什么理由?我都不乐意
0

引用来自“三月-惊蛰”的评论

明天上线
这 具
个 体
功 实
能 现
很 我
简 不
单 管
马上要提交上线了!
老板来看:这个感觉怪怪的~那个不应该这样子~。产品狗:汪汪,老板英明啊!马上叫开发那边改!
凌晨时分。
产品狗:还没改好吗?怎么那里又出问题了?
第二天。
老板:怎么还没上线?昨天不是准备上线了吗?
产品狗:又发现BUG了,攻城狮还没修好。
攻城狮:..zZ(梦中,女产品经理乱改需求,惨遭攻城狮NP凌辱.avi)
0
有请 @小瓶盖儿 现身说法~
0
说实在的本来100天搞完的活,然后你跟我说10天后要,我就不信能出什么好产品。需求什么的都不是问题,就是给个相对宽松的时限和严格的技术规范就能避免很多不必要的问题。一旦赶时间,那就啥都不要说了,没用
0
万事可商量 就像做买卖 生意是谈出来的
0

引用来自“uller”的评论

以前做开发的时候我们经理问我如果我当项目经理最关注项目代码中什么东西?我回答:“数据结构。”,结果那个经理给了我一堆算法程序的项目让我做(分布式多线程蜘蛛、fastdfs客户端协议封装...),过了一段有问我同样的问题,我回答:“沟通”,然后经理让我做项目经理了。沟通目前仍是我最关注的问题,遇到菜鸟你要用沟通引导他写出高质量代码让他理解什么是高可用高扩展,最愉快的是遇到老手我们一起忽悠出一个符合需求易于维护项目。
这个好
0
据我同学吐槽,某XX网络公司,上层是做销售的,管理开发的,某次周末2天,开会开了2个早上,说让周日出demo,当时就他一个能做java的,其他人都是其他项目抽出来的,有些做C的、嵌入式的,然后他加班加点写了几千行代码赶出来一个的demo。经常加班,以“发掘个人潜力”为理由,真是哔了狗了,这个功能不是很简单?
然后一些页面,只要看到某个功能,就想加进去,臃肿得跟什么一样,什么东西都要在一个页面看到数据
0
对而没用的。即使程序员考虑了需求变动,但是为了需求变动而写的代码,一是不一定会用到。二是必然增加了耗费的时间工作量。——上面会同意吗?如果决定权不在开发手中,那和开发还有什么关系?
0
不错 有点感触。
0
以前做开发的时候我们经理问我如果我当项目经理最关注项目代码中什么东西?我回答:“数据结构。”,结果那个经理给了我一堆算法程序的项目让我做(分布式多线程蜘蛛、fastdfs客户端协议封装...),过了一段有问我同样的问题,我回答:“沟通”,然后经理让我做项目经理了。沟通目前仍是我最关注的问题,遇到菜鸟你要用沟通引导他写出高质量代码让他理解什么是高可用高扩展,最愉快的是遇到老手我们一起忽悠出一个符合需求易于维护项目。
0
产品经理还是懂技术的好,至少到时候程序员会问什么问题 自己在做PRD的时候会想到。程序员问的时候也知道他们的心情 需要怎么安抚~
顶部