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