Технический директор. Эффективное техническое лидерство

Процесс планирования по умолчанию

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

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

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

• Команды несут ответственность за выполнение квартального или полугодового плана, используя методы по своему выбору (например, Scrum или Agile).

• Возможен ежемесячный контроль за выполнением планов, например бизнес-ревью (https://infraeng.dev/business-review-template), чтобы отслеживать прогресс в достижении целей компании.

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

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

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

• финансовый партнер прекратил свою деятельность;

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

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

Три этапа планирования

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

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

Этот план устанавливает цели по доходам и расходам, разбитые по выполняемым функциям и направлениям бизнеса. Из него вы сможете понять соотношение инвестиций в исследования и разработку (R&D); продажи и маркетинг (S&M); общие и административные расходы (G&A), а также увидеть распределение финансов по продуктам или бизнес-юнитам компании.

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

Оформите его как кросс-функциональное соглашение об объеме и сроках выполнения работ.

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

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

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

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

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

Этап 1. Составление финансового плана

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

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

Рис. 4.1. Образец финансового плана

Например, образец плана на рисунке 4.1 показывает, что направление бизнеса B2C растет на 31 % в годовом исчислении, у него $133 млн расходов на $625 млн выручки в первом квартале. Напротив, корпоративный сегмент B2B растет гораздо быстрее – на 95 % в годовом исчислении, но имеет $96 млн расходов при $52 млн выручки в первом квартале. Глядя только на эти две строки, можно обозначить очень интересную тему для дискуссии относительно двух направлений бизнеса.

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

• отчет о прибылях и убытках[17] (profit & loss statement), показывающий доходы и расходы с разбивкой по направлениям деятельности и функциям;

• бюджет, более подробно показывающий расходы на поставщиков, подрядчиков и персонал;

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

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

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

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

Капитализация затрат на разработку программного обеспечения – это финансовый вопрос, а не инженерный, его решение обусловлено обязательствами финансовой команды следовать общепринятым принципам бухгалтерского учета, или GAAP (https://www.investopedia.com/terms/g/gaap.asp). Как правило, специалисты финансовой команды не сертифицируют свои ежегодные финансовые аудиты, если только они не следовали GAAP[18], в рамках которого и принимаются решения о том, капитализировать или списывать те или иные понесенные расходы.

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

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

• ее должно быть легко объяснить и обосновать аудитору;

• данные должны быть доступны для подготовки финансовой отчетности финансовым отделом;

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

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

На основе тикетов

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

На основе проектов

Отслеживайте время, затраченное на каждый проект, и определяйте вес капитализации для каждого из них (80 % капитализировано, 0 % капитализировано и т. д.) на основе характера работы. Затем финансовые специалисты объединят это с синтетическими почасовыми затратами на выполнение инженерных задач[19] на основе средней почасовой ставки команды или отдела.

На основе ролей

Установите фиксированный процент времени для каждой роли. Например, 80 % времени продуктового разработчика должно быть капитализировано; 0 % времени инженера по инфраструктуре должно быть капитализировано; и т. д.

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

Инженерное подразделение редко напрямую отвечает за доход компании (хотя почти всегда отвечает косвенно: перед отделом продукта или продаж), поэтому ваш основной вклад в финансовый план – управление расходами (https://infraeng.dev/efficiency).

Я рекомендую разделить эти расходы по направлениям деятельности на три отдельные группы:

• затраты на персонал внутри инженерного подразделения;

• операционные расходы на продакшен (на облачные окружения; расходы на вендоров, связанные с производством, и т. д.);

• расходы на разработку (расходы на вендоров и хостинг, связанные с CI/CD; проведение тестирования; среды разработки и т. д.).

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

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

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

Для этого есть три основные причины.

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

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

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

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

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

Даже самые простые вопросы оказываются неоднозначными, когда вы погружаетесь в их суть. Например, рассмотрим такую компанию, как Figma. У нее есть один основной продукт, но бизнес имеет два подразделения: Enterprise (B2B-продажи крупному бизнесу) и все остальное. Хотя продукт один и тот же в обоих случаях, многие функции, ориентированные на Enterprise, не представляют ценности для других покупателей. В этом случае легко отнести затраты на продуктовых разработчиков, ориентированных на Enterprise, к бизнес-юниту Enterprise, но куда следует относить затраты на разработчиков, создающих основной продукт? Смотреть на доходы? Или отнести все затраты на основной продукт к сегменту non-Enterprise и тем самым искусственно обеспечить высокую рентабельность Enterprise? Другие варианты?

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

Финансовое планирование не является спорным по определению, если управление компанией сосредоточено в руках опытных менеджеров. Однако когда руководители разобщены и не заинтересованы в общем успехе, разнесение расходов становится игрой с нулевой суммой. А еще менеджеры, испытывающие трудности в работе, любят указывать на недостаточный бюджет как на оправдание своей неэффективной работы. Так что процесс планирования может закончиться либо разрушенными отношениями с коллегами, либо неконтролируемыми расходами (https://www.saastr.com/the-biggest-problem-with-mediocre-vps-they-spend-all-the-money).

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

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

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

Всякий раз, когда вы говорите, что вам требуется увеличить численность персонала, вы должны иметь документ – проект организационной структуры, в которой будут учтены новые сотрудники. Самый простой способ сделать это – провести математические расчеты (https://infraeng.dev/organizational-design).

1. Разделите общее количество сотрудников на команды по восемь человек (https://lethain.com/sizing-engineering-teams). У каждой из них должны быть менеджер и собственная миссия.

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

3. Продолжайте группировать, пока не дойдете до пяти-семи групп, которые будут подчиняться вам непосредственно. В компании из ~40 инженеров вам нужно сформировать только один уровень групп, но для компании из ~200 специалистов потребуется несколько уровней.

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

Последнее, о чем я упомяну, говоря о финансовом планировании, – это привычка руководителей компании тратить время на споры о численности персонала, которая на деле вряд ли будет достигнута. Я считаю чрезвычайно полезным сравнивать количество нанятых в прошлом сотрудников с актуальным планом найма (https://infraeng.dev/recruiter-velocity-check). Если вы увидите, что запланированные цифры сильно больше прошлых значений, то все и так становится понятным.

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

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

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

Вендоры обычно ценят следующее:

• деньги, желательно гарантированные;

• долгосрочные обязательства, желательно эксклюзивные;

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

• иногда – сроки платежей (например, небольшая компания с капиталоемким бизнесом будет ценить авансовый платеж, а не постоплату);

• иногда – совместный маркетинг (если вы поможете привлечь будущих клиентов или инвесторов).

С другой стороны, при пересмотре условий сделок вы обычно ждете от вендоров:

• скидку в зависимости от объема закупки: чтобы их цены снижались, если вы будете покупать больше;

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

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

Общий подход, который я бы рекомендовал, таков.

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