Ну вот как я думаю. Нужно на первом этапе обзначить роли в команде и их взаимодействие. А потом уже это будем меняться, развиваться и т.п. Это не так? Нужно начинать вообще без процесса и по ходу уже рулить?

найдите себе PO и расчитывайте ценность продукта

процессы построятся сами собой

Ну вот как я думаю. Нужно на первом этапе обзначить роли в команде и их взаимодействие. А потом уже это будем меняться, развиваться и т.п. Это не так? Нужно начинать вообще без процесса и по ходу уже рулить?

Нужно начинать. (тчк)

потом нужно быстро учиться заканчивать

потом все остальное :)

нельзя найти PO, PO на рынке нет, человек который умеет сортировать бэклог это не ПО

заказчик-прокси это не ПО

человек с сертификтом PO это не PO, кароче грустно все

зачем их на рынке искать?

> найдите себе PO и расчитывайте ценность продукта

пусть им будет тот кто в продукте больше всего заинтересован

назначьте*

выберите*

а потом назначьте, ок

:)

Я правильно понимаю, что нужно найти "правильных людей" и они сами выстроят процесс? На любом уровне процесса. А до этого о ролях говорить смысла нет?

пусть им будет тот кто в продукте больше всего заинтересован

Человек заинтересованный в продукте и РО — это разные вещь. Есть люди которые заинтересованы больше всего, часто творят херню

А как называется человек который умеет сортировать бэклог?

сортирователь беклога

😂

правильные люди

это очень смешное, нет люди могут быть неправильные

сортирователь беклога

На hr напрашивается вакансия

вообще неправильные люди всегда лучше правильных

потому что когда хоть кто-нибудь говорит "это какая-то хуйня"

;)

ну самое ужасное что зачастую многие вакансии так и нужно обозвать

коллектив хоть может отрезвиться чуть-чуть

сортирователь беклога, погонятель программистов

спрашиватель сроков

отвечатель за сроки

сдвигатель дедлайнов

Я правильно понимаю, что нужно найти "правильных людей" и они сами выстроят процесс? На любом уровне процесса. А до этого о ролях говорить смысла нет?

а что нужно сделать-то?

наверняка нужно сделать какую то работу. поэтому нужен делатель работы :D

кстати неправильные люди вполне себе синоним мудакам :D

Нужен тот кто сделает работу.

эксперт в переключение контекста

Хотя agile настаивает на важности процесса, а не результата

где он это делает?

а что нужно сделать-то?

Есть SaaS-продукт для МСБ, плюс ряд корпоративных заказчиков с различающимися требования, которые этот продукт хотят видеть on premises. И нужно все это уложить в единую кодовую базу

что мешает "начать укладывать это в единую кодовую базу"?

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

куда она будет расширятся?

и зачем?

а как неструктурированный процесс мешает начинанию?

куда она будет расширятся?

В сторону увеличения числа разработчиков. Заказчиков много, команда не справляется

это команда решила?

кстати МСБ который SaaS и идет в on-premise - это кастом стоимость поддержки которого может сделать маржу минусовой

я так понимаю эту математику уже посчитали? ))

это команда решила?

Это CEO видит по планам и срокам, которые ему команда дает

каждый клиент придет со своей хотелкой

может стоить научить команду давать более реалистичные сроки?

а как неструктурированный процесс мешает начинанию?

Меня зовут в эту команду и нужно принять решение, поняв видение CEO и его ожидания. Синхронизироваться в какой-то степени. Или тут правильная тактика "Давайте начинать, по ходу поймем ожидания друг друга"?

кстати МСБ который SaaS и идет в on-premise - это кастом стоимость поддержки которого может сделать маржу минусовой

Да, есть такой риск. Сейчас его оцениваем

может стоить научить команду давать более реалистичные сроки?

Они в свои сроки укладываются, просто очередь заказчиков растет

но увеличение количества разработчиков только усложнит процессы

может стоить разделить продукт?

Как вариант. Если поймем, что это будет реалистичнее, то так и сделаем. Чтобы не городить сверх-кастомизацию

а что такое разделеить продукт? :)

Две назависимые кодовые базы

человек вам только что предложил умножить затраты на 2

как минимум есть то что нужно разным группам пользователей

значит

необязяталеьно иметь две кодовые базы

пока кстати проблемы озвучено так и не было

а вот предложений по решений масса

либо я что-то упуустил

похоже что есть только опасения

;)

так не делается же нифига

надо идти и смотреть по ситуации

я бы посоветовал понять что такое agile :D

тогда и будет понятно что делать

кстати SaaS который в on-premise превратится в разные продукты - это сомнительный продукт

значит продукт там - ядро, которое надо отдавать в маркет

а если не превратится, то on-premise это небольшая нагрузка

jira тому хороший пример

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

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