Ловушка для бизнеса. Шесть случаев, когда Agile бесполезен и опасен | Forbes.ru
$58.81
69.3
ММВБ2152.41
BRENT63.38
RTS1153.32
GOLD1254.77

Ловушка для бизнеса. Шесть случаев, когда Agile бесполезен и опасен

читайте также
+513 просмотров за суткиРазговоры ни о чем. Деловые встречи в России удивляют европейцев +230 просмотров за суткиНаперегонки: 4 правила, которые помогут вам больше успевать +197 просмотров за суткиКак скажете. Как расположить к себе любого собеседника +218 просмотров за суткиСловарь начальника. Как говорить с людьми, чтобы они работали на результат +124 просмотров за суткиКадры решают все. Как уволить некомпетентных сотрудников +25 просмотров за суткиПилюля для топ-менеджера: как лечить главные болезни российского бизнеса +53 просмотров за суткиСамый умный. Как научиться делегировать, чтобы выжить +71 просмотров за суткиВеликая мысль: 10 главных бизнес-теоретиков мира 2017 +26 просмотров за суткиБез блокчейна и Big Data. Банк «ФК Открытие» покинули ключевые специалисты по инновациям +9 просмотров за суткиВсему голова: почему отлаженная система важнее яркого управленца +131 просмотров за суткиПринцип трех основ и другие секреты работы со сложными сотрудниками +8 просмотров за суткиНатуральный обмен: кого в стартапах мотивировать деньгами, а кого — интересными задачами  +5 просмотров за суткиГейтс, Брин и Маск: три незаменимых персонажа в вашем совете директоров +7 просмотров за суткиКружок книголюбов: как заставить читать профлитературу поваров и официантов +17 просмотров за суткиСлучайный гость. Чем грозит наем топ-менеджера крупной компании в стартап +10 просмотров за суткиИгра на удержание. Почему увольняются успешные сотрудники +20 просмотров за суткиПрощание с иллюзиями: какие заблуждения опасны для владельцев бизнеса +15 просмотров за суткиУроки моря: принципы яхтенного спорта, которые помогают в жизни и бизнесе Руководи как CEO: бизнес-подход к управлению регионом +29 просмотров за суткиAgilе для чайников: семь тезисов о методе, который любит Герман Греф

Ловушка для бизнеса. Шесть случаев, когда Agile бесполезен и опасен

Василий Савунов Forbes Contributor
Фото Getty Images
Популярный бизнес-подход 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 — это не методология и не алгоритм, а четыре ценности:

  • Люди и их взаимодействие важнее, чем процессы и инструменты;
  • Готовый продукт важнее, чем исчерпывающая документация;
  • Взаимодействие с заказчиком важнее, чем уточнение условий контракта;
  • Готовность к изменениям важнее, чем следование первоначальному плану.

Опираясь на эти ценности, вы станете более гибкими, а ваш продукт быстрее завоюет рынок. 

Читайте также
Agilе для чайников: семь тезисов о методе, который любит Герман Греф  Прощание с иллюзиями: какие заблуждения опасны для владельцев бизнеса 
Закрыть
Уведомление в браузере
Будь в курсе самого главного.
Новости и идеи для бизнеса -
не чаще двух раз в день.
Подписаться