0°

产品经理到底要不要懂技术?

小婧隐匿在好几个产品的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),如果想与小婧同行,就请关注我吧!

产品经理到底要不要懂技术?



「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论