Ловушка для бизнеса. Шесть случаев, когда Agile бесполезен и опасен
Agile methodology, что в переводе значит «гибкая методология», — тренд среди программистов и разработчиков. Но принципы agile популярны во всех сферах бизнеса, ведь идея agile — в гибкости, способности адаптироваться под текущую ситуацию и корректировать сроки и отношение к продукту в зависимости от изменений. Пожалуй, это самый адекватный подход для российского бизнеса именно сейчас, в условиях нестабильности и невозможности долгосрочного планирования. Вот только на самом деле agile вовсе не универсален. Так в каких случаях этот метод не для вас?
1. Стоимость переделки очень высокая
Agile нацелен на быстрое получение первого продукта, который можно выпустить на рынок, получить обратную связь от конечных пользователей и понять, в каком направлении этот продукт нужно развивать дальше. При этом, необходимость доработки или переработки после каждой итерации заложена изначально.
Такой формат работы не везде применим: например, не подойдет Agile атомной или космической отрасли. Там стоимость доработки очень высока, а иногда на кону человеческая жизнь. Мы не можем построить атомный реактор с алюминиевой крышей и проверить его на маленькой мощности. В этих условиях не до экспериментов, которые так поощряет Agile. Когда ситуация «семь раз отмерь, один отрежь» — Agile не ваш выбор.
2. Все по инструкции
Agile — путь инноваций и экспериментов. Иногда возможности для этого просто нет. Если у вас call-центр, в котором алгоритм действий оператора отлажен и жестко задан прописанным алгоритмом, то здесь в Agile нет необходимости. В данном случае конечный продукт — быстрое решение оператором проблемы позвонившего клиента — определяется четким следованием инструкции. И никаких отклонений от описанного алгоритма не допускается.
Однако, прописанный алгоритм ответов оператора покрывает не все случаи, по которым может звонить человек, почти всегда процентов 10% приходятся на непредвиденные «инциденты» — случаи, которые в алгоритме оператора не предусмотрены. Допустим, в колл-центр по обслуживанию 1С позвонит человек с просьбой о помощи — за ним гонятся и угрожают его жизни, а у него в телефоне был номер call-центра, и он его набрал в панике. Как должен поступить оператор, учитывая, что этот разговор — настоящий стресс для обоих? В алгоритме такого случая нет. Так вот, улучшать этот алгоритм, включая в него отработку непредвиденных «инцидентов» как раз можно итеративно — по Agile.
3. «Команда» из одного-двух человек
Agile — для эффективной работы команды. Он позволяет убрать множество административных и организационных проблем за счет того, что все необходимые специалисты либо сидят рядом, либо оперативно доступны и все работают сообща. В результате происходит радикальное сокращение времени на коммуникацию, увеличение вовлеченности людей в поиск инновационных продуктов.
Однако стоит понимать, что команда — это когда над задачей трудятся от трех человек и больше. Нет смысла внедрять Agile там, где у вас работает два сотрудника. Они и так легко договорятся, какого-то специального процесса для этого просто не требуется. Хотя на практике мы видим, что и до и после непосредственного этапа производства есть еще люди и процессы. Если рассматривать весь поток работы, от идеи до удовлетворения пользователя, то понятие «команда» будет включать в себя не только разработчиков. И тогда Agile — ваш вариант.
4. Нет четкого понимания, что и зачем мы делаем
Если у вас нет требований и видения продукта — хотя бы на уровне понимания вашего сегмента пользователей, их потребностей и ценностного предложения — то зачем вам Agile? Мы можем научиться делать быстро, увлекать сотрудников идеей, поставлять продукт на рынок, но если мы не попадем в пользователя, то у нас ничего не купят. По этому поводу вспоминается высказывание Сенеки (IV в. до н.э.): «Когда корабль не знает, в какой порт направляется, ни один ветер не будет для него попутным».
Например, в одном из банков решили сделать систему автоматизированного документооборота с регулирующими органами. Заложили большой бюджет, набрали команду разработки. Но разработчики за месяц успели реализовать маленькую, минимально жизнеспособную версию этой системы, а у менеджеров были масштабные планы на дальнейшую разработку. Наняли Agile-коучей, чтобы наладить рабочий процесс и сделать все быстро. Но первое же планирование работ с командой на ближайший месяц показало, что исходные продуктовые посылки никто не подумал проверить. Оказалось, что весь «поток» составлял 2-3 документа в неделю. После анализа оказалось, что дешевле нанять специального человека, который бы вел этот небольшой документооборот, используя ту небольшую систему, которую успели сделать разработчики, и больше ничего разрабатывать не потребуется. В данном случае все кончилось хорошо, но представьте, какие ненужные убытки и какой бесполезный продукт появился бы, если бы вовремя не проанализировали — а какова реальная бизнес-потребность в данном продукте?
5. Ваш ключевой подрядчик не умеет и не хочет работать по Agile
Определенная (а часто и главная) часть работ делается подрядчиком. Внутренние процессы подрядчика становятся ключевыми для нас, и как бы мы ни хотели снизить Time To Market (время выхода первой версии продукта на рынок), стать более гибкими, лучше реагировать на обратную связь от пользователя, пока мы не имеем влияния на то, как именно подрядчик работает — ничего не сдвинется с мертвой точки. Например, подрядчик отказывается вносить срочные изменения, потому что техническое задание утверждено и подписано на год вперед и ваши доработки он сможет внести только в следующем году за дополнительную плату.
Что делать? Наладить оперативный контакт с подрядчиком, в каком-то смысле перетянуть его на свою сторону. Например, переходить на аренду команды разработки и оплату времени работы этой команды (time & material), а чтобы команда делала именно то, что нужно — выделить со своей стороны продуктового менеджера к подрядчику, чтобы тот напрямую доносил видение продукта команде и осуществлял приемку. Вариантов организации масса. Но все они должны быть направлены на максимально тесное, прозрачное и оперативное взаимодействие с разработчиками подрядчика. Только после этого можно двигаться в сторону Agile.
6. Руководство не доверяет своим людям и не готово предоставить им свободу действий
Когда мы идем в сторону Agile, то делаем ставку на людей. Это командная работа, мы делегируем им принятие решений. Если они работают, находясь рядом друг с другом (в одном помещении), то могут быстро согласовать все вопросы. Но опыт показывает, что руководство само не всегда готово к такой самостоятельности. А если у сотрудников нет возможности принимать решения, пусть даже в рамках какого-то «коридора возможностей», то они не вовлекаются и всегда будут ждать указаний сверху.
Мы работали с владельцем компании по производству торгового оборудования, кассовых аппаратов, датчиков. Он жаловался, что на предприятии слишком долгий цикл разработки, и их начали уже обгонять конкуренты. В итоге выяснилось, что директор замкнул все решения на себя, постоянно меняет задачи, а менеджмент практически «парализован». Источником проблем был он сам.
В заключение хочется напомнить, что Agile — это не методология и не алгоритм, а четыре ценности:
- Люди и их взаимодействие важнее, чем процессы и инструменты;
- Готовый продукт важнее, чем исчерпывающая документация;
- Взаимодействие с заказчиком важнее, чем уточнение условий контракта;
- Готовность к изменениям важнее, чем следование первоначальному плану.
Опираясь на эти ценности, вы станете более гибкими, а ваш продукт быстрее завоюет рынок.