昨天到新公司上班整101天，下午下班的时候开了一次部门会议。晚上回家思考软件开发的团队管理与过程控制，一些想法拿出来与大家分享，不妥之处，接受板砖............
作为一个软件公司或相关机构，要盈利就必须在软件开发方面提高质量，但如何提高质量，个人感觉很多公司还存在一个错误的概念----在规定的时间内做出符合客户要求的系统为标准。的确，此观点限制了很多公司与个人在技术发展的道路上走的更远，进而把团队与公司管理带入了一个死胡同。并且随着时间的推移，此逻辑会逐渐的在公司管理层面造成一种死锁的局面----高层对底层的工作表现不满意，而底层对高层的管理方式也怨声载道。
软件开发工作本身需要一个周期，而周期的内部则包含了很多因素，一个因素的不稳定在周期推移的过程中很可能会造成类似生物学领域的蝴蝶效应----非洲的一只蝴蝶扇动翅膀造成美洲大陆的一场龙卷风。而当我们发现效应存在的同时，则已为时已晚，再去控制难度会直线上升，从而形成拆东墙补西墙的恶性局面，进而提高公司业务运作、团队管理的时间、人力等各个方面的成本。
如何管理一个团队？如何提高团队的工作效率？如何保证待开发系统按部就班的度过开发周期的每个阶段？如何........很多现实的问题摆在每个开发团队成员的面前。本文就我们在开发周期内经常碰到的令人不解的一些问题就个人经验谈谈自己的看法。
基本思路如下：
1、团队的技能如何提高
2、如何提高团队的协作能力
3、团队行为的必要性
4、开发过程控制的几个重要因素
5、我们的团队是否可以应对大系统
6、如何提高系统的灵活性---即如何增强系统的可维护性、可扩展性
7、团队成员的性格特征是什么
下面就这7个问题，分别谈下自己的观点。
一、团队的技能如何提高
作为一个公司，要成立软件部门，首要的问题就是从各种渠道招募人员。在招募人员结束后，一个基本的团队的架构就形成了。但有人未必可以办成事情，人仅仅是组成团队的一个必要因素。要形成严格意义上的团队，除了有人外，还有一个必要因素就是团队中的成员必须具备一些基础技能以及公司发展需要团队成员具备的一些技能。
每个团队成员的个人经历不尽相同，对各种技能的掌握和理解广度与深度也不尽相同。所以，即使一个团队中的所有成员都具备了基本的软件开发技能，但面对公司的项目要求，临时抱佛脚的去研究学习的确可以解决时间成本上升的问题，但项目内容千差万别，客户需求千奇百怪，仅仅通过项目调研前后阶段的短时间攻克周期去克服项目需求带来的技术难题在某种程度上是对团队发展与管理的一种干扰因素。对于这种情况，个人结合自身的些许经验，总结如下几点。通过这几点，可以逐步缓解项目需求对团队技能形成的障碍，并逐步调解难点攻克与团队技能管理之间的时间、管理冲突：
1、了解每个团队成员的性格。
所谓用其人，知其性。成员是资源，不是工具。要充分地发掘资源的能量，就必须了解每个成员的性格，了解每个成员的反应力、理解力、理解问题的方式等等与掌握技能相关的一些能力因素甚至还需要了解成员的性格----好静还是好动。
或许有的人会说：有必要吗？就我的个人经验来说，答案是非常有必要。因为只有当我们了解了这些因素以后，才可能在日常团队技能管理控制的过程中充分地发挥每个人的个人能力，从而避免导致把错误的人放在错误的工作目标上，避免对未来开发造成的负面影响。
而且，但就团队管理者个人来说，通过多了解下属成员的技能掌握能力相关因素，对自身也可以起到在了解过程中去粗取精的目的，并在团队技能管理控制的过程中逐步筛选一些优秀技能，逐步扩展到整个团队中。
2、了解公司的发展定位。
任何一个软件公司都不太可能将自己的业务乏味囊括到所有的行业，势必有自己的行业针对性。所以作为公司决策方向与内部开发能力之间的协调人这样一个角色，有必要随时了解公司的软件开发行业定位。通过公司业务的行业定位，进而可以逐步获取对应行业系统开发过程中会使用到的一些技术，最后未雨绸缪。
3、在团队内部营造一种交流的氛围。
俗话说的好：三人行必有我师。任何人的能力都是有限的，即使有的人能力无限但我想其个人的精力也是有限的。如果把能力比喻作吹到气球里的空气，那么精力就是这个气球了----精力束缚着能力无限制的扩展。所以，最为一个团队，为了保障整体团队开发势力平均层面稳步提升，需要在团队内部形成一种交流的气氛。
环境造就人。有些技术点并不是开发人员掌握不了得，只不过是因为自身长期所处的环境让开发人员无法去接触这些技术，所以“不敢轻易地和陌生人说话”。而当团队中的每个成员都善于与人交流，提出自己的疑惑，说出自己的见解，相互取长补短，形成一种良性的竞争环境，对于团队中每个成员的个人技能的提升都有很大的帮助。而且在日常的定期与不定期形式的交流中，交流本身也潜移默化地让团队中的每个成员都相互磨合着----磨合着思维习惯，例如看问题的方式、解决问题的途径等等。
所以，通过上面的三个途径，作为团队管理人员，在了解了每个成员性格的基础上，自然而然的知道了什么样的成员适合做什么难度级别的开发，同时通过了解公司业务方向的行业定位，知道了团队在未来应该掌握哪些技术，再辅助逐步强化的交流氛围，在交流中对不同性格特征的成员侧重不同针对性技术的不同广度和深度探讨交流，即可以逐步提高团队整体的技能以及相关的管理水平。
二、如何提高团队的协作能力
团队中每个成员的技能提高意味着团队有了战斗的基本能力。但现在的软件开发早已告别了90年代个人英雄主义的时代，很难出现一个人写优化大师，一个写FoxMail的情况，取而代之的是协作式的开发。因为随着软件系统的规模增大，个人能力与作坊式开发已经完全抵御不了规模化开发系统对风险与后期成本的管理控制要求。所以团队成员整体技能的提高仅仅是组建有效团队的第一步，接下来的事情就是要提高团队内部成员之间的协作能力。
但如何提高团队成员之间的协作能力呢？我想任何有过团队管理经验的朋友都在自己的工作中时刻审问着自己这个问题。下面是我的一些经验：
1、交流可以契合团队成员间的协作能力。
上述已经提及，不再赘述。
2、保持团队成员的交流能力始终在一个稳定水平。
每个人有每个人的性格因素，有些团队成员本身就是不善于交流的，对于这样的团队成员，应当尽量让其明白交流的重要性----对技术团队，对个人技能发展。但面对始终不融合的情况，从管理层面和整体发展层面考虑则只能采取要不放弃、要不弱化其重要性的方式来保障团队成员交流能力的稳定水平。
有的人可能会说：这不成了只要马屁精，不要老实人的情况了吗？的确是会形成这种错误的直觉。但实际情况并非如此。作为团队的发展，人品老实和固步自封是两个完全不同的概念，前者一般会积极配合团队的交流氛围，努力朝着既定团队技能发展方向前进。而后者多是以现有技能为满足，拘泥于现状。不懂发展就意味着是对发展型团队的一个阻碍，同时此阻碍往往表现为团队内部良性竞争环境受到阻碍或遭到破坏，因为部分技能在团队内部、公司内部被私有化，造成了公司开发风险的提升。
作为一个团队的成员选择标准，我个人经验与认识是：宁愿吸收一个反应慢，技能有待提高但知道如何配合团队发展的成员，也不要去吸收一个技能高但不懂配合不懂交流的成员。顺便说一句，莫要理解成招聘人的80%原则！:)
所以，交流不单可以提高团队的整体技能，同时对团队的内部分工协作也起了至关重要的作用。作为项目管理人员或者团队管理人员，不要自恃清高，在内部管理的时候应该多以志同道合的心态去主动交流。但要分清与进度管理的区别。而作为团队成员，则更应该勇于发表自己的言论。当你通过交流发现你错误的同时，也意味着你离正确不远了。
三、团队行为的必要性
喜欢足球的朋友都知道90年代后期的巴西国家队有个叫德.尼尔森的球员，技能超群----球摆在你面前，只要他的两条腿来回的在球前晃几晃，你可能就不知道球跑哪里去了！当然说得有点夸张，但也不尽其然。提到这个世界级球星的目的不为别的，只为了说明即使巴西国家队拥有如此一个技艺超群的球员，但巴西队在世界杯的比赛中也未必就可以尝尝全胜战绩地举起大力神杯。可见，个人行为与团队性格也是两个截然不同的概念。
软件开发也是如此。一个人的能力只代表对如果存在的团队交流有了一个契机----引入新技能、了解新思想的契机。但如果没有团队交流，个人的技能的价值就会打很大的折扣甚至在团队的范围内彻底失去其作用。
所以，作为一个团队，不应该过分的强调个人的技能，因为个人技能是为团队服务的。一个健康发展的团队，首先看的是团队行为，而也只有良好的团队行为才可以应对软件公司中规模越变越大的待开发系统的开发要求。
团队行为的主要包含3个方面：
1、意识方面：团队意识高于个人意识。团队中良好的协作意识，管理意识应当被扩大化。
2、个人素质方面：团队素质高于个人素质，同理好的东西要在团队范围内扩展。
3、技术思路方面：团队中优秀的技术思路也应得到及时的普及。
四、开发过程控制的几个重要因素
一个团队在没有整体团队技能，没有整体团队协作能力以及没有整体团队行为意识之前不能算做一个真正的团队，更确切的说仅仅是一个离散的人群。当这个离散的人群具备了团队技能、协作能力以及行为意识后，这个团队才完全具备开发规模系统的能力。所以，团队管理重在尽快地让团队掌握整体技能，整体协作能力以及整体团队行为意识三个方面。团队管理的目标是要为过程控制做铺垫。一旦过程控制开始，则需要严格按照过程控制规则来进行监督与管理。下面就自身在过程控制中认识的几点体会提及一下：
1、开发过程重要的是人，而不是工具。
工具永远都是工具，工具和人最大的区别就是工具没有主动思维的能力。而现在很多的团队重视的着眼点都在工具的选择上。实际很多的团队在选择工具的时候的标准就是所谓的大流。选择要有依有据，即使“我们团队的人只会这个工具！有什么办法.....”这么简单的理由也是一个很充分的理由。所以，主流未必正确，且自己的选择要很充分，否则容易被误导，浪费不必要的时间和人力去做所谓的选择。
建模未必就一定要用ROSE，如果你只会PD，完全也可以。天下没有哪条法律规定开发必须要使用正向工程，也没有哪条法律规定模式必须在代码中体现到百分之几。所以，一切的选择在开发人员自己手中，合适的就是应该选择的。其实目前业界流行的敏捷（XP、TDD等）其核心思想都是在告诉大家合适即可，全面未必就是最好的。
原文链接：https://www.f2er.com/javaschema/287864.html