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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мудрые слова

Вам не скажут спасибо

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

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

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

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

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

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

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

Поиск подсказок

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

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

30–70 ДНЕЙ

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

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

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

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

70–100 ДНЕЙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Разработка

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

• Поддержка

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

РАЗРАБОТКА

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

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

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

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

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

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

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

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

Как проще планировать бюджет

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

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

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

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

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

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

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

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

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

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

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

ПОДДЕРЖКА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Туманное видение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нередко, особенно в случае масштабных проектов, бизнес требует оценки окупаемости (ROI, return on investment). Проще говоря, ответа на вопрос: сколько бизнес заработает на каждый потраченный доллар? Оценить это чрезвычайно сложно, но все же возможно.

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

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

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

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

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

Здесь мы стараемся предотвратить момент, когда бизнес устает ждать – забыв, что проект долгосрочный и должен был занять много времени (или если началось отставание от сроков), – и начинает задаваться вопросом, стоит ли продолжать. Этот феномен, «долина страданий» (названный так Джеймсом Милбери, партнером-основателем ParkerGale Capital и описанный в главе 2), отражает отношение бизнеса к долгосрочным проектам, и если вы будете следить за своим положением на кривой, то сможете облегчить эти страдания.

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

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

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

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

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

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

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

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

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

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

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

• штатные сотрудники;

• сотрудники, работающие по договору подряда;

• компании-подрядчики;

• местный аутсорсинг;

• зарубежный аутсорсинг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В табл. 4.1 собраны воедино основные преимущества и недостатки каждого типа ресурсов.

Таблица 4.1. Сравнительный обзор ресурсов

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

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

Обычно сотрудников нанимают в трех случаях:

• Запуск нового проекта.

• Уход кого-то из команды.

• Ресурсы команды исчерпаны или требуется дополнительная поддержка.

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

Рассмотрим подробнее три основные ситуации, в которых происходит рост вашей команды.

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

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

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

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

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

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

• Требуемые знания и личные качества.

• Перспективы по завершении проекта: останется ли сотрудник востребован или в нем больше не будет необходимости?

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

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

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

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

• Потеря навыков. Оцените потерю опыта и компетенций. Насколько они были важны для успеха команды?

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

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

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

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

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

Будь готов

Не «если», а «когда»

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

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

РЕСУРСЫ КОМАНДЫ ИСЧЕРПАНЫ ИЛИ ТРЕБУЕТСЯ ДОПОЛНИТЕЛЬНАЯ ПОДДЕРЖКА

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

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

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

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

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

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

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

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

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

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

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

• от 10 до 8 – основной навык для этого сотрудника, уровень старшего специалиста/эксперта;

• от 7 до 5 – основной навык для этого сотрудника, уровень младшего специалиста; требуется руководство или наставничество со стороны более опытного человека;

• от 4 до 3 – второстепенный навык в дополнение к основному;

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

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

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

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

Знай свою команду

Аудит человеческих ресурсов

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

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

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

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

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

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

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

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

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

Хорошее агентство – ваш партнер в процессе найма, вторит Лори Дженнингс (Lori Jennings), основатель Jennings ProSearch. Агентство продает и продвигает ваше предложение, отсеивает кандидатов, которые не соответствуют требованиям (как в части навыков, так и в части личных качеств), готовит кандидата к собеседованию и обеспечивает весь процесс отбора. Лучшие из агентств действительно ведут себя как партнеры. Они даже сопровождают кандидата на собеседование, ожидая снаружи, пока интервью не закончится.

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

Преимущества:

• можно быстро получить несколько квалифицированных кандидатов;

• кандидаты уже прошли предварительный отбор.

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

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

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

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

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

В конце концов, вы можете взять дело в свои руки и использовать один из множества онлайн-ресурсов для поиска подходящих кандидатов. Вот некоторые основные сервисы: LinkedIn, ZipRecruiter, Indeed и Stack Overflow. Результаты здесь будут зависеть от времени года и должности, на которую вы ищете человека. Волшебной формулы не существует; то, что сегодня работает на одном сайте, может не сработать на другом.

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

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

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

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

Большинство описаний вакансий составляются по всем знакомому шаблону:

1. Название должности.

2. Описание.

3. Минимальные требования к кандидату.

4. Требуемые навыки.

5. Информация о компании.

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

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

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

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

• Вице-президент по разработке (VP of Engineering)

• Старший веб-разработчик (Senior Web Developer)

• Руководитель направления цифровой трансформации (Head of Digital Transformation)

• Архитектор облачных решений (Cloud Architect)

• Младший мобильный разработчик React (React Mobile Developer (Jnr))

• Руководитель проектов (Project Manager)

• Скрам-мастер (Scrum Master)

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

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

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

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

Добавьте в название как можно больше метаданных, но не переусердствуйте. Младший мобильный разработчик React – хороший пример грамотного обращения к целевой аудитории. Вам нужен мобильный разработчик, и, поскольку существует множество фреймворков и языков, сразу укажите требуемые навыки, чтобы людям не пришлось тратить время на дальнейшее чтение в попытках узнать, подходят ли они. Если соискатель решит читать дальше, то он уже будет знать, подходит ли он. То же самое касается последних двух формулировок. Да, «руководитель проектов» встречается часто, но, если вы уже работаете, например, со Scrum, укажите это прямо в названии; не упускайте возможности. Люди склонны выбирать то, что им знакомо, особенно когда принимают решение, способное изменить всю их жизнь.

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

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

• Не пишите о компании.

• Не повторяйте то, что есть в названии.

• Не тратьте место на лишние слова.

• Опишите, чем кандидат будет заниматься.

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

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

• Название: Архитектор облачных решений.

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

• Название: Младший мобильный разработчик React.

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

• Название: Руководитель проектов.

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

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

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

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

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

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

Лучше всего свести этот раздел к минимуму. Многие компании ошибочно включают в него то, что на самом деле не нужно. Сколько раз вы читали, например: «Минимальный опыт работы x лет»? Задумайтесь – вам нужен кто-то, кто сможет выполнять эту работу, и какая разница, сколько времени ему понадобилось, чтобы научиться этому?

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

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

При составлении этого списка велик риск перестараться. Будьте внимательны. Вспомните, к кому вы обращаетесь, и спросите себя, действительно ли необходимо то, что вы указали, и не подразумевается ли это другими пунктами. Например, требование навыков работы с Microsoft Office в вакансии разработчика. Скорее всего, если человек умеет программировать, то уж с Word или Excel проблем у него не будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Одно собеседование с вами или командой.

• Серия собеседований с 1–2 членами команды.

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

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

Однако вы можете быть и основным интервьюером. Как в этом случае организовать собеседование?

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

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

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

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

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

СОБЕСЕДОВАНИЕ – НЕ ДОПРОС

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

• Может ли этот кандидат выполнять необходимую работу?

• Впишется ли он в команду?

• Сможете ли вы убедить его присоединиться к вашей команде?

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

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

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

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

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

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

Здесь отлично работает сопоставление двух конкурирующих технологий или стандартов, которые знает кандидат. Например, при сравнении JSON/XML спросите: «Почему JSON сложнее и медленнее парсить, чем XML?» Если вы решите задавать вопросы с подвохом, то, пожалуй, это максимум, который можно себе позволить.

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

Вам необходимо понять, почему кандидат меняет работу (если это не выпускник). Тут нужно выяснить две вещи:

• Как он отзывается о своем предыдущем или текущем работодателе (красный флажок: если плохо – однажды таким работодателем можете стать вы)?

• Можете ли вы предложить ему такие условия, в которых он будет доволен и эффективен?

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

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

ТЕСТОВОЕ ЗАДАНИЕ

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

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

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

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

Пункт оплаты

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

ПРОЩАНИЕ

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

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

Слева или справа?

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

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

Прежде всего, выберите подходящий сервис для видеоконференций. То, что хорошо для звонков друзьям и семье, может не подойти для всесторонней оценки кандидата. Классические варианты, в том числе Google Meet, Microsoft Teams, Zoom, Apple FaceTime и Skype, совместимы с разными платформами, поэтому, если кандидат использует ПК, Mac или даже мобильный телефон, проблем быть не должно.

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

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

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

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

Тем не менее то, как кандидат ведет себя в ходе видеовстречи, многое говорит о его характере:

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

• Нашел ли он тихое уединенное место или у него за спиной ходят люди?

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

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

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

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

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

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

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

Такие решения, как Google Docs или функция Live Coding в Visual Code, позволяют совместно редактировать документ в режиме реального времени, и это хороший способ выделить интересующую область документа и обсудить ее.

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

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

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

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

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

• Социальные навыки:

• внешний вид;

• речь и общение;

• деловой этикет / отношение к работе.

• Профессиональные навыки:

• жизненный цикл разработки ПО;

• паттерны проектирования;

• знание определенного языка программирования.

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

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

• 0

Нет опыта работы с AWS.

• 1–3

Использовал отдельные сервисы, такие как S3 или EC2.

• 4–6

Создал и настроил собственную учетную запись, использовал IAM для управления пользователями.

• 7–10

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

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

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

Можно делать заметки в листе оценки во время собеседования (не привлекая к этому лишнего внимания), можно заполнить его и сразу по завершении, пока впечатления еще свежи. Главное – не затягивать с этим, иначе будет сложно вспомнить все детали. Пример листа оценки показан в табл. 5.1.

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

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

• Точно определены наиболее важные критерии для должности.

• Для каждого критерия описаны диапазоны оценок.

• Каждый интервьюер понимает принципы оценивания кандидата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Подробно изучить сервис или продукт, который вы разрабатываете.

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

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

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

• Любые правила компании или отдела, о которых нужно знать.

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

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

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

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

После вводной части переходите к главному: как работать с вами и командой. Это самая важная часть процесса адаптации – как новичку добиться успеха в вашей команде?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Клиент – любой пользователь продукта, как внутренний, так и внешний.

• Ресурсы

• База знаний о структуре внутренних данных в виде внутренней вики.

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

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

• Требуемые навыки

• Знание веб-технологий, включая системы видеоконференций/чаты.

• Грамотная письменная и устная речь.

• Знание SQL.

• Ключевые показатели

• Время до закрытия инцидента.

• Общее количество обращений за определенный период.

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

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

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

В популярных реалити-шоу, таких как Survivor в США или The Apprentice в Великобритании, создают команды с самым разношерстным составом участников и разной структурой, все это для создания конфликтов и драм с целью развлечения. Но эти конфликты вполне реальны, поэтому стоит позаботиться о подборе структуры, которая лучше всего подойдет для вашей команды.

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

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

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

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

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

• разные стеки технологий;

• непересекающиеся клиентские базы;

• независимые релизные циклы;

• уникальные для разных продуктов и трудоемкие проблемы поддержки;

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

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

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

Эта модель хорошо работает, если в организации существует четко определенный и работающий SDLC (Software Development Life Cycle, жизненный цикл разработки программного обеспечения). Скорее всего, на начальном этапе создания проекта каждый из ваших сотрудников будет выполнять сразу несколько ролей. Однако придет время, и вам потребуются специалисты с более глубокими знаниями в каждой области. Тогда вы сможете выделить их в отдельные команды с определенным кругом задач.

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

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

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

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

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

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

Таблица 6.1. Должностная иерархия: технологии

Каждый из этих уровней в идеале должен указываться для определенной специальности, например «старший разработчик» или «руководитель службы поддержки». Он позволяет выделить отдельных сотрудников в пределах каждой специальности. Но всегда бывают исключения из правил, и ваши названия будут отражать реалии именно вашей компании. Также в некоторых организациях существуют определенные традиции: например, в IBM каждый, оказывается, «вице-президент»! Другие компании могут добавлять «директор» к названиям должностей всех руководителей старшего звена (что сбивает с толку), потому что в Великобритании используется название «управляющий директор» (Managing Director) вместо «генеральный» (Chief Executive Officer) (понятие «директор» в Великобритании юридически закреплено, там директора указываются в учредительных документах компании как ответственные лица). И не стоит за названиями должностей забывать про реальный опыт – пять лет работы младшим специалистом сами по себе не сделают никого экспертом.

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

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

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

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

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

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

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

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

Таблица 6.2. Уровни вовлечения СТО

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

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

Информация о клиентах

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

«НОВОСТЬ ОБ ОТСУТСТВИИ НОВОСТЕЙ»

Много лет назад Келли Пауэлл (генеральный директор и писатель), занимавшая в то время должность руководителя отдела по взаимодействию с клиентами в Royall & Co, рассказала мне о том, как важно сообщать «новости об отсутствии новостей» в случаях, если от вас ждут информации. Если вы когда-нибудь бывали в ситуации, когда ждешь от кого-то новостей, а их долгое время нет, то наверняка у вас было чувство, что о вас забыли. Такое происходит с каждым, и все испытывают беспомощность и раздражение от того, что ничего не происходит.

Пауэлл требовала сообщать ей о положении дел, даже если результата еще нет и работа продолжается. Она просила направлять ей уведомления по электронной почте или в текстовом сообщении каждые 30–60 минут (в зависимости от серьезности проблемы).

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

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

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

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

• количество открытых/закрытых заявок;

• количество обращений в службу поддержки;

• метрики производительности/нагрузки;

• устранение технического долга;

• процент выполнения задачи/спринта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует множество платных и бесплатных онлайн-ресурсов, предлагающих разные форматы и пакеты. Многие технические издательства предлагают специальные подписки, дающие неограниченный доступ к их каталогу книг. Специализированные сайты (например, Khan Academy и Coursera) предлагают более формальные онлайн-курсы с упражнениями и тестами, и все это бесплатно. Другие сайты, такие как Udemy, предлагают обучение стоимостью несколько долларов за курс.

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

Крупные игроки, такие как Amazon, Microsoft, Cisco и Oracle, предлагают возможность сертификации специалистов для многих своих продуктов. За последние годы цены на нее значительно снизились, и многие сертификаты стоят всего несколько сотен долларов (по сравнению с тысячами несколько лет назад).

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

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

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

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

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

Конференции были очень популярны до пандемии COVID-19, посмотрим, вернутся ли они когда-нибудь к прежним масштабам (таким, как AWS re: Invent, когда Лас-Вегас переживал недельное нашествие 30 000 человек). Тем не менее многие конференции успешно перешли в онлайн и смогли сохранить при этом свою ценность, хотя и утратили фактор нетворкинга.

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

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

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

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

Как руководитель команды, вы выступаете посредником между ней и бизнесом, фильтруя и обогащая информацию, относящуюся к команде. Джастин Марквардт (Justin Marquardt), партнер частной инвестиционной компании New Harbour Capital, кратко сформулировал это так: «Крайне важно, чтобы они [CTO] являлись сильными коммуникаторами и эффективно объясняли своей команде, высшему руководству и совету директоров, как их план согласуется со стратегическими инициативами компании, в том числе были способны выйти за рамки технических подробностей и донести связь тех или иных инициатив с ключевыми целями бизнеса».

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

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

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

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

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

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

• Объявления отдела. Ключевые события, крупные успехи и признание заслуг отличившихся членов команды. А также сообщения о любых сбоях или ошибках (без указания виновных) и мерах, которые были приняты.

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

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

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

Вот несколько советов, как написать хорошее профессиональное электронное письмо для широкой аудитории:

• Пишите естественно; избегайте излишней формальности.

• Не используйте ненормативную лексику, намеки или оскорбления.

• Никогда не переходите на личности.

• Будьте честны: никаких домыслов и преувеличений.

• Оставайтесь профессионалом. Говорите по существу.

Помните, что электронные письма никогда не удаляются. Все чаще компании хранят копии каждого отправленного и полученного письма в отдельном хранилище, данные в котором невозможно изменить. Это может быть обусловлено нормативными требованиями, или же компания может быть особенно внимательна к юридическим вопросам. Такие службы, как G Suite и Office 365, упрощают настройку подобного хранилища. Поэтому, даже если вы думаете, что удалили электронное письмо – как только оно покидает папку «Исходящие», оно сохраняется навсегда. А поскольку это письмо является собственностью компании, оно может быть использовано как в вашу пользу, так и против вас.

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

Это собрание, на котором вы рассказываете группе, как идут дела. Оно должно проходить раз в 1–2 недели и занимать не более 30 минут. Основные темы: крупные релизы, рост или падение количества пользователей, улучшения процессов и структурные изменения. Формат должен быть постоянным, чтобы люди знали, чего ожидать.

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

Такие встречи посвящены конкретной теме и проводятся по необходимости. Обычно вначале кто-то один выступает по теме собрания, после чего следует открытое обсуждение в формате «вопрос – ответ».

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

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

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

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

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

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

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

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

• Не отвлекайтесь; уберите со стола мобильные телефоны.

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

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

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

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

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

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

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

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

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

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

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

Таблица 7.1. Базовая структура матрицы – разработчик

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

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

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

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

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

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

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

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

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

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

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

Если кто-то ошибся, никогда не обвиняйте этого человека, особенно публично. Неважно, что он сделал, в конце концов, его ошибка – это ваша ошибка. Известная фраза, получившая широкое распространение благодаря 33-му президенту США Гарри С. Трумэну: «Фишка дальше не идет», – больше чем просто слова. Это олицетворение менеджера, берущего на себя ответственность за неудачи своей организации. Многие менеджеры заявляют, что придерживаются этого стандарта, но мало кто доказывает это на деле.

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

• Кричать, ругаться или угрожающе жестикулировать.

• Угрожать или оскорблять.

• Немедленно увольнять кого-либо.

Неважно, насколько вы нервничаете, злитесь или разочарованы – ничто не может оправдать подобное поведение.

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

По мере расследования проблемы вы сможете отнести ее причину к одной из двух категорий:

• ошибка/некомпетентность;

• непродуманность / недостаточное планирование.

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

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

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

Составьте описание инцидента и его причин. Задокументируйте шаги по исправлению.

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

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

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

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

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

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

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

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

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

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

• Проблема повторяется? Это говорит о том, что процессы, которые вы внедряете для предотвращения проблем, не работают.

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

• Проблема сезонная? Если проблема возникает в одно и то же время, определите внешние факторы: например, не связан ли сбой с переходом на летнее время?

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

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

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

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

• Сокращение отдела.

• Какая-то из специальностей больше не нужна.

• Плохие результаты.

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

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

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

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

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

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

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

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

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

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

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

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

Бывает так, что человек просто не обладает навыками, необходимыми для выполнения работы. Это проявляется одним из следующих способов:

• смерть от тысячи порезов;

• инцидент.

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

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

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

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

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

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

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

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

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

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

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

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

При увольнении сотрудника не забудьте о следующих вещах:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удаленная работа не обязательно означает гибкий график (когда вы сами выбираете часы работы). Он может быть частично гибким – все зависит от того, насколько тесное взаимодействие в режиме реального времени требуется от команды. Скорее всего, удаленные сотрудники будут работать по обычному графику. Гибкий график должен обсуждаться и согласовываться отдельно.

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

С 2011 по 2020 год правительство Великобритании проводило обширное исследование влияния удаленной работы на людей (http://mng.bz/PoQg). Некоторые из его результатов довольно поучительны:

• Удаленные сотрудники на 50 % реже получали повышение.

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

• Удаленные сотрудники реже брали больничный, чем офисные работники: 0,9 % против 2,2 %.

• Бонусы для удаленных сотрудников были на 38 % ниже, чем для тех, кто работает в офисе.

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

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

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

• Стоимость установки/лицензии, включая как ежегодные платежи, так и оплату за использование.

• Профессиональные услуги по настройке.

• В случае запуска системы на своем оборудовании:

• затраты на оборудование и дополнительные лицензии на ПО;

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

• Время на внедрение и настройку программного обеспечения.

• Можно ли периодически экспортировать данные.

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

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

Таблица 8.1. Покупка: преимущества и недостатки

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

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

Крупная покупка

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

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

Таблица 8.2. Разработка: преимущества и недостатки

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

Помните также: будьте осторожны с решениями low/no code. Это современные версии Visual Basic, позволяющие не-разработчикам создавать ПО с помощью инструментов point-and-click («наведи-и-щелкни») или drag-and-drop («перетащи-и-брось»), без написания кода. Эти инструменты создают обманчивое впечатление, что вы экономите кучу времени и быстро решаете 80 % задачи, но оставшиеся 20 % могут делаться гораздо дольше, потому что окажется, что проблема только усложнилась. В худшем случае вы идете на компромиссы, чтобы оправдать выбор именно этого инструмента, хотя он и не обеспечивает необходимой гибкости. Пойдут ли ваши конкуренты на такой же компромисс или же обойдут вас с более широким набором функций?

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

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

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

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

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

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

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

Таблица 8.3. Разработка или покупка

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

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

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

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

• Свое оборудование – инфраструктура, в которой базовое оборудование (ЦП, память, сеть и хранилище) принадлежит компании и управляется ею.

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

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

• Подходят для использования собственного оборудования – приложения, предполагающие интенсивные вычисления, с постоянной загрузкой ЦП на 90 % и более, например для обработки сложных данных или графики (или майнинга биткоинов!).

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

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

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

• Мы не сможем контролировать наши данные. Для подобного убеждения не существует никаких оснований, но оно все еще живо. При использовании облака все ваши данные хранятся у поставщика облачных услуг, а доступ к ним предоставляется с помощью инструментов и API поставщика. Организация хранения может выглядеть по-разному – как в виде файлов, так и в виде баз данных. Контроля над данными у вас будет не меньше, чем если бы они находились в вашей локальной SAN. Да, за загрузку большого объема данных будет взиматься плата. Но доступу к данным никто не препятствует.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вы запускаете несколько сервисов на одном сервере. Железо стоит дорого, поэтому на одном сервере обычно запускают несколько сервисов (вспомните классический стек Linux Apache MySQL PHP). В облаке таких ограничений нет. В облачной среде серверы должны быть максимально легкими, чтобы их было легко заменять, обслуживать и масштабировать.

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

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

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

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

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

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

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

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

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

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

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

Существует два основных варианта размещения оборудования:

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

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

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

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

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

Выделенный центр обработки данных (ЦОД) может позаботиться обо всем этом (и возьмет с вас соответствующую плату). Стоимость ЦОД обычно зависит от объема занимаемого оборудованием места в стойке (измеряется в юнитах, или U; один U равен 1,75 дюйма) и пропускной способности сети (доступного вам подключения к интернету). Большинство центров обработки данных включают в свои тарифы стоимость электроэнергии в расчете на использование стандартных блоков питания. Серверы обычно бывают длинными и плоскими и размещаются в стойке плотно один над другим, поэтому их называют «коробки для пиццы». Такие серверы (или серверы для размещения в стойке) стоят немного дороже, чем серверы в обычных настольных корпусах.

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

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

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

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

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

• Дата покупки/установки – когда было приобретено и подключено оборудование?

• Источник покупки – где было приобретено оборудование (включая полные контактные данные продавца)?

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

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

• Способы доступа – есть ли на устройстве консоль? Если да, то как настроена сеть и где хранится имя пользователя/пароль?

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

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

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

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

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

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

Как технический директор, ответственный за все технологии в компании, вы должны поддерживать их работоспособность, что бы ни случилось. Внесем ясность: реализовать отказоустойчивость непросто. Большинство организаций имеют плохую (читай: «не имеют никакой») стратегию аварийного восстановления, а те, кто думает, что она у них хорошая, никогда не проверяли ее в реальных условиях, и она является не более чем плацебо, страховочной сетью, которая никак не закреплена.

В этом разделе мы рассмотрим все соображения и вопросы, на которые вам необходимо ответить, чтобы составить грамотный план аварийного восстановления в своей организации. Вот три основных вопроса, которые будут определять вашу стратегию:

• Каково допустимое время простоя?

• Допускается ли частичное предоставление услуг на время восстановления?

• После отказа вы полностью перейдете на новый основной комплекс или вернетесь к прежнему?

Для наглядности предположим, что у вас есть две зоны: одна основная и одна резервная, готовая подключиться в аварийной ситуации. Необязательно ограничиваться одной резервной зоной – их может быть несколько. Помните, что если она одна, то, как только вы перейдете в состояние восстановления (начнете использовать резерв), у вас больше не будет резерва для уже задействованного резерва.

Генеральному директору легко требовать нулевого простоя. Хотя такое возможно, это очень дорого и очень сложно, особенно если в инфраструктуре существуют компоненты, которые нельзя запустить в нескольких экземплярах. Яркий пример – обычная база данных: в большинстве организаций таблицы не спроектированы для легкой реализации резервирования в реальном времени (если вы полагаетесь на сгенерированные базой данных автоинкрементные первичные ключи, а не на GUID, то вам придется несладко). Старые системы или плохая архитектура просто не позволяют иметь дублирующую систему, на которую можно быстро переключиться.

При использовании для вашей системы двух географически разнесенных зон сложность (и стоимость) решения для аварийного восстановления будут определять два фактора:

• Технология синхронизации данных в обеих зонах.

• Способ перенаправления трафика (пользователей) на новую основную зону.

Синхронизация данных между двумя разнесенными в пространстве зонами требует времени – буквально. Для передачи данных по сети требуется время, и даже небольшая задержка в 50–100 мс может иметь огромное значение, когда речь идет о синхронизации баз данных. Даже если сеть в рабочем состоянии и не перегружена, вы будете ограничены временем, которое требуется для пересылки байтов. При выборе места для размещения резервной системы учитывайте схему пиринга между ЦОД (они должны быть связаны друг с другом напрямую, чтобы избежать влияния общей перегрузки каналов связи).

Хотя современные БД (такие как SQL Server и Oracle) имеют мощные функции синхронизации (из-за чего лицензия на них стоит дороже), скорость передачи данных по-прежнему ограничена физическими возможностями сети.

Таким образом, в зависимости от организации вашей инфраструктуры и конфигурации сети, нулевое время простоя может быть недостижимо. Отставив эту высокую цель, подумайте, какое время простоя допустимо для ваших клиентов: минуты, часы или дни? Определить эту величину можете только вы и генеральный директор, которому вы предоставите данные о финансовых потерях в результате простоя.

Существует два подхода к аварийному восстановлению: горячий и холодный резерв. Горячий – более дорогой, он предполагает малое время простоя, и для него необходимо поддерживать серверы в рабочем состоянии и постоянно синхронизированными, готовыми начать обслуживание пользователей, как только на них начнет поступать трафик. При горячем резервировании постоянно потребляется электроэнергия и загружается сеть, а также сокращается срок службы резервного оборудования.

В отличие от горячего, холодный резерв – это режим, при котором работает минимальное количество оборудования, а при аварийном переключении оно включается по мере необходимости. Это более дешевое решение, но и более медленное, потому что приходится ждать, пока серверы загрузятся и синхронизируют данные. Иногда холодный резерв является более чем достаточно дешевым способом обеспечить необходимый уровень отказоустойчивости.

Второй фактор, влияющий на выбор стратегии аварийного восстановления, – необходимость продолжать предоставлять полнофункциональный сервис в случае аварии. Можно ли обойтись частичным сервисом? Представьте, что что-то пошло не так, и спросите себя, какие услуги из тех, что вы предлагаете, можно оставить временно недоступными или предлагать в режиме только для чтения.

Например, представьте, что вы отвечаете за Twitter и у вас очень ограниченный бюджет. В режиме частичного предоставления сервиса можно позволить людям просматривать ранее опубликованные твиты, но временно ограничить возможность писать и публиковать новые. Или, если у вас онлайн-магазин, позвольте клиентам просматривать и добавлять товары в корзину, но уберите возможность оформить заказ. Почти всегда существуют области, которые какое-то время могут работать с ограниченным функционалом.

Если вы предоставляете услугу в ограниченном объеме, подумайте, что можно временно отключить из сервисов, невидимых для конечного пользователя: например, ведение журналов, создание отчетов или какие-то асинхронные служебные задачи.

Обеспечить полное предоставление услуги гораздо сложнее, в том числе потому, что может понадобиться четко определить текущее состояние системы, которое необходимо воспроизвести в новой системе. Может ли что-то задублироваться или быть обработано повторно – потому что резервная зона не знает, что уже было сделано или какая-то информация полностью потерялась? В качестве примера можно привести уведомления по электронной почте, генерируемые системой. Если сбой происходит во время отправки пачки электронных писем, обязательно ли выяснять, какие письма уже были успешно отправлены, или допустимо, чтобы часть пользователей получила письма еще раз?

Для некоторых систем действительно трудно создать решение для аварийного восстановления без большого количества ручных операций с базой данных и файлами.

Создавая ограниченную версию сервиса, помните: необходимо предусмотреть возможность запустить на ее основе полное решение. Если в вашей основной зоне отключили электричество, скорее всего, энергетическая компания рано или поздно восстановит электроснабжение. Однако если произошел пожар, наводнение или кража, то ваша урезанная версия должна будет стать основным, полнофункциональным комплексом. Представьте ее как лампочку: она не должна погаснуть и оставить вас во тьме, но, скорее всего, вы потерпите, если какое-то время света будет меньше.

Предположим, вы перешли на резервную зону в полной или частичной конфигурации. Что вы будете делать после восстановления основной зоны? Если вы обнаружите, что не знаете ответа, то обратите на это внимание. Это очевидный признак того, что в вашей организации аварийное восстановление никогда не происходило (или не отрабатывалось) и никто не думал о том, что будет происходить после того, как прошел Годзилла, и о том, что и как необходимо восстановить. Тем не менее все это вполне может произойти в реальности.

В зависимости от вашей стратегии аварийного восстановления и конфигурации оборудования и при условии, что зоны взаимозаменяемы, вы можете просто назначить резервную зону основной. Зачем организовывать еще один переход, если он не требуется? Займитесь решением проблем с неисправной основной зоной и сделайте ее готовым к использованию резервом. Это называется конфигурацией аварийного восстановления без отката.

Однако если у вас нет взаимозаменяемых комплексов, вам придется после решения проблемы вернуться к основной зоне – так обычно происходит, если вы предоставляете частичный сервис во время восстановления. Хорошая новость в том, что необязательно делать это немедленно. Вы можете запланировать второй перерыв в работе сервиса и вернуться к основной зоне спокойно, в удобное для вас время, обычно это можно сделать в выходной или ночью.

До сих пор мы говорили о различных вариантах конфигурации аварийного восстановления, рассматривая отдельные части инфраструктуры, чтобы понять, что подойдет для вашей организации. Процесса переключения с одной зоны на другую мы пока не касались. Здесь, как и в случае со сбережениями на черный день, которые у всех нас есть, самое сложное – определить, наступил ли этот черный день, чтобы можно было открыть кубышку. Переход в режим аварийного восстановления – серьезное событие, и такое решение не должно приниматься легкомысленно.

В некоторых случаях это понять проще (вспомните о запуске «Аполлона», когда думаете, начинать ли процедуру аварийного восстановления), в некоторых – сложнее. Например, полный отказ оборудования, пожар, наводнение или кража – это события, после которых нельзя быстро восстановиться, поэтому имеет смысл запустить аварийное переключение.

Однако другие события не столь очевидны. Например, ввод питания, который периодически выключается, но при этом для поддержания работы ключевых серверов как раз хватает ресурса ИБП (источника бесперебойного питания), или сбой сети, когда провайдер уверяет вас, что занимается проблемой и подключение будет восстановлено «очень скоро». Когда – «скоро»? Стратегия перехода в режим аварийного восстановления, включающая такие критерии, как затронутые сбоем службы и время, в течение которого они остаются недоступны, избавит от неопределенности, и вы будете четко понимать, когда пора щелкнуть воображаемым переключателем.

Определив, когда переключаться, спланируйте порядок перехода. В общем случае необходимо сделать следующее:

• Убедитесь, что все контактные данные, параметры сети и пароли хранятся в надежном и легкодоступном месте.

• Определите, какие службы необходимо запустить (если они находятся в режиме холодного резервирования) и заполнить актуальными данными.

• Определите все сетевые адреса, которые необходимо будет изменить, включая как публичные, так и внутренние записи DNS. Для внесения изменений в DNS потребуется время, в зависимости от срока кэширования записей зоны, поэтому предусмотрите это в плане.

• Определите все роли и параметры настройки, а также какие тесты необходимо выполнить для проверки резервной зоны и кто должен будет это делать.

• Если вы планируете возврат к исходной конфигурации, продумайте план перехода к основной зоне после устранения сбоя.

Сделав все это, составьте необходимые документы, разошлите их заинтересованным лицам и разместите в легкодоступном месте. Люди не должны судорожно искать пароль к консоли, когда им понадобится переключиться на резерв.

Крайне важно регулярно тестировать процедуру аварийного восстановления в нерабочее время, чтобы убедиться, что вся документация и процессы доступны и понятны. Системы развиваются, в них вносятся изменения, компоненты добавляются и удаляются. Процесс аварийного восстановления тоже должен развиваться и всегда соответствовать текущему состоянию системы, потому что об авариях обычно не предупреждают заранее.

Рекомендуется регулярно проверять средства аварийного восстановления, по крайней мере, раз в неделю, чтобы убедиться, что все данные при переходе на резерв по-прежнему передаются туда, куда нужно. Раз в квартал или каждые шесть месяцев отрабатывайте полное переключение, чтобы сотрудники освоили все процессы и не воспринимали сбой как экстраординарное событие. К тому же, как гласит старая поговорка, повторение – мать учения.

Хотя мы исходили из того, что система, для которой вы создаете стратегию аварийного восстановления, не работает в облаке, это не означает, что облако нельзя использовать как часть решения. Вполне допустимо при необходимости расматривать облако как временный центр обработки данных, и это может оказаться весьма выгодным.

Облако идеально подходит для «горячего» или «холодного» резерва, поскольку вы можете передавать в него данные и оплачивать только тот объем хранилища, который вы используете. Создать взаимозаменяемую конфигурацию в облаке немного проще, потому что вы платите только за то, что вам нужно, и тогда, когда вам это нужно. Облако упрощает тестирование различных конфигураций и стратегий при ограниченном бюджете.

Данные – это кровь нашей отрасли. Они поступают в организацию и выходят из нее, генерируют данные о движении данных, перерабатываются в другие данные, и все это необходимо сортировать, преобразовывать, хранить и обрабатывать. Данные – это больше чем файлы на жестком диске или строки в таблице. У них есть значение, контекст и ценность. И наоборот, в то же самое время они могут быть избыточными, отвлекающими и бесполезными. Необходимо уметь отличать полезные данные от информационного шума.

Раньше хранение данных стоило очень дорого. Сейчас, в облачной парадигме бесконечного хранилища, хранить данные стало дешево и просто как никогда (и стоимость продолжает снижаться с каждым годом). Из этого вытекают два вопроса: (а) стоит ли хранить вообще все и (б) как организовать хранение, чтобы данные оставались доступными?

Эффективная работа с данными и их защита – непростая задача. Безопасности в этой книге посвящена отдельная глава, поэтому сейчас мы лишь слегка коснемся некоторых ее вопросов. За данные компании отвечает CTO, и, по моему опыту, технические директора организуют работу с данными не так хорошо, как могли бы, в основном потому, что не понимают истинной ценности этого актива или не знают обо всех доступных инструментах и методах.

В этом разделе мы рассмотрим возможные способы хранения и основные типы данных в компании, а также вопросы безопасности, соответствия нормативным требованиям и прав собственности, с которыми вы можете столкнуться. Попутно мы познакомимся с актуальной терминологией в области данных, которая поможет вам разобраться со множеством поставщиков и решений в этой сфере, которые предлагаются на рынке.

Когда мы думаем о данных, мы, естественно, представляем их в виде папок с файлами. Именно так представляют себе данные типичные руководители высшего звена, причем большинство из них ограничивается электронными таблицами. Это нормально, учитывая, что топ-менеджеры в основном выходцы из финансовой среды. Они могут говорить о базах данных, на самом деле имея в виду большие листы Excel. Задача технического директора – помочь топ-менеджерам понять, что их самый ценный актив представляет собой нечто большее, чем электронные таблицы. Другая задача CTO – продумать и спланировать долгосрочное размещение данных, чтобы бизнес мог использовать их эффективнее.

Как мы уже сказали, хранение данных никогда не стоило так дешево, как сейчас, и больше нет оправданий для того, чтобы не сохранять их. Но что это на самом деле означает? И действительно ли нужно хранить всё? Чтобы ответить на эти вопросы, для начала рассмотрим основные типы хранилищ, в которые можно загружать данные:

• Файлы/папки. На сегодняшний день файл – автономный именованный набор данных, находящийся на физическом носителе, – по-прежнему является наиболее универсальным способом хранения данных. Существует множество популярных форматов файлов, таких как JSON, XML, CSV и TXT, и этот способ хранения данных универсален, потому что почти каждый инструмент способен открывать файлы и работать с ними. Файлы легко копировать, шифровать и перемещать, и ими легко делиться. Не существует ограничений на виды данных, которые можно хранить в файле.

• Реляционные хранилища (базы данных SQL). Данные, которые имеют общие атрибуты (столбцы) и связаны друг с другом (строки), прекрасно вписываются в структуру, которую мы называем таблицами. Таблицы могут быть связаны с другими таблицами, а наборы таблиц известны как базы данных. К таблицам можно выполнять запросы, используя специальный псевдоязык (SQL), который описывает команды для получения данных, их изменения или записи в таблицу новых данных. Это очень популярный механизм для хранения больших объемов одинаково структурированной информации.

• Хранилища NoSQL. В хранилищах NoSQL, или документных, отсутствуют структурные ограничения, свойственные реляционным хранилищам. В них сохраняется только то, что вы передадите, и не остается пустот на месте отсутствующих данных, как в реляционных СУБД. Группы документов образуют коллекции, в которых каждый документ может значительно отличаться от другого.

• Озеро данных. Озеро данных – это место для хранения большого количества файлов разной структуры и разного размера с целью резервного копирования или последующего анализа. Оно обычно используется в качестве промежуточного хранилища для данных, поступающих в организацию, пока для них еще не назначено постоянное место.

• Корпоративное хранилище данных (Data warehouse). Хранилище – это специально разработанная база данных, которая в основном используется для анализа и бизнес-аналитики (business intelligence, BI). В нем хранятся большие наборы данных, организованных таким образом, чтобы упростить составление отчетов и годовой анализ.

До появления облака создание и обслуживание хранилищ любого из этих типов было непомерно дорого, и на каждом этапе подготовки принимались решения о сокращении количества данных до минимально необходимого на текущий день. Если бизнес развивался и решал, что ему нужны более подробные данные, то сохранять их можно было только начиная с этого момента, а исторические данные были утеряны.

Файлы и базы данных распространены повсеместно. В каждой организации есть своя база данных – SQL Server, Postgres, MySQL или Oracle. Тем не менее зачастую БД плохо организованы, например, одна БД может использоваться одновременно для нескольких областей (скажем, для клиентского веб-сайта и для предоставления отчетов о состоянии бизнеса). Вместо этого у каждой области бизнеса должна быть своя БД, и данные должны реплицироваться между ними. Таким образом, когда финансовый директор задумает сформировать масштабный отчет о квартальных продажах, он не положит весь сайт.

Базы данных NoSQL (такие как MongoDB, CouchDB, DynamoDB и Elasticsearch) становятся все более популярными, особенно на ранних этапах разработки проектов, когда еще нет полного представления об итоговой структуре. Их производительность с годами увеличилась настолько, что при правильно выбранной организации данных они способны работать так же эффективно, как и их реляционные аналоги. Будьте осторожны и не увлекайтесь: некоторые команды строят всю систему на архитектуре NoSQL. В этом случае возрастает риск нарушения единообразия данных (то есть в разных документах одни и те же данные будут храниться в разных форматах, например, число 2 может быть представлено в строковом и целочисленном форматах, потому что где-то при обработке данных они не были приведены к одному виду). NoSQL не обеспечит вам ни целостность, ни единую структуру данных.

Озеро данных (Apache Hadoop, Amazon S3) – это одно большое пространство для хранения файлов. Однако это не просто крупное файловое хранилище. В озере данных есть инструменты и механизмы для просмотра файлов, чтобы вы могли выбрать то, что вам нужно. Например, оно отлично подходит для размещения журналов продакшена. Вам не нужно беспокоиться о формате файлов, он может меняться со временем. При необходимости озеро данных предоставит удобный механизм для перебора файлов журналов, чтобы найти заданное ключевое слово или строку (этот подход называется map/reduce).

Наконец, корпоративное хранилище данных (Amazon Redshift, SQL Server) – это место, куда поступают данные, необходимые для отчетности. Оно специально разработано для упорядочивания данных таким образом, чтобы их можно было очень быстро проанализировать для получения отчетов, необходимых бизнесу. Данные в хранилище обычно агрегируются, обезличиваются и выстраиваются таким образом, чтобы отвечать на вопросы бизнеса. Такое хранилище будет полезно, только если накоплено значительное количество данных. Традиционная реляционная СУБД тоже может обрабатывать запросы к данным, но придет время, когда ее окажется недостаточно.

В облаке все эти хранилища данных можно организовать без дополнительных затрат на запуск и управление серверами (и лицензиями). Подавляющее большинство команд, с которыми я работаю, только выиграли от переноса хранилищ данных в облако, где они масштабируются по требованию, поэтому нехватка места осталась в прошлом, а данные защищены гораздо лучше благодаря множеству инструментов, доступных по умолчанию.

Организация должна иметь хотя бы какую-то разновидность озера данных. Представьте, что это чердак – место, где хранится все, что вы не можете заставить себя выбросить, потому что однажды оно может вам понадобиться. Озеро данных – это место хранения данных, у которых нет постоянного дома, поэтому, если они однажды кому-то понадобятся, вы, по крайней мере, будете знать, что они у вас есть. Хотя поиск на чердаке может занять некоторое время, вы их там найдете.

Не все данные в организации одинаковы. Хотя это кажется очевидным, на удивление многие компании не осознают этого простого факта и в результате наживают множество проблем. Важно разбираться в основных типах данных, за которые вы отвечаете.

Хотя это и не исчерпывающий список, его можно взять за основу для выделения групп данных:

• Система учета – данные, которые считаются ключевыми для вашей компании, обычно они содержатся в БД. Данные этой категории считаются «истиной» для организации.

• Конфиденциальные/охраняемые данные – в эту категорию попадают данные, требующие дополнительной защиты. Примеры: паспортные данные, номера водительских прав, банковская информация, данные кредитной карты.

• Транзакционные данные – данные, которые генерируются в процессе продаж или оказания основных услуг; их часто называют операционными данными.

• Данные бизнес-аналитики – данные, которые используются для аналитики и отчетов; обычно это агрегированные/обезличенные копии транзакционных данных.

• Данные журналов – данные, генерируемые различными компонентами и программами, обеспечивающими работу системы. Эти данные используются для расследования ошибок/сбоев и аудита, а также для анализа производительности.

Для каждого класса нужно разработать правила, которые будут учитывать особенности вашей организации. Необязательно вдаваться в подробности, но определите по крайней мере следующие характеристики:

• Права собственности. Кто владеет данными этого класса? Проще всего предположить, что владелец – вы. Наличие прав собственности означает, что вы можете делать с данными все, что пожелаете (продать, удалить или даже сделать общедоступными, если захотите). Проведя анализ, вы, вероятно, обнаружите, что у вас есть данные клиентов/пользователей, которыми вы просто управляете. Также данные могли быть арендованы вами на ограниченный период времени (например, списки рассылки или наборы данных для анализа). Определение истинного владельца данных позволит вам выяснить, для чего и как разрешено их использовать.

• Хранение. Как долго предполагается хранить данные? Этот вопрос касается как оперативных хранилищ, так и резервных копий (если правами собственности это предусмотрено). Сюда же относится политика устаревания: как долго хранить данные до перемещения в долгосрочное (более дешевое) хранилище? В каких случаях можно удалить все данные, включая резервные копии (например, если клиент уходит от вас)?

• Видимость. Кто может видеть данные как внутри компании, так и вне ее и какими средствами будет обеспечено ограничение видимости (шифрованием, списками доступа и т. д.)? Когда данные устаревают или перемещаются в другой класс (например, когда оперативные данные становятся данными бизнес-аналитики), здесь будет определяться, какие изменения необходимо внести (например, обезличить данные пользователей), чтобы соответствовать правилам нового класса.

• Соответствие нормативным требованиям. Должны ли данные соответствовать нормативно-правовым или другим особым требованиям? Если да, необходимо внедрить дополнительные процессы аудита и обеспечения безопасности, которые могут различаться в зависимости от региона, где работает компания. Особого обращения требуют, например, персональные, медицинские и финансовые данные.

Данные – один из самых ценных активов, которыми компания управляет и владеет. Чем больше данных у вас есть, тем больше их генерируется. Грамотная работа с данными позволит компании избежать этических и правовых коллизий.

Особо следует выделить данные, для которых необходимо обеспечить соответствие нормативным требованиям. В основе любых ограничений (PII, HIPAA, PCI и др.) лежит требование безопасного и бережного обращения с данными. Если у вас есть такие данные, то, управляя ими, внедряйте все возможные способы защиты. Хотя для некоторых типов данных это может быть излишним, но это гарантирует, что вы выработаете в команде привычку относиться к этим данным ответственно, поэтому возможный аудит не станет потрясением и неожиданностью. Также планирование архитектуры с учетом обеспечения безопасности данных и возможности аудита обеспечит страховку на случай любых будущих изменений.

ПО с открытым исходным кодом (open source) – это ПО, которым члены сообщества разработчиков делятся друг с другом на безвозмездной основе и которое доступно каждому желающему, по крайней мере для просмотра, и, возможно, для использования в собственных проектах, с некоторыми ограничениями в зависимости от лицензии. Именно эти ограничения мы здесь и рассмотрим, поскольку многие компании не разбираются в их различиях и сталкиваются с юридическими трудностями при продаже или взаимодействии с отдельными клиентами или организациями.

ПО с открытым исходным кодом позволяет ускорить разработку любого программного проекта за счет использования готовых компонентов. Популярными примерами ПО с открытым исходным кодом являются операционные системы (яркий пример – Linux), серверы баз данных (MySQL, Postgres) и настольные приложения (Firefox, Open Office), а также программные библиотеки (JQuery, Gson). Учитывая степень распространения ПО с открытым исходным кодом, вы найдете в нем что-то полезное для себя на любом уровне.

Хотя у вас есть доступ к исходному коду этого ПО в интернете, это не значит, что у вас есть все права на его использование. Хотя я и могу сыграть Let It Be (на самом деле не могу) на фортепиано, это не значит, что мне можно продавать записи своего исполнения, не выплачивая гонорары правообладателям – Маккартни и Леннону. Так и с исходным кодом. Исходный код может быть защищен авторским правом, как и любое написанное слово, и обычно его использование ограничивается лицензией, которая определяет, что вы можете и что не можете с ним делать. Лицензии для исходного кода делятся на две большие категории:

• копилефт (Copyleft);

• разрешительные.

ПО с копилефт-лицензиями обычно считается неподходящим для бизнес-использования. Этот тип лицензий (наиболее популярной из них является Универсальная общедоступная лицензия (general public license, GPL)) подразумевает, что любое программное обеспечение, включающее код с лицензией GPL, должно само распространяться с лицензией GPL, включая все его модификации. Другими словами, если ваш секретный алгоритм использует ПО с лицензией GPL, то вы юридически обязаны сделать свой исходный код доступным для всех желающих, включая конкурентов.

Разрешительные лицензии (например, BSD, MIT или Apache) не имеют таких ограничений, поскольку они разрешают включать ПО с открытым исходным кодом в коммерческое программное обеспечение или дорабатывать продукты с открытым исходным кодом, а также объявлять производный продукт своей частной собственностью и закрывать исходный код, что, естественно, гораздо предпочтительнее для бизнеса.

Некоторые разрешительные лицензии обязывают вас публично уведомлять об использовании библиотеки в конечном продукте. Подобные уведомления можно увидеть в разделе «О программе» на некоторых устройствах (например, для телефонов на Android перечислены все использованные библиотеки с открытым исходным кодом).

Каждый из указанных типов лицензий содержит четкие формулировки в отношении авторских прав, патентной защиты и производных работ, различия между которыми достаточно незначительны и имеют значение, только если вы вносите большие изменения или создаете новый продукт на основе ПО с открытым исходным кодом.

Хотя GPL является исключительно копилефт-лицензией, существует ее облегченная версия (LGPL). Этот тип лицензии не требует делать код общедоступным в случае, если его связывание с лицензируемым ПО динамическое, а не статическое. Это гораздо более удобно для бизнеса, чем GPL.

Этот обзор различий ни в коем случае не стоит считать исчерпывающим, поэтому, если вам нужно подробнее углубиться в эту тему, проведите собственное исследование.

Старайтесь по возможности использовать ПО с открытым исходным кодом, особенно если вы работаете на Java, JavaScript или Python, поскольку на GitHub и SourceForge доступно множество ответов на вопросы и готовых утилит. Прежде чем вы дадите зеленый свет разработчикам, ознакомьтесь с рекомендациями о том, как лучше включать ПО с открытым исходным кодом в ваш продукт:

• Составьте список лицензий, которые может использовать команда, – скорее всего, это будут лицензии типа Apache/MIT/BSD.

• Библиотеки необходимо использовать целиком – не выделяйте отдельные фрагменты и не включайте их таким образом, как будто они были разработаны у вас. Воровство недопустимо.

• Создайте централизованный список всех внешних библиотек (например, общую электронную таблицу) со следующей информацией:

• имя библиотеки;

• URL веб-сайта;

• тип лицензии;

• компонент, в котором она используется.

Разработайте и передайте команде инструкции по использованию open source, чтобы она могла быть уверена в том, что вы поддерживаете, уважаете и поощряете использование открытого исходного кода.

Есть еще один способ работы с ПО с открытым исходным кодом – это поделиться своим кодом с другими. На это могут быть следующие причины:

• Вы много лет использовали результаты работы других людей и теперь хотите отблагодарить сообщество.

• Вы хотите повысить надежность своего продукта и просите других помочь в его отладке.

• Вы хотите установить стандарт в определенной нише и ускорить разработку, приглашая других присоединиться к ней.

Крупные корпорации, в том числе Google, Oracle, Microsoft, IBM, Netflix, Amazon и многие другие, выпускают ПО с открытым исходным кодом (под разными лицензиями). Например, Microsoft владеет GitHub – одним из крупнейших ресурсов, на котором размещаются open source проекты.

Если вы решите открыть исходный код библиотеки, разработанной вами или вашей командой, важно понимать, что вы не просто делаете ее общедоступной. Проект с открытым исходным кодом должен поддерживаться и обновляться. Никто не захочет участвовать в разработке библиотеки, которая годами не обновлялась. Чтобы ваша публикация пользовалась успехом, ее необходимо поддерживать так же, как внутреннюю библиотеку, и продолжать исправлять ошибки и добавлять функции.

Перед тем как создавать учетную запись компании на GitHub и публиковать там код, убедитесь, что генеральный директор (и юристы) понимают, что именно вы собираетесь делать и зачем вы это делаете. Продумайте, какой код вы опубликуете и в каком формате. Делясь кодом, будьте очень внимательны. Убедитесь, что вы не раскрываете ничего, что защищено правами интеллектуальной собственности или содержит коммерческую тайну компании. Кроме того, разумеется, публикуемый код должен принадлежать вам.

Для публикации отлично подходят небольшие библиотеки, которые ваша команда создавала, разрабатывая основной продукт. Это полезно еще и тем, что позволяет понять, в правильном ли направлении вы движетесь, особенно если вы встретите похожую библиотеку.

Неважно, насколько хороша ваша команда разработчиков – рано или поздно в поисках решения они полезут в интернет. Пытаясь выяснить, почему данная библиотека ведет себя так, а не иначе, или как что-то написать на данном языке, они в конце концов увидят какой-то код в своем браузере. Ответ на все их вопросы уже ждет, когда его выделят на странице – CTRL+C и затем CTRL+V в IDE или редакторе. Задача решена.

Не торопитесь: сам по себе факт, что код находится на StackOverflow.com или найден в сообщении в чьем-то блоге или статье, не означает, что его можно просто взять и включить в ваше решение. Помните, что любой код, созданный вашей командой, будет считаться активом и интеллектуальной собственностью вашей компании. Он должен быть создан добросовестно, не скопирован и не должен содержать элементов, защищенных авторскими правами. Вы ходите по юридическому минному полю, но, если будете руководствоваться здравым смыслом, поможете команде избежать ошибок.

В целом «копирование» кода с форумов разработчиков – это нормально. Все, что превышает 5 или 10 строк, стоит переписать, используя алгоритм только для вдохновения (просто переименовать переменные недостаточно). Чаще всего код на этих форумах демонстрирует примеры использования библиотеки или API и не является чьей-то собственностью.

Части кода из библиотеки с открытым исходным кодом можно копировать, только если это разрешено лицензией библиотеки, и в этом случае следует действовать так, как если бы вы интегрировали всю библиотеку (то есть зарегистрировать ее использование в вашем списке).

Выбор языка и фреймворка – еще одно важное решение, которое может принять технический директор. Это решение будет иметь далеко идущие последствия, возможно, даже более далекие, чем ваше пребывание в компании. Однако в большинстве случаев выбор языка уже сделан за вас, потому что вы унаследовали стек технологий от своего предшественника.

Бизнесу по большому счету все равно, на каком языке разработана система, пока она решает проблемы и пока клиенты довольны. Тем не менее переход на другой язык (или даже фреймворк) – задача не из легких. Помимо того, что в существующую команду разработчиков были вложены определенные инвестиции, а теперь потребуется ее переобучение, изменения затронут все процессы внедрения ПО и всю базу знаний, поддерживающую бизнес. Смена языка повлечет за собой переписывание больших компонентов системы, которое будет сложно обосновать.

Как вообще происходит выбор языка? Во многих компаниях, возглавляемых владельцами или основателями, основным языком обычно является тот, которым владел основатель или первый «технический директор». Они использовали его для написания всего, даже того, для чего он никогда не был предназначен. Это был не выбор языка, а отсутствие выбора.

В свою очередь фреймворк – это набор библиотек или стандартов для конкретного языка, который облегчает выполнение повторяющихся рутинных задач (например, обеспечения безопасности пользователя после авторизации или работа с файлами). Примеры фреймворка – Java Enterprise Standard или Spring для языка Java либо ReactJS для JavaScript и Express.js для Node.js. Зона ответственности фреймворков гораздо шире, чем у языков программирования, и поэтому они могут накладывать гораздо больше ограничений на способы реализации того или иного функционала. Разработчики, специализирующиеся на конкретном фреймворке, хотя и владеют базовым языком, могут столкнуться с трудностями при переходе на другой фреймворк для того же языка. Но знание фреймворка так же важно, как и знание языка.

Разные языки и фреймворки то становятся модными, то выходят из моды. Фреймворки создаются поверх языка, поэтому чаще именно они сменяют друг друга. Будет довольно неприятно, если компания вложила значительные средства в основной фреймворк, а через несколько лет он устарел. Тогда компания столкнется с необходимостью поддержки как решения, так и фреймворка, на котором оно построено.

Языки тоже устаревают, хотя и гораздо медленнее. Чаще всего перестают использоваться языки, связанные с конкретной компанией. По возможности не используйте их. Если компания-разработчик будет приобретена или разорится, язык умрет. Так произошло с Gupta, PowerBuilder, Delphi и бесчисленным множеством других языков, появившихся на рубеже этого века.

Выбирая язык, важно ориентироваться на пятилетнюю перспективу. Вы собираетесь сделать большие вложения, нанимая разработчиков, создавая базу знаний, разрабатывая процессы внедрения ПО и стандарты кодирования – все это в надежде, что язык будет развиваться, чтобы обеспечить вам больше возможностей.

Если ваш язык или фреймворк перешел в стадию заморозки, постарайтесь как можно скорее его заменить. Чем его заменять – мы рассмотрим в следующем разделе. Но язык нельзя менять только потому, что вы с ним не знакомы. Смотрите шире и принимайте решение по совокупности факторов, включая то, достаточно ли на рынке труда специалистов по этой технологии. Если ваша команда разработчиков стареет, а молодая кровь не прибывает, значит, используемый вами язык умирает.

Замена языка потребует значительных усилий и ресурсов. Как уже говорилось, одна из эффективных стратегий здесь – определить области, которые легко преобразовать в микросервис. Это даст возможность вырезать куски кода из системы, а не полностью переписывать ее.

Единственно верного ответа на вопрос, какой язык использовать, не существует. Это хорошо и плохо одновременно. Наша отрасль постоянно создает новые и лучшие технологии, и по сравнению с ними все существующее кажется хуже, чем оно есть на самом деле. Вы в любом случае будете испытывать сомнения покупателя, который, что бы ни купил, думает, что есть вариант получше, но если вы основываете свой выбор на результатах анализа, то он будет правильным для своего времени. Следующие вопросы помогут вам оценить языки/фреймворки:

• Кто является его разработчиком? Движущая сила, стоящая за языком, важна, особенно если это конкретная компания. Какая часть ее доходов зависит от успеха этого языка? Если условия для бизнеса изменятся, выживет ли она и что с ней произойдет при этом? Языки, созданные вокруг независимого комитета по стандартизации, обычно имеют больше шансов на долгожительство.

• Как давно он существует? Зрелость – важный фактор. Ваша цель не стать защитником языка, а обеспечить решение задач и стабильность для ваших клиентов. Старайтесь избегать языков, существующих менее двух лет, – за этот срок другие успеют пройтись по всем граблям в языке и станет понятно, сможет ли он расти и расширяться.

• Насколько активно тематическое сообщество? Когда у разработчика возникает вопрос, он обращается к поисковику. Но если язык новый, данных о нем мало. Изучите, насколько активно интернет-сообщество пользователей данной технологии: сколько результатов поиска выдается по запросу, существуют ли активные группы пользователей, есть ли у языка живое и деятельное сообщество open source, сколько книг было опубликовано по этому языку?

• Учат ли его в вузах? Убедительным доказательством перспективности языка служит то, что его изучают в университетах. Вузы обязаны думать о долгосрочной перспективе, поскольку студенты должны получать знания, которые останутся актуальными еще несколько лет после выпуска. Как правило, языки, привязанные к одной компании, в университетах не изучаются.

• Насколько широко эта технология представлена на рынке труда? Представьте, что завтра вам нужно будет подобрать большую команду. Сможете? Просмотрите сайты вакансий, позвоните в агентства и оцените не только количество вакансий, в которых этот навык требуется, но и количество кандидатов, обладающих этим навыком. Если язык только начинает развиваться, вам придется значительно переплачивать узкому кругу экспертов.

Принять правильное решение бывает сложно; однако с последствиями ошибки вы столкнетесь очень быстро. Потратьте достаточно времени на анализ и выбирайте с умом. Не поддавайтесь соблазну выбрать технологию, которая использовалась для проверки концепции, потому что обычно она не слишком хорошо масштабируется при создании полноценного продакшена.

Одна из самых сложных задач технического директора – сообщать бизнесу сроки. Работаете ли вы над крупной инициативой либо проектом или же над небольшой функцией, другие должны знать о ходе работы, чтобы иметь возможность планировать свои задачи, зависящие от ваших результатов. Неумение технарей придерживаться сроков печально известно. Мы с легкостью назначаем срок, а потом его и близко не соблюдаем. Причина в том, что мы вечные оптимисты, которые верят, что вещи не так сложны, как на самом деле. В общем и целом мы правы; однако в своих прогнозах мы не учитываем внешние обстоятельства, которые вмешиваются и нарушают идеальный план (если бы клиенты постоянно не надоедали, мы бы совершенно точно все успели!).

Поэтому прогнозировать сложно. А учитывая внешние обстоятельства, новые данные и расползание функционала, порой это кажется невозможным. Однако это не обязательно должно быть так. Чтобы даже самый требовательный генеральный директор терпеливо ожидал результатов от вашей команды, вам понадобится планировать все немного более тщательно, а также изменить оптимистичный стиль общения с бизнесом.

Организации бывают двух типов: те, в которых есть хороший руководитель проектов (проджект-менеджер), и те, в которых его еще нет. Причинами, по которым нет выделенного руководителя проектов, могут быть как недостаточный бюджет (уважительная), так и отсутствие необходимости в нем, потому что технический директор сам может управлять проектами (неуважительная). Но независимо от причины его отсутствия – руководитель проекта необходим всегда, когда у вас больше пяти технических специалистов. Если разработчиков меньше – в большинстве случаев они сами эффективно координируют свои действия.

Для целей этой книги предположим, что скрам-мастер и руководитель проектов выполняют одни и те же задачи. Хотя можно найти различия, принципиально эти роли очень схожи. Руководитель проектов помогает достичь ваших целей, управляя всеми ресурсами и сообщая их статус, планируя и поддерживая в актуальном виде сроки исходя из текущей ситуации. Вопреки распространенному убеждению, руководитель проектов не должен ставить задачи и назначать ответственных – это функция лидов. Если есть риск несоблюдения сроков, он оперативно сообщит вам об этом, а также о причинах задержки, что даст вам возможность принять меры, если нужно. Также он проводит периодические собрания и следит за тикетами, чтобы в реальном времени видеть состояние работы. Хороший проджект-менеджер поощряет открытый обмен информацией, независимо от того, хорошие новости или плохие, чтобы постоянно держать руку на пульсе проекта.

Для этой роли нужны врожденные способности организатора в сочетании с практичным взглядом на жизнь и методическим подходом к процессам. Мы, технари, обманываем себя, думая, что в сутках больше 24 часов, а проджект-менеджеры знают, что на самом деле в обычном рабочем дне всего шесть часов (с учетом перерывов, обедов, походов в туалет, размышлений о вечном и т. д.). Они знают, что тому, кто вернулся из отпуска, потребуется время, чтобы войти в рабочий ритм, тогда как мы верим, что он начнет работать сразу по возвращении из двухнедельного отпуска, в течение которого он лежал на пляже, полностью отключившись от шума и суеты офиса.

Управление проектами – это не наука, а искусство, потому что необходимо учитывать постоянно меняющийся ландшафт, отфильтровывать лишнее и непрерывно корректировать путь к цели. Каждый, кому доводилось управлять дроном, вероятно, оценил его софт, который поправляет траекторию полета, когда порыв ветра сбивает его с курса. Кажущаяся легкость, с которой дрону удается сохранять свое положение, управляя воздушными винтами в реальном времени, впечатляет. Руководитель проектов подобен такому дрону в том, что он анализирует все входные данные и прогнозирует, что произойдет, если пойти по той или иной траектории, и затем сообщает эту информацию техническому директору для принятия корректирующих мер. Менеджер проекта поможет:

• Контролировать результаты работы каждого сотрудника.

• Определить основные этапы и цели.

• Запланировать сроки и регулярно корректировать их для повышения точности.

• Координировать релизный цикл.

• Управлять передачей промежуточных результатов в процессе работы, а также коммуникацией с внутренними/внешними командами.

• На основании данных о ходе проекта предлагать действия, направленные на более эффективное управление временем.

• Отчитываться о состоянии всего; следить, что ничего не упущено и не забыто.

В компаниях, где объем работы по управлению проектами невелик, эти сотрудники обычно также берут на себя роль бизнес-аналитика, который помогает детализировать задачи со стороны бизнеса. Однако руководитель проектов в любом случае в той или иной степени занимается такой детализацией, поскольку одна из его задач – разбить проект на понятные этапы.

Очень важно поддерживать с проджект-менеджером постоянную связь – например, ежедневно. Менеджер не должен бояться сообщать вам плохие новости, поэтому вам необходимо воздерживаться от непрофессиональной реакции на них или обвинений. Также он будет напоминать вам о том, что необходимо сделать, и будет вносить это в планы – например, про ежегодное техническое обслуживание, которое требует выделения части команды для выполнения обновлений. Если подобные события будут запланированы и ожидаемы, то команде не придется постоянно решать неожиданные проблемы и она сможет работать как отлаженный механизм. А ваше общение с генеральным директором и правлением будет содержать гораздо меньше сюрпризов.

СИСТЕМА УПРАВЛЕНИЯ ЗАДАЧАМИ

Чтобы эффективно управлять командой любого размера, важно всегда знать, над чем она работает сейчас и какая работа запланирована. Технари, как правило, любят доводить дело до конца – нам нравятся списки задач, и мы получаем удовлетворение, когда ставим галочку о том, что та или иная задача выполнена. Сопоставив эти условия, вы поймете, почему использование системы управления задачами (или тикетами) является лучшим способом управления в IT. Отраслевым стандартом здесь является Atlassian Jira, которая выводит работу с тикетами на совершенно новый уровень. Существует и множество альтернатив, но все они работают по одному и тому же принципу: в них есть тикеты с уникальными идентификаторами – это единицы работы, назначаемые конкретному исполнителю на конкретное время. У тикетов есть определенный жизненный цикл: от статуса «открыт» через промежуточные статусы к статусу «закрыт». Статус «закрыт» может означать, например, что задача была завершена или что она не была взята в работу, поскольку уже неактуальна. Статус «открыт» означает, что задача будет показываться исполнителю и ее необходимо выполнить.

Задачи могут быть сгруппированы в эпики, истории или проекты (о гибких (agile) подходах к разработке мы поговорим позже), а также могут включать подзадачи. Вы сами устанавливаете правила работы с тикетами, но, какими бы они ни были, их необходимо донести до команды, чтобы ни у кого не возникало вопросов.

Например, тикет должен представлять собой такую единицу работы, выполнение которой занимает не более определенного периода времени (пусть это будет четыре часа). Если требуется больше времени, то тикет следует разделить на подзадачи меньшего размера. У этой техники есть дополнительный бонус, заключающийся в возможности не тратить время понапрасну. Если человек начинает работать над задачей и в середине работы выясняется, что он не сможет ее завершить, то он может остановиться и попросить помощи. Возможно, он слишком усложняет работу над задачей, или же сотрудник, поставивший ее, недооценил ее сложность и ее нужно разбить на ряд более мелких задач. Выполнение тикета не должно занимать несколько дней или недель – это значительно усложняет управление проектом. Но какой бы уровень детализации вы ни выбрали, он должен подходить для вашей организации, и о нем необходимо сообщить другим. Если вы научите команду работать с тикетами, актуализировать приоритеты и планировать каждый день – это будет постоянно приносить дивиденды в будущем, поскольку все смогут видеть загрузку команды, а сотрудники смогут самостоятельно управлять своими списками задач.

Еще одно большое преимущество централизованной системы управления тикетами в том, что она устанавливает единый язык для обсуждения всего, что связано с задачами. Я с огромным удовольствием слушаю, как команда перебрасывается номерами тикетов, обсуждая, что предстоит сделать, или когда кому-то нужна помощь. Номер задачи позволяет любому найти ее, посмотреть ее историю, прочитать комментарии, увидеть код, связанный с тикетом, и получить всю информацию о проблеме, чтобы оказать помощь максимально эффективно.

Система управления задачами, если ее правильно поддерживать, также может стать живой, самообновляющейся базой актуальных знаний, особенно если она используется в качестве системы поддержки клиентов. Для этого тот, кто закрывает тикет, должен подробнее расписать шаги для решения проблемы, и этой информацией смогут воспользоваться другие сотрудники.

Разработчики и инженеры не всегда следят за актуальным статусом задач. Здесь также на помощь приходит руководитель проектов, который следит за своевременным обновлением тикетов, а лучшие проджект-менеджеры показывают всем важность этого и таким образом приучают всех делать это без напоминаний. Подавляющее большинство своих отчетов и текущей работы руководитель проектов выполняет в системе управления задачами, поэтому в его интересах добиваться актуальности данных в его главном инструменте. Также в этой главе я покажу, как система управления задачами может помочь в планировании релизов.

Общее определение проекта ни у кого не вызывает возражений: это набор связанных друг с другом задач, выполнение которых приводит к желаемому результату. Разногласия возникают при обсуждении масштаба: насколько большая задача может считаться проектом? Проект может быть рассчитан как на несколько дней, так и на годы. Независимо от продолжительности, у проекта должна быть конкретная цель – основная причина, по которой он существует. Цель не говорит о том, какими способами и в какие сроки она должна быть достигнута. Она всего лишь определяет критерии успеха, выполнение которых означает, что проект завершен.

Цели проекта необходимо сформулировать языком, понятным не-разработчикам. Это обеспечит прозрачность и более эффективную коммуникацию, особенно с генеральным/финансовым директором, которым нужно знать, на что вы и ваша команда тратите время и деньги. Ниже приведены два разных описания целей одного и того же проекта:

• Внутреннее описание. Переделать процесс интеграции новых клиентов, убрав зависимость от Windows XP и реализовав его в виде Java-приложения, предназначенного для использования в бессерверной архитектуре.

• Внешнее описание. Модернизировать процесс подключения новых клиентов, переписав его для облака, чтобы повысить гибкость и скорость работы.

Определение результата проекта – это легкая часть. Теперь необходимо понять, как добиться этого результата. Для этого нужно разбить основную задачу на более мелкие, выполнение которых приведет нас к цели. В IT существует два основных подхода к реализации проектов. Традиционный подход называется каскадным, или же «водопадом» (waterfall), а целый набор более современных подходов – гибкими методологиями разработки, или agile.

Эта модель предполагает максимальную степень планирования до начала работ. Идея здесь в том, что, как в водопаде, все начинается сверху и движется только вниз. Основной акцент делается на анализе предметной области, при котором выявляются все задачи и проблемы, которые необходимо решить. Затем принимаются основные решения, касающиеся архитектуры и деталей реализации. Каскадная модель ставит целью получить как можно больше данных, прежде чем выделять ресурсы для проекта.

На предварительное планирование уходит много времени, но чем четче определен проект – тем проще спрогнозировать для него сроки и стоимость работ. Кроме того, такие проекты благодаря своей продуманности отлично подходят для участия во внешних тендерах.

Однако то, что на детализацию и планирование проекта уходит много времени, является и одним из основных недостатков каскадного подхода, особенно если проект крупный, потому что, пока планирование не будет завершено, приступать к реализации нельзя. Представьте проект, цель которого – доехать из Майами в Сан-Франциско: команда не сможет начать движение, пока маршрут не будет проработан во всех деталях.

Еще более важный недостаток каскадной модели – ее неспособность работать с изменениями. Изменения появляются по самым разным причинам: какие-то технологии или требования могут потерять актуальность, в проект может добавиться новый функционал. Иногда в больших проектах такие проблемы просто игнорируются и все продолжают следовать плану, поскольку внедрить изменения чрезвычайно сложно. Случается, что реализованный проект уже не решает изначальную задачу и основан на устаревшей технологии (такое чаще встречается в государственных проектах или в акционерных компаниях, поскольку в этих сферах любые изменения требуют слишком большого количества согласований, которые блокируют работу).

При использовании каскадной методики создается большое количество предварительной документации, которая может включать макеты и прототипы и обычно разрабатывается совместно экспертами по предметной области, бизнес-аналитиками, архитекторами и руководителями проектов.

Если водопадная модель предполагает, что все детали должны быть известны до начала проекта, то на другом конце спектра находятся гибкие методологии, при использовании которых проблемы решаются по мере их появления. (На самом деле это упрощение – бывает, что только отдельные проблемы не исследуются или не решаются до начала разработки.) Гибкий (agile) – значит способный адаптироваться к изменяющейся среде, поэтапно приближающийся к конечному результату, быстро и успешно реагирующий на изменения. Например, вернемся к нашему проекту поездки в Сан-Франциско, на этот раз использовав гибкую методологию: поняв, как ехать по штату Флорида, мы разрешаем команде двигаться к его границе, одновременно с этим планируя следующие шаги. Гибкие методологии – это набор руководящих принципов, обеспечивающих непрерывное внедрение результатов работы и вовлечение в процесс всех заинтересованных сторон, включая конечного клиента или пользователя, для обеспечения высокого качества, поскольку при этом проблемы выявляются и устраняются гораздо быстрее.

Многие считают, что гибкий подход – это просто отсутствие планирования, что абсолютно неверно. Такие проекты точно так же требуют планирования, просто не такого подробного, как при каскадном подходе. Для них определяются промежуточные цели (или, в agile-терминологии, эпики), они затем превращаются в набор задач, которые можно брать в работу. Затем эти задачи объединяются в ограниченные по размеру периоды работы, или спринты. Обычно они продолжаются 1–2 недели, и после каждого спринта проводится разбор итогов. Как правило, по результатам каждого спринта какая-то часть функционала должна быть уже готова к использованию, чтобы другие по возможности могли начинать работать с ней.

Agile может быть ориентирован в первую очередь на процессы, что поначалу может пугать. Но это скорее набор руководящих принципов, чем строгих правил, которым необходимо обязательно следовать, – то есть структура, обеспечивающая необходимый уровень порядка и последовательность действий там, где это нужно. Некоторые организации настолько зацикливаются на правилах, что работа лишается всякого удовольствия и творческого подхода. Секрет успеха гибкой методологии состоит в том, чтобы найти баланс, подходящий именно для вашей команды. В качестве одного из примеров гибких подходов к разработке можно привести методологию скрам (scrum).

Гибкий подход значительно упрощает внесение изменений, поскольку позволяет увидеть, работает ли решение, до того, как на него будет потрачено слишком много ресурсов. Способность адаптироваться – вот ключ к успеху agile. Для того чтобы внедрить ту или иную методологию, сначала определите и формализуйте области, в которых не потребуется менять привычный вам порядок работы, а затем постепенно адаптируйте остальные процессы, позволяя команде привыкнуть к новой организации работы по мере того, как она начинает приносить плоды. Более подробный обзор гибкой и каскадной методологий можно найти здесь: https://www.guru99.com/waterfall-vs-agile.html.

Обеспечение качества (QA), или тестирование, как и все темы, рассматриваемые в данной главе, является целой отдельной дисциплиной. Цель QA очень проста: проверить, будет ли то, что вы только что разработали или внедрили, делать то, чего вы от него ожидаете?

Тестирование – сложная область, возможно, это одно из самых сложных направлений в вашем отделе. Предсказать все варианты использования и действия, с которыми придется столкнуться вашему ПО, почти невозможно. Тесты как деньги: неважно, сколько их у вас уже есть, вам всегда нужно немного больше.

Одно совершенно точно: мы, инженеры, плохие тестировщики, особенно если речь идет про результаты нашей собственной работы. Поэтому всегда рекомендуется, чтобы кто-то (или что-то) со стороны проводил независимое тестирование. Выделите отдельную команду контроля качества, не имеющую отношения к разработке, чтобы они проверяли исправления и новый функционал с точки зрения конечного пользователя. Скорее всего, вам понадобится внедрить тестирование следующих двух видов:

• ручное;

• автоматизированное.

Как следует из названия, ручное тестирование предполагает участие человека, который подтверждает успешное прохождение одного или более тестов. Обычно оно проводится, когда автоматизированные тесты для каких-то сценариев слишком сложны в реализации или ненадежны.

Как правило, есть выделенная команда QA, которая очень хорошо знает продукт и разработала набор планов тестирования как минимум для областей, которые используются чаще всего. Хорошей практикой является создание плана и методологии тестирования, чтобы любой мог выполнить тесты и не возникало ситуации, когда только один человек знает, как правильно тестировать код.

Тестирование может занимать очень много времени, и, в зависимости от тестируемой области, быть довольно утомительным. Это может приводить к тому, что, например, если какие-то тесты всегда проходят успешно, в очередной раз тестировщик может пропустить их, предположив, что все работает. Это создает риски для проекта, но отслеживать подобное очень сложно.

К участию в тестировании можно подключать новых разработчиков, прежде чем давать им задачи по написанию кода. Так они не только познакомятся с продуктом, но и получат представление о том, как организуется тестирование проекта и что необходимо для обеспечения высокого качества.

Мечта любого технического директора, инженера или владельца продукта – добиться полного покрытия кода автоматизированными тестами. Автотесты работают без участия человека, и их можно выполнять как часть процесса сборки и деплоя приложения. Они могут включать в себя модульные тесты (unit tests), тестирование API, тестирование функционала для конечных пользователей – все, что последовательно проверяет кодовую базу без участия человека.

Сложность создания и поддержки автоматизированных тестов состоит в том, что для правильного выполнения бизнес-логики требуется разработка соответствующих сценариев и тестовых данных. Например, вам нужно протестировать удаление учетной записи пользователя. Часть теста заключается в том, чтобы выполнить удаление учетной записи и убедиться, что она удалилась. Ничего сложного? Так и есть, но, чтобы иметь возможность удалить учетную запись, сперва ее нужно создать. Вот такой порочный круг – добро пожаловать в тестирование.

Покрытие кода – важная метрика, которую следует учитывать при оценке качества тестов. Она показывает, какая часть исходного кода фактически выполняется при прохождении теста. Но не весь код одинаков – какие-то фрагменты кода гораздо важнее других, особенно те, которые выполняются чаще или предоставляют критически важные сервисы.

Поэтому при оценке покрытия кода необходимо определить наиболее важные компоненты. Для них необходимо обеспечить максимальное тестирование. 100 % покрытия кода достичь почти невозможно; хорошим результатом можно считать 50–70 %.

Автоматизация исключает из ручного тестирования повторяющиеся действия, помогая избежать утомления, при котором пропускаются важные шаги. Разработка системы автотестов требует большого количества работы; кроме того, ее необходимо поддерживать в актуальном состоянии. Добавление каждой новой функции может привести к невыполнению тестов, которые приходится обновлять.

Если сроки проекта поджимают, чаще всего пренебрегают тестами. Может возникнуть ситуация, когда сборка приложения блокируется невыполняющимися автотестами. Вы убеждаете себя, что тесты не проходят из-за новой бизнес-логики и никаких ошибок нет. Таким образом, вместо того чтобы доработать тесты, вы выключаете их, что позволяет успешно выполнить сборку и уложиться в срок.

Время летит, дни и недели проходят, а автотесты так и остаются выключенными и неактуальными. Мы всё это проходили – еще один пример технического долга в системе. Использование автоматизированного тестирования требует большой дисциплины, но оно того стоит, а актуальный набор тестов всегда будет приносить вам дивиденды.

Без результатов ваша работа не имеет никакого значения. Выпуск релизов вашего продукта или обновление всей активно используемой корпоративной платформы может стать безболезненным и будничным делом, но, если вы хотите, чтобы это не требовало усилий, – вам придется как следует поработать.

Прежде обновление программного обеспечения было целым отдельным проектом – для него планировался технологический перерыв, обычно в нерабочие часы, направлялись уведомления клиентам, готовился порядок действий, которые затем выполнялись в надежде, что все пройдет по плану, потому что об откате изменений не хотелось даже думать. Сравните с современной архитектурой, в которой обновления при необходимости выполняются несколько раз в день без прерывания сервиса.

В этом разделе мы рассмотрим составляющие грамотной стратегии выпуска релизов, а также что необходимо подготовить и какие коммуникации наладить для ее успешного выполнения. «Выпускай понемногу и часто» – это не просто красивые слова, это достижимая цель.

Первый тип релизов выполняется с простоем: для него необходимо отключить систему. Это может быть связано с необходимостью перезапуска каких-то компонентов либо с необходимостью выполнить миграцию данных для перехода к новой версии. Такие релизы требуют больше усилий и предварительного планирования. Процедура их проведения может включать следующее:

• Определите, что нужно вывести в офлайн: серверы, компоненты.

• Что будут видеть конечные клиенты: нужно ли создавать специальную страницу с информацией о работах?

• Рассчитайте следующие сроки:

• время на выключение сервиса;

• время на резервное копирование;

• время на обновление программного и аппаратного обеспечения;

• время на проверку, что все работает;

• время на приведение системы в доступное для пользователей состояние.

• Для каждого из этих этапов распишите точный порядок действий.

• Для каждого этапа назначьте ресурсы и определите процесс перехода к следующему этапу.

• Определите совместно с бизнесом наиболее удобное время проведения релиза, желательно в период наименьшего использования системы.

• Составьте список тех, кому необходимо предоставлять отчеты о ходе работы, и тех, кого необходимо уведомить о завершении релиза.

Теперь у вас есть план выполнения релиза. Предусмотрите запас времени на случай возникновения проблем. Например, если выключение сервиса на все выходные не является проблемой для бизнеса и при этом вы ожидаете, что вам понадобится всего 2–4 часа, все равно планируйте выключение на все выходные. Если вы справитесь раньше – отлично, но, если что-то пойдет не так, у вас будет время решить проблему без необходимости дополнительно это согласовывать.

При проведении релиза необходимо информировать всех заинтересованных лиц о выполнении каждого этапа. Не скрывайте плохие новости – если все затянется или пойдет не по плану, лучше сказать об этом, чем устраивать радиомолчание и заставлять людей думать, что процессом никто не управляет.

В идеале, особенно если вы делаете релизы часто, найдите время для тестовых прогонов. Это не всегда возможно, в зависимости от того, какая система требует обновления. Например, миграция бэк-офисной системы (такой как электронная почта) с одной платформы на другую занимает много времени, и проверить ее в полном объеме может быть сложно.

После завершения релиза проведите ретроспективу, чтобы отметить, что прошло хорошо, и изучить, что пошло не так или что можно сделать лучше в следующий раз.

Традиционно, когда кто-то думает об обновлении, он представляет себе замену кода на сервере (то есть буквальную замену файлов в файловой системе). Это сопряжено с большим риском и, конечно же, усложняет откат к предыдущему состоянию, потому что в файловую систему были внесены изменения.

Появление виртуализации, благодаря которой запуск новых серверов стал занимать минуты или даже секунды, открыло возможности для радикального переосмысления многих подходов к работе, и, в частности, к выпуску релизов. Вместо обновления текущих серверов вы можете создать совершенно новую копию с новой версией ПО, полностью настроенную и готовую к работе. После развертывания (если вы используете Docker или что-то подобное, можно создать скрипты для его ускорения) вы можете проверить работу новой версии, а «текущий» набор серверов пока продолжит обслуживать запросы от пользователей.

Убедившись, что все в порядке, вы можете начать направлять трафик на новую версию, и, когда он будет переведен полностью, старую версию можно будет удалить, так что продолжит работать только новая версия. Если же что-то пойдет не так, вы можете удалить новую версию и начать сначала – пользователи при этом даже ничего не заметят.

Такой способ развертывания называется сине-зеленым (blue-green), и если вы его освоите, то сможете проводить релизы спокойно и безболезненно. Дополнительным преимуществом этого способа является постоянная проверка скриптов для развертывания инфраструктуры. Чем сложнее ваша архитектура, тем сложнее в реализации будет этот способ деплоя, однако ничего невозможного тут нет. И он идеально подходит для веб-приложений.

Одна из самых сложных вещей в любом релизе – изменение схемы базы данных. Правило здесь простое: только добавляйте, никогда не удаляйте. Удаление делает невозможным откатить обновления, не прибегнув к восстановлению из резервных копий. Вы сможете удалить таблицы, столбцы и индексы позже в будущих релизах, когда будете уверены, что этот функционал работает нормально и его не придется откатывать.

Когда вы добьетесь того, что релизы будут хорошо отработаны и будут проходить безболезненно, вы избавитесь от стресса и рисков, связанных с обновлениями, и они перестанут быть значительным событием. Независимо от того, какую стратегию вы выберете, всегда создавайте описание релиза (release notes), в котором описывайте все изменения, – это очень полезная привычка. Это может быть просто текстовый файл, документ в вики или же страница в Atlassian Confluence. Некоторые системы управления задачами позволяют привязывать тикеты или спринты к версиям ПО и автоматически создавать описание релизов.

Это очень полезный документ, особенно если конечный пользователь должен понимать, какие обновления были выпущены. В этом случае описание релиза можно изложить языком, понятным для конечного пользователя.

Рано или поздно вы начнете пользоваться услугами сторонних компаний – а может быть, уже пользуетесь. Они могут привлекаться в следующих целях:

• Пополнение штата сотрудников.

• Выполнение конкретного проекта.

• Оказание поддержки.

• Управление системой.

Хороший договор здесь – это такой, из текста которого обе стороны четко понимают свои обязательства, а также стоимость оказания услуг. Не обязательно для этого расписывать много страниц юридических тонкостей, но как минимум ваши ожидания должны быть четко изложены.

Подобно книге, договор должен иметь начало, середину и конец. В первой части указывается дата начала оказания услуг, любые предварительные условия, которые должны выполняться, и стоимость работ. Если предполагается создание какого-то продукта, то четко пропишите передачу прав собственности на результаты, она может быть привязана к ежемесячным платежам.

В середине описываются детали того, что вы ожидаете от подрядчика, в том числе результаты работ, ответственность, отчетность и необходимость соответствовать тем или иным требованиям. Этот раздел не должен быть ни слишком подробным, ни, наоборот, слишком общим.

В конце договора указываются условия передачи результатов и завершения сотрудничества. Эта часть также может включать положения о досрочном прекращении действия договора по инициативе сторон.

Расторжение договора не обязательно является негативным событием. Причиной может быть изменение требований бизнеса. Часто расторгаются договоры на поддержку устаревших систем, которые перестают использоваться: цель замены или доработки этих систем как раз и состоит в уменьшении расходов.

Заметки с полей

Читайте, что написано мелким шрифтом

Философу Юджину Льюису Фордсворту (Eugene Lewis Fordsworthe) приписывают высказывание: «Допущения – источник всех ошибок», – и это действительно так, когда речь идет о договорах. Я участвовал в аудите due diligence от имени частной инвестиционной компании, которая намеревалась приобрести компанию, занимающуюся разработкой ПО. У этой фирмы не было разработчиков в штате, и все свои проекты она передавала стороннему подрядчику. Предполагалось, что правами на все результаты работы владеет заказчик. Однако тут была проблема: в договоре не была прописана передача прав интеллектуальной собственности на конечный продукт, и заказчик не мог его продавать. Полагая, что это просто недоразумение, и учитывая их прекрасные многолетние отношения, компания посчитала, что урегулировать юридическую сторону дела не составит проблем. Однако люди ведут себя непредсказуемо, когда речь идет о больших деньгах. В итоге они не смогли договориться. Подрядчик воспользовался ситуацией и начал выдвигать новые требования. Излишне говорить, что инвестор отказался от сделки, и все потому, что кто-то не прочитал то, что было написано в договоре мелким шрифтом.

Тем не менее иногда деловые отношения не складываются как из-за невыполнения обязательств, так и из-за личных конфликтов или неудовлетворительного качества услуг. Пункты о возможности прекратить действие договора необходимы для того, чтобы расторжение произошло обоснованно, своевременно и профессионально. Как правило, при этом предусматривается срок, в течение которого другая сторона может найти альтернативного поставщика или нового заказчика, обычно от двух до восьми недель. Если это договор на привлечение сотрудников – чаще всего устанавливается месячный срок.

Договор оказания услуг часто дополняется следующими документами:

• техническим заданием;

• описанием параметров оказания услуг.

Выбор поставщика услуг мало чем отличается от подбора нового сотрудника в команду. Первым делом необходимо составить список ожидаемых результатов. Он может иметь вид или технического задания (ТЗ), или заказа на поддержку. В документе должно быть достаточно подробностей: участвующие в тендере компании должны понимать, что им нужно будет сделать, чтобы условия контракта считались выполненными.

Эти документы обычно обсуждаются с потенциальными поставщиками после подписания NDA (соглашения о неразглашении), которое дает обеим сторонам возможность вести переговоры, не опасаясь утечки конфиденциальной информации. Тем не менее наличие обязательств о неразглашении не означает, что вы можете рассказывать все – в любом случае лучше ограничиться как можно меньшим количеством информации и сообщать только то, что имеет отношение к обсуждаемому договору.

Типовое техническое задание содержит следующую информацию:

• Объем работ: что нужно делать, что не нужно.

• Предоставляемые результаты: исходный код, библиотека или сервис.

• Момент передачи прав интеллектуальной собственности на результат работы.

• Доступы, необходимые для выполнения работ.

• Разрешения/ограничения на использование определенных сотрудников или привлечение субподрядчиков.

• Процесс согласования дополнительных работ, лицензий или командировок.

• Гарантийные обязательства.

• Срок действия договора.

• Условия продления / внесения изменений / прекращения действия договора.

• Ограничения возможных вариантов реализации.

• Условия оплаты.

Степень детализации ТЗ зависит от планируемого взаимодействия. Для ресурсов, предоставляемых быстро и по запросу (таких, как привлечение разработчиков), характер выполняемой работы обычно указывается кратко. Например: «Услуги разработки на языке Java по запросу менеджера проекта», – без перечисления конкретных задач. Однако в этом случае обычно обозначаются минимальные сроки работ и добавляется условие, что компания не может напрямую нанимать на работу персонал подрядчика без предварительного согласования в течение, например, двух лет после завершения срока действия договора.

Если это договор на поддержку ПО – в ТЗ может оговариваться, для каких версий ПО предоставляется поддержка, с какой частотой выполняются обновления и каков порядок взаимодействия с бизнесом при необходимости выключения ПО на какой-то период.

Хорошее техническое задание должно быть достаточно подробным, чтобы обе стороны четко понимали свои обязательства, но при этом гибким, чтобы адаптироваться к изменениям по мере вашего развития. Ни одна из сторон не должна чувствовать себя связанной чрезмерными обязательствами, поэтому старайтесь не заключать соглашения на слишком длительный период. Примеры ТЗ см. на странице https://www.projectmanager.com/blog/statement-work-definition-examples.

Параметры оказания услуг, или SLA (service-level agreement), обычно определяют верхние или нижние границы различных характеристик услуги или продукта. Например, ожидаемое время доступности сервиса и какова компенсация в случае, если оно не обеспечивается.

AWS в SLA для службы Elastic Compute Cloud (EC2) указывает, что доступность сервиса в месяц составляет не менее чем 99,99 % времени, а в случае невыполнения этого требования клиенту будет предоставлена скидка в размере 10 %. Это значит, что время недоступности сервиса может составлять около шести минут (точнее, четыре с половиной минуты – прим. редактора) в месяц, если оно будет больше – Amazon должен будет вернуть вам 10 % от суммы вашего счета за EC2 (https://aws.amazon.com/compute/sla/).

Цель SLA – обеспечить вашу уверенность в том, что на сервис можно положиться. Представьте, что Amazon не оговаривает параметры оказания услуг или, что еще хуже, доступность сервисов у них составляет всего 50 %. Это означает, что их сервисы могут быть недоступны до двух недель каждый месяц без каких-либо компенсаций. Устраивает ли ваш бизнес такое качество обслуживания?

Документы SLA очень распространены для облачных сервисов и моделей X-as-a-Service (что-либо как услуга). SLA применяется ко всем сферам, в которых привлекаются сторонние сервисы, и определяет, на какую их доступность вы можете рассчитывать, что, в свою очередь, позволяет вам предоставлять своим клиентам информацию о возможностях вашего продукта.

SLA предусматривают разные уровни: чем больше девяток (0,999999) надежности вам нужно от службы, тем дороже она будет. Выбор оптимального варианта во многом зависит от ваших потребностей и может быть разным для разных областей. Некоторые части вашей экосистемы способны выдержать большее время простоя, чем другие.

SLA также определяет, сколько времени может пройти с момента сообщения об ошибке или проблеме до ее решения. Чем важнее сервис, тем выше требования SLA.

С другой стороны, если ваш продукт предоставляет API или работает по модели X-as-a-Service, вам необходимо сформулировать ваши параметры оказания услуг, которые вы должны будете соблюдать. Они оговаривают уровень сервиса, который вы планируете предоставлять своим пользователям, и компенсацию за его невыполнение.

Если вашим сервисом пользуются не сотрудники компании, а внешние клиенты, то размер компенсации устанавливается совместно с бизнесом. Ваша основная задача в этом случае – разработать параметры SLA, выполнимые в рамках разумного бюджета.

Первое, что нужно отметить: стопроцентный уровень доступности сервиса недостижим – слишком много факторов влияет на него. Вот что следует принять во внимание при определении вашего уровня доступности:

• Какой из сторонних сервисов, используемых вами, имеет самый низкий уровень SLA? (Вы сильны ровно настолько, насколько сильно ваше самое слабое звено.)

• Какова длительность простоя, необходимого вам для выпуска релизов или обновлений системы?

• Способны ли вы обеспечивать выполнение SLA 24 часа в сутки каждый день, или же только в рабочее время?

• Каковы сроки решения той или иной проблемы?

• Достаточно ли у вас сотрудников для обеспечения поддержки, с учетом отпусков?

• Каким был уровень доступности вашего продукта до сих пор?

• Какова самая слабая часть или единая точка отказа в вашем решении, которая может повлиять на его бесперебойную работу?

Никогда не берите цифры из воздуха. Они должны быть достижимы, и вы должны быть готовы обосновать и защитить их.

Зачем эти хлопоты? Ведь ваша команда знает, как все устроено, – это знание передается из поколения в поколение. Кроме того, ваш технологический стек так грамотно спроектирован и внедрен, что в нем разберется любой толковый специалист. Если вы так думаете, то, вероятно, еще и уверены, что ваш код не содержит ошибок и, следовательно, не требует тестирования! Звучит абсурдно, но многие действительно так считают.

Документация – это преемственность. Документация – это масштабируемость. Документация – это свобода. Это не признак слабости и не формалистская рутина, которую приходится терпеть и которую можно откладывать на самый последний момент.

Независимо от того, насколько современна ваша архитектура и читабелен ваш код, существуют правила и логика, применимые только к вашей организации. Нельзя понять, почему были приняты те или иные проектные решения, только читая код. Документация – это руководство по эксплуатации вашей системы, и без документации никто не сможет в полной мере воспользоваться всеми ее возможностями.

Люди забывают детали. По мере того как дни складываются в недели, недели – в месяцы, а месяцы – в годы, забывается причина, по которой что-то было сделано именно так, а не иначе. Нестандартное бизнес-правило или неочевидное ограничение, которое в свое время направило архитектуру/реализацию в ту или иную сторону (и в то время это решение было верным), в будущем может оказаться не столь понятным. С решениями, причины которых затерялись в прошлом, произойдет одно из двух:

• Новый сотрудник увидит его, подумает, что можно сделать все проще, переделает – и в итоге что-то сломается.

• Люди будут бояться трогать решение или тем более пытаться его переделать. Оно приобретет мифические свойства и будет считаться слишком сложным или важным, чтобы рисковать и вносить в него изменения.

Оба сценария несут большую опасность, и обоих можно полностью избежать, если оставить краткие пояснения. Как однажды заметил один мудрый разработчик: «Комментарии [в коде] – это любовные записки будущему самому себе».

Документация – это не единая универсальная вещь, подходящая сразу для всех читателей. Это набор документов, предназначенных для разных групп получателей, в зависимости от того, как они взаимодействуют с системой. Вот какими могут быть эти группы:

• Конечные пользователи. Пользователи системы, взаимодействующие с готовым продуктом.

• Техподдержка. Сотрудники службы поддержки, которые помогают конечным пользователям с их вопросами.

• IT/DevOps. Команда, отвечающая за поддержание системы в рабочем состоянии.

• Разработчики. Команда, которая создает и исправляет функционал.

Чем больше и старше система, тем больше у каждой группы будет особых требований. В небольших командах, которые только начинают развитие своего проекта, одни и те же люди могут выполнять широкий спектр обязанностей, совмещая несколько ролей, а документация для конечного пользователя может вообще отсутствовать.

По мере роста у каждой группы появятся собственные процессы и зона ответственности, и ей будут требоваться поддержка и документация от более низкого уровня, на который она опирается. Наличие надежного источника информации поможет новым членам каждой группы (от конечного пользователя до разработчика) быстрее и успешнее адаптироваться к своим ролям.

Составляйте документацию на языке, понятном каждой группе, чтобы информация была более доступной. Например, описание алгоритмов не будет иметь особого смысла для конечного пользователя или сотрудников службы поддержки, но поможет разработчикам развивать и дорабатывать ПО. Точно так же подробные описания интерфейса и последовательности скриншотов не помогут команде IT/DevOps, потому что им на самом деле все равно, как выглядит приложение. Им необходимо знать, как, например, делать резервное копирование. Обращайтесь к конкретной аудитории.

Чаще всего документацию оформляют в классическом текстовом формате: такие документы легко создавать, читать, хранить, они не занимают много места, их легко искать и на них можно делать ссылки. Однако в последнее время набирают популярность видеоролики, записи сеанса работы с каким-либо инструментом, как будто ты смотришь через плечо человека, который это делает. Доступные инструменты для создания и редактирования коротких видео позволяют быстро записать и переслать или опубликовать их – а 5-минутный ролик может заменить несколько страниц подробного текста.

Хорошая документация должна быть легко доступна при необходимости. Какой бы хорошей ни была вещь, она практически бесполезна, если ее нельзя найти в тот момент, когда она нужна.

Документация в файлах PDF или DOC была актуальна 20 лет назад, но не сейчас. Документ, особенно предназначенный для обучения или описывающий работу платформы, должен быть живым. Его необходимо обновлять с каждым релизом или при появлении новых данных. И такое обновление не должно превращаться в отдельную большую задачу, оно должно делаться быстро и без усилий.

Когда Тим Бернерс-Ли (Tim Berners-Lee) создавал интернет, его целью было обеспечить удобный обмен информацией. Таким образом, логично организовать хранение документов на основе технологий интернета. Такие инструменты, как вики, Atlassian Confluence, Google Docs и Office 365, отлично подходят для работы в браузере. При выборе платформы для документации учитывайте следующее:

• Прямые ссылки на контент. Убедитесь, что пользователь может попасть в нужный раздел по ссылке и не требуется совершать несколько шагов, чтобы найти его.

• Организация связанного контента. Инструмент должен позволять легко объединить связанные области, чтобы читателю было удобно искать дополнительную информацию. В идеале это должно делаться автоматически, с помощью тегов или семантического анализа текста.

• Простое обновление. По мере появления новой информации контент необходимо обновлять, особенно если он предназначен для службы поддержки.

• Хранение предыдущих версий документа. Большинство современных инструментов уже поддерживают эту функцию. Возможность вернуться к предыдущей версии позволит постоянно дорабатывать документы, а читатели смогут определить, к какой версии продукта относится тот или иной контент.

• Безопасность. Не все документы должны быть общедоступны, поэтому необходимо иметь возможность ограничить доступ к определенным областям или разделам для конкретных групп пользователей.

• Обратная связь. Читатели должны иметь возможность оставлять комментарии или примечания, чтобы дополнять текст.

• Вложения. Насколько удобно прикреплять дополнительные файлы (изображения, видео, PDF)? Такие данные лучше хранить вместе с документом, к которому они относятся.

Хороший контент не обязательно должен быть безупречно оформлен – главное, чтобы он помогал читателю. Поощряйте каждого вносить свой вклад в формирование базы знаний – это залог того, что она будет полезной. Чем проще будет написание и дополнение документов, тем лучше.

Мы все знаем о необходимости тестировать код перед релизом с помощью автоматизированных или чаще ручных тестов, проверяющих, что код делает именно то, что должен делать. Если вы хотите создать современную технологическую платформу, нельзя просто «надеяться», что все будет хорошо. То же самое касается и документов. Прежде чем документы начнут использоваться по назначению, необходимо проверить, насколько они полезны.

Все содержимое документов, особенно недавно написанных, кроме автора должен проверить еще кто-то, подтвердить нужность информации и убедиться, что документ не содержит слишком много пропусков или допущений с учетом его целевой аудитории и темы. Необязательно организовывать формальный процесс ревью – просто попросите еще кого-нибудь посмотреть текст.

Возьмем, к примеру, процесс релиза, включающий сборку, проверку и деплой вашей системы. Вместо того чтобы держать все в голове, разработчик этого процесса решил его описать. Как узнать, достаточно ли подробностей он зафиксировал? Нужно поручить кому-нибудь пройтись по документу (в идеале тому, кто не очень разбирается в предмете и не будет подсознательно заполнять пробелы в описании). Это лучший способ понять, решает ли документ свою задачу.

Особое внимание уделите описанию работы, которую обычно выполняет один человек, – все ли его действия зафиксированы верно, чтобы любой мог заменить этого сотрудника? Только проверив документацию, вы сможете с уверенностью ответить на этот вопрос.

В этом разделе мы рассмотрим, какие документы могут храниться в организации. Это не исчерпывающий список, а скорее ориентир, чтобы вы поняли, с чего начать.

Собрания не должны быть частыми и многолюдными, поскольку они сильно отвлекают от работы и занимают много времени. Если вы решили, что собрание необходимо, оно должно быть максимально продуктивным.

У хорошего собрания должен быть один или несколько вопросов для обсуждения (или план встречи) и понятная цель. Собрания могут быть отличным способом обмена информацией, идеями и предложениями. Тем не менее, если на них почти или совсем не ведутся записи, много ценной информации упускается – и это большая потеря.

Протоколы собраний, подробно описывающие историю принятия тех или иных решений, должны стать частью вашей базы знаний. Некоторые организации ведут отдельный «журнал решений», подробно описывающий, почему договорились что-то делать именно так.

На каждом собрании назначайте кого-то, кто будет вести заметки, и предусмотрите время для их обработки. Можно вести записи в Google Doc в режиме реального времени, фиксируя ключевые моменты и решения. Если это быстрое собрание, посвященное разбору конкретной задачи, зафиксируйте все договоренности в комментариях к тикету в виде списка.

В постпандемийном мире многие собрания перешли в онлайн и проходят в режиме видеоконференций. В таком формате удобно записывать и хранить все ключевые встречи, чтобы не пропустить важные решения.

Сообщения в чате (Slack, Microsoft Teams и т. д.) также могут содержать ценную информацию. Пусть члены команды копируют ее и добавляют или в основную базу знаний, или в тикеты. Можно даже настроить ботов или плагины, чтобы вы могли быстро пометить сообщения, которые нужно отправить в отдельное хранилище.

Вспомните, сколько раз вы проводили демонстрацию продукта или показывали какой-то функционал по шагам. Записывалось ли это? При этом каждый следующий показ будет содержать что-то новое – или новый вопрос от зрителей, или новую информацию.

Полезно посмотреть рекламные ролики вашего продукта – так можно увидеть, каким образом отдел продаж продвигает его, и узнать, как его функции воспринимает клиент/пользователь и чего они ожидают от продукта. Ваши представления об этом могут значительно отличаться от клиентских.

Эти материалы помогают управляющей развитием продукта команде понять, что нужно пользователям, инженерам – что в продукте наиболее важно, и, наконец, новым членам команды – в создании чего они участвуют.

Объем информации со временем будет расти; не бойтесь этого. У таких материалов есть замечательный побочный эффект: они служат машиной времени, позволяющей новичкам ознакомиться со старыми версиями продукта и понять, как он эволюционировал.

Вероятно, один из самых важных документов – это тот, который объясняет, как поддерживать систему в рабочем состоянии, если хотите – инструкция по использованию. Он не про деплой кода. Это описание всех частей платформы и того, что они делают, как контролировать их состояние и что делать, чтобы снова запустить их в случае отключения электроэнергии (или выключения по другой причине).

Уровень детализации здесь должен быть достаточным, чтобы любой мог понять и выполнить нужные действия. Недостаточно просто написать: «Обязательно перезапустите компонент XYZ». Как перезапустить XYZ, какие команды нужно вводить и куда, как определить, успешно ли все прошло, и что делать в случае проблем? Такие детали часто пропускаются и хранятся только в чьей-то голове.

Например, во время запуска системы в консоли может выводиться много разной информации. Человек, не привыкший читать все эти строки, будет сбит с толку, он не будет понимать, что из этого хорошо, что плохо, а что можно игнорировать. Но если включить в документацию простой скриншот вывода, всего этого непонимания можно избежать и быть уверенным, что все работает правильно. Как известно, лучше один раз увидеть, чем сто раз услышать.

Руководство не должно быть многословным. Вы же не пишете очередную книгу о Гарри Поттере. Вы описываете, какие действия и в каком порядке нужно выполнить. Придерживайтесь простой структуры: нумерованный список шагов, для каждого из которых читатель должен понять, что нужно сделать, успешно ли все выполнилось и можно ли переходить к следующему шагу.

Также необходимо описать, как контролировать состояние системы: по каким признакам можно определить потенциальные проблемы? Сначала это может казаться сложным. Небольшой совет: попросите сотрудника, отвечающего за ту или иную часть комплекса, представить, что он уходит в отпуск, и написать электронное письмо тому, кто будет его замещать. Такой формат более привычен, и людям проще написать подробное электронное письмо, чем новую страницу вики или документ в Google Docs. Возьмите это письмо и добавьте его в базу знаний. Так можно делать много раз, и в результате вы соберете обширную, подробную библиотеку практических руководств.

Никто в команде не должен чувствовать, что единственная причина, по которой он здесь работает, – это его знание той или иной системы. Подобное отношение часто встречалось 10–20 лет назад, но сегодня это редкость. Люди ценятся не за информацию, которой они владеют, а за их вклад в общее дело команды.

Все мы любим работать с новыми модными технологиями – мы же инженеры. В нашем ДНК заложен постоянный поиск чего-то нового и лучшего. Важно описать работу существующих систем на таком уровне, чтобы никому не приходилось возиться с ними только потому, что больше никто этого не умеет.

Часто в документации не уделяется необходимого внимания резервному копированию и восстановлению системы. Необходимо описать не только способ экспорта/импорта базы данных (хотя и это тоже). Речь об информационной системе в целом, от аппаратного обеспечения до операционных систем и ПО.

Что требуется, чтобы вернуть компонент к жизни? Какие части операционной системы нужны для запуска компонента? То, что кажется очевидным сегодня, может быть непонятно через месяцы или годы.

С ростом популярности контейнеров (таких, как Docker) зависимости на уровне операционной системы теперь обычно описываются как часть процесса сборки. Однако это не отменяет необходимости указать, что от чего зависит. Даже если все находится в контейнерах, необходимо описать, как контейнеры работают и взаимодействуют между собой, чтобы понять, как ими управлять. Должно быть достаточно информации, чтобы любой, кто разбирается в используемых технологиях, мог собрать компоненты системы из исходного кода. Если сейчас это невозможно, то у вас есть информационный долг. Разумеется, документы также необходимо обновлять с каждым релизом, по мере появления новых компонентов и замены или удаления старых.

Как я уже говорил, отрабатывать восстановление системы необходимо хотя бы раз в год, если не чаще. Если вы используете облачные сервисы, это можно делать без проблем, не мешая остальной работе и не подвергая риску продакшен. Полезно поручать новичкам выполнять сборку проекта с нуля. Это эффективный способ познакомить людей с процессом, показать взаимодействие компонентов и проверить актуальность документации.

Релизы и обновления систем предприятия должны быть отлажены, предсказуемы и безопасны. Чтобы этого добиться, необходимы соответствующие инструменты и документация. Даже если вы полагаетесь на автоматизированный инструмент оркестрации (такой, как Jenkins), для его настройки в вашей среде все равно требуется руководство.

Оно должно содержать все необходимые шаги для подготовки сборки, с объяснением происходящих процессов, а также описанием критериев успеха или сбоев. Кроме того, следует указать порядок выполнения шагов и на каких этапах изменения можно безопасно отменить. Если у вас есть дополнительные процессы выпуска патчей, фиксов или релизов, то их тоже необходимо подробно описать.

Разработка надлежащей документации поможет информировать сотрудников и гарантирует, что релизы не будут зависеть от одного человека. Бывает такое, что компания может выпускать обновления, только когда старший специалист DevOps не в отпуске.

Если вы хотите вовлечь разработчиков в спор, по накалу страстей не уступающий легендарной дискуссии о табуляции и пробелах (кстати: пробелы), спросите, сколько комментариев должно быть в коде. Ответы будут варьироваться от «Моему коду комментарии не нужны – он и так понятен» до «Да уж, без комментариев тут не разберешься».

Чаще всего, если исходный код недостаточно очевиден и требует дополнительных комментариев – возникают вопросы «что» и «как». Реже бывает непонятно назначение чего-то и приходится пояснять «зачем».

Такой уровень детализации предназначен для других разработчиков, использующих эту часть кода. Например, это может быть библиотека с публичными функциями или методами, которые будут использоваться разработчиками других систем. Сюда также относятся API, которые используются какими-либо сервисами.

Для большинства современных языков существуют соглашения или специальный синтаксис, которые позволяют создавать документацию к вашей библиотеке из комментариев к функциям. Таким образом разработчики, импортировавшие библиотеку в свой проект, могут увидеть справку к ее методам с помощью встроенных в IDE механизмов автодополнения кода.

Отличным примером является язык Java, в котором есть стандарт для написания документации для классов и методов, он называется Javadoc. Такая документация не только показывается при использовании автодополнения кода и других функций IDE, на ее основе также можно сгенерировать набор веб-страниц с описанием исходного кода. Другой пример – библиотека Swagger, которая предназначена для создания документации в формате HTML для различных API, и, кроме этого, содержит инструменты для выполнения запросов к API для его тестирования или изучения.

Большое преимущество подобной документации состоит в том, что она находится в том же файле, что и код, поэтому ее легко обновлять. Документация в исходном коде очень важна, особенно для больших команд или в тех случаях, когда ваше API используется внешними клиентами.

Этот тип документации тоже находится в функциях и методах исходного кода и предназначен только для тех, кто разрабатывает этот код. Он не должен быть чересчур подробным. Работа грамотно спроектированного и хорошо написанного кода должна быть очевидна. Для этого необходимо использовать осмысленные имена функций и переменных, соответствующие их назначению, – в первую очередь необходимо стремиться к читабельности, а не к оптимизации. Тем не менее, если какая-то часть требует дополнительных пояснений, стоит добавить к ней несколько строк комментариев.

Идеальным будет оставлять в комментариях ссылки на тикеты – это поможет следующему разработчику лучше понять, почему компонент делает именно это. Какой-нибудь неочевидный оператор if можно легко объяснить, добавив номер тикета, и тогда следующий разработчик не будет его рефакторить в уверенности, что помогает проекту, но на самом деле добавляя еще больше проблем.

Убедитесь, что при ревью кода проверяется и достаточность комментариев. Когда разработчики привыкнут это делать, они уже не смогут работать без документации.

Если для чего-то недостаточно описать «как», то нужно объяснить «зачем», то есть для чего предназначена та или иная функция или система, обычно на гораздо более высоком уровне бизнес-логики. Обусловлено ли это на первый взгляд понятное техническое решение каким-то требованием бизнеса или это особенность работы одного из партнеров?

Когда вам дарят коробку дорогих шоколадных конфет, на что вы смотрите в первую очередь? Конечно же, на схему, на которой указано, где лежат конфеты с разными начинками! Эта схема дает вам шанс избежать фундука, который прячется внутри. А истинные ценители шоколада используют ее для планирования своего гастрономического путешествия, ведь они хотят насладиться максимально насыщенным вкусом. Схемы и карты обеспечивают нас информацией, чтобы мы могли ориентироваться гораздо увереннее.

У вашей системы тоже должна быть такая «карта», или схема архитектуры. Когда вы знакомитесь с системой, всегда просите нарисовать ее схему на доске. Если в ответ вы получите недоуменные вопросительные взгляды, уточните: «Она состоит из прямоугольников и линий».

Это не должна быть сложная или формальная схема. Это не строительный чертеж, который должен соответствовать строгим стандартам. Это просто путеводитель, помогающий понять термины, в которых описывается платформа.

Здесь должны быть основные компоненты вашей системы, и если какие-то из них связаны между собой, то их нужно соединить на схеме линиями. Не вдавайтесь в подробности. На этом уровне достаточно знать, что File Microservice используется модулем обработки фотографий профиля пользователя. Сейчас не имеет значения, как он это делает – это может быть вызов API, очередь или просто общая папка. Такие подробности должны быть в других документах. Здесь же вы указываете – возвращаясь к аналогии с картой – только границы штатов, автомагистрали, показывающие, каким образом разные штаты связаны между собой, и самые крупные города.

Слишком много деталей тут не нужно, это перегружает карту и делает ее трудной для понимания. Для каждого компонента (или штата, если говорить о карте) создайте отдельную схему, более подробную (уже с указанием местных дорог и городков).

Аналогия с картой особенно хорошо подходит для архитектур, использующих микросервисы и API. Как и в штатах США, крупные города и автомагистрали остаются неизменными, но местные дороги в каждом штате и городе постоянно развиваются.

В продуманных схемах архитектуры отдельные части могут оставаться актуальными даже спустя годы развития проекта. Схема верхнего уровня должна показывать людям, не входящим в вашу команду, как все устроено, не загружая их излишними деталями или сложными терминами. Не удивляйтесь, если она появится в презентации для совета директоров, потому что хорошая схема – отличный способ продать свое ви́дение.

Со схемой архитектуры тесно связаны диаграммы процессов. Они дают представление о том, как данные перемещаются по системе и что с ними происходит, когда они попадают в тот или иной сервис или библиотеку. Если схема архитектуры – это карта автомагистралей внутри штата или между ними, то диаграмма процесса – это наложенная на нее схема трафика из Google карт, показывающая, где находятся автомобили.

Диаграмма процесса – это логическая схема, показывающая, где данные хранятся, кэшируются и передаются из одного компонента в другой. Опять же, если она будет чрезмерно подробной – схема станет слишком сложной и в ней можно будет увязнуть.

Цель таких диаграмм – наглядно показать движение данных и на общем уровне обозначить пути и способы их перемещения, а также то, как данные попадают в систему и покидают ее.

Схема сети похожа на схему архитектуры, но она создается с точки зрения структуры ваших сетей и серверов. Полезно указывать на ней сетевые адреса, маршруты, файерволы и шлюзы, которые соединяют части сети.

Если у вас есть физические серверы, на этой диаграмме нужно показать их местоположение (например, адрес ЦОД и координаты стоек в нем). Характеристики каждого элемента оборудования, в том числе даты покупки, гарантийный срок и настройки конфигурации, можно будет указать в отдельных документах.

Базы данных лежат в основе большинства информационных систем, именно они хранят бесценные данные и связи между ними, без которых деятельность компании невозможна. Тем не менее, несмотря на всю важность этой области, документации по ней чаще всего недостаточно, хотя так быть не должно.

Существует, однако, множество инструментов (например, DB Schema), которые могут проанализировать реляционную базу данных и сгенерировать ее схему, при этом на основании внешних ключей (foreign keys) будут определены связи между таблицами. Вы можете дополнить эту схему комментариями, поясняющими бизнес-логику, которая стоит за структурой данных. Также все современные СУБД поддерживают возможность добавления комментариев к таблицам и столбцам наподобие того, как это делается в исходном коде.

Другие хранилища данных могут не поддерживать встроенные комментарии, и, следовательно, для них приходится вручную создавать дополнительные документы. Контроль этого нужно добавить в релизный цикл, чтобы, если что-то изменится, документация была обновлена.

Если ваша документация, описывающая структуру и месторасположение всех данных, составлена так, что будущие сотрудники смогут легко ее найти и использовать, то вы можете быть спокойны.

Вы можете работать в отрасли, где требуется наличие определенной документации, например описание процессов, результаты аудитов и периодические отчеты. Типичный пример таких отраслей – здравоохранение и финансы. Некоторые правительственные и военные проекты также требуют определенного уровня описания процессов (например, соответствия стандарту ISO).

Подробности, касающиеся соответствия HIPAA, PCI, ISO и т. д., выходят за рамки этой книги. Если вашей компании требуется сертификация – привлеките стороннего эксперта, который поможет организовать этот процесс. В больших аудиторских компаниях, например, этим занимаются целые департаменты. Эта задача на первый взгляд кажется пугающей, но, если подойти к ней правильно, сложностей не будет.

Какими бы ни были нормативные требования – считайте, что за ними стоит здравое желание добиться, чтобы все стороны действовали прозрачно. Организациям, в которых отсутствуют документация, процессы и регламенты, здесь будет тяжелее всего. Все придется создавать с нуля, и это может быть трудной и долгой задачей. Компаниям с четкой документацией и стандартами намного проще. Да, в них тоже наверняка есть области, требующие доработки, и части, которые не помешает усилить, но все уже движется в правильном направлении.

Соответствие требованиям – это, конечно, больше, чем просто документация, и все, что вы описали, необходимо выполнять на практике. Это может потребовать доработки кода или архитектуры, так что смотрите на это как на возможность для оптимизации и приведения в порядок различных частей проекта.

Большинство нормативных требований уделяют много внимания вопросам безопасности и работы с данными. Если вы считаете, что ваша организация может попасть в сферу действия таких требований, то начинайте изучать их заранее, готовиться и внедрять в команде соответствующие практики. Считайте, что это знак вашей исключительности. Именно вы отвечаете за защиту систем и данных вашей организации. Поэтому прислушивайтесь к любым полезным рекомендациям.

Вопрос, о котором обычно не думают, но рано или поздно он возникает, – как найти все ваши лицензии и купленное ПО. Заведите в базе знаний документ для учета всего используемого вами стороннего ПО, как купленного, так и с открытым исходным кодом. Сообщите команде, что важно вносить туда все, даже то, что кажется незначительным. Каждый раз, когда разработчик Java добавляет новую библиотеку в конфигурацию Maven или разработчик JavaScript подключает новый модуль npm, обновляйте этот документ, включая информацию об источнике ПО и условиях лицензии.

Проверка списка используемого ПО – это обязательная часть аудита due diligence, но на момент написания этой книги я еще не встречал команду, в которой эта информация была бы под рукой. Этот список необходим и в других случаях, например для продления и обновления лицензий, а также для того, чтобы понять, можно ли перенести ваше ПО в облачные сервисы, если вы захотите это сделать.

Для начала необходимо составить список всего ПО (включая библиотеки), которое используется в компании, с информацией о версиях. Этот список понадобится во многих случаях, его важность и работу и ним мы обсуждали в главе о документации. Если не следить за актуальностью этого списка, можно легко пропустить критическое обновление: вы не обратите на него внимания, думая, что оно к вам не относится.

Наличие обновлений необходимо в первую очередь проверять на сайтах разработчиков. У всех крупных поставщиков ПО есть сайты или рассылки, за которыми вы можете следить. Проекты с открытым исходным кодом публикуют описание для каждого из релизов, также у них есть форумы, на которые вы можете подписаться. Лучшим источником информации об уязвимостях является широко известный реестр CVE.

Настройте автоматическое получение обновлений, чтобы их наличие не приходилось постоянно проверять. Будьте внимательны: периодически проверяйте, что ваша подписка работает. Параметры рассылок и уведомлений со временем могут меняться.

Хотя это обязанность вашего специалиста по информационной безопасности (Chief Information Security Officer, CISO), поощряйте других членов команды тоже следить за уязвимостями. Сигнальный огонь Гондора (во «Властелине колец») мог увидеть всего один человек, этого уже достаточно, чтобы забить тревогу.

Узнать, какие обновления нужно установить, – это обычно легкая часть. Теперь нужно решить, когда это делать. Есть соблазн проигнорировать какие-то обновления как не относящиеся к вам. Это большая ошибка. Возьмите за правило устанавливать обновления, даже мелкие, часто, по крайней мере ежемесячно: это может повлиять на текущую работу, но защитит вас в долгосрочной перспективе. В идеале у вас должна быть возможность выполнять сине-зеленый деплой (см. главу 9), чтобы упростить тестирование исправлений/обновлений перед внедрением.

Обновления, особенно из проверенных источников, в 99 % случаев будут работать без сбоев. Но, каким бы высоким ни был этот показатель, не рассчитывайте на полное отсутствие проблем. Тестируйте, тестируйте и еще раз тестируйте. Используйте для проверки исправлений серверы для разработки или стейдж или, по крайней мере, выкладывайте обновления вместе с релизами вашего ПО. Так ваши тестировщики смогут обнаружить любые отклонения в поведении.

Если у вас нет возможностей для тестирования в изолированном окружении, то придется иметь дело сразу с боевыми патронами – обновлять продакшен. Это относится в том числе к системам бэк-офиса (таким, как серверы электронной почты и файловые серверы). В таких ситуациях всегда лучше проводить обновления в нерабочее время – лучше всего в субботу, чтобы, если что-то пойдет не так, у вас оставался день в запасе (воскресенье) для решения проблемы.

Такое оборудование, как принтеры, сканеры и телевизоры, обычно не относится к компетенции технического директора, однако для него тоже нужно постоянно проверять наличие обновлений безопасности. Современные продукты (например, Google Chromecast/Nest) регулярно обновляются автоматически. Однако не все производители настолько прилежны. Сетевые маршрутизаторы и коммутаторы здесь требуют особого внимания, и способ получения информации об обновлениях для них не всегда очевиден.

Для некоторых устройств приходится вручную заходить в консоль управления и проверять наличие обновлений. Этим действием нельзя пренебрегать, и оно должно входить в обязанности сотрудников, ответственных за ИТ. Заведите привычку регистрировать такие проверки в общем журнале или отдельных журналах для каждого устройства. Любое устройство, подключенное к интернету, необходимо рассматривать как часть продакшена и уделять должное внимание его безопасности и управлению паролями, даже если оно не вызывает никакого беспокойства. Любое устройство в сети может быть атаковано. Если у устройства есть IP-адрес – оно является потенциальной угрозой.

Скорее всего, вы фиксируете все события (почему бы и нет?), и это бесценная информация для отладки и анализа производительности. Хорошо. Но, подождите, а что конкретно ваши разработчики сохраняют?

Если вы записываете запросы к API и ответы – что, опять же, обычная практика – то что происходит при этом с конфиденциальными данными, которые в них передаются? Вы уделяете большое внимание тому, чтобы, например, номера паспортов или водительских удостоверений хранились только в зашифрованном виде, но при этом они будут попадать в логи в открытом виде, потому что передаются в API.

Журналы событий могут быть настоящей сокровищницей, и обычно они не так хорошо защищены, как базы данных. Тщательно следите за тем, что у вас регистрируется, и используйте средства маскировки конфиденциальных данных перед их сохранением в журналах. Не стоит использовать безопасность как оправдание тому, чтобы вообще не хранить логи, – просто следите за тем, что в них попадает.

У вас бывало такое, что вы заходите на сайт и вместо нужной страницы видите страницу ошибки, иногда содержащую большое количество диагностической информации для разработчика? Однако вы не разработчик; вы просто пользователь со стороны.

Такая «полезная» страница может содержать много конфиденциальных данных, касающихся подключения к БД и информации о системе. Потенциальные взломщики могут специально вызывать ошибку на сайте, чтобы получить подсказки.

Раньше сайты, работающие на JSP, CFML или PHP, выводили на страницах ошибок полную последовательность вызовов функций (stack trace), значения переменных и параметры сервера. Эта информация не предназначалась для продакшена, но где-то по пути кода из разработки и тестирования ее вывод порой забывали выключить. Хотя такое бывает нечасто, сообщения об ошибках, если за ними не следить, могут привести к утечке большого количества информации.

Ваша система может позволять пользователям экспортировать данные или выполнять произвольные запросы / получать аналитику через интерфейс или даже через API. Не получает ли пользователь при этом доступ к слишком большому количеству данных?

Часто инструменты бизнес-аналитики или отчетности становятся источником утечки, если данные не изолируются в достаточной степени. То, что видно на экране, может быть лишь частью того, что фактически передается, и в консоли разработчика в браузере можно быстро найти гораздо больше данных (и, возможно, более ценных).

Исходный код – это сердце многих компаний, но он может служить и источником утечек. Указанные в нем учетные данные (такие как имена пользователей и пароли для разных сервисов) могут оказаться в самых непредсказуемых местах, например, попасть в инструменты проверки качества кода, которые исследуют его и копируют куда-либо для анализа или более эффективной работы. Некоторые инструменты управления версиями, как коммерческие, так и с открытым исходным кодом (например, GitHub), выполняют базовую проверку на наличие чувствительной информации и отправляют оповещения с описанием того, что они нашли.

Пароли по-прежнему являются основным способом аутентификации для большинства систем, с которыми мы работаем. Сама по себе эта технология неплоха. Cлабые места, которым она обязана своей плохой репутацией, – это генерация паролей и работа с ними. Если пароль никогда не меняется и указан прямо в исходном коде, то он никак не участвует в обеспечении безопасности – это просто дополнительный атрибут конфигурации.

Правильная организация работы с паролями должна быть такой, при которой сами пароли имеют достаточную длину и сложность (необходимый набор букв и символов), а их изменение происходит легко и без последствий. Пароли, которые нужно указывать в исходном коде или отдельных файлах, будут создавать проблемы. Если пароль находится в файле, то его может прочесть любой, у кого есть доступ к соответствующей файловой системе.

Нередко, особенно в различных старых системах, учетные данные для подключения к базе данных хранятся в файле XML, после изменения которого требуется перезапуск сервера. Это является проблемой для многих серверов приложений. В такой ситуации смена пароля становится кошмаром, поскольку приходится изменять файлы и планировать перезапуск серверов и проверку их работы. Неудивительно, что пароли меняют редко.

Работа с паролями должна быть гибкой, чтобы их можно было менять или перегенерировать настолько часто, насколько это требуется. Программное обеспечение, требующее пароль, должно поддерживать его получение из менеджера паролей. Провайдеры облачных сервисов предоставляют такую услугу, и она является основой для надежного облачного приложения (учетные данные как к локальным, так и к сторонним сервисам не смогут быть получены, пока вы не подключитесь к менеджеру паролей).

Скорее всего, вы будете жить в гибридном мире и работать вручную с паролями, хранящимися в обычных файлах (даже если этот файл создается безопасно с помощью скрипта). Определите все места, где требуется комбинация имени пользователя и пароля, и для каждого из них опишите процедуру изменения пароля – что нужно менять и перезапускать.

Для этой цели подойдет простая электронная таблица, хранящаяся вместе с другими результатами инвентаризации ваших систем, в которой будут перечислены все компоненты, требующие учетных данных, как в примере ниже.

Меняйте пароли в следующих случаях:

• Сотрудник покидает организацию.

• Возникло подозрение в нарушении безопасности.

• Программное обеспечение было обновлено.

• Периодически (например, раз в месяц).

Поддержание дисциплины в команде и внедрение практики регулярной смены паролей поможет избавиться от связанных с этим страхов и сомнений. Общий совет: если меняете пароли, то меняйте их все. Если вы подозреваете, что скомпрометированы одна или два учетные записи, считайте, что в зоне риска находятся все. Не поддавайтесь искушению ограничиться точечными изменениями.

Безопасность – это не еще одна функция, которую можно добавить к проекту или купить. Это философия и набор принципов, по которым вы живете и работаете, и то, за чем вы постоянно следите. Создание безопасной инфраструктуры сосредоточено вокруг трех основных задач: инвентаризации, защиты и контроля.

Прежде чем возводить эффективный «забор», необходимо определить области, нуждающиеся в защите. Это называется «определить поверхность атаки» – найти все потенциальные пути взлома или утечки. Как технический директор, вы обязаны максимально сокращать поверхность атаки, а там, где это невозможно, обеспечивать всю возможную защиту. Вот примеры направлений атаки на вашу организацию, а также способы их локализации:

• Серверы продакшена находятся в той же сети, что и серверы для разработки. Слишком многие имеют к ним доступ. Уменьшите поверхность атаки, поместив продакшен в изолированную сеть.

• Все используют одну и ту же учетную запись для доступа к БД, поэтому нельзя понять, кто выполнил то или иное действие, или запретить доступ отдельному пользователю. Уменьшите поверхность атаки, создав отдельные учетные записи только для тех, кому этот доступ действительно нужен.

Это все реальные ситуации, и исправление их не требует запредельных усилий, а увеличение безопасности в результате будет очень существенным. Поверхность атаки недостаточно определить один раз. Она меняется с выпуском каждого нового релиза или добавлением нового сервиса, и вы должны будете заново оценить, достаточны ли ваши средства защиты.

Определив все области, потенциально подверженные риску, переходите к следующему шагу – защите. Это самая сложная часть процесса. Каждый уровень защиты требует финансовых затрат и несет потенциальные неудобства для пользователей. Рассмотрим следующие сценарии доступа к базе данных (или к любой другой системе, требующей аутентификации):

• Имя пользователя и пароль не требуются.

• Все используют одни и те же имя пользователя и пароль.

• У каждого пользователя свои имя пользователя и пароль.

• Для доступа к базе данных требуется подключить VPN.

• Используются MFA (многофакторная аутентификация) и VPN, а также индивидуальные имя пользователя и пароль.

Каждый следующий уровень обходится дороже предыдущего как за счет трудозатрат на его организацию, так и за счет стоимости дополнительного функционала и лицензий. Кроме этого, каждый уровень добавляет неудобств пользователю, которому приходится совершать все больше действий.

Такова плата за обеспечение безопасности. К примеру, самая защищенная база данных – та, которая не подключена к сети и к которой никто не имеет доступа. Но каким бы привлекательным этот вариант ни казался с точки зрения безопасности, для целей бизнеса он не подходит. Данные должны быть доступны, чтобы приносить пользу и обеспечивать работу бизнеса. Баланс между безопасностью и доступностью у каждой системы будет своим, и его поиски требуют изучения и обсуждения с ответственными за бизнес, чтобы все понимали и поддерживали связанные с этим процессы и политики.

Существует много способов достичь цели, особенно в вопросах безопасности. Защита обеспечивается на нескольких уровнях, и ошибочно считать, что всего один уровень может гарантировать безопасность.

Создайте несколько уровней защиты, каждый из них для своей области. Эту модель часто называют моделью швейцарского сыра. Ее большое преимущество в том, что такая защита не зависит от каждого отдельного механизма. Например, файервол может блокировать всё, за исключением нескольких портов, через которые пользователи попадают только в одну подсеть, и дальнейший доступ требует дополнительной аутентификации. Такое сочетание аппаратной и программной защиты может быть очень эффективным.

Заметки с полей

F5 Big-IP, весна 2022

По моему опыту, безопасность – это не что-то, что можно отдать на аутсорсинг и забыть. Например, логичным шагом выглядит покупка серьезных средств защиты, таких как F5 BIG-IP (можно сказать, что это IBM в сфере безопасности). Тем не менее даже компания, которая сосредоточена исключительно на обеспечении безопасности, со всеми ее многоуровневыми проверками, выпустила продукт, который позволял выполнять произвольные команды от имени пользователя root путем отправки простого запроса HTTP POST. Уязвимость CVE-2022-1388 имеет рейтинг 9,8 из 10 и является одним из самых серьезных нарушений безопасности в современной истории. Безопасность – это всегда сложно, поэтому никогда не полагайтесь на один инструмент и используйте несколько решений, которые дополняют друг друга, чтобы обеспечить наилучшую возможную в данный момент защиту.

Полагаться на один уровень защиты – значит складывать все яйца в одну корзину в надежде, что она никогда не упадет и яйца не разобьются!

После инвентаризации и защиты следующий и последний этап – постоянный мониторинг уязвимостей и атак на случай, если кому-то удастся обойти защиту. Здесь у нас две цели: во-первых, убедиться, что средства защиты работают. Нет ничего хуже, чем обнаружить, что после перезагрузки программный файервол не заработал. Во-вторых, определить потенциальные слабые места, которые можно улучшить. Злоумышленники постоянно совершенствуют свои методы, и ваша цель – чтобы ваша команда и технологии были хотя бы на один шаг впереди них.

Основной источник данных для мониторинга – журналы событий каждого из уровней защиты. Работа с ними сопряжена с определенными сложностями. Каждый из уровней и каждая система защиты имеют собственную консоль управления и свой журнал событий. Вручную заходить в каждую систему для проверки совершенно неудобно, и люди со временем устают и становятся невнимательными.

Нужно объединить все журналы в единый агрегат для комплексного мониторинга. Это позволит увидеть на первый взгляд несвязанные части скоординированной атаки.

Сложность этой панели инструментов во многом зависит от вашего бюджета и от ценности того, что защищается. Например, можно начать с таких инструментов, как Elasticsearch или Splunk, это популярные агрегаторы журналов. Некоторые продвинутые инструменты, использующие искусственный интеллект, могут постоянно анализировать данные.

Каким бы путем вы ни пошли – а это в любом случае будет движение вперед – убедитесь, что вы приучаете команду к постоянной бдительности. Не думайте, что если вы уже внедрили какие-либо средства защиты, то этого достаточно. Обеспечение безопасности – постоянная и важнейшая часть обязанностей команды.

Стоит отметить, что эти агрегаты также можно использовать для проведения проверок. Регистрацией входов в систему (как успешных, так неудачных) часто пренебрегают. Добавление этой информации поможет отслеживать необычную активность, например использование учетной записи сотрудника ночью или попытку доступа к недавно удаленной учетной записи. Уровень детализации будет зависеть от вашей организации и от данных, за которые вы отвечаете.

Компаниям, занимающимся разработкой и внедрением ПО, особенно важно обеспечить безопасность:

• исходного кода, который они разрабатывают;

• процесса сборки и внедрения ПО.

Разрабатывать безопасный код сложно. Если бы это было легко, нам не приходилось бы постоянно исправлять и обновлять программное обеспечение. Уязвимости появляются в исходном коде по двум основным причинам:

• Низкое качество кода или наличие ошибок, которыми могут воспользоваться злоумышленники.

• Высокая сложность функционала создает возможности для его незапланированного использования.

В зависимости от языка программирования низкое качество кода влияет на продукт по-разному. В языках, которые требуют от разработчика ручного управления памятью, риск атак с использованием переполнения буфера выше, чем в языках с автоматическим управлением памятью. Другой пример – печально известные «SQL-инъекции», когда один оператор SQL может быть преобразован в несколько операторов путем подстановки в него специально подобранного значения.

Рассмотрим сайт, на котором есть функция поиска и пользователь может ввести произвольный поисковый запрос. Код, выполняющий соответствующий запрос к базе данных, может выглядеть следующим образом:

Выглядит безобидно, не правда ли? Однако, если посмотреть внимательнее, видно, что разработчик создал огромную дыру в безопасности, которая позволяет взломать или удалить всю базу данных. Каким же образом?

Что, если в поле ввода на сайте вместо слова noah ввести "2'; TRUNC X; " и отправить этот запрос в API? В результате будет собрана строка, содержащая две отдельных команды SQL, которые будут выполняться одна за другой (при условии, что библиотека для работы СУБД разрешает это, а в большинстве случаев она разрешает). Первая команда SQL выберет записи, в которых поле «имя» имеет значение 2; это не вызовет никаких проблем. Однако вторая команда, "TRUNC X", удалит все строки таблицы X. После некоторого количества проб и ошибок злоумышленник может устроить хаос в вашей базе данных.

Подумайте только: взломщику даже не нужен какой-либо доступ к сети или к базе данных – он всего лишь использует средства, предоставленные ему самой компанией и включающие удобный интерфейс для выполнения его хакерских SQL запросов.

На заре существования веб-сайтов такие атаки были обычным делом, и многие из них оставались незамеченными. И хотя подобные уязвимости теперь встречаются нечасто, разработчики все еще пишут неграмотный код, особенно те из них, кто недостаточно обучен принципам безопасной разработки и тому, что все данные, поступающие снаружи, необходимо проверять. И это только один пример. Разработка безопасного и безошибочного кода – отдельная дисциплина, и ей посвящено множество книг.

Вы можете снизить риски, обучая свою команду программистов, внедряя стандарты разработки и проводя внимательное ревью кода. Инструменты контроля качества кода (такие как SonarQube) могут выявлять некоторые типовые проблемы и постоянно совершенствуются, но никогда не заменят взгляд опытного человека.

Подобные побочные эффекты возможны в любой системе, которая допускает расширение с помощью сторонних плагинов. Яркий пример – веб-браузеры, в которых плагины или дополнения обеспечивают более широкие возможности для пользователей. Однако это означает постоянное перетягивание каната между возможностями и безопасностью, потому что каждое изменение системы плагинов создает новые возможности для обхода ограничений.

Есть еще одна область, в которой нарушения безопасности могут принести такой же ущерб, как и взлом продакшена: это средства работы с исходным кодом и сборки ПО. При этом защищена она обычно хуже, что понятно: разработчики здесь вносят изменения и экспериментируют с кодом, а безопасность, при всей ее важности, может этому мешать.

Тем не менее у многих команд отсутствуют средства защиты, отделяющие среду для разработки и сборки от продакшена. Предпринимаются ли при этом какие-то меры, чтобы в код незаметно не оказалась добавлена вредоносная библиотека или фрагмент кода?

Если пайплайн сборки не защищен, кто-нибудь может внести в него небольшие изменения. Точно так же, если доступ к вашей системе контроля версий не ограничен надлежащим образом или вы используете небезопасный менеджер зависимостей (например, Maven или npm, где не фиксируется конкретная версия библиотек), то вы рискуете задеплоить код, не зная, что на самом деле у него внутри.

Так произошла печально известная атака на ПО SolarWinds, которая оказала огромное влияние на все отрасли, поскольку это программное обеспечение использовалось в крупных организациях как часть системы управления ИТ-инфраструктурой. Хакеры нашли идеального троянского коня: им не пришлось взламывать каждую цель, хватило одного сервиса, которым пользовались все. Затем вредоносный код распространялся как часть обычных обновлений ПО, проникая глубоко во внутренние сети и не вызывая срабатывания средств защиты.

Безопасный подход здесь – считать, что любая часть вашей системы является потенциальной мишенью, и создать как можно больше средств защиты, включая вынесение процесса сборки в отдельное окружение, фиксацию конкретных версий для всех сторонних библиотек (и их обновление только после проверки и подтверждения) и повышенное внимание к внезапным изменениям размеров файлов, которые не связаны с большими изменениями в коде (например, если собранное приложение стало занимать в два раза больше места, чем обычно, должен срабатывать алерт мониторинга).

Один из самых кошмарных моментов в жизни технического директора – когда вы узнаете, что вас атакуют. Еще один, ничуть не лучше, – когда вас атакуют, но вы об этом не знаете. Будем надеяться, что такое будет происходить как можно реже, потому что вы предприняли все необходимое для мониторинга угроз в режиме реального времени. Атаки могут быть следующего вида:

• Атака с целью вызвать отказ вашей системы.

• Скачивание данных.

• Удаление или шифрование данных.

• Несанкционированный вход в систему.

Эти ситуации могут быть чрезвычайно стрессовыми, главное тут не паниковать. Окружающие будут ждать от вас разумного и надежного плана действий. Первым делом необходимо определить область атаки и то, как ограничить дальнейший урон. Но это легко только на бумаге.

Коммуникация важна. Если ваше руководство будет знать, что происходит, это обеспечит вам их поддержку и пространство для маневра. Может показаться, что такая коммуникация будет отвлекать, но, как говорилось выше, периодические новости-об-отсутствии-новостей будут держать всех в курсе, а ваша команда сможет сосредоточиться на проблеме.

После изоляции проблемы перенесите фокус на определение нанесенного ущерба, чтобы затем выяснить, как ликвидировать последствия и предотвратить повторное появление подобных проблем. Ущерб может заключаться как в неправомерном использовании ваших ресурсов (например, если был вызван отказ в обслуживании), так и в скачивании или уничтожении данных либо в их шифровании в целях вымогательства. Необходимо не только определить, что конкретно произошло, но и убедиться, что злоумышленники не смогут продолжить или возобновить атаку после того, как вы с ней справились.

Если ваша команда не имеет соответствующих навыков, то никто не упрекнет вас, если вы привлечете специализированного поставщика услуг безопасности. Его экспертиза позволит не только решить проблему до конца, но и гарантировать, что она не повторится.

Только когда вы определите, каким образом взломщики получили доступ, и устраните слабые места, вы можете быть уверены в том, что после восстановления все не начнется сначала. Иначе вы будете играть в «ударь крота» («whack-a-mole»), думая, что решили проблему, но, как только вы отвлечетесь, она повторится.

Проверка вашей системы потребует усилий, времени и знаний, и вы никогда не будете до конца уверены, что вычистили все следы атаки. Если вы оказались в такой ситуации, я настоятельно рекомендую привлечь стороннего подрядчика. Хотя современные подходы к архитектуре с их большим количеством взаимосвязей создают дополнительные риски для безопасности, они также упрощают восстановление системы, особенно если вы используете контейнеры и виртуальную инфраструктуру, – просто уничтожьте контейнеры и создайте их с нуля (при условии, что в ваш процесс сборки не проникла библиотека злоумышленников).

Еще одна область, с которой вам, возможно, придется столкнуться, – это последствия нарушения безопасности или кражи данных. В этой ситуации вы должны определить, что было украдено. В отличие от физических активов – похищение которых очевидно, потому что они будут отсутствовать, – цифровые активы можно скопировать, не оставив следов. Будем надеяться, что вы записываете достаточно событий, чтобы следы остались в журналах; иначе как бы вы вообще узнали о краже? В таких случаях часто проводят компьютерно-техническую экспертизу.

Самое безопасное здесь – считать, что злоумышленники забрали все, что было им доступно. После того как вы составили список украденного, определите следующее:

• Кого необходимо уведомить?

• Что сделать, чтобы снизить ущерб от похищения или ценность данных?

• Какие меры безопасности предпринять, чтобы предотвратить дальнейшие кражи?

• Влечет ли кража юридические последствия?

Мой совет – не пытайтесь сделать все самостоятельно. Подключите руководство компании, проконсультируйтесь с юристом и воспользуйтесь услугами сторонних специалистов.

Мы все получали электронные письма в духе «беспокоиться не стоит, но…» от генеральных или технических директоров после утечек данных в крупных фирмах. Их рассылают тем, чья учетная запись или данные по результатам расследования могли быть скомпрометированы. Таким образом они, как ответственные за ваши данные, предупреждают вас, чтобы вы были начеку на случай чего-то подозрительного.

Очевидные шаги, которые можно предпринять, включают в себя принудительный сброс всех паролей или требование заново аутентифицироваться для учетной записи, требующей кода подтверждения из электронной почты или SMS. Какими бы простыми эти действия ни казались, они уменьшают ценность украденных учетных данных. Однако с определенными данными, такими как имя, адрес или номер паспорта, вы мало что можете сделать, поэтому их кража может повлечь серьезные последствия. Вы серьезно подвели ваших клиентов, доверивших вам свои ценные данные.

В зависимости от украденных данных вам, возможно, придется публично сообщить об утечке. Как правило, это касается любых финансовых или медицинских данных, но, прежде чем что-либо делать, проконсультируйтесь с вашими юристами.

Чтобы разобраться во всех подробностях атаки или взлома, требуется время. Вы неизбежно обнаружите, что слабое место было именно там, где события не регистрируются или регистрируются недостаточно подробно. Ничего необычного в этом нет, и добавить дополнительное логирование не составит труда.

Проведите тщательное расследование и представьте его результаты так, чтобы они были понятны нетехническим специалистам. Рассмотрим простую структуру отчета об инциденте из четырех частей: инцидент, выявление, влияние, устранение (IIIR – issue, identify, impact, remedy):

• Инцидент – что произошло и как это произошло.

• Выявление – как вы узнали о проблеме.

• Влияние – последствия инцидента.

• Устранение – действия для прекращения инцидента и устранения последствий.

Отчет IIIR может выглядеть, например, следующим образом:

• Проблема. Через форму на сайте, используемую для изменения адреса пользователя, любой зарегистрированный пользователь мог увидеть адрес любого другого пользователя, просто изменяя через консоль разработчика в браузере значение ID при выполнении запроса к API.

• Выявление. Команда системных администраторов обратила внимание на увеличение количества запросов к API, в итоге они выявили подозрительные запросы к API работы с адресом, выполняемые с одного и того же IP.

• Влияние. С одного IP-адреса, предположительно принадлежащего одному пользователю, была получена информация о примерно 1000 адресов пользователей, прежде чем системные администраторы заблокировали доступ для него. Конкретного пользователя идентифицировать невозможно, потому что в журнале аутентификации пользователей не сохраняется информация о их IP-адресе.

• Устранение. API было доработано, теперь оно возвращает только адрес текущего пользователя, доработка выложена на продакшен. Все остальные API проверяются на наличие аналогичных проблем и дорабатываются. При регистрации событий сеанса пользователя теперь сохраняется IP-адрес. Составлен список всех учетных записей, чьи адреса были просмотрены.

В зависимости от инцидента IIIR могут быть достаточно большими. Эти документы предназначены только для внутреннего пользования и должны содержать достаточно подробностей, чтобы на них можно было опираться, если будет принято решение о публикации информации об инциденте. В них излагаются факты, а не план действий (который находится в зоне ответственности всего руководства компании).

Договоры на поддержку со временем приобрели плохую репутацию и считаются слишком дорогими, когда за поддержку вам приходится платить больше, чем за саму лицензию на продукт. В частности, этим славились некоторые из известных поставщиков СУБД.

Смотрите на эти контракты как на страховые полисы: если что-то пойдет не так, они помогут вам восстановить работоспособность. Тем не менее, как и страховые полисы, не все договоры на поддержку одинаковы, и вы можете не получить тот объем помощи или поддержки, который вам действительно нужен. Поэтому, прежде чем подписывать долгосрочный контракт, убедитесь, что он предусматривает все, что нужно для вашей системы. Поддержка может включать следующее:

• Постоянные обновления функционала или безопасности.

• Гарантированное время ответа (не решения проблемы, а лишь подтверждения, что ваш запрос получен).

• Регулярное резервное копирование (если оборудование подключено к интернету).

• Восстановление при отказе и резервирование.

• Замена деталей/компонентов при их выходе из строя.

В зависимости от опыта и возможностей вашей организации вам может требоваться меньший объем поддержки, чем другим. Чтобы определить, нужна ли вам поддержка (и если нужна, то какая), необходимо провести анализ рисков для каждого из компонентов и ответить на следующие вопросы:

• Если компонент выйдет из строя, повлияет ли это на предоставление услуг конечным пользователям?

• Какой объем знаний имеется внутри компании для решения проблемы и насколько хорошо обучена команда?

• Как часто возникают проблемы?

• Единственная ли это точка отказа?

Иногда наличие или отсутствие платной поддержки влияет только на приоритеты. Например, если будут проблемы с подключением вашего здания к интернету, провайдер рано или поздно их решит, но, скорее всего, в первую очередь он займется клиентами, у которых есть договор на поддержку, и лишь затем всеми остальными.

Все это актуально и для ПО. Поставщики облачных сервисов предлагают базовый уровень поддержки бесплатно, но при этом восстановление системы или ответ на ваш запрос может потребовать несколько дней, а не часы, как для тех клиентов, у которых есть платная поддержка. Такой договор – это спасательный круг; номер, который вы набираете, когда все другие возможности исчерпаны. Обязательно покупайте поддержку для старых систем, которые еще не модернизированы или не заменены, чтобы подстраховаться до тех пор, пока вы сможете что-то сделать с ними.

Также можно заключить договоры на поддержку для ключевых библиотек или ПО с открытым исходным кодом. Многие крупные проекты (Mongo, Postgres, MySQL, Elasticsearch) имеют «коммерческие» версии, которые можно приобрести, но по сути это просто договор на поддержку для того же самого продукта. Бывают недорогие коммерческие версии, где каждый релиз задерживается на некоторое время и обновление происходит только тогда, когда выйдет несколько следующих версий основного продукта. Таким образом, вы не будете сталкиваться с детскими болезнями, которые случаются в свежих релизах (иногда к этому добавляется некоторый дополнительный функционал). Кроме того, такие версии предусматривают оповещение об обновлениях безопасности, чтобы вашей команде не приходилось следить за их появлением на сайтах.

Договоры на поддержку оборудования могут сильно различаться по стоимости и уровню обслуживания. В случае дорогого контракта оборудование будет контролироваться удаленно, при этом инженеры будут самостоятельно заменять детали еще до того, как вы заметите, что они вышли из строя. Такие договоры типичны для больших SAN (storage area network, сетей хранения данных), поскольку срок службы жестких дисков ограничен. В случае более дешевой поддержки о проблеме надо будет сообщать по телефону или электронной почте, и подрядчик вышлет вам комплектующие для самостоятельной установки. За что вы заплатите, то и получите. Не всем нужен полный набор дорогих услуг, но решать тут вам.

Говоря о поддержке, стоит рассмотреть и другую сторону медали: какую поддержку вы оказываете своим клиентам, когда они сталкиваются с проблемами в работе сервисов, которые вы им предоставляете? В крупных организациях первая линия поддержки обычно подчиняется операционному директору (COO) или ИТ-директору (CIO). Сотрудники этой линии поддержки напрямую взаимодействуют с конечным пользователем и пытаются диагностировать и устранить неполадку. Если им нужна помощь, они передают информацию в технический отдел. Таким образом, хотя вы напрямую и не участвуете в поддержке конечных пользователей, вам все равно необходимо разработать процессы для предоставления своевременного ответа команде поддержки. Для этого обычно предусматривают SLA (соглашение о параметрах оказываемых услуг), где фиксируются параметры, на которые может рассчитывать конечный пользователь (см. главу 10). Обычно в SLA входит следующее:

• Доступность сервиса за определенный период; например, доступность 99,9 % за год означает, что время простоя за этот период не должно быть более 8,7 часа.

• Сроки подтверждения запроса как в рабочее, так и в нерабочее время.

• Возможность удаленного мониторинга.

• Применение обновлений, включая исправления ошибок и обновления безопасности.

• Максимальное время, которое может быть затрачено на обработку отдельного запроса или всех запросов клиента.

• Возможность дополнительных работ и исправления проблем, возникших не по вине поставщика, за отдельную плату.

Это соглашение вы составляете не в одиночку, а совместно с отделом продаж, менеджером по продукту, генеральным и финансовым директором. Его содержимое будет определяться потребностями клиента, а также тем, что отдел продаж сможет ему продать, а вы, как технический отдел, – выполнить. Итак, если вы решили, что поддержка будет оказываться и в нерабочее время, то необходимо будет укомплектовать штат сотрудников (обеспечить отдельные команды в разных часовых поясах, либо наличие дежурного, который будет постоянно доступен по телефону, либо организовать круглосуточное присутствие сотрудников в офисе) и запланировать соответствующие расходы в бюджете.

Никогда не пытайтесь оказывать круглосуточную поддержку 7 дней в неделю, не имея продуманного плана, как конкретно она будет предоставляться. Ее нужно планировать так же, как ужин на День благодарения или Рождество. Полагаться на то, что команда много лет шла вам навстречу, или надеяться, что аварий не будет, – это не стратегия поддержки. Подходите к организации поддержки так же, как вы ожидаете этого от ваших поставщиков.

Самая неловкая ситуация, которая сразу говорит о нашем непрофессионализме, – это узнать о том, что что-то не работает или недоступно, от клиента. Тем не менее в какой-то момент нашей карьеры все мы в ней оказывались. Приложив некоторые усилия, можно создать культуру эффективного мониторинга, которая позволит как вам, так и вашему руководству чувствовать себя более уверенно.

Если ваш основной пользователь или клиент не является частью вашей компании, то необходимо контролировать работу сервиса с его позиции. Как бы очевидно это ни звучало, это означает, что средства мониторинга должны находиться вне вашей сети. Например, если вы используете AWS, то для мониторинга стоит использовать Azure или Google, или, по крайней мере, отдельную учетную запись AWS в другом регионе.

Внешний мониторинг предполагает периодическое выполнение с вашим сервисом действий, имитирующих реальное взаимодействие с клиентом. Эти действия могут находиться в диапазоне от простого определения доступности сервиса до измерения сетевых задержек и времени отклика. При создании средств мониторинга проектируйте их таким образом, чтобы каждое сообщение о проблеме сопровождалось информацией о том, что конкретно пошло не так.

Например, вы можете просто контролировать доступность веб-страницы входа в систему. Для начала неплохо, но так вы не проверите доступность API для аутентификации клиентов. Если двинуться дальше и использовать для входа тестовую учетную запись, то вы подтвердите возможность аутентификации; однако проверяет ли это работоспособность основного сервиса? Можете ли вы запрашивать еще какие-то API, которые будут выполнять запросы (только легкие) к основной базе данных? Мы добавили всего пару дополнительных шагов, но посмотрите, насколько больше всего теперь проверяется: и сеть, и API, и база данных. Выполняйте проверку каждые 5-30 минут (в зависимости от потребностей), и, если что-то из указанного выше перестанет работать, вы очень быстро об этом узнаете.

Теперь продумайте отправку оповещений. Логично отправлять их в электронном письме, но как конкретно? Если электронная почта работает в той же сети, которая контролируется, то существует риск, что письмо не будет доставлено, потому что та же проблема, которая мешает работе сервиса, может препятствовать и отправке электронной почты. Это еще одна веская причина использовать электронную почту Google или Microsoft – независимо от того, что происходит в вашей сети, почта всегда будет доступна. Если же вы поддерживаете и используете собственный почтовый сервер, то все равно настройте для оповещений адрес не на вашем основном домене, а на бесплатном сервисе (Gmail, Yahoo и т. д.), чтобы он пересылал письма нужным людям.

При использовании стороннего сервиса электронной почты придерживайтесь той же схемы: создайте группу или алиас «alert», письма на который будут пересылаться всем, кому нужно. Гораздо проще управлять списком рассылки, чем отправлять письма отдельным получателям.

Еще один полезный инструмент – это публичная страница состояния с индикаторами работы каждого общедоступного компонента. Такие страницы можно видеть, например, на Amazon и Azure. Множество проектов с открытым исходным кодом позволяют создать ее без особых усилий. Опять же, убедитесь, что страница состояния не находится в основной сети организации.

Взгляд снаружи полезен, но гораздо большее покрытие и детализацию обеспечивает внутренний мониторинг, помогающий предотвратить потенциальные проблемы до того, как они повлияют на клиентов, – например, контроль использования дискового пространства, чтобы освободить место прежде, чем сервер перестанет работать. Это простой пример, но он иллюстрирует эффективность внутреннего мониторинга. Контроль параметров основных компонентов, таких как процессор, память и диск, каким бы банальным он ни казался, поможет обнаружить множество ситуаций, потенциально ведущих к серьезным сбоям.

Определите, какое состояние компонентов следует считать «нормой». Это поможет определить и проанализировать всплески активности или необычное использование ресурса. Если внезапно уменьшился объем используемой памяти, это может говорить о том, что какой-то процесс умер или что он работает нестабильно – запускается и тут же падает. Обращайте внимание на непонятные отклонения от нормы – рост нагрузки, не связанный с увеличением трафика от пользователей или приходом новых клиентов.

С учетом особенностей вашей системы определите критерии, на основании которых вы будете принимать решение об обновлении или расширении ваших сервисов (добавлении ресурсов для веб-серверов или баз данных) или же, наоборот, об освобождении ресурсов, которые больше не нужны. Эти метрики жизненно важны для обеспечения нормальной работы. Другой уровень мониторинга – это журналы, в которых приложения фиксируют все события во время работы. Каждое приложение генерирует такие журналы, которые могут храниться как в отдельных файлах на диске, так и в службе событий Windows или в Amazon CloudWatch. Источников данных много.

Современный способ обрабатывать все эти данные – перенаправить все журналы в централизованную службу (такую как Elasticsearch) и использовать ее для сравнения, поиска аномалий, мониторинга и оповещения. Так вы сможете не только проводить анализ всех журналов в одном месте, но и легко обнаруживать связи между разными компонентами, потому что проблемы в одном из них могут быть признаком другого, более серьезного сбоя. Классический пример: увеличение количества SQL-ошибок в веб-приложении указывает на проблемы с сервером базы данных, где долго выполняющийся запрос мог заблокировать таблицы. Такие зависимости бывает трудно обнаружить, поэтому для анализа причин проблемы придется проверять различные подсистемы.

В идеале все журналы должны в итоге попадать в общее хранилище. Это журналы как операционных систем, так и маршрутизаторов, файерволов, различных приложений, VPN, сетей, а также журналы аутентификации пользователей, клиентов и процессов. На их основании можно сделать удивительно много полезных наблюдений – например, вы можете обнаружить, что каждый раз при входе кого-то в систему повторяется один и тот же набор действий. Информации слишком много не бывает.

Создание информационных панелей (дашбордов), отображающих информацию о текущем состоянии ваших систем, потребует времени, проб и ошибок. И они будут развиваться по мере того, как ваше понимание работы систем будет углубляться. Ваша цель здесь проста: выиграть как можно больше времени для корректирующих действий, прежде чем проблемы затронут работу компании. Не допускайте ситуации, в которой единственным средством мониторинга станут звонки ваших клиентов. Это не способствует повышению доверия ни к вам, ни к вашей компании.

Почти все компании утверждают, что у них есть резервные копии, по крайней мере важнейших компонентов, но, как сетует Райан Берч, директор по информационным технологиям в New Harbour Capital, «выглядит очевидным, но часто забывается, что резервная копия, из которой никогда не проводилось восстановление, – это не резервная копия, а просто способ расходования хранилища, что-то, что создает иллюзию безопасности, как страховочный трос, который ни к чему не прикреплен».

Организация резервного копирования – это сложная задача, и, пока вы не выполните полное восстановление системы из резервной копии, вы не сможете узнать, действительно ли в ней сохраняются все компоненты.

Первый вопрос, на который вы должны ответить: что сохранять? Только данные, или же данные и конфигурацию, или же и данные, и конфигурацию, и само приложение? Ответ зависит в первую очередь от цели резервного копирования. Она может быть следующей:

• Восстановление в случае сбоя.

• Периодическая фиксация состояния для контроля соответствия требованиям.

• Использование для целей тестирования/разработки.

В подавляющем большинстве случаев резервные копии создаются для обеспечения бесперебойной работы, и в этом случае важно время восстановления. С каждой минутой простоя компания теряет деньги, а также репутацию и доверие к бренду. Отработанная стратегия резервного копирования станет залогом вашего душевного спокойствия, поскольку в случае аварии вы будете иметь четкий план действий и понимать сроки восстановления.

Обычно рекомендуется хранить файлы резервных копий в зашифрованном виде в отдельной сети или в отдельной учетной записи в облачном сервисе. Но часто, особенно в небольших организациях, резервные копии хранятся не отдельно, а на том же самом компьютере. Исходите здесь не из того, что сбой возможен, а из того, что в какой-то момент он обязательно случится.

Необходимо делать резервное копирование не только для тех сервисов, которые вы обслуживаете самостоятельно, но и для всего, что хранится в сторонних сервисах. Например, регулярно копируйте исходный код, размещенный на GitHub или Bitbucket, в безопасное и управляемое вами место. Часто забывают и о Salesforce, особенно если он применяется в основном как облачная база данных. Если вы используете Google Диск, Office 365, Dropbox – любой сервис, в котором вы храните данные, – спросите себя, к каким последствиями приведет потеря доступа к нему или блокировка учетной записи?

Чтобы создать надежную стратегию резервного копирования и восстановления, требуется много усилий; кроме того, понадобится выполнить первое архивирование и копирование данных и настроек. Но после этого все должно работать на автопилоте, а отчеты должны регистрироваться в централизованной системе журналирования, чтобы вы получали оповещения, если резервное копирование не было выполнено или произошла какая-то ошибка.

Отработайте восстановление системы. Создайте план действий и разместите его в доступном месте, чтобы любой, кто имеет необходимые доступы, мог легко собрать и восстановить систему. Проводите учения не реже, чем раз в год (или даже чаще), чтобы убедиться, что есть резервные копии для всех необходимых компонентов.

Два насущных вопроса – как часто следует делать резервные копии и как долго их следует хранить. Рассмотрим каждый из них по очереди.

Частота резервного копирования главным образом зависит от того, как часто меняются данные. Если это происходит только раз в неделю, то при ежедневном резервном копировании архивы почти не будут различаться. Слишком частое резервное копирование может привести к чрезмерному расходованию ресурсов и нагрузке на диски. Если вам требуется восстановление с высокой точностью, стоит учесть это требование при первоначальном проектировании вашего хранилища: например, использовать репликацию данных в несколько разных регионов в режиме, близком к реальному времени.

Раньше срок хранения резервных копий зависел от доступного места. С появлением облачных хранилищ и оплатой по мере их использования лимитов по размеру больше не существует. Теперь акцент смещается в сторону определения, какие данные являются полезными для восстановления.

Раньше рекомендовалось сохранять последние три резервные копии на случай их потери или сбоя копирования. Теперь, с хранилищами большого объема, использованием контрольных сумм и шифрованием, это не проблема. В большинстве случаев будет достаточно одной копии. Однако если вы понимаете, что резервная копия может понадобиться для восстановления только части данных, то вам стоит хранить архивы подольше.

Допустим, вы узнали, что был случайно удален какой-то набор данных, но это обнаружилось только через несколько дней или недель – что нередко случается, когда вашим сервисом пользуется несколько разных клиентов. В такой ситуации лучше иметь возможность вернуться и для части данных восстановить состояние, в котором они были в заданный момент времени. Поэтому хранение данных в течение нескольких месяцев может быть оправдано.

Прежде чем завершить эту тему, необходимо упомянуть о том, как важно обеспечить безопасность полученных архивов: из-за недостаточного внимания к их защите и легкой доступности они могут стать источником утечек конфиденциальных данных. Вы же не хотите, чтобы все усилия по обеспечению безопасности и многоуровневая система контроля доступа стали бесполезными только потому, что резервная копия доступна для всех, у кого есть полномочия DevOps.

Сотруднику, ответственному за создание и проверку резервных копий, необязательно видеть данные внутри архива. Управляя доступом к ключам шифрования, вы можете ограничивать доступ к архивам резервных копий и обеспечивать их сохранность.

Уделяйте безопасности резервных копий такое же внимание, как и безопасности систем, к которым они относятся. Не позволяйте резервным копиям стать источником утечки.

Слова due diligence могут вселить страх в сердца даже самых опытных технических директоров, уверенных, что это обязательно будет допрос с пристрастием и что все, что они сделали, будет подвергнуто критике. Любой, кто видел классический фильм «Офисное пространство» («Office Space», 1999), помнит сцену, когда два менеджера (обоих зовут Боб) собеседуют всех сотрудников, решая, кого уволить. Вот зловещая фраза, которая, по мнению многих, воплощает в себе всю суть due diligence: «Чем вы вообще здесь занимаетесь?»

Due diligence – это возможность для покупателя понять, что он на самом деле покупает, и в том числе узнать обо всех подводных камнях. Возвращаясь к аналогии с покупкой дома, результат due diligence похож на отчет об осмотре объекта недвижимости, составляемый профессионалами. Они указывают в отчете, на что покупатель должен обратить внимание перед покупкой, чтобы избежать неприятных сюрпризов (например, на протекающую крышу или на то, что кондиционер требует замены).

Зачастую даже крупные консалтинговые компании, проводя due diligence, могут упустить важные детали и контекст. Многие из них забывают интересоваться «зачем». Проведение due diligence не должно быть прохождением по таблице с заранее подготовленными стандартными вопросами, потому что так оно неизбежно превращается в формальное дознание, исключающее возможность отметить достижения и интересные особенности.

Когда кто-то что-то покупает – телевизор, машину, дом или компанию, – он делает это с конкретной целью: решить свою проблему. Если вы планируете использовать телевизор только для Xbox, то вам не нужна возможность установки на него приложений и неважно, сколько каналов он может принимать. Вас интересует только разрешение и частота обновления экрана. Другой покупатель собирается смотреть местные новости и Netflix, и его процедура оценки будет совсем не такой, как у геймера. Это вопрос соответствия цели, то есть «зачем».

Прежде чем начинать due diligence, определите причину покупки, то есть планы и ожидания от нее. Это позволит обеим сторонам сделки сосредоточиться на действительно важных и актуальных вопросах. Таким образом, due diligence – это диалог, а не сцена допроса подозреваемых, прикованных наручниками к столу, из сериала «Полиция Чикаго» («Chicago PD»).

Этап due diligence – довольно поздняя стадия сделки по приобретению, и к этому времени «зачем» должно быть уже хорошо понятно. Таким образом, цель проведения оценки проста: узнать, способна ли приобретаемая технология делать то, что нам нужно, а если нет, то сколько денег и усилий потребуется, чтобы она смогла это делать?

Мы рассмотрим процесс due diligence с точки зрения каждой из участвующих в нем сторон. Вы можете как проводить оценку due diligence, так и быть в центре ее внимания. Начнем с первого варианта, поскольку он дает больше понимания и общей информации, а затем перейдем на другую сторону.

В зависимости от того, на каком этапе находится ваша карьера, вы, скорее всего, хотя бы 1–2 раза уже проводили due diligence. Возможно, процедура называлась иначе – скорее всего, оценкой. Она могла проводиться не для компании, а для конкретного ПО, языка, фреймворка или сервиса. Готовясь к ней, вы заранее изучали все, что могли, формулировали свои мысли и составляли вопросы.

Когда вы общались со специалистами по оцениваемой системе (ее пользователями или же техническим менеджером), вы спрашивали их о вещах, относящихся к проблеме, которую эта система должна решать. У вас наверняка не было таблицы с абстрактными вопросами, ответы на которые ни на сантиметр не приблизили бы вас к принятию обоснованного решения. Вместо нее у вас был список тем, относящихся в основном к эксплуатации продукта, обсудив которые вы бы поняли, в правильном ли направлении движетесь. В этом и состоит разница: так вы понимаете «зачем» сделаны те или иные вещи, и на основании этого можете определить, подходит ли оцениваемый продукт для ваших целей.

Тот же подход применяется при оценке технологий всей компании – в этом случае требуется просто немного больше усилий, но сам процесс будет не сложнее. Вы здесь эксперт по технологиям, который занимается решением практических проблем. Большая часть из того, что вы увидите, будет либо «кока-колой», либо «пепси» (они обе хороши – просто разные), либо какими-то мелочами, которые легко решить. Так что именно вы, а не сотрудник консалтинговой компании, лучше всего подходите для проведения due diligence. Вы способны быстро распознать вещи, требующие особого внимания, поскольку они могут стать проблемными.

Рассмотрим основные области, которые требуют подробного изучения. При проведении обследования помните, что, если сделка состоится, все обнаруженные проблемы или вопросы придется решать вам. Но вполне возможно, что вы также узнаете что-то, что поможет вашей команде и что можно будет использовать в дальнейшей работе. Может быть, вы найдете решение для проблемы, с которой давно боретесь, или узнаете, как делать что-то более эффективно. Всегда найдется что-то полезное.

Насколько отличаются их технологии от ваших? Достаточно ли у вашей команды знаний, чтобы использовать их? Если они применяют устаревшие технологии, то что потребуется для их дальнейшей поддержки, в том числе будут ли проблемы с подбором специалистов или обслуживанием оборудования или операционных систем? Есть ли что-то, что можно оптимизировать или сделать более эффективным с помощью современных технологий? Если понадобится все переписать – каких усилий и затрат это потребует и вызовет ли это перебои в работе?

Какая часть их технологий уникальна? Что является объектом ПИС («секретным ингредиентом») – алгоритмы и код – либо это способ применения инструмента? Имеются ли патенты на технологии, и если да, то кому они принадлежат – физическим лицам, компании, кому-то еще? Кто (как ни странно это звучит) на самом деле является владельцем исходного кода? Ответ на этот вопрос не всегда очевиден, особенно если компания отдавала основную разработку на аутсорсинг.

Как сохраняются и используются данные? Какой их объем доступен и может применяться для аналитики? Каковы основные источники и потребители данных? Кому принадлежат данные и какие есть ограничения на их использование? Как регулируется работа с данными (должен ли выполняться регламент Евросоюза по защите персональных данных (GDPR)?) и есть ли в компании конфиденциальные данные, подпадающие под действие нормативных требований (например, PII, PCI или HIPAA)?

Какова структура существующей технической команды? Каковы навыки и опыт сотрудников? В небольших организациях люди часто работают с самого момента основания компании, и всему, что они умеют, они научились на этой работе. Если вы имеете дело с таким случаем, то чему и у кого эти люди учились?

Кто из инженеров является более опытным, чем остальные, и незаменимым? Лучший способ выяснить это – спросить: «Чье отсутствие сильнее всего заметно в компании, когда человек уходит в отпуск?» Большинство команд ответят на этот вопрос быстро и не задумываясь. Небольшие компании слишком полагаются на верность и трудолюбие одного человека. Иногда это тот самый, кто спроектировал все системы, и, вероятно, именно он отвечает на все ваши вопросы в связи с due diligence.

Привлекает ли компания подрядчиков или аутсорсинговые фирмы для поддержки или разработки? Каковы их зоны ответственности и сроки договоров? Вам необходимо выяснить, могут ли какие-либо договорные отношения вызвать проблемы в будущем (например, с правами собственности или с прекращением договора).

О каких проблемах обычно сообщают пользователи или клиенты? Сколько времени тратится на поддержку по сравнению с разработкой новых функций?

Сколько усилий или времени обычно занимает в компании подключение новых клиентов? Участвует ли в этом техническая команда? Какие серьезные сбои или проблемы были за последние 12 месяцев? Как они повлияли на клиентов и что было сделано, чтобы они не повторились? Что не дает руководству спать по ночам и что бы они сделали в первую очередь, если бы у них была волшебная палочка?

Как в целом в компании организовано обеспечение безопасности? Когда в последний раз менялись основные пароли? Какие доступы имеют разработчики? Отделен ли продакшен от окружения для разработки?

Если компания работает с учетными данными пользователей, то как хранятся пароли в базе данных (открытым текстом или в виде хэша с солью)? Вы удивитесь, сколько компаний до сих пор хранит пароли в открытом виде!

Как организовано тестирование, проводились ли тесты на проникновение, на SQL-инъекции в продакшене? Требования безопасности либо могут учитываться с самого начала, либо про них вспоминают в какой-то момент позже – вам нужен первый вариант.

Если приобретаемая компания разрабатывает исходный код, очень важно изучить его общее качество и подходы к разработке. Вникнуть в каждую строчку кода, конечно же, не получится. Во-первых, у вас нет времени, а во-вторых, за несколько часов невозможно понять результат разработки, ревью, переписок и исправлений, сделанных множеством разработчиков за годы. Лучше выбрать несколько мест, подробно изучить их и на основе этого сделать вывод об общем состоянии.

Все мы в своей жизни писали код, по которому лучше бы нас не оценивали, поэтому выберите относительно недавний коммит. Найдите его по истории в системе контроля версий или начните с какого-то из тикетов и проследите работу над ним от создания задачи до разработки и деплоя на продакшен.

Еще одна сфера, на которую следует обратить внимание, – безопасность разработки. Изучите, как в коде организована работа с параметрами конфигурации, именами пользователей и паролями. Если в инфраструктуре имеется большое количество API – проанализируйте, как они устроены, единообразно ли используются? Как обрабатываются ошибки и исключения? Код основан на предположениях о том, что ничего не сломается, или в нем предусмотрены различные проверки?

О зрелости кода многое скажет его общая структура. Это просто куча функций или же все организовано в виде объектов, которые можно использовать при разработке нового функционала? И если говорить об использовании готового кода, то какие библиотеки с открытым исходным кодом применяются для решения типовых задач, и применяются ли? Соответствуют ли лицензии этих библиотек требованиям бизнеса, соблюдаются ли условия лицензий?

Наконец, ознакомьтесь с системой журналирования. Как мы увидели в предыдущей главе, она помогает мониторить продакшен в реальном времени и оперативно диагностировать проблемы. Приводятся ли журналы к единому формату, чтобы можно было легко выявлять исключения и ошибки среди информационных и прочих не требующих реагирования записей?

В компаниях, занимающихся разработкой, стоит изучить организацию работы, включая ревью кода, работу с системой контроля версий, тестирование, сборку и деплой. Небольшие команды обычно гораздо меньше соблюдают формальности, и в них все это может быть в зачаточном состоянии. Не нужно осуждать их – просто отметьте это как особенности. Неважно, что и как они делают и нравится вам это или нет: результат их работы кому-то нужен, иначе вы бы даже не и подумали приобретать эту компанию.

Последнее, что необходимо выяснить, – как выполняется деплой и как организован мониторинг продакшена. Вы можете спросить, для эффектности добавив драматическую паузу: «Откуда вы знаете, что прямо сейчас у вас все в порядке?» Ответ на этот простой вопрос, в том числе честное пожимание плечами, говорящее о том, что ваш собеседник понятия не имеет, все ли в порядке, многое скажет о том, как в компании организован продакшен.

Вам нужно понять, что необходимо для бесперебойной работы проекта. Помните: если сделка пройдет успешно, это станет вашей заботой. Итак, выясните, какие требуются ежедневные проверки, какие журналы нужно просматривать и по каким признакам можно понять, что что-то может пойти не так.

Изучите план обеспечения отказоустойчивости. Как работает резервирование при сбоях? Обсудите слабые места и точки отказа и что с ними можно сделать. Сюда также относится вопрос резервного копирования и восстановления – при его обсуждении также выясните, есть ли доступная документация или инструкции по восстановлению.

Еще в рамках этой темы узнайте, кто отвечает за оплату сторонних сервисов и продление подписок и договоров с ними. Нередко (особенно в небольших компаниях) учетные записи таких сервисов, как AWS, GitHub или GoDaddy, «принадлежат» программисту, который начал с ними работать, просто потому, что к ним привязана его банковская карта и с нее списывается ежемесячный платеж, который затем возмещается компанией.

Большинство из найденных проблем вполне решаемы и рассматриваются в этой книге, но, прежде чем заключать сделку, важно определить, кто чем владеет и на каких основаниях.

Все вышеупомянутые темы – это всего лишь то, что нужно иметь в виду, чтобы вы могли начать готовиться к изучению вопроса, насколько приобретаемая компания соответствует вашим целям. Теперь нужно понять «как». Не устраивайте допрос и не задавайте вопросы по заранее заготовленному списку. Придя с перечнем вопросов, вы не построите правильные взаимоотношения и не узнаете нужные вам подробности. Вместо этого просто разговаривайте – пусть два технаря рассказывают друг другу о себе и своей работе. Вашему собеседнику должно быть интересно и комфортно, он должен спокойно делиться информацией, а не жалеть, что не взял с собой адвоката!

Всегда поддерживайте дружелюбный настрой, цените усилия другой стороны и хвалите ее за результаты, которых она добилась. Повторюсь, что сам факт того, что к компании проявляют интерес покупатели, говорит о том, что дела в ней идут скорее хорошо, чем плохо.

Вы пришли не для того, чтобы судить кого-то и решать, что правильно, а что нет. Вероятно, вы найдете много такого, что можно улучшить, но это можно будет сделать позже. Выясните, из-за каких препятствий или обстоятельств все получилось именно так, а не иначе. Например, из-за нехватки финансирования или просто из-за незнания альтернативных вариантов.

Ваша цель здесь – наладить отношения, создать связь. Если все пойдет по плану, то человек, с которым вы разговариваете, станет частью вашей команды. И он должен чувствовать, что способен принести вам пользу.

Во время разговора с активным использованием доски и погружением в код информация начнет передаваться сама собой, без всякого принуждения. Чтобы создать нужный настрой, я обычно использую два сценария ролевой игры. Первый – я выступаю в роли нового клиента и прошу провести меня через процесс интеграции, включая демонстрацию продукта и обучение. Это прекрасный способ создать комфортные условия для вашего собеседника, потому что так он может с гордостью продемонстрировать свой продукт и показать его лучшие стороны. Также вы достигнете следующих целей:

• Узнаете, какие термины приняты в компании для общения с клиентами. Это позволит вам использовать привычные для них формулировки и тем самым уменьшить количество вопросов, которые могут быть неверно поняты, потому что вы выбрали не те слова или фразы.

• Понять, какие функции наиболее важны для клиентов. Фразы наподобие «Мы такое можем, но никто этим не пользуется» сразу отсекут целую массу вопросов, а вы узнаете, что что-то не совпадает с ожиданиями руководства.

• Получите возможность углубиться в детали той или иной области, чтобы выяснить то, что вас интересует. Например, вам показывают интерфейс чата и в нем можно загрузить файл. Вы сможете спросить, куда в итоге попадает загружаемый файл, а также есть ли резервные копии этого места, и если есть, то где они хранятся.

Когда показ для клиента закончится, самое время будет сделать перерыв на обед или кофе. Используйте возможность поблагодарить за разговор и похвалить проект. Будьте здесь самим собой. Позвольте всем немного отдохнуть перед второй ролевой игрой.

В зависимости от того, как устроен отдел разработки, с которым вы общаетесь, она может выглядеть по-разному. Ваша задача – получить как можно больше информации, не вызывая у собеседника чувства, что он наговорил лишнего.

В этой игре представьте себя новым разработчиком, инженером или другим членом команды, проходящим адаптацию, чтобы приступить к работе. Побыв в роли клиента, вы узнали терминологию, принятую в компании, так что теперь можете адекватно общаться и задавать более актуальные и конкретные вопросы, ответы на которые позволят вам стать полноценным членом команды.

Это даст всем возможность углубиться в подробности, при этом ваш собеседник будет находиться в знакомой ему ситуации, особенно если компания недавно нанимала новых сотрудников. Так вы познакомитесь с внутренними процессами, способами взаимодействия и управления задачами, порядком разработки и деплоя кода, а также с основными компонентами, которые обеспечивают работу системы.

Еще одним результатом должна стать атмосфера доверия и взаимопонимания. Вы можете поделиться своим опытом и, возможно, помочь решить какие-то очевидные проблемы, а также оценить сложности, с которыми сталкивается компания. Теперь заполнить любые пробелы в знаниях будет гораздо проще.

Удобно иметь карточку с нужными вам темами, как в лото. Каждый раз, когда вы знакомитесь с каким-то вопросом, ставьте галочку. Эта карточка не определяет ни порядок обсуждения, ни конкретные вопросы. Но она позволит отследить, все ли темы вы охватили в процессе обсуждения. Успешный due diligence информативен, познавателен и увлекателен для обеих вовлеченных сторон.

Поговорив со всеми и составив необходимые заметки, изложите свои выводы языком, понятным нетехническим специалистам. Результаты вашей работы будут использовать руководители, банкиры, юристы, инвесторы, операционные партнеры и бухгалтеры. Не перечисляйте технические подробности, а укажите возможные последствия для всего, что вы нашли, и то, какие усилия потребуются для устранения проблем.

Вернемся к аналогии с домом. Предположим, вы обнаружили неисправность выключателя бойлера. Не вдавайтесь в технические детали; просто укажите, что горячей воды нет, на ремонт уйдет три недели и его ориентировочная стоимость составит 2000 долларов. Это более ценная информация для покупателя. Теперь он знает, что ему нужно найти 2000 долларов (либо добавить денег, либо попросить скидку от цены продажи) и он минимум три недели не сможет принимать душ.

С технологиями принцип тот же. Когда мы, технари, излагаем подробности (например, что у основной базы данных нет резервирования и что она работает на одном сервере с публичным IP-адресом), нам кажется, что все тут понятно. Часто мы упускаем из виду вопрос «и что?» и забываем объяснить, каковы последствия этого.

В примере с базой данных мы могли бы сказать: «В случае сбоя (в том числе отключения электроэнергии) компания не сможет работать, а на восстановление может уйти несколько дней. Нужно выбрать и внедрить решение для обеспечения отказоустойчивости, это будет стоить X долларов». Все технические подробности, подтверждающие ваши выводы, должны содержаться в приложениях или сопутствующей документации. Стандартный отчет о due diligence включает в себя следующее:

1. Общий обзор объекта покупки.

2. Методология: время проведения, кто присутствовал, какие материалы были предоставлены, а какие были недоступны.

3. Выводы.

4. Дополнительные материалы.

Выводы необходимо упорядочить по серьезности их последствий для бизнеса. Можно составить отдельный список того, что вам понравилось и что можно похвалить.

Пишите так, чтобы содержание документа было понятно каждому, независимо от его уровня технических знаний. Представьте правдивую картину, ничего не искажая. Если целевая компания использует X, а не Y, а вы предпочитаете Y, то это не имеет никакого значения и не должно указываться в качестве проблемы.

Если позволяет время, попросите людей, с которыми вы говорили, просмотреть документ перед публикацией. На это есть две важные причины. Во-первых, точность. Вы могли что-то не понять или перепутать. Проверка дает возможность исправить такие ошибки. Ваше самолюбие здесь никак не задевается, потому что вы излагаете не мнения, а факты. Вторая цель – установить связи и вызвать доверие людей, которые, возможно, будут работать в вашей команде. У них будет возможность увидеть, что вы считаете важным и как вы предлагаете действовать. Вы также продемонстрируете вашу открытость, честность и порядочность. В конце каждой беседы отмечайте, что у собеседника будет возможность проверить точность итогового отчета и что в отчете не будет никаких сюрпризов или того, что не обсуждалось. Нервозность и недоверие никому не идут на пользу.

До сих пор мы обсуждали, как проводить due diligence со стороны покупателя, но что, если ваша компания – объект покупки и опрашивают вас? Теперь, когда вы знаете, как проводить процесс, вы лучше поймете, о чем вас спрашивают. Имейте в виду, что вас не судят, а если вы чувствуете обратное – это ошибка того, кто проводит интервью.

Существует много так называемых экспертов, которые проваливали due diligence, общаясь снисходительно или высокомерно. К сожалению, в этой ситуации вам остается разве что отнестись к происходящему с улыбкой. Вопреки распространенному мнению, не всегда покупает тот, кто предложит самую высокую цену – в большинстве случаев сделки заключаются с теми, кто наиболее подходит по менталитету. И due diligence в том числе позволяет это понять.

Ключом к успешному общению является подготовка. Однако к вам могут прийти уже со списком вопросов, и через 20 минут вы будете умирать от скуки. В этом случае вежливо поинтересуйтесь, не будет ли проще и быстрее, если этот список пришлют вам по электронной почте и вы ответите на все вопросы.

Не обязательно готовить многостраничные документы, но следующая информация должна быть у вас под руками:

• Общие схемы архитектуры/сети.

• Список всех технологий (включая версии).

• Лицензии, даты обновления и стоимость.

• Организационная схема со всеми сотрудниками.

• Описание процесса адаптации новых членов команды.

• Список недавних обращений в поддержку.

• Приоритеты развития.

Проницательный читатель узнает список: это темы, которые освещались в книге и которые должны быть постоянным объектом внимания CTO.

Вам необходимо предоставить как можно больше подробностей, не раскрывая при этом секретную информацию, и помочь покупателю принять обоснованное решение. Возможно, есть вещи, которые вы предпочтете не обсуждать. Причины для этого могут быть разными, но в любом случае необходимо согласовать это с генеральным директором (и, если нужно, с отделом кадров), чтобы вы одинаково понимали, какую информацию можно раскрывать.

Главное – никогда не лгите и не искажайте информацию, ни к чему хорошему это не приведет. Если вам задают действительно неудобный вопрос, тактично переадресуйте его генеральному директору. Но такое бывает редко, особенно в случае небольшой компании, которую вы, скорее всего, представляете.

Тем не менее подробно обсудите вопрос разглашения коммерческой тайны с генеральным директором. В какой-то момент, пусть и не на раннем этапе, вы с ней столкнетесь.

Доступ к исходному коду, если его попросят, предоставить можно и нужно. Вы можете показать его или в виде простого zip-файла, переданного через защищенный канал, или же создать в вашей системе контроля версий учетную запись с доступом только для чтения. Однако, когда вы дойдете до баз данных – доступ к ним необходимо ограничить максимум демонстрацией экрана, без прямого доступа к данным. Они принадлежат вашим клиентам и должны быть защищены. Вы можете показать количество записей в таблицах, какие-то примеры, но не забывайте о безопасности.

Все то же самое относится и к инфраструктуре. Если вы используете облачные сервисы, вы обязательно будете их обсуждать. Заранее подготовьте учетную запись только для чтения, позволяющую посмотреть на все, что необходимо, без возможности внести какие-то изменения.

Открыто и честно говорите о недостатках. Кто знает, возможно, именно эти люди помогут вам решить проблему. И прежде всего старайтесь получить от общения удовольствие и пользу – как бы вы ни готовились, всегда найдется что-то, что можно улучшить, и вы всегда сможете чему-то научиться.

Помните: желающих приобрести ваш бизнес может быть несколько, и в этом случае за короткое время вам придется провести не одну встречу с потенциальными покупателями. Не забывайте, однако, про свои основные обязанности. Клиентам по-прежнему нужно предоставлять сервис, командой нужно руководить. Делегируйте часть задач либо выделите достаточно времени, чтобы вы могли отвлечься. Проведение due diligence тоже может занять больше времени, чем вы предполагали, поэтому заранее составьте план на случай вашей занятости.