Самая дорогая ошибка в проекте редко выглядит как катастрофа. Обычно она звучит вполне разумно: - Давайте пока не будем поднимать этот вопрос. - Сначала продвинемся, потом разберёмся. - Не хочется сейчас тормозить команду. - В крайнем случае поправим на тестировании. После таких фраз совещание заканчивается вовремя, никто не спорит, а статус остаётся зелёным. Через несколько месяцев выясняется, что проект всё это время двигался не туда. Мне приходилось видеть разные ошибки: неверные оценки, слабые требования, неудачные архитектурные решения, смену приоритетов перед релизом. Но самой дорогой почти всегда оказывалась одна и та же. Руководитель вовремя не остановил работу, хотя уже понимал, что у участников проекта нет общего представления о результате. На одном сложном интеграционном проекте одновременно работали несколько команд. Аналитики описывали процессы, разработчики реализовывали сервисы, внешние участники готовили свои части интеграции. Все были заняты. Задачи двигались. Статусы обновлялись. При этом каждая команда представляла конечное решение по-своему. Для одних внешний сервис должен был передавать готовые данные. Для других — только идентификатор, по которому мы сами должны были получить всю информацию. Одна команда считала определённый сценарий обязательным. Другая была уверена, что он относится к следующему этапу. В документах противоречие почти не бросалось в глаза. Формулировки были достаточно общими, чтобы каждый мог прочитать их в свою пользу. Первые сигналы появились рано. На встречах снова возникали одни и те же вопросы. Оценки уточнялись. В задачах появлялись временные решения. Аналитики договаривались с разработчиками напрямую, чтобы не ждать общего ответа. Каждый такой компромисс казался небольшим и полезным. Команда не останавливалась. Сроки формально не сдвигались. Именно поэтому никто не хотел произносить неприятную фразу: Мы не готовы продолжать разработку, пока не договоримся о том, что именно строим. Остановка проекта всегда выглядит плохо. Особенно перед заказчиком или руководством. Намного приятнее показать движение: выполненные задачи, новые экраны, работающий API. Проблема в том, что движение и прогресс - не одно и то же. Можно очень быстро двигаться в неправильную сторону. Когда противоречие стало невозможно игнорировать, значительная часть работы уже была выполнена. Пришлось менять модель данных, контракты взаимодействия, логику сервисов и повторно проводить тестирование. Но дороже всего стоил не код. Код можно переписать. Гораздо дороже обошлось время нескольких команд, которые месяцами решали разные задачи, считая, что работают над одним продуктом. После этого проекта я стал осторожнее относиться к фразе: - Давайте пока примем рабочее допущение. Рабочее допущение полезно только тогда, когда оно зафиксировано, назначен ответственный и понятен срок решения. В противном случае это не допущение. Это долг, проценты по которому ежедневно оплачивает вся команда. Чаще всего руководитель проблему видит. Но надеется, что она разрешится по ходу работы. Боится потерять темп. Не хочет обострять отношения. Не хочет сообщать наверх, что план придётся пересмотреть. Команда справляется: сначала временными решениями, потом ручными обходами, затем переработками по вечерам. И только ближе к релизу становится понятно, какую цену все заплатили за нежелание вовремя провести один тяжёлый разговор. Сейчас я стараюсь не спрашивать: - Кто виноват? Гораздо полезнее спросить: - В чём именно наши представления о результате различаются? Иногда руководителю нужно остановить движение, собрать людей, принимающих решения, зафиксировать противоречия, выбрать один вариант и только после этого возвращать задачи в работу. Это может стоить недели. Но альтернатива иногда стоит нескольких месяцев. Самая дорогая ошибка - слишком долго делать вид, что решение уже принято. А вам приходилось останавливать работу, когда проект формально ещё выглядел вполне благополучно?