Программисты делятся на два типа: «человеко-часы» и «человеко-результаты». А теперь серьезно. Проблема сроков в IT существует давно, и единой формулы до сих пор не выработано. В этой статье мы рассмотрим основную причину и подскажем, как работать со сроками правильно.
В чем проблема
Оценивать задачи не нравится никому. Одно дело, если задача типичная, проект родной и давно изученный и все баги учтены. Другое — новый проект, задача «с чужих рук», незнакомый код и… И:
– За сколько ты это сделаешь?
– А на когда надо?
– А надо было на вчера.
В такой ситуации автоматически называется самый оптимистичный прогноз. А потом срываются сроки или выгорает специалист. Это ошибка в общении — менеджера и разработчика. Лечится она путем выстраивания адекватной обратной связи. Примерно такой:
– Надо было на вчера.
– Васильич, дай мне два часа, я посмотрю, что там внутри, и скажу.
А у Васильича должна быть возможность спросить, почему над разработкой корзины для интернет-магазина у него просят неделю, хотя по прошлому проекту справились за три дня.
При этом, если в оценке сроков программист ошибся, он не должен чувствовать себя как на расстреле. Нужна система «кризисных» мер. К примеру, заложенное лишнее время или возможность заморозить пару соседних проектов без срыва сроков по ним.
Второй вопрос — как оценивать сроки правильно
1. Найдите минимальную единицу измерения
Только никаких минут и очень аккуратно с часами. Если у вас отдел разработки — самым удобным будет формат не менее половины рабочего дня. Если задача рутинная, привычная и программисты ее уже неоднократно выполняли.
Система оценки в рабочих днях более точная и дает нужный буфер времени на форс-мажоры. К тому же учитывает часть типичных рисков, о которых мы поговорим ниже.
2. Ставьте задачу грамотно
Задача менеджера — добиться внятного ТЗ от заказчика. Без него даже с самыми точно угаданными сроками задача рискует сорваться. К примеру, задача «Хочу, чтобы в личном кабинете можно было просмотреть и скачать историю покупок» такой не является. К запросу должны прилагаться:
- Критерии приемки
- Важные детали
- Дизайн
Пример четко и правильно поставленной задачи:
Хочу, чтобы в личном кабинете можно было просмотреть и скачать историю покупок. Нужна возможность выбирать период и получать документ в формате, совместимом с Excel 2007 и выше.
Дизайн формы экспорта прилагаю. Критерии приемки задачи следующие.
- Кнопка экспорта доступна
- При нажатии на кнопку экспорта появляется таблица с возможностью выбрать нужный период
- По завершении выбора периода пользователю предлагается скачать файл на диск
- Отчет формируется не больше 25 секунд
3. Оцените риски
Все, что может пойти не так, — обязательно пойдет не так. Поэтому отдельным пунктом стоит заложить от двух часов до половины рабочего дня на оценку сложности задач и возможных рисков в процессе.
Если попался идеальный проект с чистым кодом, понятной архитектурой, простой интеграцией с посторонними сервисами — можно смело называть оптимистичные сроки. Но каждая возможная сложность — это плюс 20–40% времени.
Сюда же стоит отнести все типичные случаи срыва сроков и оценить уже их.
Чек-лист прилагаем.
- Бонусные хотелки от заказчика в процессе работы и/или нечеткое ТЗ.
- Заказчик несвоевременно предоставляет нужны данные, и работа стоит из-за отсутствия дизайна, неутвержденных этапов, неправильного файла загрузки и т. д.
- В процессе вы столкнулись с задачей, которую не увидели при оценке. И кажущееся «поменять три строки и готово» превратилось в пол рабочего дня поиска, почему почта на сайте не работает.
- Болезни, семейные проблемы, выгорание специалистов.
- Часть команды не сделала работу вовремя, а задачи взаимозависимы.
Пункты 1–3 закладываются в оценку рисков. Четвертый относится к форс-мажорам, и нужен инструмент объяснения с заказчиком. Что же касается последнего… Здесь есть короткий рецепт.
4. Разбейте проект на подзадачи
Когда у вас есть задача «разработать таск-менеджер», это очень большой кусок торта. Его следует разбить на куски поменьше. Важно: независимые друг от друга!
Если у вас есть горящая задача и вы разбросали ее выполнение между разными специалистами, то у них должна быть возможность сдать свой кусок работы и сразу же проверить его на жизнеспособность. Поправить баги, внести изменения. И все это не дожидаясь своих коллег. Не только из-за экономии времени. А еще по причине, что любое изменение к части работы А может потянуть с собой изменение в части работы Б. В итоге вы получите необходимость переделывать все заново.
Так все же — часы или задачи?
А вот здесь все зависит от вашего поля деятельности. Фриланс и аутсорсинг удобнее мерить часами (днями) работы. Клиенту важно знать когда, и уйти от этой системы будет очень сложно.
Если же вы стабильно работаете над одним и тем же проектом или взялись разрабатывать конкретный продукт — логичнее оценивать сложность и отвечать на вопрос, сколько потребуется ресурсов на реализацию и какие плюс-минус полкилометра можно заложить в проект.
Выводы
Универсальной системы, как мы уже видим, нет. Дедлайны разработчикам ставить приходится, но делать это стоит гибко. Учитывая два важных фактора:
1) Правильная оценка времени;
2) Возможность корректировать дедлайн.
А как ставишь дедлайны ты? Ставь лайк и делись в комментариях.