Привет! Меня зовут Александр Мошаров, я — ведущий разработчик кластера «Индустриальные процессы». В прошлом году я руководил группой из нескольких десятков разработчиков, расшаренных на множество проектов, и собирал обратную связь от команд. На основе этих данных мы с коллегами разработали универсальный и простой подход к процессам в 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. Не делаем задачи с t > 60 минут без задачи в Jira. Задачу в работе нельзя менять или дополнять. Всё обсуждение дублируется в комментариях к задаче. На любую задачу по коду делаем новую ветку. Ветку в GitLab именуем номером задачи (id задачи из Jira). Все коммиты должны начинаться с номера задачи (стараемся) — так удобнее ориентироваться в коде, например при просмотре аннотаций. Ветки задач никогда не удаляются. Пуш в общие ветки запрещён, только через merge request. Комментарии к merge request должны быть понятны. Вот, как это стало выглядеть: Сейчас всё выглядит просто. Но мы шли к этому через слезы и боль, регулярно переделывали эталонную схему бизнес-процесса в Jira, еженедельно с каждой командой обсуждали, что нужно убрать и чего не хватает, и экспериментировали с чем-то новым. Признаюсь, что даже налаженный процесс не сработал с сильно отстающими проектами. Но в целом стало  легче: Внутри проектной команды. Ясны задачи и роли каждого участника. Меньше неопределенности = меньше токсичности. В руководстве команды разработчиков. Тимлид видит движение задач, помогает, если видит подвисание, и может дать команде больше прав и обязанностей, разгрузив себя. В управлении всеми командами. Команды стали решать проблемы, а не генерировать их. Освободилось время для других задач и новых занимательных экспериментов над подчиненными. Появился общий положительный фидбек: многие разработчики и руководители проектов прониклись нашей идеей и теперь накатывают этот workflow на своих новых проектах. У нас есть готовый бизнес-процесс, который мы просто подключаем к нужному проекту. Плюс kanban-доска. Scrum не зашёл, так как не все команды были готовы заниматься планированием спринтов. Да и регулярно прилетающие «самые важные фичи» рушили его во время экспериментов с завидной частотой. Руководитель проекта или владелец сервиса: отвечает за продукт и ставит задачи (эпики) на разработку. Аналитик: ставит и описывает задачи/истории для разработчиков. Разработчик: реализует фичи по задачам из Jira.  Тестировщик: проверяет задачи после завершения разработок. На картинке ниже видны все статусы нашего базового бизнес-процесса, которые также привязаны к ролям (серые надписи вверху) и инстансам приложения (красные надписи вверху). Примерно 80% небольших проектов используют dev, test, prod окружения. Немного про окружения: dev — для отладки и код-ревью, используется разработчиками; test — для проверки задач тестировщиками/аналитиками/заказчиками, сюда попадает код после прохождения код-ревью; stage — используется, как правило, для проверки новых фичей на данных, близких к боевым; prod — боевые серверы, то с чем работают пользователи сервисов. С доски скрыты два статуса — «бэклог» и «пауза». Остальные поделены по ролям (например, у аналитика один статус, у разработчиков их несколько). Для универсальности мы сделали возможным перевод статуса в любой другой. Также многие проекты скрывают статусы «тестирование» за неимением тестировщика.  Мы уже более года работаем с устоявшимся процессом. Казалось бы, все должны были привыкнуть. Но всё равно местами мы испытываем трудности. Забываем про перевод задач в статусы. Взяли задачу в работу — забыли поставить ей статус «в работе». Закончили задачу — забыли перевести её в статус «код-ревью».    Не документируем изменения задачи. Начали делать. Поняли, что какой-то информации не хватает. Созвонились с тимлидом или аналитиком и уточнили, но в задачу не записали. Фичу выкатили и, если прилетит баг, мы опять будем долго выяснять, почему здесь именно такой код. Комментарии к MR и коммитам. Иногда ещё встречается «Переделывай всё!!!» или просто «!», но скорее у тех команд, которые только недавно перешли на этот workflow. Пропускаем стендапы. С прогульщиками боремся на уровне руководителей. Не любим процессы. Любое лишнее движение отвлекает от работы. Однако, помня то, как мы работали вначале, мы понимаем, что все эти переводы статусов — не лишние. Мы всё ещё продолжаем бороться, но уже бОльшими силами, чем раньше и на бОльшем количестве проектов. Теперь мы системно подходим к совершенствованию единой методологии управления разработкой во всей компании. Выделяем кого-то вроде scrum-мастера, который бегает по проектам и мониторит, чтобы все работали по правилам. Назначаем временных ответственных за стендапы, чтобы прониклись все разработчики в команде. Снова и снова проговариваем правила, чтобы ночью встал и все пункты наизусть. Учимся на своих и чужих ошибках, читаем, беседуем, экспериментируем. Надеюсь, вам было интересно, а кому-то станет и полезно. Мне хочется написать больше про правила перевода в статусы и привязку к процессу в Gitlab — возможно, в скором будущем сделаю вторую, более подробную часть, если будет интересно. Пишите в комментариях. А также делитесь вашей практикой и задавайте вопросы. Спасибо!