Как формулировать задачи в проекте

Про роль технического задания или брифа, почему исполнитель не дурак и как нормально ставить задачи — команда сервиса WEEEK делится опытом

Поручаешь исполнителю задачку. Вроде всё объяснили — должно быть ясно, как там да что. А он приходит с вопросами, сомнениями, и в итоге выдаёт совсем не то, что нужно. Не факт, что проблема в исполнителе. Чаще всего источник проблемы — в постановке задачи. Рассказываем, как это делать, чтобы было всё нормально.

Чтобы человек понял, что от него требуют, надо не полениться написать техническое задание. То есть описать в любом виде требования к результату.

Зависит от задачи, но чаще всего сложные документы и таблицы не нужны. Вот минимальный набор необходимого в ТЗ:

• Что нужно сделать? Опиши результат, который нужен
• Когда нужно сделать? Поставь дату, в которую спросишь результат
• Как желательно это сделать? Обрисуй оболочку результата: размер, цвета, шрифты, формат и прочее
• С помощью каких ресурсов? Дай доступы к программам, выдай брендбук, назначь помощника
• Добавь референсы, примеры конкурентов, источники

Уточняющие вопросы по содержанию и попытки показать промежуточные результаты из разряда «Как сделать лучше?» или «Нашёл ошибку в источниках», проблемы с доступами, риск срыва сроков — всё это ТЗ не покроет. Это нормальные вопросы, на них надо отвечать в процессе совместной работы.

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

• Если человек делает задание впервые. Начинающий сотрудник и так в стрессе, он в себе не уверен, не знает своих сил. ТЗ поможет понять, что от него хотят.
• Когда делегируешь процесс. Если надо, чтобы кто-то сделал работу прямо как ты «скопировал-вставил», опиши процесс так, как ты его делаешь, и дай все вводные.
• При работе с подрядчиком на аутсорсе. Давать задание стороннему исполнителю без прописанного ТЗ — какой-то дурной тон. Человеку будет некомфортно приходить с частыми вопросами к едва знакомому заказчику. В целом любой уважающий себя исполнитель на аутсорсе сам придёт к заказчику с брифом. Задача заказчика тут — постараться понять, что ему самому надо, и не полениться потратить время на толкование своих ожиданий и требований. Ещё это страховка от прений.
• Да никогда не обойтись. Тебе же всегда важно, чтобы работа была сделана максимально хорошо с первого раза, с минимальным количеством итераций и к сроку? А если исполнитель уже на опыте, то ТЗ получится короче — и времени на него уйдёт меньше.

Техзадание — обычно текстовый документ. Так что прописать задание можно:

• в заметках, чтобы потом отправить исполнителю в мессенджере или по почте. В такой заметке можно добавить ссылки на ресурсы, указать дату.
• в Google Docs, чтобы отправить ссылку исполнителю. Опять же, внутри надо прописать содержание задачи и дедлайн.
• в таск-менеджере, где под задачу формируется отдельная карточка. Суть задачи выносят в название карточки, а внутри прописывают само техзадание. Карточке присваивается дата — дедлайн.

А вот где ставить задачу — вопрос с распространённым ответом.

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

Исполнителю на аутсорсе удобнее всего отправить ТЗ по почте — или, опять же, в мессенджере. При таком раскладе ничего не потеряется, ведь две стороны общаются только друг с другом. А со своей стороны задачу уже можно зафиксировать в таск-менеджере, блокноте или на стикере.

❗Любые задачи и ТЗ нужно фиксировать в письменном виде. Исполнитель будет возвращаться и перечитывать его, снимая новые вопросы. И документ застрахует вас от недопониманий — решает проблемы с я вам такого не обещал, вы не просили, откуда это взялось, кто вам такое сказал.

Это известная методика SMART. Штука довольно нудная — согласно ей, каждая задача или цель должна быть сформулирована как конкретная (S — specific), измеримая (M — measurable), достижимая (A — Achievable), нужная или релевантная (R — relevant), cо сроком (T— time-bound).

В реальном мире мало кто так прописывает задачи — хотя каждая из них этими атрибутами обладает. Смотри:

• Конкретная задача — чтобы человек понял. Здесь пригодятся глагол и существительное. Написать текст, сделать баннер, сверстать макет мобильного приложения. Без сленга, зауми и сокращений.
• Измеримая — почти любой результат можно измерить, так что задачу стоит конкретизировать численным показателем. Написать текст на 20 000 знаков, сделать один баннер, сверстать макет трёх стартовых экранов мобильного приложения.
• Нужная — классно, если человек понимает, зачем он будет делать задачу. Просто для себя, мотивации и понимания своей ценности. А ради компании и её бизнес-целей вообще мастхев. Написать текст «Злые овощи» на 20К знаков для научно-популярного журнала, чтобы раскрыть тему исследования пестицидов. Сделать один баннер для рекламы на 8 марта. Сверстать макет трёх стартовых экранов для мобильного приложения, чтобы отработать флоу и передать их разработчикам.
• Со сроком — к когда надо сделать. Определить адекватный дедлайн можно в диалоге, с опорой на опыт и потребности обеих сторон. Для начала задай исполнителю вопрос: «Сколько времени тебе нужно?»
• Достижимая. Имеется в виду, что человек может сделать эту задачу. То есть у него есть соответствующий опыт и ресурсы, а сроки адекватны. Нереально написать текст на 20 000 знаков за день, сделать баннер в айдентике компании без брендбука, сверстать макет мобильного приложения за два часа.

Чтобы каждый раз не заморачиваться, вспоминая расшифровку SMART-метода, просто запомни, что любая задача должна обладать конкретикой, достижимостью, важностью, измеримостью — и сроком.

Получится относительно короткое и простое ТЗ — а большинство вопросов оно снимает.

Как начать записывать задачи и что делать, если лень

Как команда ушла от миллионов чатов к таск-менеджменту