跨职能团队合作的挑战似乎对设计专业人士，，，，尤其是顾问和咨询工程师来说最为艰巨。。。。部分困难可能源于设计实践的经济性。。管理顾问长期以来一直建议设计师保持高利用率。。。。为了获得经济效益，，，他们的专业员工需要每天尽可能多地计算成本。。为了保持这种高利用率，，顾问通常必须同时处理多个项目，，，以确保不会出现浪费成本的停工时间。。。。如果目标没完成，，，就加班加点改进产品。。。但这与精益的拉动原则直接相悖，，，，拉动原则要求你只响应“客户”的信号而工作，，，，否则就休息或改进。。。在精益系统中，，，问题不是“悦道能让员工做什么来提高利用率？？？”，，，而是“如果某项工作没有提供价值，，悦道可以移除或停止什么？？？”。。。。此外，，除非专业人员待在办公室，，，，随时可以访问多个项目的文件，，否则很难在多个并发项目中实现高利用率。。这会削弱公共办公的所有优势。。
利用率强制要求还有另一个有害影响。。在具有可变性的系统中，，，，高利用率会导致整体效率大幅下降。。。。在一个具有大量可变性的系统中，，，随着利用率的提高，，，平均周期时间反而会恶化，，，而不是改善。。这对于普通会计师或管理顾问来说是违反直觉的，，因为他们被教导“通过提高资源利用率来提高生产力”。。。这意味着，，由于资源利用率高，，，团队绩效所需的信息会急剧延迟。。。最后，，许多工程公司习惯于在施工文件阶段与收到提交文件同时完成设计。。鉴于上述问题，，，后期介入会加剧延误。。。大型软件开发项目和复杂的设计项目对创造力、、、效率、、、质量和协调性有着类似的需求，，，并且它们同样面临着困扰设计和构建过程的许多问题。。。。传统上，，，，大型软件项目采用“瀑布式”方法开发。。。。首先评估客户需求，，，然后开发一个全局架构并将其分解为各个组成部分，，然后开发、、记录和安排各个任务。。随着项目接近尾声，，测试将开始，，以发现和纠正编程错误。。。团队根据他们的特殊才能或任务进行组织。。。瀑布式项目结构类似于传统的构建和设计方法。。。尽管投入了巨大的精力和资金，，，，但瀑布式方法并没有奏效。。。项目经常出现延期、、程序臃肿、、错误百出和预算超支的情况。。。。
大约二十年前，，，，一些程序员团队开始尝试以小型跨职能团队为核心的灵活方法，，，这些团队可以自我组织和管理。。工作被量化以适应团队，，并设定了时间限制。。。幸运的是这些改变奏效了。。。。其结果是精益、、、、敏捷和Scrum等灵活方法的开发和采用。。。。尽管其中一些概念需要进行转化才能适应项目的设计/施工前阶段，，，，但它们的实验和成功经验对于那些寻求更好方法的人来说，，具有重要的启示意义。。。
“敏捷”并非一种实践。。。它是一种组织及其员工的品质，，，，即适应性强、、、、响应迅速、、持续学习和发展——敏捷，，，，其目标是获得竞争性的商业成功，，，并快速交付具有经济价值的产品和知识。。。。尽管人们谈论敏捷实践，，，，但其概念是“敏捷”，，，，而不是“实践敏捷”。。。。敏捷软件开发的九大原则与高效精益设计的建议非常相似。。
向客户交付有用的东西；了解他们重视什么；
培养忠诚的利益相关者；
采用领导协作风格；
建立有能力的协作团队；
支持团队决策；
使用短时间盒迭代快速交付功能；
鼓励适应性；
倡导技术卓越；
专注于交付活动，，而不是流程合规活动。。。
在设计环境中，，，，敏捷有三点值得一提。。。敏捷意味着贴近客户。。为了避免排队问题，，敏捷团队会在特定的时间限制（冲刺阶段）内处理特定的可交付成果，，，，通过调整批次大小来减少差异，，，并提高吞吐量。。这可以实现合理的利用，，，而不会造成僵局。。。。最后，，目标是软件，，，，而不是文档。。。例如在建筑工程中，，，，结构设计的输出是建筑物，，，而不是图纸，，甚至不是模型。。。。从这个角度来看，，，，设计师的客户是承包商，，，设计应该“拉动”，，即设计应该提供承包商所需的信息，，，以使其能够实现设计师的意图。。。最后，，，测试并非最终阶段，，，而是贯穿于整个设计过程的每个步骤。。。。因此，，质量保证/质量控制并非一个单独的阶段，，而是贯穿整个设计过程。。。。
Scrum 是敏捷方法的一个特定版本，，以小型、、、自我管理、、、、跨职能团队为基础构建。。。Scrum 通常由大约 7 名来自不同背景、、承担不同职责的人员组成。。。此外，，，，Scrum 本身没有“领导者”，，，而是由一位拥有出色主题知识和人际交往能力的人员（Scrum Master）指导，，该人员提供经验、、培训和资源。。。。团队从优先级列表（产品待办事项列表）中选择要在冲刺中完成的项目，，，然后确定实现目标的最佳方法。。 Scrum 的一个显著特征是每日 Scrum 会议，，每个人在会上汇报自己正在进行的三件事：自上次会议以来取得的成果、、下次会议将要完成的目标以及目前遇到的障碍或阻碍。。。整个会议时间不超过 15 分钟，，会议期间没有讨论。。。。会议结束时，，，，如果各方有想法或建议，，，，可以分成小组进行讨论。。。Scrum 会议的时间不会用于讨论只与一两个人相关的问题，，，也不允许任何人垄断谈话。。。。在某些 Scrum 会议中，，管理层不得参加。。。。会议的目的是使团队能够更好地运作，，，而不是让管理层对活动进行评分或指导。。。团队成员每天都会更新他们对完成待办事项中当前任务所需时间的预估。。。。
冲刺剩余小时数已计算，，，进度记录在冲刺燃尽图中。。。。团队目标及其进度完全透明。。。。与敏捷一样，，，，Scrum 具有在设计和环境中产生共鸣的潜在价值观。。
承诺——愿意承诺实现目标。。。Scrum 为人们提供履行承诺所需的所有权限。。。
专注——做好你的工作。。。将你所有的精力和技能集中在你承诺的工作上。。
开放——Scrum 让每个人都能看到项目的方方面面。。
尊重——个人由其背景和经验塑造。。尊重团队中的不同成员非常重要。。
勇气——勇于承诺、、、采取行动、、、、保持开放并期待得到尊重。。。。
设计和开发行业受益于精益、、、预制、、、、跨职能团队甚至 BIM 等技术，，，，敏捷和 Scrum 将效率的重点从利用转移到创造价值。。并让团队更专注于交付有用的交付成果。。。。设计质量已融入流程，，，，团队能够获得客户认可的成果。。
相关新闻推荐
