Как запускать проекты и спать спокойно

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

Если вы проджект с последней нервной клеткой, вам сюда:) Если вы участник команды или специалист, которого привлекают в проекты, этот материал вам тоже может быть полезным -- чуть ниже я опишу схему проектов и основные элементы, которые нужно учитывать до старта, чтобы контролировать работу и быть уверенным, что ничего не забыли ни вы, ни ваш проектный менеджер.

Основные вопросы, которые нужно уточнить до того, как начнутся работы по проекту:

1. Цель проекта
2. Целевые метрики и значения. Критерии успешности проекта
   
3. Как будете оценивать результат (какие отчеты использовать)
   
4. Какие сроки реализации
   
5. За какой период будуте оценивать результаты?
   
6. Стоимость проекта
7. В какие сроки вы планируете окупить проект
   
8. Внутренние ресурсы (внешние, если есть)
9. Участники, роли и зоны ответственности
10. Если есть заказчик/стейкхолдеры — определить их роль в проекте. Кто принимает окончательные решения?
11. Дополнительные нюансы проекта и вводная информация

Обычно для ответа на эти вопросы мы приглашаем на обсуждение всех предполагаемых участников проекта, чтобы каждый был в курсе и все было максимально прозрачно. Фиксируем договоренности.

Пару слов по каждому пункту отдельно с примерами из личного опыта. А как известно, лучшие примеры - примеры добытые опытным факапным путем))

1. Цель проекта. На этом этапе очень важно понимать, зачем мы запускаем проект, что хотим получить в итоге. Это по сути бизнес-ценность проекта и она тесно связана со следующим пунктом.
   
   Из личного опыта: если к вам приходит стейкхолдер или руководитель и просит реализовать проект или выкатить определенную фичу, задавайте ему вопрос "Какая цель?" несмотря на то, что это руководитель. Цель "сделать, потому что просит руководитель" провальная с самой первой буквы! В итоге с вас будут требовать результат, который не были зафиксирован на старте.
   
   
2. Целевые метрики и значения. Критерии успешности проекта. Этот пункт сопряжен с предыдущем. Здесь вам стоит определить ключевые метрики (Key Results) - как вы поймете, что достигли цели и желаемых результатов.
   Обычно целевая метрика (Target) одна и выражается на языке бизнеса. Но ее можно разбить/расписать по дереву метрик на KR. Это делается для того, чтобы мы не наращивали одно ключевое значение за счет другого.
   
   Например, основная метрика - выручка, дополнительные: объем реализации в натуральном выражении, маржа, чистая прибыль и т д.
   Или, основная метрика - DAU, дополнительные: N-day Retention, activations, time per user и т д.
   
   
3. Как оценивать результат. Здесь основной поинт в том, чтобы вы понимали, сможете ли измерить результативности и с помощью чего. На этом вопросе часто возникает понимание каких отчетов не хватает, как собирать данные и куда.
   
   Из личного: как-то мы придумали, что будем дарить учащимся подарки за выполнение определенных действий в нашем продукте. Но забыли прикинуть, как мы будем находить этих учащихся..
   
   
4. Сроки реализации. Здесь вроде все понятно. Если нет, можно в комментах обсудить кейсы.
5. За какой период будуте оценивать результаты? Важный момент в дизайне тестов. В какой момент вы поймете, что вашим результатам можно доверять и они стат значимы? Через неделю после старта проекта? Через месяц? Это нужно обсудить с проектной группой и аналитиками, если такие есть, и зафиксировать сроки.
6. Стоимость проекта нам важна, чтобы понимать, окупится ли проект и в какие сроки ждать окупаемости.
   
7. В какие сроки вы планируете окупить проект. Если проект сложный, дорогой, требует большого количества времени и ресурсов, вам нужно понимать хотя бы приблизительно, сроки его окупаемости. Это поможет принять решение о старте проекта, а также в ходе его существования оценивать, насколько он быстро движется к цели.
   
8. Внутренние ресурсы (внешние, если есть). На этом этапе нужно определить, какие ресурсы потребуются для реализации проекта. Дальше исходя из этого будут распределяться роли и зоны ответственности.
   
9. Участники, роли и зоны ответственности. Важный этап, когда каждый член команды понимает, за какую часть отвечает именно он.
10. Если есть заказчик/стейкхолдеры — определить их роль в проекте. Кто принимает окончательные решения? Если вы работаете с подрядчиками/аутсорсерами или вы им и являетесь, попробуйте зафиксировать договоренности по каждому этапу реализации. Заказчик принимает решение? Или подрядчик, так как он компетентнее в специализации?
    
    Из личного опыта: мы запускали стартап вместе с подрядчиком, так как внутренними ресурсами компании это было бы делать дороже. Так как это был мой первый опыт подобной совместной работы, я не зафиксировала, кто из нас принимает окончательное решение по ряду технических вопросов. С одной стороны - у меня не было компетенций, чтобы принимать окончательное решение, с другой стороны - я в роли заказчика. В результате потеряли кучу времени перед тем, как зафиналиться.
    

Я обычно визуализирую шаблоны для старта проектов. Например таким образом.

Еще хочется добавить про концепцию проектов.

Она может быть описана на первых этапах, когда идет обсуждение цели проекта, вовлеченных. А может обсуждаться уже после, когда есть понимание сроков и бюджетов.

Схема проекта

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

На схеме проекта зарисовываю основные шаги пользователя. Схемы проектов я рисую с точки зрения клиента, чтобы выстраивать и реализовывать проект с учетом клиентского опыта взаимодействия с продуктом. Это помогает учесть все нюансы и позаботиться заранее о всем, что может потребоваться для реализации задуманного.

После этого можно переходить к формированию полного бэклога задач по проекту. Он включает в себя абсолютно все задачи, которые нужны на каждом этапе реализации проекта. Их можно сформировать по диаграмме ганта, если выполнение одной влияет на другу задачу.

После того, как схема проекта и бэклог сформирован, мы еще раз встречаемся с проектной группой все вместе, обсуждаем полученное, фиксируем сроки и дедлайны по задачам и закидываем их в Asana.

Такой подход помогает учесть все до начала проекта и стартануть с полным ощущением контроля над ситуацией)) важно, чтобы этот контроль оставался реальным, а не только видимым. Для этого желательно проводить синки и ретро по проекту, держать задачи в актуальном состоянии и находить быстрые гибкие решения, если что-то идет не так.

Спасибо за прочтение.

Всем успешных проектов, которые будут приносить удовольствие, а не очередной поход к психотерапевту <3