Масштабное видение требует значительных усилий для планирования и реализации. В основе хорошего видения лежит необходимость, а не действие. Подходящие тому примеры – проекты серьезной модернизации и обновления устаревших систем (например, в нашей компании HomeMax). Они могут занимать несколько лет, в течение которых также продолжает использоваться и поддерживаться существующая система. Предпринимая такой радикальный, хотя и потенциально выгодный проект, вы должны очень хорошо понимать, как будет реагировать бизнес и насколько он готов поддержать вас как финансово, так и испытывая неудобства.

Если вы не сможете обеспечить эту поддержку – вы потерпите неудачу, не успев написать ни одной строчки кода и не запустив ни один сервис. Вы должны думать как бизнес: в чем необходимо быть уверенным, прежде чем приступать к работе?

Первое, что нужно учитывать, – график работы компании. У вас сезонный бизнес? Компании, в которых можно вносить изменения в сервисы в любой период года, встречаются редко. Например, ретейлеры (как онлайн-, так и офлайн-продавцы), скорее всего, не будут вносить серьезные изменения или делать релизы в сезон высоких продаж, например во время распродаж после Дня благодарения или в рождественский сезон, а компании, работающие в сфере образования, не захотят внедрять изменения в начале учебного года или во время сессий. Определите эти периоды и спланируйте свою работу в соответствии с ними. В организациях, в которых есть подобная сезонная нагрузка, порой приходится прекращать разработку новых продуктов на 3–4 месяца в год и перераспределять ресурсы на поддержку систем.

Не стоит недооценивать время, которое требуется для переключения контекста при переходе с проекта на проект, особенно если команда не работала над проектом несколько месяцев – с ноября по январь, учитывая выходные.

Заметки с полей

Двигайтесь шаг за шагом

Одна частная инвестиционная компания привлекла меня, чтобы я оценил план ее технического директора, который смущал своей амбициозностью. План был хорошим: это был проект модернизации, направленный на снижение зависимости компании от центров обработки данных и переход в облако. Проблема заключалась в том, что CTO делал сразу большой скачок от традиционного подхода с использованием серверов к облачной архитектуре – слишком много изменений, связанных со значительным риском. Я предложил добавить в план менее крупные шаги, чтобы разогреть бизнес и добиться нескольких побед, тем самым укрепив его уверенность и веру в это видение. Например, выделить самые старые серверы и заменить их на облако, вместо того чтобы покупать новое оборудование. Да, это не полностью облачное решение, но, уменьшая зависимость от аппаратного обеспечения, мы двигались к финальной цели, демонстрируя бизнесу преимущества на этом пути и знакомя его с новой сферой виртуальной инфраструктуры и тем самым давая ему время на адаптацию, чтобы продолжать двигаться вперед.

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

То же и с видением; разделите его на кусочки размером с укус, которыми бизнес будет лакомиться и чувствовать прогресс. Определите, какие области можно разбить на части и предоставить бизнесу. Это должно быть то, что принесет ему реальную выгоду немедленно.

Если бизнес будет видеть пользу от вашего видения уже на ранней стадии и регулярно, его желание поддерживать и финансировать вас не уменьшится. А если (когда?) вы обнаружите, что начали буксовать, ваши прошлые достижения способствуют тому, что бизнес представит вам больший кредит доверия, чем мог бы.

Хуже всего, если сроки реализации проекта затянутся, а дата релиза будет отодвигаться все дальше. Ваше лидерство будет поставлено под сомнение, и бизнес может потерять к вам доверие и сократить финансирование. Да, это наихудший сценарий, но не такой уж редкий, даже несмотря на благие намерения.

Сим нарекаю тебя…

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

Мы называем вещи, чтобы придать им индивидуальность, наделить эмоциями. Мы привязываемся к вещам, которые имеют название, и поэтому желаем им успеха. Вот почему я дал своим трем сыновьям имена, а не просто назвал их Ребенок № 1, Ребенок № 2 и Ребенок № 3, хотя, честно говоря, так было бы намного проще. Хорошее название проекта вдохнет жизнь в ваше видение и позволит каждому вложить в него эмоции.

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

Хорошее название, например «Проект Гэндальф» (так назывался проект трансформации устаревшей системы, состоявший из двух этапов: «Гэндальф Серый», а затем «Гэндальф Белый») или «Позывной Борг» (для описания создания большого хранилища данных), формирует ассоциации с определенным сюжетом, чтобы помочь участникам проекта представить общую цель и сосредоточиться на ней. Одним из лучших названий, которое я встречал, было «Платформа Гамп». Так называлась система для управления устройствами Интернета вещей (IoT), которая, среди прочего, должна была работать непрерывно (вспомните, что Форрест Гамп должен был бежать без остановки).¹