«Мы отдали предпочтение кандидату с актуальным управленческим опытом».

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

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

Каждый следующий опыт делал меня как менеджера сильнее. Заодно делал мой управленческий опыт всё менее «актуальным» — по крайней мере, для тех, кто читает резюме.

Один эффективный инженер — ещё не эффективный отдел

Путь в управление у меня начался ещё до разработки — с инфраструктурной команды, которой я руководил.

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

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

Систему не разогнать, бесконечно улучшая один её компонент. Выгоднее вкладываться в остальные — в людей вокруг, — даже если по отдельности отдача от каждого меньше, чем от вложений в собственную экспертизу. Так я впервые понял, что развитие людей для менеджера не побочная забота, а основная работа: помогать людям становиться самостоятельнее, создавать условия для совместной работы и уменьшать зависимость команды от себя. Как писал Вигерс в Getting Started as a New Manager:

Руководитель работает на тех, кем руководит, а не наоборот.

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

Чтобы управлять разработкой, пришлось её понять

Очередной карьерный твист привёл меня из виртуализации и СХД в разработку — DevOps и релиз-инженером. Помню первый шок от того, что непонятно, что вообще происходит вокруг и интенсивный поиск точки входа в обретение этого понимания. Использовал подход, развитый ещё со времён игр в MMORPG: хочешь понять, как должна работать команда, изучи особенности всех классов, а не только своего.

Начал с продуктового менеджмента — прошёл цикл из 6 курсов на Coursera за полтора месяца. Оттуда вынес как работать с требованиями и стал заменять ещё и уволившегося аналитика. Но гораздо больше представления продуктовой разработки как ни странно пришло при изучении тестирования. И CI.

Параллельно погружался в современные подходы в целом и Scrum в частности. Чем больше изучал, тем яснее становилось: то, как мы работаем, со Scrum ничего общего не имеет. Хотя и декларируется. Тут случились первые осознанные наблюдения на тему того, что исходные концепции склонны дрейфовать к поддержанию формы, а не смысла (пересеклось с книгой Ричарда Баха, «Чайка Джонатан Ливингстон»). Форма сохраняется, потому что её можно воспроизвести и проверить по факту исполнения («встреча проведена»), а смысл требует понимания и не поддаётся такой проверке.

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

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

Тем не менее вовлечь людей удалось. А потом проект закрылся.

Раздал группу — получил отдел

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

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

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

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

Одновременно я разбирался, почему буксуют поставки. Тестирование — «последняя миля», сюда приезжают последствия всего, что случилось раньше. А рвалось обычно на стыках между заказчиками, разработчиками и тестировщиками.

Чтобы убрать барьеры на этих стыках, я предложил пилот: кросс-функциональная команда, новая роль системного аналитика и работа по Scrum.

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

Прозрачные грейды и требования к переходу на следующий уровень давали понятный ориентир роста. Сообщества практики — Community of Practice — помогали обмениваться опытом и устраивать «перекрёстное опыление». Я сам читал лекции о виртуализации, Scrum, теории и практике тестирования.

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

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

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

Люди переходили на следующий грейд за полгода–год. За два года выросли три лида команд и несколько техлидов по разным направлениям. Поставки ускорились в два–четыре раза.

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

«Вы просто не понимаете специфики»

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

Роль выглядела убедительно: Delivery Director игрового проекта. Я собирался продолжать делать то, что делал раньше, только теперь в игровой индустрии.

Встретил сильнейшее сопротивление попыткам организовать хоть сколько-нибудь дисциплинированную систему поставок.

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

Давайте не будем говорить о проблемах, а просто будем работать.

Корректирующую обратную связь принимали как оскорбление — особенно от «чужака» и особенно те, кто стал лидом просто потому, что так исторически сложилось.

Мне объясняли, что я не понимаю «специфики» игрового продукта. Вопросы при этом касались дисциплины уровня «не надо дописывать фичу в ветке исправления бага» или того, что вообще входит в обязанности лида delivery.

«Давайте попробуем, не зайдёт — переобсудим и примем другой подход» отлично работало в научно-исследовательском департаменте. Здесь раз за разом терпело крах.

Людей ценили за выслугу лет: проработал пять лет — всё, что ты делаешь, автоматически считается показателем экспертизы. А закрытость отрасли не давала перенять подходы, которые развивались в других областях разработки.

Нанятый мной бэкендер на второй день пришёл увольняться:

Я не готов ЭТО поддерживать.

ЭТО — бэкенд, написанный местным «архитектором», отработавшим десять лет.

Поддержки руководства я не получил. Мой подход настроил против меня часть команды, особенно молодых, но важных лидов delivery и геймдизайна. Потерять Delivery Director'а было проще, чем ведущего геймдизайнера.

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

Заодно выяснилось, что книгу Джесси Шелла о геймдизайне (он вёл курс по геймдизайну, тоже на Coursera) читал я, а наши геймдизайнеры — нет. Думаю, даже одна эта книга могла заметно изменить работу над продуктом. Проверить уже не получится: проект развалился через два года после старта, примерно через год после моего ухода.

Здесь я понял цену поддержки сверху. Изменить процесс и изменить культуру — разные задачи. Когда само обсуждение проблем воспринимается как угроза, разумного предложения мало: нужна опора на тех, кто может менять правила. А если власть на стороне тех, кто сопротивляется, эскалировать некуда — остаётся выход. Менеджер, который этого вовремя не видит, сам становится проблемой, от которой удобнее избавиться.

Один из самых гибких банков

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

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

Ведомый этим убеждением я оказался в одном из «самых гибких (на тот момент) банков». Хотел погрузиться в атмосферу Scrum среди коллег — скрам-мастеров. Работать там, где подход уже принят, учиться у других, а не проталкивать его в одиночку через инертную систему.

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

Надо ли говорить, что разработчики этот контингент всерьёз не воспринимали. Скрам-мастер считался «тамадой встреч». Для фактического управления разработкой была введена роль техлида.

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

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

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

Software Engineering Manager, который оказался менеджером проектов

Следующая вакансия называлась Software Engineering Manager. Название и описание были очень похожи на то, что я искал: управление разработкой, развитие команд и людей.

На собеседовании с двумя директорами рассказывал о своём опыте. Им отзывалось.

Дополнительный плюс — разработка систем хранения данных, а с СХД я хорошо знаком ещё с инфраструктурных времён.

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

Я начал разбираться с задержкой релиза. Плановый срок составлял девять месяцев, задержка — ещё девять. Ninety-Ninety Rule в действии (первые 90 % работы занимают 90 % времени, оставшиеся 10 % — ещё 90 % времени).

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

Снова были видны проблемы коммуникации и синхронизации между слоями: datapath, controlpath, UI, тестирование. Плюс в релиз пытались уместить слишком много.

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

Собрать команду оказалось отдельным проектом.

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

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

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

Мне дали собрать вторую команду и ещё один большой блок функционала. Появилась перспектива роста до пяти команд.

Потом случился 2022-й. Компании уходили из России, а наш производитель СХД бурно рос, вбирая их сотрудников: за несколько месяцев — примерно с 800 до 3000 человек.

Между мной и директорами, которые меня нанимали, появился слой ещё нескольких директоров. Им очень не понравились кросс-функциональные команды и «этот ваш Agile».

Мои команды формально ко мне не относились. Я всё ещё был просто менеджером проектов.

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

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

Пойду просто работать инженером

Какое-то время пытался найти применение внутри компании.

Были отдельные скрам-мастера. Спасибо, уже пробовал.

Были отдельные пипл-менеджеры: проведение 1-to-1, ИПР и коммуникации с мотивациями — без влияния на рабочий процесс и без административных полномочий.

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

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

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

Через полгода я стал руководителем группы системного анализа.

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

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

Но продуктовый менеджмент ставил задачи уровня «сделайте нам за год mid-range СХД уровня Huawei Dorado» силами команды в десять с небольшим человек. Это вселяло безысходность и скепсис в отношении успешности предприятия. Агония продолжалась полтора года.

Тогда и возникла мысль: «Не можешь победить зло — возглавь его». То есть самому попробовать продуктовый менеджмент.

Теорию я изучал давно. Практические функции уже выполнял в разработке СХД: исследовал рынок, дрался за сужение объёма, выделял MVP, расставлял приоритеты.

Так я стал TPO — Technical Product Owner — в облачной платформе.

Продакт отвечает за всё

Там был координационный ад.

Пять независимых команд: бэкенд, ещё более низкоуровневый бэкенд, UI, дизайнеры и технические писатели. У каждой свой руководитель. Никто не отвечал за сквозную поставку функций. «Продакт отвечает за всё» — и даже обсудить проблемы текущего подхода было не с кем.

Роль совмещала менеджера проектов, системного аналитика и продуктового менеджера. Нужно было изучать рынок, формировать roadmap, описывать требования, расставлять приоритеты и драться за очерёдность выполнения функций с другими продактами.

Ещё — контролировать работу всех команд: тестировщики были только у UI и тестировали не всё. Ещё — координировать выпуск с биллингом и юристами. Ещё — проектировать ресурсные модели и архитектуру новых сервисов.

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

В разборе ловушек среднего менеджмента Уилл Ларсон пишет, что балансирование между интересами руководства, коллег и команд, обслуживание процессов и распределение ресурсов могут отдалять менеджера от предметной экспертизы и непосредственной работы над результатом. В этой роли около 90% рабочего времени занимала координация неэффективных процессов. А 90% внерабочего — развитие AI-агентов, их пайплайнов и "второго мозга", чтобы снимать рутину и удерживать контекст по 14 параллельным рабочим активностям. Это был один из двух плюсов работы. Второй — знакомство с предметной областью облачных платформ. Остальное просто убивало.

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

Неконсистентный опыт

I tried so hard, and got so far
But in the end, it doesn't even matter
— Linkin Park, «In the End»

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

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

В паре случаев резюме дошло до живых людей — благодаря другим людям — ответ был таким:

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

Скрам-мастер, менеджер проектов, системный анализ, продукт — эти шаги в сторону были где-то вынужденными, где-то сознательными: я искал роль, реализующую мои навыки и видение менеджмента, а также прокачивал смежные треки. Каждый добавлял понимания продуктовой разработки как системы и навыков, чтобы её выстраивать. В резюме те же шаги читаются как метания.

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

Остаётся неудобный выбор. Рассказать свой путь честно — и отсеяться до первого разговора. Подогнать его под фильтр — и прийти на разговор с историей, которую трудно защищать перед живым человеком.

Литература и материалы

(полезные штуки, которые не вошли в текст, но имели влияние)

• Карл Вигерс, Джой Битти — «Разработка требований к программному обеспечению» / Software Requirements.

• Кеннет Рубин — Essential Scrum.

• Рэй Далио — «Принципы. Жизнь и работа» / Principles: Life & Work

• Гойко Аджич, Дэвид Эванс, Том Роден — Fifty Quick Ideas to Improve Your Tests

• Специализация на Coursera Coaching Skills for Managers

• Специализация на Coursera Leading People and Teams

• Google re:Work — Understand team effectiveness.

• Talantix — ИИ-сортировка и оценка кандидатов.