После начала войны 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 — снижает риски и замедляет работу (больше коммуникации) + трудности с ресурсным планированием, а еще иногда может не найтись проекта, куда можно отправить «вторые половинки».
Перевезите сотрудников в западные области Украины или за границу (по возможности) — это очевидный пункт, который применили уже, наверное, все.
Выработайте общую рейт-карту вне зависимости от локации. Скажем, у вас есть офис в Украине и Болгарии. У них разные внешние рейты. На этапе пресейла вы не всегда знаете, будет ли вся команда украинской, болгарской или смешанной. На состав могут повлиять и предпочтения клиента, и доступность сотрудников на бенче.
Конечно, можно дать клиенту две рейт-карты, но это усложнит ему картину мира и может негативно повлиять на выбор вас как вендора. А можно посчитать бюджет, взяв для каждой роли наибольший рейт между локациями или средний (в зависимости от ваших таргетов по маржинальности) — так у клиента будет универсальная рейт-карта, а вы получите гибкость в выборе локаций.
Демонстрируйте прозрачность перед клиентом. Чтобы убедить клиента в вашей надежности, покажите ему те меры, которые предпринимаете для минимизации рисков, включая упомянутые выше. Здесь важно говорить лишь о том, что вы реально делаете. Если клиент поймет, что вы приукрашиваете реальность — он точно уйдет и будет прав.
Прозрачность предполагает:
- ознакомление клиента с планом действий на случай изменения/ухудшения ситуации в конкретной локации;
- информирование о том, где находятся члены команды;
- частое (ежедневное/еженедельное) информирование клиента об изменении ситуации;
- информирование об исполнении выработанного ранее плана по рискам;
- признание самого факта военных рисков. Отрицая их и повторяя мантру «всё нормально», вы только отпугнете клиента — он решит, что вы неадекватно воспринимаете реальность.
Стоит отметить, что время здесь часто работает на вас: если обеспокоенный клиент в течение нескольких недель видит, что вы успешно справляетесь с ситуацией, он со временем успокоится и не станет форсировать тему перехода к другому вендору.
Буду рад, если эти рекомендации будут полезны читателям. И конечно же, надеюсь, что уже совсем скоро они перестанут быть необходимыми.