modelo-icon

协作-37.HTML - 文章专栏 - 模袋云

Trimble SketchUp的安德鲁·科尼(Andrew Corney)写道,

当涉及到如何管理团队和交付工作时,建筑设计专业人员可能是时候跟随软件开发人员的领导并变得敏捷了

信不信由你,建筑设计和软件工程有很多共同之处。在这两种情况下,你会看到不同的技术团队,由独立工作的个人组成。专注于任务,这些任务加起来就是一个集成的产品。

有时,这些人会同时处理多个项目,每个项目都有自己的经理和客户。平衡多个项目的竞争需求使得谨慎的时间管理变得至关重要——但公平地说,尽管毫无疑问技能高超,但构建设计团队的个人并不总是像软件工程师那样擅长时间管理。

建筑设计,AFTER All倾向于宏观层面的关注,将来自不同公司的大型团队聚集在一起。相比之下,软件项目管理关注微观层面,使小型工程师团队具有高生产力。

这让我想到了一个我经常想知道的问题:在软件开发中,更微观层面的关注是否有助于提高构建设计团队的效率?

瀑布问题

要回答这个问题,理解它是有帮助的现代软件是如何开发的。有一段时间,这是一个“瀑布”过程,在开发工作开始之前,所有的决定都已经做出。

但随着敏捷流程的引入,这种情况已经发生了改变。现在,工作的交付是结构化的,以便不断检查进度,并可以相应地改变设计方向,几乎不会浪费精力。

相比之下,

建筑施工几乎必然是一个“瀑布”过程。设计必须是完整的在它的创建开始之前。虽然在大型建筑项目中,敏捷执行是可能的,但在大多数情况下,它仍然是一条漫长的道路。

<!--Develop3D Ads 300x250 inarticle 7p-->
广告
广告

然而,当我们直接将创建软件的工作部分与创建文档化的建筑设计进行比较时,会出现一些重要的相似之处。两者都有:

•一个松散的概念愿景,需要随着时间的推移加以发展和完善,成为工作解决方案

•随着更多信息的出现或项目要求的发展

,需要灵活性和适应性

•高度相互关联的依赖关系,需要单独开发,但很容易触发彼此

的变更要求

可以说,许多建筑设计团队试图通过瀑布式思维来最大限度地降低成本。这实质上意味着在开始之前等待一组完美的设计要求,以便更改n应避免。我们需要在开始之前了解一切的观念在工程中根深蒂固,但这可能不是最具成本效益的操作方式。

换句话说

,围绕敏捷性构建软件开发团队的方式也可能导致构建设计团队获得巨大的生产力收益。为了说明这是如何工作的,让我们比较三种组织技术任务和工作的方法。

“一切照旧”

的做法

这是建筑设计中最常见的方法,尤其是在咨询公司。在这里,参与项目的每个公司都是独一无二的,具有不同的管理风格和组织流程。

当设计专业人员被分配多项任务时,他们可能会被拉向不同的方向,并对工作

的优先顺序感到困惑

项目由项目经理管理,项目经理也可能领导项目的技术设计。或者仅仅是项目经理。他们根据可用的费用计划所需的资源。资源需求是根据整个项目的时间框架和最后期限制定的,项目经理作为一个小组定期举行会议,以便根据剩余的努力和在某种程度上有待完成的工作,就如何分配资源达成一致意见。

在一周的开始,团队资源被分配给项目,每个团队被分配一个或多个任务。作为每个项目的一部分进行表演。设计专业人员通常可以被分配到多个项目,并且通常不会被要求估计完成任务所需的时间。分配的任务通常需要一周以上的时间,一旦每个团队成员都知道他们在做什么,他们就会自生自灭,尽管经理和其他员工可能会检查并确保一切正常。

但是这个过程可能会导致许多问题,从而导致REDUCED生产力。如果有人在执行任务的过程中被阻止,他们可能不清楚在等待解除阻止时应该做什么。他们最终可能会执行不太重要或不太明确的任务,只是为了保持忙碌。当其他人正在审查一项任务时,情况尤其如此,他们可能需要很长时间才能将其交回进行更正,从而导致频繁的上下文切换。

或者,当设计专业人员被分配多个任务时,Y最终可能会被拉向不同的方向,并对工作的优先次序感到困惑。同样,这会产生频繁的上下文切换,从而导致错误和更长的完成时间。

最重要的是,该系统并不是为了奖励提前完成任务而设计的。随着时间的推移,这导致了一种花费可用时间来完成工作的文化,而不是尽可能高效地完成工作,这意味着企业失去了节省时间的机会。这个系统EM还惩罚花费时间超过费用允许的任务,即使没有对工作进行估计。这可能导致工作仓促和不正确,以及士气低落。

看板方法

看板是一种结构化的开放式框架,其中工作被划分为任务,这些任务在看板上直观地表示出来。这使团队中的每个人都能看到团队成员正在做什么以及每项工作的状态。

在看板中,项目上的工作CT分为“史诗”和“任务”结构。史诗是一个完整的范围;一个很好的例子可能是“交付暖通空调系统描述报告”。同时,任务是一项包含的、可定义的工作,有助于完成EPIC.例如,上述EPIC的任务可能是“运行负载计算”。

在看板框架中,需要为中期未来完成的工作被划分为任务。虽然任务大小不是技术上的重要的是,一项大型任务是由一名工程师经过三到五天的独立努力后完成的有意义的事情。

我们需要在开始之前了解一切,这一概念在工程中根深蒂固,但这可能不是最具成本效益的操作方式。换句话说,围绕敏捷性构建软件开发团队的方式可能会导致构建设计团队获得巨大的生产力。也是

在沿看板线运行的建筑项目中,项目经理在项目开始时花时间将已知范围划分为任务。一旦项目开始,项目经理就会对前10-20项任务进行优先排序并分配最后期限。在此阶段,任务包括说明、注释依赖关系并提供启动任务所需的文档。“准备就绪”的任务显示在看板的左栏中。只有一次初步Wル.阻止任务的人会得到通知,设计师在等待时会转到下一个优先级最高的任务。任务完成后,将移至“ QA ”,检查是否完成,然后移至“完成”。

跟踪每项任务所花费的

时间,当工作完成时,空闲的团队成员将转到下一个优先级最高的任务。每天,整个团队都会参与15分钟的单口相声,让每个人都有机会强调他们在哪里遇到了障碍,需要帮助。或者任务需要QA检查的地方。它还允许团队庆祝已经完成的工作。

看板

之所以如此有效,是因为任何人在任何时候都不能有一个以上的任务“正在进行”,并且任务的优先顺序始终是明确的,指导团队在任何给定的时刻应该处理哪些任务。

Scrum方法

Scrum是敏捷开发的一个更加结构化的版本,它试图为G的完成日期创造确定性。任务组,并提高团队对这些任务的关注。作品依然分为史诗和任务,只是任务的交付方式不同。

与看板不同的是,在看板

中,项目经理对每项任务都有完全的控制权,而Scrum则试图将任务分配到不间断的“冲刺”中,通常持续一到两周。在此期间,任务不能更改或重新确定优先级,设计师只需完成Sprint中的所有工作。

一周的打印可能按如下方式工作。在Sprint之前的星期五,工程团队召开计划会议,评估完成任务所需的工作量,并商定哪些任务将构成Sprint的一部分。在这一周里,设计师们有一个明确的目标——完成冲刺阶段的所有任务。当设计师完成任务时,他们被鼓励去看看还剩下什么,并专注于如何在冲刺阶段的剩余时间内完成工作。这可能包括帮助他人完成任务。毕竟,团队的目标是完成所有任务。

在一周结束时,团队简要分享已完成的工作。如果错过了最后期限,他们会讨论完成工作的估计时间在哪里出了问题以及原因(或额外努力完成工作)。

在Scrum中,看板通常用于帮助组织Sprint中每个任务的状态。但是Scrum和看板之间的主要区别是Scrum提供了更多的焦点(以统一的形式一周的工作范围)。与此同时,代价是灵活性降低。

敏捷建筑设计——你准备好了吗?

Scrum和看板都可以从根本上改变建筑设计公司组织工作交付的方式。

但领导是必不可少的,因为这两个过程都赋予了项目经理更大的责任来协调任务的准备工作并响应团队的需求。在许多方面,这些过程把项目经理变成了“服务”。“ NT领导者”,他们努力为设计工作扫清道路,以最小的干扰和最高的效率完成设计工作。

不管怎样,科技行业已经投入了巨大的努力来优化软件交付的过程,并将继续这样做。尽管建筑行业也经常评估交付机制,但它并不倾向于在如何管理和运行各个团队的微观层面上这样做,但也许是时候做出改变了。

安德鲁科尼是Trimble SketchUp的产品经理

<!--relpost-thumb-wrapper--><!--close relpost-thumb-wrapper-->

广告
如果(!window.adbutler){(function(){var s=document.createElement(“ script ”);s.async=真;s.type=“ text/JavaScript ”;s.SRC=https://servedbyadbutler.com/app.js';var n=document.getElementsByTagName(“ Script ”)[0];n.parentNode.insertBefore(s,n);}();}