产品经理所需要掌握的技术点

　　首先强调一下，产品经理需要掌握一些技术点这事不是必备项，但却是大大的加分项，从我目前的经验来看，不懂技术的产品经理很难做产品，但可能会有一些天马行空的想法，只不过大多数都会被同行或者技术开发人员说实现不了。有些产品经理是有研发背景的，即在转行做产品经理之前，有从事过开发工作，这样就非常的有优势，如果之前的开发工作与现在产品所需的技术语言是一样的话，就比较完美了，可以在设计的时候就进行一定程度的实现性和可行性考虑，评估所设计的功能是否可以在现有条件和资源下实现，也能在开发人员的系统设计说明书评审会上听懂，可以大致了解是否符合要求。
　　技术开发人员都比较喜欢和同行交流的，就像我们自己喜欢和产品经理同行交流一样，因此做过开发的产品经理在和开发人员的沟通上有优势，但需要注意的是，千万不能不懂装懂，不要以为自己做过开发了不起，就指手画脚的参与系统设计，这样反而会令人反感，要记住你的技术背景只能停留在产品设计阶段和PRD沟通阶段，不要过多的给出技术方面的意见或建议，术业有专攻，况且你都转行了，说不定你所知道的东西已经过时了。
　　没有研发背景的产品经理就需要修炼了，其实也不需要去学习开发技术，但是要知道一些专业术语，比如要知道缓存、JS脚本、Ajax、数据库、存储过程、BI等等名词到底是什么东西，否则你会发现你在和开发人员沟通的时候会一愣一愣的，因为他们说的你听不懂。学习的时候要有针对性，比如公司产品都是采用JAVA开发的，那就去了解一下JAVA相关的基础知识，数据都都是采用MYSQL的，那就去简单了解一下这个数据库相关的知识，我们的目标是能听懂开发人员说的话，以免陷于被动。如果让开发人员发现他说了半天，你都没有听明白，如果要他讲第二遍或者一一解释一下，估计首先会有点不耐烦，其次会有点嫌弃你了，呵呵。
　　从我目前的经验来看，以下这些技术点是产品经理应该掌握的，这里不说必须掌握，确实是因为有例外存在。
　　SQL的读和写
　　在大数据时代，产品经理几乎天天都要和数据打交道，数据的来源有很多，但大部分肯定都是存储在数据库里面的，这时要做分析数据的话，数据分析能力是体现在拿到数据之后的，前提是你要拿到数据，这时就和SQL有关系了。
　　大公司数据仓库建设比较完备，有较为完善的数据管理系统，且有专门的数据维护人员，俗称BI或者DA，即做商业智能和数据处理加工的。在这种条件比较优越的公司，常规的取数需求都可以提交给这些专业人士处理，如日常的分析报表、项目开展所需要的基础数据等，只要说明清楚取数逻辑和所需要的字段就可以了。但平时的一些产品分析所需数据的获取，以及一些指标考核项的数据就需要你自己动手了。好一点的情况下，你可以央求BI给你写一个SQL语句出来，然后根据需要你自己改改；次一点的情况下，BI会将一些表结构说明给到你，然后你自己去组织表关联取数；最差的情况就是啥都没有，你自己去取数系统里面摸索着取数。而在小公司，产品经理可以让开发人员帮你取数，但你要是频繁需要取数的，我想你也不好意思老开口，毕竟会影响开发人员的本职工作。自己动手丰衣足食，而且因为小公司数据系统建设不完善，最好的情况就是上面说的第二种，有表结构说明给你参考。
　　上面这些场景就要求产品经理需要懂SQL语言。这里首先是要能看懂SQL，比方说你是求别人帮你取数的，但看了数据总感觉不对，这时你就需要去看看人家写的SQL对不对，毕竟你自己才最清楚取数需求是什么。看懂了发现有错误的地方，还要会改，特别是别人给你一段有相似取数功能的SQL语句时，要能手动改改之后适合你自己的取数需求。其次是要知道怎么写SQL，这就要求产品经理懂得SQL语言的语法和一些常用的函数，比如日期函数、格式转换函数、数学函数、字符串函数等等，最常见和最基本的都要掌握和灵活运用。
　　个人强烈建议产品经理同行们都学习一下SQL，这样在日常工作当中会方便很多。需要注意的是，SQL语言有TSQL（TransactSQL）和PLSQL（ProceduralLanguageSQL）两种，需要根据不同的数据库类型，有针对性的去学习。比如说产品采用的是SQLServer数据库，那就需要学习TSQL；如果采用的是Oracle或者Mysql数据库，就需要学习PLSQL，两种语言在语法上差别比较大，大部分情况下都不能混用。另外Oracle和Mysql数据库在应用PLSQL的时候，会有一些函数有使用上的差异，需要注意一下。有人会说现在还有一些非关系型数据库，如MangoDB之类的，这种数据库基本不支持SQL语言去查询，而且里面存储的都是非关系型的数据，也不需要查询出来做分析。
　　UML和ER图
　　早些年，产品经理这个名词还没有流行的时候，做类似行当的人一般称为需求分析师，传统的软件需求分析师的一项必备技能就是用UML画用例图，当然这个现在也适用，用例图对于说明需求来说，作用还是很明显的，至少开发能看的比较明白。现在随着思维导图和原型的星期，用例图逐渐的有点被淘汰的意思，但很多开发人员还是会用UML来画系统设计图，如活动图、状态图、协作图等，产品经理需要了解一下这些，以便能在设计评审上看懂这些图。
　　ER图也称实体联系图（EntityRelationshipDiagram），提供了表示实体类型、属性和联系的方法，在数据表关系设计上应用比较多。一个产品的数据存储，肯定不会只有一张数据表，而是由多张数据表通过关系关联起来的，相互之间的这种关系就可以用ER图来表示，可以从中看出各表之间关联的主键和外键分别是什么，哪些字段值唯一等。
　　UML图和ER图在系统设计当中经常出现，产品经理要能看懂其所表达的意思。你和开发人员讲需求设计的时候需要面面俱到，每个细节都会讲到，但开发人员跟你讲系统设计的时候，可是能简则简，你看不懂是你的事情，他们可是按这个开发的。
　　移动端的设计规范
　　这里包含产品设计规范和编码规范，无论是Android还是IOS都有自己特定的规范，移动端的产品经理在设计产品的时候就需要先了解清楚这些规范的内容，和一些技术实现的方式。移动端的技术实现相对比较可控和有限，多了解一些技术有助于进行有效的产品设计。盲目的设计要么实现不了，要么最终无法通过审核，是不可取的。移动端的一些特效也需要清楚，如拖拽、滑动、下拉、手势等，产品经理如果不了解这些，都设计不出操作体验很好的产品来。另外诸如不能获取用户的某些敏感数据等注意事项，都需要在产品设计时就考虑到。这块具体的还是要看场景来决定。
　　基础的技术名词