我是产品经理我需不需要学技术？

　　我是产品经理我需不需要学技术？
　　这个问题我已经听过很多遍了。作为一个技术出身的产品经理，我的意见是，需要学，但很可能不是你所想的那种学法。
　　PM为什么要学技术？
　　科学技术是第一生产力，而现在这个生产力正在移动互联网、云计算、3D打印和物联网等领域飞速发展。这意味着谁先将它转化为产品，谁就能突破现有的用户体验，在这个体验至上的产品领域中占领头筹。可以用来砸钉子的大猩猩屏幕让手机用户不用再担心屏幕被划伤，更可能从根源上干掉手机贴膜这个产业。可以随身佩戴的GoogleGlass即将带来AR（增强现实）技术的全新体验，并在游戏、社交和工具领域开辟出一个全新的产业链。而不懂AR只懂PR的你，肯定不可能在第一时间做出最新的产品。
　　再回过头来想想PM和RD的沟通。为什么在你眼里很简单的东西，RD就是说不能实现？他是在忽悠你吗？为什么一个简单的功能，RD评估出来要开发3个月？有办法改进吗？
　　所以，不管是为了能紧跟技术发展潮流带给用户更NB的体验还是为了和RD沟通时不被当猴子或者外星人，PM都是需要懂技术的。
　　那么PM怎么学技术？
　　对于RD来讲，学习技术是一件很简单的事情，找到相关的技术资料，搭建好相应的开发环境，编码、测试、改进，再编码、再测试、再改进
　　但是对于PM来讲，学技术是一个很艰巨的任务。不是说PM都比RD笨，而是RD通常只需要精通一门技术即可；而只要项目要用到的技术，都属于PM要懂的范围。要想都精通它们，一般人很难做到。
　　其实当刚开始负责微盘项目的产品的时候，我曾尝试着去学iOS开发，后来因为各种原因半途而废（《30天精通iOS开发》什么的完全是骗人的哇！o）。但我发现虽然我只读完了iOS开发的概要说明部分，并不清楚移动开发的细节，我也能很好的管理技术团队、和我们RD的同学有效的沟通。后来再接触到新技术时，我也开始用类似的方式去处理，发现效果很好。
　　这个学习技术的方法总结起来就是：忽视技术细节，关注技术的原理、边界和成本。
　　下边我详细说明下。
　　原理
　　好的产品经理需要保持对事物的好奇感，看到一个新东西，第一反应就是它是怎么做出来的。比如Nexus4采用了无线充电技术，那么你想过它的原理么？“快传”这个手机应用可以不通过网络传输文件，你去分析过它采用了什么方式么？当你在浏览器地址栏输入一个网址，敲击回车后，网站内容是如何显示到你屏幕上的？
　　了解原理的成本其实比想象的低，通常认真的阅读完一个Wiki页面就可以。一些技术细节可以略过，因为我们的目的是建立整体概念，从而理解技术常识。当你了解了网站的工作原理后，你就会理解为什么你电脑上的图片要放到服务器上其他人才能看见。
　　但是有一类技术细节是产品经理们要额外注意的，那就是“边界”。
　　边界
　　我把影响可实现性的技术细节称为边界。这些细节制约着产品的实现，无论你拥有多好的技术人员都无法逾越。一个典型的边界例子是早期iOS中应用本身存储的数据只有自己能访问（越狱的不算），这在产品层面的影响是，这导致了微盘iOS版本开发了自己的文件阅读、视频播放功能。边界是把双刃剑，一方面，边界制约了产品；而另一方面，一旦你穿越了边界，就能在这个领域里边领先。
　　穿越边界很常见，一种方式是通过产品设计或者其他技术方案绕过边界；另一种更常见的方式是，观测边界的松动，并及时更新产品。大部分的非安全类边界都会松动，并定期更新。比如早期Flash对3D的支持很差，这导致纯3D游戏很难在浏览器上运行，而最新的Flash版本已经支持3D渲染，甚至可以启动GPU处理。在我用PhoneGap做HTML5动画效果时，发现Android系统没有对Canvas做硬件加速，导致产品卡得没法用，这其实也是一个边界。而APPCAN就抓住了这个边界，和微游戏推出了支持Canvas加速的SDK。
　　即使对于技术人员来讲，边界也是非常重要的东西。以前我一般都悄悄的记录到QQ邮箱的笔记本里边，以后我会尝试着在方糖气球的微信中推送最新松动的边界信息。：）
　　成本
　　对PM来讲，成本更多表现为开发时间。这本来是属于技术经理的活，不过产品经理需要对这些有常识。你要是拿着一个Path去和RD讲：“这东西这么简单，一周时间够了吧？”被人家咬就不要问什么了。一般熟悉产品开发流程后，对产品开发时间的评估就能有概念了，这个是体力活，多和RD沟通，跟几轮就清楚了。但有部分技术细节会影响开发时间，包括两类，细节黑洞和开源黑洞。
　　细节黑洞
　　细节黑洞是指一些吞噬时间的细节。比如说拖放效果。对于大部分开发者来讲，标准的拖拽效果很简单，因为JQuery（一个开源JavaScript库）有很多组件可以直接重用；但如果需要对这个拖放进行定制，那么只有认真读过拖拽实现的程序员才能做好。在开发第一个可用版本的时候，PM要放弃一切可能成为黑洞的细节；即使在后期的版本迭代中，也要把可能成为黑洞的细节放到最后来做。
　　开源黑洞
　　开源是个好东西，一个好的开源项目可以帮你节省大量的开发时间。但是对包含不熟悉的开源项目的情况，一定要让RD认真评估。我经历过的因为开源方案不成熟、不满足某个细节需求最后改为自行开发的例子已经不下3个了。不是说开源不好，而是不要把它想太好，就像鲁迅对中国人一样，要以最坏的情况去估算成本。
　　当然了，新技术也会带来成本的降低。比如最近正在飞速成长的PhoneGap技术，它通过把HTML5直接打包到各个移动平台，实现了一次开发多平台运行。我个人正在开发的团队协同工具TeamToy2就采用这种技术，虽然各种小坑不断，整体成本上还是非常给力的。要知道这种所有东西就一个人的项目要是采用原来的方案同时开发iOSAndroid客户端Web版Mac客户端根本就是不可能的任务。