Asana не дала 150 миграциям повторить одну и ту же ошибку

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

Именно с такой ситуацией столкнулась Asana при переносе 66 настроек Admin Console через примерно 150 миграций в нескольких общих фреймворках. В инженерном отчёте, опубликованном 16 сентября 2026 года, компания описывает другой подход: не зафиксировать один расширенный бриф и не запускать все миграции разом, а разбить работу на тикеты, выполнять независимые тикеты параллельными волнами, проверять каждую волну и корректировать ещё не запущенные тикеты.

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

Риск был не в одной сложной миграции, а в повторении

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

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

Описанный Asana процесс сохранял устойчивую цепочку: Problem → Research → Spec → Review → Implementation → Verification. Смысл был не только в ускорении подготовки реализации. Нужно было сохранить ход рассуждений, чтобы следующий инженер или следующая сессия понимали, что меняется, зачем это меняется и что будет считаться завершённым результатом.

Превратите серию миграций в процесс, который учится по ходу работы

1. Сформулируйте проблему до предложения решения. Зафиксируйте бизнес- или платформенное условие, из-за которого нужна миграция, а не только желаемую техническую реализацию.
2. Исследуйте затронутую область и подготовьте спецификацию, сохраняющую ключевые решения и критерии готовности между последующими сессиями реализации.
3. Перед началом реализации воспроизведите понимание задачи и вынесите вопросы, которые могут существенно изменить план. Здесь инженер может скорректировать направление до того, как придётся переписывать код.
4. Создайте отдельный ограниченный тикет для каждой миграции. В случае Asana тикет был единицей контекста, назначения, ревью и истории работы.
5. Запускайте независимые тикеты параллельными волнами, а не как единый необратимый запуск всей совокупности.
6. Проверяйте каждую завершённую волну и обновляйте оставшиеся тикеты с учётом полученных выводов до их запуска. Верификация закрывает отдельную миграцию, а ревью волны улучшает незавершённую программу.

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

Заявленный результат полезен, но его нельзя расширять

Asana сообщает, что 91% миграций в этой программе примерно из 150 миграций не потребовали доработки после ревью. Это не показатель точности спецификаций, инструментов разработки или миграций вообще. Это заявленная компанией доля единиц миграции в конкретном проекте, которым после ревью не понадобились изменения; точный числитель за округлённым процентом источник не раскрывает.

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

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

Человеческое суждение из процесса не исчезло

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

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

Хорошая спецификация всё равно может закрепить плохую предпосылку

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

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

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

Практическое правило для платформенных команд

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

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

Источник и границы кейса: Asana, «Spec-driven development», 16 сентября 2026 года — первичный отчёт компании о трёх месяцах внутреннего использования. Рассматриваемая совокупность: 66 настроек Admin Console и примерно 150 миграций в общих фреймворках. Текущая документация Asana по тикетам подтверждает наличие описаний, владельцев, вложений, зависимостей и истории ревью, но не является независимой проверкой результатов кейса. Источники: https://asana.com/inside-asana/spec-driven-development и https://help.asana.com/s/article/creating-and-managing-tickets-in-command