一家公司发展的胡言乱语

终于一天早上，睁开极不情愿被睁开的眼睛，厌倦了文档、厌倦了没完没了的BUG、需求反复、项目延期，做出一个极为重要的决定：自己干。忽悠到2个人，于是创业开始。

第一个项目时间很紧张，是经过层层外包转包而来，尽管利润微薄，但是3个人在一起非常开心，我们做持续集成、做自动化测试，所有问题都经过集体讨论解决，很累，但每个人都很努力，因为大家的目的都是一致的。终于，项目按时完成，我们拿到自己挣到的第一笔钱。

由于第一个项目完成的很不错，我们很快接到了第二个项目，第二个项目比较大，公司很快又招了好几个人，公司的规模扩充到10人左右，因为只有一个项目，大家还是在一个项目组中共同努力，每个人都比较开心，尽管有些时候，也会为一些编程问题发生争吵，不过现在这还不是一个问题。我们很敏捷，第二个项目也完成的很好。

一年之后，公司发展顺利，已经扩大到50人左右，可以同时进行多个项目了。我们按照项目组建团队，每个团队都是全功能团队，包括了业务分析、程序员、测试和项目经理。项目经理对整个项目负责，同时向我汇报工作。我不再参加编程，因为我现在很忧愁：上个月，因为没有项目，那帮程序员天天聊QQ，这真让我苦闷！这个月突然又有了好几个项目，靠，那帮程序员不够用了！项目经理向我抱怨要增加人手。这种忧愁的生活让我生活像坐过山车，不踏实。我已经将自己的全部精力投入到市场和销售中去，我需要有市场计划，但是这个好像不受我的控制。不管怎么样，稳定的项目来源是我最关注的，我决定多找些市场和销售人员。

不过开发这块还是让我很放心的，每个项目组都很敏捷，每个项目组都很独立，没有争吵。但是也存在问题，因为项目来源很杂，基本上是只要赚钱就要做，所以所用的技术也很杂，java\c#\ruby\groovy\php，这对有些程序员来说是好事，扩大了他们的视野，但是也有些程序员很不喜欢，因为他们认为太泛，要不停的学习，他们喜欢找一门语言专下去。同时，我也发现了另外一些问题，就是项目质量也会受到技术的影响，其中就有个java的项目，因为是swing，很多人不熟悉，结果项目发生了延期。我很生气，找到了该项目的项目经理，项目经理很委屈：为什么我们什么项目都接，都不能选择性的接吗？这又回到了市场的原因，我们还远未强大到选择接项目的地步。同时，项目组之间产生了互斥的关系，项目经理们都很不愿意就技术问题互相帮助，A项目组以前有人做过PHP，B项目组现在做PHP，当B项目组需要帮组时，A项目组以工作忙进行了拒绝。就这个问题，我找一些骨干成员进行了讨论，决定成立相应的开发社区，这是个虚拟组织，定期组织相关的技术培训，这个组织跨越项目组的界限。但是后来我又发现，其实这样的效果也不是很好，技术积累很有限，一些项目做得相当初级，关键原因还是技术太杂，人员变动太大。这时，我决定找个专职的HR，从入职入手，只找符合公司标准的人才，要尽量找到聪明的程序员，为此，每次面试，我都尽量参加。

不管怎么说，除去市场和销售，我还是感到满意的。现在公司按照项目组建项目性团队，每个团队都是全功能团队，这样最重要的好处就是解决了工作中的工作相依性，BA\Dev\QA都在一个项目组中，有任何问题都可以进行非正式的沟通，这样如果需求有任何变化，整个项目组能够非常容易的进行调整，同时，通过将客户拉入项目，一方面能够迅速的进行反馈和拥抱变化，另一方面，客户也会承担一定的项目风险。

又一年过去了，公司取得了进一步的成功，这次的成功来自于市场，由于我们在电信行业进行了一系列成功的项目，使得我们的软件在电信行业小有名气，这时我做出了一个重要的决定：公司性质的转型，由项目性公司转为行业公司，我们只做电信相关的项目，同时技术栈也固定为c++和java。这样的好处是很明显的，首先就是通过进入细分行业，项目的来源比较稳定了，二来我们也比较容易的积累业务和技术。

同时，我发现了一些问题：项目规模开始扩大，有项目经理向我抱怨，他根本没有办法同时管理20多个人的项目团队，除去客户之外，他每天的工作就是在听组员汇报、处理冲突，忙不过来。我意识到，当项目组主要采取有机结构和非正式沟通时，项目管理者根本管理不过来超出20人的团队。同时，因为电信企业都拥有相同的业务背景和标准，他们的需求都非常相似，处于不同项目组的BA私下里经常沟通，互相请教问题，因为电信一系列的标准化，所以对BA也提出了要求，他们需要了解电信的这些业务和标准，而不是什么都去问客户。这样，很快，我将所有的BA都从项目组里抽出来，组成了单独的需求部门，项目经理的管理人数减少了，BA们可以聚集在一起解决问题，并对相似的问题进行整理，编写文档，业务知识能够很容易积累。但是这样做也有成本，就是Dev需要找BA确定需求，这样割裂了原有的工作相依性，但是因为需求比较稳定，Dev和BA的沟通成本尽管上升，但是总的次数减少了，这是我希望看到的。很多时候，BA通过文档与Dev沟通，这并没有想象中的那么坏，需求的稳定将这个坏处减少了，同时，项目经理总是可以组织BA和Dev不定期进行非正式沟通。

因为技术栈和需求稳定，我开始独立出单独的产品部，将通用的功能和底层技术栈进行封装。我开始重视文档，我要求产品部尤其重视文档和代码注释，文档在于产品部与项目部的沟通大部分要依靠文档，在不能进行非正式沟通的情况下，文档是唯一的选择，同时，文档在需要长期维护的代码里也非常关键，尽管结对，但是我不能认为每个人都能对所有代码都很熟悉，同时，项目规模的扩大，必然要划分模块组，结对也只是限定在模块组内，即只要有部门的划分，则必然需要文档来沟通！尽管很多人相信代码是最好的文档，但是很多人也忘记了一个很重要的前提，即好的代码才是最好的文档，我更愿意相信由于种种管理因素（部门之间的隔阂、成员之间水平的差异、进度）的影响，代码必然是逐渐腐化的，所以，在代码水平做不到很好时，就必须有文档，必须有注释！

公司继续发展，项目规模越来越大，我按照模块对项目进行了划分，每个模块对应于一个开发小组，每个小组一个负责人员，他们向项目经理负责，项目经理向我负责，同时项目部门依赖于产品部门。部门之间的沟通通常情况下依赖文档，由我统一进行两个部门之间的协调。

终于，发生了一件很严重的事情，交付的项目出现了一个严重的BUG，这让我很生气，开始追究责任，最后发现BUG出现在两个开发小组之间的一个接口约定，于是文档的要求进一步严格了，同时，公司成立了独立的质量保证部，对交付的项目进行统一测试。很自然，为了激励测试部的积极性，我规定按发现BUG的数量发放测试部的奖金。

于是，我发现，项目中到处都是文档、开发人员与QA对立严重，代码质量以安全第一，不愿重构，这一切，都是我当初最反感的。我怀念起最开始的日子。于是，我开始找敏捷咨询，通过外部力量进行部分的改进。。。。

很明显，我个人所理解的全功能团队（即所有成员都在一个部门里）将变得不太可行，而必然会产生某种形式的分组，不管是正式的还是非正式的，这种分组而产生的沟通成本可以认为是管理成本的一部分。

评论

47 楼 cliff4 2011-12-15  

很不错，欣赏楼主的见解，尽管是一篇文章

46 楼 cloudtopo 2010-10-26  

即使不是真实的经历，看得出楼主还是有些工作阅历的.

45 楼 bonny 2010-10-26  

似乎是个YY小说

44 楼 kinglyhum 2010-10-26  

tedeyang 写道

楼主这个过程起码要10年。

我也很关注LZ走完上述流程，不断积累改进到底花了多久，而且中间基本都是理想情况，在发展初期未出现致命性的错误。要知道任何事物在初期势力都是十分的微小，任何失误都可能将前途葬送。实际情况远比这曲折复杂，且天朝的国情，国内创业想成一定气候（小打小闹除外）基本就是抱到托拉斯粗腿，否则成事难矣。鄙人出道不久，浅谈拙见，欢迎讨论

43 楼 bangyan2003 2010-10-24  

fm_974 写道

于是，我发现，项目中到处都是文档、开发人员与QA对立严重，代码质量以安全第一，不愿重构，这一切，都是我当初最反感的。我怀念起最开始的日子。

-- 于是造就了新的创业者。

呵呵，写的很好！

有点阴阳循环的味道。人事过多 可以离去矣 这么说lz理想主义者。

42 楼 fm_974 2010-05-17  

于是，我发现，项目中到处都是文档、开发人员与QA对立严重，代码质量以安全第一，不愿重构，这一切，都是我当初最反感的。我怀念起最开始的日子。

-- 于是造就了新的创业者。

呵呵，写的很好！

41 楼 rikeinei 2010-04-21  

twobowl_eye 写道

楼主展示了公司内部管理上的优化和发展，这很好，不知在这期间，市场业务方面的成长路线是怎样的？

同样的疑问，请楼主介绍一下

40 楼 hotjuly 2010-03-20  

也许正如楼主厌倦了无尽的编码bug什么的后走上了创业这条路一样，往后发展也深深的带上这种烙印，每当厌倦了便竭力思索改革，这些努力也带来了回报。可我想说的是楼主事业的快速发展是在中国电信行业飞速发展的基础上才产生的，这是大道理，希望楼主在事业中多关注些大道理，获得更大的事业。

39 楼 simonlzs 2010-03-17  

frank_je 写道

tedeyang 写道

楼主这个过程起码要10年。

楼主的文章只是个传说，而不是事实！！

不是传说，是大多中国IT企业的缩影，特别是像我们这批70后的人感触会很明显，有小作坊发展起来的很多，模式也是基本如此。

38 楼 zmeng 2010-03-15  

很棒，很真实，就是一个打天下的过程

37 楼 JJYAO 2010-03-04  

个人现在能想到的一些见解：
1. 公司一大，就要讲战略，前瞻性，未来3，5年，在大方向上避免走弯路，否则纠正的成本是巨大的
2. 避免公司出现严重的政治问题，虽然有人的地方就有江湖，但尽量减少江湖，维护公司的健康是极其重要的
3. 关键位置上要有优秀，并且敬业的人，并且建立良好的奖惩制度
4. 重视员工，重视文化，将实的做虚，将虚的做实
5. 关注员工的生产力
6. Boss自己需要建立人格魅力，要有前瞻性和创新能力，在自己认为对的地方不能被旁人左右，但同时也要能够乐于倾听
7. 重视产品的用户体验

最后一句话，成功是折腾出来，伟大是折磨出来的。大公司，问题必然多，报着乐观的心态去接受问题，解决问题，反而会得到好的结果

36 楼 specsence 2010-02-26  

可能你忽略了一点：项目大了要强调系统设计后的分隔性。

我觉得一个真正优秀的架构师很可能解决你的很多问题，我始终都觉得架构师不是开发经理，他的工作是进行正确拆装设计，把合适的实在放在合透的位置（web, server or DB).

不好，好架构师难找，但公司到一定规模了必须要找。看起来是需求和开发，QA和DEV之间的问题，实际上很可能是在需求和开发间没有做系统设计导致。

35 楼 lkj107 2010-02-26  

Teok 写道

你们这群有眼无珠的家伙，楼主可是大牛。。

workflow，BPM方面的牛人，并不是说各个方面的牛人
不过看很多获得图灵奖的那些人真是很多方面都是登峰造极的水平

34 楼 lkj107 2010-02-26  

国内创业最简单的是某人有一些关系，能拿到单子，于是乎请个懂技术的熟人帮忙招聘个项目经理，再有项目经理找几个人，开始整
真正的搞技术出身的，别管你技术多牛，在国内创业，基本都是死路一条
所以第一步是有关系

33 楼 hongfei3 2010-02-08  

我们公司的发展经历竟然也如此的相似，从老板创业到现在有快7年了，有400多人。人员按行业做了分类，逐级有中心、部门和项目组，人员按部门来管理，顾问部、测试部和多媒体部也独立了出去。部门间、项目间的那些纠结的事情肯定少不了，但文档肯定是非常必要的，尤其夸项目互相协作的时候，好几期的长线项目。

我们也是电信业，都是按项目走的，现在这个阶段最头疼还是竞争压力，如何减少成本？如何使我们比别人更有竞争力？现在电信方也压缩成本，减低单价了还要求总价打折，而且跳水的越来越多，2010年改革势在必行啊。

我不是什么cto，只是一个在公司待的比较久的员工，看到楼主写了这么多，有感而发。

32 楼 powerclark 2010-01-29  

谢谢楼主的分享，其实看的确实很真实。
对于一家公司的成长，确实会遇到这样种种的问题。
祝lz能够在未来的道路上一切顺利！！！

31 楼 Teok 2010-01-29  

你们这群有眼无珠的家伙，楼主可是大牛。。

30 楼 dch1287 2010-01-28  

楼主学习了一些软件开发过程模型，有重量级的，也有轻量级的，读了不少相关的书
了解了相关历史，思考了现状

然后编纂出这么个小说
不错不错 很有前途

29 楼 frank_je 2010-01-28  

tedeyang 写道

楼主这个过程起码要10年。

楼主的文章只是个传说，而不是事实！！

28 楼 twobowl_eye 2010-01-28  

楼主展示了公司内部管理上的优化和发展，这很好，不知在这期间，市场业务方面的成长路线是怎样的？