一家公司发展的胡言乱语

终于一天早上，睁开极不情愿被睁开的眼睛，厌倦了文档、厌倦了没完没了的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对立严重，代码质量以安全第一，不愿重构，这一切，都是我当初最反感的。我怀念起最开始的日子。于是，我开始找敏捷咨询，通过外部力量进行部分的改进。。。。

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