Препирательства из-за сроков возникают потому, что кому-то они кажутся завышенными; редко кто сочтет их заниженными.

Часто бывает, что участники проекта, которые слабо разбираются в его технической стороне и мало что знают о кодовой базе, ставят под вопрос сроки, озвученные командой, приводя аргументы вроде: «Нет, здесь меньше работы!» Их цель – продавить команду, чтобы она согласилась на лучшие для них условия, то есть более сжатые сроки. Когда разработчики и другие участники проекта вступают в подобные споры, предполагающие, что о сроках можно торговаться, это приводит к утрате доверия и другим неприятным последствиям в будущем.

В конце концов, после продолжительного ворчания, утверждаются какие-то новые сроки, которые готовы принять обе стороны. При этом стороны, как правило, остаются недовольны, у всех появляется ощущение, что они чем-то поступились. Больше всего при этом страдает самый ключевой участник проекта – бизнес, потому что в компании утвердились искаженные ожидания относительно того, сколько времени понадобится на передачу продукта клиентам.

Цитаты, которые я привел, взяты из статьи «Не пускаем ли мы деньги на ветер, требуя от разработчиков развернутого обоснования сроков?» В своей же статье я объясню, почему внешние участники, требующие урезания сроков без предоставления новых фактов, которые могли бы повлиять на объем работ, совершают ошибку. Также я расскажу, как разработчики могут направить разговор с этими участниками в значительно более продуктивное русло.

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

Почему так и в каком направлении следует переводить разговор?

Дело в том, что метеоролог не контролирует погоду. Он просто использует свои знания и собранные данные чтобы строить прогнозы, какой она будет. Подобным же образом команда разработчиков не контролирует, какими будут трудозатраты – разве что чуть-чуть. Разработчики используют знания и данные в своем распоряжении, чтобы определить ожидаемый объем работ. Они опираются на скорость выполнения задач, которую обычно показывает команда, смотрят показатели по завершенным проектам и с каждым спринтом стараются оттачивать процесс.

Что я подразумеваю под «разве что чуть-чуть»? Команда может перескочить через некоторые этапы процесса и выдать продукт менее высокого качества. Применять такие практики не рекомендуется – впоследствии команде, возможно, придется дорого заплатить за свой выбор стратегии. Кроме того, команде всегда доступны те или иные способы повысить скорость выполнения задач. Тем не менее, рассчитывая примерные сроки, нужно исходить из текущего положения дел, а не из предполагаемых результатов в будущем.

Возможно, кто-то скажет вам: «Ну, значит, вам нужно иногда задерживаться на работе». Если подобные разговоры ведутся в вашей компании, задумайтесь, не пора ли сменить работу. Почему? Потому что работать в таких условиях – верный путь в катастрофе, в чем можно убедиться на примере многих разработчиков.

Иными словами, техническая команда практически никак не может повлиять на то, сколько работы потребует от нее имплементация заданного набора функций. В следующий раз, когда кто-нибудь начнет рассуждать о заявленных вашей командой сроках, требуя их сократить и не предлагая никаких способов снизить трудозатраты, спросите этого человека: «А метеорологу вы тоже скажете: “Нет, ваш прогноз на завтра меня не устраивает, с таким я к клиентам не пойду, давайте мне что-нибудь получше”?»

В такой «логике» нет никакого смысла. Между тем, существует и более здравый подход к обсуждению сроков.

Написание программ – дело сложное, и зачастую оно занимает больше времени, чем предполагалось. Исходя из этого, сторонние участники нередко ожидают, что объем работ будет меньше, чем он оказывается на самом деле, и отводить на него больше, чем определенный период, представляется им нецелесообразным. Что делать в таких ситуациях?

При подобном раскладе обсудите с участниками проекта следующее:

1. Узнайте, сколько времени допустимо потратить на функциональность
2. Объясните, какие этапы имплементации займут больше всего времени
3. Опишите основные непредвиденные обстоятельства, которые могут возникнуть
4. Обсудите, как можно скорректировать подход с учетом второго и третьего пунктов

Также обсудите, какие возможности есть для:

1. дробления функциональности, чтобы выкатить ее в несколько приемов;
2. ранней валидации каждого компонента, желательно на стадии прототипа.

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

В следующей статье мы разберем, как отвечать на конкретные вопросы вроде:

1. К какому времени вы сможете реализовать такую-то функциональность?
2. Что сможете представить к концу следующего квартала?
3. Можно ли довести такую-то функциональность до готовности к концу следующего квартала?