一家公司发展的胡言乱语

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

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

评论

27 楼 clyman 2010-01-26  

vieri122 写道

弱弱的问一句，楼主公司现在还招人吗
嘎嘎~~~

同问,感觉很爽啊,什么都可以接触

26 楼 chaotian 2010-01-25  

楼主的文章很有启发和经验性。随着公司规模的逐渐增大，会产生各种各样的问题，小团队我们可以灵活处理，沟通层级少，成本低，大家关系和睦，相互理解。公司变大后，原来创业时期的和谐氛围逐渐消失，我们为了明确权责、制约、激励员工，设立和各种各样的部门，这样的发展是一环套一环。为了解决问题，设立了a职位（部门），问题消失了，新问题出现了，所以b职位（部门）设立了，新问题又出现了，如此往复循环，永无止境。
公司不断发展，这样痛苦的变革就会持续进行，而且公司越大，要做变动和设立新职位就越难，很多问题不是一年两年就可以改变的，阻力越来越大，对立越来越多，协调越来越困难。
我建议楼主从企业文化方面也考虑考虑，不同的企业文化对待相同事情有着不同的反应。

25 楼 lkj107 2010-01-25  

只是楼主的YY小说，鉴定完毕

24 楼 lonelybug 2010-01-23  

kunee 写道

lonelybug 写道

kunee 写道

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

据我现在工作环境的经验来说，一个超大系统维持超过10年，无数人更换，离去，依然保证系统运行，最主要的前提就是，文档，其次是设计的前瞻性。

不过，我接受的项目来说，前瞻性完全在于框架的设计，一个稳固的框架可以让一个系统稳定维持运转超过10年，甚至更久。甚至可以承受住重大版本更新，甚至是通信消息协议变更。

我不知道具体你们公司所作的项目，不过，就我现在工作来说，良好的框架设计，使重点中的重点。

补充以下，我说的框架是对应一种行业来说的系统框架，不是对应一个产品！

BSS，BOSS，这个领域核心的是企业模型，模型是先进的，应用是天天改版。相信你是电信行业的应该知道

这种系统责任又重大，一年异常停机时间只允许几十小时甚至更短，所以安全第一

惭愧了，我不是做电信的，不过，我做的行业系统也是要求高机密高安全和保证可靠的在线时间的。所以我明白你说的难处。

不过，还是觉得你应该花点时间和精力还有人力来做一个稳定的底层框架，之后的业务在上面搭建就简单的多了，而且容易测试。

我现在工作的这个框架是有两个公司分别完成前端和后端，不过，我看他们整合的也挺好。

23 楼 kunee 2010-01-22  

lonelybug 写道

kunee 写道

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

据我现在工作环境的经验来说，一个超大系统维持超过10年，无数人更换，离去，依然保证系统运行，最主要的前提就是，文档，其次是设计的前瞻性。

不过，我接受的项目来说，前瞻性完全在于框架的设计，一个稳固的框架可以让一个系统稳定维持运转超过10年，甚至更久。甚至可以承受住重大版本更新，甚至是通信消息协议变更。

我不知道具体你们公司所作的项目，不过，就我现在工作来说，良好的框架设计，使重点中的重点。

补充以下，我说的框架是对应一种行业来说的系统框架，不是对应一个产品！

BSS，BOSS，这个领域核心的是企业模型，模型是先进的，应用是天天改版。相信你是电信行业的应该知道

这种系统责任又重大，一年异常停机时间只允许几十小时甚至更短，所以安全第一

22 楼 kunee 2010-01-22  

lonelybug 写道

kunee 写道

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

据我现在工作环境的经验来说，一个超大系统维持超过10年，无数人更换，离去，依然保证系统运行，最主要的前提就是，文档，其次是设计的前瞻性。

不过，我接受的项目来说，前瞻性完全在于框架的设计，一个稳固的框架可以让一个系统稳定维持运转超过10年，甚至更久。甚至可以承受住重大版本更新，甚至是通信消息协议变更。

我不知道具体你们公司所作的项目，不过，就我现在工作来说，良好的框架设计，使重点中的重点。

补充以下，我说的框架是对应一种行业来说的系统框架，不是对应一个产品！

BSS，BOSS，这领域核心的是企业模型，模型是国际领先的，程序是天天改版

21 楼 中发白 2010-01-22  

楼主， 你不是在胡言乱语， 而是一针见血指出了很多管理上的弊病。

就我们公司，现在管理混乱，文档不成文档，项目经理、软件经理整个项目周期都见不上几次面。项目经理在片区， 软件经理在开发， 片区和开发的结算在项目前期就划分好了。项目经理和软件经理之间都在不停的博弈， 唉。 可怜的项目呀。。。

20 楼 lonelybug 2010-01-21  

kunee 写道

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

据我现在工作环境的经验来说，一个超大系统维持超过10年，无数人更换，离去，依然保证系统运行，最主要的前提就是，文档，其次是设计的前瞻性。

不过，我接受的项目来说，前瞻性完全在于框架的设计，一个稳固的框架可以让一个系统稳定维持运转超过10年，甚至更久。甚至可以承受住重大版本更新，甚至是通信消息协议变更。

我不知道具体你们公司所作的项目，不过，就我现在工作来说，良好的框架设计，使重点中的重点。

补充以下，我说的框架是对应一种行业来说的系统框架，不是对应一个产品！

19 楼 tedeyang 2010-01-21  

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

18 楼 kunee 2010-01-20  

王者之剑 写道

感觉按bug数发奖金不太靠谱。

是不太靠谱，哈哈。我们公司以前搞多，但是容易造成对立矛盾，反而进一步降低了生产力

17 楼 王者之剑 2010-01-20  

感觉按bug数发奖金不太靠谱。

16 楼 aaxron 2010-01-20  

针对一个需要重构的项目.
建议:
成立一个新的项目组.保留原有项目组成员中既懂业务又懂技术的
其他成员按情况安排.

旧项目组:只保留1-2个人进行维护.

15 楼 aaxron 2010-01-20  

团队大了,管理的问题凸显.


有意思哦,期待楼主的继续!

14 楼 orcl_zhang 2010-01-19  

楼主可以写小说去了。

13 楼 httpclient_bd 2010-01-19  

我认为在质量方面的度量可以引入发布后或者上线后的某级别以上的Bug率作为对QC和开发的共同评测指标。

12 楼 guyuean 2010-01-19  

感觉你们公司发展还是挺快的呢

11 楼 刃之舞 2010-01-19  

有的公司会将开发的管理跟项目经理拆分下来。我之前待过个公司就是这样的

项目经理完全负责项目的需求和需求拓展，但是不负责管理开发人员，项目经理可以带个组，这个组人不用多，几个人就好，只负责跟客户接洽需求和谈需求的工作量，维护项目运转，包括售前和售后。

开发单独存在个开发经理全权负责开发人员，根据技术栈的不同，分为java大组和c++大组，存在个大组长。每个技术大组下按模块划分技术小组，存在小组长，小组长跟大组长直接负责，大组长对开发经理负责，大组长的职务为开发控制，和管辖下的小组沟通配合提供协助，并且负责技术架构重构和技术难题的领导攻关。

项目经理接到需求或项目，跟客户谈判成功后发回完整的项目规划书和需求规格书，并责成自己的一个组员为需求接口人，负责开发人员和客户之间的业务疑点沟通。每个需求的工作量的谈判，有技术大组长组织具体开发人员和开发小组长进行评估。 技术大组长总体跟项目经理趋近于平级，但是项目经理更有话语权。

项目经理和开发经理问题归你调控

测试部拿到测试任务进行功能测试，出了BUG反馈给开发人员，一轮测试后，开发人员修改后提交新的版本，知道版本在测试部通过，BUG数对2个边都加点要求，要求开发人员需要一个月最多只能出几个，测试部一个月至少要测出几个。

测试部测试通过后，项目经理结合自己的维护人员开发人员选择具体时间对新版本进行上线和割接，也可以在现场加个测试服务器，现场需求接口人负责将新版本代码升级部署后进行部分验证，然后没有问题后，割接上线到正式的生产机。

10 楼 kunee 2010-01-19  

精彩

后面咋办，我们这也是安全第一，每次都是等重大版本变更才来个底朝天的改。但是每次业务前瞻性又做得不够，导致后续需求的跟进使代码，结构变得相当UGLY，支撑困难

9 楼 j2ee.iraqdream 2010-01-19  

楼主现在还招Java人员吗？

8 楼 LucasLee 2010-01-19  

lonelybug 写道

在你发现项目少的时候大量的人员没有事情做，当突然间很多项目的时候有人手不够，我觉得，你可以试着在大学中进行招聘，intership或者summer project student都是不错的方式，因为，这样你既培养了一部分有潜力经历过考核的潜在员工，又会减少人力资源上的浪费。

招聘兼职或新手，风险也是挺大的。
如果技术用得比较深入，或者有自己的框架，那么新人或兼职人员，在前3-5个月不但可能帮不上忙，还会拖项目后腿，这个是要好好考虑的