Постановка задачи
Успех проекта зависит от множества факторов. Во главе этого списка стоит правильно поставленная задача. Для того, чтобы на выходе из идеи получить результат, который будет работать и приносить пользу, важно, чтобы все сотрудники в проекте понимали суть задачи. При этом неважно, работает сотрудник с самого начала задачи или подключился недавно. Задача должна быть понятна на всех уровнях.
В моем отделе на культурном уровне есть такое понятие, как «понимание задачи». Понимание задачи — когда задача формулируется на языке бизнеса, а не на языке «хотелок» или «было бы здорово это сделать».
Пока задача не будет принята обеими сторонами и не будет понятно, что делать, хотя бы первый шаг, никто не приступит к работе. Этот процесс занимает длительное время. Постановка задачи — одна из самых важных отправных точек, по которой можно предположить, какой будет результат проекта.
Как распознать факап проект
В иных случаях, а такие периодами происходят, так как внедрение такого подхода в культуру компании — это тяжелый труд, мы сталкиваемся с бесполезными продуктами на выходе. Отчасти от бездумной концентрации внимания на самой задаче, а не над ее смыслом. Такие проекты сразу заметны по критериям:
— Нет определенного ответственного
— Нет конкретного первого шага в рамках задачи
— Отсутствие понимания для чего нужно решить эту задачу
— Долго тянется, либо вообще не оговорен дедлайн
Читатель может возразить, что не все специалисты знают, какая должна быть структура у лендинга, или как должен выглядеть дизайн макет. Поэтому не смогут обозначить первый шаг или понять сроки. Но для начала не нужно так глубоко копать, важнее ориентироваться на вопросы, которые на старте помогут понять задачу и ее выхлоп.
Чаще всего в работе непонимание появляется, когда приходит задача откуда-то «сверху» и воспринимается, как обязательная к выполнению.
Для того, чтобы снять этот барьер, есть алгоритм с вопросами, которые нужно задать.
Алгоритм понимания задачи
Если вы хорошо поймете задачу, у вас получится хороший проект.
Как происходит понимание задачи в нашем отделе на примере разработки лендинга.
Понимаю задачу
Сначала подробно описываем текущую ситуацию.
О чем будет лендинг?
Как клиент попадает на него?
Какие решает задачи?
Можно ли решить эту задачу без лендинга?
Как будем измерять успех?
Совместно с аналитиком выбираем ключевые метрики и, как правило, ставятся количественные цели, но не всегда
Пример:
Маркетолог хочет делать лендиг экскурсий по элитной недвижимости на автобусах. Идея класс, но такие клиенты не готовы трястись в микроавтобусе три часа подряд, к ним нужен индивидуальный подход и личные встречи. Спрашиваем, зачем нам лендинг: что должно измениться? Почему благодаря сайту клиентам станет хорошо?
Естественно решение мы придумываем совместно
Маркетолог и интернет-маркетолог пишут подробный план.
После он проходит через апруф ведущего специалиста моего отдела и дизайнера. Накидывается быстрый макет на А4 листе с содержанием, и тут же определяется mvp проекта. Согласовывается.
Сроки и ответственность
Это крайний пункт для условий и договоренностей, у каждого проекта есть свой дедлайн, ответственный со стороны интернет-маркетинга + инициатор проекта. Ответственный должен помочь членам команды не сойти с верного пути и напоминать о том, каким должен быть конечный результат.
Вывод
Печально, когда происходит так, что дизайнер или интернет-маркетолог, менеджер, не разобравшись в задаче, приступает к ее выполнению. За этим стараемся следить и приступать к работе, когда задача разжевана и понятна на всех уровнях.
Означает ли это, что если вы всегда будете следовать по алгоритму понимания задачи, то не будет факапов? Нет. Часто так происходит, что даже уже после выяснения нюансов задачи, она все равно не понятна, но, так как задача стоит, ее продолжают делать, вместо того, чтобы найти контраргументы и доказать ее бессмысленность. Рядом всегда полно задач, которые не менее важные, но более понятные, решение которых даст большую отдачу для бизнеса.
Как рекомендация: больше всего внимания и времени уделяйте пониманию задачи и тому, ЧТО делать. Дальше все станет намного яснее.
P.S.
В ближайшем будущем планируем допилить формат и использовать — Job Stories. Если не слышали, что это, то вот ссылка JTBD — Jobs to be Done.
Если совсем вкратце: описание того, зачем, для достижения чего именно люди разрабатывают продукт.
[ КОГДА Я ___ ], [ Я ХОЧУ ___ ], [ЧТОБЫ Я СМОГ ___ ].
Ситуация-мотивация-результат
Это следующий уровень, так как Job stories всегда должны быть основаны на результатах исследования.
