Как оценивать время на задачи по разработке

За первый квартал мы улучшили КПД по оценке задач с 76 до 86%. Стремимся к 95%. В статье рассказываем, как закладываем время на задачи, — даже с которыми не сталкивались.

Если нет времени читать, — в конце чек-лист для анализа задач.

Почему мы неправильно оцениваем задачи 

Недостаточно опыта

Проблема джунов. Если не знаем, сколько времени закладывать и как решать задачу: 1) гуглим решение, 2) идем к тимлиду просить помощи. Но сначала гуглим.

Излишняя самоуверенность

Тоже часто у джунов. В этом случае рекомендуем:

• Работать над осознанностью и адекватно оценивать свои силы и прошлый опыт.
• Советоваться со старшими коллегами. Да, придется потеснить самолюбие.
• Возложить на себя ответственность за действительно классный результат — сместить фокус на качество, а не на скорость.
• Глубже погрузиться в задачу — возможно, катка не так уж и изи.

Заказчик меняет требования к задаче

Здесь важно фиксировать все изменения.

Например, изначально вы заложили 10 часов на задачу. В процессе требования менялись. Результат = 30 затраченных часов. Но никто не помнит, почему закладывали 10, а получилось 30.

Если все зафиксировать, то вопросов не возникнет. Или, как минимум, будет меньше.

Не учли подводные камни на проекте

Как это бывает: изучили задачу, какое-то время поработали над ней и понимаем — что-то не так все просто.

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

Важно: делать переоценку нужно в середине задачи, а не в конце.

Иначе будет так:

— Коллеги, ну что, вы проверили, корректно ли приходят данные из CRM-системы?
— Извините, нужно еще время. В процессе выяснилось, что интеграции между сайтом и CRM нет.

Мало времени на анализ

Этот пункт мы подробно разбираем ниже.

Как правильно оценивать задачи

1. Потратить достаточно времени на анализ
   
   Анализ должен занимать 5—15 % от общего времени на задачу. Например, если задача занимает 5 часов, на ее оценку нужно потратить не меньше 25 минут.
   
   Не забываем учитывать время на самотестирование, отладку, релиз и возможные риски. Погрешность в оценке задачи должна быть не более 20 %.

2. Максимально вникнуть в контекст задачи
   
   Без этого невозможно правильно заложить время.
   
   Если проект новый, обязательно прочитайте документацию — больше времени сэкономите в процессе. Заодно поищете подводные камни. Лучше узнать о них сейчас, чем потом.
   
   Если ТЗ расплывчатое и непонятно, что надо делать, — идите к заказчику, старшему разработчику, тимлиду и задавайте вопросы, пока не поймете, что именно от вас нужно.

3. Д е к о м п о з и р о в а т ь 
   
   Если по предварительной оценке задача займет больше 10 часов, разбейте ее на подзадачи.
   
   Два условия:
   
   1) Подзадача занимает не более 6 часов. Тут, как и в любом правиле, есть исключения, поэтому руководствуйтесь опытом и здравым смыслом.
   
   2) У подзадачи есть финальный результат. Вспоминаем джедайские техники: «Формулировка задачи должна звучать как ответ на вопрос „что нужно сделать?“».

4. Описать, как будете решать задачу, учитывая возможные риски
   
   Так сразу поймете, есть ли у вас решение. И проджекту полезно — сможет аргументировать клиенту, почему задача занимает 100 часов, а не 5, как он планировал.

Как оценить задачу, с которой не сталкивался 

1. Поискать решение в интернете и внутренней базе знаний.

2. Подключить старшего разработчика/тимлида или коллегу, у которого была такая задача.

3. Проанализировать себя по «Светофору». Тут остановимся подробнее.

Метод «Светофор» 

Авторская техника руководителя отдела разработки Ивана Шишкина. В том числе помогла повысить КПД по оценке на 8 % — эффективность проверена нашими ребятами.

В чем суть: нужно оценить, на каком «свете» вы стоите.

На красном, если:

• раньше не сталкивались с подобной задачей;
• не видите конечный результат;
• не понимаете, что именно нужно делать.

На желтом, если:

• уже сталкивались с похожей задачей;
• не сталкивались, но видели решение на «Хабре»;
• есть примерное, но не полное понимание, как делать задачу.

На зеленом, если:

• уже решали такую задачу;
• знаете, как будете делать;
• понимаете, какой нужен результат;
• в прошлом успешно решили проблемы, которые возникали в процессе.

Закрепим инфографикой.

1, 2 и 3,5 — это коэффициенты. В зависимости от того, на каком вы «свете», умножьте первоначальную оценку задачи на соответствующий коэффициент.

Пример:

1. Упала задача, которую вы никогда не делали, не понимаете финальный результат и конкретные шаги решения = вы на красном.

2. Погуглили решение.

3. Идете к коллеге, который уже сталкивался с такой задачей, и спрашиваете, сколько у него это занимает времени. Он говорит: «Ну, где-то часа 4».

4. Умножаете 4 на 3,5 = 14. Примерно столько часов вам потребуется, чтобы решить задачу.

Когда нужно делать переоценку 

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

Здесь есть несколько условий.

1. Заранее предупредить менеджера, что нужно переоценить время — до того, как выработали больше 50 % от первичной оценки.

2. Аргументировать, почему задача займет больше времени. Можно в таком формате:

• Что уже сделано по задаче.
• Что именно не учли в первичной оценке.
• С какими проблемами столкнулись в процессе.
• Сколько еще времени необходимо для решения.

Чек-лист для анализа задач по разработке 

• Выделять на анализ не менее 5 % от времени, которое заложено на саму задачу.
• Максимально вникнуть в контекст задачи. Если условия непонятные, обсудить их заказчиком, старшим разработчиком/тимлидом.
• Изучить техническую документацию для новых проектов.
• Если неясно, как делать задачу, сначала поискать решение задачи в интернете/базе знаний.
• Если кажется, что задача займет больше 10 часов, разбить ее на подзадачи. Подзадача занимает не больше 6 часов (есть исключения).
• Описать подробные шаги, как решать задачу. У каждой подзадачи должен быть результат.
• Учитывать в оценке время на самотестирование, релиз и отладку.