Привет! Меня зовут Александр Мошаров, я — ведущий разработчик кластера «Индустриальные процессы». В прошлом году я руководил группой из нескольких десятков разработчиков, расшаренных на множество проектов, и собирал обратную связь от команд. На основе этих данных мы с коллегами разработали универсальный и простой подход к процессам в Jira и Gitlab. Вот уже на протяжение года этот подход облегчает жизнь многим командам разработчиков в «Северсталь-инфокоме». Расскажу, как мы пришли к этой системе и в чем она заключается.
У каждого проекта «Северстали» есть заказчик и разработчики. Также в полном наборе задействованы: руководитель проекта (в 90% проектов), дизайнер, аналитик, тестировщик. Примерно 60% разработчиков работали на проектах с полным набором специалистов и налаженными процессами. Как правило, это средние и крупные проекты, рассчитанные на несколько лет активной разработки, в которых ребята сидят на постоянке. Сегодня не про них, а про остальные 40%, которые заняты на небольших проектах и поддержке. У них-то процессы были не отлажены, из-за чего страдали результаты.
Проект, с которого начались перемены: его «не успевали», но задач не было
Однажды заказчик попросил меня добавить в проект разработчиков, аргументируя просьбу тем, что текущий состав не успеет закончить к нужному времени. Регулярно проводя встречи с командами, я знал, что на этом проекте задач немного, и ребята в свободное время занимались закрытием технического долга, в том числе и низкоприоритетного. Бывали даже ситуации, когда я мог переключить одного члена команды на другую разработку на 2–4 недели, а основной проект от этого не страдал. Как же так получилось, что команда не успевала, но при этом не знала, чем заняться?
Провели несколько встреч и кое-что накопали:
Задачи на этом проекте никто не видел, потому что их попросту не заводили. Они проговаривались устно на встрече с заказчиком.
Команда реализовывала множество «хотелок» заказчика, отклоняясь от технического задания. Причина в том, что всю нужную информацию оперативно удавалось получить только по ним.
Уходило несколько часов (иногда десятки), чтобы понять, для чего в проект была внесена та или иная логика. Это следствие пункта 1, когда задачи не заводятся или к ним нет никакого описания.
Фичи часто переделывались, так как разработчикам приходилось самим додумывать постановки к задаче.
Почему не заводили задачи? Команда не могла договориться о том, кто должен это делать.
Почему не делали постановку к задачам? Собрать подробное описание для задачи — значит ловить заказчика. Но кто должен это делать?
Одной из серьезных проблем, помимо того, что продукт не будет готов в срок, стала растущая токсичность на проекте. Регулярно происходили выяснения отношений и споры, из-за чего решить рабочие вопросы было сложно. Людям было просто не до проекта — все пытались перекинуть ответственность друг на друга. В такой атмосфере развивалась сильная демотивация, ребята просили перевода на другие проекты. Также появлялся негатив к ИТ-отделу со стороны «бизнеса» в целом.
Ладно, сейчас мы разберемся с задачами, назначим ответственных, аналитиков и атмосфера в коллективе наладится. Превратим проблемный проект в обычный и всё успеем. Делов-то! Однако этой статьи не появилось бы, если бы тот проект был единственным проблемным или если бы для его исправления было достаточно предполагаемых мер.
Копнули глубже: нашли клад из шести глобальных проблем
Мы стали думать, как всё это исправить. Посмотрим в другие проекты — ведь там всё нормально? Ведь каждый новый проект мы заводили в Jira и Gitlab, настраивали уровни доступа, CI/CD и прочие интересные штуки. Затем отдавали всё это вместе с командой на разработку. Решили включить режим «Шерлок» и в каждом проекте искать шероховатости, тайно надеясь, что не найдём ничего серьезного и докажем себе и бизнес-заказчикам, что всё не так страшно. Но мы нашли. И не просто шероховатости, а много проблемных вопросов.
Проблема 1: Откуда брать задачи?
Как сгенерить задачи, имея только верхнеуровневое ТЗ и укрупнённый план работ (считай, эпики) у руководителя проекта? И кто это должен делать?
Проблема 2: К кому идти за деталями?
Когда нужны уточнения по задаче, команды часто сталкиваются с редиректом между представителями заказчика, а также спостоянными переносами встреч. Стоит ли говорить, что в таком случае на задачу обычно забивают?
Проблема 3: На какой стадии находится фича?
На некоторых проектах требовалось лично обзвонить нескольких разработчиков для определения статуса.
Проблема 4: Нужна ли помощь?
Требуется ли помощь кому-то из команды? Есть ли вопросы? Проекты выглядели так, будто всем всё понятно и помощь не нужна. До тех пор, пока задачи не сгорят.
Проблема 5: Кто за что отвечает?
Договориться об этом «на берегу» ребята не догадались. В итоге часть процесса выпадала.
Проблема 6: Кто во всем виноват?
А это следствие предыдущего пункта, которое обычно проявляется разговорами на повышенных тонах и метанием стрелок.
В таких условиях использование Jira не приносило ощутимой пользы. Она использовалась только разработчиками и только для распределения тех редких задач, которые в неё всё же попадали.
Вот что мы сделали, чтобы всё это разрулить
Во-первых, отважились поделиться информацией о проблемах с руководителями и другими направлениями разработки и попросили нам помочь. Небольшой командой (в основном тимлидами) поговорили с лидерами проектов, где не было видно подобных проблем и собрали подходы, которые они используют, а также «грабли», на которые они наступали. Много гуглили в поисках статей, подобных этой. Ещё одна причина её появления: таких материалов мало.
Определили начальные установки
Без правил ничего не работает. Их надо ввести и знакомить с ними команды. И повторять снова и снова, чтобы правила осели в головах.
Нужны роли и зоны ответственности. Участники проекта должны хорошо понимать, что и как они должны делать. Это позволяет сосредоточиться только на своей работе, не обращая внимания на проблемы в других стадиях, по которым всегда понятно, к кому идти. Например: если нет описания задачи, разработчики не идут сами за подробностями к бизнес-заказчику — задача перекидывается на аналитика.
Должно быть просто и понятно. В «Северстали» есть проекты со сложными, но очень эффективными процессами и большими командами — это не наш случай. У нас процесс, наоборот, должен быть максимально простым, как минимум по двум причинам:
Чтобы он быстро усваивался, даже людьми без опыта командной работы.
Чтобы команда проекта не тратила время на его администрирование.
Должно быть универсально. Решение должно подходить под любой небольшой проект с минимальными и простыми доработками. Это особенно удобно для людей, работающих на нескольких проектах одновременно или при переходе команды на новый проект с теми же процессами.
Ввели базовые правила
Проект ведём в Jira + GitLab + Confluence.
Определяем роли и ответственность участников команды.
По второму пункту договариваемся на берегу.
Стендапы обязательны для всех разработчиков.
Следим за токсичностью.
С пунктом 1 бывало жёстко. На некоторых проектах пришлось призвать высоких руководителей, как со стороны разработки, так и со стороны управления проектами. Но мы победили и договорились: если нет задачи в Jira, значит она не будет сделана.
Ввели правила для Jira
Не делаем изменений в коде без задачи в Jira.
Не делаем задачи с t > 60 минут без задачи в Jira.
Задачу в работе нельзя менять или дополнять.
Всё обсуждение дублируется в комментариях к задаче.
Ввели правила для GitLab
На любую задачу по коду делаем новую ветку.
Ветку в GitLab именуем номером задачи (id задачи из Jira).
Все коммиты должны начинаться с номера задачи (стараемся) — так удобнее ориентироваться в коде, например при просмотре аннотаций.
Ветки задач никогда не удаляются.
Пуш в общие ветки запрещён, только через merge request.
Комментарии к merge request должны быть понятны.
Вот, как это стало выглядеть:
Сейчас всё выглядит просто. Но мы шли к этому через слезы и боль, регулярно переделывали эталонную схему бизнес-процесса в Jira, еженедельно с каждой командой обсуждали, что нужно убрать и чего не хватает, и экспериментировали с чем-то новым.
Что получили в итоге
Признаюсь, что даже налаженный процесс не сработал с сильно отстающими проектами. Но в целом стало легче:
Внутри проектной команды. Ясны задачи и роли каждого участника. Меньше неопределенности = меньше токсичности.
В руководстве команды разработчиков. Тимлид видит движение задач, помогает, если видит подвисание, и может дать команде больше прав и обязанностей, разгрузив себя.
В управлении всеми командами. Команды стали решать проблемы, а не генерировать их. Освободилось время для других задач и новых занимательных экспериментов над подчиненными.
Появился общий положительный фидбек: многие разработчики и руководители проектов прониклись нашей идеей и теперь накатывают этот workflow на своих новых проектах.
Как мы работаем сейчас
Базовые настройки
У нас есть готовый бизнес-процесс, который мы просто подключаем к нужному проекту. Плюс kanban-доска.
Scrum не зашёл, так как не все команды были готовы заниматься планированием спринтов. Да и регулярно прилетающие «самые важные фичи» рушили его во время экспериментов с завидной частотой.
Роли
Руководитель проекта или владелец сервиса: отвечает за продукт и ставит задачи (эпики) на разработку.
Аналитик: ставит и описывает задачи/истории для разработчиков.
Разработчик: реализует фичи по задачам из Jira.
Тестировщик: проверяет задачи после завершения разработок.
Статусы бизнес-процесса
На картинке ниже видны все статусы нашего базового бизнес-процесса, которые также привязаны к ролям (серые надписи вверху) и инстансам приложения (красные надписи вверху). Примерно 80% небольших проектов используют dev, test, prod окружения.
Немного про окружения:
dev — для отладки и код-ревью, используется разработчиками;
test — для проверки задач тестировщиками/аналитиками/заказчиками, сюда попадает код после прохождения код-ревью;
stage — используется, как правило, для проверки новых фичей на данных, близких к боевым;
prod — боевые серверы, то с чем работают пользователи сервисов.
С доски скрыты два статуса — «бэклог» и «пауза». Остальные поделены по ролям (например, у аналитика один статус, у разработчиков их несколько). Для универсальности мы сделали возможным перевод статуса в любой другой. Также многие проекты скрывают статусы «тестирование» за неимением тестировщика.
Стало хорошо, но трудности всё ещё возникают
Мы уже более года работаем с устоявшимся процессом. Казалось бы, все должны были привыкнуть. Но всё равно местами мы испытываем трудности.
Забываем про перевод задач в статусы. Взяли задачу в работу — забыли поставить ей статус «в работе». Закончили задачу — забыли перевести её в статус «код-ревью».
Не документируем изменения задачи. Начали делать. Поняли, что какой-то информации не хватает. Созвонились с тимлидом или аналитиком и уточнили, но в задачу не записали. Фичу выкатили и, если прилетит баг, мы опять будем долго выяснять, почему здесь именно такой код.
Комментарии к MR и коммитам. Иногда ещё встречается «Переделывай всё!!!» или просто «!», но скорее у тех команд, которые только недавно перешли на этот workflow.
Пропускаем стендапы. С прогульщиками боремся на уровне руководителей.
Не любим процессы. Любое лишнее движение отвлекает от работы. Однако, помня то, как мы работали вначале, мы понимаем, что все эти переводы статусов — не лишние.
Мы всё ещё продолжаем бороться, но уже бОльшими силами, чем раньше и на бОльшем количестве проектов. Теперь мы системно подходим к совершенствованию единой методологии управления разработкой во всей компании.
Несколько действенных способов, которые нам помогают бороться с трудностями
Выделяем кого-то вроде scrum-мастера, который бегает по проектам и мониторит, чтобы все работали по правилам.
Назначаем временных ответственных за стендапы, чтобы прониклись все разработчики в команде.
Снова и снова проговариваем правила, чтобы ночью встал и все пункты наизусть.
Учимся на своих и чужих ошибках, читаем, беседуем, экспериментируем.
Надеюсь, вам было интересно, а кому-то станет и полезно. Мне хочется написать больше про правила перевода в статусы и привязку к процессу в Gitlab — возможно, в скором будущем сделаю вторую, более подробную часть, если будет интересно. Пишите в комментариях. А также делитесь вашей практикой и задавайте вопросы. Спасибо!
