Как оценивать сроки задач в IT-проектах?

Случалось ли у вас так, что сроки, которые вы установили на выполнение задачи, странным образом удлинялись? Вроде бы вы делали все быстро, не отвлекались на посторонние дела, а все возможные “форс-мажоры” заранее просчитали? Что ж, это вполне распространенное явление, особенно в IT-среде, где рассчитать время на решение задачи в точности до часа не всегда представляется возможным.

Возникает вопрос, как в таком случае определить сроки, если заказчик требует дать четкий ответ? Как уложится в эти сроки и, главное, зачем их нужно ставить, если ваша команда — это профи, которые знают свое дело?

Об этом, а также о том, как мы решаем такую задачу в собственном проекте - в статье.

Когда вы прикидываете, сколько времени у вас уйдет на фичу, вы рискуете ошибиться в расчетах и столкнуться с недовольством заказчика. Несоответствие изначальных сроков с реальными кроется в том, что мы привыкли оценивать время в “идеальных часах”. В IT-сфере существует специальный термин - estimate. Это то время, которое требуется для выполнения задачи в идеальных условиях.

Приведем простой пример из жизни. Вам нужно прочитать книгу для завтрашней презентации перед партнерами. В книге - 200 страниц. В среднем на одну страницу у вас уходит одна минута. Сколько времени уйдет на книгу? Руководствуясь простыми правилами математики, мы получим ответ: 3 часа, 20 минут. Вуаля!

Спустя 3 часа 20 минут….

Мы оказались всего лишь на 133 странице. Такая нестыковка произошла, потому что мы не учли ряд факторов:

• залезали в словарь(или Google), чтобы узнать значение новых терминов;
• обращались к сноскам;
  
• читали дополнительную информацию по теме;
  
• созванивались с коллегами;
  
• выписывали интересные мысли автора в заметки;
  
• перечитывали абзац несколько раз, чтобы лучше усвоить материал.
  

Все эти манипуляции отдаляли нас от “идеальных часов”. Получается, определить реальные сроки не получится? Ведь каждый раз мы сталкиваемся с разными отвлекающими факторами. На самом деле нет. Это вполне возможно.

При оценке сроков айтишники руководствуются несколькими правилами. Сначала мы оцениваем идеальное время (estimate), далее умножаем на коэффициент 1,5 (это среднее значение, которое может отличаться в зависимости от задачи и личного опыта) и на выходе получаем - реальные часы. В зависимости от реальных часов и значимости, мы приоритизируем наши задачи. Получается, что к выполнению задачи мы приступаем не сразу.

Отсюда мы получаем еще один термин, нужный для просчета сроков - Due date. Это день, к которому должна быть выполнена задача. Due date получается из сложения задержки в старте задачи с реальными часами, которые мы тратим на ее выполнение.

Если говорить о коэффициентах, то тут важно понимать две вещи:

• Поскольку одну задачу могут выполнять несколько человек, коэффициент учитывает не только личные потери, но и потери командные, и у каждой команды он свой.
• При выполнении задачи нужно стремиться каждый раз сокращать коэффициент. Например, если команда ограничила срок задачи одним днем, а выполнила ее за два, то коэффициент равен двум. Важно, чтобы в следующий раз команда выполнила такую же задачу за полтора дня, сократив таким образом коэффициент до 1,5.
  

Очень важно отталкиваться от своего личного опыта и смотреть на задачу ретроспективно. Таким образом, мы из раза в раз будем оценивать сроки более точно.

На самом деле, если нет понимания, для чего вы ставите дедлайн, сроки могут скорее навредить, чем принести пользу.

• Во-первых, вы теряете свободу действий. Если вы пообещали заказчику, что сделаете фичу за два дня, а в процессе разработки поняли, что лучше делать ее в конце, вам будет трудно убедить заказчика в перестановке планов. Он уже настроился на другой результат.
• Во-вторых, вы рискуете проиграть в качестве. Правило “умри, но сделай” обычно работает, но будьте готовы к тому, что результат может оказаться неудовлетворительным.
  

Не подумайте, никто не говорит о том, что сроки вообще не нужны. Мы говорим скорее о том, что лучше гибко подходить к дедлайнам, если их сдвиг не повлечет за собой серьезных потерь для проекта. Качество всегда дороже, особенно если ваша команда — сеньоры со стажем.

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

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

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

• Не стремитесь угнаться за “идеальным временем”. Мы не роботы, и выполнять задачу дольше, чем компьютер - вполне нормально.
• Всегда задумывайтесь, зачем вам или вашему заказчику нужны сроки. Если нет важной причины выполнить работу к конкретной дате, может следует подойти более гибко?
  
• При оценке времени пользуйтесь коэффициентом и каждый раз старайтесь его сокращать.
  
• Сроки - хорошая метрика профессионализма команды и успешности ее работы, но в тот момент, когда скорость выполнения задачи становится целью, качество может серьезно пострадать.