Привет! Меня зовут Виталий, и я управляю проектами в KTS.
Последние несколько месяцев довольно круто изменили специфику моей работы. Еще недавно я был тимлидом команды фронтендеров, и следующим этапом в моей карьере стала роль директора проекта.
По счастливому совпадению в прошлом феврале я попал на курс СТО от Стратоплана, о чем рассказывал на Хабре в своей предыдущей статье. На курсе я взаимодействовал с бывшими и действующими техдирами крупных компаний, работал с ними в командах, обменивался с ними опытом.
Параллельно в моей работе появилось намного больше бизнес-составляющей. Теперь я не только обеспечиваю производство и развитие команды, моя ответственность состоит в верхнеуровом развитии аккаунта: пресейл, формирование и развитие команды, найм, обеспечение деливери, контроль маржинальности и апсейл.
Сегодня я хочу поделиться своими инсайтами, которые я извлек из обучения, и которые помогли мне сделать следующий шаг в моей карьере. Эта статья будет вам полезна, если вы тимлид и вам хочется понять, куда двигаться дальше (или если вы уже CTO и хотите узнать, какие блоки своего профессионального трека стоит усиливать).
Оглавление
Обзор
Как я уже отметил во введении, моя предыдущая статья была посвящена началу обучения в Стратоплане. Мне предложили пройти любой курс и написать серию статей об этом опыте. В прошлый раз я рассказал о том, из каких курсов я выбирал, как был устроен отбор кандидатов и как прошли первые модули, посвященные областям компетенций CTO, инструментам делегирования и организации процессов.
Сегодня мы погрузимся в контент следующих трех модулей. Я расскажу:
об особенностях конструктивной коммуникации, в том числе с партнерами и топ-менеджерами;
об управлении закупками и работе с подрядчиками (а также коснемся темы легаси, от которого никуда не деться);
об операционном менеджменте и подходе DDM (Data Driven Management).
В каждом разделе я буду делиться материалами с курса и своими выводами.
Коммуникация
Встречное предложение
Одной из важнейших для меня тем в рамках модуля, посвященного коммуникации, стал алгоритм «встречного предложения». Он помогает структурировать и повысить шансы на успех диалога в случаях, когда его стороны придерживаются разных взглядов или когда их цели противоречат друг другу. В основе алгоритма лежит простая идея — слушать собеседника, уважать его позицию и валидировать свое понимание. Рассмотрим, как это работает.
Представим ситуацию: в вашем департаменте возникла потребность автоматизировать процесс. Ваш руководитель предлагает разработать собственное решение; вы же считаете, что в вашем случае оптимальнее использовать SaaS.
Руководитель озвучивает следующие тезисы:
у инхаус-команды есть опыт разработки похожих автоматизаций, поэтому проект можно реализовать своими силами;
готовые SaaS-решения не закрывают все потребности, кастомизация недостаточно гибкая.
Вы знаете, что у вашей команды был опыт в похожих проектах, и проприетарная разработка вам действительно под силу.
В то же время вы понимаете, что у коман��ы не хватит ресурса, так как разработчики уже заняты на других проектах и не освободятся в следующие несколько месяцев. Еще вам известно, что DevOps-инженерам тоже не хватает рук — неочевидно, кто будет поддерживать новую автоматизацию. Как вы донесете свои возражения?
Вы можете высказать их прямо и надеяться, что будете услышаны. Например, так:
«Я не согласен, потому что ресурс наших разработчиков уже запланирован на ближайшие полгода, и прибыль с коммерческих проектов будет выше, чем выгода от внедрения автоматизации. И я сомневаюсь, что нашим админам хватит сил на поддержку нового решения. Все-таки стоит остановиться на SaaS и смириться с тем, что некоторые этапы процесса мы продолжим закрывать вручную.»
Но шансы на успех невелики, так как подобная формулировка может вызвать отторжение. Даже если ваши аргументы верны, в эмоционально окрашенном контексте их будет сложнее услышать.
Алгоритм «встречного предложения» делает конфронтацию конструктивной. Он предлагает следующую структуру диалога:
Выслушайте позицию и аргументацию собеседника.
Установите контакт и понимание:
выразите признательность (не шаблонное «спасибо за то, что вы пооткрывали рот», а искреннюю благодарность. Помните, собеседник готовился к этому разговору и проводил предварительный анализ, без этого между вами не сложился бы продуктивный диалог);
задайте 2–3 открытых вопроса к тезисам, которые вызвали у вас непонимание или сомнение;
убедитесь, что вы действительно поняли позицию собеседника.
Выразите согласие и проговорите свои аргументы. Именно в такой последовательности. Когда ваши тезисы звучат как продолжение логики оппонента, а не как ее противопоставление, ему проще их воспринимать. Например, взгляните на такую формулировку:
«Я согласен, что наша команда разрабатывала похожие платформы, и я разделяю идею о том, что решения на рынке недостаточно гибкие для наших задач.
И вместе с этим я знаю, что ресурс наших разработчиков не освободится в ближайшие полгода, а платформу нужно внедрять уже в конце следующего квартала.
Более того, после внедрения администраторам также потребуется выделить ресурс на сопровождение этой платформы, и админы не уверены, что к этому моменту они успеют нанять нового инженера в свою команду.»
Думаю, вы и сами вероятнее согласитесь с такой подачей, чем с фразой «Нет, я не согласен, потому что ни у нас, ни у админов нет на это времени.»Проговорите встречное предложение и выгоды для другой стороны. В нашем примере это может звучать так:
«Поэтому я предлагаю отдать разработку новой платформы на аутсорс. Тогда платформа будет отвечать запросам бизнеса и полностью принадлежать нам, а наши разработчики смогут остаться на текущих коммерческих проектах и продолжат приносить прибыль. А пока админы не наймут нового сотрудника, аутсорс-команда сможет взять поддержку платформы на себя.»
Заметьте, суть сказанного не изменилась — вы поделились своими возражениями и вынесли на обсуждение вариант, потенциально выгодный как для собеседника, так и для вас (пресловутый win-win). Но шанс достижения желаемого результата заметно выше, чем в случае открытой борьбы аргументов.
Отличие в том, что в таком разговоре вы лучше понимаете эмоции вашего собеседника и, что важнее, управляете своими. Умение выбирать эмоциональное состояние — это следующая степень свободы. Такая же, как умение выбирать одежду, еду, литературу, гражданскую позицию, техническое решение и так далее. И именно она позволяет вести диалог в русло обоюдной выгоды.
Коммуникация с топами
Стоит сделать акцент на особенностях коммуникации с топ-менеджерами. Чем выше грейд человека, с которым вы разговариваете, тем меньше у него времени и тем больше он ценит конкретику. Поэтому важным навыком становится умение «мэтчиться» по уровню абстракции — давать ровно тот объем деталей, который нужен собеседнику здесь и сейчас, не уходить в лишние подробности, но и не оставаться слишком поверхностным.
Формирование доверия
Отдельный блок модуля был посвящен доверию — тому, как оно возникает и как его выстраивать в рабочей среде. Мы разбирали доверие сразу в трех горизонтах: краткосрочном, среднесрочном и долгосрочном, потому что механика в каждом случае заметно отличается.
Краткосрочное доверие — самое хрупкое и самое быстрое. Оно формируется буквально за доли секунды и держится на ощущении «ты такой же, как я». Чтобы это доверие завоевать, крайне важно во время презентации своей мысли подстраиваться под архетип собеседника и апеллировать к выгоде для него. При этом нужно самому верить в то, что вы говорите, и проявлять эмпатию — слышать потребности другой стороны переговоров.
Важно помнить, что хорошая подстройка — это не «хамелеонистость» и притворство, а искреннее желание показать человеку, что вы уважаете его мировоззрение и его способ быть, и готовы для него и во время общения с ним постараться быть более понятным и близким ему, разделить его ценности.
Среднесрочное доверие строится уже дольше — от одной встречи до пары полноценных диалогов. Оно появляется, когда у собеседника формируется ощущение «у нас много общего» и «ты можешь быть полезен». Чтобы такое доверие возникло, важно уметь рассказывать о себе, обозначать опыт, делиться рекомендациями и примерами проектов, вовлекать в совместные активности, находить общие темы. Иногда помогает элементарное человеческое взаимодействие: помочь, рассмешить, заинтересовать, попросить об услуге. Все это создает ощущение реального контакта.
Долгосрочное доверие формируется от нескольких недель до года и базируется на том, насколько ваши слова совпадают с действиями. На этом уровне важно управлять ожиданиями в разговоре и соблюдать дисциплину выполнения обещаний. Если договоренности исполняются, то доверие укрепляется. Если нет — оно разрушается намного быстрее, чем строилось.
Мои инсайты
Сам я считаю себя довольно открытым человеком. У меня нет сложностей с коммуникацией, и поэтому я бы не сказал, что эта тема открыла мне глаза на принципиально новые вещи. Но практи��еские задания модуля показались мне действительно полезными, потому что они помогли мне сформулировать и осмыслить принципы, которые раньше я воспринимал только на интуитивном уровне.
Что еще важнее — теперь я могу прокачивать свою команду, предлагая им структурированную выжимку на тему «почему общаться важно, и как это делать эффективней». Мне кажется, такие обучения особенно ценны для IT, где многие инженеры интровертны по натуре, и им априори нелегко коммуницировать. Отсюда часто растет разрыв между «инженерами» и «бизнесом», хотя в моем представлении такой грани быть не должно, поскольку инженеры — неотъемлемая часть бизнеса, а не black-box команда где-то сбоку.
Наверное, самая ценная мысль, которую транслирует это блок — любая эффективная коммуникация строится на доверии.
Приведу пример из своей работы. Я регулярно участвую в презентации коммерческих предложений. В общем случае моя работа состоит в том, чтобы убедить незнакомого человека заплатить нам кучу денег за работу, финальный результат которой он увидит минимум через несколько месяцев. Конечно, все финансовые риски для заказчика покрывает договор, но есть еще и бизнесовые риски: я должен убедить заказчика, что именно с нами в ожидаемый срок будет поставлен необходимый результат, и что вместе с нами этот результат будет:
релевантен;
достаточен, но не чрезмерен;
бюджет израсходован рационально.
У нас в KTS за годы работы накопилось портфолио из сотен проектов в совершенно разных доменных областях. Когда мы готовим презентацию, мы выбираем только н��иболее релевантные кейсы. Это помогает построить то самое краткосрочное и среднесрочное доверие.
Более того, релевантность проявляется не только в учете требований заказчика, но и в совпадении с его духом. Если вы общаетесь со стартапом, важна скорость принятия решений и гибкость. Если вы общаетесь с корпорацией, важна структурированность процессов и строгость в соблюдении скоупа. Бывают инженерные решения, где в первую очередь важна архитектура и техническая составляющая. А есть сервисы, в которых важнее всего дизайн и UX, которые заставят пользователя «влюбиться» в полученное решение.
Бывают погруженные клиенты, которые точно знают, чего хотят, а есть более отстраненные, которые хотят просто решение своей задачи, но при этом нуждаются в вашей помощи даже при ее формулировании. И при подготовке КП важно понять, с кем вы общаетесь, чтобы презентовать именно ту часть вашего опыта, которая больше всего попадает в цели и потребности заказчика.
Если вам удалось сформировать среднесрочное доверие и вы начали сотрудничать, важно укрепить долгосрочное доверие. Для этого следует поддерживать максимально прозрачные процессы, регулярно транслировать результат, синхронизироваться в целях и самое главное — исполнять взятые на себя обязательства. Все это невозможно без развитого эмоционального интеллекта и искреннего вовлечения в решение задачи.
Мой пример относится к области продаж, но эти же принципы можно экстраполировать и на любой другой акт коммуникации: на собеседование и работу в компании, на найм сотрудника и дальнейший его путь в вашей команде, на взаимодействие с внешними подрядчиками. Словом, это подходит для любой рациональной коммуникации (т.е. той, у которой есть цель).
Инфраструктура
В рамках модуля об управлении инфраструктурой мы разобрали много аспектов: от работы с легаси и вендорлока до стандартов надежности ЦОДов. И если последняя тема слабо связана с моей текущей зоной ответственности и интересов, то многие другие нюансы оказались действительно полезными для меня. О них и поговорим ниже.
Риски
Legacy
Легаси принято воспринимать как проблему, однако в действительности это скорее не «плохо», а «неизбежно». Легаси — естественное следствие развития продукта и бизнеса. Если в компании есть история, изменения, рост и накопленные решения — значит, где-то обязательно будет и легаси. И от него никуда не деться.
Во-первых, систему бывает сложно заменить по частям, особенно если она не разделена на микросервисы. Часто ее приходится обновлять целиком, а это большие риски и затраты. Иногда на доработки не хватает времени, а иногда велика вероятность нарушить работающий бизнес-процесс. Бывает и так, что у компании нет опыта работы с актуальными технологиями, либо рынок не предлагает достойных аналогов.
Кроме того, не всегда очевидно, что текущее решение вообще требует обновления: возможно, оно все еще справляется со своей задачей и менять его нет смысла. В итоге чем старше и крупнее компания, тем больше подобного наследия накапливается — это нормальный жизненный цикл любой сложной системы.
Vendor-lock
Вендор-лок — это ситуация, в которой компания жестко привязана к технологии, продукту или поставщику, что создает риски: лицензии могут внезапно вырасти в цене или перестать продлеваться; поставщик может уйти с рынка, закрыться, изменить правила лицензирования или перестать поддерживать продукт, сосредоточившись на новых проектах.
При этом переход на другую технологию почти всегда связан со значительными трудозатратами, поэтому полностью избежать вендор-лок практически невозможно.
Чтобы снизить риски, можно придерживаться следующих принципов:
по возможности выбирать решения, у которых есть конкуренты, чтобы оставить пространство для маневра;
проектировать системы так, чтобы их можно было относительно безболезненно разворачивать на разных платформах;
регулярно мониторить рынок и отслеживать новые продукты, которые могут заменить текущие;
время от времени запускать пилоты: тестировать новые технологии в небольших масштабах, чтобы заранее понимать, на что можно перейти в случае необходимости.
Работа с рисками
Технологический радар
Для митигации рисков, проистекающих из легаси и вендорлока, необходимо держать руку на пульсе, регулярно изучать рынок, тестировать аналоги и стараться не строить свою архитектуру вокруг единственного решения. На курсе с нами поделились подходом, который помогает решать эту задачу. Он называется «Технологический радар».
Его идея заключается в том, что в релевантных для вас областях вы поддерживаете структурированный реестр решений. Его можно визуализировать в виде круга, разделенного на следующие четверти:
инструменты;
платформы;
технологии;
языки программирования и фреймворки.
Этот же круг разделен на радиусы adopt, access, hold и trial. В каждой четверти решения сгруппированы следующим образом:
adopt — решения, которые активно применяются в вашей компании;
access — решения, на которые стоит обратить внимание, но пока рано применять в проде;
hold — решения, которые теряют для нас актуальность;
trial — решения, которые можно протестировать и уже безопасно пробовать для продакшена.
В частности, систематически и регулярно поддерживая актуальность техрадара в своей компании, вы можете существенно снизить вероятность вендор-лока.
ITAM
Следующей итерацией структурирования контроля над технологиями в вашей компании сможет стать ITAM (IT Asset Management) — подход к управлению цифровыми активами. Если техрадар полезен при формировании технологической стратегии, то ITAM удобен для операционной деятельности. Фактически он нужен, чтобы понимать, какие технологии и где вы применяете, на каком этапе жизненного цикла в компании они находятся от внедрения до ремонта и списания, и как эти технологии связаны между собой. ITAM повышает прозрачность и управляемость системой и позволяет оптимизировать расходы за счет выявления избыточных или низкоэффективных активов.
Универсальные и кастомные технологии и процессы
Вернемся к вопросу, которого я коснулся в примере к блоку о коммуникациях — когда стоит разрабатывать свое решение и внедрять уникальный процесс, а когда проще и разумнее взять что-то готовое. Опираясь на существующие инструменты и на решения, которые вы принимаете, нужно ответить на следующие вопросы:
Насколько срочно вам нужно это решение?
Вы решаете уникальную или типовую задачу?
Является ли решаемая задача фокусом вашей деятельности, или это сайд-активность?
Какая у решения стоимость внедрения и эксплуатации?
Есть ли у вас компетенции и ресурсы для развития собственного продукта?
Отвечая на эти вопросы, вы можете решить, стоит ли разрабатывать свою технологию, или лучше купить коробку, предложенную рынком.
К слову, при внедрении новых процессов стоит задаваться аналогичными вопросами. Здесь я вижу два вектора:
Подстраивать систему под процесс.
Кастомизировать процесс под вашу систему.
Скорее всего, оптимальным выбором будет что-то гибридное: идея существующей методологии позволит структурировать наименее упорядоченные части вашей работы. При этом специфичные части вашей деятельности может быть разумно описать уникальными рамками процесса.
И главный комментарий по этой теме: при выборе и процессов, и технологий важно избежать карго-культа. Ни в процессе, ни в технологиях нет ценности. Важно лишь то, с какой эффективностью с их помощью вы достигаете поставленной цели.
Закупки и подрядчики
Время от времени имеющихся инструментов и технологий перестает хватать для закрытия потребностей бизнеса, и привлечь внешние ресурсы для решения задачи бывает дешевле, чем работать над ней своими руками. В такие моменты перед руководством встает задача по производству или закупке новых необходимых товаров, материалов и услуг. И когда эта задача касается технологий, она ложится на плечи CTO; следовательно, в его область компетенций обязательно входит навык управления закупками.
В общем случае процесс выглядит следующим образом:
Планирование:
решение о закупке — фиксация самого факта необходимости;
задание на закупку — формирование ТЗ, причем не ��ля подрядчика, а для представителя команды заказчика, который будет взаимодействовать с подрядчиком;
закупочная документация — все материалы, которые описывают будущую закупку (требования, контекст, спецификации, юридические рамки, предварительные оценки бюджета);
критерии выбора подрядчика.
Проведение:
запрос предложений — выход с заказом на рынок и сбор КП от потенциальных подрядчиков;
выбор подрядчика;
контрактинг — самый важный этап, о нем ниже.
Контроль:
контроллинг — своевременные проверки соответствия контракту, соблюдения сроков, корректности промежуточных результатов;
изменения — работа с непредвиденными обстоятельствами, фиксация изменений в заданиях, согласование и принятие решений.
Закрытие, оно же приемка. Заказчик проверяет, соответствует ли работа требованиям, закрыт ли скоуп, соблюдены ли сроки и качество — словом, выполнены ли все обещания.
Контракт
A.k.a. ядро закупочного процесса. Контракт формализует выбор подрядчика и фиксирует требования: сроки, стоимость, скоуп, качество и любые другие параметры. Он описывает риски и способы их смягчения, задает основание для контроля и приемки работ, а также служит базой для обсуждения любых изменений в процессе.
Соответственно, правильный контракт — это значительная часть качественной закупки. Чем точнее и прозрачнее он составлен, тем меньше конфликтов и недопонимания возникнет по ходу работы. Контрактинг является полноценной практикой, на которую следует делать особый акцент при развитии управленческих компетенций.
Мои инсайты (и мой опыт)
В моем опыте в большинстве случаев именно я являюсь представителем подрядчика. Этот блок оказался особенно релевантным для меня, поскольку он дал мне взгляд со стороны на то, по каким критериям нас выбирают. Следовательно, мне стало яснее, как тюнить наши преимущества и как выстраивать маркетинговую стратегию, каким клиентам мы можем быть полезны.
Одна из идей, презентованных, в этом блоке заключается в том, что корпорациям полезно создавать пулы подрядчиков, сгруппированные по задачам, которые они решают. Например, с распределением по скорости, качеству и стоимости работы:
Дешево, быстро, но не очень качественно — для быстрой проверки гипотез, не требующих креативного подхода;
Быстро, качественно и дорого — для решения срочных сложных инженерных задач (сюда можно отнести разработку сложных систем, кризис-менеджмент, технический аудит);
Качественно и недорого, но долго — для долгосрочных решений, которые к тому же не горят по срокам.
Также можно распределять подрядчиков по компетенциям: веб, мобильная разработка, ML, инжиниринг, узкопрофильные или широкопрофильные команды.
Еще одна важная тема, которую мы обсудили — варианты контрактов, их преимущества и недостатки для подрядчика и для заказчика:
Fixed price — модель, при которой стоимость контракта фиксирована. Чем выше неопределенность, с которой предстоит работать, тем выше риски для подрядчика. Следовательно, с этими рисками нужно уметь работать и закладывать их в предварительную оценку и стоимости. Подходит для краткосрочных проектов с фиксированным скоупом.
Time & material — в этой модели оплата происходит за фактически выполненный объем работ (например, с учетом почасовой оплаты команды). Здесь с ростом неопределенности рискует именно заказчик. Time & Material подходит для долгосрочных проектов с неограниченным скоупом. На практике, для того, чтобы все-таки повысить определенность при работе по T&M, проект делят на итерации и блоки, после которых происходит пересогласование бюджета. И в рамках каждого T&M-блока есть согласованный потолок, т.е. подрядчик работает по T&M, но может потратить не больше фиксированной суммы.
Гибридная модель — подразумевает фиксировнный скоуп, но не исключает дополнительные работы, которые будут оплачены уже по факту.
Data driven management
С модуля про DDM (принятие решений на основании измеримых данных) я тоже вынес несколько полезных инсайтов. Оказалось, например, что пирамида — это не только схема Понци, но еще и удобная модель для операционного менеджмента.
Пирамида операционного менеджмента
(взято из материалов курса)
В основании пирамиды лежат сотрудники и их показатели. Количество комментов и итераций на код-ревью, закрытые тикеты — пригодится все, что действительно помогает вам оценивать эффективность, загрузку и динамику развития сотрудников.
Как правило, здесь не выйдет подсмотреть готовое решение у других команд. KPI необходимо выводить самостоятельно, экспериментальным путем, поскольку каждый коллектив имеет свои особенности. Но есть несколько принципов, которых стоит придерживаться при его формировании:
показатели должны быть связаны между собой;
показатели должны быть релевантны;
сотрудник полностью влияет на KPI, показатель находится в его зоне контроля;
за KPI стоит мотивация:
KPI достижим;
если у двух сотрудников противоположные KPI, у руководителя должен быть KPI на разруливание конфликта.
Курс предлагает еще несколько правил из того же ряда, однако именно эти показались мне основными.
Хочу заострить внимание на том, что с KPI стоит работать очень аккуратно, если вы занимаетесь не механическим трудом, а творческой деятельностью. Есть риск сделать из вовлеченных членов команды роботов, которые не нацелены на решение проблемы, а борются за достижение формальных показателей.
На втором уровне операционки находятся метрики здоровья проектов. В этой области тоже нет недостатка в фреймворках, поэтому я приведу два примера:
Модель PROJECT (которую я уже упоминал, но не раскрывал в прошлой статье):
P → People — команда проекта и ее состояние;
R → Reliability — надежность, качество;
O → Operations — операционные показатели;
J → Job — состояние скоупа;
E → Economy — финансовые показатели;
C → Customer — удовлетворенность клиента;
T → Timetable — расписание (сроки).
Модель HEART:
H → Happiness — польза для клиента;
E → Engagement — вовлеченность ЦА;
A → Adoption — привлечение клиентов;
R → Retention — удержание клиентов;
T → Task Success — успех продукта.
Удобство этих фреймворков в том, что с ними всегда можно свериться и убедиться, что вы ничего не забыли учесть. И практика показывает, что этих показателей достаточно для принятия взвешенных решений.
Буква C в модели PROJECT раскрывает следующий уровень пирамиды — удовлетворенность клиента. Даже сбор оценок по пятибалльной шкале позволяет определить качество предоставления продукта за конкретный период. Но чем более развернутый фидбэк вы можете получить, тем лучше.
Сбор фидбэка следует проводить регулярно, например, 1 раз в 2-6 недель, дополнительно «замеряя температуру» после каждого кризиса.
На практике мы постоянно собираем фидбэк от всех клиентов (регулярность зависит от проекта), и это реально помогает подсветить точки роста. Но не стоит забывать, что фидбэк указывает именно на проблему, а не ее корневую причину. Корень нужно выявлять отдельно и работать над его исправлением. Нам в этом помогают коллективные брейнштормы — мы собираемся командой лидов и анализируем, как скорректировать наши действия, чтобы улучшить фидбэк.
И четвертый уровень пирамиды, ради которого все и затевалось — деньги. Но какие деньги стоит считать? Выручку? Не только. Курс от Стратоплана предлагает следующую памятку по основным финансовым показателям:
LTV клиента;
Отток (не сами деньги, но их интеграл);
Лояльность → Стоимость удержания клиента (CRC);
Сарафан → Стоимость привлечение клиента (CAC).
От себя хочу уточнить, что универсальных финансовых показателей не существует, и на каждом уровне абстракции они будут отличаться. В своей работе я чаще всего руководствуюсь маржинальностью — как отдельных проектов, так и группы.
Каждый уровень пирамиды зависит от предыдущего. Без эффективной работы сотрудников не будет здоровых проектов, без здоровых проектов не будет довольных покупателей, без довольных покупателей не будет денег. И каждый уровень — это не дихотомия, где результат либо есть, либо его нет. Каждый уровень можно оцифровать и замерять в динамике. И если это делать, то принимать эффективные решения будет намного проще, чем при использовании метода научного тыка.
Финансовые модели и бюджет
И раз уж речь зашла о деньгах, мы можем перейти к финальной теме, на которой я хотел бы сегодня остановиться: зачем CTO считать деньги.
Следует понимать, что управление бюджетом — это не отдельная функция финансового отдела, а полноценный управленческий инструмент. Для CTO работа с бюджетами — такой же обязательный навык, как контрактинг и коммуникация.
Для меня этот блок оказался супер релевантным, потому что наша модель работы фактически строится на непрерывном подсчете денег и маржинальности. Консалтинг зарабатывает продажей профессиональных услуг, которые выполняются людьми. Это значит, что выручка и, следовательно, прибыль пропорциональна размеру команды, вместе с которым растет и ФОТ.
С двумя моделями, которые разбирались в этой секции, любой руководитель в аутсорсинге работает практически ежедневно:
Первая модель, P&L (Profit & Loss) — фактически регулярно обновляемая табличка с кучей параметров, которая в конечном счете позволяет считать выручку и вычитать из нее затраты, где итоговый показатель — это прибыль, которая должна стремиться к целевой маржинальности.
В секции выше я упоминал про контроль затрат в рамках проекта. P&L же нужна, чтобы считать затраты в рамках юнита, контролируя и маржинальность в рамках отдельных проектов, и совокупную для группы проектов. Отслеживание P&L показывает, когда нужно перераспределить ресурсы, где сфокусировать больше внимания.Вторая модель, которую также подробно рассмотрели на курсе – Cash Flow — в моей практике применяется реже, но она не менее важна. Фактически CF нужна, чтобы строить прогнозы денежных потоков и, как следствие, принимать управленческие решения для выхода на целевую маржинальность. Например, в консалтинге с помощью CF можно рассчитывать и прогнозировать ставки специалистов с учетом налоговой нагрузки, непроизводственных затрат, планируемых повышений, роста штата и оплачиваемых простоев (отпуска, больничные, обучение и т.д.).
P&L нужна для расчета полученной прибыли, а CF фокусируется на реальном движении средств с учетом кассовых разрывов. На мой взгляд, второй показатель лучше подходит для построения финансовых моделей и выделения оптимистичных/пессимистичных сценариев на интервалах от нескольких месяцев до нескольких лет (с разной точностью, конечно).
Итоги
Курс от Стратоплана возник в моей жизни как нельзя кстати — благодаря ему я очень вовремя стал осваивать те навыки, которые пригождаются мне в работе. Хорошо знакомые мне доменные области (вроде коммуникации и закупок) раскрылись для меня с новой стороны и приобрели системность. А те области, с которыми я был знаком опосредованно (финмодели, работа с инфраструктурными рисками), я начал понимать глубже.
Отдельно для себя я отметил, насколько сильно роль CTO смещена в сторону бизнеса. Деньги, маржинальность, P&L, бюджетирование — это все зона ответственности СТО. От этой области не получится убежать даже тем, кто считает себя в первую очередь техническим руководителем, а не менеджером и не стратегом (то есть «cTo» по классификации из предыдущей статьи).
Если вы тимлид и чувствуете, что вам становится тесно в текущей роли, этот путь может оказаться для вас релевантным. Если вы уже CTO, возможно, некоторые блоки помогут подсветить зоны роста или переосмыслить привычные практики. А если вы просто интересуетесь тем, как устроено управление в IT за пределами кода, надеюсь, эта статья дала вам полезный срез реальности.
Какие еще компетенции следует развивать людям, которые стремятся к роли CTO, я расскажу в следующей статье (она будет заключительной в серии материалов о курсе Стратоплана). А пока оставлю ссылки на статьи моих коллег, которые также делятся на Хабре своим опытом в управлении:
Как дать разработчикам свободу при деплое приложений и ускорить процессы в команде
Планировать нельзя сойти с ума: как не забыть ни про проекты, ни про людей
Что происходит с собеседованиями QA в 2025 году? Взгляд с обеих сторон баррикад
Я управляю тестированием ИИ-моделей 4 года. Что я понял за это время?
