Будучи признанным техническим директором (CTO), имея частичную занятость в качестве технического директора в пяти разных компаниях, а также являясь бывшим техническим директором, работающим уже на полную ставку в трех разных стартапах, и, наконец, как человек, который в настоящий момент руководит агентством по разработке программного обеспечения и запускает свои собственные продукты, я могу с уверенностью сказать, что в течение первых 30 дней работы в качестве CTO у вас не будет времени на шутки. Я расскажу вам, как извлечь максимум пользы за это время… Вам стоит понять, что вас наняли, чтобы вы несли ответственность за выполняемую работу. Раньше я ждал поддержки от команды или CEO, чтобы меня ввели в курс дела. Теперь же я не жду, а просто беру инициативу в свои руки. Меня наняли для того, чтобы я выполнял свою работу, и именно от меня зависит в каком направлении поплывет этот корабль. Например, организуйте ланчи с командой в неформальной обстановке и без промедлений планируйте выездное развлекательное мероприятие.  Определяйте паттерны, элементы дисфункции и ведите подробные записи. Будьте Шерлоком Холмсом и начните распознавать, что люди на самом деле подразумевают под своими словами. Прислушайтесь к тому, о чем шепчутся люди вокруг... Я знаю, что это ужасно, но вам придется играть в эту игру. Если у членов вашей команды есть какие-либо недостатки, вам нужно знать о них СЕЙЧАС, прежде чем вы встанете у штурвала. СОВЕТ ОТ ПРОФИ: делайте записи. Создайте систему показателей для каждого из ваших подчиненных и начните определять, какие у них цели и насколько они в этом преуспели. Давайте посмотрим, чем же вы будете заниматься следующие несколько недель. Почему мы создаем именно этот продукт? Поговорите с руководителями компании. Узнайте какое у них видение. Чаще разговаривайте с продакт-менеджерами, и поймите, на каком этапе они находятся. Будьте с ними по-настоящему честны. Дайте им знать, что ваши отношения крайне важны для достижения успеха этой компании. Ошибка очень многих компаний заключается в том, что продакт-менеджеры и руководители отдела технологий обвиняют друг друга в недочетах. В прошлом мне удавалось избегать этого хаоса благодаря объединению отдела по продукту и отдела по технологиям в один технологический отдел. Хотя многие терпеть не могут эту стратегию, она полностью оправдала себя в компаниях, с которыми я работал. В вашей компании может не быть такой гибкости и возможности объединения, поэтому вам лучше всего работать в согласии с командой по разработке продукта. Несколько вопросов, которые вы можете задать: Почему мы создаем этот продукт? Почему этот продукт найдет отклик у наших клиентов? Почему он важен для рынка? Почему именно наша команда подходит для создания этого продукта? Почему кто-то другой не создал этот продукт до нас? Почему нас воспринимают всерьез? Почему люди готовы работать день и ночь для реализации этой идеи? Почему наши коллеги доверяют нам быть лидерами? Советы: Узнайте о каждом проекте, которые планирует реализовать ваша компания. Узнайте о всех текущих проблемах, с которыми сталкивается команда по разработке продукта. Распишите все цели на год, шесть и три месяца и проанализируйте стратегии на эти периоды. Периодически разговаривайте с вашим CEO и просите посвящать вас в его видение почаще. Помните, согласны вы с этим ним или нет, успех будет зависеть только от ваших действий. Потому что если вы не можете воплотить это видение, у всей компании будут проблемы. После того, как вы получили ответы на вопрос “Почему”, пора переходить к следующему вопросу “Что?”. Что именно мы создаем? Узнайте о каждой составляющей вашего флагмана. Если вы начинаете с нуля, пора перейти к чертежной доске и определить, что мы пытаемся создать. Сильно не мудрите. Цель состоит в том, чтобы НЕ переусердствовать. Достаточно будет нарисовать на доске несколько блоков, чтобы мы понимали, что мы создаем. Часто я просто рисую блок-схему различных подсистем и их взаимоотношений друг с другом. Знать все детали о вашем флагмане критически важно. Если у вас не получается отразить все на листе бумаги, значит, вы делаете что-то неправильно. Несколько примеров вопросов “Что?”, которые вы можете задать: Что мы создаем? Что из себя представляют подсистемы? Что является основным направлением развития этой системы? Что из себя представляет минимально жизнеспособный продукт (MVP)? Что именно в нашем продукте будет вызывать удивление у клиентов на ежедневной основе? Что мы предприняли для измерения соответствия продукта рынку? Что не дает тебе уснуть по ночам? Что НЕ работает? Что из себя представляет процесс приема на работу? В чем заключается процесс утверждения нашего продукта? В чем заключается процесс разработки программного обеспечения? Что есть процесс управления релизами? В чем заключается процесс управления изменениями? Что из себя представляет общение в нашей команде? Какие из процессов работают действительно хорошо? Когда вы получили ответы на вопросы “Почему?” и “Что?”, переходите к вопросу “Как?”. Здесь все вращается вокруг процессов. Как мы строим наш флагманский проект? Как мы будем его внедрять? Как мы собираемся выходить на рынок? Как мы объединяем все наши команды для реализации подсистем, которые мы определили, когда отвечали на вопрос “Что?”? Как обстоят дела? Как мы можем стать лучше? Как мы измеряем успех/неудачу? Как мы празднуем наши победы? (И ДА - если вы этого не делаете, вам нужно изменить политику) Как мы автоматизируем процессы? Как не изобретать велосипед заново? Как мы относимся к нашим партнерам/поставщикам? Как мы работаем с нашими партнерами/поставщиками? Как часто мы делимся своим видением с командами? Как часто мы взаимодействуем с окружающим нас техническим сообществом? Как мы позиционируем наш продукт? Каков уровень согласованности технического отдела с остальными? Я мог бы продолжать и продолжать еще долго, но суть вы уловили... Это моя любимая часть. На этом этапе обнаруживается, в чем именно есть явные недоработки в бизнесе. Но если вас это удивило, возможно, вам не стоит заниматься стартапом. Для растущих компаний я очень рекомендую книгу “Traction” Джино Викмана (Gino Wickman). В ней говорится о том, как подобрать нужного человека на подходящую ему должность. Для любой команды, которую я возглавляю, крайне важно, чтобы нужные люди занимали нужные места. Помните записи, которые вы делали о подчиненных? Пришло время поразмыслить над этим. Вы уверены, что люди в вашей команде “Понимают”, “Хотят” свою работу и “Довольны ее результатом” ? Вы уверены, что остальные отделы (по крайней мере, те, с которыми вы взаимодействуете) также “Понимают”, “Хотят” свою работу и “Довольны результатом”? Вы не можете изменить направление развития других отделов, если эти моменты не совпадают. Однако очень важно, чтобы вы постоянно расставляли плюсы и минусы в столбцы “Понимают”, “Хотят” и “Довольны результатом” для всех членов команды, с которыми вы работаете. Даже если у кого-то есть минус по какому-то из пунктов, и вы не способны сейчас с этим ничего сделать, вы можете заранее выстроить стратегию. СОВЕТ: Вот почему я обычно не работаю CTO на полную ставку, если только я не являюсь владельцем акций с очень высокой долей участия. Я отказываюсь работать в компаниях, где я не могу влиять на решения в других отделах или где другие отделы имеют слишком большое влияние на CEO, в то время как техническое руководство не может влиять на решения. Если вы разбираетесь в продуктах, продажах, маркетинге, технологиях и лидерстве, вам также следует серьезно задуматься над этим. Вопросы “Кто?”, на которые у вас должны быть ответы: Кто тот человек, который понимает все подсистемы? Кто работает здесь дольше всех? (СОВЕТ ОТ ПРОФИ: сходите вместе с ним на ланч) Кто тот человек, который поднимет трубку посреди ночи, если что-то пойдет не так? Кто тот человек, к которому прислушивается CEO? Хорошо это или плохо, но с этим человеком нужно дружить. Кто на самом деле главный? Сюрприз… вы поймете, что ваш CEO не всегда является главным, даже если его все заставляют думать, что это так. Кто проявляет наибольший оптимизм в отношении этой компании? Кто наиболее пессимистичен в своих взглядах? Кто управляет DevOps? Кто является ведущим/главным архитектором? Кто отвечает за прием на работу? Кто отвечает за утверждение бюджета? СОВЕТ ОТ ПРОФИ: подружитесь с ними. Вам это пригодится. Повторюсь, я мог бы продолжать и дальше… но вы меня поняли. Теперь, когда вы разобрались в положении дел, пора сделать следующее. Не торопитесь. Вы только начали свою работу. Ваши первые 30 дней работы не изменят направление развития компании, и от вас этого не ждут. С другой стороны, теперь у вас есть записи, полные заметок, наблюдений, показателей и стратегий, на которые вы можете положиться в течение следующих 30 дней. Увидимся через 30 дней. Материал подготовлен в рамках курса «Microservice Architecture».  Всех желающих приглашаем на бесплатное demo-занятие «Паттерны декомпозиции сервисов». На открытом уроке мы разберем разные подходы к декомпозиции микросервисов: Monolith first, разбиение по агрегатам, по бизнес-возможностям, функциональную модель и разбиение по транзакциям. Немного поговорим про Event storming, BDD/User story, а также рассмотрим подходы к описанию сервисов.>> РЕГИСТРАЦИЯ Редактор