Роб Цубер, технический директор CircleCI, опираясь на свой опыт взращивания технологических стартапов, обсуждает на портале Information Age, какова цена технологических изменений для бизнеса и как ее минимизировать.

Всегда полезно знать, как трансформация стратегии повлияет на организацию, независимо от того, является ли она стартапом или давно сформировавшейся компанией.

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

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

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

Какова стоимость изменения?

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

Драйверы этих изменений развиваются по мере роста бизнеса. На ранних этапах, при попытке выяснить соответствие продукта рынку, масштаб изменений огромен. Есть много известных примеров: система подкастинга под названием Odeo стала Twitter; игровой движок под названием Tiny Speck стал Slack; онлайновая ролевая игра под названием Ludicorp стала Flickr; операционная система для камер — Android OS. Должно быть ясно, что готовность к кардинальным изменениям — это то, что позволяет бизнесу найти нужный продукт, подходящий для рынка.

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

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

Не идите на расходы до тех пор, пока не будете уверены, что они принесут ценность

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

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

  • избегать любых решений, которые вы могли бы принять позже;
  • использовать как можно больше из уже имеющегося.

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

Вот пример: если бы в 2016 г. вы выбирали платформу оркестровки контейнеров, то было бы примерно 20% шансов на то, что вы выбрали бы Kubernetes. Это означает, что к началу 2018 г. почти 80% компаний пришлось бы поменять выбор. Если нет очевидного выбора, то отсрочка будет лучшим решением. Однако откладывать до возникновения кризиса не стоит. Вам нужны гибкий ум и вдумчивый подход с частыми возвращениями к одним и тем же вопросам.

Не влюбляйтесь в экзотические технологии

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

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

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

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

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

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