Для меня прототип "средней точности" - схематичный макет, где показываем какие атрибуты/кнопки мне нужны, где примерно, и что хочу видеть. Но разработчик в любом случае делает по дизайн-системе и из тех фронтовых компонентов, что под нее были разработаны. Как раз за счет этого и обеспечивается качество поставляемого UI.
Системный аналитик может сам разработать прототипы "средней точности" в случае, если экраны типовые.
Насчет утверждения о дороговизне - не справедливо. Привлечение дизайнера - это плюс чч на разработку сразу же. При этом без аналитики уточняющей макет это все равно в разработку не отдать. Да, уточнять нужно будет меньше, но все равно нужно. К тому возникают сложности сразу с внесением небольших изменений - поменять нейминг, столбцы местами - вечно "дергать" дизайнера и удлинять процесс разработки.
Предлагаемые мною в статье артефакты и их наполнение достаточно базовые и подходят для большинства команд, в которых есть аналитик. Если и будут варьироваться по составу и наполнению, то очень незначительно.
Благодарю за комментарий и за то, что поделились опытом.
Постановка на разработку - это все-таки как ни крути артефакт процесса на разработку, тут 100% нужно согласовывать шаблоны со всеми лидами (имею ввиду PM, лид разрабов и тд), что именно в таком формате нам всем будет ок. И точно все зависит от зрелости и компетенций самой команды, согласна с вами.
Насчет экзотических изменений подумаю, спасибо. Это видимо будет что-то из разряда самые дорогие факапы)
На мой взгляд, однозначно нужно к этому стремиться. Но могу сказать, что полное отсутствие вопросов всегда пугает нас) Тут нужна золотая середина - и постановки сразу максимально адекватные со стороны аналитика и критическое мышление тех, кто это в работу принимает.
Со временем, когда получаешь одни и те же вопросы, можно дорабатывать шаблоны постановок, писать чек-листы для самопроверки себя, как аналитика и т.д. Таким образом приходя к хорошему взаимопониманию внутри команды.
В идеальной жизни вообще бы такой макет figma, который сразу можно экспортировать в верстку) Но практика показывает, что такое возможно только для зрелых систем, где происходит не очень много изменений от общего процента функций системы, и на все есть актуальные (соответствующие реализации) макеты. Иначе становится очень дорого идеальные макеты поддерживать. Чаще всего используются прототипы средней точности.
Принцип черной коробки по мне имеет смысл в командах, где не предполагается системного аналитика. Тогда вполне может быть такой расклад: стейкхолдер отдал требования, продакт/бизнес-аналитик дополнительно проработал и отдал сразу в разработку.
Все зависит от состава команды.
Успех задач клиент-серверного взаимодействия - либо fullstack-разработчик либо здоровые коммуникации между frontend и backend-разработчиком и аналитиком. В целом без общения внутри команды никуда, какие бы идеальные постановки не были.
Чаще всего согласуют ТЗ, да, но бывают заказчики, которые очень глубоко погружены в процессы разработки информационных систем и хотят участвовать в том числе в согласовании постановок. Поэтому Наталья выше верно это подметила.
Нет, я не предлагаю контроль целостности данных выносить на уровень клиента. Как раз мое предложение в том, что часть проверок будет на бэке и для этого нужно в артефакте "Описание экранных форм" сослаться на алгоритм бэка, где эта логика обязательности поля будет расписана.
За все остальные комментарии благодарю, думаю, будет полезно читателям-аналитикам понимать возможные "подводные камни" в случае описания именно физ. модели и почаще обращаться к разработчикам/архитекторам за консультацией)
Архитекторы есть, но задачи у них другие. Привлекаются к валидации модели данных, если посчитает нужным разработчик. Там есть свои правила взаимодействия.
Насчет физической модели написала свое мнение выше. Насчет алгоритмов - мы не описываем алгоритмы уровня взаимодействия сервисов между собой. Не нужно понимание стека технологий, чтобы, например, описать алгоритм проверки. Это в большей степени бизнесовая последовательность шагов, которая выполнятся системой. Пример на каждый шаблон постараюсь описать в следующей статье, чтобы не возникало лишних вопросов.
Насчет "не хватить компетенций" - аналитики в любом случае не работают в вакууме от другой команды, если команда аналитики слабая и все по итогу переделывается архитекторами/разработчиками, то меняются процессы и шаблоны постановок. В статье поделилась тем, как работает у нас, причем на нескольких проектах.
Я тоже за логическую, но на практике встречалась и с тем, что описывали физическую (как раз выше отвечала на подобный комментарий, это в основном проекты, где мало разработки с "нуля", много доработок уже существующего), поэтому указала обе модели в статье.
Насчет 90% не согласна) Но тут все зависит от компетенций команды аналитики.
Все зависит от конкретной команды и проекта. Например, если в целом проект какой-то небольшой был и мы дорабатывали что-то существующие, то описывали физические модели. Потому что там вся разработка сводилась к тому, что с "нуля" ничего не делаем, просто обогащаем, что есть (добавить поле "комментарий" в таблицу такую-то). Если же очень много новых сущностей, то лично я за то, что отдавать логические модели (на большинстве проектах у нас было именно так).
У нас отдельный шаг согласования требований. Т.е. шаблоны, которые у меня выше, подразумевают, что требования уже согласованы, все всем понятно, нам нужно просто передать все в работу команде.
Внешнюю документацию мы условно делим на входящую и отчетную. Входящая - грубо говоря то, что мы обязаны согласовывать перед тем, как приступить к разработке - ТЗ, форматы обмена данных с какими-то другими системами (если там исполнители другие) и т.д. Отчетная - это ПМИ, пользовательские инструкции и другие документы. Согласуем их с заказчиком уже при приемке работ.
При написании алгоритмов, физической модели аналитики могут проконсультироваться с разработкой, либо потом разработка на этапе получения постановки может указать - "так не можем, потому что есть такие ограничения".
Пыталась сразу описать и для логической и для физической шаблон постановки, поэтому, скорее всего, и возникли такие непонятности.
Верно, если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице". Если первичный ключ композитный, то это два и более поля.
Вопрос обязательности для логической и физической модели данных различается, согласна. Но чаще всего, что было по логической обязательно, становится в конечном итоге и для физической модели обязательно. Постараюсь раскрыть эту тему уже здесь в комментарии.
Для физической модели данных обязательность должна указываться с точки зрения БД - "можно ли вставить строку, не заполнив поле." Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм". При этом, если обязательность какая-то сложная, то стоит добавлять отдельный алгоритм проверки этой обязательности и ссылаться на него.
Для логической модели данных обязательность должна описывать то, без чего сущность не может существовать - т.е. без этого атрибута сущность будет не валидна с точки зрения бизнес-логики. Однако тут явно нужно будет уже с разработкой обсуждать, какие из этих атрибутов логмодели будут в БД обязательными или нет. Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
В любом случае перед тем, как разработчик начнет создавать таблицу по постановке, он должен сказать свое "фи"). Нам, как аналитикам, главное понимать, что эту обязательность нужно не забыть указать в принципе.
Надеюсь, будущим читателям я немного прояснила ситуацию с обязательностью. В целом я за то, что постановки не являются истиной в последней инстанции, и всеми членами команды должны восприниматься всегда критически. У нас, например, даже тестировщик может сказать свое "фи", если разработчик об этом не задумался) Все-таки результат разработки - общая ответственность всей команды, все всегда обсуждаем в процессе.
А если нужно согласовать с заказчиком постановки, то, конечно, стоит сначала обсудить с разработкой, а потом уже бежать согласовывать с заказчиком, чтобы не уйти на миллион итераций согласований.
Тут смотря, какие у заказчика требования. Бывают заказчики, которые с удовольствием хотят посмотреть и техническую часть. Но если заказчик больше про "бизнес", то я бы предложила с ним согласовывать артефакты "Варианты использования" и "Описание экранных форм" (в целом, как вы и делите). Но при этом внутри них, на мой взгляд, уже не желательно размещать какую-то техническую информацию, чтобы не вводить в заблуждение. И, скорее всего, этих артефактов будет недостаточно. Заказчик захочет какой-нибудь очевидной трассируемости - как из конкретного пункта его ТЗ появляется какой-то вариант использования, может быть карту пользовательского пути, схему экранных форм. Тут нужно точно обговаривать ожидания от состава и шаблоны постановок с обеих сторон.
Да, вы верно подметили, если ui нет, то и не будет артефактов, связанных с ним. Классифицировать постановку для читателей тоже можно, однако в моей статье описан подход ведения постановок, используемых именно командой разработки (под командой разработкой я понимаю не только разработчиков, но и тестировщиков, других аналитиков и т.п.).
Согласна с вами на миллион процентов, что у разных читателей будут разные требования к информации. Если заказчик помимо какого-то официального документа, например ТЗ по ГОСТ, требует еще согласовывать с ним постановки, то там явно будут немного другие шаблоны.
Насчет вариантов использования - здорово, конечно, если их можно совместить с форматом ПМИ, но на практике так не всегда удается. Многие заказчики в ПМИ предпочитают видеть именно указание требование из ТЗ и то, как мы его закрываем конкретной функцией системы. Для разработки это может быть слишком большим use case. Но в целом, мы когда процессы на новых проектах выстраиваем, всегда стараемся сделать так, чтобы внутреннюю документацию для команды разработки можно было легко превратить в отчетную для заказчиков или других стейкхолдеров.
"Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д." - тут согласна с вашим комментом, если доступность элемента связана с бэком, то это должно быть ссылкой на алгоритм внутри постановки на экранную форму.
Для меня прототип "средней точности" - схематичный макет, где показываем какие атрибуты/кнопки мне нужны, где примерно, и что хочу видеть. Но разработчик в любом случае делает по дизайн-системе и из тех фронтовых компонентов, что под нее были разработаны. Как раз за счет этого и обеспечивается качество поставляемого UI.
Системный аналитик может сам разработать прототипы "средней точности" в случае, если экраны типовые.
Насчет утверждения о дороговизне - не справедливо. Привлечение дизайнера - это плюс чч на разработку сразу же. При этом без аналитики уточняющей макет это все равно в разработку не отдать. Да, уточнять нужно будет меньше, но все равно нужно. К тому возникают сложности сразу с внесением небольших изменений - поменять нейминг, столбцы местами - вечно "дергать" дизайнера и удлинять процесс разработки.
Предлагаемые мною в статье артефакты и их наполнение достаточно базовые и подходят для большинства команд, в которых есть аналитик. Если и будут варьироваться по составу и наполнению, то очень незначительно.
жалко на хабре нет реакций на сообщения)
Благодарю за комментарий и за то, что поделились опытом.
Постановка на разработку - это все-таки как ни крути артефакт процесса на разработку, тут 100% нужно согласовывать шаблоны со всеми лидами (имею ввиду PM, лид разрабов и тд), что именно в таком формате нам всем будет ок. И точно все зависит от зрелости и компетенций самой команды, согласна с вами.
Насчет экзотических изменений подумаю, спасибо. Это видимо будет что-то из разряда самые дорогие факапы)
Бизнес-аналитик и архитектор приравненные - это что-то страшное) Сочувствую вашему опыту, я с таким не сталкивалась.
Спасибо за поддержку! Я тоже не ожидала такое количество комментариев, казалось бы такая стандартная тема)
Согласна, полное отсутствие вопросов - это звоночек. Самые дорогие ошибки - это ошибки на этапе анализа.
На мой взгляд, однозначно нужно к этому стремиться. Но могу сказать, что полное отсутствие вопросов всегда пугает нас) Тут нужна золотая середина - и постановки сразу максимально адекватные со стороны аналитика и критическое мышление тех, кто это в работу принимает.
Со временем, когда получаешь одни и те же вопросы, можно дорабатывать шаблоны постановок, писать чек-листы для самопроверки себя, как аналитика и т.д. Таким образом приходя к хорошему взаимопониманию внутри команды.
В идеальной жизни вообще бы такой макет figma, который сразу можно экспортировать в верстку) Но практика показывает, что такое возможно только для зрелых систем, где происходит не очень много изменений от общего процента функций системы, и на все есть актуальные (соответствующие реализации) макеты. Иначе становится очень дорого идеальные макеты поддерживать. Чаще всего используются прототипы средней точности.
Принцип черной коробки по мне имеет смысл в командах, где не предполагается системного аналитика. Тогда вполне может быть такой расклад: стейкхолдер отдал требования, продакт/бизнес-аналитик дополнительно проработал и отдал сразу в разработку.
Все зависит от состава команды.
Успех задач клиент-серверного взаимодействия - либо fullstack-разработчик либо здоровые коммуникации между frontend и backend-разработчиком и аналитиком. В целом без общения внутри команды никуда, какие бы идеальные постановки не были.
Да, разработчики обязательно критически смотрят на все то, что мы напридумывали)
Чаще всего согласуют ТЗ, да, но бывают заказчики, которые очень глубоко погружены в процессы разработки информационных систем и хотят участвовать в том числе в согласовании постановок. Поэтому Наталья выше верно это подметила.
Нет, я не предлагаю контроль целостности данных выносить на уровень клиента. Как раз мое предложение в том, что часть проверок будет на бэке и для этого нужно в артефакте "Описание экранных форм" сослаться на алгоритм бэка, где эта логика обязательности поля будет расписана.
За все остальные комментарии благодарю, думаю, будет полезно читателям-аналитикам понимать возможные "подводные камни" в случае описания именно физ. модели и почаще обращаться к разработчикам/архитекторам за консультацией)
Архитекторы есть, но задачи у них другие. Привлекаются к валидации модели данных, если посчитает нужным разработчик. Там есть свои правила взаимодействия.
Насчет физической модели написала свое мнение выше. Насчет алгоритмов - мы не описываем алгоритмы уровня взаимодействия сервисов между собой. Не нужно понимание стека технологий, чтобы, например, описать алгоритм проверки. Это в большей степени бизнесовая последовательность шагов, которая выполнятся системой. Пример на каждый шаблон постараюсь описать в следующей статье, чтобы не возникало лишних вопросов.
Насчет "не хватить компетенций" - аналитики в любом случае не работают в вакууме от другой команды, если команда аналитики слабая и все по итогу переделывается архитекторами/разработчиками, то меняются процессы и шаблоны постановок. В статье поделилась тем, как работает у нас, причем на нескольких проектах.
Я тоже за логическую, но на практике встречалась и с тем, что описывали физическую (как раз выше отвечала на подобный комментарий, это в основном проекты, где мало разработки с "нуля", много доработок уже существующего), поэтому указала обе модели в статье.
Насчет 90% не согласна) Но тут все зависит от компетенций команды аналитики.
Все зависит от конкретной команды и проекта. Например, если в целом проект какой-то небольшой был и мы дорабатывали что-то существующие, то описывали физические модели. Потому что там вся разработка сводилась к тому, что с "нуля" ничего не делаем, просто обогащаем, что есть (добавить поле "комментарий" в таблицу такую-то). Если же очень много новых сущностей, то лично я за то, что отдавать логические модели (на большинстве проектах у нас было именно так).
У нас отдельный шаг согласования требований. Т.е. шаблоны, которые у меня выше, подразумевают, что требования уже согласованы, все всем понятно, нам нужно просто передать все в работу команде.
Внешнюю документацию мы условно делим на входящую и отчетную. Входящая - грубо говоря то, что мы обязаны согласовывать перед тем, как приступить к разработке - ТЗ, форматы обмена данных с какими-то другими системами (если там исполнители другие) и т.д. Отчетная - это ПМИ, пользовательские инструкции и другие документы. Согласуем их с заказчиком уже при приемке работ.
При написании алгоритмов, физической модели аналитики могут проконсультироваться с разработкой, либо потом разработка на этапе получения постановки может указать - "так не можем, потому что есть такие ограничения".
Пыталась сразу описать и для логической и для физической шаблон постановки, поэтому, скорее всего, и возникли такие непонятности.
Верно, если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице". Если первичный ключ композитный, то это два и более поля.
Вопрос обязательности для логической и физической модели данных различается, согласна. Но чаще всего, что было по логической обязательно, становится в конечном итоге и для физической модели обязательно. Постараюсь раскрыть эту тему уже здесь в комментарии.
Для физической модели данных обязательность должна указываться с точки зрения БД - "можно ли вставить строку, не заполнив поле." Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм". При этом, если обязательность какая-то сложная, то стоит добавлять отдельный алгоритм проверки этой обязательности и ссылаться на него.
Для логической модели данных обязательность должна описывать то, без чего сущность не может существовать - т.е. без этого атрибута сущность будет не валидна с точки зрения бизнес-логики. Однако тут явно нужно будет уже с разработкой обсуждать, какие из этих атрибутов логмодели будут в БД обязательными или нет. Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
В любом случае перед тем, как разработчик начнет создавать таблицу по постановке, он должен сказать свое "фи"). Нам, как аналитикам, главное понимать, что эту обязательность нужно не забыть указать в принципе.
Надеюсь, будущим читателям я немного прояснила ситуацию с обязательностью. В целом я за то, что постановки не являются истиной в последней инстанции, и всеми членами команды должны восприниматься всегда критически. У нас, например, даже тестировщик может сказать свое "фи", если разработчик об этом не задумался) Все-таки результат разработки - общая ответственность всей команды, все всегда обсуждаем в процессе.
А если нужно согласовать с заказчиком постановки, то, конечно, стоит сначала обсудить с разработкой, а потом уже бежать согласовывать с заказчиком, чтобы не уйти на миллион итераций согласований.
Тут смотря, какие у заказчика требования. Бывают заказчики, которые с удовольствием хотят посмотреть и техническую часть. Но если заказчик больше про "бизнес", то я бы предложила с ним согласовывать артефакты "Варианты использования" и "Описание экранных форм" (в целом, как вы и делите). Но при этом внутри них, на мой взгляд, уже не желательно размещать какую-то техническую информацию, чтобы не вводить в заблуждение. И, скорее всего, этих артефактов будет недостаточно. Заказчик захочет какой-нибудь очевидной трассируемости - как из конкретного пункта его ТЗ появляется какой-то вариант использования, может быть карту пользовательского пути, схему экранных форм. Тут нужно точно обговаривать ожидания от состава и шаблоны постановок с обеих сторон.
Да, вы верно подметили, если ui нет, то и не будет артефактов, связанных с ним. Классифицировать постановку для читателей тоже можно, однако в моей статье описан подход ведения постановок, используемых именно командой разработки (под командой разработкой я понимаю не только разработчиков, но и тестировщиков, других аналитиков и т.п.).
Согласна с вами на миллион процентов, что у разных читателей будут разные требования к информации. Если заказчик помимо какого-то официального документа, например ТЗ по ГОСТ, требует еще согласовывать с ним постановки, то там явно будут немного другие шаблоны.
Насчет вариантов использования - здорово, конечно, если их можно совместить с форматом ПМИ, но на практике так не всегда удается. Многие заказчики в ПМИ предпочитают видеть именно указание требование из ТЗ и то, как мы его закрываем конкретной функцией системы. Для разработки это может быть слишком большим use case. Но в целом, мы когда процессы на новых проектах выстраиваем, всегда стараемся сделать так, чтобы внутреннюю документацию для команды разработки можно было легко превратить в отчетную для заказчиков или других стейкхолдеров.
"Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д." - тут согласна с вашим комментом, если доступность элемента связана с бэком, то это должно быть ссылкой на алгоритм внутри постановки на экранную форму.
Благодарю за дополнения)