学一件事情 最好的办法就是去做那件事情

现在是9月28日下午6点， 天阴阴的， 一反北加州那种阳光灿烂的形象， 旱了那么久终于该有点雨了～

最近顶着各种压力， 坚持看了两本手册一样的书， 这是其中之一。 什么叫手册？ 就不是给你看的， 是给你随时握在手里备查的～ 类似现代汉语词典之于汉语， 特点就是第一， 有很多内容， 基本上那个方面该懂的知识那上面都有， 非常非常全面； 第二， 很多知识是当前， 甚至在不远的将来， 有些甚至是永远用不到的， 意思是说， 你真不用一次性把它看完， 会让你有种恐惧感， 觉得怎么要学那么多， 要qualify这个职位好难噢， which is commonly something that holds you back！ 第三， 即便你看完， 搞很熟， 也不见得就可以把事情做好， 因为手册里的东西正如你把现代汉语词典背熟， 也不见得你就能像人家韦小宝那样， 光凭一条舌头玩转整个世界。 有太多太多的东西需要实践了， 因为真正用起来灵活度很大。 或者说， 看你实际是不是混得开， 做事是不是多快好省， 其实是看你多聪明， 对已经有的资源， 包括你已经掌握的知识， 用得如何。 至于知识本身， 除了可以到需要的时候现学现用以外， 其他的就是给你开扩个视野， 让你在做决定的时候知道有这么一种可能性， 然后pros/cons大概怎样， 所以了解到这个程度就可以了～ 最近各种面试， 给我的感觉都这样。

以上就是我读完这本书， 或者说没读完的时候脑里就开始不断萦绕着的念头。 这不是一本给你一次性看完的书， 对于没有相关经验， 曾经在遇到类似实际问题的人， 读起来脑里没什么概念， 也许应付考试可以把那些条文背得很熟， 但真没什么印象， 对于实际中遇到， 并且已经解决了类似问题的读者， 手册里的内容就显得很刻板很教条很不适用自己的case， 读起来会有一种 “呵呵” 的感觉； 真正有意义的， 我个人觉得， 是对那些拔苗助长新官上任对行业一无所知的经理们， 遇到问题以后可以来这本书查一下solution， 对比自己的情况， 修正一下， figure out一个自己能用的东西。 即便是最后一种情况， 也不用在此时此刻一口气读完这本书来着～ 这是一件很讽刺的事情你们知道我的意思吗？ 很tight的schedule下硬挤出时间精力读完这本书， 就是为了得一个我们不需要读这本书的结论。

Anyway， 对我， 这本书最大的作用就是告诉我一个全景， 到底一个PM是怎样的， 要面临哪些， 要suffer哪些， 有哪些挑战。 看这本书的目的之一就是为了更好的理解PM， 因为我总觉得我现在单位那PM不行， 很多该做的工作没做好， 留给我来做， 就让我觉得还蛮讨厌的～ Well， 说实话当时是蛮suffer的， 有种头大的感觉， 一次又一次为了赶deadline不得已越权， 心里都觉得挺悬的， 这是职场的大忌， 同时又有怨念， 你要做好你的事， 老子省老多事儿呢！！！ 后来因此拿了最有价值员工奖， 简单说一泡钱， 感觉就好一些， 今天无意中看了一下周星驰奋斗史， 就觉得， 男人就应该是这样， 能忍！！！ 任劳任怨！！！ 并且大胆越权， 敢于挑战权威， 一切只为了完美！ 好吧，有点激动了， 但看完星爷奋斗史真有一种瞬间觉得自己曾经suffer的一切都不算什么， 豁然开朗的觉悟。 并且我真心觉得， 如果要增加自己在职场上的不可取代性， 光会code还不行， 当然code牛到极致本身已经足够不可取代了， 但很多时候在一个猪头经理的引导下， developer是很难全力施为的， 更多时候是在反反覆覆做无用功…… Well 简单说， 下一份职位 我需要做管理带队的角色， 同时作为我职业生涯头5年， 我还是希望能继续加强自己的技术， 有一个hands on的职位， 类似lead developer那种， 从无到有组建一个团队， 构建一个产品， 上接公司全局战略配合其他团队， 下应团队成员所需控制进度与质量， 嗯～

那就结合我自己的实际体会， 以及从书里学到的， 谈一下目前为止我眼中的产品经理～ 李开复说， 产品经理是一个公司的核心， 这一点也不过份～ 产品经理对产品的全部负责， 包括产品的研发与改进， 未来发展方向， 市场营销， 公关， 及至树立品牌， 产品系列， 全球化等等。 其实后面那些对大公司makes more sense， 对小公司不是那么make sense， 但大公司实际上是有很多产品经理， 一人负责一个方面， 不会让这么多重要责任全押在一个人身上。 对很多startup来说， CEO就是产品经理。 关于产品研发， 跟R&D团队打交道什么的， 书上都写得很清楚了， 对我个人来说， 书上没写但很重要的一点是， 团队成员的emotion management 和 passion management。 如果能让developer们对产品的未来有信心， 并且有足够的热情， 你甚至不用QA， 不怕tight deadline造成的压力。对于这两方面， 都是平时一点一滴的积累， 随便一句话比如：
Can you catch up the deadline by the end of this week? 这句没什么问题， 但如果换成
What do you need to finish your work by the end of this week? 仔细体会一下？
也许有些自诩神经大条的人会觉得， 反正都一个意思， flavor有点不一样而已没什么。 你知道为什么influence 那么出名而广为流传？ 就是因为那东西即便你知道所有的trick， 你也还是受影响。 每次表达flavor的些许差别， 或多或少会在团队成员心里有些积累。 这些， 不去实际体会一番， 忙中抽出时间反复咀嚼你感受不到～

除此以外， 人们普遍认为PM是技术不行的人才去做的。 我觉得恰恰相反， PM就得是技术特别厉害的人才能去做。 之所以人们会有这样的感觉， 我想也许是因为技术特别厉害的可遇不可求， 好不容易遇到那么几个， 还大多都是不爱跟人打交道对人没耐心只想做技术的主儿。 而人们往往招了一些搞技术的， 到头来发现技术不行， 炒掉成本又太高， 还可以去当PM， 所以去当了PM。 很多时候不懂技术的PM一开口， developer们就不想再谈下去了。 要让developer们想跟自己交流， 并进一步听从自己的主张， 就得或多或少跟那帮人在同一个频道上， 甚至让他们觉得你指的路是正确的。 另外技术厉害的PM在划分任务， 评估截止期的时候也是有优势的， 不然没良心想偷懒的工程师可以随便说一个很大的story point， 那进度一拖再拖， 别的环节做再好都没用, 或者工程师们不明白全局， 过低估计困难， 顺便插一句， 如果项目过于复杂文档过于不完善开发过程过于不规范， 那估计截止期真的是很困难的事情， 过低估计就是可以离谱到再怎么加buffer都无济于事的程度 ＝＝

PM还需要跟UX team打交道， 如果公司规模允许UX designer单独成立一个team的话。 来不断设计产品的外观和使用流程。 这个主要是对软件产品来说。 对此我只想说， 一定要以事实为根据， 在产品中插入analytics， 用数据说话。 这听起来像是废话， 我原来也这么觉得， 但是在美国经历一番之后， 我很惊讶很多PM在做决策的时候都没有数据事实作为依托， 很多产品甚至都没有插analytics。 在快速迭代不管有没有数据的情况下产品经理都必须要做决定， 并且在利益至上没有好处的东西先放着不做的情况下， 团队也可以一直不插入analytics， 所有这些都是可以理解的～ 所以如此浅显的道理没人按着去做就不奇怪了～ 就我现在的团队， 从我进来第一天开始就发现了， 经理们说话都是to me， I think 等等这些 sigh

PM 还有许多其他方面的职能， 类似品牌建设， 产品布局就哪些功能合在一起做一个产品，哪些应该分出去做另外的产品， 以及上市战略等等这些～ 但我不了解那么多， 就先到这里吧～

作为startup的CEO， 除了这些以外， 更重要的还有公司的 IP管理， 尤其对high-tech企业， 以及适当的融资～ 这段时间我想了很久， 再继续打工我永远接触不到这些， 但我必须接触， 或早或晚的事情， 所以下个阶段要开始自己开公司了～ 学习一样技能， 最好的办法就是开始用这项技能， 或者让自己每日的生活离不开这项技能。 晚上10点40， 一抬头， 正是路漫漫呐 囧～