失调的动态工作方式
研究表明，在研发过程中，这种模式可能极其低效。同样，上级领导的定期阶段关卡审查也可能意味着，整个团队在埋头苦干数月之后才意识到与管理层的期望不符，因此，这也可能导致返工。
敏捷软件开发方式还能提高开发人员单独工作时的工作质量。专注于开发功能性组块，意味着团队和客户距某个可使用的软件片段永远不超过几星期的距离，因而大大便于评估它是否能满足客户需求。
相比之下，在瀑布模式中，早期阶段的客户要求列表和所需功能列表总是很长，却没有什么可供尝试或测试的内容。所以，瀑布法往往导致在项目开发周期的结尾环节才发现重要缺陷和其他问题，以致需要成本高昂的返工。
4 动态工作设计的实际应用
与传统的静态方法相比，动态工作设计承认变化不可避免，并建立了应对变化的机制。一旦管理者认识到在偏个人型工作模式与偏协作型工作模式之间切换的必要性，便可基于以下四个原则创建与本组织的工作完美匹配的切换机制。
1. 区分明确界定的工作和模糊的工作
首先要清楚地区分明确界定的任务和模糊的任务。试图用同一流程处理这两种类型的工作往往会导致麻烦。
通常情况下，这两种类型的工作可以通过检查来区分，如果这个办法无效，则需要查找模糊型工作的标志性元素——迭代。明确界定的工作可以像接力棒一样，从一个阶段传到下一阶段。如果正确完成，就无须回头审视。
相反，当工作是模糊的时候，即使做得再好也经常需要重新审视。如果你发现某项任务需要经过同一组步骤多次迭代，这就充分表明，你正在以低效方式处理模糊的任务。
2. 将工作流程分解为可以经常检查的较小工作单元
无论是在传统的、前丰田时代的制造业还是在瀑布式软件开发中，评估工作都不够频繁，而且不是特别有效。结果，这两种方法针对外部环境变化所做的调整往往比较迟缓，只能通过缓慢且成本高昂的返工周期来达到高质量。
相反，在评估工作频繁且高效的情况下，工作流程的适应性极强，质量也能迅速提高。简而言之，提高流程敏捷性的基本方法就是：拆小工作单元，增加检查频次。
3. 识别为工作提供支持的帮助者链条
识别帮助链也很重要——就是看清哪些人能够按照何种次序为这项工作提供帮助。
根据我们的经验，关键在于识别从事这项工作和为其提供支持的一系列具体人员，而不是看他们的职务、部门或职能。提高敏捷性需要你在出现问题或需要反馈时，知道该给哪个人打电话。
4. 设置将工作转入协作模式的触发器和核查机制
一旦了解了帮助链，你可以通过两种基本机制来激活它：触发器和核查机制。所谓触发器就是一个测试，它能显示缺陷或偏差，随即将工作从工厂模式切换到偏协作的模式。
再看前文所举的例子，丰田生产线上的操作员无法按时完成组装任务，这触发她按下..按钮，然后接受主管的帮助。核查机制包含一个预先安排的时间点，在此时间点上将工作转到协作环境接受评估。
在敏捷软件开发过程中，这个转移发生在每日立会上，团队趁此时间迅速评估项目的当前状态。每个冲刺结束则创造了再次核查的机会，这一次是接受客户的评估。
5 追寻最佳原则
企业管理者和咨询顾问往往痴迷于追寻最佳实践——那些让领先企业脱颖而出的做法。其背后的理念是，一旦识别出最佳实践，便可将其推广到其他组织，从而创造类似的绩效收益。
但企业实际采纳新工具和新实践的过程往往困难重重，能取得类似绩效的也极为罕见。
这种模仿失败的一个关键原因是，组织拥有复杂的人员和技术配置，某一套工具或实践在一个组织环境下运行良好，但是对于该组织的主要竞争对手来说就未必同样有效——即使两家企业就在同一条街上比肩而立。
所谓最佳实践，只有当它背后的行为准则能够与组织本身完美匹配，才称得上“最佳”。
丰田那闻名遐迩的安东绳及其催化的本地化问题解决方案，主要是利用了个人重复性工作所创造的效率和协作解决问题所带来的创新。反之，敏捷软件开发方法则借助频繁的团队会议和客户互动来引导软件工程师提出创意，从而取得成效。
从更广泛的意义上来说，当组织具备及早发现缺陷和偏差的能力，其适应力就会更强。由触发器和核查机制支持的动态方式可以开辟一条新路，帮助组织提高工作敏捷性。
作者简介：纳尔逊·雷佩宁，麻省理工学院斯隆管理学院（Sloan School of Management, MIT）系统动力学和组织研究领域杰出教授，现任该学院负责领导力和特殊项目的副院长兼领导力中心学术主任。
唐·基弗，斯隆管理学院运营管理高级讲师，同时也是ShiftGear Work Design公司创始人。
詹姆斯·雷佩宁，ShiftGear Work Design工作设计公司执行合伙人。
