全球速卖通的模式

系统改进的空间还很大，物流，交易，风控，发布产品，搜索 产品，推广产品。

克服大团队的危险性

冯大师在博客DBA Notes中写”大团队的危险性“。这种危险性来自多种因素。大船“瓦沙”是一个大团队危性的常见结果。

1625年，瑞典国王古斯塔夫二世·阿道夫打算建造有史以来最棒的战舰。他雇了最好的造船工匠，专门种植了一片最刚硬的橡树林，都为了建造大船瓦沙。国王不断提出各种要求，希望把船建得更宏伟壮丽，到处都加上华美的装饰。有那么一天，他甚至决定在船上配备两套甲板炮，这是当时世界上绝无仅有的。他的船会是海上的霸王。而且由于迫在眉睫的外交问题，他还希望大船瓦沙能尽快造好。当然了，工匠们一开始的设计只有一套甲板炮，不过既然国王提出了要求，自然就得再加一套。由于太赶时间，工匠们来不及做“摇晃测试”──让一群水手从船的一边快跑到另一边，船在这种情况下不应该摇晃得太厉害（换句话说，没有头重脚轻）。结果，它的处女航只有几个小时，然后就沉入了海底：在给它加上所有华丽“特性”的同时，国王和工匠也让这条船变得根本无法航行。大船瓦沙在北海的海底长眠了几百年，直到20世纪初才被打捞出来，陈列在博物馆里。

一个有趣的问题：到底是谁导致了瓦沙的沉没？是国王，因为他要求了太多的特性？还是工匠，因为他们只顾着满足国王的要求，没有大声说出自己的担忧？看看你正身处其中的项目吧：你是不是正在建造又一艘瓦沙？

只做当下需要的。一开始这会很难，但最终你会得到一个更好的代码库。如果不引入不必要的复杂度，在修改或是重构时就不用对抗这些复杂度。程序员应该谨记：熵会杀死软件，所以，如无必要，勿增特性。

其实，这种危险性在我们的团队中一样存在。公司从最初的几十个人，用两年多的时候发展成500人。技术开发团队有200人的规模。一个总监，近10个经理或主管，每个经理下面15个员工左右（包括外包和实习生）。总监下属几个专家或架构师，各部门经理下面也有自已的架构师。这样的一支团队，从组织结构上看还是清楚的，但这已经是一支大团队。这支大团队会遇到这些问题：

1. 部门各自目标不同；每个部门都希望作出大成绩，搞大项目，以建立自已的影响力；大项目的启动成本是很高的，先要建立虚拟组织，建立新的合作流程，然后是角色分工，然后任务分解，再进入设计研发…….。因为是大项目，所以管理者一般不允充项目出问题，所以前期一定会精确管理，认真对待。
2. 每个部门有自已的风格，包括规范和流程，部门之间要统一流程和规范的话，需要大量时间进行培训；小团队流程很少，很多问题都直接口头交流；大团队为了加速不同部门人员的理解和统一思路，必须借用各用画图工具，项目管理软件等进行管理；很多团队为了用这些软件还需要进行角色培训；于是团队的成员一个个都成为了软件的使用者，准确的说，在被软件所使用。越来越多的只了解自已的环节，还不知道全局。
3. 决策层次太多，沟通低效。当需要跨部门合作时，沟通占用大量时间，并且沟通的层级会很多；为了保证项目的并行度，往往需要多部门合作。学计算机的人都知道，多线程并发的效率是最高的！然后多部门沟通时，人与人之间的沟通并不像线程这间的通信这么简单。好的架构设计和分工可以减少沟通或提高沟通效率。而分工和任务项的越细，并行度越高，会带来明显的沟通成本。人不是机器，计划总是不如变化快。一个蝴蝶可以引起一场海啸。一个小任务项的DELAY，一定会引起相关方的等待。与时，沟通产生了，但沟通的大会小会，一般不会进入项目计划。
4. 搞大项目，搞完美的项目，是大团队的通病。大技术团队，人强马壮，想去作一些小公司、小团队不敢想的大项目；那些很好的小项目，只要综合好了，一样可以产生大项目的效果。但是，大团队如果去作小项目，那这个大团队存大的价值就会被挑战。作大项目的时候，大团队会在一开始就严格要求每一个细节每一个feature，很多80%的人在80%的时候 不会用的功能在一开始就被设计进去，并要求zero bug。
5. 管理者确实喜欢搞一些统一的基础服务或基础设施；让别的项目或产口依赖这些基础，从而带来问题是，这些基础服务一点变动或升级，一定会引起上层依赖方的回归测试或各种问题。于是，有些时候上层应用宁可自已研发一个独立的基础服务。但这样又会进入一种不统一的状态，管理者会认为大量软件基础被重复研发了，于时又开始会提出统一的架构与基础设施。这时候另一方，即商业部门会来挑战说“为什么完成这样的一个FEATURE需要这么多时间呢？”；基础服务还需要有很多的培训学习期，比不上市场上的开源软件广为人知；
6. 大团队里很容易让个人的工作积极性受压制。成绩在很多时候是个人英雄主义的产物。大团队里如何发展个人英雄主义？老板们者很头痛，因为这个确实是个麻烦事。

大团队的危险性大家都深有体会。我们可以从几点来克服或减小他的危害性：

1. 让小团队，小部门去完成大项目；很多互联网知名公司和网站都是由小团队创建的。小团队适合初创的项目；
2. 减少决策层次，充份信任最接近用户和客户，离炮火最近的决策人；使用最简单的决策工具。
3. 搞小项目，把小项目组合成大项目；
4. 多用已有的开放软件或组件，少作统一封装。竟可让各应用自由封装，也不要出统一的服务。除非这个统一的服务边界相当明显，调用相当方便，否则我建议宁可费点人工重写，也不宜搞统一封装提供给多个不同的业务或上层应用。互联网上，没有什么东西找不到的。可以搞小团队内的封装，但不建议强制大团队的统一。这种统一只会减少团队工作的灵活性。传统软件的管理者一般会倾向于选择统一的底层封装，而互联网服务的海量客户导向特性却要求极高的灵活性。很多产品的生命周期是很短的。服务器一开，项目启动了，服务器一关，项目就结束了；
5. 作减少，不要作加法。一开始就要减少需求，减少那些少量用户会用的功能，把主流程，主要服务搞好。让大部份主要功能可以稳定的工作。
6. 允许BUG，搞好业务相关的功能。互联网是一个工具，把工具相关的功能作好。允许项目中存在BUG,并让用户去发现。这一点和WEB2.0的BETA理念一致，大团队一样可以用这个理念。
7. 给团队成员时间去学习和创造，让成员有机会成为英雄。

PS: 经常回想99年的时候作项目，三五个人，快乐的工作。

创业团队破坏成功的几个要素

创业很难，成功的团队很少。电视里在讲，4个毕业生合股成立了一个小电脑公司。没多久，由于分工不明确，权职不清晰，4人之间在对事情有不同看法时交流不通畅，目标不明确，最终，一年后，散伙了。

有些大公司也在创业，这些公司讲愿景，讲梦想，讲管理，讲流程，讲执行力，讲组织结构。这样的公司很可能成功，她有很好的基因和很高的竟争门槛。然而，在我看来，大公司大团队创业和小公司小团队是一样的，一样的问题，一样的原因会破坏成功的路。

治大国如烹小鲜。再大的理论，再多的执行力，最终，是要人去实现的。我从99年开始正式作团队。作团队的每一天，都在想把通过团队取得目标。在学校的时候目标是作校园内的影响力，在公司的时候目标是完成一些超出领导期望的业绩。这些目标不一定都能达成。小结一下，以下要素会破坏目标的成功达成：

1. 上面没人；很多目标的达成，是需要上面有人引路的，这些引路的人是支点；拥有一个支点，将增大成功的可能；
2. 下面没人；作一个创业项目需要不同的角色。没有很好的执行者，再好的idea也是空想；idea太廉价，路上随变拉一个人，都可以说出一大堆的想法；谁去作呢？
3. 太多的人；今天刚看了一个blog，说winamp当初是出何的出众，一个小团队的作品。我看到winamp的时候有一种天生的亲切感。太熟悉了，我在2000年作的音乐分享网站上，近3万首MP3，都使用这个软件播放；音乐分享站的首页就是推荐这个软件进行“试听”；后来这个软件不知道怎么就没名气了。连她什么时候变的无变，我也不知道。 直到今天看到这个BLOG，我才知道，原来这个软件的小公司被AOL收购了。AOL是什么？大公司，肯定不差钱，也不差人。可以想象的道，这个软件在被收购之后，增加了无数的人。这些人需要被管理，管理就需要有流程，有沟通，有制度，有过程。这一切都需要以时间为代价。这样的软件消失在无形之间，他的最大破坏杀手，那就是人太多了！很多创业公司的事，其实一个人是可以作的，当然5个人也可以完成。为了使5个人的共同完成一个目标和任务，这5个人需要沟通与管理。于是，流程出现了，5人之中为了建立分工，需要先进行任务分解，为了分解任务，需要找到清楚的边界。为了边界的权责明确，需要建立check的机制。同时。为了5个的进展同步，需要一定的sync机制，日报，周报，晨会，等等，都由此产生了。5个人往往比一个人更不容易出成果。因为5个人需要协同，需要和谐与平衡，一些很好的见解和观点，在5人的平衡过程中消失了。而如果是一个人呢？ipod,iphone,mac等这些APPLE的产品设计师一直是同一个人，他的观点和思维方式是非常特别的，他可以一个人发出声音，就算他的决定不能说服别人，不能让所有人理解，他还是一样可以坚持作下去。他是一个可以飙高音的人。因为他只是一个人。人，在创业初期，还是少一点好。
4. 不合适的人；我这30年的人生经历坚持这点：世界上没有完人！没有一个人可以作所有的事。所以一定要让合适的人作合适的事。什么样的人是合适的？并不是让所有人满足的人一定是合适的人。不同的创业阶段需要不同的人。创业初期，团队里更需要能集合众人智慧，能沟通，能准确体验客户。创业初期的人，一定要敏而好学，能容忍问题的现实，能想办法解决问题。
5. 不会找主要矛盾的人；这是一个很简单的道理，以前小学里，我们曾经不泻一顾，我们曾认为这是一个是人都明白的理。当然要抓主要矛盾。然后，又有多少大公司小团队这样作到了。当gmail以beta精神带动web2.0概念的时候，人们还在议论，web2.0是不是纯概念？我真是想不通，为什么很多人，包括上面的人，还不明白beta精神对于创业初期的重要性？还是那个软件winamp，当他最初发布的时候，他的说明里有一句“这个软件大部份功能可以用”。这句话一般人我想都会反对，因为他们不懂什么是主要矛盾。我却非常，十分，绝对认同这句话。这句话的表明了软件创作者那种服务客户主要需求的目标，也需这个软件还有一些功能不可用，但在不影响用户人生安全的前提下，这个软件把这些功能也布出来了，这又影响了谁呢？影响了创业公司的形象？or影响了这个软件以续的发展空间？事实证明这个软件相当成功。当然，在人太多之后，这个软件被破坏了。所以，创业公司一定要抓 主要矛盾。如果不能把这种精神在整个团队内通行无阴，那么他将对创业团队产生巨大的破坏力。我已经看多了，在一般的创业团队里，”这很正常“。

因为我改的BUG都比你写的程序多，所以各位看官，一定要相信我。这些破坏份子，如果你不能解决，那你失败不远了。

一个坚难的产品上线过程

原本预计一周的一个项目计划，实际用了三周才完成。上周六早晨，当多走出创业大厦的时候，已经不能再思考什么了，不想吃早饭也感受不到多少上线的快乐，只想快点回去睡下。

项目过程总是充满变化，没人能把整个过程事先作好计划，但是总有人能比别人看得更远。

XP实践一二

XP这词和agile一样，被用烂了，不管懂不懂，总有人喜欢用这词。

从几个人的团队到二十几个人的团队，从几百块钱的小项目到上千万的项目，几年的项目经历给我带来的思考很多。当团队小的时候，我一个人就从事很多的事，从头到尾大小事通吃，很有成就感，非常清楚今天作了什么，明天要作什么，什么时候能作到什么样子。当团队大点的时候，效率，进度和质量就成为新的问题。 Extreme Programming(极限编程简称XP)是由Kent Beck在1996年提出的软件项目管理流程。有于解传传通软件开发的效率，进度和质量问题。互联网产品是一种有特色的产品，接近客户，快速反应是两大典型的特色。如何在解决传统软件效率，进度和质量问题基础上突出以上两大特征？从XP的实践中，我还是找到了一些感觉： 1：XP工作环境，GOOGLE据说也在用XP，小团队，小的CUBE，在一个不同一般的办公环境中“自由”的工作。放个帐篷在CUBE中也不会影响其它CUBE的同事，在一个CUBE中的同事随时可以共同休息，玩乐，编码，看似散乱，实际是劳逸结合的最佳实践； 2：XP的需求与设计，简单就是最好，从客户视角的第一感觉出发，作最能帮助人类省时省事的懒汉交互。马总说了：懒人创造世界。设计文档力求图型化，开发人员要一看就懂，细节的问题遇到再与设计沟通。永远只需要沟通今天需要了解的细节。 3：XP的编码，让测试成为代码质量买保险。有保险，就有信心写下去，并重构之。 4：XP的项目计划，两周左右的一个Release Planning，每天明确目标，哪些已经作完，哪些今天要作完，哪些问题，不段调整计划。