Привет! Меня зовут Инесса. Я — аналитик в компании fuse8. Предлагаю сегодня поговорить о том, как встроиться в уже сработавшуюся команду. По моему опыту, это всегда испытание. Почти как игра в русскую рулетку: не знаешь, как команда примет новичка и как быстро он подстроится под общий ритм. Новому человеку нужно время на адаптацию, обучение и погружение в процессы. И только потом можно по-настоящему оценить его вклад.
Рубрика «планирование цикла разработки»
Чужой среди своих: как аналитику войти в уже сработавшуюся команду
2025-10-28 в 7:15, admin, рубрики: аналитика проекта, документация проекта, коммуникации с заказчиками, коммуникация в команде, организация процессов, планирование проекта, планирование цикла разработки, Процессы в ITУ нас есть ERP! Разве этого недостаточно для автоматизации бизнес-процессов?
2025-07-02 в 7:16, admin, рубрики: автоматизация бизнес-процессов, автоматизация предприятий, закупки, оптимизация запросов, оптимизация производительности, оптимизация рабочего времени, планирование ресурсов, планирование цикла разработки, производствоЕсли задать вопрос искусственному интеллекту “зачем нужна ERP-система” мы получим следующий ответ:
«ERP‑система нужна для упрощения, автоматизации и эффективного управления бизнес‑процессами в организации. Она собирает важные данные в одном месте, чтобы их анализировать и решать задачи бизнеса.»
Гибкое планирование выпуска релизов 101 (на основе Excel)
2017-04-04 в 13:27, admin, рубрики: agile, product backlog, release planning, sprint backlog, планирование выпуска релизов, планирование цикла разработки, Управление продуктом, управление проектами, управление разработкойПредисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.
А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?
И эта статья о том как это сделать.

В этой статье я хочу рассказать о простом механизме составления плана выпуска релизов. Не буду вдаваться в принципы и ценности, лежащие в основе гибкого планирования выпуска релизов, но в конце статьи найдёте ссылки на материалы, которые помогут в этом разобраться.
Это лишь один из способов составить план выпуска релизов и уверен, что существует много других вариантов. Я использовал этот подход со многими командами разного размера во многих проектах различной величины и сложности. Во многих случаях я его расширял и дополнял, но основы всегда оставались прежними и хорошо работают. Буду рад комментариям о том, как вы это делаете со своими командами.
Читать полностью »
Планирование цикла разработки и выпуска релизов по продуктам
2017-02-25 в 13:24, admin, рубрики: agile, atlassian, jira, product backlog, sprint backlog, планирование выпуска релизов, планирование цикла разработки, Управление продуктом, управление проектами, управление разработкой, метки: product backlog, sprint backlog, планирование выпуска релизов, планирование цикла разработкиЭто продолжение статьи «Управление потоком задач на разработку. История из жизни», ссылка на неё в конце этой статьи.
Контекст и задача
Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.
Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.
Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.
Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.
Бизнес-логика

Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
Читать полностью »
