News-资讯-管理

敏捷行动,响应变化

马保静

 

敏捷宣言

          个体和互动高于流程和工具

          工作的软件高于详尽的文档

          客户合作高于合同和谈判

          相应变化高于遵循计划

 

这是一个敏捷的时代。

在互联网技术的推动下,越来越多的行业面临着快速发展、不断变化的生存环境。每一天甚至每一秒,都会有新的思想产生,都会有新的产品正在推向市场,也有无数家企业正在倒闭。快速应变,成为所有企业必须面对的问题。

设计行业是传统行业,是依靠一个个项目完成,推动业务的发展。在行业发展的过程中,设计质量是衡量设计成果尤其施工图设计成果是否合格的、重要甚至唯一的指标。而这些项目的管理和执行,在很长时间里,依靠的是传统的项目管理方法,也就是“瀑布型”方法,设定明确的目标,制定严密的计划,依靠严谨的过程管理控制质量,完成设计任务,提供技术成果。成熟的设计企业会有一整套的质量管控体系,有的还完成了ISO认证。这些管理体系为保证设计质量起到了巨大的作用,也大大推动了设计企业的规范化管理。

然而,随着房地产行业的发展,很多设计企业的业务更多地来自于地产项目。由于很多原因,地产项目不但周期很短,且存在很大变数。政策变化、或者市场环境改变、销售的压力,都有可能引发产品设计的变更。客观存在的现实是,还有不少项目已经在建造的过程中还会因为成本的压力而产生变更。甚至购房业主的要求,都有可能反馈到产品设计端,从而产生设计变更。这些变更引发的问题方方面面,设计团队因为频繁的变更而造成项目成本无形增加,甚至导致图纸质量的失控。又或者因为坚持遵循变更管理流程而使得设计周期延后,影响到开发商的项目整体推进速度。甚至因为变更而造成返工,不但增加建造成本,也增大了工程质量风险。面对这样频繁变更、时间紧的项目,原有的项目管理方法几乎不起作用,“计划没有变化快”成了困扰设计企业的大问题。

既然传统的方法不起作用,那么有没有什么新的方法可以解决这样的问题呢?

敏捷项目管理,也许是一个值得探讨的思路。

什么是敏捷项目管理?

敏捷项目管理出现于20世纪90年代中期,最早应用于软件行业。它是一种全新的项目管理价值观引导下的、全新的项目管理方法论。

敏捷项目管理能够快速调整和应对不断变化的商业需求,具有在动荡环境下产生商业利润、平衡灵活性与稳定性的能力。

传统的项目管理是计划导向的,注重预测,基于明确的需求,强调管理和控制,严格遵循确定目标、定义范围、制定计划、按流程实施的过程,适用于稳定的环境。如:工程建设项目,大型活动,航空航天项目等。

而敏捷项目管理是价值导向的,在需求不确定的条件下,依靠高技能的团队,开发团队与客户的紧密交互,通过小版本多次迭代,不断完成“计划—执行—实证”的过程,提供最能实现客户价值的产品。敏捷项目管理注重适应,适用于不确定的、多变的环境。如:IT、生物制药、智能自动化等。

敏捷的核心价值观——敏捷宣言

2001年,17位敏捷方法论的拥护者在美国犹他州的雪鸟滑雪场共同起草了一份陈述敏捷组织原则的文件,这就是《敏捷宣言》。它的内容非常简单:

        个体和互动高于流程和工具

        工作的软件高于详尽的文档

        客户合作高于合同和谈判

        相应变化高于遵循计划

这里所说的“高于”并不是取代,而是更为强调另一方面的价值。

虽然只是短短四句话,但可以说对传统的项目管理观念是一种颠覆。

它强调了了人的价值。沟通和充分的信息交换是非常重要的,项目的成功必须关注于团队与客户、团队成员的互动和交流,而不是一味强调流程,让工具束缚住手脚。

它强调了成果的价值。项目的核心是向客户交付成果而非过程中的记录文档,团队应该把更多的资源用于创造可交付的成果,而不是把精力过多地用于填写繁琐的文件表格。当然这不是说不需要文档,而是强调文档刚好够用就行,不要因为完成冗余的文档而使项目目标失焦。

它强调了客户的充分参与。团队与客户之间,应该建立相互信任的合作关系,项目团队应该花精力和客户保持方向一致,站在客户的立场为客户创造更大的价值。项目团队不应该预设立场甚至站到客户的对立面,仅仅想着保护团队利益,把大量的精力用于拟定或谈判限制双方的合同条款。

它强调适应变化,而非拒绝变化。传统项目管理是不希望有变更产生的,因为可能会影响到项目范围、时间、成本一系列的变化,因而制订了严格的变更管理流程,要求项目严格按照计划执行。但敏捷项目因为其适应外界环境的要求,为了能够实现客户价值最大化,则更积极响应变更。

敏捷准则

在敏捷宣言的知道下,敏捷项目管理遵循12条准则:

1、  我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、  欢迎对需求提出变更,即使在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、  要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、  在项目过程中,业务人员与开发人员必须在一起工作。

5、  要善于激励项目人员,给他们所需要的环境和支持,并相信他们能够完成任务。

6、  无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、  可用的软件是衡量进度的主要指标。

8、  敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、  对技术的精益求精及对设计的不断完善将提升敏捷性。

10、   要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11、   最佳的架构、需求和设计出自自我组织的团队。

12、   团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

总的概括起来,分别针对二个方面:

一是产品交付。敏捷项目需要快速迭代,用小步快跑的方式,尽可能短的周期,向客户交付有价值的、可用的成果。强调好的产品是简洁利落易于维护和变化升级的,这需要更高的技术能力才可以做到。同时,在开发过程中应保持稳定的速度,既不要使周期拉得过长浪费资源,更不要在项目收尾时陷入“赶工”的泥潭。

二是团队和协作。敏捷项目是以团队为核心的,积极和优秀的成员是团队的成功因素,而自下而上、自我管理更是敏捷团队的管理方式。强调面对面的沟通,快速传递信息,消除障碍,激发团队自身的创造力。更重要的是在这样“小步快跑”的过程中,通过“每日站会”、“阶段回顾”等方式,随时总结反省,可以快速总结经验教训,在下一个周期里迅速得到改进。

更为具体的理解和阐述,有许多参考书可以查阅,在这里就不一一赘述。

用敏捷方法管理设计

今天的商业环境对传统行业已经形成了巨大的冲击,我们发现敏捷的方法论不再仅限于IT行业,而是覆盖了许多深处变革中的行业。

设计是传统行业,但今天同样面临着变革的需求。环境在变,市场在变,客户在变,我们怎可能闭门造车,拒绝变化?

首先,传统的设计管理是不欢迎变更的,因为这会导致工作范围蔓延、进度拖后、质量下降等后果。然而,你坚持不变就可以了吗?我们有多少时间和精力,花在了和客户拉锯式的争论,以及要求客户必须遵循我们的设计流程。然而最终,又有多少变更要求是真的被我们成功地挡在了门外呢?我们依然要完成设计变更,却“出力不讨好”,甚至导致客户满意度的降低。就算是大型设计企业有着稳定的流程和质量管控体系,项目的控制能力、对客户的说服能力较强,变更较少,但最终的成果真的就是各方满意的吗?

其次,我们的设计成果真的就达到客户的预期了吗?细究下来,很多方案性变更,是因为考虑不周造成的。这不能简单归罪于设计师不认真或者客户不专业,在极短的周期内,要“一次成型”做出一个满意的成果,真的很难。在没有详细或完整的图纸之前,成本是很难估算得那么准确的,各专业的管线空间、结构尺度对于建筑的影响,很难说可以细到触手可及的尺度范围内。我们都在凭经验判断,通过一个个失败案例总结教训,这固然是一种方法,然而所谓的精细化设计,如果没有细化的成果支撑,怎么精细得了?

我们一直强调流程、进度、质量,要求项目团队有计划、按照计划实施,但一直以来抗性非常大。团队不愿意写计划,因为“计划没有变化快”。你说是计划不够细,但是真的需要花那么多的时间去做一份严谨详尽的网络进度图吗?团队不愿意开会,因为觉得浪费时间。你可以说他们不懂得有效会议的规则,但是所有的会议都是必要的吗?自上而下的管理固然可以把控住大的方向,但是如果所有的设计师都等着总工来定某一扇防火门是不是该加,某一根梁是不是合理,那么总工岂不是要忙死都解决不了问题?

上面这些矛盾和疑惑,在整个设计行业都存在,无非因为项目的不同而有差异,也由于各设计企业不同的管理模式焦点不同而已。

与其在原地纠结徘徊,不如另辟蹊径,看看有没有更好的方式。

敏捷方法在之前更多地是用于软件行业,因此不管是敏捷宣言还是敏捷准则,其描述都围绕着软件开发。然而细究其内容,发现很多新的理念和方法,也许就可以用作解开我们难题的钥匙。

传统设计管理,遵循“方案—初步设计—施工图设计”的流程,每一个阶段都有深度要求,遵循的是“渐进明细”的原则。在这个过程中,阶段性的交付成果并不是最终可用的交付成果,真正可用的成果,就是最后的施工图,其它都是过程。按照这样的设计过程,每一个阶段解决的问题是缺少细节的,在过去建筑仅仅考虑“经济、适用”的前提下,是可以不去考虑的。但在今天,建筑设计要求综合最优,前期对细节的忽略,有可能直接导致成果的颠覆。很多项目最后决算时,会吃惊地发现大大超出初步设计的概算,这里面固然有概算过粗的问题,但是初步设计成果过粗,是不是也是重要的原因呢?如果是这样,那么这样的流程究竟有多少价值呢?同时,这样的过程是不可逆的,一旦进入下一个阶段,如果要重新回到上一个阶段,需要付出更大的代价——时间、人力资源,甚至资金成本。

很多时候我们都发现,在设计早期,客户其实提不出过多的建议和意见,尤其是一些技术性的问题,如:结构选型、设备系统配置。然而在设计成果完成尤其施工图提交后,很多客户如梦方醒,提出颠覆性修改要求。这当然是因为客户不专业,但客户必须要专业吗?在看到完整的图纸之前,许多客户根本无法想象最终建造需要付出多大代价,更也不清楚最终建成的效果,这就是传统项目管理最怕的一点——需求不明确。

敏捷方法强调迭代的概念。简单说来,就是原型交付,在原型的基础上升级迭代。每一个版本所产出的产品,都是有着基本功能的可用的产品,迭代只是完善和升级。那么,我们可不可以这样设想:每一版完成的设计图纸,都是全专业的,有细节的,可以在此基础上计算成本、考虑施工组织、材料采购。我们不再关注简单的图纸设计深度,而是考虑这一版图纸是否可以让客户了解建筑整体的效果,成本构成、运营维护要求等。通过“原型图纸”,探查客户的需求。客户参与到产品设计过程中,每一次迭代都欢迎客户提出变更,每一版图纸,都是一次完整的升级。设计的每一个细节都是经过推敲的,每一个技术方案的选定,都有数据支撑。在一次次迭代过后,最终趋于设计师和客户都想要的结果。今天,BIM技术日趋成熟,三维协同设计本身就已经打破了传统设计的专业界限和阶段成果限制。可以说,借助这样的技术手段,使客户参与到设计的每一次迭代,向客户呈现完整的产品,在技术上将不再有不可逾越的障碍。

有的设计企业按照加工制造业的模式管理设计公司,有严格的、标准化的流程体系和质量管控,甚至图纸也标准化。这样做当然有莫大的好处,设计质量稳定,图纸标准化程度高,一次成图速度快。然而这样的模式管理成本很高,一次标准更新将会付出较大代价,是对变更抗性最大的。最大的问题还在于它是要求客户来适应自己的,自己的流程、质量标准、产品设计标准,很多时候可能交出了一个质量好的设计成果,但并不一定能够实现客户价值的最大化。在这样的过程是观念上的一个偏差:设计是交付符合质量要求的图纸的。然而事实却是——设计最终交付的,不是图纸,而是建成后可以使用的建筑。

传统的设计项目管理往往自上而下,总工定案,专业负责人盯细节,基层设计人员只管画图。在设计过程中,“画图”成为关键词,而不是“设计”。可能有70%的时间用于画图,而考虑设计的时间往往不到30%。这种模式在今天似乎越来越不适用。项目团队成员是追求个性和自我价值的,也希望能够在项目中学到知识和经验,获得成就感。但自上而下的管理,使得团队大多数成员只需要执行,甚至只参与局部的设计,这对于成员的成长也是不利的,更不利于设计企业整体水平的提高。

在传统的设计管理中,团队成员的信息交换,通过过程中的质量管理文件,阶段性的专业互提资料完成,甚至在部分企业,完全通过局域网和互联网完成。这样的方法是“流水线生产”方法,工序和工序之间天然存在接口和界面。设计本应是整合的结果,却在这样的思路下,形成了专业壁垒,造成专业矛盾,反而降低效率。

敏捷方法以团队为核心,强调授权、自我管理、面对面沟通,构建学习型的团队。敏捷团队中,团队自己决定工作如何组织开展,自己制定工作规则,每一个成员都可以对产品提出建议,团队保持密切的沟通和快速的信息交换。所有团队成员都清楚项目进展和阶段目标要求,通过“每日站会”,及时总结工作中存在的问题,及时协调和校正。在一个迭代周期完成后,团队召开回顾检讨会议,共同检视及调整做事方法、协同合方式,以在下一个周期延续或修正。这些过程中,团队成员充分参与,不存在“信息孤岛”的问题,打破了专业界限,相互学习和支持,也始终了解产品特性,不再被隔离在某一个局部,学会站在全局看问题,因而获得了较大的成长空间。那么,设计团队是否也可以用这样的方法呢?因为项目的独特性,团队成员有条件根据项目的需要而决定工作方法,过程中自我控制,打破专业壁垒,充分沟通和交流,及时总结回顾,从而在设计过程中真正获得创造的乐趣。

 

上述仅是个人对于敏捷理念理解和应用的一些初步想法,关于敏捷方法在设计项目中的应用,这篇文章应该仅仅是个开始。

如何有效率、有效果地完成设计,为客户创造价值,一定还有很多路径。这里所探讨的仅仅是其中一种可能性,欢迎批评指正。也欢迎所有对设计管理有思考、有追求的同仁,共同探讨。

 

©2016 昆明新正东阳建筑工程设计有限公司   滇ICP备14000856号. 技术支持 云南实创电子