Привет! Меня зовут Александр Мошаров, я — ведущий разработчик кластера «Индустриальные процессы». В прошлом году я руководил группой из нескольких десятков разработчиков, расшаренных на множество проектов, и собирал обратную связь от команд. На основе этих данных мы с коллегами разработали универсальный и простой подход к процессам в Jira и Gitlab. Вот уже на протяжение года этот подход облегчает жизнь многим командам разработчиков в «Северсталь-инфокоме». Расскажу, как мы пришли к этой системе и в чем она заключается. 

У каждого проекта «Северстали» есть заказчик и разработчики. Также в полном наборе задействованы: руководитель проекта (в 90% проектов), дизайнер, аналитик, тестировщик. Примерно 60% разработчиков работали на проектах с полным набором специалистов и налаженными процессами. Как правило, это средние и крупные проекты, рассчитанные на несколько лет активной разработки, в которых ребята сидят на постоянке. Сегодня не про них, а про остальные 40%, которые заняты на небольших проектах и поддержке. У них-то процессы были не отлажены, из-за чего страдали результаты. 

Проект, с которого начались перемены: его «не успевали», но задач не было 

Однажды заказчик попросил меня добавить в проект разработчиков, аргументируя просьбу тем, что текущий состав не успеет закончить к нужному времени. Регулярно проводя встречи с командами, я знал, что на этом проекте задач немного, и ребята в свободное время занимались закрытием технического долга, в том числе и низкоприоритетного. Бывали даже ситуации, когда я мог переключить одного члена команды на другую разработку на 2–4 недели, а основной проект от этого не страдал. Как же так получилось, что команда не успевала, но при этом не знала, чем заняться?

Провели несколько встреч и кое-что накопали:

1. Задачи на этом проекте никто не видел, потому что их попросту не заводили. Они проговаривались устно на встрече с заказчиком.

2. Команда реализовывала множество «хотелок» заказчика, отклоняясь от технического задания. Причина в том, что всю нужную информацию оперативно удавалось получить только по ним.

3. Уходило несколько часов (иногда десятки), чтобы понять, для чего в проект была внесена та или иная логика. Это следствие пункта 1, когда задачи не заводятся или к ним нет никакого описания.

4. Фичи часто переделывались, так как разработчикам приходилось самим додумывать постановки к задаче.

Почему не заводили задачи? Команда не могла договориться о том, кто должен это делать.

Почему не делали постановку к задачам? Собрать подробное описание для задачи — значит ловить заказчика. Но кто должен это делать?

Одной из серьезных проблем, помимо того, что продукт не будет готов в срок, стала растущая токсичность на проекте. Регулярно происходили выяснения отношений и споры, из-за чего решить рабочие вопросы было сложно. Людям было просто не до проекта — все пытались перекинуть ответственность друг на друга. В такой атмосфере развивалась сильная демотивация, ребята просили перевода на другие проекты. Также появлялся негатив к ИТ-отделу со стороны «бизнеса» в целом. 

Ладно, сейчас мы разберемся с задачами, назначим ответственных, аналитиков и атмосфера в коллективе наладится. Превратим проблемный проект в обычный и всё успеем. Делов-то! Однако этой статьи не появилось бы, если бы тот проект был единственным проблемным или если бы для его исправления было достаточно предполагаемых мер.

Копнули глубже: нашли клад из шести глобальных проблем

Мы стали думать, как всё это исправить. Посмотрим в другие проекты — ведь там всё нормально? Ведь каждый новый проект мы заводили в Jira и Gitlab, настраивали уровни доступа, CI/CD и прочие интересные штуки. Затем отдавали всё это вместе с командой на разработку. Решили включить режим «Шерлок» и в каждом проекте искать шероховатости, тайно надеясь, что не найдём ничего серьезного и докажем себе и бизнес-заказчикам, что всё не так страшно. Но мы нашли. И не просто шероховатости, а много проблемных вопросов. 

Проблема 1: Откуда брать задачи?

Как сгенерить задачи, имея только верхнеуровневое ТЗ и укрупнённый план работ (считай, эпики) у руководителя проекта? И кто это должен делать?

Проблема 2: К кому идти за деталями?

Когда нужны уточнения по задаче, команды часто сталкиваются с редиректом между представителями заказчика, а также спостоянными переносами встреч. Стоит ли говорить, что в таком случае на задачу обычно забивают?

Проблема 3: На какой стадии находится фича?

На некоторых проектах требовалось лично обзвонить нескольких разработчиков для определения статуса.

Проблема 4: Нужна ли помощь?

Требуется ли помощь кому-то из команды? Есть ли вопросы? Проекты выглядели так, будто всем всё понятно и помощь не нужна. До тех пор, пока задачи не сгорят.

Проблема 5: Кто за что отвечает?

Договориться об этом «на берегу» ребята не догадались. В итоге часть процесса выпадала.

Проблема 6: Кто во всем виноват?

А это следствие предыдущего пункта, которое обычно проявляется разговорами на  повышенных тонах и метанием стрелок.

В таких условиях использование Jira не приносило ощутимой пользы. Она использовалась только разработчиками и только для распределения тех редких задач, которые в неё всё же попадали.

Вот что мы сделали, чтобы всё это разрулить

Во-первых, отважились поделиться информацией о проблемах с руководителями и другими направлениями разработки и попросили нам помочь. Небольшой командой (в основном тимлидами) поговорили с лидерами проектов, где не было видно подобных проблем и собрали подходы, которые они используют, а также  «грабли», на которые они наступали. Много гуглили в поисках статей, подобных этой. Ещё одна причина её появления: таких материалов мало.

Определили начальные установки

• Без правил ничего не работает. Их надо ввести и знакомить с ними команды. И повторять снова и снова, чтобы правила осели в головах.

• Нужны роли и зоны ответственности. Участники проекта должны хорошо понимать, что и как они должны делать. Это позволяет сосредоточиться только на своей работе, не обращая внимания на проблемы в других стадиях, по которым всегда понятно, к кому идти. Например: если нет описания задачи, разработчики не идут сами за подробностями к бизнес-заказчику — задача перекидывается на аналитика.

• Должно быть просто и понятно. В «Северстали» есть проекты со сложными, но очень эффективными процессами и большими командами — это не наш случай. У нас процесс, наоборот, должен быть максимально простым, как минимум по двум причинам:

1. Чтобы он быстро усваивался, даже людьми без опыта командной работы. 

2. Чтобы команда проекта не тратила время на его администрирование.

• Должно быть универсально. Решение должно подходить под любой небольшой проект с минимальными и простыми доработками. Это особенно удобно для людей, работающих на нескольких проектах одновременно или при переходе команды на новый проект с теми же процессами.

Ввели базовые правила

1. Проект ведём в Jira + GitLab + Confluence.

2. Определяем роли и ответственность участников команды.

3. По второму пункту договариваемся на берегу.

4. Стендапы обязательны для всех разработчиков.

5. Следим за токсичностью.

С пунктом 1 бывало жёстко. На некоторых проектах пришлось призвать высоких руководителей, как со стороны разработки, так и со стороны управления проектами. Но мы победили и договорились: если нет задачи в Jira, значит она не будет сделана.

Ввели правила для Jira

1. Не делаем изменений в коде без задачи в Jira.

2. Не делаем задачи с t > 60 минут без задачи в Jira.

3. Задачу в работе нельзя менять или дополнять.

4. Всё обсуждение дублируется в комментариях к задаче.

Ввели правила для GitLab

1. На любую задачу по коду делаем новую ветку.

2. Ветку в GitLab именуем номером задачи (id задачи из Jira).

3. Все коммиты должны начинаться с номера задачи (стараемся) — так удобнее ориентироваться в коде, например при просмотре аннотаций.

4. Ветки задач никогда не удаляются.

5. Пуш в общие ветки запрещён, только через merge request.

6. Комментарии к merge request должны быть понятны.

Вот, как это стало выглядеть:

Сейчас всё выглядит просто. Но мы шли к этому через слезы и боль, регулярно переделывали эталонную схему бизнес-процесса в Jira, еженедельно с каждой командой обсуждали, что нужно убрать и чего не хватает, и экспериментировали с чем-то новым.

Что получили в итоге

Признаюсь, что даже налаженный процесс не сработал с сильно отстающими проектами. Но в целом стало  легче:

• Внутри проектной команды. Ясны задачи и роли каждого участника. Меньше неопределенности = меньше токсичности.

• В руководстве команды разработчиков. Тимлид видит движение задач, помогает, если видит подвисание, и может дать команде больше прав и обязанностей, разгрузив себя.

• В управлении всеми командами. Команды стали решать проблемы, а не генерировать их. Освободилось время для других задач и новых занимательных экспериментов над подчиненными.

Появился общий положительный фидбек: многие разработчики и руководители проектов прониклись нашей идеей и теперь накатывают этот workflow на своих новых проектах.

Как мы работаем сейчас

Базовые настройки

У нас есть готовый бизнес-процесс, который мы просто подключаем к нужному проекту. Плюс kanban-доска.

Scrum не зашёл, так как не все команды были готовы заниматься планированием спринтов. Да и регулярно прилетающие «самые важные фичи» рушили его во время экспериментов с завидной частотой.

Роли

1. Руководитель проекта или владелец сервиса: отвечает за продукт и ставит задачи (эпики) на разработку.

2. Аналитик: ставит и описывает задачи/истории для разработчиков.

3. Разработчик: реализует фичи по задачам из Jira. 

4. Тестировщик: проверяет задачи после завершения разработок.

Статусы бизнес-процесса

На картинке ниже видны все статусы нашего базового бизнес-процесса, которые также привязаны к ролям (серые надписи вверху) и инстансам приложения (красные надписи вверху). Примерно 80% небольших проектов используют dev, test, prod окружения.

Немного про окружения:

• dev — для отладки и код-ревью, используется разработчиками;

• test — для проверки задач тестировщиками/аналитиками/заказчиками, сюда попадает код после прохождения код-ревью;

• stage — используется, как правило, для проверки новых фичей на данных, близких к боевым;

• prod — боевые серверы, то с чем работают пользователи сервисов.

С доски скрыты два статуса — «бэклог» и «пауза». Остальные поделены по ролям (например, у аналитика один статус, у разработчиков их несколько). Для универсальности мы сделали возможным перевод статуса в любой другой. Также многие проекты скрывают статусы «тестирование» за неимением тестировщика. 

Стало хорошо, но трудности всё ещё возникают

Мы уже более года работаем с устоявшимся процессом. Казалось бы, все должны были привыкнуть. Но всё равно местами мы испытываем трудности.

Забываем про перевод задач в статусы. Взяли задачу в работу — забыли поставить ей статус «в работе». Закончили задачу — забыли перевести её в статус «код-ревью».   

Не документируем изменения задачи. Начали делать. Поняли, что какой-то информации не хватает. Созвонились с тимлидом или аналитиком и уточнили, но в задачу не записали. Фичу выкатили и, если прилетит баг, мы опять будем долго выяснять, почему здесь именно такой код.

Комментарии к MR и коммитам. Иногда ещё встречается «Переделывай всё!!!» или просто «!», но скорее у тех команд, которые только недавно перешли на этот workflow.

Пропускаем стендапы. С прогульщиками боремся на уровне руководителей.

Не любим процессы. Любое лишнее движение отвлекает от работы. Однако, помня то, как мы работали вначале, мы понимаем, что все эти переводы статусов — не лишние.

Мы всё ещё продолжаем бороться, но уже бОльшими силами, чем раньше и на бОльшем количестве проектов. Теперь мы системно подходим к совершенствованию единой методологии управления разработкой во всей компании.

Несколько действенных способов, которые нам помогают бороться с трудностями

1. Выделяем кого-то вроде scrum-мастера, который бегает по проектам и мониторит, чтобы все работали по правилам.

2. Назначаем временных ответственных за стендапы, чтобы прониклись все разработчики в команде.

3. Снова и снова проговариваем правила, чтобы ночью встал и все пункты наизусть.

4. Учимся на своих и чужих ошибках, читаем, беседуем, экспериментируем.

Надеюсь, вам было интересно, а кому-то станет и полезно. Мне хочется написать больше про правила перевода в статусы и привязку к процессу в Gitlab — возможно, в скором будущем сделаю вторую, более подробную часть, если будет интересно. Пишите в комментариях. А также делитесь вашей практикой и задавайте вопросы. Спасибо!