{"id":14290,"url":"\/distributions\/14290\/click?bit=1&hash=bece6ae8cf715298895ba844b6416416882fe02c5d18dab2837319deacd2c478","title":"\u041a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438 \u043a\u0430\u043a \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0440\u0430\u043d\u044c\u0448\u0435 \u0445\u043e\u0442\u044f\u0442 \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u0447\u0430\u0442\u044c \u0441 \u043c\u0430\u043b\u044b\u043c \u0431\u0438\u0437\u043d\u0435\u0441\u043e\u043c","buttonText":"","imageUuid":""}

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

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

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

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

  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

0
15 комментариев
Написать комментарий...
Dima

А как же сбор и анализ требований? Ну а как же матрица рисков и компромиссов, которые очень важны? А цели хорошо ставить по SMART. И нет ничего про выбор методологии.

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

Спасибо за ваши дополнения, они действительно ценные) надеюсь, люди, которые прочитают, так же обратят на ваш комментарий внимание

Ответить
Развернуть ветку
Евгений Вилков

Стейкхолдер?
Ну вообще есть полезные моменты в статье, спасибо. А то мозг пухнет.
Но еще…одно дело создать для себя спокойствие пониманием, что все под контролем….это уже не очень здорово.
В идеале нужно быть спокойным, даже если полного контроля нет.

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

Великий навык, Евгений!)

Ответить
Развернуть ветку
Фёдор Спирин

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

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

😅😂а вы кое-что знаете про это😅

Ответить
Развернуть ветку
bright pixel

Спасибо! Нашел для себя пару полезных моментов.

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

Это очень ценно для меня) спасибо за комментарий ☀️

Ответить
Развернуть ветку
In the Abyss

статья отличная,ничего нового,но все очень понятно расписано

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

Спасибо за приятную обратную связь)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Майнкрафтер Фирамир

У меня есть альтернативная инструкция на эту тему:
1. Запускайте проекты
2. Спите спокойно

Ответить
Развернуть ветку
Projecto

Хороший материал)

Какую систему используете для постановки и контроля задач? Мы тоже разрабатываем аналогичную и нам очень важно мнение вашей команды :)

Ответить
Развернуть ветку
Hanna Buinouskaya
Автор

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

Ответить
Развернуть ветку
12 комментариев
Раскрывать всегда