Технический долг по аналитике — это любая отсутствующая документация на функционал, который поставлен в промышленную среду. Давайте разберемся на простом жизненном примере, почему важно не копить техдолг? Представьте, вы прошли ТО для машины, вам написали лист рекомендаций по ремонту, которые уберегут вас в будущем от проблем и сделают поездку на машине комфортной, но вы отложили эти работы на потом. Однажды в летний жаркий день вы едете на машине в отпуск, и кондиционер не охлаждает, пошел ливень, а дворники не помогают, да еще порвался ремень ГРМ, и машина остановилась. Выглядит как самый худший день в жизни, остается только ждать эвакуатор. В этот момент вы вспоминаете: «Почему я не выполнил сразу работы по ремонту, а отложил их подальше?!» Вот и с техдолгом похожая ситуация. «Снежный ком» документов Вам срочно нужно внедрить новый функционал, но от вас просят документацию. Если бы вы раньше её написали, то всего пару строчек нового функционала — и документ готов, но сейчас вам нужно написать полноценный документ на весь функционал, что ранее не был описан. Отсутствие экспертизы для будущих поколений Вы пришли в новую команду, документация есть, но не на все, а аналитик, который все это проектировал, уволился. Теперь вы как первопроходец тратите немало времени, чтобы разобраться в том, как это все работает и как это дорабатывать. Время разбора дефектов увеличивается Наташ, мы все уронили! Поддержка просит разобраться в дефекте, разработчик в отпуске, а документации нет? Становится грустно в такой ситуации. Но её бы не было, если писать документацию вовремя и не копить техдолг. Негатив от команды Разработчики пишут код со слов, тестирование тестирует со слов, а бизнес думал, что его слова по-другому поняли. В итоге функционал работает, но когда начинаешь разбираться, как работает, появляется много вопросов, и нет документации, где посмотреть Нашей дружной командой аналитиков Альфа-Банка мы понимали, что надо что-то делать! Одно дело понимать, а другое выстроить процесс, чтобы техдолг не копился, а закрывался, и мы приступили. Собрали рабочую группу, в которую включили аналитиков от каждого направления из центра компетенций аналитики удаленных каналов доступа (Альфа-Мобайл, Сайт, Интернет-банк и др); Определили, что такое техдолг, и как выбирать приоритеты; Расписали процесс ведения, включения задач по техдолгу в бэклог, ответственных; Сформулировали ситуации, сигнализирующие, что техдолг растет, и определили, что делать в таких случаях; Собрали задачи по техдолгу в рамках направлений. Отсутствующей документации (техдолга) может быть много, поэтому важно правильно выставить приоритет у задач. Мы выбрали основные приоритеты: важный, средний, низкий. Приоритет Ситуация важный На функционал в промышленной среде нет документации; Нет архитектурной документации, которая блокирует поставку функционала в прод. средний Существующий документ не соответствует актуальному шаблону. Документ сложно читать  и понимать. Приоритет выбирается совместно с техлидом аналитика; неактуальный; не полностью описывает функционал в проде. низкий Существующий документ не соответствует актуальному шаблону. Документ понятен, но визуально выглядит иначе. Приоритет выбирается совместно с техлидом аналитика; Нет архитектурной документации, которая не блокирует выкат в прод функционала. В качестве инструмента ведения техдолга мы выбрали Jira, так как она позволяет визуализировать количество техдолга, отследить процент закрытия и увеличения задач по нему. Добавить задачу по техдолгу аналитики может любой член команды или сопровождение. За выполнением задач по техдолгу следит техлид аналитиков. Поле Как заполнить Тип task Приоритет Важный Средний Низкий Метки Техдолг_команда_функциональность Тема [вид функциональности] Описание работ Вид функциональности: фронт, сервис (имя), архитектура Описание работ: написать/актуализировать Описание Цель: опционально, когда необходимо обосновать приоритет Что: написать/актуализировать + ссылки на материалы Dod: аналитика подготовлена, согласована В качестве инструкции и отчета в первой версии создали статью в Confluence с содержанием: Что такое техдолг Почему важно закрывать техдолг Ответственность Кто добавляет задачи Как задача попадает в техдолг Процесс работы с техдолгом Как ведем задачи в Jira Кто закрывает техдолг Кто следит за выполнением Список задач Срез задач на 2 квартал 2021 Список задач собрали автоматически с помощью макроса «Jira» и настроили возможность фильтрации с помощью макроса «Фильтр таблиц». Для визуального отображение использовали макрос «Jira круговая диаграмма» Ситуация 1 — растет тех.долг Решение: Бери задачи по техдолгу в работу в sprint. Ситуация 2 — увеличилось время разборов дефектов из-за отсутствия документации Решение: Выполняй задачи по техдолгу. Ситуация 3 — хочешь повысить оценку компетенций для продвижения по карьерной лестнице Решение: Помогай другим направлениям закрывать их техдолг. Проблему накопления техдолга мы сначала отрицали. Потом злились, что документации нет, когда она так нужна. Торговались сами с собой: завтра, с понедельника обязательно все сделаю. Потом ушли в депрессию, что не хватало времени на задачи техдолгу. Дальше должно было быть смирение, как в 5 стадиях принятия проблемы, но нет, мы стали действовать. Каждый аналитик из рабочей группы в рамках своего направления: создал задачи в JIRA по текущему техдолгу; написал статью по шаблону. Пример статьи был выше; обсудил с аналитиками из своего направления, кто какие задачи возьмет в работу в следующем квартале; рассказал аналитикам из своего направления, какие правила заведения задач по техдолгу. Прошло не так много времени, но мы уже видим положительную динамику по закрытию задач по техдолгу аналитики, потому что теперь появилась прозрачность и понимание объемов задач. Это процесс легко могут переиспользовать другие направления: разработчики, тестирование. Следующим шагом будет настройка dashboard для мониторинга прироста задач по техдолгу.  Предупрежден — значит вооружен. А на какой стадии принятия вы, в вашей компании есть тех.долг по аналитике? Возможно, у вас есть средство, которое позволяет не иметь тех.долга и быстро доставлять изменения до промышленной среды вместе с документацией? Solution архитектор