按照标准的流程，一个产品的开发(对象或目标)需要一个总揽全局的产品经理，下面需要一个设计组，一个开发组和一个测试组。
产品经理
|—-——————————|——————--———|
| | |
设计组长 开发组长 测试组长
|————|————| |—————|—————| |—————|—————|
设计员 设计员 设计员 程序员 程序员 程序员 测试员 测试员 测试员
当然，在我们很多企业中不是这样组织的，我们更多的是由技术高深的开发人员出任产品(或说对象和目标)的负责人，由他负责设计和构架，并领导和管理开发人员和测试人员负责项目的实现。(这里说的产品和项目指真正产品的一个独立部分或一个功能模块)
这么一来，如果设计有瑕疵，开发人员就是发现了或有一些这方面的想法也不敢贸然提出。因为，设计人员既在技术上是资深的“专家”，更重要的是：在行政上还是顶头上司——可以影响和控制自己的薪水、升迁以及其他的东西。那么，设计人员处于一种不受‘监视’和制约的状态下，如果他又刚愎自用，那么，在他自己的潜意识影响下他的设计就会变成一种他的自我表演而忽略 客户的存在，就是他的脑子里有客户，他脑子里的客户也是‘他按自 己的思维方式想象的客户’而不是真正的客户。结果做出来的东西客户 总是不满意!另一方面，由于他在技术上和行政上都具有绝对的权威和制约部下的权力，那么，开发人员不但不会凭着自己的良心和知识来检查他的设计，反而以无条件满足他的设计为最高标准。而测试人员最多针对开发人员的代码提出一点意见，如果设计本身有问题，他们是无能为力的。很何况在我们的氛围内测试人员无论在技术和资力上都比开发人员要弱。如果开发有问题，开发者也不一定愿意承认，反而会以一种‘技术的权威’反咬测试本身是否有问题。因为在我们的文化中，一个技术和资力高的人是很能接受一个技术和资格比他低的人指出他的错误的，因为，在潜意识下他会认为别人在置疑他的技术和才能。而且，在有的时候就是将错就错也要维护自己的这种权威形象。
另一个问题就是沟通的问题，一个团队必须是象‘图’而不是象‘树’那样，才能充分的协调沟通。如果一个团队内大家都按照自己想象的方式去做事或者靠揣测队友的心思和意图去做事，那么这个事情迟早会做的不成样子并且大家互相指责。沟通是个细微的活，并不是就某件大事进行表决，更多的是就一些细节进行具体的磋商和协调。那么，一方面，需要沟通双方有足够的时间和精力;另一方面，沟通双方需要有“共同语言”——都关注同一具体问题，而不是泛泛而谈——毕竟，在工作的团队中沟通协调是为了发现、总结和解决问题而不是为了增进感情之类的东西。
孔子有句老话，大意是：天下因一言而得，一言而丧。突出了个人在集体里的价值和意义。一个成熟的团队，这样的人越少越好，最好是绝迹!常听人说：“我们公司如果没有我不行!…….”如果真是如此的话，他们公司还真的是不行——抗风险能力太差了!
对于组织软件开发团队，我的看法就想上面的示意图：由一名产品经理总揽全局并负责行政事物，直接对客户负责。下面的设计、开发和测试三个小组“三权分立”——平级监督互不领导并直接对产品负责。产品经理就好比司令部——提出战略构想，最后做出决策并直接对战争负责;设计小组就象参谋部——对司令的战略构想进行具体战术设计;开发小组是前敌指挥部，负责直接的战斗实施，并根据实际的情况对参谋部的作战计划提出修改意见;测试小组类似于后勤部——通过对后勤保障的测试为指挥部的作战命令提出修改意见保障作战胜利。三者负责各自的部门并直接对司令部负责。
考核后勤部的是后勤部的后勤保障能力，那么，从自身的利益出发，