Thread by @produnderhood

Вы просили и я не смог отказать.
Тема дня: методологии управления проектами

Главный вопрос: Когда какую методологию применять?

У PM-ов же все просто! Есть PM BoK для зануд, а есть Scrum Guide для всех остальных

Или все немного сложнее?

Давайте за основу возьмем простое правило.

Чем больше вы и команда понимаете что и как надо делать, чтобы проект увидел свет, тем дальше мы от Scrum и ближе к Kanban.

Условно говоря

Если вы впервые делаете свой ютуб на Flutter, то конечно вы ближе к скраму.

Вероятно, что команда понятия не имеет сколько это займет, сложно ли это и какие трудности возникнут. 🤔

Давайте оценим все в сторипоинтах, за пару спринтов разберемся с нашей велосити и поймем когда будет готов рабочий инкремент.

И да, конечно же результат будем выдавать именно инкрементами, чтобы иметь постоянную обратную связь.

Если у вас большой опыт и вы в очередной раз делаете еком / банк, то конечно вы ближе к PMI 📚

Вы можете заранее назвать риски и конкретную оценку трудозатрат.

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

А вот дальше тема для споров,

НО как мне кажется, нужно стремиться поставить работу на поток.

Как задачи в техподдержке: у всех есть инструкция, все знают что делать в том или ином случае.

Например

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

Так почему бы не переиспользовать эти компоненты от приложения к приложению? 🤔

Это не реклама, так как результатов эксперимента еще нет и хвастаться нечем 🙂

В Surf мы пробуем сейчас прийти к такому подходу, когда приложение собирается как конструктор.

В результате приложения будут дешевле и при этом не терять в качестве.

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

Будет ли результат, к какому проценту отладки это приведёт, на сколько больше приложений появится у среднего бизнеса... Посмотрим 🤷‍♂️

Итого:

Скрам — лучший подход в продуктовой разработке. Довольный пользовать в центре проекта

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

Освоились? Понимаем как работать? Пробуем запустить конвеер

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

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