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

Сейчас есть некоторые мысли как заинтересовать людей, путем некоторой геймификации. Собственно, сделать бота, который бы постил в чат итоги месяца и определял самых активных ревьюеров; показывал бы самый "интересный" Merge Request и тд

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

Это гм... KPI, который начнут "взламывать", придется ограничить время которое сотрудник может тратить на ревью, а значит упадет качество ревью. Опять же будут те, кому не интересно получать "лычки" и они это будут игнорировать - в итоге возможено отторжение "не таких" и ухудшение морального духа. Я вот не против, чтобы кто ревьюил мой код, но сам это не очень люблю делать и смотрю только на критичные на мой взгляд вещи, который потенциально могут стать базой для чего-то еще в данном проекте (что требует погружения в проект и сложно со стороны), на остальное закрываю глаза - так как код будет все равно переписываться. :)

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

Спасибо за развернутые ответы. Много чего для себя открыл

Зачем вам замедлять разработку в обмен на иллюзию обмена знаниями?

Замедлять? Каких либо обязательных ритуалов я не ввожу

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

Критерии?

Покурил тему, проконсультировался. с коллегами, и, как обещал, возвращаюсь с материалами.
Мы оба были правы, сейчас в этой области по части применения PO, PdM полярные мнения, но есть нюанс 🙂
Надеюсь эти материалы помогут составить представление о масштабировании роли PO.
Enjoy!

За материал спасибо)

Тоже глянул гугл и поговорил с разными людьми - везде свое видение. И где-то мое есть, где-то ваше)

Яж говорю - бардак 😂

Ребят, об$срались по срокам с заказчиком. Из-за текучки субподрядчиков.

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

зафиксировать убытки, успокоиться, идти дальше

По-русски говоря, то взять яйца в руки и продолжать работать. Верно посыл понят?

+
решить насущные проблемы, поставить дату ретроспективы, записаться к психологу

примерно, Это ж риски классические