Представьте: полгода работы, сотни человеко-часов, вовлечённая команда — и в один день всё обнуляется событием, которое никто не мог предсказать. Зависимый сервис поменял контракт. Гипотеза не подтвердилась. Люди не приняли новый процесс. Звучит как редкая неудача? На самом деле это статистическая закономерность — если у вас был только один путь к цели.

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

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

На практике мы запустили несколько активностей параллельно:

1. Принуждение. Робот-контролёр не пускал код в мастер, если покрытие падало. Написал код без тестов — остаёшься с ним, в мастер он не попадёт. Обойти это нельзя — можно только написать тесты.

2. Умение. Серия обучающих занятий: теория тестирования, принципы FIRST, написание кода, совместимого с тестами (по SOLID). Робот-то заставит писать тесты, но писать-то их надо уметь — иначе получим тесты для галочки.

3. Возможность. Доскональная документация. Даже замотивированный и обученный разработчик не напишет тест, если не понимает, как устроен код. Документация снимала этот барьер — и, кстати, одновременно спасала от bus-фактора.

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

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

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

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

Здесь важно не спутать два принципа. Фокус говорит: мало целей. Параллельность говорит: к каждой цели — несколько путей. Они не противоречат: фокусируйтесь на целях, диверсифицируйте пути.

Полная история того, как мы это делали в 2022-м — с цифрами, ошибками и раскладкой по направлениям — в моей статье на Хабре.

А сколько путей к вашей текущей цели? Если ответ «один» — это не уверенность, это ставка на то, что реальность вам подчинится. А она не подчиняется почти никогда.