软件工程师成长之旅----经典版

软件工程师成长之旅

从事软件开发已有些年头，其间经历了各种各样的团队，见识了不少开发的方式和现象，这些经历或给人以一些失败的教训或给人以一些成功的经验，历经数年的分析总结，逐渐对软件开发的认识有了相当的深度，平时总忙于各种锁事的处理，没什么时间来整理，现在越发感觉这些经验有必要整理出来，所以就特地根据原先写成的一些东西，把它整理成文，但愿这些教训或经验能给正从事软件开发的同行们一点启发，或是当作一个故事看看。

首先，作为软件开发的热爱者，我是肯定软件开发行业的从业价值的，至少在我看来这是一个不错的行业。但这个行业毕竟是一个重脑力劳动的行业，如果没有良好的心态和良好的学习惯在这行立足是比较困难的。我个人认为要成为一个优秀的软件开发者需要从如下几个方面考虑。

一、从事软件开发必须具备三个条件硬条件：

1.  智力不宜太差
　　我不敢说做软件不一定要有多聪明，但如果反应力不太好的，我认为从事这行是比较困难的，毕竟这是一个知识高速更新的行业，需要不停的学习。如果接受学习知识不能深入或是接受起来比较吃力是不太适合做软件开发的。

2.  要有良好的心态和学习习惯
　　一般来说，在绝大多公司做软件开发都要求有一定知识面，一个人从学校出来时所学的知识远远不够。软件开发所需的知识表现为一个特点：多熟悉或精通几个知识点是不足以体现出实力的提升，往往需要你日积月累掌握相当数量的知识点，最后才能表现出实力。所以，这就要求你必须不急不燥认真学习、实践相关的知识，当这种积累达到一定程度的时候你就会明显感觉实力有所增强，而这种实力增强的周期通常在半年到一年半，如果一个人没有相当的毅力和良好的心态，急于求成，学习的时候东一下西一下往往不能见成效，日子一久，就会逐渐丧失对知识、对技术的追求热情，最后不知不觉在竞争中被淘汰，或是处于很平常的状态。所以良好的心态和学习习惯是从事软件开发的第二个必备条件。

3. 要善于总结和分析
    软件开发所涉及的知识和方面是非常广泛的，包括行业领域知识、技术知识、为人处世等各方面的知识。软件行业的思想和门派也五花八门，我们如果见风跟风见雨跟雨，通常是行不通的，其实无论软件开发涉及多广泛的知识，但它始终跳不出一个基本出发点，那就是：它都是为了做好软件，获得经济效益。所以，在软件开发的过程中，只要我们根据具体情况，认真分析问题、积累解决问题的有效手段，一般来说在公司里生存都不会有太大的问题。这种积累越多，你就会发现良性循环的效益越大。如果不分析总结你可能会陷入失败再失败的恶性循环，即使你参与了一个成功开发的案例，往往也不知道之所以成功的原因，到哪天自己组织项目时还是感觉力不从心。对个人而言，无论是成功或失败的案例都是很宝贵的，失败的案例通常能提供给我们更多的教训，让我们在以后的软件开发中遇到类似问题时不再重蹈覆辙，甚至你从这些失败中提炼出了很有价值的问题，然后找到了很好的解决办法，间接从失败中获得了经验。成功的案例直接就给你提供了很多有益的参考。所以成功和失败是辩证的，关键是看我们如何吸收它所蕴含的财富。

二、软件开发成长的五个阶段
　　从我本人及身边朋友的成长经历来看，我认为成为一个优秀的软件开发人员，应该要经历以下五个阶段的发展层次。否则，即使能在竞争中左右逢源，处处钻空子生存下去，起码这种生存方式不是所有人都能做到的，生存起来也不会很踏实。我不否认“天生一人必有一路”的说法，但我认为既然你有意在软件开发这行做下去，就应该认认真真的去做，不要总想着拉帮结伙，去获取人际斗争的渔人之利，这对个人和这个行业都不好，甚至可以说对这个国家的软件发展都不利。我比较主张走实力之路，所以以下的观点也基于这个立足点，也就是说这些观点并不适合追求“非实力”型的人员，但参考参考也无妨。
1. 面向技术点阶段：
　　我认为一个初入这个行业的程序员，由于知识技能与见识的不足，接受一些思想是比较困难的，如果这个时候去过多的关注一些思想，到头来可能会成为一个只能夸夸其谈而无实际用处的“吹水派”，到哪里做砸哪里的项目。这个时候，通常由于资历、经验的不足在团队中难以成为核心成员，即使你能做到“思想层面”，也没有机会去实践。所以这个阶段的程序员，最好是踏踏实实把一些常用的技术点认真消化，深入理解，深入实践，为以后的发展积累良好的基础。对技术点的积累，你既要兼顾工作中的需要也要兼顾将来的发展，既不能完全被所在的环境束缚于一隅，也不能背离现实而一味追求知识面的扩张。你必须明白一个道理，只有工作相对愉快的前提下你才能有更高的学习效率，所以，首先把“工作上需要的知识”解决的情况下，才进行知识技能的扩张。
　　其次，在这个阶段的程序员，因为技能的不足，通常会认为技能是最重要的，而忽略对业务的理解。其实，做好软件“技能”与“业务”都是相当重要的，缺一不可。技术的强势有时可以降低对业务的理解要求，同样，业务的强势有时也可以降低对技术的要求，有的时候很多东西本身就很难定性它是属于“业务问题”或是“技术问题”，所以总是去争论“业务”与“技术”的优劣是比较狭隘的。虽然我深知“业务”的重要性，但我个人认为，这个阶段的程序“相对忽略”对业务的理解是可以理解的，因为这个时候的程序员面临的最大问题通常技能不足。技能不解决，即使熟悉了业务也一样做不好，而且这个阶段的程序员，我认为还达不到会花很多精力关注业务的程度，所以对这个阶段的程序员，一些经验丰富的主力程序员，或是项目Leader有认真指导其工作的义务（注意是义务而不是权力）。但现实中的很多Leader或是经验丰富的程序员往往出于个人水平的不足，无法给予相应的指导，或是由于利益关系不愿意指导，这就是现实。这个阶段的程序员要有面对这种矛盾的心理准备，尽一切办法渡过这个难关，尽量处理好“业务”与“技术”的关系，可以通过加强对业务的理解来“适当弥补”技术上的不足，或是找到其它更好的方法来处理这些问题。其实，我不是很主张这个阶段的程序把主要精力花在业务上，还有一个更重要的因素，这个因素“可能”甚至是“一定”会给公司的发展带来难以处理的“后遗症”，这对公司长远的发展来说，几乎是百害而无一益。但仅对个人的生存而言“重业务轻技术”未必不好，特别是对那些“管理不善，人员流动频繁的公司”或是“业务含金量很高的行业(如银行、保险等)”，走“业务线路”也可能迎来好的“钱途”，不过这种情况并不适合多数人。关于这个话题，我暂时就不再这里阐述了。

        另外，知识技能的积累发展，通常也有一个过程，我把这个过程归纳为“想到(理论水平)à能做到(可能水平)à做到(极限实战水平)à熟练做到(常态水平)”。对于很多常用的知识只有达到“常态水平”才有实际意义，所以在学习、实践的过程中要注意体会、总结知识的应用特性，把那些需要达到常态水平的知识提炼出来，加强理解和运用，力争达到熟练状态，甚至“幻化自如”的境界。

   这里，我想提醒大家一句：我们学习技术应站在表演者的角度去学习，而不是观众的角度去学习，表演者是需要真枪实弹上阵的，是要对后果负责的，而观众只是听听，看看，说说，当当评论家而矣，通常不需要对后果承担责任。我个人认为这种意识相当重要，它能让你对事情负责、对公司负责、对自己负责、对过去负责、对现在负责、对未来负责。我强调这种责任心，绝不是简单的“文字游戏”，而是切身体会到：多角度、多方位去想想自己的责任与前途，在进行学习的时候，就会有更加明确的指导思想，知道事情的轻重缓急，更加合理的安排学习内容和进度。

最后，关于学习方法，我想强调一点：俗话说“学海无涯”，特别是软件开发这行，也可以算得上“博大精深”，我个人认为，应该以“如何能更有效的掌握知识，就如何去做”为主要指导思想，这样才能加速知识的学习进度。比如说，对你所在的环境而言，你向别人请教，能比你自己去研究更有效，你就应该优先考虑向别人请教，而不是放不下面子，自己花大量时间研究。如果你认为看书比看电子文档更有效，你就应该投点资买本书来看，而不是吝啬几十元钱，……。如果你能认同这种“指导思想”，至少你能克服性格的上的缺陷，不是性格完全决定你的行为方式，而是主动根据需要去改变自己的行为方式，做事的时候也更能把握主次，懂得如何取舍(比如：你舍点“面子”取得的是“知识”，你舍点“钱”取得的是“更好的学习效率”……)。

2. 面向框架阶段
　　当软件技能发展到一定阶段的时候，你会发现要做好一个项目往往不是有足够的技术点就能成功的。这个时候你会发现一个东西即使做出来了，也还有质量高低之分，质量高低在维护修改时，就能明显体现出来。然后你会关注如何写代码，如何让代码结构良好工整，如果不出意外，通常你会开始进行结构研究，最后过渡到框架。在达到这个阶段后，你就已经完成了从“只管做出来”，到关注“如何做比较好”的升级。这个阶段你大致会接触设计模式、组件化编程这样一些理念，并在思想和形式上有不同程度的运用，这个时候你基本上够格成为一个团队的主力了。

3. 面向团队阶段
　　当你在技能上趋于成熟，框架上趋于成形的时候，你自然会想大家都按你的成果来展开工作，这个时候你会发现很多的矛盾和冲突。你会发现原来一个东西“自己会做”和“让别人也愿意这么做”之间有如此大的差距。如果你善于分析总结，你会发现：研究框架必须面向团队，它必须易于接受，真实的减少大家的工作量，明显示提升项目质量，对项目起到实质性的推进。否则，可能你的框架仅仅是为技术而技术，不是过于做作而显复杂，就是过于简单而没有“包容变化”的能力。这个层次往往是很多程序员的瓶颈，到最后就此为止，而处于自认为“身怀绝技”却总“怀才不遇”的尴尬境地。这种阶段的程序员在公司呆上比较长的时间后，往往会被提拔，这对公司来说是危险的，他们的技术能力通常会成为团队发展的瓶颈。之所以成为瓶颈，从根本原因来说，就是“他们的技术不具备团队特性，而他们的职位其实已经主要要求团队特性”，这样，致使他们的经验、技能无法对团队形成根本性的影响，无法满足团队建设的需要。最后只能通过一些低水平的手段，比如通过“拉帮结伙，排斥异已”、“死死捏住公司的重要资源，使公司形成对个人的绝对依赖，而不敢有所动作”，通过这样一些方法来求得生存，这对公司来说当然是极其危险的。这种人一旦成为团队的主导力量，将严重阻碍团队的进步，成为团队发展的瓶颈，对公司的近期、长远发展都将留下难以处理的历史遗留问题。通常这种人非常善于掩饰问题、推卸责任、颠倒黑白、混淆视听，对团队甚至整个公司的环境都极具破坏性的影响力，公司的领导层往往对技术团队缺乏了解，即使明知有问题，却无法把问题具体化，同时由于其制造的历史遗留问题，公司的领导也很难作出决择。目前很多公司之所以人员频繁流动，软件产品的维护成本极高，大多属于这种情况下发展起来的“乌合之众”，实在称不上什么团队。“团队”应该是能互相影响，互相提高，个人技能能比较顺利的转化为“其它成员（即团队）”的技能。这样的环境才算得上是团队。

另外，能真正证明“技能”能对“团队”形成“根本性影响”的是代码，而不是一句句空话或是一些漂亮的文档、规范之类的东西。当然这不是说文档之类的东西就是没用的，而是说只有当这些东西直接或间接的转化为代码了，才能真正说明这些东西是具有可行性，否则这种“可行性”就具有相当的不确定性，并且是难以评判其作用的。

4. 面向问题阶段
　　当你的技术在框架层面游弋一段时间后，你通常就会成一个经理、项目经理、或是技术Leader，这个时候你会发现，你手下会有很多不同特色的成员，面对项目“公说这么做，婆说那么做”争论不休。团队里人际关系也变得重要起来，对上要能交得了差，对下要能让大家认真做起来。这个时候，你不要昏了头，乱了分寸，你可以用“面向问题”的思维方式来处理这些问题。把握最本质的东西，把问题找出来，拆解问题，找最有效的手段，逐步解决问题，而不要为了运用技术或理念而争论不休，这个时候你要分析要解决的问题是不是有价值的？所倡导的技术或理念是不是能有效解决问题？一切皆从问题起，无论用什么理念或技术，它一定是有目标的，如果它的目标和我们要解决的问题不一致，也就不用争论了。所以，找到“最有效的问题，最有效的解决手段”才经得起实践的检验。这个有效性包括“我们的问题确立是否有效？技术或理念是否和我们的目标一致？我们的团队有没这种技术或理念的驾御能力？在短期利益和长期利益之间如何取得平衡？”，无论多么先进的东西，不管出于什么样的原因，只要它不能解决问题都是“废物”。“面向问题”不仅适用于软件开发，还适用于处理生活上的其它事情。其实，它有点类似于武侠书中的“见招拆招”即无招，但并不等价于不懂招。

关于“面象问题”我想再补充一点：如果已经拥有良好的“面象团队的框架”，那么“准确发现问题”远比解决问题重要。当然，这种情况并不是绝对的，有些时候“发现问题”和“解决问题”同等重要，甚至正好相反，比如：有些问题可能很明显，但我们没这方面的经验和资源来解决这些问题。不过，总的来说，我认为绝大部分时候“不能准确定位出问题”而引发的困难更多，诸如“开发人员能力不足、组织管理有问题、需求变化太大”之类的问题，以我个人经验来看，更多是问题定位不准确所致。比如说：“开发人员能力不足，究竟不足在哪里，能力不足究竟会对事物的什么方面产生什么具体的影响？组织管理有问题，究竟哪里’组’得有问题，哪里’织’得有问题，这么’组’这么’织’，究竟会具体影响到事物什么方面？对需求变化太快，也是一样的道理”。我认为，如果问题没找准，解决问题就是空话。

5. 面向过程控制

“面向过程控制”主要是分析事物发展的过程，总结事物的发展规律，并将这种规律团队化，然后又在团队的运用中，不停的发现问题、解决问题、逐步完善。从而达到“吸百家之精化，众人之睿智，数年之经验”最终凝结成一套“有形、有意”的沉淀，并成为团队的财富，甚至社会的财富。这个层次可以说是前面几个层次的扩展，对前面所积累的能力、方法、知识的综合运用。

如果说“面向问题”主要是在“面向团队所形成的积累（即框架）”的基础上见招拆招，针对管理过程中的“问题点”进行“点层面”上的补充和完善，那么“面向过程”则是对事物发展过程中所产生的问题进行更全面的分析，研究更全面、更具有普遍意义的解决问题的体系结构，而不是“点层面”的问题。要达到真正的“面向过程控制”，以我个人的经验来看，至少需要具备几个条件：

n  丰富的实践经验

要真正分析出事物的发展过程，总结出规律，如果不是“身经百战”仅从书本上学点东西，我想是很难真正分析得出有益的“过程”的。倘若一本书或几本书，就能让你分析出真正实用的过程，那我得想想技术的含金量问题，是不是到改行的时候了。这里我强调实践的重要性，但并不是说书上写的是错误的。其实，以我这些年的经验来看，很多书上写的，特别是大师级的书都是正确的。但是这些东西，如果没有“非常丰富的实践经验”通常你很难真正理解它的正确性，更不用说合理运用了。

n  成熟的思维模式

以我个人经验来看，要达到“过程控制”这样一个层次，不是单纯总结、分析、实践就能完成的。在潜识里还存在着很多东西都对你能否达到这样一个层次有所影响，只是程度不同而矣，比如：

一个人的品行：你是务实之人，还是附势之徒？

一个人的胆识：你是敢有见解之人，还是猥缩之流？

一个人的魄力：你是敢作敢为之人，还是躲避责任的奸滑小人？

……

我感觉这些“人性”可以不同程度决定你：求知热情、改过胸怀、执着毅力等一系列与技术成就密切相关的因素。我不是分析人性学的专家，但我能比较肯定的说，它们之间还是存在着某种因果联系。

不过，有一些东西还是比较明确的，比如：一个人看问题能否很自然的切换观察角度（多方位观察）、是否有灵感发现问题的突破点等等。这些只是个人体验，我也就不过多分析，以免偏了主题。我能比较明确告诉大家的是：你应该养成一个习惯，多总结做事的方法，并使之达到“常态水平”，当你做事的时候，往“哪儿一站”，你就不由自主全面、综合的运用着很多经验（特别强调不是刻意），也就是“习惯成自然”的意思。很多好的方法、经验达到“习惯成自然”运用的时候，我认为你就具有了“成熟的思维模式”。当然要“习惯成自然”肯定先是从“刻意”开始。

n  强劲的技术实力

　　我已经说过：软件是“思想”的一种表达形式，并且最终是以代码（计算机语言）的形式来表达。这也是所有表达形式中，无可争议的“最难、最详细”的表达形式。涉及的知识之广、之多、层次之繁，如果没有相当“强劲的技术实力”以及“研究能力”来“准确、高质、恰当”的表达自己的“思想”，我想任何“思想”都可能是纸上谈兵。所以“强劲的技术实力和研究能力”，也就意味的“强劲、实用”的表达能力，也就意味着“高效的执行力”。

n  有益的技术价值观

　  最后，我想强调一点，如果你不认同技术的价值或是看轻技术的价值对团队来说可能是相当有害的。坦白地说，我相信一个不懂技术的人“通过借他人之力”是可能管好技术团队的，但我绝对不相信一个贬低、藐视技术价值的人能管理好技术团队。中国有句俗话“知已知彼，百战胜”，如果“贬低、藐视”技术，我们怎么能有那份兴趣、那份责任感去了解“技术人员的特点”？如果我们不了解技术人员的特点，我们又凭什么，拿什么去“百战百胜”？我个人觉得：管理的重点应该是“理清事、管好事、用好人”，是“决策力”，而不只是“监督力”，绝对不只是看别人做事这么简单!  如果你没有“决策能力”但身居相应的管理职位，你也确实主要行使监督职责，我真的可以理解你，但如果你理所当然地认为管理的主要职能就是“监督”，就是看别人做事然后“指手划脚”这么简单，我认为这很现实，但很荒唐。这就象当“二奶”很现实，如果冠冕堂皇的话，那就很荒唐。的确，在现在的中国，单纯的技术不能帮你赚到很多的钱，这是个事实，但我依然热爱它。我热爱技术，完全不代表我不理解其它的不同想法，甚至可以说我非常理解。所以，我不会因为自己喜欢技术或是技术比较别人好一点就看不起别人，看不起那些对技术不以为然的人，当然“道不同不相为谋”，我也没必要一定要说服别人认可技术，事实会最终给出一个公平的结论。“万物有异，容之则同，事无完美，容之则美”，这就象我不认同“监督型上司”，但我理解他们、包容他们，最后我们还是能在一起共事，甚至愉快的共事。这里我以一句有点文诌诌的话来结束此节，“天地苍苍，人渺渺，尔心虽大勿自傲，海纳百川乃为容，胸怀淡然人自高”。

6. 小结
　　本人现在只是致力于开发研究，也不太想脱离技术团队，所以纯商业层面和纯人际层面的东西就不再谈了。其实上面的很多思想和方法，不仅适用软件开发技术团队的管理，对其它方面的管理都是有用的，甚至对其它行业的团队管理都有相当的参考价值。并且从上面的第三个层次开始，就应该形成：

n  一个可执行的框架（即以代码来表意的框架）

我已经无数次强调过“人的意图(或思想)在软件这行，最终都会以代码的形式来表达”。如果“仅”有一些文档，我们尚无法严格证明其“可行性、正确性”，“执行力”比较差的可能性非常大。根据经验，基本可以这样下一个定律：“越接近代码的表达方式（如果正确、合理的话），它的执行力越高，越远离代码的表达方式，它执行的难度越高，出问题的可能性越大，执行力也就越差”。比如“正确的伪代码”通常比“正确的其它类型文档”执行效率高，“正确的算法流程图”通常比“正确的说明性文字”执行效率高，……，因为前者都比后者更接近代码。这里，我并不是要排斥文档，我只是想说明，不能因为“文档表意”的“重要性”，而否定“代码表意”的“更重要性”。一些宏观结构用文档表达肯定更好，它有利于我们理解系统，但基本不代表任何执行力。说到“执行力”我有必要提到“敏捷开发”这种思想体系，“敏捷开发”并非排斥文档，只是它特别强调“设计”的重要性，更多的时候是以“代码、伪代码、类图、交流”的方式来表达设计的意图，就被很多一知半解的人误传为“敏捷开发”是不需要文档的。其实，无论是代码还是文档，都是表达出我们对业务的理解，如果业务逻辑没有理清之前，就开始“拼代码”，这样表达出来的逻辑存在着比“文档”表达更高的晦涩性、更大的风险。所以我完全否定“代码表达可以替代一切表达形式”。

通过上面的分析，我们可以看出一个“良好的可执行框架”的重要性，一个“良好的可执行框架”至少应具有以下几个特征：

Ø 面向团队的，基于“使用者”的感受来研究（第三层应该达到的）。

Ø 以“面向问题的思维模式”作为重要的补充思想（第四层应该达到的）使其在针对特殊问题上更加完善。

Ø 涵盖常用的“技术点”，涵盖“常用的过程”使其更加体系化。这样可使团队的“代码表达技能”有一个中心，并可在这个中心的基础上不停的积累完善，从而使“常用技术点及思想”的积累形成一个“可持续的体系结构”。而这个“可持续的体系结构”是以“过程”为中心来建立的，溶“意、形”于一体。当然，这只是解决“常用问题”的一种方法，但并不是解决“所有问题”的方法(第五层要做到的)。

另外，我还想补充说明一下关于执行力的问题。“事物需要经历什么样的状态，最终达到我们想要的结果”与“用什么样的资源，经历怎样的过程，来完成这个目标”并不是一回事，只能说它们有比较密切的关系，前者强调“目标与结果(做什么)”，后者强调“执行过程(怎么做)”，它们本质上都是围绕同一件事物来展开。在软件这行“任务”要执行得好，我们每做一步工作必须让它接近“可转化为代码的程度”。至于我们把它划分到“决策部分”来完成，还是划分到“执行部分”来完成？由“管理者”来完成，还是由“程序员”来完成？每个部分完成到什么程度？这完全是由人来决定的，所以不要偷换概念，找诸如“决策人（管理者）不可能干到这么细……”一类的理由来否定“代码表达”的重要性。我可以非常坚决、肯定的告诉你：“要完成软件必须干到这么细! 至于，怎样协作来达到这个目标是另外一个话题!”。我从来没有定义过“要达到转化为代码的程度”应该由谁来完成，我只说过，要保证执行力，决策部分完成的工作应该向完成“代码表达”这个方向靠拢。这个结论的正确性就在于“软件最终一定是以代码的形式来表达”。我想，通过这些阐述，我们基本可以这样来衡量一个团队成员的工作效果“当一个团队成员为一个任务做了一系列工作后，这个任务离完成代码还剩多少工作量？”，如果剩余的工作量还很大很大，那么这个成员所承担的工作量是否合适，对“任务”的完成起了多大作用就得好好权衡一下了。其实，一个真正的可执行框架，就是用代码来表达的“开发过程”，所以它的执行力是无庸置疑的。

n  一个合适的培训体系

一个良好的经验积累（不管以代码来表达，还是以文档来表达，或是两者皆有）通常都是某个经验丰富的人吸收百家之长而创造出来，然后经历若干人的共同努力使之完善，它所包含的知识范围和经验值一般来说都有一定的复杂性和广泛性。所以，如果没相当有效的培训手法，要想真正为团队所接受，特别是新人接受，我想是非常困难的。无论出于什么原因，至少，这是目前绝大部分团队没有去做的。

n          一个自觉的跟踪指导体系

　“积累经验”的推广、执行，在“培训”之后，通常也不足以保证其执行力，要真正让它执行起来，还必须有“跟踪指导”。软件开发这行有个特点“很多事看起来好象很简单，其实做起来相当复杂，至少绝大部分事都不象它看起来那么简单”。“培训”最多能保证大家都理解了这些“积累经验”，但不一定能执行起来，通常执行的过程中都会出现一些问题。所以“跟踪指导”是相当重要的。只要经常做，当达到“常态化水平”的时候就没什么工作量了。所以不要对“跟踪指导”不以为然，以免在你做了95%努力之后，因为这5%没做而“功亏一篑”。

n          正确的指导思想

   这里，我再对“团队管理”作一个补充。以这些年耳闻目睹或是亲历的经验来看，我个人认为，要真正管理好一个团队，还必须在思想上发生根本性的转变，“团队管理”应该“以事为中心，以人为本”。之所以要以事为中心，是因为我们的一切“目标价值”都会通过“做事”来实现。如果对“目标(事)”本身认识不清楚，就安排人来做，只能是瞎做，所以“用人”应该围绕“事”这个中心来展开。同时，事情最终是由人来完成，“以人为本”才能团结人、用好人，从而做好事。这样才能在“做事”和“用人”之间取得默契与平衡。很多中下层管理人员就是因为不明白这个道理，经常出现以下两种令人困惑的现象：

Ø  一关注人就把事给忘了。有意无意中淡化了对事物本身的关注。更有甚者，美其名曰：任务下放，让自己有精力来做管理(空管理)，甚至吹虚成“高瞻远瞩”的在为公司培养人才，然后一味要大家讲团结(空洞的团结，忘记了自已该干什么的团结)，把一个团队搞得人际关系复杂，人人都在讲怎么做人、怎么合作、怎么服从，弱化甚至是完全忘了自己要做什么。

Ø  一关注事就把人给忘了。忘记了个人力量的渺小，处处自以为是，这个不行那个不行就自己行，最后失去团队的支持，把团队搞得支离破碎，失去凝聚力，有能力做事的人也懒得做事了，让人推一下动一下。

这两种现象都是能力不足的一种表现。前者能力不足，最后变着法子把事推给别人，来建立自己所谓的“管理体系”。后者能力不足不是表现在个人“独立做事的能力”上，而是缺乏“带队能力”，只知道自己闷头干事，并且很是自以为是。

最后，我想提醒大家一点，能做到上面讲的第三层，就已经能够胜任一些团队管理的工作，如果达不到第三层而实际从事团队管理工作，我想是很难把团队管好的。不过，即使达到上面所说的第五层，也只能说管理好团队的可能性非常大，并不代表你就一定能管理好团队，甚至可以说有些情况单纯用“经验、积累、方法、沟通、交流”这样的话题，很难完得出一个“放之四海而皆有效的管理模式及具体方案”。比如说即使达到第五层，遇到以下情形的团队要想建设好也是有相当难度的。

Ø 对带有严重“历史遗留问题”的团队。

Ø 领导水平有限难以识别倡导者水平，信任不够，不敢执行或是支持不够。

Ø  团队文化基本上是以“管人为主”，而不是以“管事为主”的文化。勾心斗角现象严重，并且在氛围上已经自以为是，认为自己的东西已经最好，问题已经很严重，还是不敢改革的，基本排斥外来经验的。

Ø  过分追求短期利益，完全忽视中长期利益。

……

诸如有这些现象的团队要想真正建设起来，需要耐心、需要时间、还需要找准时机才能完成，有的甚至永远也不可能完成。这些现象后面隐藏着很多复杂问题，远非一般人所能理解、把握，我也不想对这些现象再展开讨论。甚至可以说，国内的很多公司都不同程度存在上述问题。所以说，软件开发是一个博大精深的领域，要做好软件成为一个优秀的软件开发者，绝非一朝一夕的事，需要大家不停的学习、实践、探索。关于以上的每点，都可以展开论述，提供更详细的实例说明。但限于时间有限，只能忙里偷闲随便说说，如有机会再与同行分享其它体会。

附注：本人曾是教师，有七年教书经历，从事专业软件开发已近八年，之前也很喜欢编程，喜欢分析问题，积累经验，并擅长授人之术，我想要真正达到第五层，对一个不是经常与人交流和喜欢授人以法的人来说，真的很难，但是我做到了。或许有人会说，这样建立起来的体系会不会对个人依赖过强？我可以明确告诉你“不会”，如果对个人依赖强，只能属于第二层。第三层“团队化”就是要解决这个问题，否则就不叫“面象团队”。关于我以上的观点，我认为只是解决团队建设问题的一种比较有效的方法，既不万能的也不是唯一的。这些观点方法也不能解决“团队建设或项目管理”的所有问题，如果它能解决所有问题的话，或许我应该去开公司。可能你很难在现实中找到一个合适的人来达到我所说的第五层，并改善你的团队。但我可以告诉你真的能做到，第五层不仅代表的是“团队或个人经验的结晶”，更代表了一个人甚至一个团队的技术研究能力、推广能力和管理能力。我衷心的祝愿所有热爱技术，并把技术当作一种事业来追求的朋友能从中受益，并希望那些有心搞好团队建设的团体或个人把你们的经验完整的分享出来，大家共同提高。