| UML软件工程组织 | |||
| |
|||
|
|||
确定组织是否真正敏捷的五种方法
2008-01-02 作者：S. E Slack 来源：IBM
每个组织都喜欢吹捧其敏捷性，尽管事态并没有很快发生。当组织宣称是敏捷的，但实际上并非如此时，架构师就陷入了两难的境地。可以使用五个关键预测指标发现组织是否缺乏真正的敏捷性。了解这些预测指标，并获得帮助组织往更敏捷的方向推进的技巧。 组织敏捷性 意味着组织能够快速和敏捷地对内部问题、外部威胁和不断变化的客户需求作出反应。最高管理层喜欢这个术语，因为它使组织听起来很时髦，并且能够处理其发展方向中遇到的所有事情。您也许听过 CEO 或组织中的其他最高级管理人员做过有关敏捷性的激动人心的演讲。他们可能谈到公司如何为充满竞争的行业中出现的所有情况做好了准备。“我们为将来做好了准备！”“我们将全力以赴，以求在竞争中制胜！”“我们公司有最优秀的员工！” 这听起来非常不错，尤其是在它出自最高管理层之口的时候。您可能对这些宣传信以为真，并开始在考虑到敏捷性的情况下着手设计和规划。这并不容易，因为最敏捷的体系结构方法被认为是脆弱的，或者与在企业环境中交付价值的能力不相干。 在该过程中的某个阶段，您也许会开始产生一些挑剔的疑问。也许使公司可以快速开始、停止和转向的新企业设计遭到质疑，因为管理层没有“马上看到对该设计的需要”。也许您遭遇到管理链中这样的人，他们无休止地询问更多详细信息，却假装拥有所不具备的能力。也许从来不允许您与业务单位交谈，因为管理层更喜欢处理那些交流。 不可对这些疑问等闲视之。听他们讲吧，直觉正在告诉您，尽管组织可能谈到敏捷性的话题，却并没有往敏捷性的方向走。要有效地为组织进行设计，您需要获得组织中某种级别的信任。准确了解组织关于敏捷性的立场，可以帮助您在下一个项目过程中节省宝贵的时间和精力。如果发现组织不如应有的那样敏捷，本文中的技巧可以帮助您扭转这种局面。 预测指标 1：食物链位置缺乏敏捷性的最先预测指标之一是架构师在组织食物链中的位置。环顾四周：您是否参与了有关项目预算、优先顺序、资源和项目选择的决策过程？现在或曾经是否有任何人询问过您有关应该实现某个项目的意见？ 如果您对上述所有问题都作否定回答，那么您可能处于组织食物链的最底层。情况很可能是狼群在您四周环绕，只留下残渣碎片等您去处理和实现。 作为架构师，您需要成为狼群中的一员。您的知识和专业经验应该得到重视和发掘，而不是去做其他所有人的扫尾工作。如果认为自己处于组织食物链的最底层，您需要开始改善自己在组织中的地位。也许这意味着在会议期间大胆陈述，或更积极地参与高端组织团队，这些团队与体系结构关系甚少，但是与组织的政策休戚相关。要点在于，您需要提高自己的姿态，以便在考虑组织变更时，体系结构成为其他人首先 想到的事情。 每个项目都有参与者。每个人都想成为英雄，并且都想创造将在组织中带来积极影响的神话。如果您始终处于这些参与者的前列，就可以与他们构建友善关系，这种关系将确保他们在下次考虑某个变更时想到您。如果您处于食物链的最底层，就只能是事后诸葛亮，情况就太糟糕了，因为这样会使组织的敏捷性大打折扣。 预测指标 2：我还是我们？组织中的项目是如何分配的？您是否在团队中工作？如果是，那就太好了。团队协作是强有力的敏捷性预测指标，因为它促进了多个人协作，并且使组织可以发现和实现最有可能的想法。如果项目通常是分配给个人，则您所看到的组织就不如应有的那样敏捷。 这并不是说您没有非常好的想法。但是当人们单独工作时，很容易陷入交流的真空中。单独一个人，您只有自己的想法。在团队环境中，您有自己的想法加上其他每个人的想法。只需倾听其他人所具有的不同体验，即可集思广益并激发创新的火花。 如果组织不相信团队协作，则应该在下一个项目上使用该概念逐步说服管理层。务必小心对待，因为如果管理层以为您是在请求帮助，就可能会认为您很脆弱且无法处理该项目。应该从以下角度逐步表达您的想法：为了最大化参与者价值，您希望尝试一种协作方法，即在项目的初始自由讨论阶段涉及架构师、业务参与者、IT 操作和支持人员，以及其他人员。阐明这种方法应该有助于您更好了解项目的目标、约束和要求。 这种方法使您至少可以获得部分团队协作好处，并将您直接置于前面提到的狼群前面。至少有一些参与者会感激您对他们的特定需要的兴趣，并在后面出现其他项目时想起您。 预测指标 3：缺乏业务联系人您上次与业务单位联系人面谈是在什么时候？我的意思是说，真正 坐下来并与他们讨论其需要、他们的将来预期，以及他们为了使业务更高效地运作所希望看到的更改？ 如果上个月还没有与业务单位会过面，您就没有帮助组织保持敏捷。在实现帮助之前等待业务单位的认可，这并不是真正的敏捷。要保持敏捷，组织必须不断地向上、向下和横向更改。通过与业务单位联系人会面，您可以更好地确定变更可能会在何时发生，以及将会需要多大程度的更改。 当您失去警惕的时候，就很难以受控的方式作出更改。相反，您被迫对情况作出反应，并疲命于纠正突然的更改所导致的问题。即使您目前正在进行设计和构建，与业务单位进行定期、一致的联系也会帮助您密切关注将来。 预测指标 4：文档胜过交流交流是任何敏捷组织中的主要力量。它可以促进敏捷性，因为它存在真正的弹性，让人们更紧密地彼此协作，并整合了来自整个组织中的新想法和信息。但是，存在一个常见的误解，以为组织中的文档越多，交流效果就越好。（请原谅我歇斯底里地嘲笑这种想法。）我曾经在存在这种概念的组织中工作过，尽管文档可能是实现交流的很好手段，但它远远不是真正的交流过程。您可以为希望的所有事物编制文档，但是如果没有人阅读或理解该文档，就不存在交流了。 仅当两方或更多方交换信息并且 各方可以彼此交互以达到对所涉及主题的相互理解时，才会实现真正的交流。这是一项通过学习得来的技能。人类通过口头或书面语言、歌唱、眼睛接触、触摸、手语和身体语言进行交流。甚至动物也以非口头的方式进行交流。 因此，简单的文档编制行为并不意味着您在与任何人交流。您只是在为流程或其他主题编制文档，以便在以后出现问题时可以参考该文档。文档是参考资料或教程，而不是某种形式的交互式交流。它只提供很少或没有提供对话机会，以便消除误解或让人们辩论文档中的内容。如果组织大量依赖文档，这是它轻视敏捷性的很好迹象。真正的敏捷性需要整个组织中不断的交流。 只是因为其他人认为文档可以取代良好的旧式双向交流并不意味着您需要这样做。要改进组织中的敏捷性，应该集中于客户的要求，并以他们能够理解的语言与他们交谈。有关如何在组织中有效地交流的更多信息，请参阅 Obtain approval for your process change recommendations。 预测指标 5：虚线报告您是否注意到许多公司的组织图表充满杂乱的虚线？例如，您可能要正式地向 Joe 报告，但您在组织图表中可能还有指向 Greg、Sandra 和 Vasundhara 的虚线。Joe 处理您的年度审核，但除此之外，除了接收新任务，您很少看到他或与他交谈。您每天更紧密地与其他三个人一起工作。在敏捷性不是管理层的最优先考虑事项的组织中，这种虚线类型的报告系统非常典型。 此类报告过程迫使人们至少间接地向多个人报告。在上述示例中，您要向四个人报告。那样如何能敏捷呢？您受到不同方向的牵引，各个方向具有不同的目标和各不相同的管理风格及预期。您也许让其中一方满意，却不断地惹恼另一方，因为您的表现不符合他们的规定。 当组织认为一个角色等同于一个人时，此类报告非常普遍。他们预期架构师为组织需要的所有一切完成设计。您可能是个天下难找的优秀架构师，但是很难在所有事情方面满足所有人的需要。如果您正在组织中体验到这种情况，这是最难扭转的局面之一，因为如果您抱怨或建议采用新方法，他们就以为您不能胜任多重任务或学习新的技能。 在此情况下，应该与您要向其报告的每个人（无论在组织图表中是否带虚线）坐下来面谈，并阐明各自的预期。这可以帮助您确定是否一个人（举例而言）预期要占用您一半的时间，以及另外三个人是否也做同样的预期。预先建立有关时间限制的边界，要远胜于尝试处理所有事情却谁也无法满足。在初始会谈之后，尽量至少每月与各方会谈一次。越多的人了解您在做什么和各自项目部分的进展情况，您就越有机会让所有各方都满意。要改变组织中的此类糟糕的敏捷性是极其困难的，因此要保护您自己，并保留有关您的时间都花在何处的书面文档。 总结中国古代哲学家老子的谚语已翻译成多种版本。其中一个版本“软件架构师之道 (The Tao of the Software Architect)”提供了有关敏捷性概念的启蒙思想。下面摘录其中一段（建议您阅读完整的翻译版本（请参见参考资料））：“真的旅行者没有固定的计划，没有意向中的目的地。真的艺术家让直觉自由指引他的创作。真的科学家不拘泥于概念，而让思维面对事实。因而，架构师普度众生，不拒绝任何人。他准备利用所有解决方案，而不浪费任何既有成果。” 当您考虑自己的组织是否真正敏捷或者只是讨论敏捷性时，要让自己的思维保持开放以成为敏捷性的化身。结果是您也许会教会组织中的其他人明白一两个道理。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
