如何建设更加全面的团队
<div align="left"><span style="FONT-FAMILY: 微软雅黑"><strong>简介 </strong></span></div><div align="left"><span style="FONT-FAMILY: 微软雅黑"> 团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么作，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景?测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。</span></div>
<h2 align="left"><span style="FONT-FAMILY: 微软雅黑"> 亚当与大头针工厂</span></h2>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处：提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度，提升效率，并由此提升企业的盈利能力。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 然而市场的不断变化让重复生产的美梦不在，切换任务变得越来越频繁。IT公司不是大头针工厂，知识工作者毕竟有别于体力劳动者，在劳动主体发生变化的过程中有两件事情的差异被放大了：一是局部优化与整体优化的差异，二是正确的做事与做正确的事情的差异。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 有一道数学题，假设每个开发人员每天可以完成一个功能，测试人员每天可以测试2个功能，团队由3名开发人员和1名测试人员组成，那么一周内通过测试的功能最多为多少个？</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 大多数人的第一反应是5（天）x2（功能/天）=10功能，下面的表格会告诉你，由于负载不均衡，测试人员在周一没有功能可测，团队其实无法在一周内交付10个功能。</span></div>
<div align="left">
<table style="WIDTH: 654px; HEIGHT: 115px" border="1" cellspacing="0" cellpadding="2">
<tbody>
<tr>
<td valign="top" width="84"><span style="FONT-FAMILY: 微软雅黑"> </span></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">周一</span></div></td>
<td valign="top" width="51">
<div><span style="FONT-FAMILY: 微软雅黑">周二</span></div></td>
<td valign="top" width="56">
<div><span style="FONT-FAMILY: 微软雅黑">周三</span></div></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">周四</span></div></td>
<td valign="top" width="59">
<div><span style="FONT-FAMILY: 微软雅黑">周五</span></div></td>
<td valign="top" width="79">
<div><span style="FONT-FAMILY: 微软雅黑">总计</span></div></td></tr>
<tr>
<td valign="top" width="84">
<div><span style="FONT-FAMILY: 微软雅黑">开发人员</span></div></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td valign="top" width="51">
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td valign="top" width="56">
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td valign="top" width="59">
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td valign="top" width="79">
<div><span style="FONT-FAMILY: 微软雅黑">15个功能</span></div></td></tr>
<tr>
<td valign="top" width="84">
<div><span style="FONT-FAMILY: 微软雅黑">测试人员</span></div></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td valign="top" width="51">
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td valign="top" width="56">
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td valign="top" width="57">
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td valign="top" width="59">
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td valign="top" width="79">
<div><span style="FONT-FAMILY: 微软雅黑">8个功能</span></div></td></tr></tbody></table><span style="FONT-FAMILY: 微软雅黑">（表一）</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 那么我们改变一下条件，假设团队中有4个开发人员，并且开发人员可以参与测试，结果会怎样呢？</span></div>
<div align="left">
<table style="WIDTH: 655px; HEIGHT: 115px" border="1" cellspacing="0" cellpadding="2">
<tbody>
<tr>
<td><span style="FONT-FAMILY: 微软雅黑"> </span></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周一</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周二</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周三</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周四</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周五</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">总计</span></div></td></tr>
<tr>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">开发人员</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">4功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">4功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">13个功能</span></div></td></tr>
<tr>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">测试人员</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">2功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">4功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">8功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">14个功能</span></div></td></tr></tbody></table><span style="FONT-FAMILY: 微软雅黑">（表二）</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 我们最终能够交付13点，产量提高了60%， 如果我们只留下三名全能人员：</span></div>
<div align="left">
<table style="WIDTH: 655px; HEIGHT: 115px" border="1" cellspacing="0" cellpadding="2">
<tbody>
<tr>
<td><span style="FONT-FAMILY: 微软雅黑"> </span></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周一</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周二</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周三</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周四</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">周五</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">总计</span></div></td></tr>
<tr>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">开发人员</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">3功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">1功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">10个功能</span></div></td></tr>
<tr>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">测试人员</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">0功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">4功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">6功能</span></div></td>
<td>
<div><span style="FONT-FAMILY: 微软雅黑">10个功能</span></div></td></tr></tbody></table><span style="FONT-FAMILY: 微软雅黑">（表三）</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 居然比3个开发人员和1个测试的人员组合还多交付两个功能！</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 我们当然有理由质疑第二题的假设：“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。我对此的的回答是：</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 第一，以我的观察来看开发人员之所以不进行测试工作，不是能力不允许，而是主观上认为测试工作是简单、重复而枯燥的，不愿意作。客观上开发人员们比较贵也更难于培养，组织层面不允许这样的“浪费”。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业，而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情（做正确的事），从而更倾向于熟练的按照脚本进行操作（正确的做事）。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 第二，我的关注点不在交付8点还是10点，我希望这个例子能够引发大家对于均衡生产的思考。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰（过度生产）和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"></span> </div>
<h2 align="left"><span style="FONT-FAMILY: 微软雅黑"> 拧螺丝的卓别林</span></h2>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 不难发现，对分工以及个体效率的迷信已经深刻的影响着IT领域。分工的端倪在招聘时就已经显现，即便对于差异不大的毕业生们，雇主也会根据其极有限的技能，用不同的标准进行测试（Java, .Net, PHP等），并在入职后将其冠以前端工程师，后端工程师，测试工程师，支持工程师等不同的头衔，甚至可能在其可见的职业生涯中专门负责某个文件的维护。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。对于IT企业来说，变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急，员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种（不是唯一一种）证明。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 整体效率的优化要求员工必须持续学习、成长，兴趣无疑是成长的催化剂，然而丧失意义的工作却在不断扼杀人的兴趣。丹·艾瑞里在怪诞行为学里著述到：</span></div>
<blockquote>
<div align="left"><span style="FONT-FAMILY: 微软雅黑">劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑">如果员工成长是必须的，那么，帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。</span></div></blockquote>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 在我看来，进行角色轮换的最大阻碍在于编程能力的普遍缺乏，大多数的测试、需求分析工作（鉴于大多数团队所处的地位，需求分析师实在言过其实，更精确的名字是需求整理师），迭代管理，简单的客户交流，学习曲线都非常低，任何成员都可以在师傅的带领下迅速掌握工作要点，然而编写程序却是个例外，即便对于基础良好的新人，在经验丰富的导师带领下，也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下，用别的角色轮换开发人员几乎是个死局。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 非常奇怪，IT领域如此的看重抽象能力和逻辑分析能力，可为佐证的是层出不穷的建模语言、模式、领域模型、架构。然而最能训练抽象能力和分析能力的一项活动，却仅仅有选择性的开展，这是不是意味着我们认为IT项目可以在大多数人无法（也没有能力）达成共识的情况下顺利展开并成功交付呢？在我看来，编写程序不仅仅是一项技能，一种思考方式，还承担着构造IT团队成员间共同经验区，提高交流效率的目的。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 一个值得从其它行业借鉴的经验是首先展开基础素质培养，再进入领域培养专业素养，换言之，避免过早的分工，所有新人从编程开始职业生涯，在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后，在员工对工作内容和自身兴趣有了充分的了解后，根据个人意愿进入领域发展专业技能，兴趣将成为员工成长的内在动力，而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 同时公司应当鼓励员工跨界工作，“应用Selenium和Ruby进行面向领域的Web测试”的作者是拥有卓越能力的开发人员，他曾经进行了相当长时间的测试工作，在其他人抱怨自动化界面测试难于维护时，他优秀的抽象能力、分析能力已经帮他提炼出测试模式，识别出缺陷，找到了优雅高效的工作方式并诞生了这篇优秀的文章。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 丹·艾瑞所言于我心有戚戚焉。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"></span> </div>
<h2 align="left"><span style="FONT-FAMILY: 微软雅黑"> 知行合一</span></h2>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 在过去9个月间我们在团队中进行了建设全功能团队的初步实践，在分享具体实践前，我希望下面的总结性数据能帮助你获得一些背景知识。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 项目处理的是期货交易领域，使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成（其中一名测试人员在项目中期加入），其中4位是毕业生，3位具备工作经验，但刚刚加入Thoughtworks，只有一位开发人员具备.Net开发经验。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 下面是全部35周的燃尽图，黑色实线代表项目的范围，绿色实线代表开发完成的速度，蓝色实线代表测试完成的速度，每周为一个迭代。</span></div>
<div class="image-wide" align="left"><span style="FONT-FAMILY: 微软雅黑"></span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 在这张图的大部分区域内蓝色和绿色是重叠或者非常接近的，这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面，这归功于测试人员自行实现的自动化测试框架对效率的提升，另一方面，开发人员参与测试也起到了平衡开发和测试速度的作用。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 让我们截取开发过程的一部分，观察每个迭代的速度，在下面这样图中，横轴代表第几个迭代，纵轴代表每迭代完成的功能点数。</span></div>
<div class="image-wide" align="left"><span style="FONT-FAMILY: 微软雅黑"></span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> 从项目经理的角度看，团队的交付速度很稳定，从15周开始直到项目的结束，我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多，包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下，每个人都具备跨角色，跨模块工作的能力才保证了可持续的交付节奏。</span></div>
<div align="left"><span style="FONT-FAMILY: 微软雅黑"> </span></div>
<p align="left"><br /></p> 我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在实践篇中我将详细分享一些实践以及我们团队的经验数据。
吃自己的狗粮
当开发人员坐在测试工作站前，你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件，多少人认为自己设计的复杂配置是荒唐的。在很多情况下，这都不是安装、配置的问题，而是设计问题，将开发和测试过程分离把痛苦转嫁给了另一个团体（测试、用服、用户），开发人员丧失了亲身使用软件的机会，从而无法发现问题的存在。暴露并修正这些问题，是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看，开发人员可以在一周内掌握大多数的测试技巧，个人的建议是从经验丰富的开发人员开始轮换，一方面他们更能认识到测试的必要性，便于交流，也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是：一对一的充分交流，让开发人员认识到进行测试工作的价值和目的。 引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌，要对开发人员形成挑战。 一周轮换2天持续数周或连续轮换2星期为宜。
睁开眼睛看大象
开发人员习惯于正确性驱动，然而正确的返回结果却不一定是必须的，有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳，10代表2010年，01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来，用于推断正确年份。这是必须的么？如果我们能了解到客户最大的压力在于半年后项目能否成功上线替换掉现有无人能够维护的应用，而不是100年后才可能出现的问题，我们是否能在类似的技术决策中，做出更聪明的选择呢？帮助开发/测试角色获取更多的信息，让他们了解到制定需求的上下文，而不仅仅是需求是什么；让他们更高的层面认清各个故事之间的关联，能够分辨可以给客户带来最大价值的任务，这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是：在进行分析工作前，开发人员需要完成多个模块的开发，而测试人员最好完成开发轮岗，否则收效甚微。 分析工作可以兼职进行，我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领下有重点的分析一、两个故事。 重点放在提供一套思考框架帮助新手梳理分析思路，我们发现一个有效的方法是结对工作、独立思考、演讲并点评。
根据我们的经验，两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路，教练可以考虑逐渐减少在新手思考过程中的侵入，再经过大概2个月的练习，新手基本可以独立工作。
和客户对话
在进行过分析角色的轮换后，可以进一步利用需求管理作为主线让团队成员参与到客户交流中，慢慢削弱项目经理的客户联系人角色，其主要价值在于：提升交流质量，一线人员常常比项目经理更了解产品。 展示开发人员的能力，增强客户信心。 弱化项目经理在客户眼中的重要性，为未来平滑的取代项目管理者，减少开销作准备。 帮助技术人员掌握交流技巧、提升团队能力。
个人建议是：从例行的功能展示会（showcase）开始，让每个成员练习从客户的角度进行思考（客户想看什么？），锻炼语言能力，消除与客户交流的恐惧感，并且让客户熟悉开发团队的每个成员，习惯开发团队的交流方式。 由多人分别准备客户进行电话会议中需要讨论的议题，每人深入的思考一、两个问题，通过充分思考弥补经验、技巧上的不足。 结对完成发给客户的邮件，让另一双眼睛检查有没有把该说的问题点到，表达方式、方法是否得当。 提供一套与客户交流的思考框架，并在与客户的交流中不断强化它。我们采用的框架是“客户，交付，流程，员工”，团队成员在思考问题时，首先从这四个点出发再逐层展开。
这项练习需要贯穿项目始终，对于团队成员无差别的进行，我们的经验数据是经过5个月左右的练习，项目经理就不需要出现在与客户的例行电话交流中了。
写程序，我行么？
测试人员普遍编程技术能力欠缺，同时有常常对编程这一未知的经验产生恐惧。从经验看，如果测试人员不能编写、维护自动化测试，测试工作将很快成为交付瓶颈。通过编程，让测试人员掌握技术，避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是：与测试人员结对完成简单的编码任务，不断树立信心。在这个团队中，我们从设计与实现自动测试框架开始，亲手设计的框架让测试人员更有能力来编写、维护测试，同时增强了编程的信心。 在测试人员消除了编程恐惧、具备编程基础后，安排测试人员与开发人员结对进行功能开发。
在这个过程中，必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧，同时针对每天的工作内容留一些家庭作业的效果也非常好。必须承认的事实是即便在完成轮换后，测试人员较开发人员还有一定距离，然而我们得到了一个意外的收获：进行过轮换后，再讨论需求时，测试人员越来越熟练的使用开发术语与团队交流，越来越多的参与讨论，甚至主导讨论，她开始直接引用核心组件的设计思想来推导测试用例，不断质疑和挑战开发人员，极大的提升了交流的效率和功能实现的质量。从经验数据看，大致需要3个月的时间测试人员可以达到在辅导下完成功能的程度。
订最后一颗纽扣
前端开发有其独特的知识领域，但这并不意味着任何界面工作都要由前端开发工程师来完成。前后端的分离增加了开发过程中的瓶颈以及人员认知领域中”Unknown Unknown”的区域，降低了找到更优解决方案的可能性。前端开发能力的培养特别适合在全团队中无差别的展开：让后端开发人员进行前端开发可以减少瓶颈，积累知识，构造“T”型知识区。测试人员需要测试界面，所以了解界面是如何工作，可以帮助她们设计出更高质量的用例，对于需求分析人员来说，高保真原型可以用作高效的交流工具。一个有效的方法是全面铺开，引入专家，重点培养，我们所采取的步骤是：要求全团队在业余时间完成一组界面练习，在全团队普及Html, Css和Javascript知识。 引入界面开发专家重点培养一名有兴趣进行界面开发的团队成员，对系统的界面结对进行改进，优化。 在界面开发专家的带领下，全员重新完成之前的界面练习，专家每天用一个小时讲解对应的前端技术并点评作业。
从全面普及知识到引入界面专家再到培养出新人，总共花费3周时间。值得一提的是，在整个过程中，由于之前团队建设的铺垫，其它成员有能力完全分担工作，团队重点培养的开发人员可以不受任何干扰，全职投入到前端开发中，最大程度的利用了界面开发专家的价值，提升了学习效果。
上同一艘船
项目经理是和技术领袖是作为现场管理者存在的，他们必须能够理解现场，能够通过现场的痕迹找到团队的不足和改进方向。那么，没有什么比卷起袖子参与到一线的工作中更能帮助这些角色理解现场。形成对产品质量和进度的亲身体验。理解现场，有效的管理现场而不是管理数据，而是这些角色轮换到开发、测试或者分析工作的主要价值所在。现场管理人员常常有太多的职责，既要对内负责也要对外负责，一个自然而然的问题是：”没有时间投入一线工作“。我认为现场管理人员的工作主要是两个部分：首先是职责所赋予的管理性事务，譬如状态的汇报，客户的管理等；其次是能力所赋予的工作，作为团队中最有经验的成员，他们需要参与到需求分析、架构设计、决策的制定、培训等活动中。基层管理者应当有意识的主动卸下身上的工作职责，完成到一线角色的转换，从另一个角度看，这个过程就是整个团队能力提升的过程，个人经验是：对职责所赋予的工作，首先做到对团队的状态、开发的进度等尽量的做到自动化、透明化、可视化，让所有人都能获得这些信息，其次通过知识传递，把不涉及敏感内容的工作下放，重点培养一、两名团队成员参与管理。 对能力所赋予的工作，一是针对团队急需提升的能力组织培训，二是通过结对工作传递知识，提升能力，让团队习惯于自行决策，有意识的逐步弱化自己在团队中的重要程度。
我们的的经验数据是大约需要4个星期，新人可以在指导下正确的进行管理实践（正确的做事），这已经可以保证基层管理角色有一定的参与一线工作的时间；而让新人具备辨别团队目前需要什么帮助（做正确的事），进一步将原有的管理角色基本弱化为开发角色，则需要6个月左右的引导和练习。
结对工作，不止于结对
我完全认可结对工作在知识传递、提升工作正确性方面的作用。我们几乎结对作所有的事情，某种程度上结对工作成为一种文化，成为了思维惯性和一种必然。长期的结对工作让我发现目前的结对方式对于培养新人还不够友好，这里，新人所指代的是广义的新人概念，不仅仅指毕业生，刚刚从事测试工作的开发达人也算是测试新人。目前结对方式的的缺点在于：培养了思维惰性，心理上依赖于别人的带领。 无法从失败中学习。有经验的人常常会跳过很多陷阱，新人的工作经历全是各种成功，一旦独立工作就被这些陷阱打的措不及防。 只见树木不见森林。譬如在TDD的过程中，新手可以看到一个个的方法是如何被设计的，如何从测试中被驱动出来，但很难从他的搭档那里学会如何想到要设计这些方法？从下向上驱动还是从上向下，各有什么区别？为什么这个方法要被放在这个类，而不是那个？
我认为结对工作其中一个被忽略的要点在于让新人在可控的状态下经历失败，获取经验，并且在工作中学会思考问题的方式（如何发现问题？从何处着手？怎么在不同的方案中取舍？从哪里开从哪里开始分析？），而不仅仅是思考问题本身（写什么测试？如何让测试通过？）。从我的观察看，培养新人比较有效的途径是从全程结对工作开始，通过对细节的指导让新人了解工作的主要方式和职责，进行必要的知识贮备，学会如何正确的做事。接下来应当让新人逐渐学会什么是正确的事情。我们的做法是：新人接到任务后，自行思考。 在白板上写下完成任务的主要步骤 向教练讲解主要思路和考虑点，教练通过提问引导他（输入特殊字符会怎样？） 自行完善方案 和教练一起确认方案 教练对整个思考过程进行点评，告诉新人这类问题的思考要点。
整个过程大致耗时半个小时，这种方式的优点是新人对方案非常了解，执行起来不容易跑偏；有机会在可控范围内犯错，成长更快； 新人可以通过不断的练习，有能力通过多个任务逐渐总结出一套思维方式。教练利用这种方法可以通过代码检视和有选择的结对（譬如针对任务中的难度部分结对）同时帮助多人，更有效率。
结局
在咨询的过程中，我见过太多的团队把目标放在交付上，寄希望于工具、外部力量能够快速的解决问题，往往对小步前进不够耐心，不关心团队的成员。在我们这个90%以上成员没有.Net经验，50%是毕业生的团队中，那些微不足道的改进，一点点的提升，最终造就了这个9个月中没有一天加班，几乎没有缺陷，提前交付的项目，客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话：把项目目标放在人员能力提升，让项目成功成为能力提升的副产物。 学习一下，求人管理，求人带啊
页:
[1]