Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

3.4.1. Паралич решений

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

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

Комплекс вины первопроходца

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

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

3.4.2. Определите, на чем основывается ваше видение

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

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

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

Предположим, в рамках своего видения вы планируете перейти к архитектуре на основе API, чтобы отделы компании и клиенты могли получать нужные им данные и использовать сервисы. Опорой здесь будет технология предоставления безопасного и масштабируемого API. Допустим, вы остановились на технологии HTTP REST, а для передачи токена защиты выбрали формат JWT. Это не ограничивает дальнейший выбор языка или фреймворка, но предоставляет конкретную методологию, которая позволяет сфокусироваться на деталях реализации.

Другой пример: вы основываете свое видение на том, что сбор данных и управление ими представляет особую важность и необходимо обеспечить хранение больших объемов данных без потери производительности. Ваша опора здесь – хранение и управление данными. Не заморачивайтесь – используйте озеро данных (модный термин для обозначения хранения большого объема данных независимо от их формата) для хранения, а затем решите, как и где обрабатывать эти данные. Например, для начала прекрасно подойдет AWS S3.

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

3.4.3. Контролируйте состояние опор

Определив опоры, не забывайте следить за ними. Вам необходимо видеть, как они развиваются и внедряются, и понимать, какое место они занимают в вашем видении, чтобы их развитие не приводило к проблемам. Если вы правильно определили опоры – выбрали то, что не является частью вашего бизнеса, но от чего он зависит – значит, в какой-то момент кто-то попытается превратить их в товар.

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

Облачный подход, или, другими словами, коммодитизация (commoditization), – это этап развития процесса или технологии, на котором они становятся достаточно значимыми, инновационными и конкурентоспособными, чтобы превратиться в общедоступный продукт. Два хороших примера – веб- и почтовые серверы. Также в последнее время создавать и поддерживать собственный кластер серверов баз данных стало дороже, чем заказать БД-как-услугу (database-as-a-service) у одного из крупных облачных провайдеров, то есть базы данных тоже перемещаются в облако. Раньше у вас была целая команда администраторов баз данных, которая занималась резервным копированием, оптимизацией и аварийным восстановлением, а сейчас все это можно сделать одним щелчком мыши в браузере. Некоторые считают, что при этом утрачивается контроль, но на самом деле это означает, что теперь есть целый ряд технологий, которыми больше не нужно управлять.

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

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

3.4.4. В поисках простоты

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

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

Невозвратные затраты

Любой хороший игрок в покер скажет: если вы видите, что ваша рука не выигрывает, – выходите из игры, и неважно, сколько денег вы поставили. В бизнесе это называется невозвратными затратами. Да, вы вложили много ресурсов и поэтому хотите довести дело до конца, даже если понимаете, что шансы на успех невелики. Я видел такое много раз, обычно все заканчивается переходом либо на AWS, либо на Azure. Многие команды разрабатывали сложные и трудоемкие системы, но потом появлялся AWS с готовым сервисом – и всю работу приходилось выкидывать. Возникает вопрос: следует ли команде в такой ситуации продолжить разработку или же изменить план? Вашей первой реакцией должно быть следование первоначальному плану, тем временем присмотритесь к сервису и убедитесь, что в нем есть все, что вам нужно. После этого вы сможете перейти на готовый сервис, таким образом уменьшив операционную нагрузку, и затем перейти к следующим большим задачам.