Почему задачи выполняют долго

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

Задача готова

1. Задача готова, но про нее забыли на стадии ревью или тестирования. Такое бывает, когда задач много или у задачи неправильный статус.
2. Задача готова, но до нее не доходят руки из-за недостаточно высокого приоритета задачи (задача потерялась среди др. задач, которые имеют такой же приоритет). Решение казалось бы очевидное - отсортировать задачи по дате (старые задачи вылезут вперед), но так почему-то не делают
3. Задача готова, но не хватает глаз, чтобы поревьювить код или не хватает рук, чтобы протестировать код (нехватка ресурсов, задач много - людей мало, или людей набрали - идет процесс обучения/адаптации, а работать некому)

Задача вернулась

1. Задача вернулась аналитику т.к. требует доработки требований, которые выявлены в процессе разработки (задача изначально недостаточно описана, выявлены моменты которые ны были очевидными)
2. Задача вернулась с ревью (задача была плохо спланирована с архитектором/руководителем отдела/тимлидом/старшим специалистом или не была вовсе согласована)
3. Задача вернулась с тестирования т.к. пока велась разработка - изменились бизес-требования к задаче (изменившиеся нужно делать новой задачей, возможно в следующем эпике, иначе задача может никогда не закончится)
4. Задача вернулась с тестирования т.к. сотрудник неправильно понял ТЗ (часто такое бывает, когда ТЗ было описано недостаточно подробно)
5. Задача вернулась с тестирования т.к. новый код ломает текущую функциональность (нужно обсудить с разработчиком, чтобы он поддерживал обратную совместимость, например API для старых клиентов должно работать как и раньше)
6. Задача вернулась с деплоя из-за проблем слияния (код "протух" и вызывает конфликты - такое бывает, когда над одним функционалом работает несколько разработчиков или задачу забыли, следовательно ветку давно не актуализировали, а надо бы не забывать)

Задача задерживается

1. Разработчик реализует эпик (стек задач), следовательно обязательна последовательность выполнения задач, без первой задачи нельзя начинать вторую, потому что если начать вторую, а первая не пройдет ревью или тестирование, то придется вносить правки и в первой и во второй (хорошо когда в эпике только 2 задачи, но когда их много, то это как снежный ком). Решением в этом случае может быть реализация сразу всех задач стека в виде одной задачи и затем уже ревью и тестирование.
2. Сотрудник не знаком с инструментами, техниками и технологиями, которые будет использовать для реализации задачи (рассчитывая время выполнения задачи, нужно учесть время на ознакомление)
3. Тесты на новый функционал еще не написали (нужно заблаговременно выделять время на написание тестов)
4. Отдел тестирования может не иметь опыта в тестировании определенных задач (например тестирование крон-задач). Решение: подготовить план тестирования и заложить больше времени на выполнение задачи.
5. Хаос в бизнес-процессах, работа аналитиков не согласована (знания о процессах не описаны, не упорядочены, не наглядны, недостаточны, избыточны на верхних уровнях - слишком много деталей)
6. Профессиональный уровень сотрудника ниже, чем ожидаемый (сотрудник допускает большое кол-во ошибок и нарушает договоренности в команде, требуется время на обучение, можно закладывать некий процент на оцененное время, например умножая на 200%)
7. Задача на устранение ошибки не имеет логов, или имеет логи, но невозможно найти их связь с действиями клиента (на глаза тех. долг или инфраструктурные проблемы, например нет агрегации логов)
8. Инфраструктурные проблемы сотрудников компании (такая ситуация часто возникает у удаленщиков/аутсорсеров/фрилансеров и решается только компетентными кадрами)
9. Поломанный CI/CD или его отсутствие, нет стратегии деплоя и отката сложных задач
10. Редкий деплой, в следствии чего сложно понять, что могло некорректно повлиять на бизнес-процесс (нужно деплоить чаще, хотя бы: раз в 1-2 недели)
11. Кол-во критичных ошибок в приложении не позволяет выкладывать код новой задачи (нужно выделять больше времени на технический долг, больше уделять стабильности, безопасности)
12. На проде внезапно возникают инфраструктурные проблемы, например: бд тормозит, жесткий диск полностью заполнен (нужен более детальный мониторинг с прогнозированием, нагрузочное тестирование)
13. Некоторолируемые права доступа, например: всем сотрудникам дают доступ на запись в бд продакшена, в результате рано или поздно возникает случайное удаление/изменение данных.
14. Закрытие технического долга или рефакторинг занимает слишком много времени в следствии того, что приходится поддерживать код, который никем уже не используется. Решение - иметь статистику вызова функций кода.
15. Неучтенный отпуск/болезнь сотрудника или коллеги, который может проконсультировать по деталям реализации задачи (рассчитывая время не полагайтесь, что нужный сотрудник будет рядом)
16. Руководство сменилось / меняется политика разработки продукта, с новым процессом/инструментами текущие сотрудники незнакомы (требуется обучение, которое требует время)
17. Сотрудник не мотивирован работой (перегружен задачами, не конкурентно-способная зп, неприятный коллектив, плохое рабочее место и т.п., в следствии возможно уже созрело решение о смене работы)
18. Сотрудник видит и уподобляется руководителю, который слишком лояльно/безалаберно относится к своей работе (решение - замотивировать или сменить руководителя)
19. Отделы компании плохо содействуют друг другу, так называемая стена (нужно больше коммуникаций, развитие коммандного духа)

Задача отложена

1. Руководство изменило приоритеты задачам, в следствии чего, задача которая уже в работе и даже почти выполнена, может быть отложена

Важно: употребяя термин "сотрудник", я имею ввиду не только нижне звено, но и вышестоящее руководство.

Конечно, в этом списке представлены не все проблемы, поэтому, для тех, кто хочет серьезно подойти к стабильности и производительности в компании, я советую обратить внимание на ITIL (а именно на десять базовых процессов, которые описаны в IT Service Management (ITSM))

Пожалуйста, поделитесь ситуациями из свой жизни, а я постараюсь их оформить в данной статье.

Дополнительно по теме: 1 - 2 - 3