Когда в ИТ-компании работают 6 человек, которые работают над одной системой и обсуждают ее в кулуарах, описание системы и документация кажутся излишними.
Но когда систем уже более 100, без описания обойтись невозможно.
Ведь непродуманное изменение пользовательского интерфейса может остановить создание заказов.
Мы создали единый шаблон описания системы, чтобы сделать документацию максимально полезной.
Меня зовут Александра Камзеева, работаю системным аналитиком 9 лет, из них 3,5 года в Lamoda. Я много читаю, анализирую текущую документацию и создаю новую.
В своей работе я всегда структурирую информацию и делаю ее максимально удобной.
Преимущества хорошего описания системы:
- помогает найти нужную информацию быстрее и проще, чем в неструктурированном описании;
- снижает риск провала проекта;
- облегчает адаптацию сотрудников.
В этой статье я расскажу на примерах, что побудило нас создать шаблон описания системы, историю его создания и то, как он сейчас используется в Lamoda. Что такое шаблон и зачем он нужен? Для начала опишу свое понимание паттерна.
Представим, что мне нужно найти в неубранной комнате небольшую пишущую машинку.
Не факт, что я справлюсь.
Но я могу случайно наступить на деталь Лего.
А теперь представьте, что все игрушки разложены по местам и рассортированы.
Я заранее вижу, в каком боксе все машины, быстрее, проще найду ту, которая мне нужна, и не буду тратить на это нервы.
То же самое и с документацией.
Шаблон — это заказ.
Мы создали структуру для описания системы, которую может использовать любая команда.
На каких условиях мы работаем с документацией? У Lamoda более 100 систем, которые автоматизируют доставку заказов, контакт-центр, склад, фотостудию и другие операционные и бизнес-процессы.
В разработке и поддержке задействовано более 300 инженеров.
Любому из них может понадобиться описание любой из этих 100 систем.
Каждая команда самостоятельно описывает свою систему в отдельном пространстве в Confluence. Технический руководитель должен участвовать в документации, потому что он обязан фиксировать информацию.
Систему описывают и активные тестировщики и разработчики, которым жаль просто потерять полученные знания.
И естественно, аналитики, поскольку документация – один из наших основных инструментов.
Может показаться, что эта свобода ведет к хаосу.
Но это не так, ведь у нас корпоративная культура: ответственное отношение к документации, открытый обмен знаниями, привычка фиксировать проектные и системные артефакты.
Эта традиция сложилась отчасти благодаря неудачным проектам.
Эти инциденты доказали командам разработчиков, насколько важно документировать системные процессы и функциональность.
Ниже я расскажу о нескольких случаях, когда путаница или отсутствие документации приводили к проблемам.
Просто добавьте две кнопки Первая проблема, которая побудила нас создать шаблон, заключалась в том, что у нас не было описания некоторых систем, что приводило к сбоям и доработкам.
У нас был проект «Управление самостоятельным заказом» (SOM).
Мы решили добавить в личный кабинет клиента две кнопки: «Изменить дату доставки» и «Отменить заказ».
Раньше клиент мог отменить или перенести заказ, только позвонив в контакт-центр.
Понятно, что у некоторых клиентов не было времени и желания общаться с оператором.
В результате торговый представитель мог принести ненужный заказ или не застать клиента дома.
В таких случаях расходы несет Lamoda. Проект был нужен и важен.
Казалось бы, добавление двух кнопок! На самом деле в четырех системах за ними стояло много логики.
Изменение заказа проходит через систему обработки — огромный монолит, где можно что-то потрогать в одном месте, а выстрелит в другом.
К сожалению, тонкости его работы в документации не описаны; при разработке проекта этому не было уделено внимания.
После релиза кнопки не заработали как положено и его откатили.
В результате вместо двух человеко-месяцев на этот проект ушло шесть месяцев.
Конечно, такой результат мы получили не только из-за отсутствия документации.
Но если бы у нас было четкое описание процессов отмены и переноса заказа, то, возможно, результат был бы другим.
Комплексный онбординг Вторая проблема, которая привела нас к созданию шаблона, — сложность онбординга.
Я пришел работать в команду, которая работала над системой обработки заказов.
Для погружения я прочитал документацию в пространстве системы и в трех разделах нашел три разных описания основной сути нашей системы — статуса заказа.
В данном случае облегчить адаптацию не удалось.
Такая документация не помогла передать знания коллегам, которые раньше не сталкивались с нашей системой.
Проблема чистого листа Третье необходимое условие для создания шаблона — проблема чистого листа.
Для каждой новой системы технический руководитель должен сделать соответствующее пространство с нуля.
Технический руководитель думает, какие разделы стоит создать.
Прежде чем создать шаблон, сотрудник изучил другие пространства и посмотрел, какие разделы используются и будут полезны для его системы.
Раньше это занимало много времени.
Как мы создавали шаблон и что получилось Каждую неделю системные аналитики проводят стендап и обсуждают вопросы, возникающие в проектах и за их пределами.
И не раз коллеги жаловались на то, как сложно найти информацию и разобраться в пространствах различных систем.
Поскольку нас это постоянно обжигало, мы решили взять в свои руки описание систем, к которым мы привязаны.
И тогда будет понятно, что делать.
Сначала мы определили характеристики хорошего шаблона:
- Хороший шаблон помогает быстрее и проще найти нужную информацию за счет структуры описания системы.
- Информация в системе не дублируется.
Конечно, это достигается не только документом, но и культурой документирования.
Вы можете создать атомарность разделов в шаблоне, чтобы ссылаться на них.
Это не даст лишнего повода для дублирования информации.
- Хороший шаблон применим к большинству систем.
Да, для отдельной системы это, скорее всего, будет избыточно, но таким образом можно охватить если не все случаи, то большинство.
- Он помогает сохранить все необходимое и напоминает о важном.
В разделе «Проекты и возможности» были спецификации для разработки проекта.
Разделы «Разработка» и «QA» содержали конкретную информацию для разработчиков и тестировщиков.
В разделе «Инциденты» описывались инциденты, произошедшие в системе, и пути их решения.
Мы поделились идеей шаблона с другими коллегами на неформальных встречах (ужинах на кухне, стендапах, соседних командах, с которыми время от времени общаемся) и создали рабочую группу волонтёров.
Это были представители разных компетенций: два менеджера, три технических руководителя и два тестировщика.
В шаблон добавлены следующие разделы: 
Далее мы протестировали шаблон описания системы с коллегами с широкой компетенцией: руководителями ИТ-подразделений, опытными техническими руководителями и тест-лидами крупных интеграционных проектов.
В результате добавили еще несколько полезных разделов: 
Проверка качества шаблона
Мы проверили полученный документ на наличие нашего определения хорошего шаблона в Lamoda:
- Это поможет вам быстрее и проще найти нужную информацию.
У нас удобная структура: я передвигаюсь по дереву и понимаю, что где.
Если вам нужна информация о системных процессах (например, отмена заказа), то я иду в «Описание основных процессов».
- Информация о системе не дублируется из-за атомарности разделов.
Например, вы можете описать печатные формы в одном разделе, а затем ссылаться на него из раздела «Описание основных процессов», чтобы избежать повторения информации.
- Хороший шаблон применим к большинству систем.
Наш шаблон учитывает разделы для всех систем Lamoda, поэтому структура описания адаптирована под каждую систему.
Например, система обработки заказов не использует описания пользовательских интерфейсов или ссылки на исследования AV-тестирования.
А для сайта это два ключевых раздела.
- Хороший шаблон поможет вам ничего не забыть.
Я расскажу об этом более подробно в следующей главе.
Особо хочу выделить следующие три раздела: Описание основных процессов системы .
Да, кажется очевидным, что этот раздел необходим.
Но почему-то она не всегда есть, как это было в нашем примере с кнопками отмены и переноса заказа.
Если бы мы заранее описали процессы отмены и переноса заказа, риск провала проекта был бы снижен.
Контрольные списки – раздел, который напоминает вам о самом важном в обычном процессе.
Например, у нас в описании системы управления способами оплаты есть «Чек-лист по подключению нового способа оплаты».
Там указано, что мы должны согласовывать добавление или изменение способа оплаты с бухгалтерией, контакт-центром, службой доставки и другими бизнес-отделами.
Однажды мы забыли сообщить в контакт-центр об изменении способа оплаты.
А когда клиент позвонил в наш контакт-центр и спросил об этом, оператор ничего не смог сказать.
Это привело к конфликту между контакт-центром и командой разработчиков, ответственной за способы оплаты.
После этого инцидента мы составляем чек-листы по запускам ключевых проектов, подключению новых партнёров и т.д. Домашняя страница космоса — раздел с информацией о том, зачем нужна эта система, о составе команды и стейкхолдерах.
Мы должны координировать системные изменения и ресурсы развития с заинтересованными сторонами.
Так что здорово, что вы можете получить эту информацию, просто заглянув в Confluence. Здесь же указываем информацию о составе команды, чтобы понимать, к кому обращаться с вопросами по системе.
Это также помогает новичкам с опухшей головой.
Замечательно, когда новый сотрудник может видеть, с кем он только что разговаривал, кто этот человек, какая у него роль и как его зовут. Как я начал использовать шаблон в своей системе
- Первым делом я создал необходимые разделы шаблона без заполнения.
Это было легко и заняло не более 30 минут.
- Дальше было самое сложное: мы назначили регулярные встречи с техническим руководителем, на которых начали анализировать документацию нашей системы.
На первой встрече мы разложили текущие страницы на три стопки.
Мы удалили эти страницы или отправили их в архив.
Вторая стопка необходима, но неактуальна.
Мы отметили страницы как нерелевантные, создали проблему в Jira, а затем обновили эту информацию в соответствии с нашим бэклогом.
Третья стопка – самая простая.
Когда все понятно, разделы актуальны – мы просто переместили их в нужное место.
Перед этими встречами по пространству хаотично разбросаны описания процессов и архитектуры, заметки тестировщиков и разработчиков, инциденты.
Домашней страницы тоже не было.
За 6 часов встреч мы получили отличный результат. Из хаоса мы сформировали структуру и порядок.
Теперь вы можете понять, где найти описания процессов, информацию об архитектуре и инцидентах.
И самое главное, у нас теперь есть домашняя страница.
Здесь было написано, зачем нужна система обработки заказов и кто ее заинтересованные стороны.
Наша большая система задействована практически во всех сферах бизнеса.
Но раньше у нас не было своего заинтересованного лица.
Пока мы делали домашнюю страницу, мы обсуждали с техническим директором, с кем согласовывать изменения в системе.
Таким образом был определен коллега, который расставил приоритеты в улучшениях.
Теперь кажется забавным фактом, что создание домашней страницы привело к появлению заинтересованной стороны.
Как мы распространяли шаблон Аналогичные результаты с использованием шаблона получили и другие аналитики, внедрившие его в своих областях.
Таким образом, мы осветили большинство систем, которые активно участвовали во многих интеграционных проектах.
У нас были команды, системы которых часто участвовали в интеграционных проектах, но их описания было недостаточно.
Там обычно ощущали потребность в документации, поэтому продавать идею не было необходимости.
Мы показали успешный опыт использования шаблонов техническим руководителям и менеджерам таких команд. Некоторые команды на нашем примере привели свою документацию в порядок самостоятельно, другие обратились за помощью к аналитикам.
Обратная связь по шаблону Наш шаблон не является принудительным или обязательным описанием системы.
Коллеги берут шаблон за основу, если он им нужен, и редактируют его под свои нужды.
Например, они перемещают биржи из подраздела в раздел, если система в основном состоит из них.
Все наши системы различаются по описанию, но общая структура и общая логика все же сохраняются.
Теперь нам легче найти информацию о том, из каких процессов состоит система, об архитектуре системы и так далее.
Мы в Lamoda любим делиться знаниями.
У нас есть крупные интеграционные проекты, которые мотивируют нас это делать.
Мы отправляем ссылки на актуальные описания систем, и коллеги получают необходимую информацию без дополнительных вопросов к уже занятым техническим лидам.
Спустя 2 года после создания шаблона я опросил своих коллег и получил от большинства хорошие отзывы.
Они используют шаблон, редактируя структуру в соответствии со своими потребностями.
Но есть и люди, которые считают, что нам не нужна документация и шаблон.
В основном это рассуждения команд тех систем, в которых на данный момент нет острой необходимости что-либо документировать.
Они работают над системами, которые практически не меняются: нет интеграционных проектов, нет необходимости рассказывать об этих системах другим коллегам и, соответственно, нет желания их документировать.
Я думаю, что прежде чем приступить к большому проекту, наша культура и упертые люди напомнят нам о необходимости документировать основные процессы, и они изменят свое мнение.
Советы для себя и желающих пойти по нашему пути
- Систематизируем знания о системе, отвечая на вопросы, без какой информации плохо, что указать в первую очередь, какие данные будут наиболее популярны.
Благодаря этому мы расставляем приоритеты и избегаем бесполезных описаний.
- Мы стараемся избегать дублирования информации.
Совет очевиден, но мы все равно постоянно совершаем ошибки.
Мы используем атомарные разделы и атомарные страницы, на которые можно ссылаться из других разделов.
- Мы общаемся с коллегами, делимся опытом, рассказываем о проделанной работе.
И это мотивирует: мы наводим порядок в своих системах, и коллеги из других систем видят, как удобно и быстро находить информацию.
Они начинают структурировать документацию в своих помещениях.
Мы стараемся быть примером, и тогда в нашем хаосе становится немного больше порядка.
-
Тонкие Клиенты, Толстые Серверы
19 Oct, 24 -
Какой Ты, Macbook Air 13,3″ 2013 Г.?
19 Oct, 24 -
Mail.ru Согласился Оплатить Видео
19 Oct, 24 -
Открытие Высокопористого Материала
19 Oct, 24
