Как правильно создавать задачи: чек-лист и шаблон описания

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

1. Главное правило

Задача — это конкретное действие с понятным результатом.

• Плохо: «Разобраться с сайтом».
• Хорошо: «Исправить ошибку 404 на странице /pricing до 15 октября».

Если формулировка звучит как тема для размышления («подумать», «разобраться», «оптимизировать») — это не задача, а проект или исследование. Его нужно разбить.

2. Обязательные элементы задачи

Минимальный набор, без которого задача считается «сырой»:

• Название — что сделать: глагол + объект + результат.
• Описание — контекст, детали, критерии готовности.
• Исполнитель — кто отвечает.
• Дедлайн — когда должно быть готово.
• Приоритет — насколько срочно и важно.
• Проект или список — где эта задача живёт.
• Статус — на каком этапе; по умолчанию «Нужно сделать».

Дополнительно, по необходимости:

• Чек-лист — шаги выполнения.
• Вложения — файлы, скриншоты, ссылки.
• Теги — для фильтрации.
• Оценка времени — сколько займёт.
• Зависимости — что должно быть сделано до.
• Наблюдатели — кого уведомлять.
• Критерии приёмки — как проверить, что готово.

3. Как формулировать название

Глагол в инфинитиве + объект + результат или уточнение.

Примеры:

• «Подготовить коммерческое предложение для клиента X».
• «Исправить отображение кнопки на мобильной версии».
• «Позвонить поставщику и уточнить сроки поставки».
• «Написать статью о новых функциях (1500 слов)».

Чего избегать в названии:

• Общих слов: «Сделать», «Проверить», «Улучшить» — без объекта.
• Вопросов: «Почему не работает форма?».
• Двух действий в одном: «Написать и согласовать текст» — это две задачи.
• Технического жаргона, если исполнитель не в теме.

Проверка: прочитайте название вслух. Если коллега спросит «а что именно?» — переформулируйте.

4. Что писать в описании

Хорошее описание отвечает на четыре вопроса:

1. Зачем — какая цель, какой контекст.
2. Что именно — детали, требования, ограничения.
3. Как понять, что готово — критерии приёмки.
4. Где взять информацию — ссылки, файлы, контакты.

Шаблон описания:

Контекст: [почему это нужно]
Что сделать: [конкретные шаги или требования]
Результат: [что должно быть на выходе]
Критерии готовности: [чек-лист проверки]
Материалы: [ссылки, файлы, доступы]

Пример:

Контекст: клиент жалуется, что не может оплатить подписку с мобильного.
Что сделать: проверить форму оплаты на iOS и Android, воспроизвести ошибку.
Результат: список шагов воспроизведения + скриншоты + гипотеза причины.
Критерии готовности: ошибка воспроизведена, описание передано разработчику.
Материалы: тикет #4521, доступ к тестовому аккаунту в менеджере паролей.

5. Чек-лист перед созданием задачи

Пройдитесь по пунктам:

• Название начинается с глагола и понятно без контекста.
• В задаче одно действие или один результат.
• Указан исполнитель.
• Указан реалистичный дедлайн.
• Указан приоритет.
• Есть описание или хотя бы ссылка на контекст.
• Понятно, как проверить, что задача выполнена.
• Нет скрытых подзадач, которые лучше вынести отдельно.
• Задача не дублирует существующую.
• Если задача большая — она разбита на подзадачи.

Если хотя бы половина пунктов не отмечена — задача создана «на бегу» и вернётся к вам с вопросами.

6. Декомпозиция: когда задача слишком большая

Признаки, что задачу пора разбить:

• Нельзя выполнить за один подход — больше 1–3 дней.
• Внутри несколько разных результатов.
• Требует участия разных людей.
• Нельзя оценить срок.
• Непонятно, с чего начать.

Пример декомпозиции. Плохо: «Сделать лендинг». Хорошо:

1. Собрать требования у заказчика.
2. Написать текст лендинга.
3. Сделать дизайн-макет.
4. Сверстать страницу.
5. Подключить форму заявки.
6. Протестировать на мобильных.
7. Опубликовать и проверить аналитику.

Каждая подзадача — отдельная карточка со своим исполнителем и сроком.

Правило: если задача не помещается в голову целиком — делите.

7. Оценка и сроки

• Не ставьте дедлайн «на вчера» — это демотивирует и обесценивает планирование.
• Оценивайте время реалистично: если кажется, что 2 часа — ставьте 4. Опытные люди знают про «закон Паркинсона».
• Учитывайте зависимости: если задача ждёт дизайн, дедлайн не может быть раньше готовности дизайна.
• Буфер: на непредвиденное закладывайте 20–30 %.
• Если срок неизвестен — ставьте дату «уточнить к …», а не выдумывайте.

8. Приоритеты

Простые системы:

• Высокий / Средний / Низкий.
• Матрица Эйзенхауэра: срочно-важно, важно-несрочно, срочно-неважно, несрочно-неважно.
• MoSCoW: Must / Should / Could / Won't.

Правило: у задачи должен быть один приоритет. Если всё «высокий» — приоритета нет.

9. Типичные ошибки

• «Разобраться с …» — нет результата. Добавьте конкретное действие и критерий.
• Два действия в одной задаче — непонятно, когда закрывать. Разбейте на две.
• Нет исполнителя — задача «висит». Назначьте ответственного.
• Нет дедлайна — не делается никогда. Поставьте дату или хотя бы неделю.
• Описание «см. в чате» — контекст теряется. Перенесите суть в описание.
• Задача-проект — слишком большая. Декомпозируйте.
• Дубликаты — путаница. Проверьте поиском перед созданием.
• Нет критериев готовности — споры о результате. Добавьте чек-лист приёмки.

10. Примеры: плохо и хорошо

Плохо: «Сайт»
Хорошо: «Обновить раздел "О компании" на сайте: добавить новых сотрудников и фото офиса до 20 октября».

Плохо: «Позвонить клиенту»
Хорошо: «Позвонить клиенту ООО "Ромашка" (Иван Петров) и уточнить статус оплаты счёта №45 до 12:00 пятницы».

Плохо: «Маркетинг»
Хорошо: «Подготовить план публикаций в Telegram на ноябрь: 12 постов, темы согласовать с руководителем до 28 октября».

Плохо: «Починить баг»
Хорошо: «Исправить баг: при отправке формы без email появляется ошибка 500. Критерий: форма показывает валидацию "Введите email"».

11. Шаблоны задач

Если в команде повторяются типы задач — создайте шаблоны:

• Баг-репорт: шаги воспроизведения, ожидаемое и фактическое поведение, окружение, скриншот.
• Контент: тема, целевая аудитория, ключевые слова, объём, дедлайн, ответственный за редактуру.
• Онбординг сотрудника: чек-лист доступов, задач и встреч.
• Запуск фичи: разработка → тест → документация → анонс → аналитика.

Шаблоны экономят время и не дают забыть важные детали.

12. Автоматизация при создании

Ручное создание задач — самый быстрый способ потерять детали. Передайте рутину автоматизациям:

• Форма → задача: клиент заполнил форму — карточка создалась с нужными полями.
• Email → задача: письмо на специальный адрес превращается в задачу.
• Повторяющиеся задачи: «каждый понедельник — планёрка» создаётся сама.
• Шаблон по кнопке: «Создать задачу из шаблона "Баг"».
• Автоназначение: задача с тегом «дизайн» автоматически уходит дизайнеру.

13. Культура задач в команде

• Одна задача — один ответственный. Соисполнители — в подзадачах или наблюдателях.
• Задача без исполнителя — не задача, а идея. Идеи — в отдельный бэклог.
• Не создавайте задачу, если не собираетесь её делать в ближайшее время — иначе бэклог превращается в свалку.
• Регулярно чистите: архив, дубликаты, устаревшие задачи.
• Договаривайтесь о правилах: что считается задачей, что — проектом, где что лежит.
• Комментируйте прогресс в задаче, а не в чате — контекст сохраняется.

14. Как это выглядит в реальном проекте

Ниже — проект «Лендинг «Альфа»», разложенный на задачи по правилам из статьи: понятные названия, исполнители, приоритеты, сроки и подзадачи-чек-листы. Блок интерактивный — переключайте виды, открывайте карточки и отмечайте шаги.

Короткая формула хорошей задачи

Что сделать + зачем + кто + когда + как понять, что готово.

Если все пять элементов есть — задача создана правильно. Если чего-то не хватает — либо дополните задачу, либо разбейте её на части.

И главное: задача должна быть такой, чтобы исполнитель мог начать работу без единого уточняющего вопроса. Это и есть критерий качества.