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

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

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

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

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

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

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

Когда вы автоматизируете бизнес-процесс, успешность проекта зависит от множества факторов. Ключевой – качество бизнес-требований. Бизнес-требования с одной стороны достаточно понятное определение, но как показывает практика, каждый вкладывает в это свои смыслы. Из 100 бизнес-аналитиков на рынке РФ и СНГ, только трое досконально изучили BABOK ( Business Analysis Body of Knowledge), а остальные, как у классика “Мы все учились понемногу чему-нибудь и как-нибудь”. Как следствие бизнес-требования могут не охватывать весь процесс, не упрощать, а усложнять шаги этого процесса. Когда бизнес-требования сделаны плохо, работа остальных команд будет бесполезна. А это десяток ИТ-сотрудников: системные аналитики, разработчики, архитекторы, тестировщики и другие. Представьте, если повар Мишлен приготовит блюдо из просроченных продуктов, да еще и не все ингредиенты будут. Повар может все сделать идеально, вот только есть это блюдо будет опасно для здоровья. То же с проектами, где плохо сделан бизнес-анализ.

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

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