Сейчас agile-практиками никого не удивишь, все уже давно прочитали практическое руководство (или вы еще нет?:) ) и стремятся выполнять по методичке привычные функции: планировать, разрабатывать, тестировать и далее по циклу. "Но ведь все это мы делали всегда, зачем нам agile?" - с таким возражением пришлось работать больше всего, ведь сроки учитывались и раньше, ценность все понимают и так… При этом, меня не покидало тимлидское чувство что "что-то не так", разобралась в этом для себя и делюсь с вами.

Про команду и привычки

Я возглавляю команду Sugar CRM с 2019 года, наш состав практически не менялся все это время. И в своем департаменте корпоративного и малого бизнеса у команды сформировался имидж одной из самых стабильных и зрелых. Мы, как и большинство коллег, работали по классической проектной модели: календарно-ресурсное планирование, объемные согласования, десятки документов (ФСД, ДПТЗ, БТ, МПИД, протоколы тестирования и т.д.) — всё, как положено в водопадной модели.

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

Первый шаг в трансформацию

С осени 2024 в Банке началась масштабная трансформация всего ИТ, и моя команда стала одной из первых, кто пошёл по пути продуктового подхода, применяя agile-практики.

Скажу прямо: принять решение оказалось проще, чем его реализовать. Невозможно "просто взять и внедрить agile" в команде, где все привычно, предсказуемо и вотерфольно… Самая большая сложность была в изменении мышления, мы много часов потратили на все стадии принятия: отрицание, гнев, торг. Это были разные инструменты, здесь многое зависит от лидера и удобных форм получения контента: one-to-one, чтение методичек, поиск ответов на Хабре и много синхронов.

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

Конкретно, что поменялось?

№1 Фокус на ценность, а не документацию.
Сейчас заказчик к нам приходит с простым запросом: у меня есть идея, я хочу чтобы стало вот так.

За 15 минут мы поняли друг друга, без чтения 20-ти страничного документа. Ушли в прошлое возражения типа "по ФСД такого не было", мы используем это время фокусируясь на результате.

 №2 Лёгкая коммуникация с заказчиком

Это очень близко к п.1, но все-таки про другое. Нет споров и бесконечных согласований: бизнес объяснил свое видение, команда понимает цель фичи и делает "как для себя". Даже если приходят изменения, это по-прежнему остается на уровне простой коммуникации: мы не тратим время на переписку, а сразу "пилим" как надо заказчику.

№3 Минимум бюрократии - максимум ценности

Мы убрали из процесса всё, что отнимает время впустую: согласования, протоколы, внутренние наряды и перебрасывания задач из КРП. Команда планирует спринт, ставит приоритеты - делаем.

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

№4 Вовлеченность и ответственность команды

Кстати, про ресурс. Появляются силы и желание углубленно разбираться в своем продукте, смотреть на него с разных точек зрения и (может быть, самое главное) быть включенным в работу команды. Все знают над чем работает друллега (коллега+друг), синергия взлетает в космос.

А ещё в нашем чате стало много смешных мемов и день начинается с хорошего настроения:)

№5 Каждый спринт = результат

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

Про факапы

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

Сейчас, оглядываясь назад, я понимаю: мы просто не умели правильно декомпозировать задачи. Мы не фокусировались на пользовательских историях и ценности, которую они приносят. Взяли всё сразу, монолитно, и... застряли.

Было много недоговорённостей. Мы не умели просить помощи. Каждый варился в своей задаче и, по старой привычке, воспринимал её как личную ответственность: «тебе дали — ты и делай». Командного подхода не было.

Сейчас — совсем другое дело. Мы научились поднимать руку, как только появляется проблема. На дейли можно услышать: «у меня блокер или я туплю» — и уже через 20–30 минут кто-то из команды подскажет решение или хотя бы направление, куда копать. Я считаю это эффект доверия и открытого диалога.

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

На старте всё вызывало дикое сопротивление. Те же дейли — вместо 15–20 минут занимали по часу, все уставали, считали, что это бесполезная трата времени.

 Разработчику было сложно кратко ответить: «что я делал вчера и что буду делать сегодня». Мы будто учились заново формулировать цели. При этом у меня очень взрослый коллектив.

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

• Что сделал вчера?

• Что планируешь сегодня?

• Есть ли блокеры?

Все подробности — после. Мы даже шутим, называем это «афтедейли» — как афтепати после конференции. Хотите — присоединяйтесь, не хотите — идите писать код/тестить фичи.

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

Да, сначала все спросили: «А это вообще зачем?» мы же готовим описание изменений в гите. Но мы продолжили, и через пару спринтов коллеги начали подтягиваться.

Сейчас демо — важная часть культуры. Мы показываем не только фичи, но и то, как они решают конкретную задачу бизнеса. Людям это интересно, полезно, а мы в одном демо закрываем сразу несколько запросов. И бизнес в курсе и айти в курсе.

Как мы убирали бюрократию в банке и не сгорели

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

Мы договорились: если есть концептуальное «ОК» от заказчика на ПБР, мы просто берём задачу в спринт. Больше не нужно оформлять согласование через СД , не нужно ждать формального одобрения ДПТЗ (дата передачи тестирования заказчику).

Раньше всё это тормозило нас на 3–5 рабочих дней, а иногда — и на недели. Особенно если заказчику не нравилась предложенная дата. Теперь у нас есть релизный поезд каждые 3 недели — и всё: хочешь, чтобы задача попала в ближайший релиз, поставь приоритет выше. Просто и понятно.

Да, поначалу было непривычно — и нам, и заказчикам. Но теперь бизнес сам говорит: «Ребята, с вами проще» На каждом квартальном бизнес ревью , подводя итоги слышим благодарность от бизнеса. Это, пожалуй, и есть та самая настоящая трансформация.

 Что поможет тимлиду при переходе на agile-практики

1. Сильная теоретическая база по agile - будет вашим преимуществом;

2. Насмотренность поможет подбирать аргументацию, если она необходима (читаем всякое про agile);

3. Ментор/супервизор. Найдите того, кто уже прошел этот путь и попросите саппортить вам;

4. One-to-one (их будет много);

5. Дейлики. (Повторюсь, у нас они исключительно на позитиве);

6. PBR в начале и ретро по окончанию спринта.

Выводы

• Уходить от вотерфола страшно, но расставлять все по местам и жить в порядке гораздо понятнее и проще;

• В продуктовом подходе все вокруг твои партнеры, нет тех, кто выше или ниже по процессу;

•  40 часов в неделю наполнены смыслом и ценностью, работа перестает быть рутиной;

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

• Растет доверие между бизнесом и ИТ.

И, подводя итог, хочу сказать

Стало ли работы меньше? Нет. Но она стала другой. Без хаоса. Без вечных переносов, которые никто не может объяснить. Без ощущения, что ты работаешь в темноте.

Сейчас всё — по делу. Есть прозрачность, есть доверие, есть спокойствие. Бизнес знает, что мы предсказуемы. А мы, в свою очередь, знаем, что бизнес — не абстрактный «заказчик», а команда по ту сторону.

Мы идём в одну ногу. Гибко, но с фокусом. Быстро, но с пониманием. Вроде бы те же люди, тот же стек, тот же банк.

Таким был путь моей команды в продуктовый подход. Мы прошли непростой путь трансформации и продолжим работать над улучшением процессов. А какой путь был у вас? Что помогло наладить процессы в команде?

Делитесь в комментариях, давайте вместе выполнять упражнение про насмотренность :)