精心打造Team的组织架构

转载于http://www.blogjava.net/OneEyeWolf/archive/2007/06/03/121631.html

　　长期以来，很多Team的组合都是随意的，从创建到稳定,　不经意之间，一个Team就出世了，在项目进行当中，弊端尽现的时候，也没有人注意到是团队的组织架构，人员搭配是否出现了问题，Team成长过程，就好像一个树籽落在地下，然后自生自灭，有的长成了歪脖子，有的则树倒猢狲散，有一部分，运气好，成为能经风雨的大树。　　
　　
　　几年来，虽然敏捷管理与开发，深入一些经验丰富的PM和开发人员之心，但是在推广时，却南桔北枳，没有了味道，一些优秀的开发与设计思想或技术，如TDD、MDD，大部分只流转于个别经验丰富的开发人员之间，在团队项目开发中，不见了踪影。
　　
　　这些都非常不利于个人和团队开发经验的积累，更不利于推广。
　　
　　虽然这方面的缘由甚多，例如，在大公司，更倾向于按部就班的，流水化作业的形式，大多的领导，希望以文档驱动的方式，来进行作业。例如在Microsoft，也是个别的团队首先偷偷摸摸的搞起敏捷，然后才得以向其它团队推广，但推广的方式是思想沟通、培训多于实际运作。（见CSDN程序员２００６年杂志）。

　　连Adobe这样有名的技术主导型的公司，，也不过是在2006年开发CS３的时候，才改变以往，吃尽苦头的，BUG成堆的，瀑布式运作方式，开始转向迭代增量开发。（虽然虽然迭代，在９０年代，就已经开始了）
　　参见：Adobe edits the development cycle
http://www.regdeveloper.co.uk/2007/03/08/adobe_cs3_development/
　　当时采访Adobe photoshop团队时，一个很直接问话：
　　If it's such a good idea, why did it take so long – and how did you manage to change this time?　（如果这是一个非常不错的方法，为什么你们到现在才开始使用？你们是如何在这次项目当中，转变自己的？）
　　
　　但是更多的方面，还取决于团队中的每一个member.首当起冲的是Leader，是否有丰富的开发经验，是否有执行力，是否有Open的精神，能否坚持不懈的把敏捷这种思想，通过不同的形式，一点一点的展现或灌输给团队。

　　一个自适应的团队，首先要来自于一个自我调节的Leader，能够通过沟通、持续改进等方式，来不断的调整自己的管理方法，不断的改进开发的过程，并且能不断的改进团队的思想，使团队的成员，不断的成长。

　　Leader也需要学习，需要成长，在敏捷的团队当中，大家都是互补的，不存在junior, senior之分。所以团队的精心打造，就在于互补，很多领导寄希望于万能的Leader,　这往往是失败的开始，Team Leader往往成为进度的瓶颈，delay的主要因素，为什么？因为他只是扮演了一个救火队员的角色，到处都是失火，如何能救的过来。

　　自适应的团队，就在于人人都是主动的、自发的。问题出现的时候，不在于是你的问题，还是他的问题，而是立即解决，不是积累到失控的时候，才去解决。所以打造这样的团队，不仅仅是对Leader要求高，对于团队中的每一个人要求都高。例如对于迭代中的一个best practice，就是要求，在每一个周期的，Time-box控制的都是相当严格的，要求Leader每天，都要跟紧成员的开发状态，以求每天都有结果。如果不是一个自适应的团队，如果一个团队有几十个人，那Leader都要累死了，每个人的座位走一遍，都快要下班了。

　　有人会说，这是太理想化的东西，我想，这是一个思想层面的认识问题，一个推动力，一个唱黑脸，敢于在组织架构上动刀子的问题。

　　这几年，我经历的团队当中，往往都是开始的，两三人，不断膨胀到十人左右，但真正起作用的，不过１／３，砍掉一半，团队照样跑的转。我想一个３、４人的敏捷小分队，要胜过１０人的团队，很多PM总是在后期抱怨缺人，领导也一味的满足他们的要求，不断的在中后期加人，却不愿意在团队成立之初，去好好的考虑团队的建设问题！
　　
　　考虑一个团队的架构，很多人，自然会想到首先从技术方面想，如高级程序员，中级程序员，普通程序员，系统分析员等，一些大的公司，也会设这样的岗位，不同的岗位，Money不一样，职责不一样。这不过是一厢情愿的典型的人事设计方式，非常粗粒度的切割方式。

　　其实从技术方面，来考虑，是打造Team的一种主要的方式，但也并是说用这种无知的、分级的方式打造，这样只会损害团队的合作！

　　对于技术方面，要结合项目的特性，进行精细化的考虑，如果不知道怎么做，可以看看Microsoft的用户体验团队的组织架构。另外，也可以看看Google的开发小分队的组织架构，就像三角洲的小分队，精悍无比。一个Team　leader, 一个用户体验工程师（不仅技术好，人机交互的理念也要到位）,一个teser。

    目前的开发人员，很多都不满足不了这样的要求，很多程序员，除了会写个Java代码，其它一无所知，甚至不知道怎么去写HTML代码了，怎么可能去做一个解决问题的开发人员？我现在的项目，采用的是原型迭代的方式，项目中的几百页的静态原型，都是我一个人做的，我想交出去，没有一个人会！

    现在的三层开发，误导了技术走向，很多人以为只会一层就够了，不会SQL，不会javascript，页面也不会写.

　　其实从管理、自制和思想层面，也是另一种渠道。团队中人员要考量他的交流、沟通能力，他的思想层面，是否有团队精神，是否能够接受新技术，热爱技术。对于恶劣的磁、破坏性巨大的程序员，要敢于清除出队伍，避免毒性扩散。

　　这是不是，还是非常的理想化，也许你们还是接受不了，宁愿十几人的干活的热闹场面，不愿意５个人以内的敏捷团队？