后端技术 by Tim Yang

最近看了图灵的《结网 – @改变世界的互联网产品经理》修订版，这本书是糗百创始人王坚编著，书中有马化腾前言的光环，也有不少不错的案例分析。仅从技术角度谈一些心得。

1、产品经理是否需要懂技术 (P10)

现在产品经理群体里面部分群体不懂技术，确实技术不是必要条件，但也看到不少缺乏对技术理解，而对产品未来视野存在瓶颈的情况。在大多情况下，对技术有更深理解的产品经理应该更具备竞争优势。

2、创新者与模仿者的问题 (P26)

一些创新者与模仿者的案例
AltaVista -> Google
Napster -> iTunes
VisiCalc -> Lotus 123 -> Excel
Apple Newton -> Palm Pilot -> BlackBerry
IBM PC -> Compaq -> Dell
Double Click -> Google AdSense

这个世界上，为什么模仿者摘了这么多果子，唐。道奇发现创新者往往缺少兼备技术原件和管理能力的领导者。

大部分团队里面，缺少具备技术远见和管理能力的综合人才。技术人员关起门来做事情的占多数，综合能力的培养和实践欠缺、视野不够、看问题抓不住本职等不足影响了技术舞台的大小。而这些团队里另外一部分具有管理能力的人员，心思通常又放在专业或者业务上，毕竟在大部分环境，如按任正非提倡屁股面对老板终究是风险极大的。多方面因素导致技术精英的缺失。

3、授权与发挥空间 (P85)

《理解漫画》中有这样一个观点，图片越抽象，读者理解起来就有越大的发挥空间。
如果你想造一艘船，不要抓一批人来搜集材料，不要只会他们做这个做那个，你只要教他们如何渴望浩瀚的大海就行了。 -圣埃客絮佩里，小王子作者

引申这一点，团队领导者在传达愿景时候有两种思路，一是完全直白的指示，团队直接按指示执行即可。另外一种思路就类似上面的，给得是一个有很大理解空间的愿景，根据不同的团队背景，也许团队会做出让人惊喜的成果，这样的环境也更适合有想法的人去翱翔。

4、危机管理 (P100)

互联网在线业务出了故障或问题，如何跟用户沟通反馈上面已经提到。缺的是一个企业从上到下塑造这样的文化。

团队内部出了问题不应该遮掩，道理都懂，真正做到这一点的团队不多。敢于直面问题、将问题坦诚的公开并透明的进行进展公示，是衡量一个团队及领导者是否值得信赖的一个重要标志。

5、其他

另外还有一些不错的观点，因为没有更深思考，就不再赘述，有意读者可以关注以下部分。

• 倾国倾城的案例，P66
• 价值3亿美元的按钮，P124
• 平台拉动的分析，P154
• 20%的特性可以满足80%的用户，但是都不是同样的20%才是问题，P176
• 压力管理，P195

6、建议

本书总体感觉操作层面描述较多，如果能够透过这些技巧、案例引导读者一起思考深层次的问题就更好了。对于新的产品经理而言是本不错的书。

2013来了，又过了一年，以下是元旦假期的一些随想

分享

2012写的东西偏少。一方面由于关注的问题相对宏观问题多一点，导致在细节方面能分享的并不多；而大部分宏观问题也跟具体工作相关，不适合分享。宏观领域的粗浅理解容易导致对具体领域的忽视。比如“互联网系统架构近五年技术缺少实质性变化”的断定，会让所有对细节的关注趣味索然，进而也加剧了减少在具体问题上的分享。另外一方面由于工作岗位的原因，需要在管理方面消耗一些精力（当然这些精力投入有它另外的价值），导致专注一个领域研究及阅读时间减少。同时作为一个管理者，需要顾虑未经深思熟虑的表态可能会造成误解，尽管博客只是个人随想的表达，但无法避免被当做一种管理者或者官方的声音去解读。

以上种种，对于一个习惯写一些东西的人并不是一个非常好的状态，但是这些是未来需要克服的困难。并且在新的一年，也打算关注及分享一些新的技术领域，先留个记号。

创新

技术人员创新体现在运用技术来为产品产生更大的价值。比如在大部分开放平台中，用oauth2代替oauth1是一种创新，它在提升安全性的同时，也极大降低了开放平台使用门槛，并间接促使了开放平台领域的进一步繁荣。

但是，技术人员的大部分群体还是工作仅局限在本职工作上，即怎么样按时按质的完成所分配上的任务，技术上的挑战并不算大。尽管如此，但是在大部分企业中，技术团队往往被视为整体瓶颈之一，比如对产品的质量及细节（包括稳定性、速度、体验等）的把控不足、团队的开发效率不够理想（体现到产品的迭代速度）、技术团队对于行业关键技术的掌握能力偏弱等。比如以上情况目前在移动开发领域比较普遍。而且由于行业由于更新迭代速度快，一些技术团队未能有效掌握所需最新核心技术，而导致产品开发效率变低（对于宏观管理者而言，这些信息通常被掩盖），极端情况下，这些缺乏更新技术方法的人员也可能成为阻碍产品创新的力量。

对关键技术的把握及是否具备创新思维能力，是衡量当前创新型企业技术团队成熟度的标志。

谈到团队创新能力，常规的金字塔型团队（即少数能力强的带领一群普通的）未必创新能力很强，也许倒金字塔的更好，一群能力突出的人在一起碰撞会更利于创新。

今天看到南方周末2012/12/27期一篇文章《城市：创新的天堂》，部分摘录如下

但是，West最有趣的发现来自那些不遵从“Kleiber定律”的数据。West及其团队发现大量的城市统计背后隐藏着另一个指数法则：所有与创造力和创新能力相关的数据，比如专利产生数、研发预算、超级多产的发明家数量等都遵从同一个指数法则。与“Kleiber定律”不同的是，跟创新有关的指数法则是正相关，而不是负相关。一个城市如果是另外一个城市规模的10倍，那么它的创新能力不只是另外一个城市的10倍，而是17倍。一个城市的规模如果是另外一个城市规模的50倍，那么它的创新能力就将会是另外一个城市的130倍。West的数学模型表明认为创造的城市打破了生物学意义上的生命模式：城市越大，产生思想的能力越强，速度越快，人均产生的专利和发明数量也越多。这就是所谓的“超线性缩放”现象。

（此文应译自New York Times，A Physicist Solves the City）

开源

开源社区已经运作多年，行业对于开源运动也都有各自深入的理解。补充一点看法，目前的业界环境下，技术转化为产品再经过运营得到用户认可，是一件门槛相对较高的活，因此对于一个小型团队，如果拥有一些对用户有所帮助的技术，这些技术直接创造价值还是存在一些机会问题，因此通过开源的方式或许可获得另外一种技术产生更大价值的方式。

言辞对于提高一个人的修行具有不可言喻的好处，它不是表面的嘴皮子功夫，在胡适所述“三个方法让你的所思所想为你所用”提到

• 一曰谈话。友朋问答辩论，可使吾向所模糊了解者今皆成明澈之言论。盖谈话非明白透彻不为功也。
• 二曰演说。演说者，广义的谈话也。得一题，先集资料，次条理之，次融会贯通之，次以明白易晓之言抒达之：经此一番陶冶，此题真成吾所有矣。
• 三曰着作。作文与演说同功，但此更耐久耳。

其中有二点都是跟言辞相关的，通过谈话来“非明白透彻不为功也”，通过演说来“真成吾所有矣”。

基于以上考虑，最近和一些志趣相同的同事组织了一个业余的演讲小组，每人每次进行10分钟左右的演说，其他参加者作为评委轮流对其演讲进行简单的点评，通过练习来发现自己的不足，从而在知识的广度与深度、材料的把握能力、逻辑思考(critical thinking)、言辞表达方面来提高自己。

昨天进行了第一期活动，最大的收获是参加者发现了自己的很多不足。尽管参与者很多有在公司内外多次演讲的经历，但以往的反馈基本是来自对演讲内容的提问，没有得对演讲本身的反馈，昨天活动的大范围反馈与点评，参与者普遍反映收获还挺大。通过活动总结出来常见的问题有

纯理论观点通常效果不佳

纯理论观点的讲述会让人联想到课堂上的“老先生”，这些“总是正确的观点”让听众感觉空洞无物、缺乏共鸣、甚至昏昏欲睡。

演讲需要来自实践的案例

理论的观点需要有论据，最好是来自实践的案例，或者众所周知的典故，通过故事来辅证你的观点，好的故事比如“盲人摸象”，可以引导听众去思考平时的言行。但是讲故事的能力还是比较缺乏。

对材料的熟悉程度影响演讲的效果

很多人在网上或者微博上看到一个观点，心中比较认同就拿出作为演讲素材，但是这种情况由于对材料缺少熟悉，脱稿之后通常很难流畅的说出，出现辞不达意的情况，甚至让听众不知所云。这种情况就是“所思所想还未为我所用”。

注意内容的逻辑性

比如根据演讲者的推论得不出演讲所述结果，演讲者自己提出了问题，但是后面展开的内容和前面的提问听不出直接关系；PPT的材料及图片和演讲的重点并无关联，可能只是演讲者喜欢那张图片。