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

За последние несколько месяцев я провел серию бесед, чтобы выяснить, что работает, а что нет. Я сосредоточился на пяти проектах и задавал одни и те же основные вопросы: что сработало, что не сработало и что бы вы порекомендовали?

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

Некогда читать? Ознакомьтесь с Кратким справочником.

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

Вот пример сообщения в Slack с планами:

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

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

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

Создавайте продукт на основе контракта

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

Контракт может быть простым: эндпоинт возвращает { user_id, subscription_type, position}. Таким образом, бэкенд создает реальный эндпоинт, а фронтенд создает интерфейс под эту структуру.

Это можно применять для асситов, анимаций, дизайнов, ответов API. Создавайте на основе контракта: интерфейса, хуков и структуры данных. Используйте плейсхолдеры. Затем объединяйте их, когда они будут готовы (не забудьте оставить время на это и на тестирование).

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

Если контракт меняется, обязательно сообщите об этом всем, чтобы они могли внести аналогичные корректировки. И здесь суть снова не в идеальном плане. Суть в том, чтобы все были в курсе и могли адаптироваться вместе.

Сокращайте циклы обратной связи

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

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

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

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

Настройте прямые каналы обратной связи с руководством. Создайте отдельный канал в Slack со старшим руководством на этапе запуска. Предоставьте ключевым ревьюерам доступ к рабочим сборкам вместе с краткой еженедельной заметкой, объясняющей, какая обратная связь будет наиболее полезной. Один из фреймворков, которые мы используем в Duolingo, — это 10/50/99 approach:

На отметке 10% запрашивайте отзывы о направленности
На отметке 50% согласуйте структуру и подход
На отметке 99% сосредоточьтесь на полировке и деталях

Я выяснил, что полезно указывать уровень проработки ( fidelity) при запросе обратной связи; например: «Это грубая ранняя сборка, поэтому мы ждем отзыва на 10% по базовой механике, а не по качеству полировки». Команды, придерживавшиеся этого подхода, двигались быстрее, так как получали направленный фидбек на ранней стадии.

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

Оставайтесь синхронизированными без замедления процессов. Все это работает только тогда, когда команда остается постоянно информированной. Дейли (stand-ups) или регулярные точки контакта могут быть хорошим способом для этого, но делайте их короткими и следите за тем, чтобы каждый имел право голоса. Случайный забавный факт: слово «дейли» (stand-up) изначально задумывалось для того, чтобы подчеркнуть: встреча должна быть настолько быстрой, чтобы ее можно было провести стоя.

Каждый должен уходить с пониманием:

Что находится в работе
Что ему нужно делать дальше и к какому сроку
Не является ли он для кого-то «бутылочным горлышком» (блокером)
Если у него самого есть блокер, что ему нужно сделать, чтобы его устранить

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

По возможности держите команды небольшими, стабильными и сфокусированными

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

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

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

Когда в команде происходят изменения, есть способы сделать их немного проще.

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

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

Когда проекты выходят за рамки

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

Еще несколько полезных советов

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

Найдите эксперта. Работаете с незнакомым кодом или на стыке команд? Найдите эксперта в предметной области (SME) и попросите у него времени на консультацию. Самостоятельное разбирательство почти всегда обходится дороже, чем вопрос специалисту.

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

Применяйте закон мобильности. Он также известен как закон двух ног из концепции Open Space. На встречах, где вам не нужно присутствовать постоянно, предложите членам команды использовать закон мобильности. Если человек не учится и не вносит свой вклад, позвольте ему отправиться туда, где он сможет использовать свое время с пользой.

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

Краткий справочник

Что стоит попробовать:

Заранее согласуйте контракты интерфейсов, чтобы работу можно было вести параллельно
Сделайте V1 минимальным, чтобы проверить основную идею перед крупными инвестициями
Сделайте разрыв между прототипом и продакшеном наглядным; сформулируйте, что требуется для релиза
Настройте прямой канал обратной связи с руководством с первого дня
Указывайте уровень проработки при запросе обратной связи (10%/50%/99%)
Привлекайте QA на ранних этапах для тестирования небольших готовых частей
Проводите стендапы коротко; решайте проблемы позже только с теми, кто должен там присутствовать
Укомплектуйте проект всеми необходимыми для выпуска специалистами
Проводите жесткую приоритизацию и минимизируйте переключение контекста
Назначьте человека, который будет удерживать целостное видение междисциплинарных проектов
Напишите документ для передачи дел перед отпуском или сменой проекта
Создайте документы для онбординга по командным соглашениям
Заложите время на адаптацию, если проект переходит к новой команде
Найдите эксперта в предметной области при выходе за рамки команды
Продолжайте двигаться во время ожидания
Выделите время на доработку и технический долг
Применяйте закон мобильности (он же закон двух ног) на встречах, где это уместно. Если вы не учитесь и не вносите свой вклад, отправляйтесь туда, где можете использовать свое время с пользой.

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