Как вы ведёте проекты? Поделитесь опытом и знаниями

 Публичный пост

✋🏻 Привет

Вопрос: Как вы ведёте свои проекты?

Недавно я стал продакт-менеджером в одном стартапе и сразу же столкнулся с трудностями в ведении проекта. У меня уже был опыт в управлении проектами и продуктами, но, по большей части, он был поверхностным. Я знаю, что такое Scrum, гибкая и каскадная методологии и тд. В теории я более-менее подкован, но вот на практике не очень.

Хочется получить практичные советы от опытных проджект-менеджеров. Какие-нибудь шаблоны, структуру работы, советы, предложения, истории из личного опыта и др.

Если говорить конкретно, то меня интересует:

  1. Как вы относитесь к Scrum, какие практики из этого фреймворка применяете, есть ли у вас положительный или отрицательный опыт применения, что можете сказать насчет этой методологии?

Недавно я написал онбординг для своей команды, где кратко попытался рассказать, что такое Scrum и почему я хочу по нему работать. Выложив на Вастрик, я получил много конструктивной критики и предложений (спасибо). Как я понял, большая часть специалистов считает, что Scrum - это коммунизм, который так и не построили. Инересно получить конкретные пункты за и против, которые основаны на вашем опыте.

  1. Как конкретно вы строите работу в проекте, какие этапы применяете, как ставите задачи, как контролируете, как измеряете продуктивность?

На данный момент я работаю по немного адаптированному мною Scrum'у, с применением некоторых шаблонов.

Моя структура: с самого начала я и CEO составляем цели, которых мы хотим достичь. Составляем таблицу с верхнеуровневым описанием задач, минимальным и максимальным результатами, которые мы ожидаем получить. Составляем спринты. После показываем это команде и подробно обсуждаем с ними наше составление спринтов, подробнее расписываем задачи (понятно, что не все задачи можно сразу распределить на спринты и подробно описать). Перед началом спринта, за 1-2 дня мы планируем и грумим новый спринт. Мы будем обсуждать весь бэклог на предмет того, какие задачи мы добавим в новый спринт, какие у нас приоритеты на спринт, какие цели. Также мы оценим задачи по STP, распределим и отредактируем их, устраним возникшие препятствия и сделаем так, чтобы каждый участник спринта понимал, что он должен делать и зачем. Каждый участник поймет цель спринта и его суть, мы определим все задачи и приоритеты. Далее каждый день в строго назначенное время вся команда собирается на стендап-дейли, на котором мы обсуждаем, как идет работа у каждого члена команды, какие у него приоритеты, есть ли какие-нибудь проблемы, все ли ему понятно, что он сделал вчера и будет делать сегодня. В последний день спринта вся команда собирается на ревью и ретроспективу. На ревью мы делимся результатами проделанной работы, закрываем спринт, подводим итоги по работе и эффективности спринта, пишем описание релиза. Далее на ретроспективе мы думаем о том, как нам лучше работать дальше. Обсуждаем, что можно добавить/убрать, что понравилось/не понравилось, что бы улучшилось/убралось и т.д. Далее опять планирование и груминг, и так по кругу.

  1. Какими инструментами вы пользуетесь?

  2. Какая у вас структура документации, какие документы обязательно должны быть у проекта?

  3. Какие советы вы можете мне дать, как начинающему специалисту? Это могут быть советы от вас, литература, статьи, видео. Всё, что угодно.

  4. Какие практики вы считаете плохими, а какие хорошими?

Допустим, считаете ли вы нужным проводить стендапы, или ревью, и т.д.?

  1. Какие конкретные шаблоны вы используете и почему, могли бы вы ими поделиться?

Мои шаблоны:

Анализ конкурента


Груминг бэклога и планирование спринта


Дэйли

Ревью


Ретроспектива

  1. Как вы строите роадмап, как строите спринты, как оцениваете задачи

  2. Любая другая информация, которая может мне как-то помочь, или который вы хотите поделиться.

Некоторые комментарии на мою прошлую статью:

Статья: https://vas3k.club/post/21754/

Связанные посты
8 комментариев 👇

Скрам — худший подход к разработке софта.

Выбирать скрам я рекомендую только тогда, когда никакой другой способ коллаборации не подходит и когда вся команда (ну или команда + заказчик в заказной разработке) согласны, что скрам — это необходимое зло и требуемый компромисс.

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

Одновременно — Скрам это "серебряная пуля", наиболее применимая в следующих случаях:

  1. Вы вынуждены стартовать разработку разношёрстной несработавшейся командой, в которую собрали специалистов с разными бекграундами, опытом, возрастом, образованием, навыками, которые никак не могут между собой договориться о взаимодействии и им нужен простой и готовый чек-лист, — точно так же, как им нужен быстрорастворимый кофе "3-в-1" чтобы бахнуть и фигачить, не задумываясь. Тогда скрам.
  2. Вариация предыдущего пункта — вы собрали людей, которые работали только по Аджайлу, для которых Аджайл → религия, Манифест → Библия и "10 заповедей" (двенадцать), а Скрам → это церковный календарь, который предписывает когда креститься, а когда поститься. Ну раз люди во все искренне верят — надо этим пользоваться.
  3. Вы занимаетесь заказной разработкой, а потому от вас ожидается следовать "индустриальному стандарту", ожидается прозрачность процессов, к вам может прийти в любой момент заказчик с аудитором и вы должны будете в любой момент ему поясить за процесс, который прописан в договоре.
  4. Вы — универсистетский препод или вы отвечаете за вкатывание новичков в ИТ и нужно показать, что такое организованная и сисьемная разработка, что такое групповая работа над проектом и как вообще на практике реализуется "Iterative SLDC"
  5. Вы — Scrum Master и вам нужна работа.

В других случаях я бы сначала исследовал другие подходы к организации разработки (XP или Канбан для маленьких проектов и LeSS или Disciplined Agile для больших) ну и собирал бы свою систему, которая имеет смысл для конкретного проекта и конкретных людей, кто на нём работает.

  Развернуть 1 комментарий

@zahhar, очень крутой совет, огромное спасибо. Хвалят скрам очень многие, но вот конструктивно критикуют и предлагают другие решения - единицы. Обязательно прислушаюсь к вам и исследую другие подходы

  Развернуть 1 комментарий

@zahhar, насколько я понимаю, самый лучший подход тот, который максимально ориентирован на команду. Система должна быть выстроена с учетом желаний и личных качеств каждого члена команды. Нет единого стандарта-панацеи по управлению проектами (только подходы как канбан или лесс, или скрам в определенных подходящих случаях), под каждый нужно делать свою адаптивную и понятную систему, которую можно собирать как инструктор из деталий разных частей методологий и практик. Как раз про такое мало где пишут и мало кто говорит, по крайней мере в рф.

  Развернуть 1 комментарий
Eugene Kolbey Head of Integrations, CIB 25 ноября 2023

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

Список альтернатив, про которые я знаю:

  1. вот альтернативный подход ShapeUp - https://basecamp.com/shapeup - но он родился из работы в команде, где много дизайнеров (об этом сказано в явном виде)
  2. есть проектная парадигма (из которой убрали циклы обратной связи и получился waterfall, PMBOK в помощь) - из описания: вы сейчас так и работаете, из описания нет никаких циклов обратных связи, которые бы на что-то влияли - "запилили и отлично"
  3. использовать или не использовать Scrum? - your life, your rules - я у себя в команде построил (для этого мне понадобилось 6-8 месяцев, full-time scrum master, тех-лид и нормальная команда DevOps) - мне нравится, для меня и моих команд - работает:
  • целеполагание бизнесовое (какую проблему мы решаем для клиента/пользователя?),
  • релизы - когда готово, а не когда закончился спринт (с авто-тестами, фиче-влагами и нормальным CI/CD),
  • докуменация - as a code (верхнеуровневое описание + API спека) - т.к. команда использует ХР и нет проблемы с разным контекстом у членов команды
  • capacity management'a - у нас как такового нет и он не нужен, т.к. в основном работа в формате "no estimate"
  1. Kanban - у меня хорошо работал в стабильно-текущих процессах, где задачи в основном понятные (мало неопределенности), их просто надо делать в каком-то порядке с фиксированным (+/-) временем
  2. https://sites.google.com/a/scrumplop.org/published-patterns/home - можно еще здесь посмотреть наработки комьюнити

Если в какой-то момент, ответом на вопрос "почему мы это делаем?" становится "потому, что так написано в фремворке Х" - вы точно делаете что-то не так

  Развернуть 1 комментарий

@ikolbey, круто, очень вам благодарен. Честно признаюсь, я задавал себе именно эти неправильные вопросы и отвечал именно этими неправильными ответами 🫠. Пока что у меня достаточно маленькие команды (их две) и мало опыта, поэтому я думаю начать с чего-то более простого ( скорее комбинация канбана со своими личными наработками и некоторыми пунктами из скрама ), постепенно собирая свою личную базу ошибок/успехов, чтобы в маленькими но верными шагами строить что-то большое и реально удобное всей команде.

  Развернуть 1 комментарий
Олга Кобченко Senior Scrum Master / Agile + ICF Coach 25 ноября 2023

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

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

Если нужна более полная консультация - велком ко мне в сообщения :)

  Развернуть 1 комментарий

@debole3, большое спасибо. Внесли ясность. Немного переосмыслил свой взгляд на шаблоны и некоторые пункты своей структуры

  Развернуть 1 комментарий

Хотел написать ироничный комментарий с подъебом, но потом вспомнил, что мы на Вастрике )

Поэтому просто напишу, что тебе следует быть аккуратнее в использовании английский аббревиатур. CEO - это исполнительный директор, SEO - это другое(

с самого начала я и SEO составляем цели

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб