Чек-лист хорошего аудита

Пост Никиты Филиппова

Попросила Никиту написать пост про то, что нужно учитывать при аудите. Получились 3 очень важных правила.

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

В ранней публикации была важная фраза:

В результате аудита было предложено полностью поменять процессы в Альфа-Лаб и внедрить Agile.

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

Так все-таки, если все предрешено, зачем проводить аудит? И какой это аудит, если всё и так понятно. Вне зависимости внутренний вы агент изменений, как Надя или внешний, коим был я в тот момент по отношению к Альфа-Банку (Хотя спустя эти годы я бы не мог представить, что потрачу на этот “проект” почти 4 года, работая и пытаясь улучшить Альфа-Лаб на разных позициях) вам нужен Аудит как церемония.

И вот почему:

Во-первых, у нас ( ScrumTrek ) уже не было сомнений в том, что Agile как философия и подход к трансформации компании рабочий инструмент. Вопросов не возникало, хотя они были у наших клиентов (и до сих пор порой всплывают), “а подходит ли он (Agile) нам?” И вы столкнетесь с таким вопросом. Нужно будет ответить на него, до того, как вы начнете работать. Тут-то аудит и подходит отлично. Вы можете, собрать информацию о том, что, у кого болит и подсветить это на публике, чтобы проблемы стали общие.

Во вторых, Agile — трансформация начинается не с тренингов об Agile, а с момента, когда , общаясь с людьми, вы задаете вопросы. Люди начинают задумываться, о том, что можно работать лучше и эффективнее.

В третьих, вы же готовитесь взять ответственность, за очень важные изменения, вам надо найти сподвижников.

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

1. Ясно определить цели аудита от руководства и объяснить свои цели тем, кто проводит аудит.

Главная задача — понять цели тех, кто заказывает аудит. Они могут формулироваться, как «всем счастья» или «повысить эффективность». Но нужно максимально четко их зафиксировать. Без целей бессмысленно что-то проводить.

У каждой компании свои понятия о гибкости и скорости. Стартапам нужно каждую неделю выдавать результат. Но американское космическое агентство NASA и крупные медицинские компании тоже используют Agile. У них совсем другой уровень сложности задач и проработки продуктов — они управляют жизнями. В их масштабе выпускать что-то раз в полгода сопоставимо с ежедневной поставкой для стартапа. Это очень схоже с медициной. Болезни — это такая среда, где нельзя трактовать все однозначно. Для кого-то температура 35 градусов — норма, а для кого-то пониженная. Важно, как пациент ощущает себя на этот счет. Именно это и нужно понять в ходе аудита.

2. Понять общую картину по всем процессам в компании.

Чтобы понять общую картину, необходимо создать Value stream map — схему из квадратиков и стрелочек, в которой первые будут показывать полезную работу, а вторые — демонстрировать проблемы. Важно понимать, что не всегда проблемы, которые называют сотрудники, это проблемы в реальности. У вас может болеть нога, но это не означает, что это рак, который вас убьет. Мы уже говорили, что все люди врут, иногда невольно. Они описывают симптомы, но сами не ставят себе диагнозы.

Спецификация на виджет в “старом” Альфа-клике (Как думаете сколько это страниц?)

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

3. Разделить проблемы на разные уровни.

Когда все проблемы агрегированы, их обязательно нужно разделить на разные уровни. Зачем это делать? Все очень просто, если пытаться одновременно разобраться со всем, вы снова погрузитесь в хаос. Поэтому надо решить, что нужно сделать “кровь из носу”, иначе ничего не полетит (так называемые show stopper’ы). Это проблемы первого уровня, их нужно решать в первую очередь. Остальные проблемы нужно отсортировать по мере срочности.

Несмотря на то, что проблем будет много (если их нет, то значит вы не нужны и ничего менять не надо), метод решения всех проблем есть. Он очень простой, решение происходит по закону процессов всем известной книги “Теория Ограничений” Элиаху Голдратта. Опишу закон одной фразой:

“Компания всегда движется со скоростью одного засранца и нужно молиться, чтобы это был не СЕО компании:)”

Я это все к чему? Всегда ищИте одну проблему, а не пытайтесь решать все. Для этого вам и нужен аудит! В нашем случае это была перекаченная аналитиками команда, которая без устали в стол генерировала требования и парализовала всех согласованием своих документов. Это безусловно завязывало много факторов и общения с бизнесом и, с разработкой, но проблема была одна!

На этой лирической ноте передаю, микрофон Наде!

Like what you read? Give Avdanina Nadya a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.