<!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:宋体; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} @font-face {font-family:"/@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1; mso-font-alt:"/@??"; mso-font-charset:134; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 135135232 16 0 262145 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:SimSun; mso-bidi-font-family:"Times New Roman";} a:link, span.MsoHyperlink {mso-style-noshow:yes; mso-style-priority:99; color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {mso-style-noshow:yes; mso-style-priority:99; color:purple; mso-themecolor:followedhyperlink; text-decoration:underline; text-underline:single;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:SimSun; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->
为什么 Google 做不出 Instagram
1. Google 没有办法把团队保持到一定的小规模
Instagram 的两位创始人是在第 38 号码头的 DogPatchLabs 租了一张办公桌开始的。据此 Google 高管说, Google Wave 团队超过 30 人。他曾经创业过,所以他非常了解那个神秘的人月关系。每加一个人到团队,项目迭代的速度就会下降。他告诉我甲骨文的 Larry Ellison 是如何提高团队效率的故事。如果一个团队效率底下,他会每个星期过来说 “ 让我来帮你一下 ” 。他做了什么呢?他每次从团队调走一个人,直到团队停止无谓的会 议,开始做出产品。
2 Google 不可能像 Instagram 那样大刀阔斧的削减需求
Instagram 的初衷其实和现在的产品很不一样(这事据说当时和他们的疯投 Andreesen 起了冲突)。起初这个不仅仅是个拍照片的软件。但几个创始人认识到他们不可能完成这个巨大的任务。他们开始削减需求。 Instagram 可以做到这些。但 Google 不行。想象一下如果你对 Larry Page 说:嗯,关于我们的那个社交平台,我们去除 90% 的需求吧 “ 。 Google 要和 Facebook 正面竞争。 Instagram 只需要和它自己竞争。所以 Andreesen :这也是为什么几个我喜欢的公司从来就没有去拿疯投,比如 GoPro 和 SmugMug 。 “ 着眼于本垒打 ” 的压力其实压垮了很多公司。
3. 在 Google ,如果一个产品成功了,它会获得很多很多的资源和人力
想 象一下如果你在 Google 工作,然后你在你的 20% 的时间会做什么事情呢?肯定不是很乏味的项目吧。你当然想加入一个超酷的项目,比如 Instagram ,一个炙手可热大家都喜欢的项目。如果 Instagram 是 Google 内部的项目,他们就要面对潮涌的 email 和一大批等候在他们办公室外面跃跃一试迫切想加入的同事们。我在微软也亲眼目睹了类似的事情。
4. Google 要求他们的员工用自己的基础设施,但问题是这些基础设施并不适合小型的社交模式的项目
在 Google ,你不能用 MySQL 和 RoR 。你只能用 Google 的 Big Table 来存储数据。那可不是为了小型社交类型的项目而设计的。开发者们告诉我说用 Big Table 并不是很容易,而且也比外部开发者缺乏效率。
5. Google 的服务需要支持所有的平台
在 这种情况下,如果你说 “ 我们的项目只支持 iPhone” ,你肯定会被轰出会议室。而且这项目也必须支持 Google 在全球范围内的每个社区。我记得微软的团队因为要测试自己的产品在全世界的所有语言环境里都可以运行而被拖至龟速。还真让人无可奈何。 Instagram 就没这样的问题。他们可以说 “ 我们现在只支持英文,其他人我们没空管 ” 。
6. Google 不能使用 Facebook 来整合产品
这 也意味着获得新用户会有点困难。我这个星期下载了几个 iPhone app ,然后登录 Facebook 后就很方便的加入了我的朋友清单。我的朋友们都在 Facebook 。我在 Google 的社交圈根本没什么朋友。 Instagram 可以使用任何他们喜欢的系统。 Google 则要付出点 “ 战略税 ” ( Strategy taxes :因为战略上的原因而不得不用其他非 Facebook 的方法来实现功能。这里耗费了不必要的人力和物力)。
7. Google 没办法半公开的测试产品
几个星期前 Kevin ( Instagram 的创始人)给我的 iPhone 装上了测试版的 Instagram 。他叫我不要和其他人说,但也没有叫我签保密措施。其实他知道如果我泄露一点信息可能对他也有好处(不过我没有泄露)。他那时候需要的 是热情的用户,那些会使用这个软件并提交测试过程中遭遇到的问题。 Google 的做法是 “ 吃自己的狗粮 ” 。但现实是你需要公司外部的人来使用你的产品,而不是闭门造车。 Google 不行,这牵涉到太多的政治斗争。 Instagram 没有这种政治斗争地狱。他们毫无顾忌的给几十个人预览这个应用,从而获得很多的反馈,修复了一大堆的 bug 。而且这批早期用户也非常喜欢这个产品。
8. Google 没法用 Eric Ries 的技巧
Eric 的 “ 瘦形创业公司 ” 方法是先搞清楚客户需要什么,然后再建设所需要的基础设施和未来的可扩张性。 Google 则相反,他们需要确认这服务几亿个人使用没问题,然后再开始做产品。 Google Wave 失败的一个原因就是第一批用户进来后就变得非常的慢,虽然他们有个邀请机制限制新用户数量。
那么,大公司如何创新呢?嗯,大公司可以收购小公司。或则, Google 可以去开拓一些小公司没有能力去开拓的领域。比如开发无人驾驶汽车。这就需要很多人的团队了。
还 有一条路就是开源项目,这样大家都可以贡献代码,而不需要开无聊的会议。比如 Rackspace 的 OpenStack 里有一些非常不错的创新。而这些创新是来自 Rackspace 外部的人。还有硅谷目前最酷的公司, Cloudera ,他们知道公司会越来越大,为了防止类似公司内部政治冲突,他们正在建立一个系统,让开发者可以无顾 虑的加入新的创新。又比如非科技公司的 TEDx ,他们用加盟的方式在全世界举办了几千场 TED 大会。他们给会场 TED 的冠名,而不需要经过母公司的审批。这样他们就可以一直的处于创新的地步,就算他们的内部已经停止创新。
Posterous CEO 从苹果公司学到的 8 个管理经验
1 、科技公司应由工程师而非管理者主导
Sachin Agarwal 说,苹果完全是工程师主导的,公司没有很多的产品经验,大部分项目都是由工程师主导的小项目。而且大部分的经理本身也是工程师,这可以保证他们了解项目的技术应用。
2 、在管理者与员工之间建立尊重
在紧密的小型项目团队之间的互信与尊重是苹果成功的秘辛。大部分苹果公司的管理者都有长期的工程师经历,这种相互理解也是能建立这种企业文化的重要因素。
Sachin Agarwal 说: “ 我的经理之前就是在苹果工作了 10 年的工程师。这让我更加努力地工作,希望获得他的激赏。 ”
3 、给员工更多自由去完善产品
在苹果公司,如果某位员工在使用产品的时候发现有烦人的问题,他们可以直接去解决,完善它,无须通过各种层级审批。所有的项目都有长期的目标,但是最好驱动源于员工自发的激情。
4 、用挑战促使员工成长
Sachin Agarwal 的经理会给他分派更难的任务,也许会超越了 Sachin Agarwal 的能力。但是他从中学到了东西。成为苹果公司员工 6 个月后,他就开始项目管理了。
Sachin Agarwal 说, “ 苹果公司非常善于发展自己的员工,让员工在公司的工作中学习到自我提升的各种技巧 ” 。
5 、目标期限非常关键
Sachin Agarwal 对于苹果对底线和质量的要求感受非常深刻。苹果质量标准是不发布不符合 “ 苹果标准 ” 的产品,但是他们有严格的目标期限,即便这意味着要删减部分未能及时完成的部分。
6 、不和竞争对手玩 “ 功能堆砌 ”
苹果不信奉产品功能的堆砌,它关注产品自身的目标,不去和竞争对手在功能数量上较劲。他们试图在同样的功能上超越对手。
苹果员工不关心对手做什么,他们由创新驱动,只是打造超越自身和现状的产品。这种苹果文化根深蒂固。
7 、招募那些有疯狂激情的员工
正如 Sachin Agarwal 所说,苹果公司工作的人,非常非常喜欢在公司工作。而他本人喜欢苹果,相信这是他生活的一切,所以他会加倍努力。
激情是苹果员工招募一个关键的因素。他们需要的是那种对公司,产品,整体格调和公司肩负的使命有着真正激情的人。
Sachin Agarwal 把这一套理念搬到了 Posterous ,他们招募的每一位员工都会说: “ 我们热爱这个产品,这就是为什么我们想为它而工作 ” 。
有 趣的是, Sachin Agarwal 在他自己博客的介绍中说 “I love good food, strong drinks, fast cars, photography and New York City , I’ve never owned a PC” ,这似乎是他们对苹果产品疯狂的一个最佳例证了。
8 、保持工作与生活的平衡非常重要
苹果公司非常强调工作与生活的平衡。工作需要努力但是公司也希望你享受自己的生活。苹果公司有很棒的医疗保险计划,有慷慨的假期安排。员工都喜欢公司提供的工作环境。员工喜欢在公司工作,他们工作卖命,但是完事后,你就该享受你的生活 —— 这是苹果一直宣示的理念。
最后, businessinsider 总结把苹果的成功归结为创业文化。他们认为,苹果没有官僚主义,他们有着工程师主导的文化,强调激情和文化认同,虽然是大公司但仍然保持着创业的文化。这种文化是苹果能获得巨大成功的关键环 节