精心打造Team的组织架构

精心打造Team的组织架构

　　长期以来，很多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都要累死了，每个人的座位走一遍，都快要下班了。

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

　　这几年，我经历的团队当中，往往都是开始的，两三人，不断膨胀到十人左右，但真正起作用的，不过１／３，砍掉一半，团队照样跑的转。

　　一个技术经验丰富的、Open的开发人员，胜过一堆猪脑子的程序员。领导们算账，算过了头，只愿意雇佣大批量的，低成本的开发人员，不愿意在团队结构上，精心考虑。

　　我想一个３、４人的敏捷小分队，要胜过１０人的团队，很多PM总是在后期抱怨缺人，领导也一味的满足他们的要求，不断的在中后期加人，却不愿意在团队成立之初，去好好的考虑团队的建设问题！
　　

　　考虑一个团队的架构，很多人，自然会想到首先从技术方面想，如高级程序员，中级程序员，普通程序员，系统分析员等，一些大的公司，也会设这样的岗位，不同的岗位，Money不一样，职责不一样。这不过是一厢情愿的典型的人事设计方式，非常粗粒度的切割方式。

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

　　对于技术方面，要结合项目的特性，进行精细化的考虑，如果不知道怎么做，可以看看Microsoft的用户体验团队的组织架构：

　　
　　另外，也可以看看我最欣赏和羡慕的Google的开发小分队的组织架构，就像三角洲的小分队，精悍无比。
　　一个Team　leader, 一个用户体验工程师（不仅技术好，人机交互的理念也要到位）,一个teser.

    目前的开发人员，很多都不满足不了这样的要求，很多程序员，除了会写个Java代码，其它一无所知，甚至不知道怎么去写HTML代码了，怎么可能去做一个解决问题的开发人员？我现在的项目，采用的是原型迭代的方式，项目中的几百页的静态原型，都是我一个人做的，我想交出去，没有一个人会！
    现在的三层开发，误导了技术走向，很多人以为只会一层就够了，不会SQL，不会javascript，页面也不会写，要汝何用！

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

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

　　也许可以学习一下国外公司的做法，如Microsoft、Google，招聪明的，不招呆滞的，遇到问题，连GOOGLE都不会去查一下的人。

评论

57 楼 tcmak 2007-07-17  

gigix 写道

引用

细化讨论微软的开发team结构。
细化讨论google的开发team结构。

我就不知道为什么还有人对微软和google的开发方式感兴趣
微软的项目就算90%失败，他们照样会赚钱
google的项目就算99%失败，他们照样会赚钱
你的公司能吗？
动不动就要学微软、学google，人家有钱你学得来吗？

這取決於你覺得什麼才是成功和失敗, 在 "Project Management" 之上, 還有一個叫 "Project Portfolio Management" 的問題, 這樣是人家成功之處.

56 楼 OneEyeWolf 2007-07-17  

   照搬照抄，不可行，但有一些东西，不是用钱能够得到的，就是方法和思路。有一些东西，不用花很多钱，也可以做到。
   很多的电子商务网站中，缺少有一个角色：那就是用户体验。很多的decorate的功能都是领导的心血来潮和技术团队的别出心裁。
  

55 楼 firebody 2007-07-16  

gigix 写道

引用

细化讨论微软的开发team结构。
细化讨论google的开发team结构。

我就不知道为什么还有人对微软和google的开发方式感兴趣
微软的项目就算90%失败，他们照样会赚钱
google的项目就算99%失败，他们照样会赚钱
你的公司能吗？
动不动就要学微软、学google，人家有钱你学得来吗？

最关键还是人家 google,ms 的开发人才99%属 于顶尖人才，这样的人才队伍没有任何技术公司可以比拟的，人家采用的开发方式自然也不适合别的公司了。

54 楼 gigix 2007-07-16  

引用

细化讨论微软的开发team结构。
细化讨论google的开发team结构。

我就不知道为什么还有人对微软和google的开发方式感兴趣
微软的项目就算90%失败，他们照样会赚钱
google的项目就算99%失败，他们照样会赚钱
你的公司能吗？
动不动就要学微软、学google，人家有钱你学得来吗？

53 楼 grave 2007-07-16  

太搞笑了..一个团队怎么可能每个人专门一做一个技术..这个居然还被认为是最好的团队,这些人的工作分布在开发的各个阶段.专门扔在一个团队不是浪费资源是什么,大家都专门搞自己的那部分，那衔接谁来做，又要万精油的team leader?
dba , 美工, 需求分析这些人在项目里顶多算part time, 在某阶段参与而已。
一看sg552就是没啥经验的. 而且software quality 靠人来做保证还不如严格的测试,一个会对自己的code做的unit test的小白程序员都可以保证质量.

52 楼 kabbesy 2007-07-13  

<br/>
<strong>OneEyeWolf 写道：</strong><br/>
<p class='quote_div'>一个自适应的团队，首先要来自于一个自我调节的Leader，能够通过沟通、持续改进等方式，来不断的调整自己的管理方法，不断的改进开发的过程，并且能不断的改进团队的思想，使团队的成员，不断的成长。<br/>
<br/>
<br/>
<br/>
</p>
<div>很赞这句话。</div>
<div>期待几个问题：</div>
<div>图看不到。</div>
<div>细化讨论微软的开发team结构。</div>
<div>细化讨论google的开发team结构。</div>
<div>TDD team人员组成及相关职能，能以一个crud类项目为例讨论最好了<br/>
</div>

51 楼 tcmak 2007-06-27  

客戶花的錢會有多少花在這些文檔上? 這些文檔, 相對於一個實際能用的系統, 又有多少價值呢?

可能他們公司花在做文件的時間比做程式的時間還多, 哈.

我不反對做文件, 但最重要是他們的 "必要性", 而且是客戶明白和願意投資的必要性.

表面上這開發過程不太 "精簡" (Lean)..... 也許是受各種限制之下已經是最 "精簡" 的安排

最後, 回應原文最後的地方, 任何開發方式和組織架構都不能取締 "人才" 的重要, 無論多 "敏捷" 都好, 盡可能之下都要招個聰明的.

realreal2000 写道

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

日本企业差不多都是这样，项目设计书详细到变量的命名。

感觉项目组中其他的都不需要，但是遇到页面美化的时候一定需要一个美工，

50 楼 realreal2000 2007-06-26  

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

日本企业差不多都是这样，项目设计书详细到变量的命名。

感觉项目组中其他的都不需要，但是遇到页面美化的时候一定需要一个美工，

49 楼 抛出异常的爱 2007-06-20  

汗。。。
二到三年。。。
你说的哪样东西一年能学的像个样子？
dom ?一直不会
css ?二年全职美工估计应该算是会了
js  ?我用了三年今年才看完第一遍犀牛。。。不懂的地方很多
xml ?一年之内如果能学完那本一千五百多页的书。。。。
就连java都不是二三年能学的会的。。。
只能说够 用的知识。。。二三年内多学一点吧

48 楼 louiszheng 2007-06-20  

WEB开发需要基础知识，而如今很多工作2，3年的中级工程师都不懂，例如dom,css,js,xml,正则等，只会所谓的java

47 楼 littcai 2007-06-20  

不会SQL，不会javascript，页面也不会写


太同意了,

46 楼 抛出异常的爱 2007-06-19  

daquan198163 写道

抛出异常的爱 写道

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

写设计的是日本人，写程序的是中国人。。。。

如果文档错了呢

去与日方进行交流
用四个工作日等待结果。

45 楼 daquan198163 2007-06-19  

抛出异常的爱 写道

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

写设计的是日本人，写程序的是中国人。。。。

如果文档错了呢

44 楼 小天蝎 2007-06-19  

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

这个太强了，看来以后要多注意自我在这方面的修炼了

43 楼 抛出异常的爱 2007-06-17  

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

写设计的是日本人，写程序的是中国人。。。。

42 楼 jack 2007-06-16  

开发团队宜小不宜大。这点和项目规模没有多大关系。就算是再大的项目还得差分。

随着团队的增大，交流成本增加会越来越大，最后就会研发会议不断。然后项目就难以进行。

41 楼 basicbest 2007-06-16  

pufan 写道

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

因为还要调试，其实调试的时间可能比写代码要多。
另外一个，就是责任，如果出了问题，就可以说是程序员代码问题，而不是设计问题。介个，，，只是在某些公司有这个因素，呵呵。。。
其他还有很多原因。。。

40 楼 pufan 2007-06-15  

抛出异常的爱 写道

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。

39 楼 抛出异常的爱 2007-06-14  

basicbest 写道

如果是所有成员在项目中都是从头至尾全职的，而且工期很赶，像抛出异常的爱所说的团队我认为是合理的。但是其风险较大，假设，这四个人某日有一个在上班的路上被车撞死，或者下班回家的时候被天上掉下的花盆砸死，又或者喝水的时候不小心呛死，那么这个项目的结果会是怎样的？？？做过项目管理的应该知道人力异动其实是很大的风险。
如果是一个相对大些的公司或者组织，有专业的分工，效率可能会更高，因为他们都是同时跑几个项目，比如界面设计这件工作，想必同一个项目里面不用总是去画界面吧？那么就让界面设计师们同时负责几个项目，充分利用人力。
所以，还是要看具体情况，单纯讨论分工模式而忽略当时的环境是没太大意义的罢。

嗯，突然想到风水这个词。。。。。。

PS:风水：这就是为什么我会算命的原因。。。

引用

但是其风险较大。。。。。。。

汗。。。如果连老板一块砸死不就更好。。。

引用

相对大些的公司或者组织：

一家对日外包公司，有两百多人在作同一个项目的一小部分，
已经作了至少四年了，还没有作完。
我记忆最深的是到年底时我要求要进工具组，
我的组长。。不知道为什么：升了我的职，但没让我去工具组。。。
我当时年青，合同到期后就走人了。

引用

没有文挡怎么能行啊

那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

38 楼 basicbest 2007-06-14  

如果是所有成员在项目中都是从头至尾全职的，而且工期很赶，像抛出异常的爱所说的团队我认为是合理的。但是其风险较大，假设，这四个人某日有一个在上班的路上被车撞死，或者下班回家的时候被天上掉下的花盆砸死，又或者喝水的时候不小心呛死，那么这个项目的结果会是怎样的？？？做过项目管理的应该知道人力异动其实是很大的风险。
如果是一个相对大些的公司或者组织，有专业的分工，效率可能会更高，因为他们都是同时跑几个项目，比如界面设计这件工作，想必同一个项目里面不用总是去画界面吧？那么就让界面设计师们同时负责几个项目，充分利用人力。
所以，还是要看具体情况，单纯讨论分工模式而忽略当时的环境是没太大意义的罢。

嗯，突然想到风水这个词。。。。。。