Что делать с дедлайнами в IT и почему они мешают жить программистам

Программисты делятся на два типа: «человеко-часы» и «человеко-результаты». А теперь серьезно. Проблема сроков в IT существует давно, и единой формулы до сих пор не выработано. В этой статье мы рассмотрим основную причину и подскажем, как работать со сроками правильно.

Оценивать задачи не нравится никому. Одно дело, если задача типичная, проект родной и давно изученный и все баги учтены. Другое — новый проект, задача «с чужих рук», незнакомый код и… И:

– За сколько ты это сделаешь?

– А на когда надо?

– А надо было на вчера.

В такой ситуации автоматически называется самый оптимистичный прогноз. А потом срываются сроки или выгорает специалист. Это ошибка в общении — менеджера и разработчика. Лечится она путем выстраивания адекватной обратной связи. Примерно такой:

– Надо было на вчера.

– Васильич, дай мне два часа, я посмотрю, что там внутри, и скажу.

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

При этом, если в оценке сроков программист ошибся, он не должен чувствовать себя как на расстреле. Нужна система «кризисных» мер. К примеру, заложенное лишнее время или возможность заморозить пару соседних проектов без срыва сроков по ним.

1. Найдите минимальную единицу измерения

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

Система оценки в рабочих днях более точная и дает нужный буфер времени на форс-мажоры. К тому же учитывает часть типичных рисков, о которых мы поговорим ниже.

2. Ставьте задачу грамотно

Задача менеджера — добиться внятного ТЗ от заказчика. Без него даже с самыми точно угаданными сроками задача рискует сорваться. К примеру, задача «Хочу, чтобы в личном кабинете можно было просмотреть и скачать историю покупок» такой не является. К запросу должны прилагаться:

- Критерии приемки

- Важные детали

- Дизайн

Пример четко и правильно поставленной задачи:

Хочу, чтобы в личном кабинете можно было просмотреть и скачать историю покупок. Нужна возможность выбирать период и получать документ в формате, совместимом с Excel 2007 и выше.

Дизайн формы экспорта прилагаю. Критерии приемки задачи следующие.

- Кнопка экспорта доступна

- При нажатии на кнопку экспорта появляется таблица с возможностью выбрать нужный период

- По завершении выбора периода пользователю предлагается скачать файл на диск

- Отчет формируется не больше 25 секунд

3. Оцените риски

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

Если попался идеальный проект с чистым кодом, понятной архитектурой, простой интеграцией с посторонними сервисами — можно смело называть оптимистичные сроки. Но каждая возможная сложность — это плюс 20–40% времени.

Сюда же стоит отнести все типичные случаи срыва сроков и оценить уже их.

Чек-лист прилагаем.

Пункты 1–3 закладываются в оценку рисков. Четвертый относится к форс-мажорам, и нужен инструмент объяснения с заказчиком. Что же касается последнего… Здесь есть короткий рецепт.

4. Разбейте проект на подзадачи

Когда у вас есть задача «разработать таск-менеджер», это очень большой кусок торта. Его следует разбить на куски поменьше. Важно: независимые друг от друга!

Если у вас есть горящая задача и вы разбросали ее выполнение между разными специалистами, то у них должна быть возможность сдать свой кусок работы и сразу же проверить его на жизнеспособность. Поправить баги, внести изменения. И все это не дожидаясь своих коллег. Не только из-за экономии времени. А еще по причине, что любое изменение к части работы А может потянуть с собой изменение в части работы Б. В итоге вы получите необходимость переделывать все заново.

А вот здесь все зависит от вашего поля деятельности. Фриланс и аутсорсинг удобнее мерить часами (днями) работы. Клиенту важно знать когда, и уйти от этой системы будет очень сложно.

Если же вы стабильно работаете над одним и тем же проектом или взялись разрабатывать конкретный продукт — логичнее оценивать сложность и отвечать на вопрос, сколько потребуется ресурсов на реализацию и какие плюс-минус полкилометра можно заложить в проект.

Универсальной системы, как мы уже видим, нет. Дедлайны разработчикам ставить приходится, но делать это стоит гибко. Учитывая два важных фактора:

1) Правильная оценка времени;

2) Возможность корректировать дедлайн.

А как ставишь дедлайны ты? Ставь лайк и делись в комментариях.