如何创建系统描述模板并开始使用它

当一家IT公司雇用6名员工观看一个系统并在场外讨论时,似乎不需要系统描述和文档。但是,当已经有100多个系统时,您将不得不进行描述。毕竟,考虑不周的UI更改可能会停止创建订单。我们创建了一个统一的系统描述模板,以使文档尽可能有用。



我叫Alexandra Kamzeeva,我已经担任系统分析师9年了,其中在Lamoda工作了3.5年。我阅读了很多,分析了当前文档并创建了一个新文档。在我的工作中,我总是构造信息并使其尽可能地方便。



图片



良好的系统描述的优点是:



  • 与非结构化描述相比,可以帮助您更快,更轻松地找到所需的信息;
  • 降低项目失败的风险;
  • 使员工更容易上岗。


我们为任何团队都可以使用的描述制作了模板。在本文中,我将通过示例向您介绍促使我们创建系统描述模板的原因,创建历史以及在Lamoda中现在如何使用它。



什么是模板,为什么需要它



首先,我将描述对模式的理解。假装我需要在杂乱的房间里找到一辆小型汽车。我不能应付这个事实。但是我可以不小心踩到乐高玩具。



现在,让我们想象一下所有玩具都放置在原处并进行了排序。我可以提前看到所有汽车都在哪个盒子里,我会发现我需要的更快,更容易,并且我不会浪费我的心。



文档也是如此。模板就是这样的命令。我们已经建立了一个框架来描述任何团队都可以使用的系统。



我们在什么条件下处理文档



Lamoda拥有100多个系统,可自动执行订单交付,联络中心,仓库,照相馆以及其他运营和业务流程。300多名工程师参与了开发和支持。他们中的任何一个都可能需要描述这100个系统中的任何一个。



每个团队在Confluence中的单独空间中独立描述他们的系统。技术负责人必须包含在文档中,因为他必须记录信息。而且,该系统由活跃的测试人员和开发人员描述,他们为失去知识而感到抱歉。而且,当然是分析师,因为文档是我们的主要工具之一。



这种自由似乎导致了混乱。但是,事实并非如此,因为我们有一种公司文化:对文档负责的态度,开放的知识共享,记录项目和系统工件的习惯。这项传统之所以得到发展,部分原因是项目失败。这些事件向开发团队证明了记录系统的流程和功能的重要性。



在下面,我将重点介绍几种情况,在这些情况下,令人困惑的文档或缺乏文档会导致问题。



只需添加两个按钮



促使我们创建模板的第一个问题-我们没有对某些系统的描述,这导致了故障和改进。



我们有一个自助订单管理(SOM)项目。我们决定在客户的个人帐户中添加两个按钮:“转移交货日期”和“取消订单”。在此之前,客户只能通过致电联系中心取消或重新安排订单。显然,一些买家没有时间或不愿与运营商进行沟通。结果,销售代表可能带来不必要的订单,或者在家中找不到客户。在这种情况下,拉莫达承担费用。该项目是必要且重要的。



图片



似乎要添加两个按钮!实际上,在四个系统中它们背后都有很多逻辑。更改订单要经过处理系统-一个巨大的整体,您可以在其中触摸某物,然后在另一位置拍摄。不幸的是,文档中没有描述她的工作的精妙之处,他们在项目设计期间没有注意这一点。发布后,按钮无法正常工作,因此被回滚。结果,该项目花费了六个月的时间,而不是两个人月。



当然,我们得到此结果的原因不仅仅是缺少文档。但是,如果我们对取消和转移订单的过程有清晰的描述,那么结果可能会有所不同。



复杂的入职



导致我们创建模板的第二个问题是入职的复杂性。我来为参与订单处理系统的团队工作。为了沉浸,我阅读了系统空间中的文档,并在三个部分中找到了对系统主要本质(订单状态)的三种不同描述。



在这种情况下,无法使入门更加容易。这些文档无助于将知识转移给以前没有遇到过我们系统的同事。



空白板岩问题



模板创建的第三个前提条件是空白问题。对于每个新系统,技术负责人必须从头开始留出适当的空间。技术负责人会考虑创建哪些部分。在创建模板之前,该员工研究了其他空间,并查看了使用了哪些部分,这些部分将对他的系统有用。这过去需要很长时间。



我们如何创建模板以及发生了什么



每周,系统分析员都会站起来讨论不仅在项目上遇到的问题。同事们不止一次抱怨抱怨查找信息和理解各种系统的空间是多么困难。由于我们因此而不断燃烧,因此我们决定亲自研究连接的系统。然后很清楚该怎么做。



首先,我们确定了好的模板的属性:



  1. .
  2. . , , . , . .
  3. . , , , .
  4. .


接下来,我们分析了各种系统的当前描述并确定了常见的部分:



图片

在项目和功能部分中,有用于开发项目的规范。 “开发”和“质量检查”部分包含针对开发和测试人员的特定信息。在事件部分中,描述了系统中发生的事件及其解决方案。



我们在非正式会议上与其他同事共享了模板的想法(在厨房中的午餐,站立姿势,与您定期交谈的团队邻居),并创建了一个志愿者工作组。他们是不同能力的代表:两名经理,三名技术主管和两名测试员。他们在模板中添加了以下部分:



图片



接下来,我们与具有广泛能力的同事一起测试了系统描述模板:IT部门负责人,经验丰富的技术主管和大型集成项目的测试主管。他们最终添加了一些更有用的部分:



图片



检查模板的质量



我们对照Lamoda中对好的模板的定义检查了结果文档:



  1. 它可以帮助您更快,更轻松地找到所需的信息。我们有一个方便的结构:我沿着树走着,了解了什么位于何处。如果您需要有关系统流程的信息(例如,取消订单),那么我将转到“主要流程的说明”。
  2. 由于分区的原子性,系统信息不会重复。例如,您可以在一个部分中描述可打印的内容,然后在“主要过程的描述”部分中对其进行引用,以使信息不再重复。
  3. . Lamoda, . , -. — .
  4. . .




我们制作了一个不错的模板来描述Lamoda系统。我希望这对其他公司也有用。我特别想强调以下三个部分:



系统主要过程的描述。是的,显然需要此部分。但是由于某些原因,它并不总是像取消和转移按钮一样存在。如果我们提前描述了取消和重新安排流程,则可以减少项目失败的风险。



检查清单-提醒常规过程中最重要的部分。例如,在付款方式管理系统的说明中,我们有一个“用于连接新付款方式的清单”。它说,我们必须与会计部门,联络中心,交付部门和其他业务部门协调增加或更改付款方式。



一旦我们忘记通知联系中心有关付款方式的变化。当客户致电我们的联络中心并询问有关问题时,接线员什么也没说。这导致联络中心和负责付款方式的开发团队之间发生冲突。发生此事件后,我们为关键项目启动,连接新合作伙伴等创建清单。



太空首页-包含有关为何需要此系统,团队和利益相关者组成的信息的部分。我们必须与利益相关者协调系统变更和开发资源。因此,仅通过查看Confluence即可获取此信息非常好。



在此处,我们指示有关团队组成的信息,以便了解与该系统问题联系的人。它还可以帮助初学者头部浮肿。当新员工可以监视刚刚与他交谈的人,这个人是谁,他的角色是什么以及他的名字是什么时,这是很棒的。



我如何开始在系统上使用模板



  1. 首先,我创建了模板的必填部分,但未填写。这很容易,花费了不超过30分钟。
  2. 然后最困难的事情是:我们与技术负责人定期召开会议,在会议上我们开始分析系统文档。在第一次会议上,我们将当前页面分为三堆。


我们把所有无关紧要的东西都送到了第一堆。我们删除了这些页面或将它们发送到档案中。



第二堆是必要的,但无关紧要。我们将页面标记为不相关,在Jira中创建了一个任务,然后根据我们的待办事项更新了此信息。



第三堆是最简单的。当一切都清楚了之后,这些部分就有意义了-我们只是将它们移到了正确的位置。



图片



在这些会议之前,过程和体系结构的描述,测试人员和开发人员的注释以及事件分散在整个空间中。也没有主页。



在6个小时的会议中,我们取得了出色的成绩。从混乱中,我们形成了结构和秩序。现在,您可以了解在哪里可以找到流程的描述,有关体系结构和事件的信息。重要的是,我们现在有一个主页。这里写了为什么需要一个订单处理系统以及谁是它的利益相关者。



我们的大型系统涉及几乎所有业务领域。但是我们以前没有自己的利益相关者。在做主页时,我们与首席技术官讨论了与谁协调系统变更的问题。因此,确定了一位同事,他将改进工作列为优先事项。现在,创建主页导致利益相关者的出现似乎是一个有趣的事实。



我们如何分发模板



使用该模板的其他分析人员也收到了类似的结果,他们按照自己的指示实施了该模板。因此,我们涵盖了已积极参与许多集成项目的大多数系统。



我们有一些团队,这些团队的系统经常参与集成项目,但是对它们的描述不够。通常需要文档,因此无需出售该想法。



我们展示了将模板应用于此类团队的技术主管和经理的成功经验。根据我们的示例,一些团队自行整理了文档,其他团队则向分析师寻求帮助。



关于模板的反馈



我们的模板不是强制性或强制性系统说明。如果需要模板,同事将以模板为基础,并对其进行编辑以适合他们的需求。例如,如果系统主要包含交换,则它们将交换从小节转移到小节。



我们所有系统的描述都不同,但是总体结构和总体逻辑仍然保留。现在,我们可以更轻松地找到有关系统包含哪些流程,系统体系结构等的信息。



在Lamoda,我们喜欢分享知识。我们有大型的集成项目可以激发这一点。我们发送指向最新系统描述的链接,而同事会收到必要的信息,而不会对已经加载的技术线索产生其他问题。



创建模板2年后,我采访了同事并收到了大多数人的好评。他们使用模板,根据需要编辑结构。



但是也有人认为我们不需要文档和模板。基本上,这是那些系统的团队的理由,在这些系统中,现在没有紧迫的要求来记录某些东西。



他们在几乎不变的系统上工作:没有集成项目,不需要将这些系统告诉其他同事,因此也没有文档的愿望。



我认为在开始一个大型项目之前,我们的文化和颠簸会提醒您记录主要过程,并且它们会改变主意。



给自己和想重复我们道路的人的建议



  1. , , , , . , .
  2. . , . , .
  3. , , . : , , . . , .



All Articles