Read the book: «Настоящий CTO: думай как технический директор»

Name: Настоящий CTO: думай как технический директор
Author: Alan Williamson
ISBN: 978-5-4461-2114-4

Font::

* * *

Я посвящаю эту книгу моему давнему другу и наставнику Джиму Милбери (Jim Milbery), коллеге-спецу (только не давайте ему программировать) и партнеру-основателю ParkerGale Capital. Джим оказал огромное влияние на мою профессиональную и личную жизнь (и даже познакомил меня с моей будущей женой). Я также посвящаю эту книгу моей дорогой покойной маме, которая была с нами в начале этого пути и прочла несколько первых глав, но так и не добралась до финала.

Вступительное слово

Книга «Настоящий CTO: думай как технический директор» – исчерпывающее и вдохновляющее руководство о том, как стать техническим директором и преуспеть в этой роли в современном мире. Эта книга помогает начинающим техническим директорам глубже понять основы, а опытным специалистам – отточить свои навыки. Мне нравится, что в этой книге собрано все, что необходимо грамотному руководителю в сфере технологий, и что акцент в ней сделан на личность руководителя. Если вы уже работаете техническим директором, раздел «Проверьте себя» в конце каждой главы послужит вам стратегическим руководством и ви́дением, которое вы сможете воплощать в работе.

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

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

Один из моих любимых разделов в книге – глава 6 «Управление командой». На мой взгляд, вы вкладываете больше всего времени и внимания в людей, которыми вы управляете и которых ведете за собой. Без этих людей вы потерпите неудачу. Точка. Если вы приложите усилия к созданию атмосферы сотрудничества, где люди будут чувствовать себя самостоятельными и имеющими полномочия, чтобы идти вперед, быстро учиться на ошибках и расти в безопасных условиях, вы добьетесь максимально возможного. Технологии – едва ли не самая простая часть работы технического директора. Все дело в людях, которые приведут вас либо к успеху, либо к краху.

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

Надеюсь, «Настоящий CTO: думай как технический директор» понравится вам так же, как и мне. Советов, представленных в этой книге, давно не хватало технологическим лидерам.

– Анкит Матур (Ankit Mathur), основатель и СТО ROUNDTRIP HEALTH, основатель PRESS PLAY TECNOLOGIES

Предисловие

Технический директор (CTO, Chief Technology Officer) – одна из самых интересных и плодотворных ролей в карьере технического специалиста. Технический директор определяет направление работы компании, открывает новые возможности, создает новые линейки продуктов, улучшает рабочие процессы и оказывает огромное влияние на все отделы.

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

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

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

Устройства становятся все меньше по размеру и все более связанными друг с другом, а интернет вещей проникает почти во все, что включено в розетку (и порой в то, что не включено). Блокчейн продвигает открытые и прозрачные взаимодействия. Языки и фреймворки становятся мощнее и быстрее. Обычные разработчики стали настолько далеки от логистики управления процессором и памятью, что не каждый из них даже осознает существование ограничений: если код выполняется медленно, иногда бывает дешевле увеличить вычислительную мощность, чем тратить время на оптимизацию алгоритмов.

Кроме того, хакеры постоянно угрожают нашим системам. Программы-вымогатели нарушают работу государственных служб, наглядно демонстрируя, как плохая архитектура может поставить страну на колени. Мы стали свидетелями этого, когда в мае 2021 года хакеры вывели из строя нефтепровод на восточном побережье США, что привело к нехватке бензина на заправках, продолжавшейся более недели. И это не единичный случай. Представьте, что в то утро вы проснулись директором, отвечающим за техническую часть этого нефтепровода, – как вы будете действовать?

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

Эта книга родилась из-за необходимости заполнить пробелы в подготовке как компании, так и отдельного сотрудника к роли технического директора. Я написал ее после многих лет работы в компаниях разного размера – от стартапов до малого и среднего бизнеса (чей доход обычно не превышает 100 миллионов долларов) – в качестве штатного CTO или временно исполняющего обязанности CTO для портфельных компаний как в сфере прямых инвестиций, так и вне ее.

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

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

Эта книга – именно то, чего мне не хватало тогда, и то, что у вас есть сейчас.

Благодарности

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

Большое спасибо моим близким друзьям, Джиму Хедли (Jim Headley) и Райану Берчу (Ryan Burch), за поддержку и вдохновение по многим затронутым темам. На протяжении всей книги я упоминаю имена тех, кто поделился своим опытом и идеями, – спасибо вам, без вашей помощи все было бы иначе.

Конечно же, я благодарю своих родителей, которые потакали капризам 10-летнего мальчика и потратили месячную зарплату на ZX Spectrum, чтобы ребенок проверил, есть ли у этой «компьютерной штуки» будущее. Учитывая, что я полностью износил его резиновую клавиатуру, думаю, что инвестиции себя оправдали.

Наконец, я выражаю огромную благодарность всем и каждому в Manning, особенно Дастину Арчибальду (Dustin Archibald), который помог мне придать каждой главе законченную и осмысленную форму. За каждым великим писателем стоит еще более великий редактор. Я также благодарю Дейдру Хайэм (Deirdre Hiam), редактора моего проекта; Памелу Хант (Pamela Hunt), литературного редактора; и Кэти Теннант (Katie Tennant), корректора.

Всем рецензентам – Адаму Дудчаку, Адриану Билаука, Адриану Росси, Андреасу Бродманну, Антонио Бруно, Арони Пани, Бурку Гюнешу, Чаду Миарсу, Крису Хенегану, Крису Томасу, Кристиану Уиттсу, Данило Зековичу, Десмонду Хорсли, Дираджу Гупте, Дориану Басуяу, Флавио Диесу, Франческо Персико, Гэвину Бауманису, Гордану Бэкингему, Хироюки Муше, Йоханнесу Лохманну, Джону Маккормаку, Джону Вуду, Юре Шикину, Кевину Пелгримсу, Леонардо Анастасии, Матею Страшеку, Мэтту Фердереру, Майку Оверу, Николя Модшику, Нику Римингтону, Павло Ходышу, Павелу Климчику, Рику Оллеру, Сету Коупленду, Широшике Кулатилаке, Симоне Кафьеро, Стефану Мучлеру, Тьяго Больдту Соузе, Виллему ван Кетвичу, Уильяму Руденмальму (Adam Dudczak, Adrian Bilauca, Adrian Rossi, Andreas Brodmann, Antonio Bruno, Aroni Pani, Burc Gunes, Chad Miars, Chris Heneghan, Chris Thomas, Christian Witts, Danilo Zekovic, Desmond Horsley, Dhiraj Gupta, Dorian Basuyau, Flavio Diez, Francesco Persico, Gavin Baumanis, Gordan Buckingham, Hiroyuki Musha, Johannes Lochmann, John McCormack, John Wood, Jura Shikin, Kevin Pelgrims, Leonardo Anastasia, Matej Strašek, Matt Ferderer, Mike Over, Nicolas Modrzyk, Nik Rimington, Pavlo Hodysh, Pawel Klimczyk, Rick Oller, Seth Copeland, Shiroshica Kulatilake, Simone Cafiero, Stefan Mutschler, Tiago Boldt Sousa, Willem van Ketwich, William Rudenmalm) – спасибо; ваши предложения помогли сделать эту книгу лучше.

О книге

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

Каждая глава посвящена одной из сфер ответственности СТО. Я подробно рассмотрю их, выделяя соображения, о которых следует помнить, и стратегии управления каждой из этих сфер. Однако это не кулинарная книга технологий. Я не буду рекомендовать Java вместо C#, или Amazon вместо Azure, или облако вместо центра обработки данных.

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

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

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

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

Эта книга содержит множество практических примеров, иллюстрирующих затронутые темы, а также множество реальных историй о проблемах, с которыми столкнулись технические директора и которые им удалось преодолеть. В рамках своих обязанностей в MacLaurin Group, а теперь и в частной инвестиционной компании New Harbour Capital я работаю с техническими директорами из различных отраслей и в сфере прямых инвестиций, оказывая им поддержку, менторство и консультируя по конкретным проблемам, с которыми они сталкиваются.

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

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

Итак, работаете ли вы в одиночку или руководите командой из 100 инженеров, из книги вы узнаете, что нужно, чтобы стать успешным CTO.

Для кого эта книга

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

• Опытный технический специалист, желающий перейти на следующую ступень карьеры – к роли технического директора.

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

• Опытный технический директор, чья компания быстро растет и у которого нет ответов на задаваемые вопросы.

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

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

Структура книги

В книге 15 глав:

• В главе 1 рассматривается, кто такой технический директор и какие бывают разновидности этой должности, а также какова роль технического директора в организации.

• Глава 2 посвящена взаимодействию СТО с различными сотрудниками в организации – от генерального директора до коллег.

• Глава 3 посвящена разработке видения роли технического директора в организации.

• В главе 4 описаны некоторые рекомендации по созданию команды.

• В главе 5 показано, как подбирать будущих членов команды, проводить собеседования и принимать на работу новых сотрудников.

• Глава 6 посвящена управлению командой.

• В главе 7 объясняется процесс проведения ежегодных ревью.

• Глава 8 поможет принимать технологические решения.

• Глава 9 посвящена управлению проектами и информированию организации о ходе их выполнения.

• Глава 10 объясняет, как работать с договорами.

• Глава 11 посвящена созданию документации и работе с ней.

• В главе 12 приводятся некоторые важные соображения, касающиеся безопасности компании.

• В главе 13 рассматриваются дополнительные соображения, которые необходимо учесть в работе.

• Глава 14 посвящена управлению ростом компании.

• Глава 15 посвящена определению и анализу вашего собственного прогресса и планов на будущее.

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

Форум liveBook

Приобретая книгу «Настоящий CTO: думай как технический директор», вы получаете бесплатный доступ к закрытому веб-форуму издательства Manning (на английском языке), на котором можно оставлять комментарии о книге, задавать технические вопросы и получать помощь от автора и других пользователей. Чтобы получить доступ к форуму, откройте страницу https://livebook.manning.com/book/think-like-a-cto/discussion . Информацию о форумах Manning и правилах поведения на них см. на https://livebook.manning.com/#!/discussion.

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

Об авторе

АЛАН УИЛЬЯМСОН более 25 лет работает в области данных и технологий, внес свой вклад в спецификацию ключевых серверных Java API, создав использовавшийся в MySpace первый в мире движок CFML, написанный на Java. Он стал первым евангелистом Java (Java Champion) в Великобритании и опубликовал несколько книг по Java, посвященных Java Enterprise, сервлетам, JavaMail и работе с базами данных.

Он работал с частными инвестиционными компаниями более 15 лет, создавая и развивая команды, а также выполняя функции технического директора в ряде портфельных компаний. Алан являлся техническим директором и партнером MacLaurin Group и поддерживал деятельность портфельных компаний, консультируя технических директоров и системных архитекторов. Он осуществлял техническое руководство в нескольких организациях, поддерживаемых частными инвесторами. В настоящее время он является партнером группы портфельных операций в New Harbour Capital, чикагской инвестиционной компании, специализирующейся на предприятиях среднего бизнеса, и предоставляет услуги исполняющего обязанности технического директора и ментора.

Алан имеет степень в области computer science Университета Пейсли, Шотландия, со специализацией «цифровое управление».

О редакторе русского издания

Логинов Олег Евгеньевич – разработчик, руководитель разработки и технический директор с более чем 20-летним опытом. Создавал успешные команды и проекты в крупнейших российских IT-компаниях и медиахолдингах: ВГТРК, «Газпром Медиа», VK, «Национальная Медиа Группа».

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

1. Технический директор (CTO)

В этой главе
• Суть работы технического директора (CTO).
• Различные типы CTO.
• Эволюция от инженера до технического директора.
• Определяем, нужен ли компании технический директор.

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

Роли ближайших коллег, генерального директора (CEO) и финансового директора (CFO), более четко определены и их сферы ответственности более четко обозначены: генеральный директор указывает направление, а финансовый директор выписывает чеки! Хорошо, мы немного лукавим, но эти роли действительно общепризнаны, в отличие от неопределенной позиции технического директора.

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

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

Мы рассмотрим различные типы CTO, чтобы вы определили, какой из них вам лучше всего подходит. Это поможет сформулировать и закрепить ваши карьерные цели. Кроме того, мы выделим качества, присущие успешным техническим директорам.

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

1.1. Суть работы технического директора

На самом верхнем уровне CTO прежде всего отвечает за техническое руководство и реализацию основного продукта компании, то есть решение задач бизнеса в интересах клиента. CTO обычно подчиняется генеральному директору, но нередко и финансовому директору, главному операционному директору (Chief Operating Officer, COO) или даже ИТ-директору (Chief Information Officer, CIO), в зависимости от размера компании и количества прямых подчиненных, которым генеральному директору комфортно управлять.

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

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

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

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

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

• Стабильную, масштабируемую и управляемую платформу, которая обеспечит развитие компании.

• Компетентное лидерство для поддержания актуальности платформы.

• Возможность использовать потенциал платформы для исследования новых областей бизнеса.

• Операционную устойчивость для надежного и предсказуемого обслуживания клиентов.

• Гибкое использование технологий на благо компании и клиентов.

• Создание и сохранение высокоэффективной команды, а также управление ею.

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

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

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

Хорошего CTO отличает способность адаптироваться к потребностям компании или, по крайней мере, вовремя признать, что он больше не может выполнять свои обязанности и должен уступить место тому, кто может.

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

1.2. Различные типы CTO

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

• Предстартап, номинальная должность.

• Стартап, эксперт в области технологий.

• Устоявшаяся/зрелая компания:

• Технический директор, должность учреждена впервые;

• Технический директор, пришедший на смену прежнему СТО.

1.2.1. Предстартап, номинальная должность

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

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

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

Хотя такой технический директор и не находится в одной лиге с лучшими представителями отрасли (возможный претендент на такое звание – Вернер Фогельс (Werner Vogels) из Amazon), забот и тревоги у него ничуть не меньше. Он, как правило, не желает отказываться от контроля и чувствует угрозу, когда кто-то из новичков в команде кажется более опытным. Тому, кто тащил проект ночами, кровью и потом, трудно признавать, что может появиться кто-то более подходящий, чем он.

Когда к проекту подключаются крупные инвесторы, такие как венчурные фонды, – они могут попытаться привлечь к управлению специалиста с бо́льшим опытом, поскольку технология является ключевым компонентом успеха. Однако существующий технический директор вполне может справиться с новыми обязанностями, если получит небольшую помощь и наставничество. Этим техническим директором можете быть вы, если ответите «да» на один или несколько из следующих вопросов:

• Когда вы принимаете технические решения, никто их не оспаривает и не проверяет.

• Вы единственный человек, который занимается разработкой.

• Это ваша первая настоящая работа, даже если она не очень щедро оплачивается.

• В компании очень мало процессов или структур.

• Только вы знаете, как управлять системой (системами) и обслуживать ее.

1.2.2. Финансируемый стартап: технологический эксперт с деньгами

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

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

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

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

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

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

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

• Компания моложе трех лет.

• Никто в вашем отделе еще не проработал больше 18 месяцев.

• Ваша платформа переживает вторую (или третью) итерацию.

• Компания тратит больше денег, чем зарабатывает.

• Вам кажется, что параметры продукта меняются каждую неделю/месяц.

1.2.3. Устоявшаяся компания: первый технический директор

Успешная и зарекомендовавшая себя компания, обычно возглавляемая основателем, развивается до этапа, когда ее глава решает, что необходимо более твердо управлять платформой. В его распоряжении есть несколько разработчиков и вспомогательный персонал, возможно, подчиняющийся финансовому директору. Системы играют ключевую роль в поддержании бизнеса, но со временем они начинают устаревать, что затрудняет либо исправление ошибок, либо расширение (такие платформы, как PowerBuilder, Microsoft Access и Visual Basic, используются гораздо шире, чем многие готовы признать).

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

Иногда компании везет – руководство понимает, что необходимо заменить критически важные системы, но просто не знает, как это сделать. Может быть, настойчивый торговый представитель убедил всех, что проблемы будут решены, если компания перейдет на дорогое готовое решение, но цена таких вложений заставляет задуматься. Отрасль знает много примеров неудачного внедрения Salesforce/Microsoft/Oracle, случившихся по вине некомпетентных решений. Платформа ни при чем, дело в том, что в большинстве случаев достаточно не полного пакета услуг, а лишь его небольшой части. На другой стороне диапазона находится руководство, которое не понимает, что их время давно вышло и при следующей перезагрузке все сломается, и считает, что ничего не нужно менять – работает сегодня, будет работать и завтра.

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

Такой технический директор должен уделять больше внимания стратегии и учитывать, что внедрение изменений или новых систем может вызвать нервозность в команде. Одна из его первоочередных задач будет заключаться в замене устаревших систем без нарушения текущих операций. Ему предстоит столкнуться со множеством возражений из разряда «У нас так не принято», и, хотя задача может быть трудной, ее решение приведет к значительной трансформации и принесет пользу компании. Эта роль идеально подходит для технического директора с опытом или для тех, кто хочет перейти на следующий уровень профессионального развития. У таких компаний следующие особенности:

• Это устоявшаяся компания с платежеспособными клиентами и зрелой линейкой продуктов.

• Большинству платформ более 10 лет.

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

• Большинство людей в компании не осознают, насколько сильно они полагаются на технологии или данные.

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

1.2.4. Устоявшаяся компания с техническим директором

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

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

• Позиция технического директора в ней есть не менее трех лет.

• Организован технический отдел, определены роли и иерархия.

• Установлены процедуры и стандартные методы работы, и в основном они соблюдаются.

• Существуют общие планы, стратегическое видение и планы проектов.

• Технология стабильна и понятна большинству сотрудников компании.

Конечно, существуют и смешанные типы компаний, но в каждой из них CTO в какой-то момент проходит один из описанных этапов развития карьеры.

1.3. Определение потребности в техническом директоре

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

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

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

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

• Разрабатывается ли в компании специальное ПО для клиентов или для поддержки клиентов?

• Проводилась ли значительная доработка сторонней платформы (например, Salesforce или Microsoft Dynamics) для поддержки клиентов?

• У вас отсутствуют данные о взаимодействии клиентов с вашими системами?

• В вашей отрасли существуют требования или законы, которые необходимо соблюдать (например, вы храните медицинскую или финансовую информацию о своих клиентах или для них)?

• Относятся ли в компании к вопросам безопасности как к досадной помехе и часто оставляют пароли в открытом доступе?

• Вы используете и поддерживаете свои собственные серверы, с которыми работают клиенты?

• У вас отсутствует песочница или безопасная среда для тестирования и проверки нового ПО или конфигураций?

• У вас маленькая команда начинающих или совсем неопытных технических специалистов без технического руководства?

• Слова «исправление» или «обновление» программного обеспечения звучат для вас в новинку и вы годами этим не занимались?

• У вас отсутствует документация или управление ресурсами/версиями для систем, используемых клиентами?

• У вас нет политики резервного копирования или аварийного восстановления без прерывания сервиса?

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

• Решает ли служба поддержки проблемы, связанные с некачественным или устаревшим программным обеспечением?

• Текущие системы начинают устаревать и не в состоянии обеспечить функционал, который требуется клиентам?

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

1.4. Эволюция от инженера

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

надежного и грамотного старшего инженера, даже архитектора. Но делают ли они своего обладателя хорошим техническим директором?

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

Одна из главных причин – неготовность мыслить более масштабными и долгосрочными категориями. Масштабность – это не создание более крупных платформ или управление ими, а умение рассматривать эти системы в контексте компании и конечного пользователя. Долгосрочное мышление основано на пятилетних блоках – естественном цикле бизнеса. Как платформа будет выглядеть через пять лет? Будет ли она удовлетворять потребности бизнеса и останется ли при этом актуальной?

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

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

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

Мудрые слова
Вам не скажут спасибо
Я вспоминаю один из лучших советов, который дал мой давний наставник и друг Джим Милбери, партнер-основатель ParkerGale Capital. В то время я был архитектором, переделывал проект платформы для портфельной компании и совершил ошибку новичка, думая о сегодняшнем дне и забывая о завтрашнем. Моим оружием было то, что благодаря новой архитектуре я экономил компании 10 000 долларов в год. По тем временам это были большие деньги. Однако существовал риск (небольшой) сбоя компонента. Джим сказал, что экономия – это хорошо, но попробуй объясни совету директоров, что ты сэкономил компании 10 000 долларов, когда они потеряют репутацию у клиентов из-за сбоя. Это был урок, который показал мне, что у моих решений более далеко идущие последствия, чем просто наличие работающего функционала.

1.4.1. Первые 100 дней

Типичный вопрос, который задают на собеседованиях на руководящие должности, чтобы понять, насколько кандидат думающий и мыслит ли он стратегически: «Что вы сделаете в первые 100 дней работы?» «100 дней» – отличный инструмент для начинающих технических директоров, дающий важные идеи о том, что им делать и как справляться с новой ролью. Опытные технические директора с приходом в новую компанию тоже будут делать все это, прежде чем приступать к работе.

В следующем разделе мы узнаем, как начать приносить пользу еще до наступления 100-го дня, не принимая при этом необдуманных/реакционных решений. Как инженер, не поддавайтесь искушению выносить суждения (по крайней мере, вслух) и засучив рукава все менять. Инженеры любят брать быка за рога – они видят проблему и хотят ее решить. Боритесь с этим желанием.

0–7 ДНЕЙ

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

7–30 ДНЕЙ

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

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

Заметки с полей
Поиск подсказок
Я называю эту фазу «проигрывать в течение одного часа» после фильма 1994 года «Маверик» («Maverick») с Мелом Гибсоном. Его герой просит разрешения сесть за покерный стол и, видя, что другие игроки немного колеблются, убеждает их, что в течение первого часа будет только проигрывать, что и делает. А когда час проходит, он начинает играть по-настоящему. Когда он в итоге выигрывает, один из мужчин обвиняет его в мошенничестве. Персонаж Гибсона объясняет: «Как вы думаете, что я делал в первый час? Я изучал вас». Технический директор – это марафонец, а не спринтер. У него есть время, чтобы освоиться.

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

30–70 ДНЕЙ

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

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

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

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

70–100 ДНЕЙ

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

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

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

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

1.5. 10 главных качеств технического директора

Широко распространено заблуждение, что CTO должен иметь опыт разработки – уметь разобраться в шестеренках платформы. Это не обязательно. Хотя большинство технических директоров действительно имеют опыт разработки или исследований в сфере информационных технологий, многие из них в первую очередь менеджеры и хорошо понимают, как управлять процессами и достигать поставленных целей. Хороший технический директор:

• Ведет за собой и вдохновляет, побуждая других тянуться за собой.

• Заглядывает далеко вперед, прежде чем принимать решения.

• Общается уверенно, но не покровительственно.

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

• Следит за наиболее актуальными для отрасли и компании технологиями.

• Не боится потерпеть неудачу и в случае неудачи не показывает ни на кого пальцем.

• Не пытается делать все сам, а делегирует полномочия команде.

• Знает: тот факт, что он начальник, не делает его самым умным в команде.

• Не боится принимать хорошие идеи и доверять им, независимо от их источника.

• Имеет видение, которое можно донести до других и реализовать.

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

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

Итоги

• Технический директор – это тот, кто заботится о текущем и долгосрочном состоянии платформы.

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

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

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

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

• Первые 100 дней в должности технический директор определяет области, нуждающиеся в руководстве и вдумчивом анализе, углубляясь в поиск предстоящих задач и проводя собственный due diligence.

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

Проверьте себя

Знаете ли вы…

• В чем состоит роль технического директора?

• Какова разница между техническим директором и старшим инженером?

• Каким образом техническому директору определить, как ему принести пользу или выстроить свою работу в организации?

2. Взаимодействие с руководством и коллегами

В этой главе
• Партнерство и выстраивание отношений с генеральным директором
• Эффективное взаимодействие с финансовым директором
• Работа с коллегами внутри компании
• Принимаем дела у предыдущего технического директора
• Представление членам совета директоров
• Работа с внутренней политикой
• Поиск путей внедрения изменений в компании

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

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

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

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

2.1. Партнерство с генеральным директором

Вам нужно поддерживать отношения со многими людьми, но один из самых важных – ваш генеральный директор (CEO) либо другой непосредственный руководитель, если вы подчиняетесь операционному директору (COO) или директору по информационным технологиям (CIO). Без исключительного доверия и уважительного партнерства с генеральным директором вы не сможете достичь целей и реализовать стратегию компании, как бы ни старались. Это не обычная модель «руководитель – подчиненный» – здесь цена неудачи намного выше. В этом разделе описаны возможные типы гендиректоров и проблемы взаимодействия с каждым из них, а также инструменты для налаживания отношений.

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

2.1.1. Офис генерального директора

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

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

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

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

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

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

2.1.2. Типы генеральных директоров

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

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

ГЕНЕРАЛЬНЫЙ ДИРЕКТОР БЕЗ ТЕХНИЧЕСКОГО ОПЫТА

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

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

ГЕНЕРАЛЬНЫЙ ДИРЕКТОР БЕЗ ТЕХНИЧЕСКОГО ОПЫТА, ДУМАЮЩИЙ, ЧТО РАЗБИРАЕТСЯ В ТЕХНОЛОГИЯХ

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

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

ГЕНЕРАЛЬНЫЙ ДИРЕКТОР С ТЕХНИЧЕСКИМ ОПЫТОМ

Неужели! Наконец – хоть кто-то говорит на вашем языке… но постой, Белоснежка, это яблоко может быть отравлено. Этот генеральный директор понимает, что вы делаете, но, учитывая, что он больше не работает в технической сфере, он может забыть о каких-то сложностях и отбросить их как неважные или тривиальные.

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

2.1.3. Найти подход

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

УЗНАЙТЕ СВОЕГО ГЕНЕРАЛЬНОГО ДИРЕКТОРА

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

• Узнайте его предыдущий опыт и образование (в Google, на LinkedIn и т. д.).

• Что его мотивирует, что приносит ему удовлетворение/разочарование?

• Что для него значит успех?

• Предпочитает ли он заниматься микроменеджментом, погружаться в детали или получать комплексное представление?

• Поговорите с ним.

Основную информацию можно узнать из разговора с директором и от коллег. Если вы новичок в компании, вполне уместно задать прямой вопрос: «Есть ли что-нибудь, что я должен знать о человеке X, что поможет мне в работе?» Это продемонстрирует, что вы готовы приложить усилия. Знание личности генерального директора поможет вам более эффективно общаться с ним.

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

Доверенный круг генерального директора

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

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

Узнайте, кто на самом деле принимает решения в компании. Создавайте союзы.

Что ему нужно?

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

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

Кедрик Гриффин (Kedric Griffin), старший директор по разработке в EAB, прекрасно подметил: «Доверие требует времени, уверенности в человеке и возможности положиться на него. Слишком часто я видел, как технарь старался одержать “быструю победу”, выдавая мнение за факты. Достаточно один раз попасться на этом, чтобы потерять все приобретенное доверие».

Регулярные индивидуальные встречи

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

2.1.4. Как наладить успешное партнерство

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

Опирайтесь на данные

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

Подготовьте генерального директора к сложному решению

Рано или поздно вам придется принимать решение, которое может иметь большее влияние, чем вам хотелось бы. Вы рассмотрели множество вариантов, но идеального среди них нет. Изучив их все, изложите генеральному директору последствия каждого из возможных путей и подведите его к решению, чтобы он участвовал в его принятии вместе с вами. Он может указать новые детали, позволяющие обойти препятствие, или же согласиться с вами в том, что необходимо сделать сложный выбор. Это момент «выбора Софи», названный так в честь фильма 1982 года с Мерил Стрип, в котором героине пришлось выбирать, какого ребенка спасти. Ответственность за подобные важные решения не должна лежать только на вас.

Думайте медленно, действуйте быстро

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

Если решение принято, действуйте быстро. Не медлите и не сомневайтесь. За время, которое вы потратили на размышления и обдумывание решения, вы должны были убедиться в его обоснованности.

Дайте гендиректору возможность участвовать / вносить изменения

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

Частая ошибка – подача в стиле «все или ничего». Используйте поэтапный, инкрементный подход, демонстрируя промежуточную выгоду для компании. Это даст генеральному директору пространство для маневра, избавив от необходимости подписываться на слишком многое слишком быстро, еще до полного понимания всей ситуации, о которой вы говорите. Сделайте варианты выбора максимально соответствующими текущему положению вещей. Если вы представите слишком мало вариантов или они не будут относиться к делу, эффект будет противоположен желаемому.

Проблемы бывают не от плохих новостей, а от неправильной реакции на них

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

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

Поговорив об установлении партнерских отношений с генеральным директором, обратим внимание на финансового директора (CFO).

2.2. Ставка на финансового директора

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

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

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

2.2.1. Как контролировать свои расходы

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

Эффективная рабочая стратегия – разделить расходы на три части следующим образом:

• Разработка

• Эксплуатация

• Поддержка

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

РАЗРАБОТКА

Сюда входит все необходимое для производства того, что компания считает «продуктом», например:

• Расходы на персонал (зарплата и компьютеры).

• Лицензии на инструменты для разработки (IDE, инструменты управления проектами).

• Лицензии на ПО (базы данных, библиотеки).

• Оборудование / облако для разработки / тестирования.

• Сторонние поставщики, например подрядчики.

• Обучение (курсы, книги, конференции).

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

Как проще планировать бюджет
Рассчитайте ежедневные расходы на каждую должность. Например: допустим, средняя зарплата веб-разработчика составляет 100 000 долларов (добавьте 20 % накладных расходов – 120 000 долларов), что составляет 10 000 долларов в месяц или 500 долларов в день (при условии, что в месяце 20 рабочих дней). Если для будущего проекта потребуется 14 дней работы этого специалиста, вам не придется выяснять или угадывать стоимость – это будет стоить 14 × 500 долларов. Ваш бюджет только что стал намного более обоснованным.

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

Эксплуатация

Сюда входит все, что связано с предоставлением услуги клиенту, в том числе:

• Расходы на персонал (настройка конфигурации клиента или ввод клиентских данных).

• Стоимость оборудования/облака.

• Лицензии на программное обеспечение (базы данных, библиотеки).

• Сторонние сервисы (домены, API).

• Аудиты безопасности.

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

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

ПОДДЕРЖКА

И, наконец, поддержка. Когда что-то идет не так или клиенту нужна помощь, сколько это сто́ит? Сколько усилий тратится на обслуживание системы, например на мониторинг файлов журналов и проверку резервных копий?

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

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

Службы поддержки не всегда отслеживают все данные, полезные для анализа. Очень часто из виду упускается, к какому клиенту (или линейке продуктов) относится заявка. Здесь могут выясниться очень интересные вещи, например, что какому-то клиенту требуется гораздо больше поддержки, чем остальным.

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

Таблица 2.1. Примерные ежемесячные расходы

2.2.2. Обратитесь за помощью

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

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

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

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

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

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

2.3. Работа с коллегами

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

Джеймс Хедли (James Headly), основатель и партнер MacLaurin Group и ментор ИТ-директоров, отмечает: «Технический директор должен хорошо разбираться в потребностях всех членов организации и тесно сотрудничать с владельцами бизнеса. Он должен не близоруко рассматривать ситуацию с точки зрения разработчика, а сотрудничать с бизнесом, продвигая всю организацию вперед».

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

2.3.1. Знайте свою компанию

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

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

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

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

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

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

2.3.2. Говорите на их языке

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

Слова разные – суть одна
Я помню, как в одной компании, где я работал, для обозначения клиента применялись два разных термина: идентификатор проекта (project ID) и идентификатор кампании (campaign ID). Разные отделы использовали какой-то один из этих терминов, утверждая, что ничего не знают о втором. Мне потребовалось несколько месяцев, прежде чем я понял, что оба они означают одно и то же – никакой разницы. Так что не бойтесь задавать простые вопросы.

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

2.3.3. Найдите болевые точки

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

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

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

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

2.3.4. Мыслите стратегически

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

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

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

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

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

2.4. Принимаем дела у предыдущего технического директора

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

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

2.4.1. Цените, а не принижайте

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

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

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

Заметки с полей
Вы сделали… что?
Я часто сталкивался с очень креативными решениями и, вместо того чтобы осуждать их, хвалил творчество и изобретательность их создателя, мысленно крича: «О чем ты вообще думал?» Для одной портфельной компании мы искали нового технического директора на смену тому, который работал со дня ее основания. Этот джентльмен не доверял стандартным системам контроля версий (CVS, SVN или Git). Что сделал он? Он создал и поддерживал свой собственный стандарт и заставлял команду использовать его. С одной стороны, я должен был оценить его изобретательность, но, покопавшись, я обнаружил, что это не более чем причудливое архивирование, а не контроль версий в современном представлении. Предложение перейти на Git я аргументировал возможностью использовать встроенный инструментарий в IDE, не поднимая шума и не привлекая внимания к тому, насколько слаб имеющийся «контроль версий». Таким образом все сохранили лицо. Не афишируйте свои победы и не ищите похвалы за то, что вы умнее. Просто сделайте свою работу и двигайтесь дальше.

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

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

2.4.2. Поговорите с уходящим CTO

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

• Что не давало ему спать по ночам? Ответ даст вам представление о текущих проблемах, доставляющих беспокойство и не имеющих немедленного решения, – обычно это вещи, о которых вы никогда бы не подумали.

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

• Какой клиент самый важный? У каждой компании есть особенный клиент, ради которого она готова на все. Зная, кто это, вы сможете не сломать сложившийся подход к работе с ним.

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

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

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

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

2.4.3. Изучите команду

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

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

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

2.5. Представление членам правления

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

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

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

2.5.1. Узнайте свою аудиторию

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

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

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

2.5.2. Формат встречи

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

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

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

ПРИМЕЧАНИЕ
Девин Мэтьюз (Devin Mathews), партнер-основатель ParkerGale Capital, отмечает, что технический директор редко принимает активное участие в обсуждениях, но того, кто задает вопросы, оказывает поддержку и помогает коллегам, очень ценят и обычно приглашают вновь.

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

2.5.3. Ваша роль

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

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

Вас также могут вызвать, если произошел серьезный сбой или проблема безопасности и требуются дополнительные разъяснения. Тон подобной презентации должен отличаться от обычного, потому что в этом случае вам, возможно, придется вызвать огонь на себя и принять ответственность, соответствующую вашей должности. Используйте формат PIP (problem – проблема, impact – влияние, prevention – предотвращение):

• Проблема – что вызвало проблему? Объясните в терминах бизнеса, понятных слушателям.

• Влияние – какое влияние проблема оказала на клиентов/сотрудников/партнеров?

• Предотвращение – какие выводы сделаны и что предпринято, чтобы проблема не повторилась?

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

2.5.4. Что можно, а чего нельзя

Вот несколько советов для успешного участия в заседании правления:

• Ознакомьтесь с повесткой дня и тем, что хочет сообщить генеральный директор.

• Не возражайте и не поправляйте генерального директора / финансового директора, если он говорит не о вашей сфере ответственности. Сделайте заметки, а потом задайте вопросы. Возможно, вам не хватает контекста.

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

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

• Если вы сообщаете плохие новости, никогда никого не обвиняйте, не принижайте и не называйте имен.

• Будьте готовы рассказать подробности и ответить на вопросы, которые могут показаться не относящимися к делу. Вы можете не знать, что еще обсуждалось.

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

• Если вы не участвуете во всем заседании, уходите, как только закончите и ответите на вопросы. Спросите генерального директора (или председателя), можно ли вам уйти; не сидите и не дожидайтесь, пока вас попросят уйти.

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

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

Взгляд со стороны
Как произвести хорошее впечатление
Как партнеру-основателю частной инвестиционной компании, Девину Мэтьюзу не привыкать к заседаниям правления. В его популярном подкасте PE Funcast есть несколько эпизодов для генеральных, финансовых и технических директоров о том, как провести хорошую презентацию для правления. Когда я спросил его, что он посоветует техническим директорам, он ответил: «Не просто рассказывай, покажи». Слишком часто технический директор не показывает продукт, за который он несет ответственность, – это все равно что владеть шоколадной фабрикой, но никогда не пробовать, что получилось. Продемонстрируйте прогресс и позвольте продукту самому показать, что необходимо улучшить. Говорят, картинка стоит тысячи слов, а демонстрация рабочего ПО может стоить тысячи слайдов. Это также дополнительная возможность с гордостью продемонстрировать усилия своей команды просто с помощью языка тела – он полезен для тех, кому бывает сложно подобрать правильные слова.

2.6. Коммуникация

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

2.6.1. Внутренняя коммуникация

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

Вы можете отправить электронное письмо или сообщение в Slack/Team всем сотрудникам компании, если:

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

• Что-то пошло не так – подобные ситуации нельзя игнорировать. Если что-то сломалось, неважно, по чьей вине, возьмите на себя информирование о ситуации, применив стратегию PIP. Люди начнут доверять вам и уважать вашу открытость и честность, а также им будет проще отвечать на вопросы со стороны.

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

Важность контекста
Проблемы безопасности
В какой-то момент проблемы безопасности затронули таких гигантов, как BBC и CNN. Конкретных деталей было мало, но в технических новостях проскальзывали некоторые подробности, и в данном случае причина была в том, что кто-то не защитил сервис хранения файлов Amazon S3. В новостях говорили, что облако небезопасно и следует быть осторожными. Пользуясь случаем, я подготовил комментарий, пояснив, что файлы хранились за пределами защищенного хранилища и это вина не облачного провайдера, а тех, кто занимается безопасностью. Зная, что клиенты могут задать этот вопрос нашим менеджерам, я также указал процессы, которые мы внедрили, чтобы подобная ситуация никогда не произошла с нашим продуктом: мы не разрешаем создавать такие хранилища и у нас есть инструменты для проверки, кто имеет доступ к файлам. Люди запомнили информацию гораздо лучше, чем если бы я просто отправил это сообщение без контекста, потому что оно было связано с тем, что они читали и видели в новостях. Как говорится, никогда не упускайте возможность извлечь выгоду из кризиса. Если что-то у людей на слуху и вы можете помочь им понять правильный контекст – сделайте это.

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

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

2.6.2. Внешняя коммуникация

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

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

Сколько раз вы находили в интернете решение конкретной проблемы, потому что кто-то рассказал о нем на Stack Overflow или другом ресурсе? А теперь спросите себя, отплатили ли вы за это? Внесли ли вы свой вклад в коллективный разум, чтобы другие могли учиться на вашем опыте? Скорее всего, большинство из тех, кто читает эти строки, взяли больше, чем вложили. Но вы не находитесь в изоляции.

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

Наладить внешние связи легко, и, хотя сначала они могут показаться пустой тратой времени, никогда не знаешь, чем они обернутся в будущем – возможно, привлекут новых поставщиков и подрядчиков или нового сотрудника. Если ничего не делать, то ничего и не будет. Как говорится в старой шутке: «Господи, почему я никогда не выигрываю в лотерею?» – «Так помоги мне и хотя бы купи лотерейный билет!»

2.7. Внутренняя политика

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

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

2.7.1. Основные типы

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

Вотчина

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

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

Буллинг

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

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

ПАССИВНАЯ АГРЕССИЯ

Эта форма агрессии проявляется, когда люди не высказываются напрямую о проблеме. Вместо этого они демонстрируют деструктивное поведение, например тянут резину, ни с чем не соглашаются или сопротивляются решению проблемы.

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

Накопитель ИНФОРМАЦИИ

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

2.7.2. Смягчение политики

Технические специалисты предпочитают четко структурированные процессы: сделайте это, и тогда произойдет то. Работа с эмоциями других людей не поддается логике if-then-else. Полностью рабочего способа справиться с деструктивным поведением не существует, но можно попытаться его смягчить. Если кто-то изобретет волшебную палочку, которая заставит офисную политику исчезнуть, он станет очень богатым человеком. А до тех пор рассмотрим несколько способов облегчить жизнь:

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

• Говорите об этом. Когда кто-то демонстрирует угрожающее или пассивно-агрессивное поведение, указывайте на это. Я обнаружил, что всего одной простой фразой вроде «Попробуй еще раз, только без агрессии/сарказма?», могу разрядить самые напряженные ситуации, потому что юмор и прямота показывают, что вас не запугать.

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

• Уточните и подтвердите. Когда кто-то кричит или запугивает, попросите пояснений и конкретных примеров причины недовольства. Не уступайте ни в одном вопросе, пока собеседник не разъяснит, из-за чего он злится, и пока вы не подтвердите, что причина вам понятна. Эмоции и стресс иногда могут брать верх над любым из нас, и требуется проявлять спокойствие и собранность.

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

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

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

Правило 24 часов
Джефф Ханнер (Jeff Hanner), менеджер хранилища данных (сейчас на пенсии), прекрасно умел поддерживать конструктивные отношения так, чтобы они не ухудшались с течением времени. С момента так называемого нарушения он давал людям 24 часа, чтобы разобраться с ним; после этого об инциденте больше никогда не упоминалось. Это маленькое правило сразу же предотвратило множество недоразумений. Я сам теперь руководствуюсь им, даже если другой человек не знает об этом: если кто-то обидел меня (или, по крайней мере, я так думаю), я отпущу ситуацию, если не предпринял никаких шагов для ее изменения в рамках отведенного времени.

2.8. Управление изменениями

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

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

Стивен Таллами (Stephen Tallamy), технический директор EditShare, отмечает, что «каждый отдельный руководитель отвечает за свою сферу, но может легко видеть, что необходимо для достижения успеха всего бизнеса, и помогать другим в достижении этого успеха. Подобное единомыслие на уровне руководства оказывает влияние на всю компанию и действительно может уменьшить негативные последствия при внедрении значительных изменений».

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

2.8.1. Лягушка в кипятке

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

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

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

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

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

Реальный пример
Microsoft Windows 10
Если вам нужен мастер-класс по управлению изменениями и варке лягушек, обратитесь к примеру Майкрософт и ее выпуску Windows 10. Вместо масштабного перехода на новую версию ОС (3.1 → NT → 2000 → XP → Vista → 7 → 8), Windows 10, выпущенная в 2015 году, до сих пор с нами. Медленные, постепенные изменения радикально преобразили продукт за эти годы, но, поскольку ОС по-прежнему выглядит привычно, мы охотно воспринимаем эти изменения как незначительные. Майкрософт медленно варит лягушку (то есть нас) без нашего ведома. Да, на момент написания этой книги вышла Windows 11, но цикл начался снова: от малых изменений к большим.

2.8.2. Комитет воодушевления

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

Келли Пауэлл (Kelley Powell), генеральный директор MacLaurin Group, считает, что для каждой крупной инициативы, ведущей к большим изменениям, необходимо учреждать то, что она называет «комитетом воодушевления» (excitement committee). Это собрание представителей всего бизнеса, вовлеченных в проект с самого начала. Они станут вашими амбассадорами и защитниками, пока вы реализуете проект, и помогут двигаться в правильном направлении. Эти люди – необходимое условие успеха, отмечает Пауэлл, потому что они смогут описать своей команде грядущие перемены лучше, чем вы.

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

2.8.3. Долина страданий

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

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

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

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

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

2.8.4. Последствия

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

Итоги

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

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

• Общайтесь с другими руководителями на понятном им языке и не погружайтесь в детали.

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

• Совместно с финансовым директором ведите учет расходов и затрат вашего отдела и проектов, чтобы не было никаких сюрпризов.

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

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

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

• Грамотная коммуникация внутри компании и с клиентами расширит ваши перспективы, сделает вас более доступным и позволит избавить сферу технологий от ореола таинственности.

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

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

Проверьте себя

Что из перечисленного ниже вы уже сделали?

• Определили тип своего генерального директора, выяснили его предпочтения и выбрали оптимальный стиль работы с ним.

• Запланировали регулярные встречи с генеральным директором.

• Установили хорошие рабочие отношения с финансовым директором и регулярно обсуждаете с ним свои актуальные бюджетные потребности.

• Наладили контакт с другими руководителями компании и поняли их цели и проблемы.

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

• Подготовились к презентации на заседании правления, узнали, кто в него входит и что для них важно.

• Определили порядок своего общения с компанией в качестве технического директора.

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

3. Долгосрочное видение

В этой главе
• Важность ви́дения
• Планирование видения вокруг потребностей бизнеса
• Определение в видении настоящей ценности для клиентов
• Планирование долгосрочных изменений, которые произведут революцию в бизнесе
• Как зафиксировать ожидания и избежать ложных обещаний
• Экономический план и видение
• Донесение видения до разных аудиторий
• Актуализация видения

Генеральный директор – не только руководитель, но и лидер компании. А лидерство – это умение смотреть вперед, предвосхищать потребности рынка и оставаться в авангарде, а не просто следовать за внешними изменениями. Ваша роль технического директора, лидера корпоративных технологий, состоит в том же самом. Недостаточно просто добиться, чтобы все работало; следует убедиться, что все будет работать достаточно долго и эффективно, независимо от того, что происходит вокруг. Компания рассчитывает, что вы обеспечите необходимый функционал и возможность развития для ее клиентов. Если вы уделите время подробной разработке и детализации видения, наметите курс и расскажете коллегам о ваших планах – это придаст бизнесу уверенность в том, что с вами он в надежных руках.

Чтобы проиллюстрировать вышесказанное, представим вымышленную компанию ООО «HomeMax». Допустим, она существует уже более 40 лет и предоставляет услуги страхования жилья для собственников. Она использует устаревшую платформу, которая написана на языках RPG и Cobol, управляется через терминал, использует базу данных Db2 и работает на системе AS/400s. В компании никогда не было формального технического директора, вместо этого основатель сам руководил небольшой командой разработчиков. Недавно ее приобрела частная инвестиционная компания, которая хочет увеличить принадлежащую ей долю рынка и поэтому наняла первого технического директора, который должен возглавить технологическую трансформацию.

3.1. Общее видение

Скорее всего, у вашей компании уже есть видение или миссия. Разница между этими понятиями тонкая, но важная: видение – это цель миссии, конечный результат, в то время как миссия ориентирована на действия и описывает, зачем существует организация, какие виды услуг и продуктов она предлагает и что делает ее уникальной.

Заметки с полей
Пример видения
Чтобы понять, что такое хорошее видение, рассмотрим некоторые крупные известные корпорации. LinkedIn ставит перед собой задачу «создать экономические возможности для каждого участника глобального рынка труда», в то время как задача Disney – «рассказывать потрясающие истории, развлекая, обучая и вдохновляя людей по всему миру», а Microsoft – «компьютер на каждом столе и в каждом доме». Общее в них то, что все эти компании используют очень простые для понимания формулировки без профессионального жаргона. Видение нашей компании HomeMax может звучать так: «Будьте спокойны за свой самый ценный актив».

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

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

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

Формулируя свое видение, учитывайте две аудитории: бизнес и свою команду. Бизнесу необходимо понимать, как ваше видение повлияет на него. Чтобы рассказать об этом, используйте общую терминологию без специальных терминов. Это часть «что мы делаем» (и «зачем») вашего видения. Вашей команде тоже необходимо все это знать, но ей нужно больше «мяса», то есть подробностей и объяснений, каким образом будет достигнута цель. Это часть «как» вашего видения.

3.1.1. Часть «что»/«зачем»

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

Заметки с полей
Никакая информация не потеряется
В одной из портфельных компаний, в которой я был техническим директором, мне нужно было сформулировать свое видение на основе наблюдений за бизнесом и его ценностями (культурой принятия решений на основе данных). Чтобы поддержать видение генерального директора, я поставил своей группе следующую цель: обеспечить бизнес всеми возможными данными для принятия обоснованных решений.
Для этого я предложил простой девиз: «Никакая информация не потеряется». Я даже попросил отдел дизайна создать огромный баннер в стиле «Назад в будущее» («Back to the Future») – он выглядел потрясающе (удобно иметь собственный отдел дизайна). Учитывая то, насколько дешевым стало хранение данных – сейчас не осталось оправданий тому, чтобы не записывать и не сохранять все, что можно. Раньше это было проблемой для компании, и теперь все, что мы делали, должно было соответствовать этому девизу и обеспечивать доступность данных для бизнеса. C каждым релизом нового функционала или новой версии платформы мы видели, как реализуется это видение и как по мере накопления все большего массива данных преумножаются знания и открываются новые возможности.

Формулировка видения не должна быть слишком сложной и подробной. Она должна быть такой, чтобы каждый слушатель мог ее усвоить и увидеть в ней пользу для себя. Для нашей компании HomeMax, основанной на устаревших технологиях и стремящейся перейти в мир веба и мобильных приложений и перестать вручную обрабатывать каждый запрос и каждое изменение, видение можно сформулировать так: «Автономная платформа, ориентированная на данные клиента».

3.1.2. Часть «как»

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

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

Заметки с полей
Туманное видение
Один мой знакомый CTO гордился своим видением: «Мы интегрируем машинное обучение в нашу аналитику». Это, конечно, прекрасная идея, но после расспросов выяснилось, что в ней не хватало деталей. Он не думал о том, что это видение значит для бизнеса и какую выгоду оно несет клиентам. Его собственная команда не получила ответ на вопрос «как» (вопрос «зачем» тоже не поднимался), поэтому гонялась за тенью, пытаясь решить проблему, которой не существовало. Все дело было в том, что CTO ухватился за модную тему машинного обучения, потому что это звучало круто. Он знал, что у них есть большое количество данных, и рассчитывал, что это поможет его карьере. Но никто не подумал, нужно это кому-то или нет. Новые технологии хороши, только если им находят верное применение, а не для всего подряд (даже не буду рассказывать, от какого количества идей на основе блокчейна я не оставил и камня на камне).

3.1.3. Определите критерии успеха

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

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

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

Таблица 3.1. Примеры видения

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

3.2. Сотрудничество с клиентами

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

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

3.2.1. Знай своего клиента

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

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

• Какая система/сервис является основной точкой взаимодействия с вашей компанией?

• Если происходит обмен данными – как вы их передаете?

• Что происходит с данными после того, как вы их получили?

• Как обычно используется сервис?

• Что необходимо вашей команде для успешной работы?

• Что в ваших процессах вы бы хотели улучшить или изменить в ближайшем будущем?

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

Вот как собственник жилья мог бы ответить на приведенные выше вопросы применительно к нашей компании HomeMax:

• Я могу взаимодействовать только с горячей линией колл-центра.

• Если мне необходимо внести изменения или обновить данные, я должен озвучить их по телефону.

• Я понятия не имею, получил ли оператор мои данные, пока не получу подтверждение в установленные сроки.

• Я использую сервис только в случае каких-то проблем, когда я создаю заявку. При этом статус заявки я могу узнать только по телефону.

• Нужно, чтобы оператор отвечал своевременно.

• Я хочу иметь возможность самостоятельно вносить изменения, прикладывать фотографии к заявке и проверять ее статус без необходимости звонить по телефону.

Очевидно, что конечный потребитель хотел бы по возможности взаимодействовать с сервисом самостоятельно, в своем темпе и в удобное время. Это типичные требования, но главный вывод, который здесь должен сделать CTO, – сейчас необязательно предлагать новые продукты или функции. Для начала нужно оптимизировать взаимодействие с компанией по телефону.

Заметки с полей
Решайте проблему, а не боритесь с симптомами
Мы работали с компанией, в которой были отлично налажены отношения с клиентами – показатель удержания более 95 %. И менеджер по работе с клиентами, и сам клиент были довольны. Однако внутри компаний-клиентов все было не так радужно – слишком большие накладные расходы на управление пользователями. У них была постоянная ротация временных работников, которые работали с клиентским порталом, и очень много времени уходило на создание и удаление учетных записей пользователей. В какой-то момент в компанию пришел новый технический директор. Услышав о жалобах, он не стал ничего обещать, однако провел опрос всех клиентов о наличии проблем. Вскоре он включил в свое видение необходимость обеспечить единый вход в систему, чтобы клиенты не испытывали затруднений при управлении пользователями.

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

3.2.2. Ваш партнер

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

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

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

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

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

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

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

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

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

3.3. Долгосрочное планирование

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

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

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

3.3.1. Время решает все

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

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

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

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

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

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

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

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

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

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

3.3.2. Обдумайте детали

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

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

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

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

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

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

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

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

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

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

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

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

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 с готовым сервисом – и всю работу приходилось выкидывать. Возникает вопрос: следует ли команде в такой ситуации продолжить разработку или же изменить план? Вашей первой реакцией должно быть следование первоначальному плану, тем временем присмотритесь к сервису и убедитесь, что в нем есть все, что вам нужно. После этого вы сможете перейти на готовый сервис, таким образом уменьшив операционную нагрузку, и затем перейти к следующим большим задачам. Чем меньше технологий вам нужно обслуживать – тем проще жизнь.

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

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

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

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

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

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

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

3.5.1. Подготовка речи

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

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

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

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

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

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

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

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

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

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

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

3.5.2. Практика и оттачивание навыка презентации

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

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

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

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

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

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

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

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

3.6.1. Что включать в бюджет

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

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

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

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

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

The free sample has ended.