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

По каким критериям выбирают подрядчика?

1. Цена
2. Качество
3. Понимание и ориентация на бизнес-цели заказчика
4. Грамотно выстроенные процессы и сертификация по ISO
5. Гибкость и скорость реакции

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

Давайте рассмотрим пример: смоделируем ситуацию с поиском подрядчика.

Disclaimer: Названия, имена, и ситуации, хоть и базируются на реальных кейсах, известных мне, в данном случае являются синтетическими. Любые совпадения — случайны.

Компания-заказчик «Thorns Digital» развивает линейку своих собственных продуктов. При этом существует несколько вспомогательных направлений, до которых никогда не доходят руки. Бюджеты есть, но все высвобождающиеся человеческие и управленческие ресурсы тут же направляются на основное направление, поскольку оно генерирует наиболее стабильный и полный денежный поток.

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

Томас обратился в несколько компаний с запросом на разработку проекта, и получил следующие ответы:

• Агентство Digital Bears ответило, что у них есть множество команд, идеально подходящих под его запрос, и предложило созвониться для уточнения требований и обсуждения условий.
• Сервисная компания Crazy Llamas мгновенно ответила, что их разработчики могут приступить завтра же, и тоже предложила скайп-колл.
• Компания Mighty Minds запросила ТЗ на оценку.
• Сервисная компания Hello World сообщила, что формирование команды под его запрос может занять от двух недель до двух месяцев, в зависимости от технических требований и желаемого процесса разработки. Да, скайп-колл поможет прояснить эти вопросы.
• Сервисная компания Lean Devs в ответном письме сообщила, что прежде, чем принять гипотезу Томаса за рабочий сценарий, они хотели бы сделать вместе с ним шаг назад, провести Customer Development, составить Lean Canvas и убедиться, что проблему надо решать именно таким образом. После чего можно будет приступать к проработке функциональных и нефункциональных требований, критериев приёмки, и постепенно двигаться к формулированию запроса на дизайн и разработку.
• Агентство Totally Right уведомило Томаса о том, что, согласно их внутренним процессам, команду разработки можно будет сформировать в течение месяца. И предложило проработать требования совместно с их Product Owner-ом, определиться с командой, необходимой для работы над проектом, выстроить Roadmap проекта, спрогнозировать сроки и стоимость работ

Какие выводы сделал для себя Томас?

1. Он не будет работать с Digital Bears. Кого ему подсунут — большой вопрос, а само агентство, похоже, не особо переживает о конечном результате.
2. Crazy Llamas — это просто группа разработчиков, без понимания бизнесовой составляющей. В таком случае, они ничем не лучше фрилансеров на «удалёнку».
3. Похоже, ребята из Mighty Minds мыслят категориями Waterfall. Томас слишком долго проработал в продуктовой разработке и понимает, что этот подход совсем не то что ему нужно. Процессы работы такого подрядчика будут слишком разными.
4. C Hello World не всё понятно. Могут оказаться интересными ребятами, а могут быть клоном Crazy Llamas. Надо пообщаться.
5. Lean Devs копают вопрос на полный штык и подходят к самой сути. Не понятно, правда, кто в итоге будет контролировать продукт — Томас или они, и как будут выстроены процессы и взаимоотношения. Но в этом определённо что-то есть.
6. Totally Right выглядят достаточно серьёзно, и предлагают вполне разумные вещи. С ними тоже имеет смысл пообщаться.

Нужен ли Agile в сервисном бизнесе?

Компания Томаса давно и прочно работает в парадигме Agile, постоянно совершенствуя свои процессы и пробуя на практике нововведения. Он понимает, что в команде, способной разработать полноценный продукт, должны быть как разработчики, так и Product Owner, отвечающий на вопрос «как именно наш продукт должен решать бизнес-цели?», а также Scrum Master, отвечающего на вопрос «что ещё мы можем сделать, чтобы процесс разработки стал более эффективным?»

Поэтому Томасу не хочется работать с «просто разработчиками», которые мыслят категориями «поставьте мне задачу — я её выполню». Если у команды подрядчика отсутствует agile-подход и продуктовое мышление, весьма вероятно она будет делать не то что надо для развития продукта. И переламывать ситуацию придётся Томасу, влезая в процесс постановки, приоритизации, планирования и контроля выполнения задач с головой. Кто при этом будет думать о продукте, формулировать гипотезы, составлять критерии их успешности, мониторить результаты, собирать метрики и принимать решения — большой вопрос. У Томаса может элементарно не остаться времени для этого, поскольку он будет занят донесением бизнес-контекста до команды и микроменеджментом.

Поэтому ему не интересны ни агентства, предлагающие безымянные команды, ни команды, мыслящие категориями работы по ТЗ, ни команды, думающие только о процессе разработки. И тем более он не сможет работать с компанией, живущей в ритме Waterfall. Там, где Томас будет требовать быстрого вывода на рынок Minimal Marketable Feature, ему будут упорно бубнить про жизненный цикл разработки, диаграммы Гантта и длительный этап внедрения. А если даже и согласятся работать «по правилам этого идиота», то результат будет предсказуемо плохим. В компании Томаса гибкие подходы закладывались с самого основания. При этом культура, позволяющая эффективно использовать все плюсы на полную катушку, сложилась только через год. Чего уж ожидать от команды, давно и плотно работающей в другой парадигме.

В заключение

Томас — один из множества заказчиков на рынке. Есть и те, для которых будут важны другие критерии. До сих пор есть крупный бизнес, работающий по Waterfall и не видящий этому альтернатив.

Однако, если уже даже на сверхконсервативном уровне государства начинаются разговоры о проблемах традиционных подходов к управлению, то что уж говорить о крупном бизнесе. SAFe уверенно лидирует в чартах внедрения масштабируемого Agile в РФ. Думаю, не за горами тот час, когда работа по SAFe станет необходимым условием для начала любых переговоров о крупном контракте.