荐课这个栏目，就是这样诞生哒~今天的荐课专题，是围绕着产品经理和工程师这对相爱相杀的职场同事介绍的。产品开发早期，工程师和产品经理的分工协作很容易出问题，究竟该怎么办呢？对于一个公司来说，最大的成本就是用错人。而优秀的人，通常有三个特点：
Tip1：敏感度高
与天分有关，有的人一眼就看出有问题，而有的人却很难觉察。
这一点，在面试的时候就应该果断判断。让一个人做他不擅长的事情，只能带来双方的痛苦和时间浪费。
Tip2：容忍度低
容忍度高的人，其实是做不了好产品的。因为他很难把别人逼到角落里还坚持自己的主张。
产品经理这个职位更是。对产品经理来说，最重要的是有创造力。而创造力是自我的延伸，所有创造力强的人都是自我中心的人，很难照顾别人的感受。
这种自我将造就对产品的敏感和决不妥协的态度，以及推倒一切的创造力。所以我们看到乔布斯其实就是一个绝对自我的人。
Tip3：主动优化
一个人发现了问题，是在不停抱怨还是主动优化？这取决于你和他的沟通和鼓励。
举个例子我家很乱，我请了一个阿姨来打扫。她第一次来，肯定要不停地和我沟通，哪些可以扔哪些不能动。但是时间长了以后，你不用多说，她也可以自动优化了。
所以我们在搭建团队的时候，首先，就是必须快速地察觉这个人是不是有足够的敏感度。其次，用你的沟通和鼓励让他从一个敏感、容忍度低的人变成一个能够主动优化的人。这是我们搭建一个好的创业团队的关键。
阅读笔记《洞察产品经理》
Step1：两个数字：
NO.1：平均一个产品经理有多少个工程师？
谷歌的比例是8：1——8个工程师有1个产品经理，基本上每天或每周都有新东西推出。Facebook的比例是20：1——在有200个工程师的时候，只有不到10个产品经理。所以，Facebook很多项目是没有产品经理的，由工程师自己解决。
很多情况下，一个产品经理需要同时管理很多产品。好处是各个产品之间相互协同，坏处当然是他很忙。
最好的产品就是要50个产品看上去像是一个人做的，这是非常重要的。假设你招了50个产品经理，每个人都有想法，那么，一个产品看上去像是50个人做的。
NO2.：资深工程师和初级工程师的比例是多少？
资深工程师很有经验，看过很多东西。但是他的创新的能力就因此下降了：他看的东西是过去的，他想未来的东西就比较少。
所以，一个资深工程师应该多带几个初级工程师，互相学习互相融合。
Step2：优化工具与流程
这是很多人没有想到的问题。
古人云，工欲善其事，必先利其器。很多快速增长的公司，会遇到事情太多，人忙不过来的情况。在国内，因为人工成本比较低，大家的解决方法就是疯狂地招人；而不是思考如何优化工具，或者优化流程。
我们鼓励最优秀的工程师来做工具。特别是在Facebook、Twitter，我们鼓励大家不一定都要去做产品，而是先去优化公司的工具，想办法提高公司的效率。
Step3：让工程师去创造新的东西
在公司里面，很重要的一点就是，要让工程师多做决定，给他一个锻炼的过程。这里谈到的是代码管理和维护方式。
大部分公司的一般做法是，把每个系统单独承包给一个组或者一个人，形成各自独立的专家团队。
这里有一个很大的问题：如果新人想做改动，就必须要说服很多专家，增加了改动的难度和时间成本。
Facebook是怎么做的呢？
Tip1：大胆放权，大家轮岗。
任何人都能成为任何系统的专家，每个人都能提供新的框架和方法。这样就能产生更多的全站式的工程师。以前改动一个产品需要叫10个系统的人过来做，现在不需要，只要5个全站式工程师就能全改了，然后产品就很快推出去了。
Tip2：高度透明。
我们在Twitter发明了一个Twitter大学，上面有公司内部的在线选课系统。公司内部上千工程师每个人都有自己擅长的方向，大家都可以把自己的知识拿出来分享给他人。如果员工可以不断地学到东西，他就不会离开。
阅读笔记《比起产品，工具和流程优化更重要》
产品开发早期，工程师和产品经理的分工协作很容易出问题。工程师最喜欢问：你有数据吗？产品经理一听这话很崩溃：产品都还没做呢，确实没数据。
两者之间应该怎么协作？
工程师应该从扩展性出发，进行前瞻性提问，而非静态关注单个项目成功率。
这是一种什么样的提问呢？比如，
- 我们到底围绕什么样的用户，解决什么样的需求痛点？
- 我们跟竞争对手是有一定差异化，还是和它同质？
- 我今年希望达成一个什么样的进度？
而产品经理，则要考虑及时反馈对规模和用量的判断，让工程师给你跑数据，以技术和运维掌握全局判断。
为什么呢？用户规模的改变所带来的变化，是环境改变里面非常重要的一环。
很多人认为，环境改变就是竞争对手改变。实际上用户规模除了可以改变竞争对手，对你自身平台所带来的冲击也是非常大的。这对社交性产品尤其明显。豆瓣它基本上不是被环境打败的，而是被自己的规模影响的。豆瓣早期是"小而美"的地方，用户都是高质量的文艺青年，主要围绕读书产生的，后来扩展到音乐、电影等。在这些领域又衍生出来一些小组，这些小组的话题变成兴趣社交，成为更大的一个敞口。
但是，如果豆瓣不去分析规模所带来的变化，只求扩大规模，对产品就会有影响。
2010年，豆瓣和腾讯合作，从QQ导入很多用户，规模一下子变得很大。但是，这部分用户跟之前的用户不一样了：他们最喜欢讨论的是情感问题。
情感绝对是一个特别好的生意，永远没有正确答案——"我爱上一个天蝎座，我该怎么办"，这种问题是永无止境的，别人问过你也会问。
导入乱七八糟的用户以后，豆瓣产品发生质变。
这时候要提醒工程师注意这个问题：考虑用一些手段制约和约束用户行为。
从技术上怎么解决这个问题？
- 工程师，应该对用户ID、活动轨迹、行为模式都要去约束和监控，找出异常用户。
- 产品经理，不应该给技术定义的太死，要开放地让技术找解决的方案。
- 最后双方再坐在一起去商量，每个手段对系统的提升一级代价和误伤是什么？
- 这些都弄清楚后再上线实践，检验是否和当初想象的一样。
通过这样迭代，产品经理和工程师就能形成很好的默契，失败几率变的越来越低。