​​А может, попробовать Agile? Как навести порядок в хаос-проекте

Даже неупорядоченный проект сможет слаженно работать, если у лида получится внедрить принципы Agile. Заместитель начальника управления автоматизации процессов кредитования корпоративных клиентов «Иннотех» Татьяна Алейникова рассказала, как хаос-проект поставить на рельсы и превратить в порядок.

Татьяна Алейникова

Заместитель начальника управления автоматизации процессов кредитования корпоративных клиентов «Иннотех»

1. Выявляем боли
2. Внедряем в «дурдом» DoD и DoR
3. Выстраиваем планирование
4. Правильно ставим задачи
5. Выделяем время на техдолг
6. Проводим ретроспективы
7. Слушаем пожелания команды
8. Сохраняем прозрачность
9. Повторяем лучшие практики

Проекты с хаотическими процессами внутри нередки для IT-сферы. Приходя в них, лиды могут чувствовать, что у них опускаются руки и возникает желание продолжить ранее выбранный командой путь: если хоть как-то работает — не трогай. Но такой подход провоцирует дальнейшее накапливание технического долга и множества дефектов, противоречий между командой и заказчиком, конфликтов внутри команды. Как итог — продукт некачественный, лид портит репутацию, а команда лишается мотивации.

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

Алгоритм превращения хаоса в рабочие процессы рассказываю ниже. Делитесь им с коллегами и лидами, если чувствуете, что команда скатывается в хаос.

Выявляем боли

Первое, что нужно сделать лиду, когда он приходит на новый проект, — узнать, что вызывает раздражение и не устраивает заказчика и команду в процессе разработки. Можно сказать, что снять боли.

Если этого не сделать, то внешнее недовольство командой и внутренняя усталость IT-специалистов будут постоянно мешать работе. Когда нет коммуникации, то заказчик не понимает команду, а команда — заказчика.

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

В идеале регулярно проводить внутреннее демо и показывать, что реализовали, как оно работает. Тогда у заказчика появится представление, на каком этапе сейчас находится процесс. Даже если прошлый лид и приукрашивал прогресс разработки, то лучше заранее показать, что есть на самом деле. Этим снимется напряжение команды разработки, а заказчик получит объективную картину мира.

Внедряем в «дурдом» DoD и DoR

Не стоит забывать наладить взаимодействие внутри команды. Одни из инструментов для решения этой задачи — DoD и DoR.

• Definition of Ready (критерии готовности к взятию в работу) — список условий к элементу бэклога, которые позволяют переместить его в работу или на следующий этап.
• Definition of Done (Определение готовности) — список условий к процессу и инкременту, которые указывают, что они могут получить статус «Готов».

При этом договариваться о DoD и DoR необходимо на всех этапах. Условно, бизнес-аналитики вместе с системными аналитиками определяют, что они выдают после бизнес-анализа. Системные аналитики договариваются с разработчиками по критериям выдачи техзадания. Разработчики вместе с тестировщиками решают, что важно и необходимо для понимания завершения этапа работы.

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

Выстраиваем планирование

Чрезвычайно важно выстроить процесс планирования. Нужно понять трудоёмкость команды и не брать задачи сверх возможностей. А ещё учитывать время на активности: дейли, планирование, ретроспективы, встречи с заказчиком и смежными участниками.

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

Обязательно закладывать риски и возможное съезжание графика. Если риск не сработает, то время не пропадёт даром — его можно использовать на следующую задачу, исправление дефекта, обучение и так далее.

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

Правильно ставим задачи

Внедряем механизм правильного назначения задач. Команда сама договаривается о минимальном и необходимом перечне достаточной информации в техническом задании, чтобы взять задачу в работу. Это позволяет сформировать понимание у каждого специалиста по быстрому вхождению в задачу. Кроме того, нивелирует возможные ошибки из-за человеческого фактора.

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

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

Выделяем время на техдолг

Заранее договориться с заказчиком, что требуется время на реализацию технического долга. Например, 60–70% времени берём на новые задачи, а в оставшееся — закрываем техдолг.

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

Проводим ретроспективы

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

Здесь важно показать пользу ретроспективы на собственном примере. Например, лиду взять на себя решение проблемы, выявленной на первом ретро. Если, естественно, найти решение ему по силам. На следующем собрании команды показать: была такая проблема, и мы её совместно решили.

Главное, лиду не уходить полностью в одного спасателя. Вовлекать команду также в решение трудностей, и далее уже команда сама будет не только вовлекаться в решение трудностей, но и предлагать улучшения.

В ретроспективе, помимо проблем, нужно подсвечивать хорошие моменты, которые происходили. Например, мы выявили ошибку, которая была очень редкая, но теперь релиз у нас без дефекта — суперспасибо всем, давайте так и дальше работать.

Стоит поощрять, чтобы в команде друг другу давали обратную связь. Не только развивающую, но и положительную. И лид в этом процессе не должен оставаться в стороне.

Мне очень помогало, когда члены команды давали обратную связь — не стеснялись, не боялись. Это позволяло мне корректировать поведение и становиться лучше. Был кейс, когда один из сотрудников как-то сказал мне: «Знаешь, ты никогда не станешь таким классным руководителем, как у нас вот этот лид». Дальше, когда мы работали вместе, он вернулся с обратной связью и сказал: «Знаешь, я не встречал нигде такого классного хорошего лида». Это самая лучшая похвала, поэтому нужно давать связь руководителю. Лидеру же не принимать эту обратную связь в каком-то негативном ключе, например, «хотят меня подсидеть».

Более того, лиду стоит самому запрашивать обратную связь от команды: «Ребята, это вам заходит или не заходит, делать мне это или не делать?»

Слушаем пожелания команды

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

На проекте у меня был очень системный человек, который любил стандарты и за них всегда топил. Решили отдать ему функцию рецензирования требований от аналитиков. И человек был очень доволен, а мы получили дополнительный контроль выявления ошибок и неточностей.

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

Но бывает и негативный опыт. Почитайте, почему Agile может не работать.

Сохраняем прозрачность

Очень краткий совет — процессы должны быть прозрачны и для команды, и для заказчика. В этом помогают канбан-доски, чаты и просто адекватная коммуникация.

Фиксировать все договорённости и оставлять их доступными для всех членов команды, чтобы вспомнить, что решили делать, когда сдавать и кто ответственный.

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

Повторяем лучшие практики

Внедряя эти принципы, важно смотреть, что работает, а что нет. Разбираться, почему не работает, а лучшие практики повторять. Не забывать подсвечивать достижения, даже если они небольшие, но не скатываться в политические лозунги: «Мы все здесь одна семья», «Мы команда», «Мы лучшие», «Мы — молодцы», «Команда мечты».

Меньше пафоса — больше адекватного общения. Мне кажется, отличный рецепт для эффективной работы.