Как запускать проекты и спать спокойно
Эта статья для тех, кто устал от постоянного хаоса во время работы и реализации проектов.
Если вы проджект с последней нервной клеткой, вам сюда:) Если вы участник команды или специалист, которого привлекают в проекты, этот материал вам тоже может быть полезным -- чуть ниже я опишу схему проектов и основные элементы, которые нужно учитывать до старта, чтобы контролировать работу и быть уверенным, что ничего не забыли ни вы, ни ваш проектный менеджер.
Основные вопросы, которые нужно уточнить до того, как начнутся работы по проекту:
- Цель проекта
- Целевые метрики и значения. Критерии успешности проекта
- Как будете оценивать результат (какие отчеты использовать)
- Какие сроки реализации
- За какой период будуте оценивать результаты?
- Стоимость проекта
- В какие сроки вы планируете окупить проект
- Внутренние ресурсы (внешние, если есть)
- Участники, роли и зоны ответственности
- Если есть заказчик/стейкхолдеры — определить их роль в проекте. Кто принимает окончательные решения?
- Дополнительные нюансы проекта и вводная информация
Обычно для ответа на эти вопросы мы приглашаем на обсуждение всех предполагаемых участников проекта, чтобы каждый был в курсе и все было максимально прозрачно. Фиксируем договоренности.
Пару слов по каждому пункту отдельно с примерами из личного опыта. А как известно, лучшие примеры - примеры добытые опытным факапным путем))
- Цель проекта. На этом этапе очень важно понимать, зачем мы запускаем проект, что хотим получить в итоге. Это по сути бизнес-ценность проекта и она тесно связана со следующим пунктом.
Из личного опыта: если к вам приходит стейкхолдер или руководитель и просит реализовать проект или выкатить определенную фичу, задавайте ему вопрос "Какая цель?" несмотря на то, что это руководитель. Цель "сделать, потому что просит руководитель" провальная с самой первой буквы! В итоге с вас будут требовать результат, который не были зафиксирован на старте. - Целевые метрики и значения. Критерии успешности проекта. Этот пункт сопряжен с предыдущем. Здесь вам стоит определить ключевые метрики (Key Results) - как вы поймете, что достигли цели и желаемых результатов.
Обычно целевая метрика (Target) одна и выражается на языке бизнеса. Но ее можно разбить/расписать по дереву метрик на KR. Это делается для того, чтобы мы не наращивали одно ключевое значение за счет другого.
Например, основная метрика - выручка, дополнительные: объем реализации в натуральном выражении, маржа, чистая прибыль и т д.
Или, основная метрика - DAU, дополнительные: N-day Retention, activations, time per user и т д. - Как оценивать результат. Здесь основной поинт в том, чтобы вы понимали, сможете ли измерить результативности и с помощью чего. На этом вопросе часто возникает понимание каких отчетов не хватает, как собирать данные и куда.
Из личного: как-то мы придумали, что будем дарить учащимся подарки за выполнение определенных действий в нашем продукте. Но забыли прикинуть, как мы будем находить этих учащихся.. - Сроки реализации. Здесь вроде все понятно. Если нет, можно в комментах обсудить кейсы.
- За какой период будуте оценивать результаты? Важный момент в дизайне тестов. В какой момент вы поймете, что вашим результатам можно доверять и они стат значимы? Через неделю после старта проекта? Через месяц? Это нужно обсудить с проектной группой и аналитиками, если такие есть, и зафиксировать сроки.
- Стоимость проекта нам важна, чтобы понимать, окупится ли проект и в какие сроки ждать окупаемости.
- В какие сроки вы планируете окупить проект. Если проект сложный, дорогой, требует большого количества времени и ресурсов, вам нужно понимать хотя бы приблизительно, сроки его окупаемости. Это поможет принять решение о старте проекта, а также в ходе его существования оценивать, насколько он быстро движется к цели.
- Внутренние ресурсы (внешние, если есть). На этом этапе нужно определить, какие ресурсы потребуются для реализации проекта. Дальше исходя из этого будут распределяться роли и зоны ответственности.
- Участники, роли и зоны ответственности. Важный этап, когда каждый член команды понимает, за какую часть отвечает именно он.
- Если есть заказчик/стейкхолдеры — определить их роль в проекте. Кто принимает окончательные решения? Если вы работаете с подрядчиками/аутсорсерами или вы им и являетесь, попробуйте зафиксировать договоренности по каждому этапу реализации. Заказчик принимает решение? Или подрядчик, так как он компетентнее в специализации?
Из личного опыта: мы запускали стартап вместе с подрядчиком, так как внутренними ресурсами компании это было бы делать дороже. Так как это был мой первый опыт подобной совместной работы, я не зафиксировала, кто из нас принимает окончательное решение по ряду технических вопросов. С одной стороны - у меня не было компетенций, чтобы принимать окончательное решение, с другой стороны - я в роли заказчика. В результате потеряли кучу времени перед тем, как зафиналиться.
Я обычно визуализирую шаблоны для старта проектов. Например таким образом.
Еще хочется добавить про концепцию проектов.
Она может быть описана на первых этапах, когда идет обсуждение цели проекта, вовлеченных. А может обсуждаться уже после, когда есть понимание сроков и бюджетов.
Схема проекта
Схема проекта строится уже непосредственно после всех согласований. Она включает в себя точные даты, полный перечень задач и ответственных.
На схеме проекта зарисовываю основные шаги пользователя. Схемы проектов я рисую с точки зрения клиента, чтобы выстраивать и реализовывать проект с учетом клиентского опыта взаимодействия с продуктом. Это помогает учесть все нюансы и позаботиться заранее о всем, что может потребоваться для реализации задуманного.
После этого можно переходить к формированию полного бэклога задач по проекту. Он включает в себя абсолютно все задачи, которые нужны на каждом этапе реализации проекта. Их можно сформировать по диаграмме ганта, если выполнение одной влияет на другу задачу.
После того, как схема проекта и бэклог сформирован, мы еще раз встречаемся с проектной группой все вместе, обсуждаем полученное, фиксируем сроки и дедлайны по задачам и закидываем их в Asana.
Такой подход помогает учесть все до начала проекта и стартануть с полным ощущением контроля над ситуацией)) важно, чтобы этот контроль оставался реальным, а не только видимым. Для этого желательно проводить синки и ретро по проекту, держать задачи в актуальном состоянии и находить быстрые гибкие решения, если что-то идет не так.
Спасибо за прочтение.
Всем успешных проектов, которые будут приносить удовольствие, а не очередной поход к психотерапевту <3
А как же сбор и анализ требований? Ну а как же матрица рисков и компромиссов, которые очень важны? А цели хорошо ставить по SMART. И нет ничего про выбор методологии.
Спасибо за ваши дополнения, они действительно ценные) надеюсь, люди, которые прочитают, так же обратят на ваш комментарий внимание
Стейкхолдер?
Ну вообще есть полезные моменты в статье, спасибо. А то мозг пухнет.
Но еще…одно дело создать для себя спокойствие пониманием, что все под контролем….это уже не очень здорово.
В идеале нужно быть спокойным, даже если полного контроля нет.
Великий навык, Евгений!)
запускать проекты и спать спокойно, 2 слова которые почти никогда не встречаются в одном предложении
😅😂а вы кое-что знаете про это😅
Спасибо! Нашел для себя пару полезных моментов.