这篇博文本应在我离开非微软部门之前完成的，以作为之前两年国内项目经验的一个总结。无奈写字这种伤神费脑的活儿最看心情，拖拉到现在，直至最近在看《程序员的思维修炼-开发认知潜能的九堂课》略有所感，才又有闲情码字。
德雷福斯模型针对技能，把人分为5个阶段：新手，高级新手，胜任者，精通者和专家。
新手――在该技能领域经验很少或者根本没有经验；他们需要指令清单
高级新手――他们可以独自尝试任务，但仍难以解决问题。高级新手能够根据过去的经验，逐步在正确的情境中采纳建议，但比较吃力。他们没有全面的理解，而且的确不想有
胜任者――这一水平的人通常被认为“有主动性”和“足智多谋”。他们是团队里的好人，既可以指导新手，也不会经常骚扰专家。他们可以独立解决自己遇到的问题，并开始考虑如何解决新的问题――那些他们之前没有遇到过的问题。他们寻求和运用专家的意见，并有效利用
精通者――需要全局思维，他们将围绕这个技术，寻找并想了解更大的概念框架。他们能够纠正以往不好的工作表现，会反思以前是如何做的，并修改其做法，期望下一次表现得更好。到这个阶段，自我改进才会出现。
专家――是各个领域知识和信息的主要来源。他们凭直觉工作，而不需要理由。也许不是有意识的，专家知道哪些是无关紧要的细节，哪些是非常重要的细节。
以上内容是在书中摘录的，这确实是本好书，它还特别对模型在软件开发领域的应用做了仔细的分析。
两年前我所接触的国内项目，都是百万以下的小项目，人员规模差不多都在20人以下，真正的技术人员（开发+测试）有时不到10人。各个项目情况的不同，测试人员配备上更多地看客户对质量的需求。抛开项目不谈，单单看部门25人的测试团队；除了老大Jeff在某些方面能称上精通者/专家，其余的68%是新手，12%是高级新手，16%是胜任者。老实说，这是很糟糕的情况，也正是我选择离开的原因。这说明大部分人都没有能力独自解决问题，而我们的组内培训也经常是SQL Server基本操作，LoadRunner安装这类简单得让人沮丧的主题。
管理一个新手/高级新手的测试团队，最重要的不是技术共享，而是要锻炼他们独自解决问题的能力。简而言之，不是“术”，而是“道”。这一点，我两年前并没有意识到，我跟着老大花了很大精力在组内培训上，我们甚至借鉴公司的培训部，还找其他部门的老大取经，希望大家能够多掌握一些测试技能，熟练使用某些语言/工具。但知识和智慧真的是两码事。当然，培训是有必要的，知识的增长让部分人获益匪浅（还有一些人会对某些知识不加理会，因为他们当前的工作中并不会用到），然而他们并没有上升一个层次，他们的思维观念没有改变，他们在大部分时候仍然是问题的旁观者，而没有涉及到解决问题的一部分。
我可以理解外包公司在组建测试人员时大量选择新手，因为测试相对开发而言，确实是门槛较低的工作。有些管理者期望项目团队中资深的开发人员可以为测试新手提供建议和帮助，令测试新手成长。我明白招到资深的测试人员也不容易，但项目管理和测试团队的管理本来就应是两条线；项目进行过程中，开发人员的任务往往比测试新手繁重，开发很少有时间对新手进行测试方面的指导，即便开发人员有时间，很有可能他只是开发老手，在测试方面也只是个新手，不懂得如何设计测试用例，如何安排测试环境/流程，进行测试数据的管理...所以让资深开发者去指导测试新手，这个想法让我讨厌。
我觉得自己和两年前一样，在团队建设和管理上做得并不好。没有主人翁意识是最大的心理障碍。而领导们或许更多的是考虑项目管理，而不是团队管理。对于项目来说，人是资源，跟主机服务器一样，是另一个可利用的资源。对这批人的关注，仅限于这个项目的有效期内，一旦项目解散，很可能负担不了这样的人力成本。在这样的大环境下去管理团队，我想，只能尽量不让自己和大家受委屈：不在钱上受委屈，拿到应得的报酬；不在心理上受委屈，有发泄渠道，不憋在心里怄气。而这两点上的问题，只有在适时进行1:1聊天时才能发觉。
或许可以参考《编程匠艺-编写卓越的代码》对工匠的培养去锻炼团队成员的思考和学习能力。管理这门学问，很需要创造力和直觉，我想我还有很长的路要走。
