Как грамотно учесть риски и убедить клиента работать с украинской компанией

29 апреля 2022

  • Автор: Александр Крючков

  • Сложность: норм

  • Время: 3 мин

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

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

Новые вызовы для РМ-ов

Команды стали более распределенными. При этом распределенность стала непредсказуемой. Любой сотрудник может поменять локацию в течение нескольких часов. У него может быть плохая связь или не быть связи вообще. Многие из тех, кто выехал в первые часы войны, оказались в очень «далеких» тайм-зонах: Канада, США, Мексика и т.д.

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

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

Компании с офисами вне Украины на этапе пресейла часто еще не знают, из какой локации будет формироваться команда.

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

Как убедить клиента работать с вами

Дам несколько рекомендаций, которые помогут учесть военные риски при планировании проекта на этапе пресейла, а также убедить клиента в том, что ваша команда выполнит коммитменты даже в текущей ситуации.

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

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

Например, фокус-фактор 0.7 означает, что для получения реальной длительности задачи «идеальные» часы нужно разделить на 0.7. Для учета меньшей работоспособности людей, а также факторов плохой связи и возможной смены состава команды имеет смысл заложить в расчеты более низкий фокус-фактор. 

Если вы вместо фокус-фактора используете другие инструменты — проделайте с ними аналогичные действия. Так ваш прогноз станет более реалистичным.

Практикуйте коллективное владение кодом и документацией, а если шире — вообще знаниями о проекте. Эта концепция не нова, но не всегда применяется в полной мере. Сейчас — самое время внедрить коллективное владение как можно полнее. Тут помогут peer-to-peer code review, ротация инженеров между фичами, коллективное/парное обсуждение технических решений.

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

Для парной работы сотрудников возможны две схемы:

  • 2×1 FTE вместо 1×1 FTE — снижает риски и ускоряет работу (если позволяет бюджет)
  • 2×0.5 FTE вместо 1×1 FTE — снижает риски и замедляет работу (больше коммуникации) + трудности с ресурсным планированием, а еще иногда может не найтись проекта, куда можно отправить «вторые половинки». 

Перевезите сотрудников в западные области Украины или за границу (по возможности) — это очевидный пункт, который применили уже, наверное, все.

Выработайте общую рейт-карту вне зависимости от локации. Скажем, у вас есть офис в Украине и Болгарии. У них разные внешние рейты. На этапе пресейла вы не всегда знаете, будет ли вся команда украинской, болгарской или смешанной. На состав могут повлиять и предпочтения клиента, и доступность сотрудников на бенче.
Конечно, можно дать клиенту две рейт-карты, но это усложнит ему картину мира и может негативно повлиять на выбор вас как вендора. А можно посчитать бюджет, взяв для каждой роли наибольший рейт между локациями или средний (в зависимости от ваших таргетов по маржинальности) — так у клиента будет универсальная рейт-карта, а вы получите гибкость в выборе локаций.

баннер Supreme PM

Демонстрируйте прозрачность перед клиентом. Чтобы убедить клиента в вашей надежности, покажите ему те меры, которые предпринимаете для минимизации рисков, включая упомянутые выше. Здесь важно говорить лишь о том, что вы реально делаете. Если клиент поймет, что вы приукрашиваете реальность — он точно уйдет и будет прав.

Прозрачность предполагает:

  • ознакомление клиента с планом действий на случай изменения/ухудшения ситуации в конкретной локации;
  • информирование о том, где находятся члены команды;
  • частое (ежедневное/еженедельное) информирование клиента об изменении ситуации;
  • информирование об исполнении выработанного ранее плана по рискам;
  • признание самого факта военных рисков. Отрицая их и повторяя мантру «всё нормально», вы только отпугнете клиента — он решит, что вы неадекватно воспринимаете реальность.

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

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

Александр Крючков

17 лет опыта в IT, Senior PM, Program Manager, Head of Presale Сейчас работает Head of Presale в Avenga, до этого был Program Manager в Ciklum. 17 лет опыта в IT, 14 из которых управлял проектами и программами численностью до 120 человек. Специализируется на работе в аутсорсинге разработки программного обеспечения. Спикер и ментор курса Supreme PM.