Четырёхнедельный проект, растянувшийся на десять недель, редко теряет шесть недель из-за плохого кода. Он теряет их в ожидании — решения, согласования, человека с нужным логином, чтобы его прислать, ответа на вопрос, четыре дня провисевший во входящих. Время разработки и календарное время — это два разных таймера, и на большинстве отстающих проектов разрыв между ними — это почти целиком время, когда никто фактически не писал код.
Решения — самое частое узкое место
Разработчик, дошедший до развилки — два разумных способа реализовать функцию, каждый со своими последствиями, — должен остановиться и спросить, потому что неправильная догадка стоит дороже, чем вопрос. Если этот вопрос неделю висит без ответа, потому что нужно согласование человека, который в командировке, весь проект встаёт за ним, хотя реального объёма оставшейся работы это не меняет. Назначение одного человека с полномочиями отвечать на такие вопросы и согласованный максимальный срок ответа устраняют это узкое место до того, как оно возникнет.
Задержки с доступом стоят дороже, чем кажется
Проект, которому нужны учётные данные для платёжного процессора, регистратора доменов или существующей системы, часто не может продвинуться дальше определённой точки без них — а эти данные часто находятся у третьей стороны, бывшего сотрудника или человека, которому нужно напомнить дважды. Неделя, потерянная в ожидании сброса пароля, функционально идентична неделе, потерянной на проблеме с кодом, за исключением того, что её можно было полностью избежать, если бы доступы собрали до старта проекта, а не запрашивали по мере возникновения потребности.
Задержка обратной связи накапливается по всему проекту
Раунд обратной связи, приходящий за три дня вместо одного, стоит не два дня один раз — он стоит два дня на каждой точке проверки в проекте, а таких точек в большинстве проектов несколько. Команда, изначально согласовавшая конкретный срок обратной связи и относящаяся к нему как к платёжному дедлайну, устраняет источник задержки, который иначе всплывает на каждой вехе, а не только на первой.
Что действительно является ответственностью разработчика
Ничто из этого не оправдывает настоящие задержки разработки — недооценённую сложность, обнаруженный технический долг или разработчика, который просто отстаёт от графика: это реальные вещи, и сторона исполнения обязана честно ими управлять и о них сообщать. Но смешивание задержки, вызванной неотвеченным вопросом, с задержкой, вызванной сложным кодом, приводит к применению неправильного решения — дополнительные часы разработчика не ускорят проект, реально ожидающий решения со стороны клиента, сколько бы их ни добавили.
Различать эти две причины важно
Определение категории задержки в момент, когда она происходит, а не на разборе полётов постфактум, — вот что позволяет проекту реально вернуться в график, вместо того чтобы все молча согласились не соглашаться, чья это была неделя.
Это часть того же разговора купить, построить или настроить — хорошо управляемая разработка держит график только если обе стороны следят за часами, которые реально идут, а не только за теми, что измеряют код.
Наша команда разработки устанавливает ожидания по срокам ответа и требования к доступам до начала проекта, чтобы недели, иначе теряемые в ожидании, просто не случались.
