更改管理以实现更快乐的ITSM

我在整个职业生涯中都曾在几家公司工作,从大型零售连锁店到仍具有“创业”心态的小型公司。 在采用Waterfall和Agile工作方法的企业中,从每天部署变更的企业到每月(甚至每季度)部署的企业。

关于如何看待成功的变更管理工作以及我认为应该进行软件变更的频率以及这些因素对ITSM的影响,我有一些想法。

首先,我们必须接受两件事。

  1. 改变是不可避免的-我们必须做出改变以向前迈进。 无论我们是要修复错误,开发新功能还是要还清一些技术债务(lol)。 我们必须做出改变以实现所有这些目标。 不进行更改就意味着没有改进,您应该始终在寻求改进。
  2. 事故不可能停止,对不起。 这是个坏消息。 生活中的确定性胜于死亡和税负。 第三是事件。 出问题。 测试中遗漏一些东西。 人为错误永远发生。 无论您构建了多少自动化,测试,连续交付和弹性,事件都可以。 会的 。 发生。

现在,我们已经建立了宇宙的这两个主要定律,我认为有些事情对于创建现代且精益的变更管理流程非常重要,该流程可使工程师感到满意并提供出色的服务。

  1. 正确掌握基础知识
    任何变更管理方法学都需要做一些基本的事情,然后才能在我的书中确定。
    他们是…创建并共享您的变更管理流程,确保所有变更都遵循变更管理流程(实验室>阶段>生产)(请不要直接部署任何变更以供实时使用),并使用适当的信息记录您的所有变更(我喜欢JIRA) (谁进行了更改,更改是什么以及如何回滚更改)。 这些为变更管理奠定了良好的基础。
  2. 经常进行小的迭代更改。
    这不是一个新主意。 但是,尽管如此,一些思想流派认为更改应该按固定的(有时是不定期的)时间间隔进行捆绑和部署。
    以这种方式对变更进行分组的问题在于,这些变更通常是要部署的大型工作,们通常未经过针对其他变更的测试,并且经常破坏变更。 一些公司甚至会进行定期维护以进行这些更改,这通常意味着停机(ewww)。 另外,您如何确定是哪个部署的更改导致了该事件?
    以我的经验,我们应该经常进行小的,迭代的更改。 为什么? 我们可以很容易地测试它们。 它们是非常可预测的。 它们对业务和客户的破坏力都较小。 最终,更改越小,风险就越小,影响也就越小。 同样,当您进行迭代更改时,您可能会发现更多更改。
  3. 较小的更改使您的工程师更快乐
    工程师并没有大多数公司似乎想的那么难。 他们希望获得高薪,他们希望感到有力量,并且希望自己能有所作为。 快速安全地部署更改的能力意味着进行更改的“满足循环”要短得多。 修复错误并能够快速部署该修复程序令人非常满意。
    为您的工程师进行生产变更所需的时间越长,他们觉得自己能够在您的业务中发挥作用的能力就越少,他们离开公司的可能性就越大。
  4. 监控您所做的更改
    进行更改时,任何更改请求都应定义接受标准。 进行更改后,操作团队应寻找什么行为? 如果没有足够的指标或监控,请添加它们。 您应该能够解释和说明更改如何改善了您的软件/硬件/其他方面。
  5. 良好的事件管理支持良好的变更管理
    如我以前的博文所述,由于事件的不可避免性,因此存在良好的事件管理流程。 我们认为事件会发生,并已采取措施在事情确实出错时采取措施。
    我的意思是给您的工程师犯错误的自由。 不要怪 了解如何停止犯同样的错误并继续前进。
  6. 不断改进变更管理
    定期检查您的变更管理过程。 使用变更管理软件中的报告来报告统计信息,例如…
    *进行了多少更改
    *回滚了多少(%)
    *引入多少生产缺陷
    *生产缺陷的最常见原因是什么
    *多少变化是由于人为错误导致的问题
    * 飞行时间
    * 还有很多…
    这里的重点是,在接受事件会发生的同时,我们还必须尽一切努力阻止事件发生,同时保持健康的变更管理节奏。 同样,请确保您的变更管理流程对您有用。
    回顾指标,KPI和CSF有助于改善变更管理。
  7. 奖金项目-与支持团队/服务台沟通
    大家好,如果您要对服务或平台进行相当大的风险或较大的更改,请告知您的支持团队。 一旦做出更改,他们将成为从客户那里收到问题的人。 给那些家伙一个提示的好举止。 您将为他们提供巨大的帮助。

总而言之,以我的经验为基础,伟大的变更管理过程建立在能够以非常快的速度计划和实施变更的能力上,并且得到了经常与之沟通的企业的支持,并且理解当事情出错时,我们仍然是一支既相互支持又相互挑战的团队。
这对您来说真的吗? 如果是这样,请在下面给我留言!