Как формулировать задачи в проекте
Про роль технического задания или брифа, почему исполнитель не дурак и как нормально ставить задачи — команда сервиса WEEEK делится опытом
Поручаешь исполнителю задачку. Вроде всё объяснили — должно быть ясно, как там да что. А он приходит с вопросами, сомнениями, и в итоге выдаёт совсем не то, что нужно. Не факт, что проблема в исполнителе. Чаще всего источник проблемы — в постановке задачи. Рассказываем, как это делать, чтобы было всё нормально.
Ставим ТЗ на минималках — без методик определения целей и задач
Чтобы человек понял, что от него требуют, надо не полениться написать техническое задание. То есть описать в любом виде требования к результату.
Зависит от задачи, но чаще всего сложные документы и таблицы не нужны. Вот минимальный набор необходимого в ТЗ:
- Что нужно сделать? Опиши результат, который нужен
- Когда нужно сделать? Поставь дату, в которую спросишь результат
- Как желательно это сделать? Обрисуй оболочку результата: размер, цвета, шрифты, формат и прочее
- С помощью каких ресурсов? Дай доступы к программам, выдай брендбук, назначь помощника
- Добавь референсы, примеры конкурентов, источники
Получится довольно ёмкий и простой в составлении документ. Такое техзадание в состоянии снять большинство вопросов у исполнителя.
Уточняющие вопросы по содержанию и попытки показать промежуточные результаты из разряда «Как сделать лучше?» или «Нашёл ошибку в источниках», проблемы с доступами, риск срыва сроков — всё это ТЗ не покроет. Это нормальные вопросы, на них надо отвечать в процессе совместной работы.
Такое ТЗ стоит давать исполнителю всякий раз — вместе с задачей. Если он умеет читать мысли, можно не давать.
Когда без ТЗ точно не обойтись
- Если человек делает задание впервые. Начинающий сотрудник и так в стрессе, он в себе не уверен, не знает своих сил. ТЗ поможет понять, что от него хотят.
- Когда делегируешь процесс. Если надо, чтобы кто-то сделал работу прямо как ты «скопировал-вставил», опиши процесс так, как ты его делаешь, и дай все вводные.
- При работе с подрядчиком на аутсорсе. Давать задание стороннему исполнителю без прописанного ТЗ — какой-то дурной тон. Человеку будет некомфортно приходить с частыми вопросами к едва знакомому заказчику. В целом любой уважающий себя исполнитель на аутсорсе сам придёт к заказчику с брифом. Задача заказчика тут — постараться понять, что ему самому надо, и не полениться потратить время на толкование своих ожиданий и требований. Ещё это страховка от прений.
- Да никогда не обойтись. Тебе же всегда важно, чтобы работа была сделана максимально хорошо с первого раза, с минимальным количеством итераций и к сроку? А если исполнитель уже на опыте, то ТЗ получится короче — и времени на него уйдёт меньше.
В каких программах писать ТЗ и где ставить задачу
Техзадание — обычно текстовый документ. Так что прописать задание можно:
- в заметках, чтобы потом отправить исполнителю в мессенджере или по почте. В такой заметке можно добавить ссылки на ресурсы, указать дату.
- в Google Docs, чтобы отправить ссылку исполнителю. Опять же, внутри надо прописать содержание задачи и дедлайн.
- в таск-менеджере, где под задачу формируется отдельная карточка. Суть задачи выносят в название карточки, а внутри прописывают само техзадание. Карточке присваивается дата — дедлайн.
А вот где ставить задачу — вопрос с распространённым ответом.
Если в компании практикуется чат-менеджемент — когда задачи ставятся в чатах, и всё планирование ведётся там — то это и есть канал постановки задачи. Учти, что есть риск потерять задачу, особенно если в чате много исполнителей. Попроси получателя-исполнителя закрепить у себя задачу, чтобы этого не случилось.
Идеально использовать для постановки задач таск-менеджеры. Там ничего не потеряется, а программа сама даст знать о приближении дедлайна.
Исполнителю на аутсорсе удобнее всего отправить ТЗ по почте — или, опять же, в мессенджере. При таком раскладе ничего не потеряется, ведь две стороны общаются только друг с другом. А со своей стороны задачу уже можно зафиксировать в таск-менеджере, блокноте или на стикере.
❗Любые задачи и ТЗ нужно фиксировать в письменном виде. Исполнитель будет возвращаться и перечитывать его, снимая новые вопросы. И документ застрахует вас от недопониманий — решает проблемы с я вам такого не обещал, вы не просили, откуда это взялось, кто вам такое сказал.
Всё-таки одна методика формулирования задачи будет
Это известная методика SMART. Штука довольно нудная — согласно ей, каждая задача или цель должна быть сформулирована как конкретная (S — specific), измеримая (M — measurable), достижимая (A — Achievable), нужная или релевантная (R — relevant), cо сроком (T— time-bound).
В реальном мире мало кто так прописывает задачи — хотя каждая из них этими атрибутами обладает. Смотри:
- Конкретная задача — чтобы человек понял. Здесь пригодятся глагол и существительное. Написать текст, сделать баннер, сверстать макет мобильного приложения. Без сленга, зауми и сокращений.
- Измеримая — почти любой результат можно измерить, так что задачу стоит конкретизировать численным показателем. Написать текст на 20 000 знаков, сделать один баннер, сверстать макет трёх стартовых экранов мобильного приложения.
- Нужная — классно, если человек понимает, зачем он будет делать задачу. Просто для себя, мотивации и понимания своей ценности. А ради компании и её бизнес-целей вообще мастхев. Написать текст «Злые овощи» на 20К знаков для научно-популярного журнала, чтобы раскрыть тему исследования пестицидов. Сделать один баннер для рекламы на 8 марта. Сверстать макет трёх стартовых экранов для мобильного приложения, чтобы отработать флоу и передать их разработчикам.
- Со сроком — к когда надо сделать. Определить адекватный дедлайн можно в диалоге, с опорой на опыт и потребности обеих сторон. Для начала задай исполнителю вопрос: «Сколько времени тебе нужно?»
- Достижимая. Имеется в виду, что человек может сделать эту задачу. То есть у него есть соответствующий опыт и ресурсы, а сроки адекватны. Нереально написать текст на 20 000 знаков за день, сделать баннер в айдентике компании без брендбука, сверстать макет мобильного приложения за два часа.
Чтобы каждый раз не заморачиваться, вспоминая расшифровку SMART-метода, просто запомни, что любая задача должна обладать конкретикой, достижимостью, важностью, измеримостью — и сроком.
Получится относительно короткое и простое ТЗ — а большинство вопросов оно снимает.
Помни святую истину: «Без ТЗ — результат ХЗ!» — и всё нормально будет. А если ищешь инструмент для управления задачами, изучай WEEEK
клиент не всегда прав) не всегда знает все нюансы работы и порой просто просит невозможного) ПОэтому нужно уточнять и советоваться
когда с клиентом дело имеем — да. С работой на аутсорсе это вообще сложно. А вот внутри команды руководитель просто обязан уделять время ТЗшкам. Потом спрашивать, как понята задача. На вопросы отвечать. И, кстати, если сотрудник-исполнитель косячит, то имеет смысл и данное ТЗ, и поставленную задачу в первую очередь пересмотреть, а потом уже и другие проблемы искать
От правильной постановки задачи зависит многое. Как вообще пойдёт проект. Ну и самое важное это постановка сроков выполнения. Чтобы было чёткое понимание и осознание того, что необходимо исполнить к определённому сроку. Это дисциплинирует выполнение работы, определяет приоритетные задачи, которые нужно выполнить в первую очередь.
под каждым словом! 🙏🏻