Основные принципы взаимодействия с командой
В основе моей методологии управления проектом лежит Growth подход в сочетании со Sсrum фреймворком по организации работы
Логика структуры управления по Scrum
Месяц → Неделя → День
Месяц → Неделя → День
Каждый уровень поддерживает предыдущий, создавая непрерывную управленческую цепочку: стратегия, тактика, операционка
Ежемесячный цикл
Цель: создать предсказуемую систему планирования, где у топов команды есть общее понимание стратегии и приоритетов
Еженедельный ритм
Цель: наметить спринт на неделю
Ежедневные синки
Цель: составить план работы на день для выполнения недельных задач
Цель: создать предсказуемую систему планирования, где у топов команды есть общее понимание стратегии и приоритетов
Еженедельный ритм
Цель: наметить спринт на неделю
Ежедневные синки
Цель: составить план работы на день для выполнения недельных задач
Каждый член команды не приходим приходим с вариантами решения, а не с проблемой
При этом решение предварительно должно быть самостоятельную оценено по:
икр (идеальный конечный результат)
приоритет: влияние + срочность
вероятность достижения (кейсы, подтвержденные практики и тд)
приоритет: влияние + срочность
вероятность достижения (кейсы, подтвержденные практики и тд)
Как научиться видеть важное среди +100500 задач или как правильно определять приоритеты?
Без определения приоритетов не должна начинаться новая неделя. Для каждой задачи мы определяем приоритет (P1, P2, Р3):
Р1 (Критично): Если не сделаем Х, то вебинар сегодня не сможем провести
Р2 (Важно): Нужно сделать сегодня для дальнейшего движения по спринту
Р3 (Косметика): Можно забить, если горим
Р2 (Важно): Нужно сделать сегодня для дальнейшего движения по спринту
Р3 (Косметика): Можно забить, если горим
Простой алгоритм сортировка задач:
Сбор всех задач по спринту
Распределяем задачи по проектам (у ЗАДАЧИ > 2 действий то это проект)
Проставляем приоритеты
Разбиваем задачи по дням и по времени
Корректировки (каждый день вечером + 1 раз в пт вечером планирование на след неделю)
Распределяем задачи по проектам (у ЗАДАЧИ > 2 действий то это проект)
Проставляем приоритеты
Разбиваем задачи по дням и по времени
Корректировки (каждый день вечером + 1 раз в пт вечером планирование на след неделю)
Если у задачи нет лимита по времени и по результату, то это не задача — это философия
Пример:
❌ Плохо: «Проанализировать конкурентов»
✅ Хорошо: «За 2 час собрать 10 самых долгоиграющих рекламных подач конкурентов, выписать 5 повторяющихся паттернов и на основании этого сформировать 5 гипотез, которые помогут в самое ближайшее время увеличить окупаемость в проекте в 1,5 раза»
❌ Плохо: «Проанализировать конкурентов»
✅ Хорошо: «За 2 час собрать 10 самых долгоиграющих рекламных подач конкурентов, выписать 5 повторяющихся паттернов и на основании этого сформировать 5 гипотез, которые помогут в самое ближайшее время увеличить окупаемость в проекте в 1,5 раза»
Лучше протестировать рабочую гипотезу за 2 дня, чем дорабатывать её до идеала 2 недели
В этом особенность Growth-подхода, в котором есть та самая важность корректировки плана действий исходя от результатов, которые мы поулчаем:
Спланировали → сделали → измерили → изменили → снова сделали
Например, любимый мной Цикл Деминга позволяет тестировать изменения в небольшом масштабе, анализировать результаты и внедрять корректировки для повышения качества, предотвращая масштабные сбои
Спланировали → сделали → измерили → изменили → снова сделали
Например, любимый мной Цикл Деминга позволяет тестировать изменения в небольшом масштабе, анализировать результаты и внедрять корректировки для повышения качества, предотвращая масштабные сбои
А как лучше всего организовать системную работу в инфобиз проекте или онлайн-школе?
Базовый минимум:
Коммуникация происходит в чатах, объединенных общей темой, а ежедневные, еженедельные и ежемесячные синхронизации подерживают эту структуру
