Текст книги "Настоящий CTO: думай как технический директор"

Составляя план своего видения, ответьте на следующие вопросы:

• Какую глобальную проблему вы хотите решить? Формулирование проблем поможет вам аргументированно ответить на вопрос «зачем», когда бизнес задаст вам его.

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

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

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

• Кто вам требуется для достижения успеха? Есть ли сотрудники, от которых зависит успех вашего видения, насколько эти люди важны для текущих повседневных задач и как компенсировать их отвлечение от этих задач?

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

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

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

3.4. Работа с постоянными изменениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во времена интереса к большим данным популярным инструментом был Apache Hadoop, распределенная система для управления большими наборами данных на нескольких серверах. Это был отличный инструмент, но настоящий кошмар для управления и обслуживания. Тем не менее только с его помощью можно было управлять наборами данных, которые не помещались на одном жестком диске. Навыки работы с Hadoop были настолько востребованы, что их обладатели просили очень много денег. Но эта специализация исчезла в одночасье, когда поставщики облачных услуг стали предлагать «большие-данные-как-сервис» (например, сервис Amazon S3). Хотя это был огромный удар для тех, кто специализировался на работе с Apache Hadoop, компании, которые стремились избавиться от накладных расходов на Hadoop, получили большие преимущества.

Рано или поздно все меняется. На момент написания этой книги отрасль переживала очередное кардинальное изменение в области управления серверами – даже эта базовая сфера перестала быть необходимой: «бессерверные вычисления» подразумевают отсутствие необходимости управлять какими-либо серверами вообще. Многие внутренние проекты теряют актуальность по мере того, как бессерверная архитектура получает все более широкое признание. Сильное видение приветствует изменения и воспринимает их как выгоду в плане общего снижения сложности.

3.5. Презентация для лифта

Что вы должны быть способны делать, не задумываясь, – так это объяснить свое видение любому, кто о нем спросит, кратким и понятным языком. Представьте сотрудников с разным набором навыков и опытом в вашей компании. Подумайте, как объяснить им ваше видение так, чтобы они впечатлились и поддержали вас в его реализации, ведь, скорее всего, рано или поздно их оно тоже затронет. Тем не менее перевод с языка гиков на общеупотребительный для кого-то может стать очень трудной задачей. Однажды освоив это умение, вы сможете использовать его снова и снова во всех аспектах роли технологического лидера (особенно при попытках объяснить своим родителям, чем вы занимаетесь; «он работает с компьютерами» – так моя мама говорит своим друзьям).

История

Презентация для лифта

Единого мнения о происхождении этого термина нет. Некоторые утверждают, что он возник в 1990-е годы; другие – что в 1970-е, а одна история относится к 1850-м годам, когда инженер Отис разработал лифт собственной конструкции. Лично мне наиболее правдоподобной кажется версия с журналистами Vanity Fair, которым никак не удавалось обсудить свои идеи статей с главным редактором. Чтобы решить эту проблему, они подкарауливали ее в лифте и там рассказывали ей свои соображения.

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

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

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

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

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

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

3. Отложите этот список хотя бы на одну ночь – это важно; на обдумывание списка требуется время, поэтому дайте мозгу возможность обработать его, пока вы спите.

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

5. Отложите получившийся список из шести пунктов хотя бы на час. Последняя проверка позволит убедиться, что остались именно те шесть пунктов, которые нужны.

6. Расположите шесть пунктов в порядке важности. Теперь расположите их в порядке важности для бизнеса.

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

8. Придумайте захватывающее начало – найдите такую вступительную фразу, которая увлечет собеседника и заставит его слушать вас следующие 20 секунд, пока вы проходите по списку. Это может быть формулировка проблемы, которую вы хотите решить («Нам нужно подключать клиента за несколько часов, а не за месяцы, как сейчас»), или отсылка к известному понятию («Представьте, что вы – Uber в сфере страхования имущества, поскольку предоставили клиентам возможности взаимодействовать с HomeMax самостоятельно»).

Вот так просто. Финальный список вас устраивает? Ничего важного не упустили? Теперь пусть все это немного отлежится, и можно переходить к практике.

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

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

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

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

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

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

3.6. Составление бюджета

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

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

Несложно понять, почему эта точка зрения ошибочна. Дело тут не в том, оплачивается уже работа этих сотрудников или нет, а в том, для чего они изначально были наняты. Если они частично или полностью будут заняты реализацией вашего видения – значит, они, вероятно, не смогут работать над другими задачами. Пострадает ли от этого какая-то область бизнеса, которая перестанет получать нужные ресурсы и поэтому будет нуждаться в дополнительной поддержке? Скорее всего. В любом случае, необходимо учесть расходы на каждого человека, работающего над проектом. Не забудьте про ежегодную индексацию зарплаты (а также другие бонусы, если вы планируете их выплачивать), потому что в большинстве компаний принято каждый год увеличивать заработную плату на несколько процентов (2–5 %, в зависимости от результатов/инфляции).

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

Парадокс дефляции облака

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

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

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