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

Question

[Давид Черенков]

Коллеги, всем привет!
Я Давид - менеджер проектов в рекламном агентстве, которое реализует для наших Клиентов продукты для бизнес-коммуникации. Грубо говоря: фирменная сувенирная продукция для закрытия определенных маркетинговых задач Клиента. Возможно вопрос не подходящий для хабра (так как не айти, но попытаюсь)

Сейчас углубленно осваиваю различные методологии управления проектами (с надеждой уйти в айти как проджект) и немного туплю

Помогите мне понять, как возможно применять гибкие методологии управления проектом (SCRUM) в проектах, которые прям созданы для каскадной методлогии.

Приведу пример:
Обратился клиент на поставку Продукции с дизайном
Клиент обозначил дедлайн поставки - через месяц

spoiler

Проведен рисерч по поиску поставщика, поиску технолога, калькуляция сметы и сроков

spoiler

С клиентом согласованы все условия сотрудничества, подобраны позиции, разработаны дизайны

spoiler

Получен ОК на запуск проекта

spoiler

Оплата товарному подрядчику - закуп продукции

spoiler

Оплата технологу - услуги нанесения

spoiler

Товар доставлен на нанесение

spoiler

Товар готов с нанесением

spoiler

Отгрузка продукции в обозначенные сроки довольному Клиенту

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

Конечно, в своей работе я параллелю некоторые процессы: например заранее занимаюсь документацией, оплачиваю различные услуги во время доставки самой продукции, чтобы потом не стопорить проект, ставлю задачи на дизайн и так далее. Но разве такие параллельные процессы могут свидетельствовать об использовании гибкой методологии, если основной скелет проекта работает каскадным методом?

Просто, например Сазерленд (создатель скрама) утверждает, что за гибкими методологиями будущее, а всякие водопады должны кануть к лету. И только используя скрам можно повысить работоспособность команды до 800%.

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

Буду благодарен за ответы:)

Comments

[Snakecharmer]

Сазерленд (создатель скрама) утверждает, что за гибкими методологиями будущее, а всякие водопады должны кануть к лету. И только используя скрам можно повысить работоспособность команды до 800%.

Будьте добры, а можно полную цитату и её источник?

Answer 1

[Jacen11]

Просто, например Сазерленд (создатель скрама) утверждает, что за гибкими методологиями будущее, а всякие водопады должны кануть к лету. И только используя скрам можно повысить работоспособность команды до 800%.

я бы тоже так говорил про штуку которую продаю

на примере самолетостроения особенно ярко это видно, выпустили говно итерацию, пара самолетов упала, сотни две умерло, внесли правки в ПО самолета, повторить. Отличный подход

то что вы пытаетесь делать похоже на карго культ. Нужно использовать правильный инструмент в своей сфере, не нужно тащить все модное к себе

Comments

[Давид Черенков]

Благодарю вас! Конечно, я не пытаюсь использовать сугубо один подход даже в не подходящих для этого кейсах, но призадумался, вдруг можно мою работу адаптировать под скрам и тем самым повысив эффективность

Answer 2

[calculator212]

Конкретно в вашем случае применение scrum близко к бессмысленному, т.к. обычно спринты длятся 1-4 недели (а у вас весь срок это 1 месяц) и по сути в конце спринта нужно показывать готовый (промежуточный) продукт, штуки типа оплаты, отгрузки и т.д. не имеют отношения к этому (по крайней мере в it как минимум в большинстве случаев).

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

Попробовать можно конечно, но вы вероятно не совсем понимаете чем разработка ПО отличается от разработки дизайна для сувениров и т.д. В большинстве случаем разработка продукта длится от 3 месяцев до нескольких лет, и при помощи методологии пытаются разбить задачи и обозначить какие-то сроки по внедрению функционала. В целом скрам не всегда подходит, т.к. разработка некоторых фич может занимать несколько месяцев(иногда конечно завышают сроки), но суть в том что формально по скраму уже не получится работать и если слепо следовать идеологии, то можно принести больше вреда чем пользы.

Просто, например Сазерленд (создатель скрама) утверждает, что за гибкими методологиями будущее, а всякие водопады должны кануть к лету. И только используя скрам можно повысить работоспособность команды до 800%.

Сказать можно много чего, человек зарабатывает на продаже своей идеи и логично что он будет её продвигать. Интересно посмотреть как именно скрам повысил производительность на 800%( хз что он вообще под этим подразумевает), в ряде областей скрам полезен, но чаще проблема просто в том, что менеджмент неэффективный, т.к. руководитель просто не понимает специфику своей работы или работы команды, я например видел пример того что руководитель просил каждый день писать отчет о проделанной работе и разбивать это по часам, в итоге на бумаге всё "хорошо" было а на практике это была худшая команда в плане выпуска продуктов и атмосферы.
Поэтому нужно изучить основные методы, хотя бы немного погрузиться в специфику (думаю есть курсы/видео на ютубе по типу "IT для менеджеров"), чтобы более менее понимать что просить от людей. И почитать книги по типу "мифический человеко-месяц" и "как пасти котов"