Как оценивать время на задачи по разработке
За первый квартал мы улучшили КПД по оценке задач с 76 до 86%. Стремимся к 95%. В статье рассказываем, как закладываем время на задачи, — даже с которыми не сталкивались. Если нет времени читать, — в конце чек-лист для анализа задач.
Почему мы неправильно оцениваем задачи
Недостаточно опыта
Проблема джунов. Если не знаем, сколько времени закладывать и как решать задачу: 1) гуглим решение, 2) идем к тимлиду просить помощи. Но сначала гуглим.
Излишняя самоуверенность
Тоже часто у джунов. В этом случае рекомендуем:
- Работать над осознанностью и адекватно оценивать свои силы и прошлый опыт.
- Советоваться со старшими коллегами. Да, придется потеснить самолюбие.
- Возложить на себя ответственность за действительно классный результат — сместить фокус на качество, а не на скорость.
- Глубже погрузиться в задачу — возможно, катка не так уж и изи.
Заказчик меняет требования к задаче
Здесь важно фиксировать все изменения.
Например, изначально вы заложили 10 часов на задачу. В процессе требования менялись. Результат = 30 затраченных часов. Но никто не помнит, почему закладывали 10, а получилось 30.
Если все зафиксировать, то вопросов не возникнет. Или, как минимум, будет меньше.
Не учли подводные камни на проекте
Как это бывает: изучили задачу, какое-то время поработали над ней и понимаем — что-то не так все просто. В этом случае нужно сделать переоценку и аргументированно объяснить заказчику, почему процесс затягивается.
Важно: делать переоценку нужно в середине задачи, а не в конце. Иначе будет так: — Коллеги, ну что, вы проверили, корректно ли приходят данные из CRM-системы?— Извините, нужно еще время.
В процессе выяснилось, что интеграции между сайтом и CRM нет.
Мало времени на анализ
Этот пункт мы подробно разбираем ниже.
Как правильно оценивать задачи
1. Потратить достаточно времени на анализ
Анализ должен занимать 5—15% от общего времени на задачу. Например, если задача занимает 5 часов, на ее оценку нужно потратить не меньше 25 минут.
Не забываем учитывать время на самотестирование, отладку, релиз и возможные риски. Погрешность в оценке задачи должна быть не более 20%.
2. Максимально вникнуть в контекст задачи
Без этого невозможно правильно заложить время.
Если проект новый, обязательно прочитайте документацию — больше времени сэкономите в процессе. Заодно поищете подводные камни. Лучше узнать о них сейчас, чем потом.
Если ТЗ расплывчатое и непонятно, что надо делать, — идите к заказчику, старшему разработчику, тимлиду и задавайте вопросы, пока не поймете, что именно от вас нужно.
3. Декомпозировать
Если по предварительной оценке задача займет больше 10 часов, разбейте ее на подзадачи. Два условия:
- Подзадача занимает не более 6 часов. Тут, как и в любом правиле, есть исключения, поэтому руководствуйтесь опытом и здравым смыслом.
- У подзадачи есть финальный результат. Вспоминаем джедайские техники: «Формулировка задачи должна звучать как ответ на вопрос „что нужно сделать?“».
4. Описать, как будете решать задачу, учитывая возможные риски
Так сразу поймете, есть ли у вас решение. И проджекту полезно — сможет аргументировать клиенту, почему задача занимает 100 часов, а не 5, как он планировал.
Как оценить задачу, с которой не сталкивался
- Поискать решение в интернете и внутренней базе знаний.
- Подключить старшего разработчика/тимлида или коллегу, у которого была такая задача.
- Проанализировать себя по «Светофору». Тут остановимся подробнее.
Метод «Светофор»
Авторская техника руководителя отдела разработки Ивана Шишкина. В том числе помогла повысить КПД по оценке на 8% — эффективность проверена нашими ребятами.
В чем суть: нужно оценить, на каком «свете» вы стоите. На красном, если:
- раньше не сталкивались с подобной задачей;
- не видите конечный результат;
- не понимаете, что именно нужно делать.
На желтом, если:
- уже сталкивались с похожей задачей;
- не сталкивались, но видели решение на «Хабре»;
- есть примерное, но не полное понимание, как делать задачу.
На зеленом, если:
- уже решали такую задачу;
- знаете, как будете делать;
- понимаете, какой нужен результат;
- в прошлом успешно решили проблемы, которые возникали в процессе.
Закрепим инфографикой.
1, 2 и 3,5 — это коэффициенты. В зависимости от того, на каком вы «свете», умножьте первоначальную оценку задачи на соответствующий коэффициент. Пример:
- Упала задача, которую вы никогда не делали, не понимаете финальный результат и конкретные шаги решения = вы на красном.
- Погуглили решение.
- Идете к коллеге, который уже сталкивался с такой задачей, и спрашиваете, сколько у него это занимает времени. Он говорит: «Ну, где-то часа 4».
- Умножаете 4 на 3,5 = 14. Примерно столько часов вам потребуется, чтобы решить задачу.
Когда нужно делать переоценку
Когда поняли, что не укладываетесь в первичный срок и/или в процессе работы заказчик поменял требования. Здесь есть несколько условий.
- Заранее предупредить менеджера, что нужно переоценить время — до того, как выработали больше 50% от первичной оценки.
- Аргументировать, почему задача займет больше времени. Можно в таком формате: что уже сделано по задаче, что именно не учли в первичной оценке, с какими проблемами столкнулись в процессе, сколько еще времени необходимо для решения.
Чек-лист для анализа задач по разработке
- Выделять на анализ не менее 5% от времени, которое заложено на саму задачу.
- Максимально вникнуть в контекст задачи. Если условия непонятные, обсудить их заказчиком, старшим разработчиком/тимлидом.
- Изучить техническую документацию для новых проектов.
- Если неясно, как делать задачу, сначала поискать решение задачи в интернете/базе знаний.
- Если кажется, что задача займет больше 10 часов, разбить ее на подзадачи. Подзадача занимает не больше 6 часов (есть исключения).
- Описать подробные шаги, как решать задачу. У каждой подзадачи должен быть результат.
- Учитывать в оценке время на самотестирование, релиз и отладку.
