Уроки из «Элегантной головоломки: системы инженерного менеджмента» Уилла Ларсона
Недавно я стал инженером-менеджером, и эта книга оказала огромное влияние на мое решение.
Что мне больше всего понравилось, так это то, что Уилл Ларсон, автор, весьма категоричен в отношении различных тем управления. Он проясняет туманную роль с помощью действенного набора систем.
Есть части книги, которые пока не очень актуальны для меня (например, быть менеджером менеджеров), но я знаю, что могу вернуться к этим частям, если/когда они станут актуальными.
#1 — Размер команды
У Уилла есть четкая формула того, каким менеджером вы, вероятно, будете, исходя из размера вашей команды.
- «Сбалансированный» менеджер — команда из 6–8 человек
- Менеджер «Техлид» — менее 4 отчетов
- Менеджер «Тренер» — более 8 отчетов
С 5 отчетами я не совсем в лучшем положении, но я чувствую себя ближе к роли «технического лидера». Я предпочитаю это в любом случае, так я могу потратить больше времени на кодирование и быть ближе к реализации.
Менеджер-тренер с более чем 8 отчетами находится на противоположном конце спектра. Уилл считает, что такой размер команды несостоятелен и слишком истощает менеджера.
По мере продвижения по карьерной лестнице я буду помнить, как размер команды повлияет на мою эффективность как менеджера и где я могу оказать наибольшее влияние.
# 2 — Команды должны как вводить новшества, так и поддерживать
Мне нравится этот принцип.
Уилл выступает за то, чтобы команда владела как инновациями (создание новых функций), так и обслуживанием (убедившись, что существующие системы не ломаются).
Я работал в компаниях, которые поступали наоборот и быстро развивали две фракции с противоположными целями.
Вместе со своей командой я выступаю за полное владение всеми функциями, которые мы создаем, включая обслуживание.
#3 — Четыре состояния команды
У каждого менеджера в мозгу должна быть встроена эта диаграмма:
Уилл предлагает самоуверенную формулу того, как справляться с каждым состоянием:
1. Отставание
- Состояние: команда усердно работает, но невыполненные работы продолжают расти. Мораль низкая.
- Решение: наймите больше людей.
2. Топчутся на месте
- Состояние. Критическая работа выполняется, но технический долг не выплачивается. Мораль в порядке.
- Решение.Сокращайте параллельную или новую работу до тех пор, пока команда не сможет погасить технический долг.
3. Возврат долга
- Состояние:способность тратить время на технический долг. Каждая решенная часть технического долга открывает больше времени, чтобы сосредоточиться на техническом долге (снежный ком погашения долга) и инновациях. Мораль хорошая.
4. Инновации
- Состояние.У команды низкий технический долг, и есть ресурсы для работы над новыми функциями. Мораль высока.
# 4 — «Вы получаете ценность от проектов только тогда, когда они завершены»
Это простая, но мощная концепция.
Каждый инженер в вашей команде может усердно работать над отдельными проектами, но бизнес не будет иметь никакой ценности, пока некоторые из них не будут завершены. Иногда члены вашей команды могут извлечь выгоду из сотрудничества, чтобы ускорить выполнение проектов.
По моему опыту, также можно получить дополнительную ценность, даже если проект еще не «завершен». Это делается путем постепенного выпуска вашей функции для пользователей поэтапно. Недостатком является то, что это требует большего планирования.
№ 5 — Диаграмма системы продуктивности разработчиков
Это моя любимая диаграмма во всей книге.
Он предоставляет способ отладки/оптимизации ограничений скорости разработки вашей команды.
Например, я заметил, что скорость развертывания для нашей команды мобильных приложений составляла каждые 2 недели. Это привело к тому, что «Готовые коммиты» накопились за 2 недели до их развертывания. Огромный объем кода затруднял нам контроль качества и приводил к ошибкам или дальнейшим задержкам развертывания.
Узким местом была наша низкая скорость развертывания. В качестве решения я предложил потратить время на инструмент под названием CodePush, который позволил бы нам мгновенно развертывать веб-подобное для некоторых функций нашего приложения Javascript. Сейчас он интегрируется в наш процесс развертывания и должен повысить скорость.
# 6 — Станьте менеджером по продукту, если у вас его нет
Это важная концепция, которую необходимо усвоить руководителям инженерных служб.
У вас не всегда будет полная команда дизайнеров, продакт-менеджеров, аналитиков данных и т. д. Будем надеяться, что это временная ситуация. Но когда одна или несколько из этих функций отсутствуют, инженер-менеджер должен надеть соответствующие шляпы, чтобы разблокировать и обеспечить успех команды.
Вы должны стирать границы своей роли, когда это необходимо.
#7 — Стратегии и видения
Смысл стратегий и концепций в том, чтобы создать согласованность в масштабе.
Это больше для менеджеров менеджеров, у которых нет времени встречаться с каждой командой или понимать каждую дорожную карту, но они хотят убедиться, что их подход понятен всем командам.
Уилл описывает самую простую формулу для создания стратегии или видения, которую я когда-либо читал.
Но во-первых, для чего они нужны?
«Стратегии подтверждают, что у вас есть общее понимание текущих ограничений и способов их преодоления».
«Видение гарантирует, что вы согласны с долгосрочным направлением, сохраняя при этом гибкость в краткосрочной перспективе».
— Уилл Ларсон
Простейшая формула
- Стратегия — напишите 5 проектных документов (или RFC) и объедините эти документы в стратегию. Это позволяет вашей стратегии основываться на примерах и не быть слишком абстрактным.
- Видение — напишите 5 стратегий и экстраполируйте их в виденье. Напишите прогноз того, что произойдет через 2–3 года, когда сработают эти 5 стратегий.
Это так просто гениально!
Стратегии и видения всегда казались мне расплывчатыми концепциями. Мне было непонятно, почему лидеры писали их, когда я был индивидуальным автором. Вероятно, потому, что они были слишком абстрактными или сложными для моего понимания.
Уилл подчеркивает, что хорошие стратегии и видение должны быть скучными и их не следует путать с инновациями. Это инструменты для согласования, а излишне сложные или абстрактные инструменты сделают прямо противоположное.
Пример стратегии
Хотя у меня нет опыта написания концептуального документа, я столкнулся с несколькими RFC, в которых было ясно, что нужна стратегия и как мы должны ее написать.
Я разобью стратегию, используя 3 шага Уилла для написания стратегии: диагностика, политики и действия.
- Диагностика. В настоящее время наш интерфейс распределен по нескольким базам кода, и я не знаю, куда добавить новое приложение или функцию внешнего интерфейса. Также есть желание консолидировать эти фрагментированные кодовые базы, но есть разногласия по поводу того, какие из них удалить. Кроме того, существуют разногласия по поводу того, куда добавлять новые функции внешнего интерфейса. Я считаю, что отчасти это связано с тем, что право собственности на эти интерфейсные системы неясно.
- Политики. Право собственности и опыт определяют, в какую кодовую базу функция будет перенесена/добавлена. Двумя основными категориями специалистов являются разработчики React и разработчики бэкэнда. Две широкие категории собственности — это продукты, ориентированные на пользователя, и внутренние интерфейсы инструментов/настроек. Разработчики React, как правило, владеют продуктами, ориентированными на пользователя, в то время как разработчики бэкэнда, как правило, владеют внутренними интерфейсами инструментов/настроек. Разработчики React будут вносить свой вклад в единую кодовую базу React, в то время как бэкэнд-разработчики будут вносить более простые статические страницы в приложение Ruby on Rails.
- Действия — это просто применение вышеуказанных политик. Уилл говорит, что это легко обрисовать в общих чертах, но сложно заставить других следовать этому. Чем конкретнее, тем лучше:
- Является ли функция ориентированной на пользователя и принадлежит ли она разработчикам продукта? Реализуйте его в кодовой базе React.
- Это функция для пользовательских настроек или внутренних инструментов? Реализуйте его в кодовой базе Ruby on Rails.
- Примените те же правила, что и выше, к существующим функциям, которые необходимо перенести из других фрагментированных систем.
# 8 — Моделируйте, документируйте и делитесь
Это блестящая визуализация того, как добиться перемен без полномочий (или с их помощью).
Поскольку я работал инженером по развитию, мышление, основанное на тестах и экспериментах, является моим хлебом насущным при создании продуктов.
Что мне нравится в этой диаграмме, так это то, что Уилл применяет тот же экспериментальный подход к изменениям внутри организации.
Основная идея состоит в том, чтобы смоделировать изменение, которое вы хотите, то есть провести эксперимент в меньшем масштабе, например. через личный пример или пример вашей команды.
В моей недавней компании я моделировал поведение, которое приводило к хорошим результатам. Одним из элементов этого было работать в качестве инженера с полным стеком и демонстрировать повышенную скорость и более сильное мышление о продукте.
Затем я потратил время на документирование того, какое поведение привело к положительным результатам. Этот процесс включал в себя глубокое осмысление и обратный инжиниринг того, что я делал для создания воспроизводимой структуры.
Затем я, как технический менеджер, потратил время на обмен и обсуждение разработанного мной документа. Кроме того, моя команда еще больше расширила эту модель, став полноценными инженерами, ориентированными на продукт.
Моделирование, документирование и совместное использование позволили мне и моей команде оказать положительное влияние на организацию без полномочий высшего уровня.
№ 9. Отделите участие от продуктивности
Это блестящее напоминание о том, что нужно безжалостно расставлять приоритеты и учиться говорить НЕТ как менеджеру.
Будут бесконечные встречи, просьбы, электронные письма и сообщения, которые могут отнять у вас все время.
Предостерегающий совет Уилла заключается в том, что посещаемость сама по себе не имеет ценности. Крайне важно быть разборчивым в том, где вы добавляете ценность или можете получить пользу от встреч.
Что я делаю каждое утро, так это пытаюсь определить 4 или 5 решений, которые я могу принять, которые действительно будут иметь значение. Это облегчает отказ от всего остального.
10. Внутренние проблемы можно свести к отсутствующим или плохим отношениям
Я интерпретирую это так: проблемы или конфликты часто возникают из-за отсутствия данных между людьми.
Обнаружение или исправление отсутствующих или плохих взаимосвязей исправляет этот путь связи, чтобы обеспечить поток данных.
Восстановив коммуникацию, два человека или часть организации могут создать более универсальный набор данных.
Этот универсальный набор данных позволяет группам объединяться и согласованно решать проблемы.
