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

Этап 2. Распределение ресурсов

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

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

На рис. 4.2 показан один из возможных ответов на этот вопрос. Он демонстрирует фиксированные инвестиции в инфраструктуру, увеличивающиеся – в Developer Experience[20] и меняющиеся – в разработку продукта.

Рис. 4.2. Распределение ресурсов по приоритетам

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

1. Примерно раз в год просматривайте весь набор инвестиций в инженерное направление и оказанное ими влияние, а также потенциальные инвестиции, которые есть у вас в запасе. Составьте список того, на что они могут повлиять, обратившись к максимально широкому кругу источников: используйте результаты исследования продуктивности разработчиков (https://infraeng.dev/developer-survey), проведите мозговой штурм и т. д.

2. Постоянно обновляйте этот список по ходу выполнения работы и появления новых идей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 3. Согласование дорожной карты

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

Дорожная карта терпит неудачу по следующим причинам:

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

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

• смешение в дорожной карте проектов с подтвержденной эффективностью и сырых идей;

• лишение команд автономии из-за слишком детализированного планирования.

Мы уже уделили время первой проблеме, поэтому давайте немного углубимся в остальные.

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

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

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

В своей превосходной статье «How to plan?» (https://kellanem.com/notes/how-to-plan) Келлан Эллиот-Маккри (Kellan Elliott-McCrea) делится наблюдениями о том, как часто в процессы планирования активно внедряют новые идеи:

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

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

Два действенных способа избежать такого сценария.

• Распределите инициативы на две группы: с подтвержденной и неподтвержденной эффективностью, а затем расставьте приоритеты в рамках этих групп. Например, вы можете сказать, что 20 % времени продуктовой разработки должно быть направлено на валидацию новых проектов. Затем вы можете обсудить, какие сырые идеи должны получить эти 20 % и отдельно – как инвестировать 80 % времени продуктовой разработки в проверенные проекты.

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

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

Последняя проблема дорожной карты, которую я отмечу, заключается в том, что, если вы будете слишком конкретны, то можете случайно лишить команду, ответственную за фактическую работу, инициативы и полномочий. Мелисса Перри (Melissa Perri) очень красочно рассказывает об этом в своей книге «Escaping the Build Trap». Она показывает, как дорожная карта, узко сфокусированная на задачах проекта, а не на желаемых результатах, может ограничивать мышление команд.

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

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

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

• Годовой бюджет – готовится в конце предыдущего года.

• Функциональное планирование – должно осуществляться на постоянной основе в течение года.

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

График планирования показан на рис. 4.3.

Рис. 4.3. Пример процессов планирования

Очевидно, что конкретные детали будут различаться в разных компаниях, но я не считаю, что это так уж важно. Самое главное, о чем я рекомендую не забывать, – это то, о чем часто говорила Клэр Хьюз Джонсон (Claire Hughes Johnson) (https://press.stripe.com/scaling-people), когда мы работали вместе в Stripe: планирование всегда занимает все отведенное на него время. Если вы выделите на него одну неделю, оно займет одну неделю. Если вы отведете ему один месяц, потратите один месяц. Поскольку планирование – это бесконечное путешествие, лучше не тратить слишком много времени на описание каждого шага.

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

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

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

Ловушки, в которые не стоит попадать

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

Рассмотрим два признака того, что планирование поручено человеку, ориентированному на процесс, а не на результат.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

1

Рейли Т. «Карьера разработчика. Стафф – круче, чем senior». Санкт-Петербург, издательство «Питер».

2

Фурнье К. «От разработчика до руководителя. Менеджмент для IT-специалистов».

3

Ларсон У. «Элегантная головоломка. Системы инженерного менеджмента».

4

Рейли Т. «Карьера разработчика. Стафф – круче, чем senior». Санкт-Петербург, издательство «Питер».

5

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

6

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

7

DEF 14A – документ, который публичные компании в США обязаны подавать в SEC (Комиссию по ценным бумагам и биржам) перед годовым собранием акционеров. Он содержит ключевую информацию для голосования, в том числе вознаграждение топ-менеджеров (зарплаты, бонусы, опционы). В РФ ближайший аналог – сообщение о проведении общего собрания акционеров (ОСА), но там, как правило, отсутствует детальная информация о вознаграждении менеджмента или даются обобщенные данные. – Примеч. ред.

8

Права на приобретение определенной доли в компании (чаще всего стартапе) по фиксированной цене. – Примеч. пер.

9

Стартапы, находящиеся на стадии инвестирования «серии C», – это компании, которые уже продемонстрировали беспрецедентный успех и находятся на этапе масштабирования. – Примеч. пер.

10

Уоткинс М. «Первые 90 дней».

11

Производительность команды, или Velocity, – это метрика из Scrum, отражает количество работы, которое команда может выполнить за один спринт. – Примеч. пер.

12

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

13

Румельт Р. «Хорошая стратегия, плохая стратегия».

14

Эскалация – передача конфликта или проблемы на более высокий уровень управления. – Примеч. ред.

15

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

16

Карс Дж. «Конечные и бесконечные игры».

17

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

18

GAAP (Generally Accepted Accounting Principles) – набор стандартов и правил, регулирующих финансовый учет и отчетность. – Примеч. ред.

19

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

20

Developer Experience (DevEx, опыт разработчика) – создание инструментов разработки и объединение их в единый автоматизированный процесс по тестированию и внедрению сервисов. – Примеч. пер.