Теория vs Реальность: как ставятся и выполняются задачи в ИТ
Теория (как "должно быть")
-
Постановка задачи:
- Четкая формулировка цели
- Понимание контекста
- Указаны сроки и приоритет
- Предусмотрены риски и зависимости
- Сотрудник имеет все нужные ресурсы
- Исполнение:
- Сотрудник сразу понимает, что нужно
- Оценивает и подтверждает срок
- Выполняет в срок, без сбоев
- Вовремя отчитывается о прогрессе
- Минимум итераций и уточнений
Мифы
-
"Разработчику достаточно просто скинуть задачу в Jira"
На деле — без контекста и обсуждения даже хорошо написанное ТЗ часто понимается по-разному. -
"Оценка — 3 дня, значит через 3 дня задача будет готова"
Это не учитывает баги, отвлекающие задачи, созвоны, размытые требования. - "Если разработчик молчит, значит всё идёт по плану"
В реальности молчание часто означает, что человек или перегружен, или не уверен, или застрял.
Реальность
Как ставится задача:
-
Часто устно, "на бегу" или в виде одного сообщения:
"Надо, чтобы эта кнопка делала экспорт в PDF. Срочно." -
Без определения:
- бизнес-цели
- сценариев использования
- ограничений
- доступов или макетов
- Оценка получается "на коленке":
"Ну, часа за 4 справишься?"
Как реально исполняется:
-
В процессе выясняется:
- нет доступа к нужной библиотеке
- формат PDF не согласован
- не определено поведение в ошибочных ситуациях
- задача зацепляет другой модуль, который тоже надо менять
-
Время растягивается:
- 4 часа превращаются в 1-2 дня
- потом ещё полдня на багфиксы и уточнение
- Возникают коммуникационные накладки:
- сотрудник боится сказать, что не укладывается
- руководитель считает, что задача "простая", и злится на задержку
⚖️ Вывод
Этап | Теория | Реальность |
---|---|---|
Постановка задачи | Четкая, с контекстом | Часто размытая, неполная |
Оценка | Основана на опыте и рисках | Часто интуитивная, без запаса на сложности |
Коммуникация | Регулярные апдейты | Отсутствует или запоздалая |
Время исполнения | Строго по оценке | Почти всегда больше |
Финал | Готово и сдано в срок | Доработка, уточнение, задержки |
✅ Как улучшить
- Писать нормальные задачи: хотя бы в формате что нужно / зачем / до когда / что влияет
- Давать право на уточнение и переоценку
- Оставлять буфер по времени (20–30%)
- Регулярные короткие апдейты — лучше, чем молчание
- Не наказывать за задержки — разбирать причины
0 3
Вы должны авторизоваться, чтобы оставлять комментарии.
Комментарии ()