Почему «сделай, как я бы сделал» — это плохой бриф в IT
На первый взгляд это кажется разумным: «Я всё знаю, ты просто повтори». Но в реальности такая установка ломает процесс с самого начала.
Во-первых, «как я бы сделал» — максимально абстрактная конструкция. Даже если вы идеальный тимлид, который пишет код во сне, у исполнителя другой стек, другой опыт и, сюрприз, другой взгляд на задачу. Вместо ясности он получает нервный квест: догадайся, что у шефа в голове.
Во-вторых, такая подача убивает инициативу. Без свободы выбора в подходах, инструментах и решениях человек теряет интерес к работе. Он не предлагает альтернативы и, вероятно, снова вернет вам задачу уже не с багами, а с безразличием. А значит, делегирование как процесс провалилось.
Хуже всего, когда вы описываете каждый шаг: от названия переменной до названия коммита. В одном проекте, где я консультировал команду, тимлид расписывал разработчикам всё до мельчайших деталей. Казалось бы, забота. Но в итоге продукт тормозил, багов было больше, а разработчики увольнялись. Вместо делегирования там был ручной контроль. Вместо роста — выгорание.
Тут вы можете заметить: в статье про SMART я писал, что вот так и нужно ставить задачи! Нет, не так, и дальше я раскрою, почему SMART не противоречит делегированию, а помогает.
Формула качественного делегирования: контекст + результат + свобода действий
Хорошее делегирование — это всегда структура. Формула простая, но часто нарушается хотя бы в одном пункте. Чтобы задачу не возвращали обратно, передавать ее нужно через три фильтра: контекст, результат и свобода действий.
Контекст
Первое, что должен знать человек, получающий задачу, — зачем она вообще нужна. Не просто «сделай кнопку» или «пересчитай метрику», а что стоит за этим: улучшение UX, оптимизация конверсии, выполнение SLA, запуск в проде через два дня.
В IT-задачах без контекста легко попасть в ловушку «всё ок, но…». Разработчик может реализовать красивую архитектуру, но не ту бизнес-логику. Аналитик — построить шикарный дашборд, который никто не поймет. Потому что им не объяснили, зачем всё это.
Результат
После контекста — четкий ориентир удачного выполнения. Конкретный deliverable:
- Рабочий API, покрытый автотестами.
- Прототип с возможностью клика по ключевым сценариям.
- Таблица с анализом за три месяца + презентация по инсайтам.
Результат — это не про работу над задачей, а про то, что именно должно быть готово. Без этого задача либо зависнет, либо вернется на уточнение, либо вы получите от исполнителя классическое «я подумал, что нужно вот так…».
Контекст и ожидаемый результат должны быть четко описаны по SMART, а вот следующий пункт позволяет простую постановку задачи превратить в делегирование.
Свобода действий
И наконец, не путайте делегирование с диктовкой. Не превращайте задачу в набор шагов: сначала установи библиотеку X, потом назови переменную Y.
У ваших сотрудников другой подход и опыт. Позвольте им использовать их и делайте акцент на результате, а не пути к нему. Особенно это важно, когда вы работаете с сильными исполнителями. Они сами знают, как лучше.
Пример:
Плохое делегирование:
«Сделай импорт данных, как в прошлый раз, через pandas, файл в той же папке, потом график построй в seaborn».
Уже лучше:
«Нужно построить дашборд по загрузке серверов за последние три месяца. Цель — понять, насколько инфраструктура справляется с пиковыми нагрузками. Формат: интерактивный график + CSV-выгрузка. Как реализуешь — на твое усмотрение, главное, чтобы было понятно бизнесу».
Главное отличие: во втором случае вы передаете не только выполнение задачи, но и ответственность за решение. То есть человек получает право самостоятельно выбирать подход, инструменты и порядок действий, чтобы достичь нужного результата. Это именно делегирование: вы позволяете исполнителю самому искать оптимальный путь к цели и отвечать за итог.
В простой постановке задачи вы говорите, что сделать и как именно, оставляя за собой контроль и принятие ключевых решений.
Примеры делегирования в IT
Разработчики
Если вы ставите разработчику задачу сделать фичу, дайте ему:
- бизнес-контекст (зачем фича);
- четкий результат (что именно должно работать на выходе);
- свободу реализации в рамках оговоренных технических ограничений.
Хорошо:
«Нужно добавить загрузку изображения в карточку товара. Это улучшит конверсию по категориям с визуальными товарами. На выходе: загружаемый файл с превью, ограничения по размеру и форматам, адаптив на мобилках. Бэк у нас на FastAPI, фронт на React. Подход выбирай сам, главное — в прод через пять дней».
Плохо:
«Сделай, как у конкурентов. Там у них прикольно, тоже лоадер такой, ну ты поймешь. И только через input type=file, а не drag’n’drop».
Проджекты
Управление проектом не равно держать каждого за руку. Чтобы делегировать задачи и не контролировать каждый шаг, хороший проджект:
- рассказывает, какие цели и сроки критичны;
- что можно двигать, а что нет;
- где ждать рисков и к кому идти за поддержкой.
Пример:
«В этой итерации главное — выпустить отчетность по новому API для партнеров. Все остальные задачи вторичны. Команда частично в отпуске, поэтому нужна подстраховка по ресурсам. Продакт — Марина, ей можно писать напрямую».
Аналитики и QA
Для аналитиков и тестировщиков важны:
- конкретные метрики и цели анализа;
- понимание, как это повлияет на продукт;
- доступ к нужным источникам данных или окружению.
Пример:
«Проверь, падает ли конверсия в заказ у пользователей с Android 14. Есть подозрение, что у них баг в оформлении. Данные в GA4 и ClickHouse, можно запросить логи у backend. Нужен ответ к пятнице в цифрах и гипотезах».
Как делегировать, чтобы задачи не возвращали обратно
Даже самый толковый разработчик или аналитик не спасет ситуацию, если с задачей изначально что-то не так. Возврат задач — это почти всегда не про «плохо сделали», а про «не договорились на старте». Как же этого избежать?
Устанавливайте четкие ожидания с самого начала
Никаких «там разберешься». Чем понятнее критерии, тем меньше шансов, что задачу придется возвращать на доделки. Вот что должно быть минимум в любой более-менее серьезной таске:
- Acceptance-критерии (что значит «готово»).
- Документация или хотя бы примеры использования.
- Ожидания по качеству (например, unit-тесты, линтер, перформанс на уровне).
Даже короткий список критериев снимает половину рисков. Когда у задачи есть явная точка завершения, никто не тратит время на додумывание.
Контроль, а не микроменеджмент
Следить важно. Контролировать каждый чих — зло. Команда должна понимать, когда результат нужен, что сроки реальны и что задача актуальна. Но никто не обязан писать отчет каждые четыре часа.
Хорошо работает формула: доверие + прозрачность. Вместо «ну как там дела?» — открытый прогресс в трекере, доступ к ветке кода или тестовой версии. Вместо «давай-ка я сам проверю» — автотесты и CI/CD.
Промежуточная обратная связь — ваше всё
Задача делится на логические части? Проверьте первую, прежде чем человек углубится в детали. Это можно встроить в ежедневные стендапы, демо на середине спринта или в условие задачи. Или попросите показать промежуточный результат через два дня.
Так вы поймаете проблему до того, как задача упрется в стену, и не потеряете время на рефакторинг уже сделанного.
Пример хорошего сценария
Разработчику дали задачу с четким описанием, критериями готовности, ссылкой на UI-макет и тестовые данные. Он показал промежуточную версию на стендапе, получил фидбэк, учел замечания. Тикет закрыт, все счастливы.
Плохой сценарий
Задача звучала как «почини загрузку файлов». Ни логов, ни примеров, ни понимания, что именно не работает. Через три дня разработчик возвращает решение, но «не то». Начинается пересылка таски туда-сюда. В итоге — потерянные дни и раздражение по обе стороны.
Заключение
Делегирование — это навык, который требует структуры, доверия и ясности.
Кратко:
- Не говорите «сделай, как я», дайте человеку понять задачу, а не процесс.
- Давайте исполнителю контекст, ожидаемый результат и свободу действий.
- Уточняйте критерии и цели до старта, а не после.
- Доверяйте, но не теряйте из виду.
- Проверяйте вовремя, пока не поздно.
Когда всё это работает, задачи не возвращаются, команда работает быстрее, а вы, наконец, начинаете заниматься тем, чем действительно должны.
