Перепрыгнуть пропасть на 90%

В проектных командах, и особенно в корпорациях, обожают процессы. Скрам, канбан, SAFe — чем больше аббревиатур, тем круче.

Но когда доходит до простого вопроса «что значит задача выполнена?», обычно начинается цирк.

Разработчик говорит: «Фича готова на 90%». Проджект-менеджер радостно кивает, ставит галочку и докладывает об успехе. А потом два месяца допиливают эти последние 10%.

Знакомая ситуация?

В реальности, если задача «готова на 90%» — она не готова вообще. Точка. Нельзя перепрыгнуть пропасть на 90% — либо ты на другой стороне, либо на дне.

Оставшиеся 10 % — это столько же, сколько ушло на первые 90%

Мне кажется, что 8 из 10 разработчиков уверены, что все сделали, когда:

— «Ну там код написан»,

— «Плюс-минус работает у меня на локалке»,

— «Осталось причесать».

Вот тут и появляется опасная иллюзия. Оставшиеся «10%» — это не пропорциональная часть работы.

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

Так вот, закрытие этих последних процентов требует столько же времени, сколько ушло на предыдущие 90% готовности. Иногда и больше.

→ А вот когда мы накопили пачку задач с 90% готовностью, неминуемо наступает коллапс тестирования и приемки: финальные стадии превращаются в хаотичное тушение пожаров вместо плановой проверки, срывая сроки и деморализуя команду, заказчика и стейкхолдеров.

Дефинишн оф дан

Нормальная работа в команде начинается с определения, что такое «готово».

Начинать нужно с гигиены.

Не «код написан», а: «Код написан, функционально протестирован, интегрирован, покрыт документацией, прошел ревью, соответствует стайлгайду».

Соответственно, дефинишн оф дан есть для всего:

— Дизайна (все состояния, адаптивы, UI-кит или дизайн-система)

— API (контракты, обратная совместимость, обработка ошибок, документация)

— Деплоя (мониторинг, логи, откаты)

Приемка на каждом этапе

Сделал фичу — показал техлиду. Прошел код-ревью — показал QA. Прошел тесты — показал заказчику. На каждом этапе — четкие критерии приемки.

Взгляд бизнеса

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

Нормальные менеджеры и QA думают строго категориями продукта и бизнеса.

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

Итого

Мой опыт как проджекта — нулевая толерантность к «почти готово»: задача имеет только два статуса — «Выполнена» или «Не выполнена».

Перестаньте прыгать через пропасть на 90%. Требуйте 100%.

«Почти готово» — главная причина, почему вы не укладываетесь в сроки.

→ Подписывайтесь на Telegram Илхом, глянь плз

5
1 комментарий