投资战略与敏捷转型
December 4th, 2011
和 上一篇博客 有关：恰好在读了《 竞争战略 》之后，又温习了一遍 成长-份额矩阵 ，然后就跟客户聊企业的敏捷转型。这时我终于清楚地意识到：敏捷引入的策略和应该与portfolio管理和投资战略紧密相关。
首先，狗是不需要什么敏捷转型的。当然也不好说得那么绝对，毕竟最起码减员增效可以让资产剥离的时候顺利一点。但是太多企业的问题不是减员增效，而是盲目追求规模舍不得把狗杀掉。这就是另一个话题了。
另外三个象限的敏捷转型策略非常有趣。效率，质量，用户。敏捷的三个关键词其实是不均等地对应在三类业务象限上的。
野猫（或者“问号”）的敏捷关键词是用户。份额小、成长快的野猫业务，最大的风险是根本就没人用。所以这时候要准确地抓住用户需求，提出强有力的价值声明，关注用户体验，以最小工作量抓住眼球并获得转化率。对于野猫业务，敏捷引入应该从 体验设计 入手，首先进行 快速项目启动 ，然后以迭代方式迅速交付并获得反馈。
明星的敏捷关键词是质量。份额大、成长快的明星业务，非常容易因为“Quick & Dirty”的开发方式而变成焦油坑甚至直接影响交付。这时候需要偿还技术债务、打好根基，才能承受不断加大的交付压力。对于明星业务，敏捷引入应该着重关注 持续交付 ，从持续集成和自动化测试入手，向下改进代码质量和架构质量，向后借助 DevOps 打通交付的最后一公里。
金牛的敏捷关键词是效率。份额大、成长缓慢的金牛业务，质量和交付风险并不高；同时因为规模大、涉及人员众多，些许效率提升就能带来明显的收益。所以金牛业务的敏捷引入思路应该是以稳为主、持续改进。通过 持续集成中心 等方式提升项目透明化程度，首先掌握现场状态、建立反馈机制，然后逐步改进、逐步提升人员能力。
结论：不同的业务类型需要不同的敏捷转型策略与实践。将投资战略与敏捷转型策略结合，有助于更有效地引入敏捷。
引论：所谓“全公司统一的敏捷流程”就是反敏捷。人和交互重于流程和工具。
听NASA讲云计算有感
October 23rd, 2011
QCon杭州最后一天，来自NASA的一个哥们 扮演了关于云计算的流言终结者，通过展示NASA对云计算的使用来说明：云计算已经是越来越多的企业越来越不可忽视的IT战略方向。
（人家NASA从组织使命开始就非常洋⋯⋯这哥们所属的部门，它的使命是“登上太阳系内所有的行星”⋯⋯这完全就把那些唯利是图的企业给比到不知道哪里去了呀⋯⋯）
第一个流言：“云计算不安全”。这里的亮点在于：大部分企业对IT资产的安全管理其实是非常不足的。比如说操作系统的安全补丁，所有的计算机都及时打上了吗？一个合理构建的云工作环境，可以把这些要求（例如必装软件、例如防火墙配置、例如操作系统补丁）自动化地落实到所有机器上，从而使安全政策即时、有效地得以实施。所以，一个合理构建的云环境比传统的企业IT环境更安全。
第二个流言：“云计算不可靠”。首先，作为专业的高可靠性机房提供商，亚马逊的机房肯定比你的更可靠——亚马逊机房当机，这一事件只能表明你自己的机房有更高的可能性当机，而不能表明你的机房不会当机。并且在使用公有云的情况下，你可以做到多区域冗余灾备，这是私有机房做不到的。所以，没错，公有云并非100%可靠，但一定比你自己的机房可靠。
第三个流言：“云计算只适用于初创企业”。实际上，越大的公司，IT资产的浪费越严重，因此从使用公有云上获益越多。我从演讲里总结了关于IT资产的几大浪费：- 预先采购机器就是浪费。计算机价格受摩尔定律影响，贬值非常快，为了两年后的需求采购机器就等于把价格的70%直接扔进水里。
- 拥有机器就是浪费。自己采购、自己管理的计算机， 计算资源的真实使用率非常低，但仍然占用空间、电力、降温等等资源。
- 因为硬件资源的约束而限制生产力，是最大的浪费。比如说，因为没有那么多机器而不能并行计算，而导致科学家等待好几个小时，对人的浪费是最严重的浪费。
所以NASA的CIO有句话说得很好：应该把所有硬件采购的界面都变成云服务开通的界面。不使用云计算，就是在每天浪费钱。
行动中的战略
October 16th, 2011
（商业读书会第十三期： What Is Strategy | HBR 1996）
战略对于企业的影响是长期的、逐渐显现的。例如某著名高科技企业，一直以来习惯于跟在同城竞争对手后面做老二，各种小小的差距日积月累，终于呈现截然的效果：当竞争对手获得近13%的销售净利率时，这家企业的净利率低了10个百分点——考虑到 棉纺行业尚有近8%净利率 ，日子之苦可见一斑。于是同样是开拓新市场，这家企业的研发速度已经明显跟不上竞争对手。缺乏独特、清晰的战略定位，企业的可持续性堪忧。
波特的这篇文章是对《 竞争战略 》所述“基本战略”（Generic Strategies）的扩展，重点在讲战略定位。所谓战略，说穿了就是要与别人有所不同。运营效率（Operational Effectiveness）是重要的，但仅凭运营效率——消除浪费提升效能——难以支撑较长时间的“与众不同”，因为提升运营效率本身是相对容易被模仿的。（丰田靠精益生产保持了相当长时间的领先地位，这是特例而非常例。）而且，基于运营效率的竞争是杀敌一千自伤八百，消费者会因此受益，但企业不能长期在这方面互相竞争。
运营效率讲的是“把事情做好”，战略讲的则是“做不同的事”。如何不同？波特给了几种方式：满足大量用户的特定需求；满足特定用户的全部需求；或是以特别的方式来接触某些特定的用户。
相比如何制定战略，波特更重视如何实施战略。这篇文章里他一直强调：要想与众不同，就必须做一些与众不同的事；如果你做的事都和竞争对手一样，你就不是与众不同的。这与众不同的事，首先就是有所为有所不为，也就是工作优先级与战略匹配。没有取舍的工作只会让所有人——顾客和员工——对战略产生迷惑，使战略既不能被理解也不能被落实。
在把行动与战略匹配的过程中，首先需要做到简单一致：行动应该符合战略目标。在同样的目标下，这些与众不同的行动应该彼此强化。最终所有人的所有行动都彼此相关，随时根据战略目标的指引优化工作。当一家企业如此将行动与战略匹配，战略就构成了企业的性格，它决定着每个人、每件事的如何想、如何做。这种企业性格是很难被复制的，它能构成企业的核心竞争力。战略的连贯性会使运营效率的改进也具有连贯性，有助于把与众不同的事做得更好。
因此当企业成长时，现在有效的企业性格是一笔重要的财富（而非负担）。成长的方向应该首先考虑深化现有战略定位，从而借力和强化企业性格；而不是扩展业务广度，从而淡化和冲击企业性格。拿句被用烂了的话叫“小胜靠智大胜靠德”，没有性格的企业是不能长久的。
生态系统 重于 经济合作
July 16th, 2011
（商业读书会第八期的题目： A Rush to Failure | HBR ）
首先这是一个破除迷思的案例：据说某些特定领域（例如航天、军事、通信）仍然适于用瀑布方法开发软件应用而不适用敏捷方法，据说一个重要的原因是这些领域中软件的可靠性要求是如此之高以至于必须首先做好一切设计然后编码然后进行长时间的测试。但这个案例告诉我们：即使在航天领域，瀑布方法也不工作。
不过再去长篇累牍谈论敏捷已经没什么意思了。越是要求高可靠性，越是不能在生产环境下失败，你就越是需要尽早验证、尽早失败。这是一个如此显而易见的道理，只不过在90年代之前人们没有足够丰富的计算能力将其变成现实。就连航天领域也会追求速度，但速度和质量并不必须是互斥的，“ 可工作的软件 重于 求全责备的文档 ”讲的就是这件事。
相比之下，文章末尾处关于合同的对话更有意思。当然这也可以归结为“客户合作 重于 合同谈判”，但在我看来，这更多的是一个社会视角（而非软件开发视角）的问题——我听过客户这样说：“我们会尽力与你们合作，我们的共同目标是履行合同。”这是将企业间的合作完全视为经济活动所带来的必然结果：在项目进展中我会尽力跟你合作，但这并不妨碍我在合同谈判时尽力占你的便宜，因为“合作”被视为个人的态度，而“谈判”才是企业间的关系。
老师讲到另一个客户跟外包商（如果一定要用这个词的话）合作的方式是完全不同的。这个客户在合同谈判时努力讨价还价，然后在敲定价格之前问：“你们确定这个价格能保证足够的利润？你们确定不会难做？”得到肯定的答复后他才放心签合同。他们派人到中国外包商的办公室一起工作，来自两个公司的人融成同一支团队；他们不仅关心进度而且关心外包商的人员培养，乃至帮助建设基础设施和买书。这都是基于一个朴素的道理：找到共赢的方式，然后让上下游企业都变强，那么所有人都会因此而获利。
所以就像德鲁克说的：企业要赚钱，这是不言自明的事；惟其为消费者、为社会做出了什么贡献，才是定义一家企业的方式。构建和维护一个共生共赢的生态系统，清晰自己在其中的定位，帮助生态系统中的其他玩家（甚至竞争对手）共同成长。这样超越经济合作的生态系统将使得“合同谈判”最终成为一项无关紧要的例行程序，因为双方都知道对方会全力以赴而不需合同的约束。
当通信业遇到云计算（上）：行业
June 26th, 2011
移动有“大云”，电信有“星云”，联通有“沃云”。三家运营商都 推出了自己的云战略 ，通信业和云计算是如何拉上关系的？运营商要如何转变自我定位？
根源：用户的诉求
我们正处于一个信息加速爆炸的时代。根据 Hadoop引用的一份调查 ，截至2009年底，全世界有超过2亿台web服务器、超过8千万个域名在为超过17亿互联网用户服务，让他们每天发出超过2千万条tweet、在Youtube上浏览10亿个视频、并制造超过2千亿封电子邮件（尽管其中81%是垃圾邮件）。而且 有人声称 到2020年人类在互联网上创造的信息量将是现在的270倍。
除了其他的各种影响，对于提供互联网服务的企业（以及个人）来说，这意味着他们需要新的计算能力（即：消费、存储和生产信息的能力）报价：不仅是更便宜的计算能力，而且是弹性的计算能力——根据对计算能力的使用付费，而非预先购买昂贵的服务器和网络带宽，并且当业务量上升时能得到充足的计算能力。
作为信息和计算服务的重要提供商之一，通信运营商希望满足这种诉求。但他们发现这并不容易。
困局：运营商的局限
不难看到，现在最成功的“出租计算能力”供应商其实是亚马逊。其实作为一家互联网企业，亚马逊提供这种服务有一些难以克服的障碍，例如QoS：亚马逊没有办法保证用户一定能连接到EC2的机房，更没办法保证连接速度，因为它没有端到端的网络接入。运营商有。
但运营商有自己的问题。运营商（以及通信厂商）太习惯于用技术眼光来看待通信网络，核心网、接入网、路由器、交换机⋯⋯在整个数据通信网络之上，通信服务与用户真正体验到的网络服务却是完全隔离的。从网络协议栈设计的角度这当然是正确的，但从服务的角度这就体现出通信业一直是个供方市场——就好像从前计划经济时代润肤霜属于“日化产品”，现在叫“Beauty Industry”，供方市场上描述产品是从生产（而非消费）的视角出发的。
随着数据通信服务的日用品化，运营商必须到网络服务这块市场来寻找增长点了。把手上的优势资源（接入、网络、IDC）充分利用起来提供客户需要的计算能力（而不仅仅是通信服务），把亚马逊赚的钱变成运营商自己来赚，这是国内外运营商都在走的一条路。
转型：迈向云端
帝国主义老巢的运营商步子迈得稍微早一点。BT在2009年和微软一起给企业客户提供 基于云的商业协作软件 ，大致属于 SAAS ；AT&T的 Synaptic 提供了存储和计算的出租，就应该算是 IAAS ；Verizon把这种业务叫做 CAAS ，说白了还是抢亚马逊的生意。
国内的三大运营商盯上的也是IAAS。移动资深研究员杜宇健认为运营商切入云计算 从基础设施这个层面落地比较好一些 ：IAAS技术门槛不算高，需要的是大量的基础设施，而后者正是运营商手中已经掌握的。
首先把手中已有的计算能力云化（我颇喜欢“Cloudify”这个词，但好像已经被某公司使用了），将云化的计算能力以私有云的形式出租给企业用户，为将来提供SAAS铺路架桥。这个大概就是运营商向云端转型的策略了。
（讲完行业，下一篇讲实施。未完待续⋯⋯）
