Алоха! Ребят, сегодня предлагаю обсудить тему, которую предложил наш подписчик!

#вопросотподписчика | @ba_and_sa

Небольшая предистория:

Наш подписчик устроился в компанию - крупная финансовая структура (Заказчик), на роль БА на проект внедрение EPM-системы.

Компания Заказчик имеет классическую орг. структуру, что влияет на состав Команды проекта и их взаимодействие:
⁃ РП - сотрудник из отдельного подразделения в структуре Компании Заказчик, выполняет функции связи с внутренними командами, KPI, которого зависит от количества проектов, а не на их сроках.
⁃ группа стекхолдеров (5 чел), каждый шарит в своих процессах, но никто не шарит во всех, т.е. нет целостной картины и понимания целевого процесса;
⁃ Продакт менеджер - по сути, инициативный сотрудник из подразделения вызвавшийся лидировать проект, тоже не имеющий целостной картины
⁃ Бизнес-аналитик (наш подписчик) , который собирает требования, согласовывает и передает их контрагенту для разработки;

Команда контрагента (проектный тип команды):
⁃ РП
⁃ Помощник РП
⁃ бизнес-аналитики (3 чел)
⁃ разработчики

Функции, которые легли на подписчика - БА:
- сбор требований и работа с ними
- формирование БТ
- первичная приемка
- процесс согласования (в 2-3 этапа внутри Банка)

Выполняя эти функции, наш подписчик столкнулся со следующими проблемами.

1. переданные требования видоизменяются, тк на стороне Контрагента их подстраивают под возможности системы и реализовывают иначе, это приводит к:
⁃ Постоянной работе с изменением требований (проект крупный, одно требование тянет другое)
⁃ Если не фиксировать изменения, то будут проблемы с приемкой функционала
2. происходит двойная работа, на стороне Заказчика собираются требований, потом на стороне Контрагента их опять пережевывают и уточняют, снова согласовывают.
3. работа с изменениями требований забирает отведенное время на сбор требований по новым фичам

——————————————————

⁉️ Вопросы на порассуждать:

1️⃣Нужен ли БА на стороне Заказчика?
2️⃣Какого типа требования должны собираться БА Заказчика, и как с ними должен работать Контрагент?
3️⃣Как история повернется дальше и что можно было бы сделать иначе?

Это довольно частая ситуация, когда Заказчик работает с контрагентом, и при таком раскладе часто бывают разные трудности для работы БА.

У меня тоже была такая ситуация, я о ней чуть позже расскажу, поделюсь своими трудностями и как я их решала! А вы поделитесь своим опытом и помогите разобраться нашему подписчику с его ситуацией)) 🧐👇

В продолжении предыдущего поста я поделюсь своим опытом работы в цепочке «Заказчик - БА - Контрагент»

Продолжение #вопросотподписчика | @ba_and_sa

Цель проекта: разработка и внедрение системы для внутреннего пользования на заводе - это если вкратце, т.е. главный пользователь - заводчане и главные стейкхолдеры со стороны Заказчика

Теперь расскажу о составе команды:

ЗАКАЗЧИК:
- РП, так же один из главных стейкхолдеров (шарил во всей внутрянки проекта со стороны пользователей)
- Стейкхолдеры - порядка 10 чел (с разным функционалом, разное количество стейкхолдеров)
- Администратор проекта - протоколист
- Бизнес-аналитик - я🫡

КОНТРАГЕНТ:
- Тимлид Разработки (один из стейкхолдеров)… Кстати, у меня с ним был конфликт, о котором я говорила ранее 🤺
- Системный аналитик, но больше даже Технический писатель
- Команда разработки
- Архитекторы
- Дизайнеры

Но в моей истории у меня был доступ и к внутренней документации, и прямой доступ к стейкхолдерам и была более полная картина того, что хочет Заказчик, а вот к ИТ сфере проходов было мало, меня не допускали к многим данным, да и разрабов я не видела, общение было в основном только с Лидом и тех.писом (он прям спасал в некоторых ситуациях)

У меня в обязанности входило:
- сбор и анализ требований
- формирование БТ, куда входили: ФТ, НФТ, БП, use case, и тд! Но полноценное написание ТЗ было на стороне Контрагента
- моделирование Бизнес-процессов
- формирование сторонней документации (например инструкции для пользователей)
- согласование со всеми стейкхолдерами, инструкции и Бизнес-процессы надо было еще и с заводом согласовывать 🤯
- ведение дорожной карты вместе с контролем сроков выполнения совместно с РП и Тимлидом разработки
- тестирование продукта, после разработки и после тестирования со стороны Контрагента

Трудности, с которыми я столкнулась:
- занятые стейкхолдеры - вечная проблема!
- мало информации со стороны контрагента, еще и натянутые отношения были с Тимлидом, а он был главным стейкхолдером со стороны Контрагента
- не было доступа к многим данным, тяжело писать НФТ для системы
- трудно было найти разработчиков, так же для описания НФТ, чаще обращалась к их аналитику, а он уже по разрабам бегал
- вести единую дорожную карту с Контрагентом, они могли не успевать по срокам, а я не в курсе

🤔Моя методика работы или советы:

- больше живого/онлайн общения со всеми заинтересованными сторонами, как и со стороны Заказчика, так и Контрагента
- на берегу, я сразу пошла к главному заказчику, для обсуждения методики согласования всех изменений. Мы установили сроки и, если они были нарушены, то согласование считалось полученным. Также перед разработкой мы с РП выбирали главные и ценные БТ и реализовывали все понемногу, тем самым документ был не на 100 стр 🤦🏼‍♀️
- После сбора требований я сразу писала док и параллельно процесс, для успешного процесса у меня было много общения с пользователями- заводчанами
- раз в неделю у нас была встреча с Тимлидом разработки и его Тех.писом, где мы обсуждали все мои накопившиеся вопросы
- была объемная и детализированная дорожная карта
- до релиза я тестировала разработанный функционал и согласовывала, если все ложилось на мой процесс
- Контрагент готовил презентацию по релизу для заказчика, я участвовала в процессе подготовки.

Я уже не вдавалась в подробности, но общую картину рассказала))