Привет!

Давайте начнём с самого начала — с точки, где всё только зарождалось. Разберём стартовый этап нашего проекта через призму методологии STAR (Situation, Task, Action, Result).

Situation (Ситуация)

В далёком 2019‑м году нашей команде из трёх разработчиков достался «в наследство» код от другого специалиста — назовём его Основателем. В следующих постах станет ясно почему.

Ключевые особенности ситуации: * Хаотичная кодовая база: Основатель экспериментировал с популярными на тот момент технологиями (ReactiveCocoa, VIPER и т. д.), создавая «лабораторию» в продуктовом коде — без документации и стандартов; * Устаревший код: приложение было написано на версии SDK, которую Apple отказывалась принимать в App Store уже через полгода — это грозило остановкой релизов; * Отсутствие процессов: не было стандартов кодирования, описания функционала, регламентов разработки и тестирования. * Высокий уровень ошибок: в конце каждого двухнедельного спринта разработчики получали список из 10–20 багов по свежеразработанному функционалу — на их исправление уходило до нескольких дней, что затягивало сроки релизов и вызывало недовольство бизнеса.

Task (Задача)

Перед нами встали следующие задачи: 1. Стабилизировать процесс разработки, чтобы сократить количество регрессионных багов, время на их исправление и общее время регресса до 1 дня. 2. Снизить зависимость от индивидуальных компетенций, создав документацию и стандарты кодирования — чтобы новые сотрудники могли быстрее разбираться в коде. 3. Выстроить базовую систему контроля качества, чтобы минимизировать появление критических ошибок в релизе (цель — не более 1–2 критических багов за спринт на разработчика). 4. Сохранить работоспособность приложения, обновив кодовую базу и продолжить выпуск нового функционала, несмотря на унаследованный технический долг. 5. Подготовиться к потенциальному росту команды — заложить основы масштабируемых процессов, чтобы при увеличении штата до 20+ разработчиков не потерять управляемость.

Action (Действия)

Мы предприняли следующие шаги: 1. Введение 20% технического времени; 2. Модуляризация проекта; 3. Стандартизация практик разработки; 4. Разработка и внедрение дизайн-системы; 5. Внедрение код‑ревью внутри команды; 6. Документирование архитектуры, процессов, функционала; 7. Внедрение юнит-тестов.

Кратенько о выполненных действиях я уже писал на Хабре и более детально планирую описать в этом канале в рамках проведения ретроспективы. Самые нетерпеливые могут ознакомиться со статьей уже сейчас.

Result (Результаты)

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

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

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

Не переключайтесь.