Agile-трансформация в сервисном бизнесе. Часть 1: критерии выбора подрядчика

Agile-трансформация в сервисном бизнесе. Часть 1: критерии выбора подрядчика
Думаю, нет необходимости рассказывать о том, что такое Agile. Agile де-факто утвердился в ноосфере. Все говорят об Agile. Многие хотят провести Agile-трансформацию. Среди сервисных компаний мнения расходятся. Да, Scrum на уровне работы отдельных команд, но трансформация всех процессов компании…
Зачем? Какие бонусы получит сервисная компания от Agile-трансформации? Если вы хотите работать с большими продуктовыми компаниями, крупным бизнесом и корпорациями, то задуматься об Agile-трансформации следует уже сейчас. Такие заказчики все активнее становятся “гибкими”, масштабируют Agile в своих организациях и будут выбирать подрядчиков “из той же обоймы”.
Этой статьёй мы начинаем цикл публикаций, посвященных Agile-трансформации сервисного бизнеса, и поможем компаниям взглянуть на вещи под иным углом. Сегодня я освещу вопрос критериев выбора подрядчика.
По каким критериям выбирают подрядчика?
- Цена
- Качество
- Понимание и ориентация на бизнес-цели заказчика
- Грамотно выстроенные процессы и сертификация по ISO
- Гибкость и скорость реакции
Это далеко не исчерпывающий список. Это те критерии, которые мне приходится слышать чаще всего. В последнее время появился еще один – работа процессов компании-подрядчика по Agile. Лет пять назад этим мало кто интересовался, два-три года назад интересовались время от времени – а теперь интересуются практически постоянно. Об этом не так давно писал Алексей Палаткин, а я в этом цикле статей постараюсь объяснить, почему это происходит. Возможно, в этом есть доля хайпа, но это действительно может быть важно для заказчика.
Давайте рассмотрим пример: смоделируем ситуацию с поиском подрядчика.
Disclaimer: Названия, имена, и ситуации, хоть и базируются на реальных кейсах, известных мне, в данном случае являются синтетическими. Любые совпадения – случайны.
Компания-заказчик “Thorns Digital” развивает линейку своих собственных продуктов. При этом существует несколько вспомогательных направлений, до которых никогда не доходят руки. Бюджеты есть, но все высвобождающиеся человеческие и управленческие ресурсы тут же направляются на основное направление, поскольку оно генерирует наиболее стабильный и полный денежный поток.
Менеджер вспомогательного направления Томас принимает решение отдать небольшой проект на аутсорс. С тем, чтобы проверить свою гипотезу и понять, можно ли продвигать это направление при помощи внешних ресурсов.
Томас обратился в несколько компаний с запросом на разработку проекта, и получил следующие ответы.
- Агентство Digital Bears ответило, что у них есть множество команд, идеально подходящих под его запрос, и предложило созвониться для уточнения требований и обсуждения условий.
- Сервисная компания Crazy Llamas мгновенно ответила, что их разработчики могут приступить завтра же, и тоже предложила скайп-колл.
- Компания Mighty Minds запросила ТЗ на оценку.
- Сервисная компания Hello World сообщила, что формирование команды под его запрос может занять от двух недель до двух месяцев, в зависимости от технических требований и желаемого процесса разработки. Да, скайп-колл поможет прояснить эти вопросы.
- Сервисная компания Lean Devs в ответном письме сообщила, что прежде, чем принять гипотезу Томаса за рабочий сценарий, они хотели бы сделать вместе с ним шаг назад, провести Customer Development, составить Lean Canvas и убедиться, что проблему надо решать именно таким образом. После чего можно будет приступать к проработке функциональных и нефункциональных требований, критериев приёмки, и постепенно двигаться к формулированию запроса на дизайн и разработку.
- Агентство Totally Right уведомило Томаса о том, что, согласно их внутренним процессам, команду разработки можно будет сформировать в течение месяца. И предложило проработать требования совместно с их Product Owner-ом, определиться с командой, необходимой для работы над проектом, выстроить Roadmap проекта, спрогнозировать сроки и стоимость работ.
Какие выводы сделал для себя Томас?
- Он не будет работать с Digital Bears. Кого ему подсунут – большой вопрос, а само агентство, похоже, не особо переживает о конечном результате.
- Crazy Llamas – это просто группа разработчиков, без понимания бизнесовой составляющей. В таком случае, они ничем не лучше фрилансеров на “удалёнку”.
- Похоже, ребята из Mighty Minds мыслят категориями Waterfall. Томас слишком долго проработал в продуктовой разработке и понимает, что этот подход совсем не то что ему нужно. Процессы работы такого подрядчика будут слишком разными.
- C Hello World не всё понятно. Могут оказаться интересными ребятами, а могут быть клоном Crazy Llamas. Надо пообщаться.
- Lean Devs копают вопрос на полный штык и подходят к самой сути. Не понятно, правда, кто в итоге будет контролировать продукт – Томас или они, и как будут выстроены процессы и взаимоотношения. Но в этом определённо что-то есть.
- Totally Right выглядят достаточно серьёзно, и предлагают вполне разумные вещи. С ними тоже имеет смысл пообщаться.
Нужен ли Agile в сервисном бизнесе?
Компания Томаса давно и прочно работает в парадигме Agile, постоянно совершенствуя свои процессы и пробуя на практике нововведения. Он понимает, что в команде, способной разработать полноценный продукт, должны быть как разработчики, так и Product Owner, отвечающий на вопрос “как именно наш продукт должен решать бизнес-цели?”, а также Scrum Master, отвечающего на вопрос “что ещё мы можем сделать, чтобы процесс разработки стал более эффективным?”
Поэтому Томасу не хочется работать с “просто разработчиками”, которые мыслят категориями “поставьте мне задачу – я её выполню”. Если у команды подрядчика отсутствует agile-подход и продуктовое мышление, весьма вероятно она будет делать не то что надо для развития продукта. И переламывать ситуацию придётся Томасу, влезая в процесс постановки, приоритизации, планирования и контроля выполнения задач с головой. Кто при этом будет думать о продукте, формулировать гипотезы, составлять критерии их успешности, мониторить результаты, собирать метрики и принимать решения – большой вопрос. У Томаса может элементарно не остаться времени для этого, поскольку он будет занят донесением бизнес-контекста до команды и микроменеджментом.
Поэтому ему не интересны ни агентства, предлагающие безымянные команды, ни команды, мыслящие категориями работы по ТЗ, ни команды, думающие только о процессе разработки. И тем более он не сможет работать с компанией, живущей в ритме Waterfall. Там, где Томас будет требовать быстрого вывода на рынок Minimal Marketable Feature, ему будут упорно бубнить про жизненный цикл разработки, диаграммы Гантта и длительный этап внедрения. А если даже и согласятся работать “по правилам этого идиота”, то результат будет предсказуемо плохим. В компании Томаса гибкие подходы закладывались с самого основания. При этом культура, позволяющая эффективно использовать все плюсы на полную катушку, сложилась только через год. Чего уж ожидать от команды, давно и плотно работающей в другой парадигме.
В заключение
Томас – один из множества заказчиков на рынке. Есть и те, для которых будут важны другие критерии. До сих пор есть крупный бизнес, работающий по Waterfall и не видящий этому альтернатив.
Однако, если уже даже на сверхконсервативном уровне государства начинаются разговоры о проблемах традиционных подходов к управлению, то что уж говорить о крупном бизнесе. SAFe уверенно лидирует в чартах внедрения масштабируемого Agile в РФ. Думаю, не за горами тот час, когда работа по SAFe станет необходимым условием для начала любых переговоров о крупном контракте.