Комментарии 11
Мы используем похожий подход, но кто у вас в итоге описывает обработку ошибок, способы решения, детали реализации? Аналитики? Вы в статье сказали, что аналитик "не способен проектировать решения на уровне системного архитектора".
Я за свой опыт пришла к тому, что аналитик таки должен быть способен на это и еще быть "достаточно технически подкован, чтобы разбираться в сложных программных нюансах". По крайне мере, в общих чертах. В идеале - проконсультировавшись с архитектором. Т.е. в нашем случае аналитик предлагает некое архитектурное решение архитектору, а тот в свою очередь, вносит корректировки при необходимости, затем уже аналитик фиксирует все в документации, которая передается разработчикам.
Обработку ошибок, способы решения и детали реализации описывает аналитик, но есть несколько нюансов:
Интеграционное взаимодействие изначально проектирует архитектор решений - он принимает решение о том, какие системы и какие микросервисы должны взаимодействовать при сложных межсистемных связях. Аналитик эту информацию использует для дальнейшей проработки, но не проектирует сам, т.к. эти вопросы выходят за границы домена, с которым работает аналитик.
Негативные сценарии и то, как они должны обрабатываться - это, безусловно, часть работы аналитика, как и все то, что относится к уровню пользовательских требований. К команде аналитик приходит с готовыми US и пользовательскими сценариями, на основе которых происходит обсуждение деталей реализации.
Способы решения, детали реализации и обработка ошибок сначала прорабатываются совместно всей командой (в сложных случаях с привлечением системного архитектора) на PBR и затем уже описываются аналитиком. Это позволяет, во-первых, донести до команды понимание бизнес-целей и ценности реализации для пользователя, а во-вторых, найти наиболее оптимальные пути решения, которые один аналитик не всегда может увидеть.
Наверное в реалиях конкретной компании данный подход применим, но в целом возникает много вопросов по подходу.
где в этой схеме бизнес-процесс, описанный и визуализированный в общепринятой нотации со всеми его вариантами развития? Как мне кажется, что тестовое описание в Miro не является оптимальным решением для такого типа задачи. Разработка схемы процесса на этапе формирования документации тоже не самая лучшая практика, потому что выявить проблемы на финальном этапе это не очень хорошо.
на этапе "Исследуем и детализируем истории" не описана стратегия работы с рисками и ограничениями, только детализация US. Если доска в Miro является основным способом коммуникации с заказчиком, то риски и ограничения должны фиксироваться в явном виде на этой доске. Как фиксируются в явном виде?
при решении любой задачи первичным, кроме бизнес-процессов, является архитектура этого решения, которая должна ответить на много вопросов, в частности варианты интеграции между системами (расширение существующих интеграций, создание новых и т.п.), участвующие системы и т.п., что в свою очередь имеет большое влияние на оценку трудозатрат. Как в концепции US решается вопрос проработки архитектуры, с учетом того, что ответы на многие вопросы не могут быть получены в режиме групповой проработки и требуют более глубокого и детального изучения и погружения?
Очень часто у бизнеса, у заказчика есть идея, есть ожидаемые доходы от реализации идеи и бизнес хочет получить ответ от IT сколько будет стоить реализация его идеи, чтобы понимать нужно вообще инвестировать в это или идея никогда себя не окупит. Чтобы получить ответ на это вопрос необходимо привлекать всю команду, даже в том случае если это просто получение оценки стоимости разработки? Как в это случае избежать формирования ТЗ?
как сторипоинты трансформируются в деньги, если это некая абстрактная единица оценки? Любой бизнес-заказчик мыслит деньгами, которые от тратит на внедрение и прибылью, которую он получает? Как понимать заказчику, что оценка в сторипоинтах уместится в его бюджет в рублях, долларах или евро?
Ой, вы-таки хотите, чтобы я раскрыла сразу все секреты наших процессов))
Каждый ваш вопрос вполне справедлив, но выходит за рамки этой статьи и заслуживает рассмотрения в отдельных статьях. В этой статье я описывала именно ту часть процесса, которая относится к работе аналитика с уровнем пользовательских и системных требований.
Попробую ответить кратко:
где в этой схеме бизнес-процесс, описанный и визуализированный в общепринятой нотации со всеми его вариантами развития?
Моделирование бизнес-процесса у нас относится к уровню работы с бизнес-требованиями и там, где это применимо, аналитик выполняет моделирование БП в BPMN, а дальше блоки из БП прорабатываются до уровня пользовательских требований и перекладываются в USM.
на этапе "Исследуем и детализируем истории" не описана стратегия работы с рисками и ограничениями, только детализация US. Если доска в Miro является основным способом коммуникации с заказчиком, то риски и ограничения должны фиксироваться в явном виде на этой доске. Как фиксируются в явном виде?
Да, вы правы, риски и ограничения фиксируются в явном виде. На PI-планировании для этого выделяется отдельная доска в Миро, затем риски переносятся в Jira и работа с ними так же ведется в течение всего квартала. Но эта часть работы лежит вне плоскости работы с требованиями.
при решении любой задачи первичным, кроме бизнес-процессов, является архитектура этого решения, которая должна ответить на много вопросов, в частности варианты интеграции между системами (расширение существующих интеграций, создание новых и т.п.), участвующие системы и т.п., что в свою очередь имеет большое влияние на оценку трудозатрат. Как в концепции US решается вопрос проработки архитектуры, с учетом того, что ответы на многие вопросы не могут быть получены в режиме групповой проработки и требуют более глубокого и детального изучения и погружения?
US — это способ работы с пользовательскими требованиями, и он никак не исключает необходимости привлечения архитектора решений или системного архитектора к проработке отдельных историй/всего эпика в случае сложных интеграционных взаимодействий. У нас существуют четкие критерии привлечения архитектора к проработке, при этом архитектор решений подключается, как правило, заранее, и на PBR с командой приходит уже с готовой архитектурной схемой.
Очень часто у бизнеса, у заказчика есть идея, есть ожидаемые доходы от реализации идеи и бизнес хочет получить ответ от IT сколько будет стоить реализация его идеи, чтобы понимать нужно вообще инвестировать в это или идея никогда себя не окупит. Чтобы получить ответ на это вопрос необходимо привлекать всю команду, даже в том случае если это просто получение оценки стоимости разработки? Как в это случае избежать формирования ТЗ?
Нет, как раз для верхнеуровневой оценки окупаемости идеи достаточно такой же верхнеуровневой декомпозиции и понимания, сопоставима ли сложность реализации с тем ожидаемым результатом, который вкладывается в идею. При этом ожидаемый результат может измеряться не только прямыми доходами — это ключевое отличие от проектной разработки — здесь полноценно включается в рабочий процесс расчет unit-экономики, но это уже вне границ ответственности аналитика.
как сторипоинты трансформируются в деньги, если это некая абстрактная единица оценки? Любой бизнес-заказчик мыслит деньгами, которые от тратит на внедрение и прибылью, которую он получает? Как понимать заказчику, что оценка в сторипоинтах уместится в его бюджет в рублях, долларах или евро?
Понятие "заказчик" — это снова из проектной разработки. В проектной разработке есть проектный треугольник, и полноценное подробное ТЗ необходимо для того, чтобы заранее выполнить оценку сроков и стоимость разработки всего проекта в силу ограниченности бюджетов.
Мы же говорим про продуктовую разработку, где применим подход работы через MVP, применимы гибкие методологии и есть возможность быстро тестировать гипотезы понятными ресурсами, а затем уже развивать, если гипотезы подтвердились. USM как раз и помогает понять, что нам нужно сделать и в каком объеме, чтобы получить первые результаты — глядя на USM, мы можем понять, сколько спринтов будет работать кросс-функциональная команда над MVP, рассчитать затраты на эту команду в этом периоде, выполнить разработку, снять полученные показатели и понять, а есть ли смысл идти в этом направлении дальше или лучше изменить вектор развития продукта.
Спасибо за ответы! Это круто, когда в статье идет живое конструктивное обсуждение, позволяющее более детально понять мысли автора.
Но исходя из написанного, хочется отметить, что по факту ТЗ существует, но лишь приобретает несколько иную форму: это схемы бизнес-процессов, проработанные аналитиком и согласованные с бизнесом, и артефакты от архитектора решений / системы, которые готовятся предварительно.
То есть по факту, даже при использовании USM "первичная документация" должна быть, , иначе фактуры, на основании которой формируются US нет. О чем вы и написали.
Наверное, не корректно отождествлять требования от бизнеса (оно же ТЗ, оно же БТ) с техническим заданием, разрабатываемым по ГОСТу.
И ещё, ГОСТ 19.101.77 в части листинга программного кода это не про постановку задачи, поэтому пример не совсем корректный. Наличие программного кода (листинга) сейчас до сих пор обязательно при оформлении авторских прав на программу.
хочется отметить, что по факту ТЗ существует, но лишь приобретает несколько иную форму: это схемы бизнес-процессов, проработанные аналитиком и согласованные с бизнесом, и артефакты от архитектора решений / системы, которые готовятся предварительно.
То есть по факту, даже при использовании USM "первичная документация" должна быть, , иначе фактуры, на основании которой формируются US нет. О чем вы и написали
Архитектура и БТ - это все же не ТЗ, даже в классическом подходе, и работа над ними лежит вне скоупа работ аналитика, поэтому их я оставляю за скобками)
И в ГОСТ, например, для этого есть вообще отдельные виды документов.
Тем не менее, вы полностью правы, работа аналитика должна на чем-то базироваться, независимо от подхода через ТЗ или через USM, поэтому БТ + архитектура будут первичными в любом случае.
В моей же статье речь идет как раз о другой форме работы с требованиями именно с точки зрения аналитика - не в формате полновесного документа, а в формате командного взаимодействия на стадии проектирования и формализации требований и описания деталей реализации по итогам обсуждения с командой. И этот формат работы включается только после сбора первичной информации, безусловно.
Наверное, не корректно отождествлять требования от бизнеса (оно же ТЗ, оно же БТ) с техническим заданием, разрабатываемым по ГОСТу.
А вот тут не соглашусь. БТ != ТЗ. БТ - это постановка задачи, на основе которой далее выполняется проработка реализации.
И ещё, ГОСТ 19.101.77 в части листинга программного кода это не про постановку задачи, поэтому пример не совсем корректный. Наличие программного кода (листинга) сейчас до сих пор обязательно при оформлении авторских прав на программу.
Пример про листинг был скорее для того, чтобы показать, что ГОСТ создан очень давно и местами оторван от существующей современной реальности. Листинг - это отдельный документ из общего набора документов, в статье я как раз об этом писала)
В usm как описываются условные переходы, когда все шаги строятся линейно?
Тут возможно несколько вариантов:
Если речь идет о сложном бизнес-процессе, перед переходом на USM прорабатываются бизнес-требования, включающие в себя моделирование бизнес-процесса в BPMN, и в этом случае BPMN перекладывается в USM в рамках перехода от бизнес-требований к пользовательским требованиям.
Если условные переходы — это самостоятельные и независимые US, они размещаются в USM в одном эпике и их реализация может быть разнесена во времени (например, истории "Я как пользователь хочу оплатить заказ..." и "Я как пользователь хочу получить уведомление о возврате средств, если заказ был отменен..." вполне могут реализовываться независимо друг от друга).
Если условные переходы неотделимы и должны реализоваться в одной US, они описываются в пользовательских сценариях / критериях приемки / деталях реализации.
Все это вода никому ненужная. Что ТЗ, что US разницы нет. Все это обертка и упаковка ИТ продукта, а важно что внутри. А внтури у вас команда dev rel разработчиков, тестировщиков делающая продукт. И вот от их вовлеченности и зависит результат. Как они будут работать, такой и результат будет на выходе.
Добрый день!
Можете уточнить следующий момент:
Выделяем исследовательскую стратегию: что войдет в MVP, какие гипотезы у нас есть, как мы сможем их проверить.
Гипотезы выдвигаете на этапе до начала разработки? Гипотезы выдвигает продуктовый аналитик?
Правильно я понимаю, чтобы уйти от этой проблемы, когда "в большинстве случаев, описываемая функциональность системы — это либо личные хотелки заказчика, либо прямое копирование у конкурентов, не подтвержденное исследованиями, гипотезами, опросами, метриками и данными.", нужно выдвигать эти гипотезы на этапе до начала разработки?
User Story Mapping как подход к проектированию