Поверхностная оценка задачи
Даже с опытными разработчиками такое случается: вначале кажется, что задача не займет много времени, а когда приступают к непосредственной реализации, оказывается, что не всё так просто.
Что думают про оценку задач наши коллеги?
💬При оценке я использую три основных критерия. Первый – выделенные ресурсы на решение задачи: есть ли все доступы, полное ли ТЗ и т.п. Второй – организация труда: приоритет задачи, необходимость коммуникаций в процессе её выполнения, бизнес-процессы и прочее. Третий – объём работ. Потом добавляю еще 30% времени на издержки: срочные созвоны, дополнительные вопросы, «падающие метеориты», попадание в «вечное Цукуёми» и другое.
Карина, frontend-разработчик

В помощь руководителю проекта, тимлиду, владельцу продукта
Как выглядят тревожные сигналы:
▪️ Задача выходит из запланированной оценки, исполнитель передвигает сроки.
▪️ Увеличились коммуникации по задаче у разработчика и аналитика или автора задачи.
▪️ Отмечается более двух возвратов одной задачи с тестирования или приёмки автором задачи.
▪️ В более чем 30% задач из бэклога нет описания или оно очень скудное.
Что делать в этой ситуации? Наиболее популярные методы:
▪️ При планировании обсуждать подводные камни задачи и задавать вопросы, всё ли понятно при реализации.
▪️ Подготовить шаблон задачи с минимальными сведениями, которые нужно указать в задаче.
▪️ Просить вести обсуждения не устно и в личных переписках, а в задаче.

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