Андрей, все верно! Это тоже отмечено в начале статьи, ваш опыт Бизнес-архитектора делает ИИ-для вас мало эффективным в рутинных задачах, как и для меня, но для рядовых junior и middle аналитиков, это хороший инструмент для ускорения работы =)
Приведенный более эффективный промт очень хорошо, и точно даст более качественные критерии приемки, но он уже более глубоко заточен именно под данную User Story, то есть время на его подготовку больше и требует более глубокого предварительного обдумывания.
Выделил жирным элементы в промте, которые специфичны для конкретной User Story:
Роль: ты — системный и бизнес‑аналитик e‑commerce.
Цель: составь проверяемые критерии приемки для User Story:
«Я как покупатель интернет‑магазина хочу видеть историю своих заказов за заданный период, чтобы найти информацию о ранее заказанных товарах».
Определения и правила:
• Ключевая дата фильтрации: дата создания заказа.
• Границы периода: включительно.
• Часовой пояс: профиль пользователя; даты без времени интерпретировать как 00:00:00 для начала и 23:59:59 для конца.
• Формат дат: ДД.ММ.ГГГГ.
• Бизнес‑ограничения: макс. длина периода — 24 месяца; дата окончания не в будущем.
Область (scope):
• Только просмотр списка заказов за период и просмотр деталей заказа.
• Не добавляй функции вне области (нет экспорта/доп. фильтров/изменения заказов).
UI/UX дефолты:
• Сортировка по умолчанию: дата создания ↓.
• Пагинация: 20 записей на страницу.
• Поля строки заказа: номер, дата/время создания, статус, итоговая сумма, ссылка на детали.
• Поля деталей заказа: наименование, артикул (если есть), количество, цена за единицу, сумма по позиции.
Безопасность:
• Показывать только заказы текущего пользователя; чужие заказы по прямой ссылке — 403/404.
Ошибки (тексты обязательны):
• «Укажите период», «Неверный формат даты», «Дата начала не может быть позже даты окончания», «Дата окончания не может быть в будущем», «За период заказы не найдены», «Сервис истории недоступен, попробуйте позже».
Нефункциональные требования:
• ≤ 10 000 заказов в периоде — 95‑й перцентиль времени ответа ≤ 2 с; таймаут — 5 с.
Покрытие критериев (обязательно):
1) Доступ/безопасность
2) Форма и валидация дат
3) Границы и часовые пояса
4) Результаты/поля/сортировка/пагинация
5) Детали заказа
6) Пустые результаты
7) Отказоустойчивость/ошибки
8) НФ‑метрики
Формат каждого критерия:
• Строго «При условии..., когда..., то система...».
• Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.
Вывод:
• Таблица с колонками «номер» и «критерий приемки»; 22–30 уникальных критериев.
• Никаких разделов, примечаний и пояснений — только критерии.
Самопроверка перед выводом:
• Каждый критерий связан только с данной User Story.
• Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Если делать его более универсальным для массового применения, то изменил бы его следующим образом:
Роль: ты — системный и бизнес‑аналитик [ОТРАСЛЬ].
Цель: составь проверяемые критерии приемки для User Story:
[ВАША USER STORY]
Определения и правила:
[ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
Область (scope):
Не добавляй функции вне области User Story
UI/UX дефолты:
[ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
Покрытие критериев (обязательно):
Доступ/безопасность
Форма и валидация вводимых данных
Результаты/поля/сортировка/пагинация
Пустые результаты
Отказоустойчивость/ошибки
НФ‑метрики
Формат каждого критерия:
Строго «При условии..., когда..., то система...».
Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.
Вывод:
Таблица с колонками «номер» и «критерий приемки»; 20–30 уникальных критериев.
Никаких разделов, примечаний и пояснений — только критерии.
Самопроверка перед выводом:
Каждый критерий связан только с данной User Story.
Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Самый главный вопрос где провести границу между временем подготовки качественного и детального промта и временем на последующее ревью его результатов. Ведь даже в рамках этой конкретной задачи по подготовке критериев приемки в зависимости от опыта специалиста она будет сильно плавать.
Я склоняюсь к тому что лучше быстрее получить результат и провести его ревью и корректировку, чем уделять существенное время детализации промта, при том что не зависимо от того детализируешь ты промт или проводишь ревью, если ты забыл или ни когда не сталкивался с проблемой формата ввода даты, то ты все равно пропустишь это требование не важно в промте или при ревью критериев =)
За основной и дополнительный промт gpt 5 pro сгенерировал 28 критериев приемки, после ознакомления могу сказать, что критерии от про версии, более детальные и качественные чем у бесплатной.
Согласен, что User Story может быть более детальной, включая, например, информацию о том, что у пользователя больше 1000 заказов, но сама идея User Story и Acceptance Criteria, как раз и заключается в том, что история формулируется как обсуждаемая (Negotiable) и отражающая выгоду для пользователя (Valuable), а через критерии приемки мы её детализируем.
Как часто среднестатистический заказчик приходит к аналитику с запросом: «мне нужна форма отзыва, где текст может быть длиной 7000 символов и можно прикрепить 15 фотографий»? Чаще всего это выглядит как: «нам нужна форма отзывов с возможностью загрузки фотографий», на основе этого мы формулируем примерно следующую пользовательскую историю: «Я, как покупатель, хочу иметь возможность оставить отзыв о товаре и приложить к нему фото, чтобы оставить образную связь для продавца.», а уже через критерии приемки мы напишем, что длина до 7000 символов и не больше 15 фото.
В статье мы обсуждаем все-таки формат документирования требований User Story, при использовании Use Case все эти моменты будут учтены в основном и альтернативных сценариях, но это другой формат документирования требований и там будут свои особенности, про промты для Use Case будет отдельная статья.
User Story написана так, как она формулировалась среднестатистическим заказчиком, владельцем продукта, аналитиком в тех коммерческих и учебных проектах в которых я участвовал. Если у вас есть примеры других подходов, буду рад их изучить!
Про галлюцинации – полностью с вами согласен! Цитата про попугая из эпиграфа статьи именно об этом и говорит =) Я бы даже сказал, это в некотором смысле преимущество ИИ, так как даже если ему давать максимально четкие инструкции, он все равно остается не зашоренным.
Про оверпромптинг – да, эти прилагательные были призваны максимально повысить качество выдаваемого результата, и, возможно, с ними получился некоторый перебор. А как бы вы видоизменили данный промт, могли бы написать свой пример?
Все верно, при таком количестве аналитиков руководитель переходит на C-level должностей и становится на один уровень или на n-1 уровень с СЕО. Отличие будет только в более узкой специализации, CEO условно отвечает за все, а гипотетический CSAO (chief system analysis officer) будет сфокусирован на работе аналитиков.
В общем случае у любого решения есть тот кому оно не нравится. :) Описанный подход действует когда есть большинство заинтересованное в общей цели. Если же непопулярное решение внедряется для незаинтересованного большинства, тот тут уже нужны другие инструменты и более глубокая и тонка работа с аудиторией.
В абзадце на который вы ссылаетесь приводится пример для чего может быть использован реестр бизнес-процессов. Вопрос с чего начинать проектирование ИС с БП или отдельных требований и как отдельные изменения ФТ влияют на другие требования не относится к теме этой статьи. Можем обсудить эту тему в телеграм канале @BA_SA_Arch_eduгде помимо меня еще 2000+ аналитиков с удовольствием примут участие в этой дискуссии :)
ER это тип диаграммы где, как вы сами написали визуализируются сущности и их связи между собой, бизнес-объект это частный случай сущности, модель предметной области это набор бизнес-объектов(сущностей) связанных между собой. Таким образом даже с точки зрения формальной логики нет противоречия в применении ER для визуализации модели предметной области. Если вы встречали материалы где это запрещено делать пожалуйста поделитесь ими с удовольствием расширю свой кругозор.
В сфере информационных технологий в принципе очень мало дерективных вещей и правил. Поэтому говорить про обязательность чего либо не совсем корректно. Скорее есть рекомендации. С точки зрения применения отдельных инструментов упорядочивания информации об этом можно начинать задумываться в командах 3+ человека, так как это уже группа людей в которой общение может происходить между двумя участниками и некоторую информацию нужно фиксировать, чтобы донести ее до третьего и любого другого участника команды. И как вы могли прочитать в статье: Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Каждая команда сама должна решать нужен ей тот или иной инструмент или нет. А расходы на это будут разные во всех проектах, так как будут зависит, от количества артефактов, инструментов, процессов, размера команды, сложности проекта, используемых технологий и тд. и тп. И если углубляться в этом направлении, то надо оценивать не расходы, а ценность которую приносит тот или иной инструмент в отдельном проекте.
Повторюсь своим ответом из пошлого комментария: Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :) О чем и говорится в статье: Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Это инструменты, которые вы можете принести в свой проект и модифицировать под себя
Новизна заключается в том, что в материале структурировано описаны инструменты, которые могут быть применены для упорядочивания работы с требованиями и документацией, собственно это и следует из заголовка. Статья не претендует на изобретение нового, она агрегирует в одном месте существующее.
поря́док - Ожидаемое, предсказуемое, правильно организованное состояние или расположение чего-либо. все приведенные инструменты, как раз и направлены на создание предсказуемого расположения информации в проекте. Да, внедрение любого структурирующего артефакта требует трудозатрат на его поддержание в актуальном состоянии, о чем тоже упоминается в статье. При этом каждая команда сама должна определять, что из приведенного инструментария ей необходимо. У кого-то вообще нет документации, а только исходных код и они отлично себя чувствуют :) Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О БП и требованиях. Есть разные уровни требований. Если укрупнить то на основе бизнес-требований(БТ) мы строим бизнес-процесс(БП), далее отдельные шаги БП описываются детальными функциональными требованиями(ФТ). Все они связаны между собой явно через трассировку требований (писал о ней в предыдущей своей статье) или умозрительно в головах членов команды. Изменения могут транслироваться, как сверху вниз от БТ, через БП к ФТ, или наверх от ФТ к БП.
В разделе про модель предметной области использую термин бизнес-объект так как он лучше подчеркивает, что речь идет именно о бизнесовой (логической) модели, а не о физической (системной). Термин сущность более общий и по моим наблюдениям часто создает путаницу о чем именно идет речь, об объекте реального мира которым оперирует система или о системных объектах в базе данных.
Трассировка - это в первую очередь именно инструмент, который позволяет упростить работу с большим количеством уже имеющихся или создаваемых артефактов.
В плане наведения порядка и с чего это лучше начинать делать. Тебе подойдет мой доклад "Как навести порядок когда попал в хаос из требований и документации?" с конференции "Второй Аналитический Курултай в Центральной Азии" - которая проходила в Алмате.
Сейчас готовлю по этому докладу статью, пока можно посмотреть его запись.
Там как раз подробно рассказываю, с чего начать и с помощью каких инструментов можно наводить порядок и структурировать работу над проектом.
Если говорить про изменения самих основ бизнес/системного анализа и проектирования информационных систем, здесь конкретные тенденции пока сложно выделить.
С точки зрения инструментов, применяемых аналитиками, уже сейчас нужно начинать знакомиться с ИИ и нейросетями, понимать, как они работают и учиться ими пользоваться в повседневной жизни и находить варианты применения для рутинных рабочих задач.
Транскрибирование записи встречи с заказчиком, подготовка драфта протокола встречи, генерация изображения для визуализации, подготовка драфта описания метрики - это малая часть того, что уже сейчас можно делать с помощью ИИ и существенно ускорять процесс своей работы.
Предвосхищая популярный вопрос, что ИИ оставит аналитиков без работы - я в это не верю :)
На мой взгляд, ИИ, на текущий момент, и на ближайшем горизонте своего развития - это супер продвинутый Т9, им просто нужно научиться пользоваться.
Заинтересовал момент о квалификации аналитика и пороге вхождения в проекты с микросервисной архитектурой. В голове родился популистский слоган: "Джунам и новичкам тут нет места!" Но давайте по порядку.
Если смотреть со стороны, то аналитиков и их задачи в проекте с микросервисной архитектурой можно разделить на две роли/категории:
аналитики решения (аналитики кроссервисных задач)
аналитики сервисов
аналитики решения - работают с кроссервисными задачами, включающими интеграции, очереди, балансировки и все остальные прелести, перечисленные автором. Они должны обладать широкими знаниями технологий, опытом и глубоким пониманием системы.
аналитики сервисов - решают задачи, контекст которых локализован внутри отдельных сервисов, и для аналитика это становится просто продуктом, который имеет ряд внешних интеграций.
Таким образом, из различий в решаемых задачах, уровне компетенций и глубине знания продукта вытекает приведенный выше лозунг с небольшим уточнением: "Джунам и новичкам в решении кроссервисных задач нет места".
Обусловлено это тем, что джун, не решавший ранее никаких задач, потеряется в дебрях межсервисных взаимодействий, технологий и бизнес логики, опытный новичок на проекте так же будет плутать без глубоких знаний назначения сервисов.
Однако вопросы роста команды, вместе с ростом количества задач и текучки кадров, всегда будут актуальны, отсюда наиболее эффективным маршрутом адаптации и развития аналитиков видится их первичное привлечение к решению задач в рамках отдельных сервисов с последующим расширением кругозора на всю систему и переходом уже в разряд аналитиков решения.
Интересно услышать ваше мнение на этот счет? =)
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Андрей, все верно! Это тоже отмечено в начале статьи, ваш опыт Бизнес-архитектора делает ИИ-для вас мало эффективным в рутинных задачах, как и для меня, но для рядовых junior и middle аналитиков, это хороший инструмент для ускорения работы =)
Приведенный более эффективный промт очень хорошо, и точно даст более качественные критерии приемки, но он уже более глубоко заточен именно под данную User Story, то есть время на его подготовку больше и требует более глубокого предварительного обдумывания.
Выделил жирным элементы в промте, которые специфичны для конкретной User Story:
Если делать его более универсальным для массового применения, то изменил бы его следующим образом:
Самый главный вопрос где провести границу между временем подготовки качественного и детального промта и временем на последующее ревью его результатов. Ведь даже в рамках этой конкретной задачи по подготовке критериев приемки в зависимости от опыта специалиста она будет сильно плавать.
Я склоняюсь к тому что лучше быстрее получить результат и провести его ревью и корректировку, чем уделять существенное время детализации промта, при том что не зависимо от того детализируешь ты промт или проводишь ревью, если ты забыл или ни когда не сталкивался с проблемой формата ввода даты, то ты все равно пропустишь это требование не важно в промте или при ревью критериев =)
Большое спасибо за тест!
За основной и дополнительный промт gpt 5 pro сгенерировал 28 критериев приемки, после ознакомления могу сказать, что критерии от про версии, более детальные и качественные чем у бесплатной.
Андрей, спасибо большое за комментарий!
Согласен, что User Story может быть более детальной, включая, например, информацию о том, что у пользователя больше 1000 заказов, но сама идея User Story и Acceptance Criteria, как раз и заключается в том, что история формулируется как обсуждаемая (Negotiable) и отражающая выгоду для пользователя (Valuable), а через критерии приемки мы её детализируем.
Как часто среднестатистический заказчик приходит к аналитику с запросом: «мне нужна форма отзыва, где текст может быть длиной 7000 символов и можно прикрепить 15 фотографий»?
Чаще всего это выглядит как: «нам нужна форма отзывов с возможностью загрузки фотографий», на основе этого мы формулируем примерно следующую пользовательскую историю: «Я, как покупатель, хочу иметь возможность оставить отзыв о товаре и приложить к нему фото, чтобы оставить образную связь для продавца.», а уже через критерии приемки мы напишем, что длина до 7000 символов и не больше 15 фото.
В статье мы обсуждаем все-таки формат документирования требований User Story, при использовании Use Case все эти моменты будут учтены в основном и альтернативных сценариях, но это другой формат документирования требований и там будут свои особенности, про промты для Use Case будет отдельная статья.
User Story написана так, как она формулировалась среднестатистическим заказчиком, владельцем продукта, аналитиком в тех коммерческих и учебных проектах в которых я участвовал. Если у вас есть примеры других подходов, буду рад их изучить!
Про галлюцинации – полностью с вами согласен! Цитата про попугая из эпиграфа статьи именно об этом и говорит =) Я бы даже сказал, это в некотором смысле преимущество ИИ, так как даже если ему давать максимально четкие инструкции, он все равно остается не зашоренным.
Про оверпромптинг – да, эти прилагательные были призваны максимально повысить качество выдаваемого результата, и, возможно, с ними получился некоторый перебор. А как бы вы видоизменили данный промт, могли бы написать свой пример?
Все верно, при таком количестве аналитиков руководитель переходит на C-level должностей и становится на один уровень или на n-1 уровень с СЕО. Отличие будет только в более узкой специализации, CEO условно отвечает за все, а гипотетический CSAO (chief system analysis officer) будет сфокусирован на работе аналитиков.
В общем случае у любого решения есть тот кому оно не нравится. :) Описанный подход действует когда есть большинство заинтересованное в общей цели. Если же непопулярное решение внедряется для незаинтересованного большинства, тот тут уже нужны другие инструменты и более глубокая и тонка работа с аудиторией.
Именно так :) Но к сожалению не для всех это очевидно.
В абзадце на который вы ссылаетесь приводится пример для чего может быть использован реестр бизнес-процессов. Вопрос с чего начинать проектирование ИС с БП или отдельных требований и как отдельные изменения ФТ влияют на другие требования не относится к теме этой статьи. Можем обсудить эту тему в телеграм канале @BA_SA_Arch_eduгде помимо меня еще 2000+ аналитиков с удовольствием примут участие в этой дискуссии :)
ER это тип диаграммы где, как вы сами написали визуализируются сущности и их связи между собой, бизнес-объект это частный случай сущности, модель предметной области это набор бизнес-объектов(сущностей) связанных между собой. Таким образом даже с точки зрения формальной логики нет противоречия в применении ER для визуализации модели предметной области. Если вы встречали материалы где это запрещено делать пожалуйста поделитесь ими с удовольствием расширю свой кругозор.
В сфере информационных технологий в принципе очень мало дерективных вещей и правил. Поэтому говорить про обязательность чего либо не совсем корректно. Скорее есть рекомендации. С точки зрения применения отдельных инструментов упорядочивания информации об этом можно начинать задумываться в командах 3+ человека, так как это уже группа людей в которой общение может происходить между двумя участниками и некоторую информацию нужно фиксировать, чтобы донести ее до третьего и любого другого участника команды. И как вы могли прочитать в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность.
Каждая команда сама должна решать нужен ей тот или иной инструмент или нет.
А расходы на это будут разные во всех проектах, так как будут зависит, от количества артефактов, инструментов, процессов, размера команды, сложности проекта, используемых технологий и тд. и тп. И если углубляться в этом направлении, то надо оценивать не расходы, а ценность которую приносит тот или иной инструмент в отдельном проекте.
Повторюсь своим ответом из пошлого комментария:
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О чем и говорится в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Это инструменты, которые вы можете принести в свой проект и модифицировать под себя
Добрый день!
Начнем с самого короткого вашего комментария :)
Новизна заключается в том, что в материале структурировано описаны инструменты, которые могут быть применены для упорядочивания работы с требованиями и документацией, собственно это и следует из заголовка. Статья не претендует на изобретение нового, она агрегирует в одном месте существующее.
Согласно толковому словарю
поря́док - Ожидаемое, предсказуемое, правильно организованное состояние или расположение чего-либо.
все приведенные инструменты, как раз и направлены на создание предсказуемого расположения информации в проекте. Да, внедрение любого структурирующего артефакта требует трудозатрат на его поддержание в актуальном состоянии, о чем тоже упоминается в статье. При этом каждая команда сама должна определять, что из приведенного инструментария ей необходимо. У кого-то вообще нет документации, а только исходных код и они отлично себя чувствуют :)
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О БП и требованиях.
Есть разные уровни требований. Если укрупнить то на основе бизнес-требований(БТ) мы строим бизнес-процесс(БП), далее отдельные шаги БП описываются детальными функциональными требованиями(ФТ). Все они связаны между собой явно через трассировку требований (писал о ней в предыдущей своей статье) или умозрительно в головах членов команды. Изменения могут транслироваться, как сверху вниз от БТ, через БП к ФТ, или наверх от ФТ к БП.
В разделе про модель предметной области использую термин бизнес-объект так как он лучше подчеркивает, что речь идет именно о бизнесовой (логической) модели, а не о физической (системной). Термин сущность более общий и по моим наблюдениям часто создает путаницу о чем именно идет речь, об объекте реального мира которым оперирует система или о системных объектах в базе данных.
Привет!
Опубликовал статью о которой говорил, про структурирование требований и документации Как навести порядок в хаосе из требований и документации?
Рад, что мой опыт будет вам полезен!
Привет!
Трассировка - это в первую очередь именно инструмент, который позволяет упростить работу с большим количеством уже имеющихся или создаваемых артефактов.
В плане наведения порядка и с чего это лучше начинать делать. Тебе подойдет мой доклад "Как навести порядок когда попал в хаос из требований и документации?" с конференции "Второй Аналитический Курултай в Центральной Азии" - которая проходила в Алмате.
Сейчас готовлю по этому докладу статью, пока можно посмотреть его запись.
Там как раз подробно рассказываю, с чего начать и с помощью каких инструментов можно наводить порядок и структурировать работу над проектом.
Если будут дополнительные вопросы, пиши!
Приветствую!
Если говорить про изменения самих основ бизнес/системного анализа и проектирования информационных систем, здесь конкретные тенденции пока сложно выделить.
С точки зрения инструментов, применяемых аналитиками, уже сейчас нужно начинать знакомиться с ИИ и нейросетями, понимать, как они работают и учиться ими пользоваться в повседневной жизни и находить варианты применения для рутинных рабочих задач.
Транскрибирование записи встречи с заказчиком, подготовка драфта протокола встречи, генерация изображения для визуализации, подготовка драфта описания метрики - это малая часть того, что уже сейчас можно делать с помощью ИИ и существенно ускорять процесс своей работы.
Предвосхищая популярный вопрос, что ИИ оставит аналитиков без работы - я в это не верю :)
На мой взгляд, ИИ, на текущий момент, и на ближайшем горизонте своего развития - это супер продвинутый Т9, им просто нужно научиться пользоваться.
Татьяна, большое спасибо за интересную статью!
Заинтересовал момент о квалификации аналитика и пороге вхождения в проекты с микросервисной архитектурой. В голове родился популистский слоган: "Джунам и новичкам тут нет места!" Но давайте по порядку.
Если смотреть со стороны, то аналитиков и их задачи в проекте с микросервисной архитектурой можно разделить на две роли/категории:
аналитики решения (аналитики кроссервисных задач)
аналитики сервисов
аналитики решения - работают с кроссервисными задачами, включающими интеграции, очереди, балансировки и все остальные прелести, перечисленные автором. Они должны обладать широкими знаниями технологий, опытом и глубоким пониманием системы.
аналитики сервисов - решают задачи, контекст которых локализован внутри отдельных сервисов, и для аналитика это становится просто продуктом, который имеет ряд внешних интеграций.
Таким образом, из различий в решаемых задачах, уровне компетенций и глубине знания продукта вытекает приведенный выше лозунг с небольшим уточнением: "Джунам и новичкам в решении кроссервисных задач нет места".
Обусловлено это тем, что джун, не решавший ранее никаких задач, потеряется в дебрях межсервисных взаимодействий, технологий и бизнес логики, опытный новичок на проекте так же будет плутать без глубоких знаний назначения сервисов.
Однако вопросы роста команды, вместе с ростом количества задач и текучки кадров, всегда будут актуальны, отсюда наиболее эффективным маршрутом адаптации и развития аналитиков видится их первичное привлечение к решению задач в рамках отдельных сервисов с последующим расширением кругозора на всю систему и переходом уже в разряд аналитиков решения.
Интересно услышать ваше мнение на этот счет? =)