站在技术的角度思考
实习到现在,觉得产品经理不仅要做好自己手头的工作,分析好需求,更重要的是要和各式各样的角色打交道。我实习的公司是IT公司,当然最常见的就是和技术人员打交道了。怎么样和他们交流才更高效,更合理呢?
技术人员在乎的是什么?
曾经闲暇时和程序员聊天,旁敲侧击地问了例如“工作中你最痛恨的是什么”。然后仿佛他们也是憋了一肚子的苦水,于是乎blablabla说了一大堆,总结了一下大概是下面类似的几个场景:
-
辛辛苦苦做好的东西,因为种种原因(例如老板嫌你走路的姿势不对,fou掉了),白干了
-
自己用了很大精力做的东西(用了一个很牛逼的算法),被直接无视
-
被不懂或者半懂的人(例如部门小BOSS)对着自己做的东西指手画脚
-
脑洞开太大,因为技术或者设备配置等原因完全不可能实现的需求
所以,我们可以从这些场景中捕捉到他们内心深处真正的需求。用一个词来概括就是“自我价值”。他们渴望自己的劳动成果被采用,渴望自己的付出得到肯定和理解,渴望自己的能力得到体现和发掘,当然也渴望有可以有效沟通的人。
技术人员如何思考问题?
程序员整天和代码打交道。编程的思想,就是计算机的世界观。所以他们是如何思考问题的呢?
-
技术人员更加关心定量的东西,而不是留有想象空间或者描述性的东西。
-
技术人员更关注按照需求实现出来,而不太关心需求之中是否还欠缺了什么细节。
-
技术人员更希望听到哪些异常需要他们去处理,而不是哪些异常不需要他们去处理。
其实技术人员是一群可爱的人,他们想法其实很简单,他们的世界也很简单。他们不会轻易来质疑你的想法是不是靠谱,他们只会在逻辑或者流程上走不通,不清晰的时候才来找你寻求解决方案,只有在涉及到其他技术人员的代码的时候,才会来让你帮他们询问技术方面的细节。
他们不希望在代码实现之外的层面上思考问题,他们只是希望你告诉他们做出来的东西需要是什么样子的,并且,说清楚,说清楚,说清楚。
如何照顾到技术人员的想法?
所以对于我们来说,和技术人员探讨的问题,更多的集中在需求是否可实现的层面上。也许有时候一个我们看似很简单的问题,在代码那边就要涉及到很底层的架构的改动;也许有时候一个我们看似非常牛掰的方案,代码实现出来也就是一行。
也许我们没有办法完全了解技术人员的工作内容,我们至少可以站在计算机实现的角度和他们探讨,在做之前先打通各技术模块之间人员的关系,然后确定最终的需求,尽量避免什么都不了解然后发现做不出来之后再来改。
当然,作为经常要和技术人员打交道的产品经理,我觉得懂一点编程是有必要的。你可以了解更多他们思考问题的方式,清楚他们实现过程的关键点(主要是涉及到不同技术人员或团队之间需要互相调用的接口或者数据),然后可以在出现问题或者技术人员出现瓶颈的时候,及时地沟通好相关的人员。
其他
前面都是废话
作为一个合格的产品经理,大家平常还是要……多健身多锻炼身体,真正碰到问题的时候,一大波技术人员上门来找你了,挨顿揍……才不至于太疼……疼……疼……
而且,有时候还可以揍回去。
当然实在是情况紧急的时候,高喊一句“PHP是世界上最好的语言”来脱身,也不是说不可以……哈哈