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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Потратить достаточно времени на анализ

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

    Не забываем учитывать время на самотестирование, отладку, релиз и возможные риски. Погрешность в оценке задачи должна быть не более 20 %.
  1. Максимально вникнуть в контекст задачи

    Без этого невозможно правильно заложить время.

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

    Если ТЗ расплывчатое и непонятно, что надо делать, — идите к заказчику, старшему разработчику, тимлиду и задавайте вопросы, пока не поймете, что именно от вас нужно.
  1. Д е к о м п о з и р о в а т ь 

    Если по предварительной оценке задача займет больше 10 часов, разбейте ее на подзадачи.

    Два условия:

    1) Подзадача занимает не более 6 часов. Тут, как и в любом правиле, есть исключения, поэтому руководствуйтесь опытом и здравым смыслом.

    2) У подзадачи есть финальный результат. Вспоминаем джедайские техники: «Формулировка задачи должна звучать как ответ на вопрос „что нужно сделать?“».
  1. Описать, как будете решать задачу, учитывая возможные риски

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

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

  1. Поискать решение в интернете и внутренней базе знаний.
  1. Подключить старшего разработчика/тимлида или коллегу, у которого была такая задача.
  1. Проанализировать себя по «Светофору». Тут остановимся подробнее.

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

  1. Заранее предупредить менеджера, что нужно переоценить время — до того, как выработали больше 50 % от первичной оценки.
  1. Аргументировать, почему задача займет больше времени. Можно в таком формате:
  • Что уже сделано по задаче.
  • Что именно не учли в первичной оценке.
  • С какими проблемами столкнулись в процессе.
  • Сколько еще времени необходимо для решения.

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

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


Intensa — производственное агентство для e‑commerce.

Мы помогаем торговым сетям увеличивать выручку интернет-магазинов за счет быстрой и отлаженной аутсорс-разработки.

Какие задачи мы решаем
You May Also Like

Как мы построили процесс разработки

Командная работа в среде разработчиков неизбежно влечет проблемы с прочтением чужого кода, его перетиранием, неподходящим по статусам таск-трекером. В статье рассказываем, как…

Развертывание фронтенд проекта на Heroku

В этой статье учимся разворачивать фронтенд приложения на PaaS-платформе Heroku. Heroku — облачная платформа для размещения веб-приложений. Легко масштабируется, интегрируется с docker…