产品经理到底要不要懂技术?
小婧隐匿在好几个产品的QQ群里,发现“我到底要不要去学技术”这个问题经常被提及。
加了好几天的班终于把需求和原型整理出来了,做需求对接时,开发直接丢过来一句“做不了”。
你傻了,顺口问“为什么啊”。然后开发就开始和你噼里啪啦的爆一大堆你听不懂的名词。
看着你一头雾水的样子丢下一句“说了你也不懂,反正是做不了”,然后挥一挥衣袖,走了。

小婧是计算机专业毕业的,上大学的时候立志成为一个优秀的程序猿,并且考取了中级程序员证书。
嗯,这证书考完了基本上就没有用上过…… 所以,我并没有太多和程序猿沟通障碍上的问题。
那么你的结论就是产品经理还是要懂技术了咯?
没那么简单。
有这样两个问题,首先要明确一下:
1.你说的技术是什么技术?C,C#,JAVA,HTML,SQL还是什么?
2.你说的要懂,是懂到什么程度?听得懂?看得懂?会独立编写?
上面的两个问题没有弄清楚,一切都是白搭。
那小婧今天就来和你把这两个问题理理清楚。

产品经理对接研发主要的任务就是把业务和解决方案定义清楚了,提供必要的输入给开发进行设计和开发。
在功能开发完成后,对产品功能进行验证和接收。
首先,你在做业务分析的过程中,
会使用到技术的部分吗?使用的是什么技术?
好像并没有吧?
有人说,需要做技术可行性分析。
没错,可是技术可行性的分析是产品经理的职责范围吗?如果你说没问题,可以作数吗?
在真正开发之前,肯定需要做需求和方案的Review(我非常不喜欢评审这个词,感觉就是在走形式)。评审评的是什么?其实就是一种宣贯,让研发团队知道接下来的日子要做什么事情,大家是否理解了,这件事情有什么难度,如果有难度是否需要做技术预研……
产品经理在这个会议上主要负责讲解自己的方案。而且我建议你将为什么这么设计,主要是为了解决用户的什么问题也做个介绍。这样才能保证整个团队的思想和观念是统一的。
接下来不知道你们会不会有可行性讨论会,或者设计评审会。基本上这类会议上,研发人员是主角,产品经理主要是在一些对象设计上从业务的角度上给一些建议。保证没有偏差。
这个时候负责任的研发人员会绘制类图、E-R图等。问题来了,你能看得懂吗?听得懂吗?这些面向对象的设计方法其实不属于纯技术的领域。如果你对UML或者数据库有基本的了解,应该是可以听得懂的。
而且在有的公司,像构件图、类图之类的和业务流程图、用例图、状态图都是需要由产品经理来绘制的。
所以,你看至少在这个过程上,产品经理是不需要懂技术的。
那在功能开发完成交付前,产品经理进行验证接收的阶段呢?
你基本上会在纸上或者脑子里写一个脚本,即验证的路线。大部分也都是表现层的验证。但是,在这里有可能会需要你到数据库里去查询一些数据是否正常存储了(如果前端没有提供展示),这个时候会用到SQL。
会用到什么程度呢?
我的经验是,会查询,最多到多表查询,就是select和一大堆的join。
你是做验证,而不是做数据库调优和建表。
所以什么create,什么update,什么view,什么insert你都不需要知道,也不用考虑多表查询的join怎么写可以提升性能。
我们来总结一下,作为产品经理到底需要懂什么技术?到什么程度?
- UML(如果你还是决定把UML划定到技术的范畴内)
这个就算你是做产品经理也应该掌握的技能,常用的几种表达业务的图,包括:构件图、活动图、状态图、用例图、数据流图、时序图(可选)、类图(对象关系)。你需要可以自己画,熟练掌握。
- SQL
这个部分只需要会写多表查询语句即可。
- 其它
视公司要求。如果你们的产品是硬件产品,那么对于产品经理的技术要求肯定还有别的部分。如果你们的产品是很注重前端的,而且要求产品经理担任UE的工作,那么一些脚本的编写技能应该也是需要的。
写在最后:
不要随随便便的把懂技术这件事情挂在嘴边,会被程序猿GG鄙视的。要知道在有的人眼里,会用0、1编程的才叫牛XX。 但是在我们眼里,写3K行代码并且1个BUG都没有的才叫牛XX(我有幸遇到一个,并且是个程序猿姐姐)。
另外,今天写的是产品经理,其实也是指的BA。要知道传统行业的产品经理可不干这些事情。
小婧是一名行走在产品路上的资深业务分析师(BA),如果想与小婧同行,就请关注我吧!