Смена ИТ-подрядчика

Логотип компании
Смена ИТ-подрядчика
Как понять, что исполнителя пора менять и на какие маркеры обращать внимание при выборе нового партнера.
Когда с проектом начинаются проблемы, заказчик в первую очередь думает: «Что-то не так с исполнителем». И решает его сменить. Возможно, дело действительно в исполнителе. Но чтобы не повторить опыт неудачного сотрудничества, нужно точно локализовать проблему. Мы в kt.team подготовили небольшой гайд, объясняющий, на что обратить внимание в работе ИТ-подрядчика (или внутренней команды) и заказчика.

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

Что делать в этой ситуации: «добивать» проект с нынешней командой, менять исполнителя, искать ошибки на своей стороне? И не усугубит ли ситуацию любое из этих решений?

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

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

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

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

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

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

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

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

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

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

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

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

Вы, конечно, можете пытаться управлять запутанной средой, как сложной – подготовив техническое задание и все прочее (см. фреймворк Cynefin, дао Toyota, Agile Manifesto и пр.). Но мы в жизни не видели ни одного технического задания, которое соответствовало бы конечной реализации, как не видели ни одного согласованного дизайн-макета, который не корректировался бы в процессе реализации.

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

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

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

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

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

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

  2. Все победы по умолчанию приписаны заказчику, неудачи – исполнителю (подрядчику).

  3. Гипотезы слабо основаны на метриках или не основаны на них вовсе.

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

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

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

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

Для выполнения задачи ее нужно понять и правильно реализовать.

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

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

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

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

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

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

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

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

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

  • нет прозрачности в команде и временных затратах.

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

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

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

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

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

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

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

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

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

С маленькими командами, не располагающими достаточной инженерной экспертизой, случаются и другие проблемы. Часто молодые разработчики говорят, мол, мы эту задачу сейчас решим за пять секунд. Пишут свою систему, а потом теряют интерес к проекту. А если система была написана с большим количеством «уникальных» решений, то потом никто не сможет подхватить и поддерживать этот проект (предупредить подобную проблему можно, выбрав low-code-решение, если это оправдано архитектурой проекта).

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

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

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

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

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

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

Заключение

Обычно считается, что если клиент недоволен подрядчиком, подрядчик тоже недоволен клиентом – это всегда обоюдная история. Значит, есть явный конфликт, и если бы он был решаемым, то уже и решился бы.

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

Опубликовано 20.04.2021

Похожие статьи