Снова наступило то время года, когда ваша лента в LinkedIn переполнена постами в стиле «Мой карьерный путь в ушедшем году», а на главной странице Medium до сих пор доминируют статьи «10 важнейших уроков прошлого года», которые набрали популярность во время зимних каникул. Что ж, последую модному тренду и позволю себе опоздать на этот праздник рефлексии. Алгоритмы, вероятно, уже закатывают глаза: «Еще один обзор прошлого года? Это уже так… неактуально».

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

От кода к хаосу: мой первый месяц в качестве главного инженера

Позвольте перенести вас в апрель 2024 года, когда я вступил в новую должность, официально став главным инженером. Знаете, принято считать, что время решает все? Так вот, у тех, кто так говорит, извращенное чувство юмора. Вместо обычного переходного периода для адаптации к новой должности, я попал в то, что могу описать только как технический торнадо: обновления наших приложений отклонялись в Google Play Store; количество подписчиков сокращалось быстрее, чем число моих сбывшихся новогодних желаний, а количество отказов наших приложений перевалило за пороговый уровень, какой был у фондового рынка во время финансового кризиса 2008 года.

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

  • выполнял роль дипломата в отношениях между маркетологами и инженерами, чтобы разгадать тайны отказов в Play Store;
  • углублялся с коллегами-инженерами в проблемы ANR (Application Not Responding — зависание приложения), чувствуя себя детективом на месте технического преступления;
  • проводил экстренные совещания для выяснения, почему наш граф регистрации пользователей вдруг решил имитировать горнолыжную трассу экстремальной сложности.

Те первые недели стали не просто экзаменом на стойкость — они полностью закалили меня. Это было настоящим крещением огнем. Но знаете, что самое интересное в огне? Он либо сжигает вас, либо делает вас сильнее.

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

И мне есть что рассказать. Слишком много для одной статьи. Поэтому я решил написать серию статей «Признания начинающего главного инженера-программиста». В ней я буду рассказывать о хаосе, проблемах, маленьких победах и обо всем, что случилось на моем карьерном пути в 2024 году. Начну с того, что считаю самым значительным своим достижением прошлого года — с инициативы, которая изменила подход моей команды к качеству продукта и сотрудничеству.

Трансформация процесса разработки: поэтапное тестирование

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

Дэниел Крейг

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

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

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

«Самое сложное в руководстве любыми изменениями — не внедрение новых процессов, а изменение старых представлений».

Знаете, в чем казус разработки ПО? Мы создаем программное обеспечение, чтобы упростить жизнь, но иногда настолько привыкаем к усвоенным неэффективным процессам, что воспринимаем их изменение как попытку предложить кошке принять ванну. Универсальная истина заключается в том, что в разработке ПО «никто не приветствует перемены», поскольку иметь дело с привычными системами и процессами комфортнее, чем с инновационными технологиями, рефакторингом кода или значительными обновлениями. Любые изменения, даже приносящие пользу в конечном итоге, вызывают естественное сопротивление в командах. Я отчетливо осознал это, когда в качестве главного инженера представил на всеобщее обсуждение свою первую крупную инициативу под названием Milestone Testing — поэтапное тестирование.

Мои цели были предельно ясны:

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

Хотя никто не выказал особого сопротивления, моя идея столкнулась с суровой реальностью:

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

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

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

Разработка процесса поэтапного тестирования

Поэтапное тестирование может показаться сложной задачей, но, поверьте, это менее болезненно, чем объяснять руководству свои промахи в реализации! Я быстро сообразил, что для запуска нового процесса нужен структурированный план, поэтому засучил рукава и разработал его!

  1. Планирование этапов (Milestone Planning): определение и указание ключевых результатов проекта и сроков.
  1. Написание тестовых примеров (Test Case Writing): создание подробных тестовых сценариев для проверки функциональности приложения и требований.
  1. Анализ тестовых примеров (Test Case Review): оценка тестовых сценариев на предмет их полноты и соответствия требованиям проекта.
  1. Разработка (Development): проектирование и разработка требований проекта.
  1. Поэтапное тестирование (Milestone Testing): проведение тщательного тестирования приложения на ключевых этапах проекта для подтверждения прогресса.
  1. Решение проблем (Issue Resolution): выявление и устранение дефектов и проблем в приложении для поддержания качества.

Распределение ответственности: моя первая попытка создать матрицу RACI 

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

Аббревиатура RACI отражает четыре базовые роли участников проекта:

  • R (Responsible) — исполнитель, выполняющий конкретную задачу; 
  • A (Accountable) — проверяющий результаты и отвечающий за качество и сроки решения задач;
  • C (Consulted) — консультант, к которому обращается за информацией и рекомендациями сотрудник, выполняющий задачу;
  • I (Informed) — участник, отслеживающий процесс выполнения задач и координирующий свою работу с другими участниками.

Это был мой первый опыт, и да, пришлось погуглить! Матрица RACI должна была помочь:

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

Разработчики (Developers, DEV) в первую очередь отвечают за выполнение задач по разработке, в то время как менеджеры инженерных групп (Engineering Managers, EM) играют двойную роль исполнителей и проверяющих, отвечая как за планирование, так и за эффективное выполнение этапов тестирования. На технических менеджеров проекта (Technical Project Managers (TPM) возлагается ответственность за координацию усилий между командами и их подчинение общим целям, а продакт-менеджеры (Product Managers, PM) вносят свой вклад, предоставляя консультации и информацию относительно любых требований. Специалисты по поддержке продуктов (Support Champions) и дизайнеры (Designers) играют важную роль, подготавливая тестовые примеры, проводя поэтапное тестирование и выполняя проверку качества дизайна.

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

Реализация процесса: от идеи до пилотного проекта

Продвигать новые идеи не всегда легко, но мне повезло: моя руководительница увидела очевидные преимущества такого подхода. Она его не только поддержала, но и решила запустить в качестве эксперимента в рамках проекта по онбордингу (интеграции новых сотрудников), порученного Android-команде. Она также отметила, что в случае успеха можно будет запустить это решение и для других команд в будущих проектах. Как только я объяснил свою концепцию Android-инженерам и нашему специалисту по поддержке продуктов, атмосфера в комнате, где шло обсуждение, изменилась — все присутствующие были заинтригованы, особенно вдохновившись идеей поэтапного тестирования и контроля качества дизайна. Таким образом, я с несколькими членами моей команды приступили к пилотному эксперименту в рамках проекта по разработке нового приложения онбординга, запускавшегося в то время. Конечно, были и скептические высказывания — перемены всегда пугают. Но обещание более плавного релиза проекта покорило большинство членов команды.

Прощупывание почвы: пилотный эксперимент

Мы разбили проект онбординга на логические части — регистрация, вход по электронной почте, вход через Google/Facebook и т. д. — и запланировали еженедельное поэтапное тестирование на пять недель. Этот план мы довели до сведения TPM. Сгруппировав связанные функции по недельным этапам, позаботились о распределении общей нагрузки и четкой целенаправленности каждого этапа. Этот пилотный эксперимент — от мозгового штурма по контролю качества тестовых примеров до синхронизации с Android-инженерами — продемонстрировал эффективность межфункциональной командной работы. Первый этап был очень важен — он задавал тон всему процессу. И когда после тестирования первого этапа контроль качества дизайна выявил кучу косметических проблем с пользовательским интерфейсом, я понял: этот эксперимент не только откроет глаза на многие недостатки, но и полностью поменяет правила игры. Инженеры поначалу были ошеломлены: они явно не привыкли получать так много ошибок на ранней стадии разработки. Но это проложило нам путь к оптимизации процесса проверки кода в будущем и более тщательному подходу к спецификации дизайна Figma.

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

Тонкая настройка процесса поэтапного тестирования 

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

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

Решение? Мы пришли к более сбалансированному подходу:

  • Максимум две сессии поэтапного тестирования раз в две недели.
  • Одна сессия комплексного сквозного тестирования.

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

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

Волновой эффект: небольшие изменения порождают большие волны

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

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

К концу 2024 года наши веб- и iOS-команды внедрили поэтапное тестирование для своих крупных проектов. В 2025 году мы планируем привлечь к тестированию и бэкенд-команду. Почему все радости жизни должно доставаться фронтенд-командам?

Мое тайное признание

Вот мое тайное признание: все те вопросы и сомнения, о которых я упоминал здесь, на самом деле исходили не от моей команды или кого-либо еще — они громким эхом отдавались в моей собственной голове.

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

Каждый раз, когда я репетировал свою презентацию поэтапного тестирования, внутренний голос мне нашептывал: «Кем ты себя возомнил? Ты, новичок, хочешь изменить привычный для всех рабочий процесс?» Иногда по ночам я лежал без сна и спрашивал себя: «Не слишком ли я тороплюсь?». В конце концов, устоявшийся процесс работал (вроде как) годами. Действительно ли я в состоянии что-то изменить?

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

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

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

Читайте также:

Читайте нас в Telegram, VK и Дзен

Перевод статьи Arighna Maity: Confessions of a First-Time Engineering Manager — Part 1

Предыдущая статьяВеб сломан