解决问题的模式

这是有关建模和增强组织环境中决策制定方式的系列文章的第2部分。 较早的决策模型通常类似于“瞎子和大象”的故事,[1]各自仅描述一种通用且普遍适用的问题解决模式的一个方面。 也许不足为奇的是,知识管理的多个定义也常常被指责仅描述了更大整体的一部分。 通过统一本系列第1部分中描述的各种决策模型的组件,可以将问题解决概括地描述为通过三个相关的活动周期进行。 这些循环中的每个循环都有不同的用途: 信息处理是指收集所需信息以开发问题解决方案或采取行动解决问题 知识处理是指开发解决方案,测试其有效性以及选择性能最佳的解决方案 业务处理是指实际执行的操作,这些操作被确定为解决问题并确定其有效性所必需。 解决问题的模式是分形的 (自相似的),在某种意义上,为解决一个大问题而努力将几乎可以确定几个较小的问题。 解决这些问题将生成问题解决模式的局部迭代,进而可以生成其他问题,依此类推。 例如,识别问题的替代解决方案的动作通常需要解决以下几个信息处理问题(以研究类似的,先前的尝试),知识处理问题(以使其适应实际情况)和业务处理问题(以解决写下与团队沟通的选项)。 大卫·威廉姆斯(David Williams)描述的AKI模型中可以找到决策过程中基础知识和环境转变的简单表示。 在这里,“行动”步骤可以映射到业务处理周期。 知识管理的作用是确定干预的机会,并改善问题解决模式中这些步骤的执行方式。 在接下来的文章中,我们将研究可以有效地应用于KM干预以提高决策质量的方法。 参考:…

关于敏捷的问题:超越软件的敏捷

肯特·麦克唐纳(Kent McDonald) 这是一系列文章的一部分,在这些文章中,我看了一些常见问题并提供了自己的看法。 答案全是我自己的。 因此,尽管我的回答不一定反映敏捷联盟的政策或立场,但我将指向AgileAlliance.org上的一些相关资源,这些资源可以支持我的观点或提供不同的观点。 我们现在是否可以将敏捷思想和相关框架公平地应用于所有业务,软件开发,如果可以的话,可以达到什么程度? 简短的答案是肯定的。 这是更深入的答案: 有很多人在探索如何使敏捷软件开发中体现的思想超越软件开发和IT领​​域。 这些探索大多属于“业务敏捷性”标签。 这些探索倾向于采取以下两种形式之一: 组织其他部门的人员如何需要采用敏捷思维方式才能进行软件开发工作,进而使整个组织变得更加有效 组织的其他部门如何采用敏捷框架(即Scrum)和实践(如定时迭代,独立陈述,回顾) 敏捷联盟启动了业务敏捷性网络研讨会系列,以与社区分享其中的一些探索,并在Agile2017和Agile2018上举办了有关敏捷公司的会议。 向组织传播思想 我建议采用第一种形式,以帮助组织其他部门的人员采用敏捷思维方式。 自从团队开始以敏捷的方式工作以来,这是很有必要的,这早在2001年的《敏捷宣言》的作者的思想中就得到了暗示。 但是,尽管宣言提供了一些具体的想法,但有一个更深层次的主题可以驱动许多(但不是全部)联盟成员。…

如何在团队中建立同理心? 使用情感文化平台后的反思。

2018年10月,我们很荣幸地邀请Riders&Elephants的Jeremy Dean参加我们的奥克兰敏捷教练聚会。 杰里米(Jeremy)向我们介绍了他的情感文化平台,这组卡片有助于在团队和组织中共同创建情感文化。 从那一刻起,我就成为Deck的忠实拥护者,在过去的3-4个月中,几乎每周都在使用它。 使用Deck的方式有多种,其中一种是与团队一起使用,为他们提供了一个讨论他们如何在工作中取得成功的感觉以及他们不想的感觉的空间。 在继续讨论讲习班以及如何使用Deck的细节之前,这里是我在举办讲习班后收到的反馈。 我希望它能向您展示它是多么强大的工具。 在我们离开的那一天,雅库布(Jakub)介绍了一些新的思维方式,以思考如何改善团队行为,以更好地为个人提供支持,并转移所有人共同的需求。 这样做的方式使每个人都乐于为之贡献。 我认为每个人都离开了那一天,感到与团队中其他所有人的联系更加融洽,更加协调。 这从未发生过如此严重的程度。 和 我从来没有像我的队友那么亲近。 突然之间,我们有时间反思自己的情绪,但也可以彼此建立同理心。 迫不及待地想看看它将如何影响我们作为一个团队的日常互动。 我们如何到达那里? 到目前为止,我参加的每个讲习班都有所不同,他们的设计取决于团队的需求,他们的期望以及我们可以在一起度过的时间。 但是,大多数原则和活动都非常相似。…