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

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

1. Отсутствие прозрачности.
2. Отсутствие контроля над принятием решений.
3. Отсутствие общего понимания функциональных и нефункциональных требований - может привести к тому, что делается не то и не так, как надо на самом деле.
4. Срывы сроков из-за плохих внутренних процессов подрядчика.
5. Снижение качества работы из-за плохих внутренних процессов и/или недостаточной квалификации сотрудников подрядчика.
6. Срывы сроков и снижение качества из-за человеческого фактора: ошибки, увольнения, отсутствие мотивации в работе.

Здесь решения примерно одинаковы:

• Можно включить режим “Command and Control”, заняться микроменеджментом и всё контролировать. В принципе, тогда надо было выбирать Crazy Llamas — или найти отдельных удалёнщиков.
• Можно потребовать подробной регулярной отчётности. Правда, непонятно, кто будет платить за выделенного менеджера, генерящего отчёты фулл-тайм. Подрядчику эта дополнительная нагрузка не очень нравится, а Томас считает это необходимой частью сервиса. Здесь возможен конфликт интересов. Но может сработать.
• И, наконец, можно включить Томаса в понятный гибкий процесс разработки. По понятному всем Скраму: стендапы, демо, ретро. Полная прозрачность и возможность для Томаса, помимо исполнения роли Product Owner, видеть всё происходящее в процессе разработки.

Оптимальным решением для Томаса является вариант гибкой разработки — при этом необходимо, чтобы у команды подрядчика было понимание процесса Scrum. Выясняется это достаточно быстро, в простом разговоре — ну, а практика уже покажет, насколько команда действительно умеет работать в такой парадигме.

• Детальная проработка ТЗ. Определение критериев попадания в треугольник “функциональность, бюджеты, сроки”. Возможно - составление Устава Проекта. В определённых нишах работает только это. Но у Томаса ситуация всё же иная, он желает разработать продукт, а не реализовать проект.
• Формулирование гипотез, определение критериев приёмки, ограничений и нефункциональных требований. Определение, в диалоге с командой, правил Definition of Ready, Definition of Done.
  

Томасу вполне подходит стандартный инструментарий гибкой разработки. Вопрос лишь в том, насколько команда умеет работать с ним. Общее понимание, опять же, проясняется буквально за полчаса-час. Что же будет на практике - можно будет увидеть только в процессе.

• Waterfall, жёсткие контрольные точки, штрафные санкции за превышение сроков, жёсткие ограничения на количество дефектов уровня 0, 1, 2. По сути, можно просто переложить всю ответственность на команду разработки. Да, сроки всё равно будут затягиваться, баги будут появляться и исправляться, но хоть какую-то компенсацию можно будет стрясти с подрядчика. При этом заказчику вообще без разницы, по каким именно процессам будет работать подрядчик. Он остаётся чёрным ящиком.
• Построение совместного процесса, контроль Burndown в рамках итераций и в рамках всего проекта, управление приоритетами и scope-ом задач. У Томаса всегда будет возможность либо раздвинуть сроки, либо уменьшить scope, без необходимости изменения первоначальных договорённостей. При этом можно заранее прописать определённый SLA, зафиксировав “нормальный” процент отказов и обязав подрядчика устранять за свой счёт любые недочёты, возникающие сверх оговорённого процента.
• Жёсткое внешнее управление процессом со стороны Томаса. Ему потребуется либо лично погрузиться во все детали технической реализации, либо делегировать это своему надёжному менеджеру. На уровне задач у команды будет определённая гибкость, но уже начиная с уровня пользовательских историй весь контроль будет находиться в руках заказчика. Хм.. пожалуй, да, можно было бы просто нанять фрилансеров.
  

Второй вариант выглядит наиболее привлекательным. Но как это будет работать на практике - опять же, большой вопрос. И здесь никак нельзя проработать риски простой беседой. Единственным критерием будет практический результат.

• Подход “чёрного ящика” с перекладыванием ответственности на подрядчика. Хорошо работает, если по завершении проекта с этим подрядчиком больше не планируем сотрудничать. Однако, это не вариант для Томаса. Если внутри команды начнётся выгорание, а Томас не будет об этом знать - это рано или поздно станет для него серьёзной проблемой, вне зависимости от того, каковы договорённости с подрядчиком. Рано или поздно Томас рискует потерять всю команду, вместе со всем контекстом проекта, пониманием предметной области и накопленным практическим опытом.
• Контроль процесса и морального состояния людей через стендапы и ретроспективы, с обязательным исполнением принятых решений. Позволяет сократить вероятность ошибок и мониторить состояние людей, предотвращая выгорание.
• Жёсткий контроль со стороны заказчика... да-да, мы помним: лучше было нанять фрилансеров.
  

Второй вариант, на самом деле, достаточно нетривиален в практической реализации. Томасу либо придётся достаточно глубоко погружаться в боли и проблемы команды, либо выделять прокси-менеджера со своей стороны, либо довериться менеджеру со стороны подрядчика. Насколько можно на него положиться - будет видно только в процессе работы.

А про подходы “чёрного ящика” хочется сказать, что они часто ведут к полному отсутствию прозрачности и управляемости. А это, в свою очередь, может приводить к совершенно неожиданным последствиям. Например, к таким забавным ситуациям, о которых говорил на локальном докладе GDG Meetup Kaliningrad.

Итак, просуммировав все полученные выше ответы, Томас решает, что одним из основных критериев конкретно для него будет способность команды подрядчика выстраивать, поддерживать и эффективно работать в гибких процессах разработки. И если для начала будет достаточно простого Scrum, то в перспективе, с ростом объёма и характера работ, в процесс может быть вовлечено несколько команд. А значит, понадобится какое-то масштабирование Agile. Например, SAFe, или хотя бы Scrum of Scrums.

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

Так как же заблаговременно понять, насколько хорошо гибкие процессы работают у подрядчика? Короткий и простой ответ - никак.

Вы можете слышать множество умных слов. Вам могут рассказывать про Scrum, DSDM, DAD, benefit hypothesis, Lean canvas и Growth mindset. Вам могут ответить на все вопросы, красиво расписать каждый шаг процесса по LESS или SAFe и показать прекрасные диаграммы из ADO.

Вы будете плыть на огромном белом пароходе. Кругом прекрасная музыка, благоухание роз и пасторальные картины. А внутри, под палубой, могут оказаться грязные гномы, вручную крутящие огромные неповоротливые шестерёнки. С чудовищным напряжением сил, матерясь и спотыкаясь, они будут тащить кривой механизм, покуда не упадут. И самое страшное в том, что вы не узнаете об их существовании, покуда что-то не начнёт идти “не так”. Покуда не начнутся серьёзные проблемы с качеством, сроками или выгоранием людей.

Если вы, как Томас, прекрасно понимаете, как должен работать Lean-Agile подрядчик, вероятно, вы сможете заметить и предотвратить проблему. Вполне вероятно. Но неизвестно, сколько ресурсов вы уже успеете вложить в новое направление, в построение совместного процесса с подрядчиком. И на каком этапе вы сможете точно понять, что это уже не шероховатости от “притирки” двух компаний друг к другу, а серьёзные системные ошибки в процессах.

Очевидно: для того, чтобы понять, как работают процессы в организации - необходимо провести внешний аудит. Причём это должен быть не аудит на уровне “расскажите мне своё понимание”, а аудит конкретного проекта, или нескольких проектов, где можно увидеть именно то, что находится под палубой, а не то, что заманивает вас на белый пароход.

В нашей практике был кейс внешнего аудита отдела разработки. Отдел занимается поддержкой и развитием внутреннего продукта, вокруг которого выстраивается основной сервис компании.

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

Понаблюдав за процессом неделю, мы обнаружили полное несоответствие даже базовому Scrum, обнаружили некоторые недоработки в процессах постановки, разработки и сдачи задач, и составили перечень необходимых улучшений и общих рекомендаций.

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

Подводя некоторый промежуточный итог хочется сказать, что красивые слова не всегда означают хорошо работающий процесс. Дьявол, как всегда, кроется в деталях. И не всегда возможно быстро понять, какие риски таятся “под капотом” подрядчика.

В следующий раз мы поговорим о том, какие варианты Agile-трансформации доступны сервисным компаниям, а также о том, когда надо и когда не надо внедрять SAFe.