По словам разработчика, отставание усугубляется, а причина «социальная». Суть в том, как организован процесс разработки, внесения изменений в ОС. Если в мире опенсорса это открытый процесс, который несёт пользу и улучшает систему, то в мире корпоративного ПО зачастую изменения вносятся по причинам эгоизма, желания продвижения по карьерной лестнице, славы и т. д. Всё это ведёт к деградации продукта.

14 лет я работал в международной компании Airbus – компании, занимающейся авиастроением. В IT же мой путь начался совсем недавно – всего лишь чуть больше года назад. Сейчас я – релиз менеджер, и мы вместе с командами разрабатываем API-центричные микросервисы.
Чем отличается управление релизами программного обеспечения и управление проектированием конструкций гражданских самолетов? Мой опыт позволяет поставить знак равенства между этими двумя видами деятельности. По крайней мере, в контексте выстраивания долгосрочных отношений между заказчиком и исполнителем.

Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи.

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

Бизнес тяжело понимает, что жизнь это не спринт. Сумасшедшие требования, фразы "нужно было вчера" и тд наш герой слышит постоянно. Оттого люди, остающиеся на этой должности не только забывают, что есть какие-то код ревью и тд, но они не следят за командой и зачастую они просто забивают и передают часть своих обязанность PO, который даже не смотря на это, всё равно тащит Team lead'а обратно в клоаку. И замкнутый круг повторяется и повторяется и повторяется и повторяется...

Одним прекрасным зимним днем, коллеги из крупной IT-компании обратились ко мне с запросом на проведение стратегической сессии. Они хотели:

- Сформировать общую целевую картину своего светлого будущего.
- Показать четкий путь к достижению этого светлого будущего.
- Обозначить промежуточную точку на этом пути через 2 года, без которой невозможно достигнуть светлого будущего.

Это была большая работа, одним из этапов которой была сессия по созданию продуктовой стратегии. Чтобы решить эту задачу, я начала искать подходящий фреймворк. В поиске я наткнулась на фрейм, который хочу представить, а также поделиться своим опытом проведения сессии по этой структуре. В середине работы мы столкнулись с отсутствием CPO, поэтому в статье вы также сможете найти как мы с этим справились и что по итогу у нас вышло.