Как вы ведёте проекты? Поделитесь опытом и знаниями
Публичный пост
Тех
✋🏻 Привет
Вопрос: Как вы ведёте свои проекты?
Недавно я стал продакт-менеджером в одном стартапе и сразу же столкнулся с трудностями в ведении проекта. У меня уже был опыт в управлении проектами и продуктами, но, по большей части, он был поверхностным. Я знаю, что такое Scrum, гибкая и каскадная методологии и тд. В теории я более-менее подкован, но вот на практике не очень.
Хочется получить практичные советы от опытных проджект-менеджеров. Какие-нибудь шаблоны, структуру работы, советы, предложения, истории из личного опыта и др.
Если говорить конкретно, то меня интересует:
- Как вы относитесь к Scrum, какие практики из этого фреймворка применяете, есть ли у вас положительный или отрицательный опыт применения, что можете сказать насчет этой методологии?
Недавно я написал онбординг для своей команды, где кратко попытался рассказать, что такое Scrum и почему я хочу по нему работать. Выложив на Вастрик, я получил много конструктивной критики и предложений (спасибо). Как я понял, большая часть специалистов считает, что Scrum - это коммунизм, который так и не построили. Инересно получить конкретные пункты за и против, которые основаны на вашем опыте.
- Как конкретно вы строите работу в проекте, какие этапы применяете, как ставите задачи, как контролируете, как измеряете продуктивность?
На данный момент я работаю по немного адаптированному мною Scrum'у, с применением некоторых шаблонов.
Моя структура: с самого начала я и CEO составляем цели, которых мы хотим достичь. Составляем таблицу с верхнеуровневым описанием задач, минимальным и максимальным результатами, которые мы ожидаем получить. Составляем спринты. После показываем это команде и подробно обсуждаем с ними наше составление спринтов, подробнее расписываем задачи (понятно, что не все задачи можно сразу распределить на спринты и подробно описать). Перед началом спринта, за 1-2 дня мы планируем и грумим новый спринт. Мы будем обсуждать весь бэклог на предмет того, какие задачи мы добавим в новый спринт, какие у нас приоритеты на спринт, какие цели. Также мы оценим задачи по STP, распределим и отредактируем их, устраним возникшие препятствия и сделаем так, чтобы каждый участник спринта понимал, что он должен делать и зачем. Каждый участник поймет цель спринта и его суть, мы определим все задачи и приоритеты. Далее каждый день в строго назначенное время вся команда собирается на стендап-дейли, на котором мы обсуждаем, как идет работа у каждого члена команды, какие у него приоритеты, есть ли какие-нибудь проблемы, все ли ему понятно, что он сделал вчера и будет делать сегодня. В последний день спринта вся команда собирается на ревью и ретроспективу. На ревью мы делимся результатами проделанной работы, закрываем спринт, подводим итоги по работе и эффективности спринта, пишем описание релиза. Далее на ретроспективе мы думаем о том, как нам лучше работать дальше. Обсуждаем, что можно добавить/убрать, что понравилось/не понравилось, что бы улучшилось/убралось и т.д. Далее опять планирование и груминг, и так по кругу.
Какими инструментами вы пользуетесь?
Какая у вас структура документации, какие документы обязательно должны быть у проекта?
Какие советы вы можете мне дать, как начинающему специалисту? Это могут быть советы от вас, литература, статьи, видео. Всё, что угодно.
Какие практики вы считаете плохими, а какие хорошими?
Допустим, считаете ли вы нужным проводить стендапы, или ревью, и т.д.?
- Какие конкретные шаблоны вы используете и почему, могли бы вы ими поделиться?
Мои шаблоны:
Анализ конкурента
Груминг бэклога и планирование спринта
Дэйли
Ревью
Ретроспектива
Как вы строите роадмап, как строите спринты, как оцениваете задачи
Любая другая информация, которая может мне как-то помочь, или который вы хотите поделиться.
Некоторые комментарии на мою прошлую статью:
Статья: https://vas3k.club/post/21754/
Скрам — худший подход к разработке софта.
Выбирать скрам я рекомендую только тогда, когда никакой другой способ коллаборации не подходит и когда вся команда (ну или команда + заказчик в заказной разработке) согласны, что скрам — это необходимое зло и требуемый компромисс.
Проблема Скрама в том, что для небольших проектов, выполняемых одной-двумя командами, он избыточен, а для больших проектов, где задействовано множество команд — недостаточен.
Одновременно — Скрам это "серебряная пуля", наиболее применимая в следующих случаях:
В других случаях я бы сначала исследовал другие подходы к организации разработки (XP или Канбан для маленьких проектов и LeSS или Disciplined Agile для больших) ну и собирал бы свою систему, которая имеет смысл для конкретного проекта и конкретных людей, кто на нём работает.
Совет по выбору "фреймворка" или "методологии" у меня простой - определи проблему, которую ты хочешь решить - "мне нужен лучший на рынке фреймворк" - это не ответ :)
Список альтернатив, про которые я знаю:
Если в какой-то момент, ответом на вопрос "почему мы это делаем?" становится "потому, что так написано в фремворке Х" - вы точно делаете что-то не так
Как скрам-мастер со стажем 6 лет еще ни разу не видела, когда заполняли страницу по Дейли и грумингу. И очень редко вообще все эти страницы заполняются, если команда не видит в них смысла :)
Скрам полезен, когда ты хочешь предсказывать темп команды, вовлекать в процесс и готов рассказать команде : что это такое скрам и зачем это все. Можно внедрить просто события и артефакты, но если они не будут понятны, приняты и полезны команде - это просто еще один бюрократический инструмент для тупо контроля. Никакого доверия или прозрачности не случится.
Если нужна более полная консультация - велком ко мне в сообщения :)
Хотел написать ироничный комментарий с подъебом, но потом вспомнил, что мы на Вастрике )
Поэтому просто напишу, что тебе следует быть аккуратнее в использовании английский аббревиатур. CEO - это исполнительный директор, SEO - это другое(