创新的艺术是可以学习的
August 13th, 2011
最近把Andy推荐的一本老书慢慢读了一遍：《 创新的艺术 》。好的东西很多：要关注客户（和非客户），要用动词而非名词来思考你的产品，要早做原型多做原型，要敢于打破规则。而且有很多真实的故事。下面抄两段，关于团队和关于产品。
打造火热团队
- 团队完全相信目标是可以达成的，所有人对于目标毫无怀疑而且充满热情。
- 团队面临紧迫得近乎可笑的最后期限，因此任何成就都将是了不起的成就。
- 团队完全没有层级，他们互相开玩笑，从工作中找乐子。
- 团队了解并尊重多样性，他们彼此信赖。
- 团队在开放、充满灵活性、鼓励沟通、适宜协作和头脑风暴的环境中工作。
- 团队被授权可以得到他们需要的一切东西，他们与整个世界相连。
如何创造伟大的产品和服务
- 伟大的产品有出色的入口。让使用者在第一时间感到“这是我需要的”和“我知道现在应该做什么”，一个产品（和服务）就已经成功了一半。
- 创造隐喻。伟大的产品（和服务）有一个清楚而漂亮的故事，好的隐喻让制造者和使用者的想法联系起来。
- 跨越工作和生活。能实现功能的产品是好的，能让使用者的生活变得轻松和美好的产品（和服务）是伟大的。
- 善用颜色。颜色也可以是隐喻的一种方式：它让使用者清楚地识别产品（和服务）的概念模型。（BTW，这也是为什么我不喜欢 Go 的一个重要原因。）
- 让顾客知道在发生什么。顾客不应该操心所有那些幕后的烦心事，但需要知道现在的状态以打消焦虑。良好的沟通让使用者既不担心也不操心，这样做的产品（和服务）会让用户放心和开心。
- 一次点击好过两次。很明显。自从iPhone和iPad出现之后更明显。
- 防呆。让用户放心使用，让用户不会因为放心使用而遭受损失，这样用户会更放心使用。
- 首先，不要为害。尤其对于服务：如果不知道该干什么，至少不要捣乱。
- 检查清单。伟大的产品（和服务）首先不要遗漏任何关键的东西，否则它首先就不可用。
- 精彩的附件。提供让人喜欢的锦上添花的小附件，它们能增加使用者对产品（和服务）的喜爱。
用点史学方法学商业
August 5th, 2011
这周读了好几个案例。一边读，一边听老师分析，一边想起 小风同学 讲过的读史料的方法。小风同学推荐了 傅斯年的书 。读书之前，我先把这几天读案例的想法记一下。
第一，不光要看材料上怎么评价，更要看相关的事实。比如材料上评价“国美重视企业文化”，但是作为事实列举出来的企业文化声明是“诚信、创新、品牌”之类毫不具体毫无特色的词汇。所以虽然作者的评价这样评价，但真正看到的东西是国美的企业文化其实很弱。尤其是涉及财务绩效时，看数据可能比看评价更有用。
第二，不光要看材料上写了什么，还要看材料上没有写什么。比如材料上讲国美的组织转型、管理提升等等，都是计划在03年后实施的管理改进（阅读的是02年的案例）；当时的管理水平，没有提及。这样一个重要的主题没有被提及，就说明国美当时的管理水平是乏善可陈的。
第三，不光要看材料上怎么写，还要想作者写材料时的状态。还是企业文化的主题，毫无特色的企业文化声明被放在案例中写了一整页，设想作者在收集材料时的状态，可以认为国美不仅缺有效的企业文化、而且缺有效的企业文化规划——对比“管理”主题的写法就明白了。
第四，不光要看作者想写什么，更要看作者不经意透露的信息。（也就是傅斯年讲的“不经意的记载优于经意的记载”。）比如讲阿里集团的企业文化在规模扩张后如何保持，在企业文化部分没有详述。在绩效部分倒是讲到了各个子公司的相对独立和高管的轮换机制，从这部分材料解读出企业文化的内容，相对更加可靠。
第五，不光要看作者写了什么，还要看作者本身的出发点。比如他推崇的方法、框架，他做的研究题目，都能提供旁佐的信息。中文的案例普遍偏乐观，这也是一个与出发点有关的问题：中国的大部分企业都还在很初级的阶段，够资格做成案例的企业，怎么说也是会让作者有所偏爱的吧。
原来以史为鉴不光可以知兴替，还可以学会读材料。
复杂度的指数曲线，以及敏捷原则的根本
August 2nd, 2011
想象我正在往一个已有的代码库中添加新的功能。假如我一次只添加一个小修改，这个小修改是如此简单以至于它只有两种状态——写完代码之后只要看一看，我要么是改对了要么是改错了；如果改错了，我就用另一种方式来修改，后者一定是正确的。
如果我一次不是添加一个小修改，而是添加两个，然后把两个修改放在一起来验证。这时可能的状态就有四种：一种正确的，以及三种不同的出错方式。
如果我再贪心一点（或者是因为某些客观条件的约束），一次添加三个小修改然后再验证。这时可能的状态就成了八种：一种正确的，以及七种不同的出错方式。
所以这就是复杂度和变量个数之间的关系：C=(V的N次方)，其中C为“复杂度”，V为“单个变量可能的取值个数”，N为“变量个数”。所以复杂度随变量个数的增加而指数上升。所以几个简单的问题可以分别解决、而合并成一个复杂的大问题就根本无法解决，因为整个问题的复杂度不是做加法而是做乘方。
所以聪明的程序员知道要小步快跑。所以一次只做一件事、做好提交等build通过了再开始下一件。所以要频繁地跟其他人的修改集成。所以不要同时开多个story卡来做。所以不要讲什么“反正这些都是我的工作怎么做都是一样的”。所以不要讲什么“小心翼翼地重构太麻烦了不如一步就改过去多省事”。因为软件开发的工作量不是要敲多少次键盘，而是要处理多少复杂度。把渐进式的修改变成大步伐的修改，会增加工作量，而不是取巧。
所以越是痛苦的事越要频繁做直到它不再痛苦。所以要让反馈周期缩短再缩短。不光是为了练习和得到信息，更是为了降低需要处理的问题的复杂度，使普通人也可以处理——从这个意义上来说，再次向所有不采用敏捷方法的程序员致敬，为他们所能处理的超大复杂度。
