Представьте, что у вас что-то заболело (не дай бог, конечно). Вы идете к врачу и тут есть две возможности:
- «Резать к чертовой матери!»
- Вы идете сдавать анализы и после этого узнаете, что просто съели что-то не то
Лично мне и мы мои коллегам нравится второй вариант, именно поэтому, когда нас просят внедрить «эти ваши аджайлы», мы проводим аудит. Но мы не такие, как PricewaterhouseCoopers — мы лучше, мы неформальные и мы даем ценные результаты. Как именно — читайте под катом!
Чаще всего мы проводим аудит за три дня. Первые полтора дня проходят в сборе информации с клиентом, еще день мы делаем анализ, а потом за полдня делаем презентацию. Теперь чуть подробнее.
В начале мы общаемся с заказчиком аудита. чтобы четко определить цель аудита, причины аудита, ожидания от аудита и готовность к изменениям. От этого зависит то, какие вопросы мы будем задавать и какие рекомендации давать. Затем вместе с лидами проектом (технические, менеджеры, лидеры аналитиков) мы рисуем value stream map (VSM). Что это такое? Это описание того, как бизнес идея через разработку в конечном итоге попадает к конечному пользователю. Выглядит это примерно так
VSM позволяет понять области для улучшенияиНенужные шаги, не добавляющие стоимость, являются источником потерь и, как таковые, они могут быть устранены.
Затем у этой схемы мы собираем по очереди разработчиков, тестировщиков и аналитиков и даем им 10 минут, чтобы они написали о тех проблемах, которые они испытывают на том или ином шаге разработки продукта. В этом нам как всегда помогают стикеры. Через 10 минут мы совместными усилиями проходим по всем проблемам, совместно их фиксируем и обсуждаем.
Так как аудит мы проводим либо вдвоем либо втроем, то дальше мы разделяемся и выясняем детали по технической и продуктовой части разработки.
С точки зрения технологий, нам важно знать следующие вещи:
- технологии (язык программирования, фреймворки, базы данных, IDE, VCS)
- архитектуру
- процесс работы над фичей
- процесс работы с VCS (feature branch, branch by abstraction, …)
- состояние Continuous Integration
- состояние unit-тестирования на проекте (пишутся ли тесты, кто пишет, какой опыт, …)
- наличие практик совместного владения кодом (парное программирование, code review, …)
С продуктовой же точки зрения нам важны следующие аспекты:
- кто и как исследует рынок и пользователей
- как происходит разработка видения продукта
- есть ли понятие MVP — minimal viable product
- как определяется, какой функционал действительно необходим
- кто и как прорабатывает требования
- есть ли метрики, удачен тот или иной функционал
Обычно на этом первый день заканчивается и мы берем таймаут.
Следующую половину дня мы продолжаем общаться с командой.
Для разработчиков, тестировщиков и системных администраторов мы по очереди проводим два следующих упражнения.
Во-первых — Speed Boat. Суть в том, что мы рисуем на большом листе корабль. Данным кораблем является процесс разработки, а проблемы, которые есть – рифы, за которые цепляется якорь корабля. Задача – написать около якоря, за что тот цепляется. Степень важности проблемы можно отразить глубиной расположения якоря, чем глубже – тем серьезнее проблема. Как ни странно, эти проблемы почти не пересекаются с тем, что до этого люди говорили на VSM. Но помимо проблем, мы так же фиксируем и то, что есть положительно или хотелось бы, чтобы оно было. В случае корабля — это ветер, который дует в парус.
После того, как с кораблем мы закончили, вместе выполняем вторую задачу — строим инфраструктуру проекта: сервера, хранилища, сервисы и так далее. Что самое интересное в данном случае, каждая следующая группа, говорит «И почем они не нарисовали … » или «Да они все неверно отобразили!»
Так же, в формате Speed Boat, мы общаемся и с рекрутерами компании. Это нужно для понимания настроения в компании, мотивации людей и так далее. Один раз, именно общение с рекрутерами помогло детально понять проблему.
После этого приходит время обрабатывать результаты. Не буду раскрывать всех секретов, скажу лишь про два момента.
Во-первых, все проблемы мы разбираем по следующим группам:
- Атмосфера и культура в компании
- Работа с продуктов
- Процессы
- Люди
Это разбиение позволяет нам понять текущий уровень зрелости компании согласно нашей внутренней модели:
- Управление требованиями
- Качество
- Коммуникации
- Управление разработкой
- Мотивация
- Инженерная культура
- Управление персоналом
После всего этого мы готовим предложение и слайды. Тут тоже стоит отметить, что презентацию мы готовим на больших листах флипчартах, используя инфографику и технику Visual Notetaking. Особенность листов — клейкий край, что превращает их в гигантские стикеры, которые после презентации остаются у клиента. Сама презентация продолжается около 3-4 часов. Во время нее мы рассказываем, что увидели за два дня, что ощутили и какие проблемы зафиксировали. В 99% вся аудитория соглашается, что такие проблемы есть и их надо решать. Таким образом достигается дополнительная цель аудита — открыть глаза людям на то, что у кого-то помимо них есть проблема, которую можно совместными усилиями взять и решить.
Вот так насыщенно и энергично проходят три дня нашего аудита и все остаются довольны друг другом.
Автор: mythmaker
