Привет! Я лид системных аналитиков в департаменте корпоративных систем ЛАНИТ. В этой статье я расскажу, как писать качественные постановки на разработку информационной системы.
Я часто сталкиваюсь с вопросом, как корректно передавать аналитические требования разработчикам. Я участвовала в проектах, где процесс постановки был выстроен качественно. Там я набиралась опыта и впитывала знания. Но были и проекты, где вообще никаких постановок не было — только устные договоренности и полотна текста в Jira. Недавно мне вовсе пришлось выстраивать процесс написания постановок с нуля. В этот момент я переосмыслила все предыдущие шаблоны. Теперь хочу поделиться своим видением с вами.
Постановка на разработку — это описание, которое прикладывается к задаче на разработку. Ее еще называют описанием постановки задачи (ОПЗ), частным техническим заданием (ЧТЗ), спецификацией на разработку.
Что же такое качественная постановка? Это постановка:
где есть минимум необходимой для разработки информации;
которая создается не ради отчетной документации, а ради пользы;
из которой легко образуется база знаний о системе, своего рода внутренняя техническая документация, которую будут использовать и разработчики, и команда тестирования, и вы, если обнулитесь через полгода с мыслью “а как же вообще это работает”.
В этой статье я не буду говорить о требованиях (держим в голове, что мы их уже собрали, уточнили, поделили на функциональные и нефункциональные). Также не буду рассказывать о том, как из требований сделать постановку. Представим, что вам как аналитику все понятно; пользовательский путь и экранные формы уже спроектированы, остается передать все в работу.
В качественную постановку на разработку должны входить следующие артефакты.
Описание экранных форм — определяет правила работы каждого элемента интерфейса, документирует состояния и переходы.
Модель данных — определяет схему сущностей, связи, а также атрибутивный состав сущностей.
Варианты использования — пользовательские сценарии использования (use case).
Алгоритмы — пошаговая логика, определяющая поведение системы при взаимодействии с ней.
Постановку на разработку можно разделить на две части: постановка на frontend и постановка на backend.
Прежде чем начать писать постановки на frontend и backend, необходимо описать варианты использования (use case). Этот артефакт нужен обеим группам разработки.
Артефакт «Вариант использования» должен включать предусловие возникновения действия, участников, само действие, а также результат. Не буду останавливаться детально, так как эта информация есть во многих источниках. Единственное, чем я ее рекомендую дополнить, — это указание на то, на каких экранных формах этот вариант использования вызывается, а также то, какие алгоритмы внутри себя инициирует. Когда вы опишете этот артефакт в части основных блоков — участники, действия, результат — приступайте к следующим. В конце еще раз вернемся к нему.
Постановка на frontend
Главный артефакт для frontend-разработчиков — описание экранных форм, которое состоит из прототипа интерфейса и его описания (рисунок 1). Прототип позволяет понять структуру экрана, атрибутивный состав, а также состав элементов управления. Описание дополняет информацию о визуализированных элементах интерфейса, определяет логику их работы, дает информацию о том, какими должны быть проверки. Чем детализированнее прототип, тем меньше информации необходимо фиксировать в постановке. Тогда прототип становится не просто частью описания экранной формы, а полноценной постановкой для верстки экранов. Однако часто при разработке информационных систем используются прототипы средней точности и большая часть уточняющих сведений располагается в описательной части постановки. Мой предлагаемый типовой шаблон создан как раз для такого прототипа (рисунок 1).
Описание экранной формы должно включать ряд аспектов.
1) Указание на элемент, помогающее понять, о чем идет речь. Может быть представлено как его название или нумерация на экранной форме. Рекомендую в качестве идентификации элемента использовать его наименование на макете интерфейса. Например, есть ли у вас поле «ФИО» на экране, назовите его так же при описании экранной формы в текстовом виде. Обещаю, что ваша команда и так вас поймет, а вы сэкономите кучу времени, не добавляя нумерацию на макете и не обновляя ее при появлении новых полей на форме.
2) Назначение, позволяющее понять более четко смысл данного элемента. Например, если изображена иконка вопросительного знака, вы в описании назначения указываете, что этот элемент необходим для открытия пользовательской инструкции.
3) Обязательность — это атрибут, указывающий на обязательность заполнения поля в интерфейсе. Подразделяется на прямую (да или нет), а также условную обязательность: если заполнено поле x, то поле y обязательно к заполнению.
3) Тип атрибута определяет его вид и поведение, наиболее распространенные из которых:
фильтр;
поле поиска;
сортировка;
поле ввода или вывода информации;
поле ввода дат;
выпадающий список единичный;
выпадающий список множественный;
чекбокс;
радиобаттон;
кнопка;
ссылка.
3) Источник данных — характеристика модели данных, указывающая на то, откуда поле выводит значение или куда сохраняет его, если форма предполагает редактирование. Для полей с типом «фильтр», «поле поиска», «кнопка» не применяется.
4) Плейсхолдер — подсказка, которая должна выводиться внутри поля для того, чтобы было легче понять, чем его заполнять. Не всегда применимо для всех проектов, так как подсказки могут быть реализованы иным способом. Однако не стоит забывать, что важно указать данную характеристику интерфейса.
5) Значение по умолчанию — характеристика, определяющая логику заполнения поля до того, как ее заполнил пользователь. Например, дата начала может автоматически заполняться текущей датой.
6) Сортировка по умолчанию — характеристика, применимая для типов «выпадающий список»; указывает на то, как именно должны сортироваться сведения.
7) Условия вывода/активности — атрибут, определяющий логику отображения элемента пользователю. Может зависеть от ролевой модели, может быть условно-обязательным. Например, если не выполняется какая-то проверка, то кнопка сохранения может быть заблокирована.
8) Редактирование — свойство, применимое для всех типов элементов, за исключением элементов управления — кнопок, иконок.
9) Комментарий — поле, позволяющее описать все, что не было описано в предыдущих характеристиках элемента интерфейса. Например, если вы описываете элемент сортировки, то необходимо указание на то, какая из них будет применена по умолчанию. Также в комментарии можно добавить информацию о проверке на стороне frontend: например, валидацию введенного текста по маске ввода.
Кроме того, в качестве общих рекомендаций при описании экранной формы я бы добавила следующее.
1) Общие части интерфейса, например, единообразное меню, “шапку” страницы и “подвал”, не стоит добавлять в каждое описание экранной формы. Вынесите это в раздел общих требований к интерфейсу и во всех новых постановках ссылайтесь на него. Это необходимо не только для ускорения процесса написания постановок, но и для обеспечения единообразной реализации общих элементов.
2) Если какие-то характеристики не применимы для описания вашей экранной формы, удаляйте столбцы с ними, чтобы не перегружать ненужной информацией постановку. Например, если форма предполагает только просмотровый формат, то нет смысла описывать плейсхолдеры, а также условия редактируемости.
3) Располагайте описание элементов в том порядке, в котором они расположены на прототипе. Это поможет быстрее понимать, о каком именно элементе идет речь.
4) Если для элемента не удается определить источник данных, то обсудите это с разработкой. Возможно, его предстоит добавить в модель данных.
5) Перед описанием элементов интерфейсов не забывайте указывать общее описание экранной формы, для чего она нужна, кто основные пользователи, какой пользовательский путь был до нее (даже при условии, что он отрисован где-то отдельно). Несмотря на то, что контекст уже собран ранее, никогда не бывает лишним добавить один небольшой абзац.
6) Если получается слишком сложное описание проверок, то, возможно, это сигнал к тому, что проверка должна быть в алгоритме на стороне backend.
7) Помимо ссылки на прототип экранной формы добавляйте еще скриншот на случай, если со ссылкой что-то случится.
Написав такую постановку, frontend-разработчик понимает ожидаемый результат. Остается дождаться backend, и можно воплощать идею в реальность.
Постановка на backend
Давайте обсудим, что же нужно backend. Прежде всего, необходима модель данных, а также понимание, какие действия с объектами этой модели вы собираетесь выполнять.
То, в каком виде вы описываете модель данных, может варьироваться от проекта к проекту. Где-то аналитики проектируют сразу физическую модель и описывают ее, привлекая разработчиков или архитекторов для консультации, а где-то приводят только логическую модель.
Обычно описание модели включает схему и таблицу с описанием (рисунок 2).
Название таблицы: если описывается логическая модель, указывается название сущности, если речь идет о физической модели — название таблицы в базе данных.
Наименование атрибута: если описывается физическая модель данных, то указывается наименование атрибута в базе данных, если логическая модель — логическое наименование.
Тип: по данной характеристике как и для физической, так и для логической модели данных рекомендую указывать логическую типизацию — текст, дату, идентификатор, число. Это важно, поскольку вы можете не знать нюансов присвоения тех или иных типов, которые приняты среди разработчиков. Допустим, вы знаете, что в значении атрибута будет храниться текст и считаете, что подходит string, а на самом деле уместен json. Рекомендую указывать точный формат по базе данных только в том случае, если вы описываете уже существующие атрибуты сущности.
Обязательность: без нее невозможно существование записи в БД. Если не уверены, то оставьте поле незаполненным. Чаще всего обязательны первичный ключ, бизнес-идентификаторы, наименование.
Значение по умолчанию должно быть присвоено записи. Например, атрибутам с типом boolean по умолчанию присваивается true.
После того, как модель данных описана, необходимо зафиксировать логику работы с этими сущностями, а именно алгоритмы. Алгоритмы — это по сути детализация действий системы, которая происходит при инициализации того или иного варианта использования.
Если вы создаете заказ, в рамках варианта использования «Создание заказа» инициируется целый алгоритм, который при обработке должен учитывать все возможные нюансы.
При описании алгоритма необходимо указать входные и выходные параметры, шаги алгоритмов, логику обработки возникающих ошибок, а также альтернативные подалгоритмы. Еще стоит указывать инициирующий вариант использования, однако это необязательно, так как у вас будет много системных алгоритмов, не инициируемых с интерфейса. Часто алгоритмы получаются непростыми, поэтому рекомендую добавлять не только текстовое описание, но и приводить схему.
Типовой шаблон на постановку алгоритма описан ниже (рисунок 3):
По итогам написания постановки на frontend и backend вам необходимо обогатить артефакт «Варианты использования» информацией о том, на какой экранной форме это действие вызывается, а также ссылкой на ваши алгоритмы. Так вы обеспечите связанность всех постановок.
Проверьте себя еще раз, перечитайте свои спецификации, создайте задачу в таск-трекере и приложите описанные вами артефакты. Созвонитесь с разработчиком, введите его в контекст по постановке, сразу ответьте на его вопросы. Вполне возможно, что он порекомендует вам изменить алгоритм и модель данных, но это вопросы уже для другой статьи.
Комментарии (48)
Akina
13.01.2026 07:49Что-то какая-то непонятность в части описания модели. Даже если брать чисто физическую. Вы вместо стандартных для хранилища данных терминов используете абстрактное "атрибут"... но далее по тексту сперва выясняется, что у этого атрибута имеется тип данных, то есть имеется в виду конкретное поле, но затем к атрибутам относите и первичный ключ, который вполне может быть функциональным или композитным. То есть вы используете один термин, но в нём валите в кучу несколько совершенно различных сущностей. Что, кстати, чревато и непониманием - скажем, вторичный ключ имеет самостоятельное имя, которое может интерферировать с именем поля.
Опять же странно вы трактуете обязательность. Со стороны хранилища данных она может быть двоякой - во-первых, это может быть NULLability (поле не может быть NULL, обязано содержать хоть какое-то значение), во-вторых, это может быть и требование наличия непустого или подпадающего под некий шаблон значения (скажем, текстовое поле не может содержать пустую строку или строку из только пробельных символов). Тут вы скорее должны описывать ограничения на поле, которые могут быть как простыми (NOT NULL), так и достаточно комплексными (которые в структуре хранения преобразуются в соответствующий CHECK). Более того, ограничения могут быть и не привязаны к конкретному полю (table-level CHECK и даже триггерная логика - при необходимости в ходе контроля обращаться к другим записям и/или таблицам).
А ведь у вас постановка. И если всё вышеуказанное не будет в ней однозначно и полно определено, вас ждёт продолжительный и очень увлекательный процесс итеративного согласования. И вам сильно повезёт, если он завершится до стадии практической реализации. Ну и толку тогда от этой постановки?
alingrishko Автор
13.01.2026 07:49Пыталась сразу описать и для логической и для физической шаблон постановки, поэтому, скорее всего, и возникли такие непонятности.
Верно, если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице". Если первичный ключ композитный, то это два и более поля.
Вопрос обязательности для логической и физической модели данных различается, согласна. Но чаще всего, что было по логической обязательно, становится в конечном итоге и для физической модели обязательно. Постараюсь раскрыть эту тему уже здесь в комментарии.
Для физической модели данных обязательность должна указываться с точки зрения БД - "можно ли вставить строку, не заполнив поле." Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм". При этом, если обязательность какая-то сложная, то стоит добавлять отдельный алгоритм проверки этой обязательности и ссылаться на него.
Для логической модели данных обязательность должна описывать то, без чего сущность не может существовать - т.е. без этого атрибута сущность будет не валидна с точки зрения бизнес-логики. Однако тут явно нужно будет уже с разработкой обсуждать, какие из этих атрибутов логмодели будут в БД обязательными или нет. Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
В любом случае перед тем, как разработчик начнет создавать таблицу по постановке, он должен сказать свое "фи"). Нам, как аналитикам, главное понимать, что эту обязательность нужно не забыть указать в принципе.
Надеюсь, будущим читателям я немного прояснила ситуацию с обязательностью. В целом я за то, что постановки не являются истиной в последней инстанции, и всеми членами команды должны восприниматься всегда критически. У нас, например, даже тестировщик может сказать свое "фи", если разработчик об этом не задумался) Все-таки результат разработки - общая ответственность всей команды, все всегда обсуждаем в процессе.
А если нужно согласовать с заказчиком постановки, то, конечно, стоит сначала обсудить с разработкой, а потом уже бежать согласовывать с заказчиком, чтобы не уйти на миллион итераций согласований.
Akina
13.01.2026 07:49если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице".
Наверное, всё же "объект в таблице". Представьте, что вам нужно, чтобы комбинация из года и порядкового номера была уникальна. Вам придётся создать: поле года, поле номера, уникальный индекс по комбинации этих полей. Или, если год берётся из, скажем, даты создания, то уникальный индекс будет функциональным. То есть это должны быть три строки в вашей таблице. А полей-то всего два... то есть от третьей строки, описывающей ограничение, вам никуда не деться, а уж будет финально это ограничение реализовано как индекс или иным способом - это вопрос, решаемый скорее на стадии реализации.
Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм".
Уж не предлагаете ли вы весь контроль целостности данных вынести на уровень клиента (код бэка, а то ещё и, не приведи господи, фронта)? Если да - то это ну очень нехорошее решение. Сами знаете - если неприятность может случиться, она случается. Или, в данном случае, появление в базе невалидных и/или несогласованных данных - это всего лишь вопрос времени. Как - в результате программной ошибки, сбоя, необдуманных или злонамеренных действий, дело десятое, но оно точно будет. Не должны формы заниматься таким контролем, они должны выполнять только первичную валидацию данных, то есть их слово "сойдёт" далеко не окончательное.
Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
А это как раз пример сложного ограничения. Но тем не менее вполне реализуемый на уровне подсистемы контроля целостности СУБД. В вашей схеме - для такой сущности требуются признаки "необходимо получить идентификатор" и "необходимо получить персональную информацию", по которым будут работать демоны, обращающиеся во внешние сервисы с соответствующими запросами. И если первый признак получил значение "выполнено", то поле идентификатора становится обязательным, а если и второй признак, то и поле фамилии. Да, получится немного обратная ситуация - БД не даст изменить значение признака без заполнения значения логически связанного поля. Но главное, что это приведёт к ошибке, детектирующей нештатную ситуацию, требующую внимания и обработки, и заблокирует появление в таблице невалидной записи.
Даже если всё это забота внешнего для СУБД программного кода, отказ от валидации на уровне хранения данных - неразумно. Тем более что проверка выполняется только в момент изменения записи, то есть способна создать ощутимую дополнительную нагрузку в СУБД лишь в случае массированных пакетных операций.
alingrishko Автор
13.01.2026 07:49Нет, я не предлагаю контроль целостности данных выносить на уровень клиента. Как раз мое предложение в том, что часть проверок будет на бэке и для этого нужно в артефакте "Описание экранных форм" сослаться на алгоритм бэка, где эта логика обязательности поля будет расписана.
За все остальные комментарии благодарю, думаю, будет полезно читателям-аналитикам понимать возможные "подводные камни" в случае описания именно физ. модели и почаще обращаться к разработчикам/архитекторам за консультацией)
Nataly925
13.01.2026 07:49А как такую постановку согласовать с заказчиком?
Обычно делю постановку на 2 блока:
1 блок - последовательность действий пользователя, с макетами форм и ожидаемыми реакциями системы. На языке, понятном заказчику.
Этот же блок используется для тестирования и для подготовки пользовательской инструкции.2 блок - это техническая часть: архитектура, объекты, алгоритмы и т.д. По ходу текста ссылки на разделы 1го блока.
alingrishko Автор
13.01.2026 07:49Тут смотря, какие у заказчика требования. Бывают заказчики, которые с удовольствием хотят посмотреть и техническую часть. Но если заказчик больше про "бизнес", то я бы предложила с ним согласовывать артефакты "Варианты использования" и "Описание экранных форм" (в целом, как вы и делите). Но при этом внутри них, на мой взгляд, уже не желательно размещать какую-то техническую информацию, чтобы не вводить в заблуждение. И, скорее всего, этих артефактов будет недостаточно. Заказчик захочет какой-нибудь очевидной трассируемости - как из конкретного пункта его ТЗ появляется какой-то вариант использования, может быть карту пользовательского пути, схему экранных форм. Тут нужно точно обговаривать ожидания от состава и шаблоны постановок с обеих сторон.
Nataly925
13.01.2026 07:49Да, конечно, поэтому два блока в одном документе.
Заказчик может и техническую часть поизучать, если захочет.
Как и разработчик - логическую часть, для понимания задачи в целом.
SSukharev
13.01.2026 07:49Постановка на разработку с заказчиком не согласуется, с заказчиком согласуется ТЗ.
alingrishko Автор
13.01.2026 07:49Чаще всего согласуют ТЗ, да, но бывают заказчики, которые очень глубоко погружены в процессы разработки информационных систем и хотят участвовать в том числе в согласовании постановок. Поэтому Наталья выше верно это подметила.
allter
13.01.2026 07:49Не увидел в перечне артефактов "требований". Получается, что вы их "перемалываете" в готовые схемы данных? Или, например, у вас отдельный шаг согласования требований перед этапом разработки ЧТЗ? Или требования указаны наряду с другими UC (например, в формате user story)?
Какой подход к внешней документации (описания протоколов интеграции разрабатываемой системы и т.п.)?
Ну и плюс непонятно, как производится разработка алгоритмов и баз данных (физической модели) - у вас аналитиков есть эксперты по используемым системам/технологиям (что бы понимать их ограничения). Или тут речь о том, что бы избавить исполнителей разработчиков от именования сущностей и т.п. ?
alingrishko Автор
13.01.2026 07:49У нас отдельный шаг согласования требований. Т.е. шаблоны, которые у меня выше, подразумевают, что требования уже согласованы, все всем понятно, нам нужно просто передать все в работу команде.
Внешнюю документацию мы условно делим на входящую и отчетную. Входящая - грубо говоря то, что мы обязаны согласовывать перед тем, как приступить к разработке - ТЗ, форматы обмена данных с какими-то другими системами (если там исполнители другие) и т.д. Отчетная - это ПМИ, пользовательские инструкции и другие документы. Согласуем их с заказчиком уже при приемке работ.
При написании алгоритмов, физической модели аналитики могут проконсультироваться с разработкой, либо потом разработка на этапе получения постановки может указать - "так не можем, потому что есть такие ограничения".
allter
13.01.2026 07:49Спасибо!
Т.е. у вас, получается, кроме этапа "приёмки требований" есть ещё отдельный этап "приёмки ЧТЗ", где можно уточнить и поправить? Здорово (не везде так)!
alingrishko Автор
13.01.2026 07:49Да, разработчики обязательно критически смотрят на все то, что мы напридумывали)
softshape
13.01.2026 07:49А почему в ТЗ смешиваются "что" и "как" ? То есть почему названия сущностей, схему данных и т.п. придумывает аналитик, а не разработчик?
RepppINTim
13.01.2026 07:49Согласен, физическую схему (типы полей, индексы) должен тюнить разработчик, но логическую (какие сущности и как связаны) обязан дать аналитик, иначе это не аналитика, а просто хотелки
Ivan22
13.01.2026 07:49Схему данных разработчику доверять делать нельзя. Ибо она должна быть конситентной для всего предприятия, а это часто сотни разработчиков из десятков команд. То же самое с нейминг конвециями. И даже с типами данных. Это уровень архитектуры
softshape
13.01.2026 07:49Конечно, поэтому делать ее должен архитектор или тимлид, а не постановщик ТЗ.
alingrishko Автор
13.01.2026 07:49Все зависит от конкретной команды и проекта. Например, если в целом проект какой-то небольшой был и мы дорабатывали что-то существующие, то описывали физические модели. Потому что там вся разработка сводилась к тому, что с "нуля" ничего не делаем, просто обогащаем, что есть (добавить поле "комментарий" в таблицу такую-то). Если же очень много новых сущностей, то лично я за то, что отдавать логические модели (на большинстве проектах у нас было именно так).
uvelichitel
13.01.2026 07:49Взгляд backend разработчика. Постановки такого уровня детализации, с физической моделью данных и описанием алгоритмов ожидаешь скорее от архитекторов. То есть специалистов с высокой технической экспертизой и знанием задействованного стека технологий. От аналитика скорее ждешь абстракций выше, что нибудь вроде диздок... Вы не слишком тянете одеяло на себя? Может ведь не хватить компетенций...
Ivan22
13.01.2026 07:49это видимо потому что нету у них архитекторов. А так да, я в роли архитектора всегда модель данных делаю сам и никому не доверяю
alingrishko Автор
13.01.2026 07:49Архитекторы есть, но задачи у них другие. Привлекаются к валидации модели данных, если посчитает нужным разработчик. Там есть свои правила взаимодействия.
alingrishko Автор
13.01.2026 07:49Насчет физической модели написала свое мнение выше. Насчет алгоритмов - мы не описываем алгоритмы уровня взаимодействия сервисов между собой. Не нужно понимание стека технологий, чтобы, например, описать алгоритм проверки. Это в большей степени бизнесовая последовательность шагов, которая выполнятся системой. Пример на каждый шаблон постараюсь описать в следующей статье, чтобы не возникало лишних вопросов.
Насчет "не хватить компетенций" - аналитики в любом случае не работают в вакууме от другой команды, если команда аналитики слабая и все по итогу переделывается архитекторами/разработчиками, то меняются процессы и шаблоны постановок. В статье поделилась тем, как работает у нас, причем на нескольких проектах.
RepppINTim
13.01.2026 07:49Хороший шаблон, но есть нюанс: если аналитик рисует физическую модель данных до согласования с бэкендером, в 90% случаев ее приходится переделывать. Разработчик знает нюансы нормализации, индексов и производительности конкретной СУБД лучше. Я бы оставил аналитику логическую модель, а физику отдал бы техлиду или сеньору, чтобы не делать двойную работу
alingrishko Автор
13.01.2026 07:49Я тоже за логическую, но на практике встречалась и с тем, что описывали физическую (как раз выше отвечала на подобный комментарий, это в основном проекты, где мало разработки с "нуля", много доработок уже существующего), поэтому указала обе модели в статье.
Насчет 90% не согласна) Но тут все зависит от компетенций команды аналитики.
alexanderniki
13.01.2026 07:49Удваиваю. Кстати, ровно то же самое происходит, когда аналитик пытается проектировать UI
venanen
13.01.2026 07:49Для UI лучшей постановкой будет ссылка на хороший и качественный макет в figma с отрисовкой логики работы. Для backend, имхо, лучше всего подходит принцип черной коробки - нюансы реализации аналитик все равно не знает, поэтому вход такой, эффект такой, выход такой. Самое сложное возникает в задачах клиент-серверного взаимодействия - там и контракты согласовывать надо, и для фронта описывать API, для бекенда входные параметры.
alingrishko Автор
13.01.2026 07:49В идеальной жизни вообще бы такой макет figma, который сразу можно экспортировать в верстку) Но практика показывает, что такое возможно только для зрелых систем, где происходит не очень много изменений от общего процента функций системы, и на все есть актуальные (соответствующие реализации) макеты. Иначе становится очень дорого идеальные макеты поддерживать. Чаще всего используются прототипы средней точности.
Принцип черной коробки по мне имеет смысл в командах, где не предполагается системного аналитика. Тогда вполне может быть такой расклад: стейкхолдер отдал требования, продакт/бизнес-аналитик дополнительно проработал и отдал сразу в разработку.
Все зависит от состава команды.
Успех задач клиент-серверного взаимодействия - либо fullstack-разработчик либо здоровые коммуникации между frontend и backend-разработчиком и аналитиком. В целом без общения внутри команды никуда, какие бы идеальные постановки не были.
Cordekk
13.01.2026 07:49Тут у меня сразу вопрос: а надо ли писать, так, чтобы не было вопросов со стороны разработки?
Я как раз набросывал статью по этому поводу, но она пока крайне сырая, поэтому пока не публикую. Но первая идея, что задачи всё равно надо обсуждать, поэтому при постановке задачи, вопросы должны быть.
whoisking
13.01.2026 07:49Однозначно должны быть, только через вопросы и общение можно прийти к единому пониманию, плюс, разработчик со своей стороны всегда может задать вопрос, который возникнет только у него, т.к. он больше всех погружен в техническую реализацию, а специфика технической реализации порой может заставить переработать и даже весь UI и даже какие-то архитектурные основы проекта.
Cordekk
13.01.2026 07:49Да просто есть пример из практики. Разработчик взял подробно описанную задачу, вроде ему всё было понятно, но сделал не так, как надо было. Пришлось потом переделывать в следующем спринте.
alingrishko Автор
13.01.2026 07:49На мой взгляд, однозначно нужно к этому стремиться. Но могу сказать, что полное отсутствие вопросов всегда пугает нас) Тут нужна золотая середина - и постановки сразу максимально адекватные со стороны аналитика и критическое мышление тех, кто это в работу принимает.
Со временем, когда получаешь одни и те же вопросы, можно дорабатывать шаблоны постановок, писать чек-листы для самопроверки себя, как аналитика и т.д. Таким образом приходя к хорошему взаимопониманию внутри команды.
Cordekk
13.01.2026 07:49Ну если будут однотипные вопросы, то да, стоит наверно поменять постановку. А в остальном, надо придерживаться золотой середины.
OlegZH
13.01.2026 07:49Постановка на разработку — это описание, которое прикладывается к задаче на разработку. Ее еще называют описанием постановки задачи (ОПЗ), частным техническим заданием (ЧТЗ), спецификацией на разработку.
Это именно начальная спецификация?
В качественную постановку на разработку должны входить следующие артефакты.
Описание экранных форм — определяет правила работы каждого элемента интерфейса, документирует состояния и переходы.
Модель данных — определяет схему сущностей, связи, а также атрибутивный состав сущностей.
Варианты использования — пользовательские сценарии использования (use case).
Алгоритмы — пошаговая логика, определяющая поведение системы при взаимодействии с ней.
Это всё — довольно конкретные вещи. Если же думать только про постановку на разработку, то следует ожидать систематического описания (анализа) предметной области. Начинать следует, скорее, с алгоритмов, то есть — снизу вверх. Остальное допускает довольно широкий выбор. Мы можем использовать различные таблицы для различных сущностей, а можем загрузить различные сущности в одну таблицу, но иметь иерархию сущностей. А уж каково разнообразие экранных форм! Любую форму можно представить одним длинным листом, а можно и мастером с возможностью возврата на предыдущие шаги. Какой смысл что-то фиксировать? Иногда забавно наблюдать какой-нибудь выпадающий список, который, на самом деле, можно заменить набором элементов, явным образом присутствующих на странице. И много чего похожего.
THEOILMAN
13.01.2026 07:49Помню в универе изучали rational rose который, в теории, должен был по сабжу закрывать все вопросы =D Отношения к разработке не имею, но всё равно это воспоминание позабавило.
SSukharev
13.01.2026 07:49RR появился тогда, когда стали делить задачу на двух исполнителей - аналитика и кодировщика, тупого индуса. За неимением RR в начале 90х мы писали задачи кодировщику прямо в редакторе комментариями.
tik4
13.01.2026 07:49Статья хорошая, а вот заголовок плохой :) Как показывает жизнь - если ни у кого нет вопросов, то это дурной знак, т.к. никто толком ничего не читал и не осмысливал. Значит все пойдёт "по бороде" при разработке (в лучшем случае), тестировании (уже хуже) или эксплуатации (ваще караул)
alingrishko Автор
13.01.2026 07:49Согласна, полное отсутствие вопросов - это звоночек. Самые дорогие ошибки - это ошибки на этапе анализа.
SSukharev
13.01.2026 07:49В целом направление у вас правильное, странно видеть под такой статьёй столько комментариев. По всей видимости большинство выдерает куски из контекста, не понимая процесса разработки ПО, и придерается к мелочам. Или не способны связать в одно целое пару абзацев любой статьи. Это раз. Два - это то, что с аналитиком, способным написать для разработчика подробную и грамотную постановку, я встречаюсь все реже и реже, к сожалению.
alingrishko Автор
13.01.2026 07:49Спасибо за поддержку! Я тоже не ожидала такое количество комментариев, казалось бы такая стандартная тема)
apcs660
13.01.2026 07:49забавноe совпадение - прошлой осенью чуть чуть не попал в тимлиды в одно из подразделений Ланит. Возможно, общались бы сейчас.
как выше написали, станно что аналитик отдает "разжеванные" структуры данных разработчикам.
В прошлом часто обсуждал с архитекторами (обратная связь от разработчиков) решения - бывало что находились грубые ошибки когда исправления было поздно вносить (дизайн подписан) - обжегшись пару раз, архитекторы обсуждали дизайн с техническими экспертами в теме. Кто не врубался и лепил решение по принципу "а че таково, все просто" и приходил на консультацию когда что то не работало в UAT (в DEV обычно данных мало, проскакивало) - получал потом героические усилия и бессонные ночи перед сдачей проекта. Иногда приходилось лепить хитроумные костыли когда схему в том же индексе, к примеру, было не поменять для поиска.
Что обидно - когда все сделано по уму и без превозмоганий - премий не было, а вот героическое исправление косяка в дизайне "в горячем цеху" премировались, при этом на меня смотрели косо "а что ж ты не предупредил?". Во первых, я ни сном ни духом не знал об этом проекте и решении, а во вторых никто ничего не спрашивал. При этом мне премии не было.
Если работал с бизнес аналитиком который иногда назывался архитектором, то по сути, архитектуру скидывали нам, всю техническую часть - сверху могли отдать только самое общее приблизительное решение, не заморачиваясь техническими деталями. Обычно делали два-три варианта на рассмотрение, либо список рекомендаций.
alingrishko Автор
13.01.2026 07:49Бизнес-аналитик и архитектор приравненные - это что-то страшное) Сочувствую вашему опыту, я с таким не сталкивалась.
apcs660
13.01.2026 07:49в консалтинге все что угодно может быть.
На одном проекте под 50 человек, а на другом - 3. Днём ты бизнес аналитик а вечером архитектор.
Aldaris_73
13.01.2026 07:49Спасибо автору за в целом справедливое и правильное (имхо) описание смысла постановок.
Статистически всего того, что есть в статье для типового проекта и среднего сотрудника (сферического в вакууме) достаточно.
Но как вредный и душный человек по сути - не могу ни вставить свои пять копеек. Простите =).
Данная статья полезна тем, кто хочет сам написать постановку впервые и не знает с чего начать. Тогда берет это за основу и вперед погнали.
Я сам ПМ. И работал на разных проектах. Ниже накидаю то, что видел на практике.
На практике (в реальных кейсах и реальных командах) всплывают разные кейсы:
постановки по такой структуре оцениваются на весьма большое число часов. И чем выше число часов - тем скорее всего не попадание факта в план оценки.
-
скиллов разработчиков не хватает для чтения многобуков и им бы что-то конкретнее да попроще, да декомпозированнее. На одном из моих проектов, например, такие постановки читали только тимлид, QA, PM да PO. Обычные разрабы спотыкались на первых же абзацах (пропускали детали постановки). Поэтому согласовывали с PO да заказчиками мы такие вот постановки, но на ЧТЗ на команду это не работало. Так например бэку нужно было больше инфы для воспроизводимости: стенд с фикс настройкой, предзаданные данные, отметка по ролевой модели (под кем должна была отрабатывать серверная логика) + спецификация по отработке ошибок + алгоритм расписанный на "пальцах" (рисовали в Миро или Excel). Фронтам же и ещё часто требуются ссылки на Ui kit, требовались пометки какой именно UI компонент юзать и с какими его настройками.
крч, такие постановки сильно человекозависимы. Способен их человек читать или понимать. Как ПМ первое что мы сделали с командой - это сделали соглашение кому и что надо видеть в постановке и договорились кто и как делает постановки да ЧТЗ. Из моего опыта - такие постановки как у автора - это для тимлидов, техлидов и QA пишутся аналитиком. А вот реальные задачи для трекера с декомпозицией - это уже лиды пишут из постановки на конкретно технарском языке (компоненты + ручки + состояния) и последовательность/зависимости нарезанных задач. Тогда можно играться в скрам и на стендапах это все отслеживать, чтоб не облажаться на тестировании да приемке задачи.
-
по сути разработчикам нужно видеть в постановке то, что нужно именно им для разработки. Отдельные пункты ЧТЗ и постановок от аналитики могут быть избыточными, или наоборот неполными. Прежде чем писать постановку стоит показать структуру типовой постановки конкретной команде и спросить все ли им хватает или не хватает по данному проекту. Обычно есть уточнения и пожелания.
Сюда еще накину такой смысл: в идеале постановки должны соответствовать зрелости команды и процессам компании. Отдельным людям достаточно просто направление, цель и задачи фичи дать - и они сами по красоте развернут все, быстро покажут на демо и доработают под конкретного заказчика. Другим достаточно ЧБ схематичного прототипа с типовым golden case (дальше они сами задолбают вопросами). Третьим же нужна чуть ли не пошаговая инструкция по шагам что, где и как надо изменить/добавить. Четвертым же сразу нужные ещё и тест-кейсы по которым будут написаны авто-тесты и под которые будут подгоняться реальные задачи на разработку.
Зарезюмирую: для старта написания постановок (если не знаешь как вообще) - крутой материал. Для практики - стоит учитывать реальных разрабов, заказчиков и команды.
Автору - мне бы было более ценно от вас услышать экзотические изменения в постановках, что требовались заказчикам или командам и зачем именно. Это если вдруг вы решитесь на ещё одну статью.
tik4
13.01.2026 07:49Могу накинуть за/кроме автора :) Не экзотика, просто обыденность, но может будет интересно. Экспозиция - серверная разработка, спутниковое вещание, все довольно абстрактно и запутанно.
Заказчик однажды честно сказал, что не понимает ничего (в одной монструозной фиче один из самых погруженных в технику менеджеров заказчика так прямым текстом и написал :) Поэтому к докам стали прилагать короткое описание с самыми основными тезисами. Не истории/кейсы, а чтоб понятно.
Одно время была благородная попытка дизайнеров вести все макеты для всех UI серверных продуктов. И из постановок картинки экранов от аналитика типа убрать (везде ссылаться на id элементов в макетах). На очередной 1001 однообразной таблице умер очередной дизайнер и было принято волевое решение ограничиться UI kit и вернуть картинки экранов от аналитика
Тексты UI с переводами. Тоже боль, 100500 похожих текстов с переводами на 100500 похожих таблиц. В какой-то момент при переносе очередного текста из доки с требованиями в гит умер очередной фронт разработчик. В итоге теперь тексты UI аналитики льют в гит сами, переводы текстов из постановок убрали.
Вечная борьба текст-диаграмма. Одно время все алгоритмы дублировались диаграммы-текст. В какой-то момент умер очередной аналитик в попытке актуализировать 1001 диаграмму. В итоге количество диаграмм в постановках сильно сократилось, победила исчерпывающая полнота текста и таблиц. Но менее наглядно, да
alingrishko Автор
13.01.2026 07:49Благодарю за комментарий и за то, что поделились опытом.
Постановка на разработку - это все-таки как ни крути артефакт процесса на разработку, тут 100% нужно согласовывать шаблоны со всеми лидами (имею ввиду PM, лид разрабов и тд), что именно в таком формате нам всем будет ок. И точно все зависит от зрелости и компетенций самой команды, согласна с вами.
Насчет экзотических изменений подумаю, спасибо. Это видимо будет что-то из разряда самые дорогие факапы)
tas
Наверно речь о постановке на разработку именно UI?
Даже если так, не лучшее разделение. К тому же фронта может не быть. А если это процесс или алгоритм, то там не будет не только фронта, но и бэка.
Постановку лучше условно делить для разных читателей. Основные читатели постановки: Заказчик, архитектор, аналитик, разработчик и тестировщик. У всех у них разные требования к информации, которая должна быть в постановке. Так получается естественное деление на бизнес и системную части. В бизнес части вы описываете функцию, требования к ней и что вы делаете с привязкой к архитектуре (какие модули, очереди, методы, БД и т.д.). Варианты использования - тоже must have, особенно в формате, который требует Заказчик в ПМИ. В системной части, которая выносится на отдельные страницы - то, как делаете, детали с расписыванием форматов и мелких деталей.
Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д.
Такой подход позволит с одной стороны получать информацию Заказчику, архитектору и аналитику не опускаясь к системной части, которая может быть очень объемной. С другой стороны этот подход позволит разработчику и тестировщику получать всю необходимую информацию для разработки и тестирования.
alingrishko Автор
Да, вы верно подметили, если ui нет, то и не будет артефактов, связанных с ним. Классифицировать постановку для читателей тоже можно, однако в моей статье описан подход ведения постановок, используемых именно командой разработки (под командой разработкой я понимаю не только разработчиков, но и тестировщиков, других аналитиков и т.п.).
Согласна с вами на миллион процентов, что у разных читателей будут разные требования к информации. Если заказчик помимо какого-то официального документа, например ТЗ по ГОСТ, требует еще согласовывать с ним постановки, то там явно будут немного другие шаблоны.
Насчет вариантов использования - здорово, конечно, если их можно совместить с форматом ПМИ, но на практике так не всегда удается. Многие заказчики в ПМИ предпочитают видеть именно указание требование из ТЗ и то, как мы его закрываем конкретной функцией системы. Для разработки это может быть слишком большим use case. Но в целом, мы когда процессы на новых проектах выстраиваем, всегда стараемся сделать так, чтобы внутреннюю документацию для команды разработки можно было легко превратить в отчетную для заказчиков или других стейкхолдеров.
"Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д." - тут согласна с вашим комментом, если доступность элемента связана с бэком, то это должно быть ссылкой на алгоритм внутри постановки на экранную форму.
Благодарю за дополнения)