Как научиться правильно определять сроки выполнения работы — отвечает эксперт «Аэроклуб ИТ»

IT-издание Tproger пригласило Варвару Новожилову, руководителя направления анализа данных в «Аэроклуб ИТ», ответить на вопрос от читателя: «Как научиться правильно определять сроки выполнения работы — отвечают эксперты».

«В нашей компании планирование задач всегда проходит несколько этапов. На стороне бизнеса мы формулируем 5–6 стратегических целей на год. Это высокоуровневые задачи, например повысить какой-либо параметр на столько-то процентов. Далее различные подразделения компании формируют бизнес-задачи на все команды ИТ. Сроки по этим задачам получают первичную грубую оценку, которая часто формируется всеми участниками команды — менеджером, аналитиком, разработчиком и тестировщиком. Получив эту оценку, бизнес приоритезирует задачи, учитывая стратегические цели компании. В этом помогают сквозные стратегические цели, с ними становится очевидно, что все мы работаем на какое-то общее дело, нет такой ситуации, когда кто-то тянет только в свою сторону. Из точно оцененных по срокам задач мы собираем спринты. У некоторых команд они квартальные, у некоторых — месячные. Нескольким задачам, по предварительной оценке попадающим в следующий спринт, команды дают точную оценку. Крупные задачи разбиваются на более низкоуровневые, за каждую из которых отвечает конкретный исполнитель, именно он и даёт точную оценку.

На данном этапе важно не забывать добавлять запас времени на исправление багов, ведь не ошибается только тот, кто ничего не делает. Это прекрасно понимают и Product Owner, и бизнес-заказчики. При этом требуемый запас времени должен быть адекватным: никто не поймёт разработчика, который поставит простой задаче слишком длинный срок исполнения, его попросят обосновать решение. Самое сложное — объяснить бизнесу, зачем нужно время на рефакторинг. Мы благодарны нашей компании за то, что периодически нам это удаётся, ведь в конечном счёте рефакторинг ведёт к облегчению инфраструктуры и наведению порядка в коде, что повышает стабильность системы и может существенно ускорить разработку новых функций.

Иногда ошибки в оценке всё же возникают. Отделу разработки в крупных компаниях с развитой инфраструктурой полностью избежать этого, на мой взгляд, невозможно. В данном случае важно, чтобы разработчик вовремя информировал о происходящем своего менеджера, а тот, в свою очередь, успел предупредить бизнес и что-то «переиграть» в общих планах компании. В таком режиме работать намного более правильно, чем судорожно пытаться сделать за 3 дня то, что занимает 5, а потом утонуть в большом количестве ошибок, возникших из-за подобной спешки».

Узнать мнение других экспертов можно на портале Tproger