终于一天早上,睁开极不情愿被睁开的眼睛,厌倦了文档、厌倦了没完没了的BUG、需求反复、项目延期,做出一个极为重要的决定:自己干。忽悠到2个人,于是创业开始。
第一个项目时间很紧张,是经过层层外包转包而来,尽管利润微薄,但是3个人在一起非常开心,我们做持续集成、做自动化测试,所有问题都经过集体讨论解决,很累,但每个人都很努力,因为大家的目的都是一致的。终于,项目按时完成,我们拿到自己挣到的第一笔钱。
由于第一个项目完成的很不错,我们很快接到了第二个项目,第二个项目比较大,公司很快又招了好几个人,公司的规模扩充到10人左右,因为只有一个项目,大家还是在一个项目组中共同努力,每个人都比较开心,尽管有些时候,也会为一些编程问题发生争吵,不过现在这还不是一个问题。我们很敏捷,第二个项目也完成的很好。
一年之后,公司发展顺利,已经扩大到50人左右,可以同时进行多个项目了。我们按照项目组建团队,每个团队都是全功能团队,包括了业务分析、程序员、测试和项目经理。项目经理对整个项目负责,同时向我汇报工作。我不再参加编程,因为我现在很忧愁:上个月,因为没有项目,那帮程序员天天聊QQ,这真让我苦闷!这个月突然又有了好几个项目,靠,那帮程序员不够用了!项目经理向我抱怨要增加人手。这种忧愁的生活让我生活像坐过山车,不踏实。我已经将自己的全部精力投入到市场和销售中去,我需要有市场计划,但是这个好像不受我的控制。不管怎么样,稳定的项目来源是我最关注的,我决定多找些市场和销售人员。
不过开发这块还是让我很放心的,每个项目组都很敏捷,每个项目组都很独立,没有争吵。但是也存在问题,因为项目来源很杂,基本上是只要赚钱就要做,所以所用的技术也很杂,java\c#\ruby\groovy\php,这对有些程序员来说是好事,扩大了他们的视野,但是也有些程序员很不喜欢,因为他们认为太泛,要不停的学习,他们喜欢找一门语言专下去。同时,我也发现了另外一些问题,就是项目质量也会受到技术的影响,其中就有个java的项目,因为是swing,很多人不熟悉,结果项目发生了延期。我很生气,找到了该项目的项目经理,项目经理很委屈:为什么我们什么项目都接,都不能选择性的接吗?这又回到了市场的原因,我们还远未强大到选择接项目的地步。同时,项目组之间产生了互斥的关系,项目经理们都很不愿意就技术问题互相帮助,A项目组以前有人做过PHP,B项目组现在做PHP,当B项目组需要帮组时,A项目组以工作忙进行了拒绝。就这个问题,我找一些骨干成员进行了讨论,决定成立相应的开发社区,这是个虚拟组织,定期组织相关的技术培训,这个组织跨越项目组的界限。但是后来我又发现,其实这样的效果也不是很好,技术积累很有限,一些项目做得相当初级,关键原因还是技术太杂,人员变动太大。这时,我决定找个专职的HR,从入职入手,只找符合公司标准的人才,要尽量找到聪明的程序员,为此,每次面试,我都尽量参加。
不管怎么说,除去市场和销售,我还是感到满意的。现在公司[b]按照项目组建项目性团队,每个团队都是全功能团队,这样最重要的好处就是解决了工作中的工作相依性,BA\Dev\QA都在一个项目组中,有任何问题都可以进行非正式的沟通,这样如果需求有任何变化,整个项目组能够非常容易的进行调整,同时,通过将客户拉入项目,一方面能够迅速的进行反馈和拥抱变化,另一方面,客户也会承担一定的项目风险。[/b]
又一年过去了,公司取得了进一步的成功,这次的成功来自于市场,由于我们在电信行业进行了一系列成功的项目,使得我们的软件在电信行业小有名气,这时我做出了一个重要的决定:公司性质的转型,由项目性公司转为行业公司,我们只做电信相关的项目,同时技术栈也固定为c++和java。这样的好处是很明显的,首先就是通过进入细分行业,项目的来源比较稳定了,二来我们也比较容易的积累业务和技术。
同时,我发现了一些问题:项目规模开始扩大,有项目经理向我抱怨,他根本没有办法同时管理20多个人的项目团队,除去客户之外,他每天的工作就是在听组员汇报、处理冲突,忙不过来。我意识到,当项目组主要采取有机结构和非正式沟通时,项目管理者根本管理不过来超出20人的团队。同时,因为电信企业都拥有相同的业务背景和标准,他们的需求都非常相似,处于不同项目组的BA私下里经常沟通,互相请教问题,因为电信一系列的标准化,所以对BA也提出了要求,他们需要了解电信的这些业务和标准,而不是什么都去问客户。这样,很快,我将所有的BA都从项目组里抽出来,组成了单独的需求部门,项目经理的管理人数减少了,BA们可以聚集在一起解决问题,并对相似的问题进行整理,编写文档,业务知识能够很容易积累。但是这样做也有成本,就是Dev需要找BA确定需求,这样割裂了原有的工作相依性,但是因为需求比较稳定,Dev和BA的沟通成本尽管上升,但是总的次数减少了,这是我希望看到的。很多时候,BA通过文档与Dev沟通,这并没有想象中的那么坏,需求的稳定将这个坏处减少了,同时,项目经理总是可以组织BA和Dev不定期进行非正式沟通。
因为技术栈和需求稳定,我开始独立出单独的产品部,将通用的功能和底层技术栈进行封装。我开始重视文档,我要求产品部尤其重视文档和代码注释,文档在于产品部与项目部的沟通大部分要依靠文档,在不能进行非正式沟通的情况下,文档是唯一的选择,同时,文档在需要长期维护的代码里也非常关键,尽管结对,但是我不能认为每个人都能对所有代码都很熟悉,同时,项目规模的扩大,必然要划分模块组,结对也只是限定在模块组内,即只要有部门的划分,则必然需要文档来沟通!尽管很多人相信代码是最好的文档,但是很多人也忘记了一个很重要的前提,即好的代码才是最好的文档,我更愿意相信由于种种管理因素(部门之间的隔阂、成员之间水平的差异、进度)的影响,代码必然是逐渐腐化的,所以,在代码水平做不到很好时,就必须有文档,必须有注释!
公司继续发展,项目规模越来越大,我按照模块对项目进行了划分,每个模块对应于一个开发小组,每个小组一个负责人员,他们向项目经理负责,项目经理向我负责,同时项目部门依赖于产品部门。部门之间的沟通通常情况下依赖文档,由我统一进行两个部门之间的协调。
终于,发生了一件很严重的事情,交付的项目出现了一个严重的BUG,这让我很生气,开始追究责任,最后发现BUG出现在两个开发小组之间的一个接口约定,于是文档的要求进一步严格了,同时,公司成立了独立的质量保证部,对交付的项目进行统一测试。很自然,为了激励测试部的积极性,我规定按发现BUG的数量发放测试部的奖金。
于是,我发现,项目中到处都是文档、开发人员与QA对立严重,代码质量以安全第一,不愿重构,这一切,都是我当初最反感的。我怀念起最开始的日子。于是,我开始找敏捷咨询,通过外部力量进行部分的改进。。。。
很明显,我个人所理解的全功能团队(即所有成员都在一个部门里)将变得不太可行,而必然会产生某种形式的分组,不管是正式的还是非正式的,这种分组而产生的沟通成本可以认为是管理成本的一部分。
第一个项目时间很紧张,是经过层层外包转包而来,尽管利润微薄,但是3个人在一起非常开心,我们做持续集成、做自动化测试,所有问题都经过集体讨论解决,很累,但每个人都很努力,因为大家的目的都是一致的。终于,项目按时完成,我们拿到自己挣到的第一笔钱。
由于第一个项目完成的很不错,我们很快接到了第二个项目,第二个项目比较大,公司很快又招了好几个人,公司的规模扩充到10人左右,因为只有一个项目,大家还是在一个项目组中共同努力,每个人都比较开心,尽管有些时候,也会为一些编程问题发生争吵,不过现在这还不是一个问题。我们很敏捷,第二个项目也完成的很好。
一年之后,公司发展顺利,已经扩大到50人左右,可以同时进行多个项目了。我们按照项目组建团队,每个团队都是全功能团队,包括了业务分析、程序员、测试和项目经理。项目经理对整个项目负责,同时向我汇报工作。我不再参加编程,因为我现在很忧愁:上个月,因为没有项目,那帮程序员天天聊QQ,这真让我苦闷!这个月突然又有了好几个项目,靠,那帮程序员不够用了!项目经理向我抱怨要增加人手。这种忧愁的生活让我生活像坐过山车,不踏实。我已经将自己的全部精力投入到市场和销售中去,我需要有市场计划,但是这个好像不受我的控制。不管怎么样,稳定的项目来源是我最关注的,我决定多找些市场和销售人员。
不过开发这块还是让我很放心的,每个项目组都很敏捷,每个项目组都很独立,没有争吵。但是也存在问题,因为项目来源很杂,基本上是只要赚钱就要做,所以所用的技术也很杂,java\c#\ruby\groovy\php,这对有些程序员来说是好事,扩大了他们的视野,但是也有些程序员很不喜欢,因为他们认为太泛,要不停的学习,他们喜欢找一门语言专下去。同时,我也发现了另外一些问题,就是项目质量也会受到技术的影响,其中就有个java的项目,因为是swing,很多人不熟悉,结果项目发生了延期。我很生气,找到了该项目的项目经理,项目经理很委屈:为什么我们什么项目都接,都不能选择性的接吗?这又回到了市场的原因,我们还远未强大到选择接项目的地步。同时,项目组之间产生了互斥的关系,项目经理们都很不愿意就技术问题互相帮助,A项目组以前有人做过PHP,B项目组现在做PHP,当B项目组需要帮组时,A项目组以工作忙进行了拒绝。就这个问题,我找一些骨干成员进行了讨论,决定成立相应的开发社区,这是个虚拟组织,定期组织相关的技术培训,这个组织跨越项目组的界限。但是后来我又发现,其实这样的效果也不是很好,技术积累很有限,一些项目做得相当初级,关键原因还是技术太杂,人员变动太大。这时,我决定找个专职的HR,从入职入手,只找符合公司标准的人才,要尽量找到聪明的程序员,为此,每次面试,我都尽量参加。
不管怎么说,除去市场和销售,我还是感到满意的。现在公司[b]按照项目组建项目性团队,每个团队都是全功能团队,这样最重要的好处就是解决了工作中的工作相依性,BA\Dev\QA都在一个项目组中,有任何问题都可以进行非正式的沟通,这样如果需求有任何变化,整个项目组能够非常容易的进行调整,同时,通过将客户拉入项目,一方面能够迅速的进行反馈和拥抱变化,另一方面,客户也会承担一定的项目风险。[/b]
又一年过去了,公司取得了进一步的成功,这次的成功来自于市场,由于我们在电信行业进行了一系列成功的项目,使得我们的软件在电信行业小有名气,这时我做出了一个重要的决定:公司性质的转型,由项目性公司转为行业公司,我们只做电信相关的项目,同时技术栈也固定为c++和java。这样的好处是很明显的,首先就是通过进入细分行业,项目的来源比较稳定了,二来我们也比较容易的积累业务和技术。
同时,我发现了一些问题:项目规模开始扩大,有项目经理向我抱怨,他根本没有办法同时管理20多个人的项目团队,除去客户之外,他每天的工作就是在听组员汇报、处理冲突,忙不过来。我意识到,当项目组主要采取有机结构和非正式沟通时,项目管理者根本管理不过来超出20人的团队。同时,因为电信企业都拥有相同的业务背景和标准,他们的需求都非常相似,处于不同项目组的BA私下里经常沟通,互相请教问题,因为电信一系列的标准化,所以对BA也提出了要求,他们需要了解电信的这些业务和标准,而不是什么都去问客户。这样,很快,我将所有的BA都从项目组里抽出来,组成了单独的需求部门,项目经理的管理人数减少了,BA们可以聚集在一起解决问题,并对相似的问题进行整理,编写文档,业务知识能够很容易积累。但是这样做也有成本,就是Dev需要找BA确定需求,这样割裂了原有的工作相依性,但是因为需求比较稳定,Dev和BA的沟通成本尽管上升,但是总的次数减少了,这是我希望看到的。很多时候,BA通过文档与Dev沟通,这并没有想象中的那么坏,需求的稳定将这个坏处减少了,同时,项目经理总是可以组织BA和Dev不定期进行非正式沟通。
因为技术栈和需求稳定,我开始独立出单独的产品部,将通用的功能和底层技术栈进行封装。我开始重视文档,我要求产品部尤其重视文档和代码注释,文档在于产品部与项目部的沟通大部分要依靠文档,在不能进行非正式沟通的情况下,文档是唯一的选择,同时,文档在需要长期维护的代码里也非常关键,尽管结对,但是我不能认为每个人都能对所有代码都很熟悉,同时,项目规模的扩大,必然要划分模块组,结对也只是限定在模块组内,即只要有部门的划分,则必然需要文档来沟通!尽管很多人相信代码是最好的文档,但是很多人也忘记了一个很重要的前提,即好的代码才是最好的文档,我更愿意相信由于种种管理因素(部门之间的隔阂、成员之间水平的差异、进度)的影响,代码必然是逐渐腐化的,所以,在代码水平做不到很好时,就必须有文档,必须有注释!
公司继续发展,项目规模越来越大,我按照模块对项目进行了划分,每个模块对应于一个开发小组,每个小组一个负责人员,他们向项目经理负责,项目经理向我负责,同时项目部门依赖于产品部门。部门之间的沟通通常情况下依赖文档,由我统一进行两个部门之间的协调。
终于,发生了一件很严重的事情,交付的项目出现了一个严重的BUG,这让我很生气,开始追究责任,最后发现BUG出现在两个开发小组之间的一个接口约定,于是文档的要求进一步严格了,同时,公司成立了独立的质量保证部,对交付的项目进行统一测试。很自然,为了激励测试部的积极性,我规定按发现BUG的数量发放测试部的奖金。
于是,我发现,项目中到处都是文档、开发人员与QA对立严重,代码质量以安全第一,不愿重构,这一切,都是我当初最反感的。我怀念起最开始的日子。于是,我开始找敏捷咨询,通过外部力量进行部分的改进。。。。
很明显,我个人所理解的全功能团队(即所有成员都在一个部门里)将变得不太可行,而必然会产生某种形式的分组,不管是正式的还是非正式的,这种分组而产生的沟通成本可以认为是管理成本的一部分。