“所谓最佳实践，即是背后的行为准则能够与组织本身完美匹配。”
近来凡涉及管理和领导力方面的讨论，“敏捷”一词已成为最大的热点。从通用电气（General Electric）这样的大企业到小微初创公司，都在试图对新技术和瞬息万变的市场环境做出灵活而又迅速的反应。
多种研究表明，与传统的软件开发方法相比，敏捷开发方法在成效上可以带来重大提升。但是，这在软件领域之外有何意义？敏捷方法能否成功应用于其他类型的工作？
1 稳定性vs.不确定性
长期以来，学术界和管理界人士一直认为，组织必须在灵活性和效率之间做出取舍。传统的工作设计有一个简单的原则：
- 如果所设计的工作是由明确界定的任务组成（部件组装），那么最好将它们组织成一个连续序列，即“工厂”模式；
- 如果所设计的工作是高度模糊的，需要持续的互动（新产品设计），那么最好采用协同化的组织方式，即“工作室”模式。
传统的工作设计
传统的流程和组织设计方法几乎完全是静态的，其中暗含的假定是：某个工作一旦经过设计，一切都将按计划有条不紊地进行。相反，动态的工作设计方法则认为现实组织中不可避免会出现各种小问题，工作需要根据这些意外情况不断调整。
敏捷方法超越了传统上“序列vs.协作”的工作框架，它创建了一种更好的机制，可在两种基本工作组织方式之间灵活切换，从而大大减少了在效率和适应性之间做出取舍而付出的代价。
2 丰田公司的动态工作设计
丰田生产线上的工作状况可以说是序列式、机械式工作设计的一个缩影。在丰田生产线上，设计了一根特别的拉绳，称为“安东绳”（也有的是按钮），任何一名工人只要发现异常，就可拉动拉绳（或者按下按钮），叫停生产线，把问题解决掉。
我们在参观丰田供应商的生产车间时，看到一位操作员遇到某种问题，无法在规定时间内完成自己的任务，于是她按下一个黄色报警按钮。
几秒钟内，该生产线的主管便赶到该工位，帮助操作员解决了妨碍她按规定程序完成任务的问题。不到一分钟的时间，这名操作员就可以完成指定任务了，她重新投入正常工作，那位主管也回去进行其他工作。
从工作设计的视角看，最开始，这名操作员是在“工厂”模式下工作，当出现问题时，操作员有两种选择：
- 她可以寻求某种临时的调整措施，使工作不致中断，但这种选择往往导致极严重的不良后果；
- 另一种选择，她可以按下那个按钮，中断工作，并寻求帮助。
这一按暂时改变了原来的工作设计，整个工作体系暂时离开机械的序列模式，转向了一种着眼于解决问题的、更有机的、协作式的方法。一旦问题得到解决，操作员便回到正常工作状态，恢复序列式工作设计。
丰田供应商的动态工作设计
3 敏捷作为一种动态工作设计方法
过去20年来，软件开发的方式发生了重大变化。曾几何时，软件开发大多采用所谓的“瀑布式”方法，然而敏捷方法如今已变得越来越流行。从动态工作设计的角度来看，瀑布式方法和敏捷式方法差异极大。
用瀑布式方法完成的软件开发项目通常在三种基本工作模式之间循环：
- 第一，在大部分时间里，软件架构师和软件工程师单独或以小组形式工作，完成特定阶段的任务目标；
- 第二，通常每周召开一次项目会议，以上人等放下手头的工作，聚到一起，报告各自的进展情况，核查相互间是否兼容，并按照上级指示的任何方向变化进行调整；
- 第三，在每个阶段临近收尾时，会有一个更重要的审查，通常称作“阶段关卡审查”，由高层领导仔细核查，以确定是否可以退出本阶段，进入下一阶段。其他类型的非软件项目的开发周期通常也与此类似。
敏捷开发流程则采用不一样的方式来组织工作。像瀑布法一样，敏捷软件开发方式也有三种基本工作模式——个人工作、团队会议和客户评审，但三者的循环方式大为不同：
- 首先，敏捷方法的倡导者们建议每天召开碰头会，也就是每天经历“个人模式-团队模式-个人模式”这三者之间的切换，由团队成员报告当天的进展、第二天的计划，以及预计可能遇到的阻碍；
- 其次，敏捷方法建议团队在每个“冲刺”结束时，让客户来测试新增的功能；
- 最后，一些版本的敏捷方法也包含某种类似于“安东绳”的设置，当某段代码没能通过特定的自动化测试时，当前工作就立即升级到整个团队级别，从而有效地将系统从个人工作模式切换到团队协作模式。
从动态工作设计的视角来看，敏捷方法较瀑布式方法有两大潜在好处：
第一，在瀑布式开发中，团队成员之间及团队与客户间的协作频率通常过低。
一名开发人员埋头工作一两个星期而不经核查，很可能在白白浪费许多精力之后，才发现自己犯了错或者偏离了正路。在实践中，开发人员常常不会等待这么久，而是提前与主管或团队伙伴进行非正式地核查。这种私下核查看似实用，但也可能造成整个团队不能在同步接收项目状态信息的基础上开展工作。
在这种情况下，项目运行模式开始从图中左下单元格的“工厂”模式转向右下单元格“以序列方法组织模糊型工作”的模式。这会导致代价高昂且进展缓慢的迭代，我们称之为“无效迭代”。
失调的动态工作方式
研究表明，在研发过程中，这种模式可能极其低效。同样，上级领导的定期阶段关卡审查也可能意味着，整个团队在埋头苦干数月之后才意识到与管理层的期望不符，因此，这也可能导致返工。
敏捷软件开发方式还能提高开发人员单独工作时的工作质量。专注于开发功能性组块，意味着团队和客户距某个可使用的软件片段永远不超过几星期的距离，因而大大便于评估它是否能满足客户需求。
相比之下，在瀑布模式中，早期阶段的客户要求列表和所需功能列表总是很长，却没有什么可供尝试或测试的内容。所以，瀑布法往往导致在项目开发周期的结尾环节才发现重要缺陷和其他问题，以致需要成本高昂的返工。
4 动态工作设计的实际应用
与传统的静态方法相比，动态工作设计承认变化不可避免，并建立了应对变化的机制。一旦管理者认识到在偏个人型工作模式与偏协作型工作模式之间切换的必要性，便可基于以下四个原则创建与本组织的工作完美匹配的切换机制。
1. 区分明确界定的工作和模糊的工作
首先要清楚地区分明确界定的任务和模糊的任务。试图用同一流程处理这两种类型的工作往往会导致麻烦。
通常情况下，这两种类型的工作可以通过检查来区分，如果这个办法无效，则需要查找模糊型工作的标志性元素——迭代。明确界定的工作可以像接力棒一样，从一个阶段传到下一阶段。如果正确完成，就无须回头审视。
相反，当工作是模糊的时候，即使做得再好也经常需要重新审视。如果你发现某项任务需要经过同一组步骤多次迭代，这就充分表明，你正在以低效方式处理模糊的任务。
2. 将工作流程分解为可以经常检查的较小工作单元
无论是在传统的、前丰田时代的制造业还是在瀑布式软件开发中，评估工作都不够频繁，而且不是特别有效。结果，这两种方法针对外部环境变化所做的调整往往比较迟缓，只能通过缓慢且成本高昂的返工周期来达到高质量。
相反，在评估工作频繁且高效的情况下，工作流程的适应性极强，质量也能迅速提高。简而言之，提高流程敏捷性的基本方法就是：拆小工作单元，增加检查频次。
3. 识别为工作提供支持的帮助者链条
识别帮助链也很重要——就是看清哪些人能够按照何种次序为这项工作提供帮助。
根据我们的经验，关键在于识别从事这项工作和为其提供支持的一系列具体人员，而不是看他们的职务、部门或职能。提高敏捷性需要你在出现问题或需要反馈时，知道该给哪个人打电话。
4. 设置将工作转入协作模式的触发器和核查机制
一旦了解了帮助链，你可以通过两种基本机制来激活它：触发器和核查机制。所谓触发器就是一个测试，它能显示缺陷或偏差，随即将工作从工厂模式切换到偏协作的模式。
再看前文所举的例子，丰田生产线上的操作员无法按时完成组装任务，这触发她按下黄色按钮，然后接受主管的帮助。核查机制包含一个预先安排的时间点，在此时间点上将工作转到协作环境接受评估。
在敏捷软件开发过程中，这个转移发生在每日立会上，团队趁此时间迅速评估项目的当前状态。每个冲刺结束则创造了再次核查的机会，这一次是接受客户的评估。
5 追寻最佳原则
企业管理者和咨询顾问往往痴迷于追寻最佳实践——那些让领先企业脱颖而出的做法。其背后的理念是，一旦识别出最佳实践，便可将其推广到其他组织，从而创造类似的绩效收益。
但企业实际采纳新工具和新实践的过程往往困难重重，能取得类似绩效的也极为罕见。
这种模仿失败的一个关键原因是，组织拥有复杂的人员和技术配置，某一套工具或实践在一个组织环境下运行良好，但是对于该组织的主要竞争对手来说就未必同样有效——即使两家企业就在同一条街上比肩而立。
所谓最佳实践，只有当它背后的行为准则能够与组织本身完美匹配，才称得上“最佳”。
丰田那闻名遐迩的安东绳及其催化的本地化问题解决方案，主要是利用了个人重复性工作所创造的效率和协作解决问题所带来的创新。反之，敏捷软件开发方法则借助频繁的团队会议和客户互动来引导软件工程师提出创意，从而取得成效。
从更广泛的意义上来说，当组织具备及早发现缺陷和偏差的能力，其适应力就会更强。由触发器和核查机制支持的动态方式可以开辟一条新路，帮助组织提高工作敏捷性。
作者简介：纳尔逊·雷佩宁，麻省理工学院斯隆管理学院（Sloan School of Management, MIT）系统动力学和组织研究领域杰出教授，现任该学院负责领导力和特殊项目的副院长兼领导力中心学术主任。
唐·基弗，斯隆管理学院运营管理高级讲师，同时也是ShiftGear Work Design公司创始人。
詹姆斯·雷佩宁，ShiftGear Work Design工作设计公司执行合伙人。