РБК Pro —  
информационный сервис для предпринимателей и управленцев. Первый месяц — бесплатно

Время перемен: когда старый ИТ-подрядчик не справляется, ищем нового

IT Инструкции IT-Manager
Эксперт журнала IT-Manager Андрей Путин подготовил гайд, объясняющий, как понять, что компании пора менять ИТ-подрядчика, и на какие маркеры обратить внимание при выборе нового партнера

Представим ситуацию. Вы внедряете в свою ИТ-архитектуру BPMS (Business Process Management System, система для управления бизнес-процессами. — РБК Pro). Но исполнитель постоянно сдвигает сроки окончательного деплоя (от англ. deploy, развертывание. — РБК Pro), а бизнес-процессы, которые должны были запуститься на этапе MVP (тестирование гипотез и проверки жизнеспособности задуманного продукта. — РБК Pro), выполняются некорректно. Что делать в этой ситуации — «добивать» проект с нынешней командой, менять исполнителя, искать ошибки на своей стороне? И не усугубит ли ситуацию любое из этих решений?

В максимально упрощенном виде аутсорсинг в ИТ строится примерно по следующей схеме:

постановка задачи ⇒ перепостановка задачи ⇒ исполнение.

Клиент в лице своего менеджера или команды проекта ставит задачи подрядчику. Подрядчик — опять же, через своего менеджера или команду проекта — эти задачи обрабатывает, анализирует требования, формулирует план действий для своих специалистов. Проблема может возникнуть на любом участке данной цепочки. Давайте рассмотрим каждый из них.

Проблемы постановки задачи

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

Например, существуют следующие четыре типа систем.

1. Упорядоченная простая — результат понятен и предсказуем, для достижения уже есть примеры успешных практик, вводные условия и требования к нему не меняются. Например, задача «построить дом» понятна, измерима и не вызывает вопросов у специалистов.

2. Сложная — задача не уникальна, желаемый результат примерно понятен, но лучшие практики в решении аналогичных вопросов пока не сложились. Задача «построить город на болоте» решается при помощи успешных практик в строительстве, дополненных здравым смыслом и инженерной мыслью.

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

4. Хаотическая — нет понимания ни по результату, ни по оптимальным практикам его достижения. Условия и приоритеты постоянно меняются. Менеджмент и команда реагируют на них ситуативно. Задача из примера усложняется до «построить универсальный жилой модуль, который можно было бы развернуть на поверхности любой планеты — газового гиганта, планеты с высокой температурой, планеты земного типа». Подобную задачу еще никто не решал, поэтому непонятно, какие материалы, технологии, формы и т.д. будут оптимальными.

У каждой системы свои особенности, каждая требует своих подходов. Если подобрать неверный формат управления, проект может попросту развалиться.

Что такое постановка задачи в ИТ? Когда есть задача покрасить стены, рисков нет. Когда есть задача поставит товар, процесс тоже по большому счету предсказуем. В ИТ же реализация чего-либо — начало выяснения, как это нужно сделать.

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

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

Если вы управляете проектом как сложным, команда не знает целей и метрик и видит только задачи, которые вы ставите. На момент постановки над задачей уже поработали множество бизнес-аналитиков, много времени было потрачено на бессмысленные обсуждения архитектуры проекта (ее обсуждать полезно, но бюрократия не должна быть в приоритете).

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

Противовес сложным системам — отсутствие какого бы то ни было планирования (и тогда проект становится хаотичным). Вам показалось, что сегодня важны задачи № 1, 2 и 3. Завтра возникли какие-то иные обстоятельства — и стали важнее задачи № 4, З и 6. В таких проектах планы больше чем на неделю вперед отсутствуют, все баги одинаково важны, важность фичи определяется положением того, кто ее поставил. Цели, метрики, архитектурные схемы — все ситуативно. Соответственно и статус согласований может быть хаотичным.

Что характерно и для сложных, и для хаотичных методов управления запутанными проектами:

  1. У участников проектов нет доверия к утверждениям, а следовательно, мозг отключается по цепочке, никто не предложит сделать лучше, потому что это может вызвать искажение оценки.
  2. Все победы по умолчанию приписаны заказчику, неудачи — исполнителю (подрядчику).
  3. Гипотезы слабо основаны или даже вовсе не основаны на метриках.
  4. Время выгорания исполнителей на проекте конечно, традиционные перформансы вроде «выпить вместе» не работают или работают слабо, так как реальных побед на проекте нет.

Так что, если вы затрудняетесь назвать внятную цель проекта и измеряющие ее метрики, а сами измерения производятся ситуативно и не обсуждаются при формировании пула работ, если никто не мыслит в терминах гипотез, основанных строго на метриках, и вы не «мечтаете вместе» о том, к чему нужно прийти, проект может постоянно находиться в состоянии затухания.

Проблемы на стороне исполнителя

Проблема № 1. Низкое качество менеджмента

Для выполнения задачу нужно понять и правильно реализовать. На наш взгляд, клиентов (и внешних, и внутренних), которые в состоянии точно объяснить свои цели, не существует. Отношения с подрядчиком усугубляются фактором культуры, где опыт в условном управлении закупкой кирпича перекладывается на управление запросами на изменение программного обеспечения, а исполнитель воспринимается как «руки», а не как «голова».

Соответственно, менеджмент исполнителя должен обладать практикой сбора и уточнения требований. А парадигма производства — учитывать реакцию на изменения и возможность их внесения в процессе работы, поскольку такие точно будут.

К сожалению, мы не знаем «серебряной пули», универсально описывающей хорошего исполнителя с точки зрения менеджмента. Но можно составить антипаттерн — каким исполнитель быть не должен.

В позиции «вы скажите, как надо, мы сделаем» требуются подробное техническое задание и прочие артефакты, подразумевающие затраты массы времени на то, что все равно поменяется:

  • со стороны исполнителя обеспечивается слабый аудит бизнес-процессов; исполнитель не сильно интересуется назначением задачи и тем, на что она влияет, а ведь все это поможет уточнить и лучше описать процесс;
  • со стороны исполнителя нет принятых внутри команды фреймворков, как описывать задачи и процессы.

Выбранный фреймворк работ не предполагает изменений в процессе реализации: нет прозрачных механизмов контроля выполняемых работ и прочих артефактов, которые упрощают внесение изменений.

Когда исполнитель выступает только как «руки» и не доверяет просмотр своего производства заказчику:

  • процедура технического или организационного контроля скрыта от глаз заказчика;
  • нет прозрачности в команде и временных затратах.

Проблема № 2. Недостаточный уровень технологической экспертизы

Дело может быть в низком качестве разработки. В целом, если такая проблема обнаруживается, ее довольно легко быстро исправить — или в рамках работы с тем же подрядчиком, или как-то иначе. На сегодняшнем «красном» рынке (который гоняется за высококвалифицированными кадрами) сильно снижается порог квалификации. Мы неоднократно сталкивались с тем, что разработчики или менеджеры уровня junior, которые не подходили нам по каким-то причинам, в другие компании были приняты как senior-специалисты и проработали там достаточно долгое время.

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

Product Owner, 9 стейкхолдеров и внешняя команда: как разработать продукт
Менеджмент Инструкции Pinkman
Фото:Shutterstock

Другие возможные проблемы

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

Однако на рынке встречаются ниши, чье состояние сильно отличается от среднего. Это связано с особенностями аудитории конкретных продуктов. Например, ограничения бюджета сказываются на команде разработки, в которой сложно полноценно развивать инженерную экспертизу. Скажем, «Битрикс» достаточно часто выбирают маркетологи,
а компании-разработчики в основном состоят из посредственных разработчиков и специалистов по конфигурации. Поэтому хорошего подрядчика на такое направление найти будет непросто.,>

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

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

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

А если система была написана с множеством «уникальных» решений, никто потом не сможет подхватить и поддерживать этот проект (предупредить подобную проблему можно выбрав решение, если это оправдано архитектурой проекта).

Как не допустить запущенного состояния

Путь выбора подрядчика не линеен, однако чем больше вы экспериментируете, тем выше вероятность повысить «насмотренность» и найти свою команду.

Думаем, что ни рейтинги, ни премии, ни награды не могут быть знаком инженерной и менеджерской культуры. Скорее они доказывают наличие или отсутствие в компании РК-отдела.

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

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

Если вы не можете позволить себе дорогой ИТ-аутсорсинг, попробуйте решить свои задачи минимальной разработкой или вообще без нее. Это вполне реализуемо, когда речь идет о стандартных процессах. Сейчас есть много готовых решений, no-соdе- и lowe-code-инструментов. Чем меньше на проекте уникальных и самописных решений, тем проще при необходимости сменить подрядчика и тем стабильнее будет работа. В любом случае на пути no-code- и lowe-code-решений у вас сформируется больше практических соображений, что нужно делать и какие требования к эксплуатации действительно важны.

Заключение

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