Привет, мир! Я Виталий, управляю проектами в KTS. Мы разрабатываем IT-решения для корпораций и стартапов.
В этой статье я расскажу о том, как прошла первая треть девятимесячного курса для CTO от школы менеджмента Стратоплан. Я написал ее для тех, кто:
взаимодействует с CTO и хочет лучше его понимать (например, тимлиды или другие миддл-менеджеры);
строит свой карьерный путь в сторону CTO и хочет разобраться, что ожидается от этой позиции (спойлер — ожидания разнятся в зависимости от вида бизнеса);
уже стал CTO и хочет провалидировать свой профиль и набор навыков, восполнить пробелы.
Сразу оговорюсь: к любым онлайн-курсам я всегда был настроен скептически, и к Стратоплану поначалу тоже относился настороженно. Тем не менее, в курсе для СТО я увидел закономерный этап развития своей карьеры, поэтому решился попробовать.
О своем решении я не пожалел, и теперь хочу поделиться собственным опытом максимально подробно. В этой статье я расскажу о том, как устроены отбор и обучение, и о том, что я успел изучить за первые месяцы.
Оглавление
Введение
Контракт
Начну с предыстории. В декабре через статьи на Хабре на меня вышел некий Влад из Стратоплана (привет, Влад!). Мне предложили пройти один из курсов, но не бесплатно: взамен я должен был написать несколько статей на Хабр. На тот момент предложение мне показалось сомнительным, поскольку раньше о Стратоплане я не слышал.
Поэтому соглашаться на такую авантюру сразу я не стал, и вместо этого провел небольшой рисерч. Сначала поискал отзывы на школу в не связанных со Стратопланом Telegram-чатах, в которых я состоял — там о школе отзывались весьма позитивно. А потом обнаружил, что еще несколько лет назад изучал их публичные материалы по менеджменту для общего развития. Просто тогда я не запомнил, что эти материалы публиковал именно Стратоплан.
В общем, по косвенным признакам я сделал вывод, что школе все же можно доверять, и записался на курс.
Выбор курса
Стратоплан обучает не только «начинающих» CTO — у них есть несколько курсов, каждый из которых был мне доступен. Я изучил сравнительную таблицу программ. Всего предлагалось 4 опции:
Для тимлидов. Последние несколько лет я и так управляю командами и, кажется, справляюсь с этим неплохо, так что «тимлидский» трек я особо не рассматривал.
Для руководителей отделов. Руководство отделом сводится к менеджменту нескольких команд на более высоком уровне абстракции; чем-то похожим я и пытаюсь заниматься сейчас.
Для CTO. Объективно мне еще далеко до управления технологиями в масштабах крупных компаний, но компетенции CTO необходимы, чтобы сделать следующий серьезный шаг в карьере.
Для CEO. У меня технический бэкграунд. Несмотря на выбор управленческого трека, уровень абстракции CEO от меня пока слишком далек.
Сравнив варианты, я решил думать наперед и изучить что-то принципиально новое, но не слишком далекое. Так что выбор пал на курс CTO.
Как устроен отбор на курс
Зачем вообще фильтр
Курс CTO длится девять месяцев, учеба идет в постоянных группах. Если кто-то сольется посередине, пострадает командная работа. Поэтому задача отбора — не «завалить», а пропустить только тех, кто реально готов вкладываться.
Этап 1. Письменные задания
Итак, вы дошли до этапа отбора. У вас на руках два задания объёмом по 5–15 тыс. знаков и один тест:
Эссе о мотивации. В нем вы должны сформулировать, куда вы идете и почему курс для вас — не странная прихоть, а реальная цель.
Управленческий кейс. Нужен затем, чтобы показать, как вы думаете в сложных ситуациях. Например, мой кейс — завод сломался, руководитель в отпуске: что делать сейчас и стратегически?
Тест зрелости. Быстрая диагностика ваших управленческих привычек.
На все это я уделял по 2–3 часа в течение четырех январских дней, и поймал легкие «университетские» вайбы. Правда, в отличие от универа, за такими заданиями сразу понимаешь ценность, зачем это делаешь.
Этап 2. Онлайн-собеседование
Собеседование представляло собой получасовой созвон с куратором, во время которого мы:
обсудили эссе и кейс;
оценили культурный мэтч;
обсудили вопросы по программе.
По факту — небольшая беседа, после которой мне прислали приглашение.
Что я почувствовал в процессе:
Самоанализ — вопросы из эссе подталкивают к четкой формулировке целей.
Кейс заставил подумОть — разбор кейса с «заводом» дал возможность копнуть в кризисы процессов, которые иногда случаются в реальной жизни. Когда они наступают, действовать нужно быстро и эффективно, и подобные кейсы помогают примерить роль «пожарника» на себя.
Фильтр на дисциплину — если вам лень написать 15к символов, то на марафон из 9 месяцев вас точно не хватит.
В общем, отбор помогает ответить самому себе на вопрос, насколько вам вообще подходит выбранный курс. Если вы достаточно мотивированы, чтобы потратить несколько часов на кейс, велика вероятность, что пройдете и отбор.
Структура обучения
Формат: трехдневные интенсивы (пт–вс) раз в 4 недели, 10:00–15:00 (МСК).
Длительность программы: 9 месяцев.
Каждый сессионный день делится на подтемы. Подтему закрепляем в 4 шага:
Теория (≈ 10-30 мин) – тренер делится базой по заданному блоку, не погружаясь в супер-глубокие подробности. Общая структура теоретического блока: «тема – ценность – цель – примеры – полезные ссылки».
Например, если сейчас вы изучаете виды оргструктур, то вам расскажут о них самих, о том, какие проблемы решает каждая, в чем их плюсы и минусы, а заодно поделятся литературой, которая поможет разобраться в вопросе досконально.
Индивидуальная рефлексия (≈ 10-15 мин). После теоретического блока вам дают кейс на подумать.
Например: «В компании X есть проблемы A, B, C. Вот ее оргструктура, которой рулят менеджеры с таким-то бэкграундом и опытом. Подумайте о том, какие изменения можно предложить».
Групповая дискуссия (≈ 15-20 мин). В начале курса вас делят на подгруппы по 6 человек. Этим составом вы будете выполнять каждое задание следующие 9 месяцев. Если вам группа не понравится, то вы можете ее сменить.
Мне с группой повезло: у каждого участника есть свой уникальный опыт, который оказывается релевантным практически к каждому кейсу. Я бы даже сказал, что значительная часть пользы от курса извлекается не из теории, а из такого кросс-опыления. Важно понимать, что не только преподаватели, но и каждый ученик курса — не просто рандом из интернета, а эксперт в своей сфере с многолетним стажем, у которого многому можно научиться, поэтому групповые обсуждения очень ценны.
Итого, сначала вы рефлексируете на тему кейса, а затем в зум-комнатах каждая группа должна принять общее решение и отправить ответ в гуглоформе. Для обсуждений в своей группе мы используем чатик в телеге и общую миро-доску.
Разбор + Q&A (≈ 10-15 мин). После заполнения ответов обновляется турнирная таблица и начинается общий разбор кейса. «Степень правильности» ответа группы зависит от того, насколько он похож на эталонное мнение эксперта. Это очень интересно, потому что идеальных решений не бывает, и мнение эксперта также можно интерпретировать по-разному. Поэтому этап разбора регулярно сопровождается спорами, а где споры, там и новые истины.
Между сессиями
Домашние эксперименты: в курсе нет домашних заданий, но вы можете поставить задачи самим себе. Например, попробовать внедрить инструменты, которые вы обсуждали на занятии.
Доп-материалы: каждый сессионный день сопровождается околобесконечным списком релевантной литературы. У вас всегда будет, что изучить дополнительно.
Созвоны команд: по желанию команды могут самоорганизоваться в дополнительные обсуждения: лекции, разборы кейсов, нетворкинг.
Сессия 1. Какими бывают CTO и чем они должны уметь управлять
Ценность сессии
Помогает понять, «какой вы CTO» и куда расти. Это стартовая точка: самоаудит, позиционирование в компании и прицел на дальнейшие модули.
Обзор
Первая сессия курса посвящена вопросу, какими бывают CTO. По аналогии с моделью PAEI Адизеса мы рассматривали модель Cto / cTo / ctO, в которой:
C — Chief (менеджмент)
T — Technical (технологии)
O — Officer (стратегия)
Комбинация прописных/строчных букв показывает фокус роли в разных типах компаний.
Если вы работаете в продукте, то вам, скорее всего, важно глубоко разбираться в технологиях, инфраструктуре, и архитектуре. Соответственно, в продукте вы «сТо». При этом требования как к менеджеру к вам ниже, чем к типичному «Ctо» из аутсорса, где вес менеджерских скиллов в матрице компетенций значительно выше, чем значимость глубокого погружения в технологии. А если вы работаете в бэкофисе, т.е. поддерживаете технологиями производство, то вам необходимо непрерывно продумывать цели и стратегию, которые будут обеспечивать смысл существования технического департамента. В этом случае вы, вероятно, будете “ctO”.
Проще говоря:
продукту нужен cTo;
аутсорсу — Cto;
бэкофису — ctO.
C опорой на эту модель мы рассмотрели матрицу компетенций CTO, которая включает целый ряд блоков: техника, архитектура, качество, инфраструктура, безопасность, people-менеджмент, продукт, риски, процессы, партнёры, HR, финансы, личные навыки, переговоры и стратегия.
Каждая из этих компетенций в той или иной степени нужна любому CTO, но их удельный вес будет варьироваться в зависимости от вашего профиля. А еще будут варьироваться подход к вашему онбордингу и практические шаги, которые вы будете предпринимать в компании.
Вы можете порефлексировать, составив матрицу компетенций для себя. По каждой компетенции ответьте на вопросы:
Какими навыками в рамках данной компетенции вы обладаете?
Что вам еще нужно изучить?
Что вы умеете / должны уметь / должны знать, но не обязательно уметь?
Выводы
Я четко увидел свой профиль Cto. Я работаю в аутсорсе, и через меня проходит очень много операционного менеджмента. При этом мне не так часто приходится погружаться в стратегию, и техника на фоне менеджмента тоже уходит на второй план.
Матрица компетенций очень помогла понять свои слабые стороны и выявить скиллы, которые мне нужно прокачивать в своей сфере.
Как я это применил
Раньше я недооценивал роль понимания структуры финансовых процессов в своих проектах. А недавно мне пришлось расследовать историю поступления оплат, в которую была зашита куча формул расчета ставок в зависимости от усредненных курсов валют, и вносить туда множество корректировок.
Может показаться, что эти формулы — довольно странная и нудная история, релевантная только на конкретном проекте. Однако в матрице компетенций CTO такие знания выделены в отдельный блок. Во-первых, это подчеркивает актуальность самой матрицы: она очень точно описывает домены, в которые на самом деле приходится погружаться. Во-вторых, это дает понять, что даже самые узкоспециализированные скиллы пригождаются неоднократно, и CTO должен ими обладать.
Сессия 2. «Делегируй или умри», инструменты делегирования
Ценность сессии
Учит масштабировать компанию без микроменеджмента: правильная оргструктура + инструменты распределения ответственности.
Обзор
В этом модуле мы рассмотрели разные виды оргструктур: плоскую, линейную, функциональную, проектную, матричную, дивизионную, сетевую.
Командный кейс был посвящен «реформированию» компании, которая росла и эволюционировала: меняла виды деятельности, обрастала продуктами, поглощала конкурентов, подвергалась реструктуризациям и оптимизациям. Все это оставляло след на ее структуре.
Три практических инструмента делегирования.
Если вы наращиваете зону ответственности, вам неизбежно придется снижать степень погружения в каждый отдельный контекст. Но как безопасно и эффективно абстрагироваться в управлении проектами, чтобы не потерять контроль? Для этого мы рассмотрели несколько инструментов:
-
RACI-матрица — разделяем Responsible и Accountable. Идея в том, что работа должна быть разделена на процессы, и за каждым процессом должны быть в явном виде закреплены следующие роли:
R — responsible. Ответственный, который отвечает за выполнение процесса, то есть непосредственно делает саму работу.
A — accountable. Вроде бы тоже ответственный, но разница принципиальна: корректнее перевести как “подотчетный”. Accountable отвечает за итоговый достигаемый результат вне зависимости от того, какие шаги и кто для этого выполнил.
C — counsulted. Это тот, кто обладает экспертизой и контекстом, чтобы с ним посоветоваться.
I — informed. Кого достаточно держать в курсе данного процесса.
Важно уточнить, что отдельная роль не всегда подразумевает отдельного человека. Для небольших задач один и тот же сотрудник может быть и responsible, и accountable; на более крупных проектах responsible может быть несколько. Главное, чтобы все участники процесса понимали, за кем какая роль закреплена.
«Светофор» метрик
Досадно, но наше время и внимание не бесконечны. Поэтому невозможно эффективно контролировать кучу контекстов, глубоко погружаясь в каждый из них.
Вместо этого контексты можно покрыть метриками и условно разделить на зеленую / желтую / красную зоны. С такой системой можно будет погружаться в процессы только тогда, когда показатели начнут выходить за допустимые пределы.
Вы должны сами определить перечень метрик, диапазоны и стратегии эскалации. Важно соблюсти баланс: метрики должны покрывать контекст с разных сторон, и в то же время их не должно быть слишком много.
Кстати, для покрытия контекстов метриками не обязательно изобретать велосипед. Например, существует удобный фреймворк метрик PROJECT (в контексте управления проектом расшифровывается как «People, Reliability, Operations, Job, Economy, Customer, Timetable»). Если вы не знаете, с чего начать, рекомендую почитать про него.
Делегирование через бюджет. Важно понимать, что бюджет — это не только деньги. Это сочетание ресурсов и ограничений в широком смысле: деньги / время / команда / сервисы и т.д. Идея в том, что вы достигаете результата НЕ через управляющие воздействия, а с помощью описания ожиданий, выделения ресурсов и введения ограничений.
Например, у вас есть три месяца и X денег, чтобы запустить пилот, который решит бизнес-задачу. Вы вольны делать что угодно: нанимайте, увольняйте, пишите код, проводите исследования — не важно. Важно, что через три месяца будет решаться вопрос о том, получит ли этот проект продолжение.
Выводы
Важно помнить, что не существует идеальной оргструктуры: это постоянное «переставление палочек дженги».
Делегирование — фрактал: ответственность должна распределяться предсказуемо и четко, а не распыляться рандомно между участниками процесса.
«Светофор» экономит внимание. Нужно стремиться к системе, в которой СТО смотрит на дашборд 5 секунд и понимает, вмешиваться или нет.
Как я это применил
Из этих инструментов я успел опробовать только RACI-матрицу. Не буду вдаваться в подробности, но недавно во время декомпозиции проекта по RACI я заметил, что у некоторых процессов вообще не было Accountable. По «удивительному» совпадению эти процессы оказались самыми проблемными.
Дальше я планирую внедрять метрики PROJECT. Сейчас мы уже проводим healthcheck, но хочется, чтобы его результаты выражались в числах, сбор данных был автоматизирован, а наблюдение можно было бы делать с помощью дашбордов.
Пока что хочется оцифровать несколько показателей: попадание в цели спринта (по закрытым задачам), здоровье команды (по опросникам и ретро), обратную связь от заказчика (по опросникам) и точность попадания в прогнозируемые затраты (по счетам). Когда буду готов поделиться опытом внедрения метрик, напишу и об этом.
Сессия 3. Процессы — баланс хаоса и бюрократии
Ценность сессии
Дает инструменты формализации работы в быстрорастущей компании и закрывает первый блок курса.
Обзор
Процессы важны, чтобы удерживать баланс между доменом, культурой, неопределенностью, рисками, ресурсами, внешними ограничениями, связями с другими системами и их целями.
Универсальных процессов не бывает. Попытки повторить чужой успех превращаются в карго-культ, который не дает результата. Нужно найти баланс — не слепо копировать, а уметь декомпозировать шаблонный процесс, взять из него только те части, которые принесут пользу здесь и сейчас или в ожидаемой перспективе.
В этом модуле мы рассмотрели факторы, которые влияют на процессы, а также подходы по их внедрению. В статье я не буду погружаться в детали, а просто зафиксирую основные положения.
Что влияет на процесс:
степень строгости / гибкости;
стабильность / изменчивость;
простота / сложность;
цена ошибки.
Как внедрять:
Зафиксировать план и лидера изменений.
Обучить участников, подготовить артефакты.
Декомпозировать, выявить узкие места, приоритизировать.
Избегать субоптимизации: оптимизировать только то, что наиболее эффективно приближает к цели.
Проводить постоянную рефлексию и корректировку.
Выводы
Наверное, самая важная мысль, которую я осознал по итогам этой трехдневки — ценности важнее процессов.
Процессы важны. Но если пытаться зарегулировать ими всё, то на их поддержание будет уходить слишком много ресурсов. Чрезмерная строгость процессов компенсируется отсутствием общего понимания, что вообще происходит, и к чему нужно идти.
В первую очередь каждый участник производства должен не просто выполнять алгоритм по шагам. Он должен понимать не только свои, но и общие цели, и валидировать каждое свое действие через вопрос: приближает ли очередной шаг к общей цели всю команду, и если да, то как именно?
И еще несколько важных инсайтов:
поддержание процесса — это непрерывная работа. Его нельзя один раз настроить и забыть;
идеального рецепта нет, но игнорировать процессы невозможно. Без них рост обернется хаосом;
главное — держать баланс. Бюрократия убивает скорость, а анархия — надежность.
Как я это применил
Сейчас мы делаем очень нетипичный проект со сложной логикой, где нет общепринятых идеальных подходов. Каждая фича в проекте едет по процессам: аналитика → дизайн → разработка → QA → поставка → поддержка. Каждый участник команды также делает задачи по процессам.
Но в какой-то момент мы осознали, что по отдельным сложным трекам помимо продакт-менеджера и руководителя разработки нет человека, который от начала и до конца понимает, что это вообще за фича, почему она такая и куда будет развиваться.
В общем, процессы есть, а понимания ценности — нет. Результат — деливери замедлился, мы стали медленнее работать, иногда совершая шаги в неверном направлении.
В итоге мы пришли к внедрению практики фича-лидинга. Фича-лид — это инженер, который отвечает за «успех» фичи. Вне зависимости от того, как устроен процесс, он должен понимать ценность каждого изменения в своей зоне ответственности и обеспечивать ожидаемый результат, предлагая изменения там, где это нужно.
Также мы ввели регулярные workshop-сессии в команде, где стали подробно разбирать будущие фичи и вместе с заказчиком и инженерами принимать по ним продуктовые решения.
Эти две активности стали частью нашего процесса. Они нужны в первую очередь для того, чтобы донести до каждого участника команды ценность изменений.
Заключение
Первые три месяца оказались очень результативными. Впереди — новые модули, а я продолжаю красить свою матрицу компетенций и проверять на практике RACI, светофоры и процессные чек-листы. Если где-то будут сложности — честно расскажу. Stay tuned!
Минутка саморекламы
В своем ТГ-канале Vitaly’s Insights я раз в месяц подробно рассказываю о каждой трехдневке. Подписывайтесь и задавайте вопросы, обязательно отвечу!
А на Хабре я уже не раз писал статьи о том, какие скиллы нужно наращивать и разработчикам, и лидам. Выбирайте, что для вас актуально, и читайте:
про харды (для фронтендеров) — Не JavaScript’ом единым: как фронтенд-разработчику затащить на собесе
про софты (для всех) — Матрица soft skills: как вырасти от стажера до синьора