Комментарии 57
Постановку на разработку можно разделить на две части: постановка на frontend и постановка на backend.
Наверно речь о постановке на разработку именно UI?
Даже если так, не лучшее разделение. К тому же фронта может не быть. А если это процесс или алгоритм, то там не будет не только фронта, но и бэка.
Постановку лучше условно делить для разных читателей. Основные читатели постановки: Заказчик, архитектор, аналитик, разработчик и тестировщик. У всех у них разные требования к информации, которая должна быть в постановке. Так получается естественное деление на бизнес и системную части. В бизнес части вы описываете функцию, требования к ней и что вы делаете с привязкой к архитектуре (какие модули, очереди, методы, БД и т.д.). Варианты использования - тоже must have, особенно в формате, который требует Заказчик в ПМИ. В системной части, которая выносится на отдельные страницы - то, как делаете, детали с расписыванием форматов и мелких деталей.
Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д.
Такой подход позволит с одной стороны получать информацию Заказчику, архитектору и аналитику не опускаясь к системной части, которая может быть очень объемной. С другой стороны этот подход позволит разработчику и тестировщику получать всю необходимую информацию для разработки и тестирования.
Да, вы верно подметили, если ui нет, то и не будет артефактов, связанных с ним. Классифицировать постановку для читателей тоже можно, однако в моей статье описан подход ведения постановок, используемых именно командой разработки (под командой разработкой я понимаю не только разработчиков, но и тестировщиков, других аналитиков и т.п.).
Согласна с вами на миллион процентов, что у разных читателей будут разные требования к информации. Если заказчик помимо какого-то официального документа, например ТЗ по ГОСТ, требует еще согласовывать с ним постановки, то там явно будут немного другие шаблоны.
Насчет вариантов использования - здорово, конечно, если их можно совместить с форматом ПМИ, но на практике так не всегда удается. Многие заказчики в ПМИ предпочитают видеть именно указание требование из ТЗ и то, как мы его закрываем конкретной функцией системы. Для разработки это может быть слишком большим use case. Но в целом, мы когда процессы на новых проектах выстраиваем, всегда стараемся сделать так, чтобы внутреннюю документацию для команды разработки можно было легко превратить в отчетную для заказчиков или других стейкхолдеров.
"Применимо к вашему кейсу при описании кнопки UI вы пишете условия доступности, что она делает, какой метод вызывается, ссылаетесь на вариант использования и добавляете ссылку на системную часть, где указано формирование атрибутов метода, изменяемые сущности, изменения в БД и т.д." - тут согласна с вашим комментом, если доступность элемента связана с бэком, то это должно быть ссылкой на алгоритм внутри постановки на экранную форму.
Благодарю за дополнения)
Что-то какая-то непонятность в части описания модели. Даже если брать чисто физическую. Вы вместо стандартных для хранилища данных терминов используете абстрактное "атрибут"... но далее по тексту сперва выясняется, что у этого атрибута имеется тип данных, то есть имеется в виду конкретное поле, но затем к атрибутам относите и первичный ключ, который вполне может быть функциональным или композитным. То есть вы используете один термин, но в нём валите в кучу несколько совершенно различных сущностей. Что, кстати, чревато и непониманием - скажем, вторичный ключ имеет самостоятельное имя, которое может интерферировать с именем поля.
Опять же странно вы трактуете обязательность. Со стороны хранилища данных она может быть двоякой - во-первых, это может быть NULLability (поле не может быть NULL, обязано содержать хоть какое-то значение), во-вторых, это может быть и требование наличия непустого или подпадающего под некий шаблон значения (скажем, текстовое поле не может содержать пустую строку или строку из только пробельных символов). Тут вы скорее должны описывать ограничения на поле, которые могут быть как простыми (NOT NULL), так и достаточно комплексными (которые в структуре хранения преобразуются в соответствующий CHECK). Более того, ограничения могут быть и не привязаны к конкретному полю (table-level CHECK и даже триггерная логика - при необходимости в ходе контроля обращаться к другим записям и/или таблицам).
А ведь у вас постановка. И если всё вышеуказанное не будет в ней однозначно и полно определено, вас ждёт продолжительный и очень увлекательный процесс итеративного согласования. И вам сильно повезёт, если он завершится до стадии практической реализации. Ну и толку тогда от этой постановки?
Пыталась сразу описать и для логической и для физической шаблон постановки, поэтому, скорее всего, и возникли такие непонятности.
Верно, если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице". Если первичный ключ композитный, то это два и более поля.
Вопрос обязательности для логической и физической модели данных различается, согласна. Но чаще всего, что было по логической обязательно, становится в конечном итоге и для физической модели обязательно. Постараюсь раскрыть эту тему уже здесь в комментарии.
Для физической модели данных обязательность должна указываться с точки зрения БД - "можно ли вставить строку, не заполнив поле." Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм". При этом, если обязательность какая-то сложная, то стоит добавлять отдельный алгоритм проверки этой обязательности и ссылаться на него.
Для логической модели данных обязательность должна описывать то, без чего сущность не может существовать - т.е. без этого атрибута сущность будет не валидна с точки зрения бизнес-логики. Однако тут явно нужно будет уже с разработкой обсуждать, какие из этих атрибутов логмодели будут в БД обязательными или нет. Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
В любом случае перед тем, как разработчик начнет создавать таблицу по постановке, он должен сказать свое "фи"). Нам, как аналитикам, главное понимать, что эту обязательность нужно не забыть указать в принципе.
Надеюсь, будущим читателям я немного прояснила ситуацию с обязательностью. В целом я за то, что постановки не являются истиной в последней инстанции, и всеми членами команды должны восприниматься всегда критически. У нас, например, даже тестировщик может сказать свое "фи", если разработчик об этом не задумался) Все-таки результат разработки - общая ответственность всей команды, все всегда обсуждаем в процессе.
А если нужно согласовать с заказчиком постановки, то, конечно, стоит сначала обсудить с разработкой, а потом уже бежать согласовывать с заказчиком, чтобы не уйти на миллион итераций согласований.
если говорить про физическую (и принято на проекте, что аналитик описывает физическую), то в шаблоне постановки будет корректнее назвать столбец "Наименование поля в таблице".
Наверное, всё же "объект в таблице". Представьте, что вам нужно, чтобы комбинация из года и порядкового номера была уникальна. Вам придётся создать: поле года, поле номера, уникальный индекс по комбинации этих полей. Или, если год берётся из, скажем, даты создания, то уникальный индекс будет функциональным. То есть это должны быть три строки в вашей таблице. А полей-то всего два... то есть от третьей строки, описывающей ограничение, вам никуда не деться, а уж будет финально это ограничение реализовано как индекс или иным способом - это вопрос, решаемый скорее на стадии реализации.
Вся остальная обязательность должна быть описана в артефакте "Описание экранных форм".
Уж не предлагаете ли вы весь контроль целостности данных вынести на уровень клиента (код бэка, а то ещё и, не приведи господи, фронта)? Если да - то это ну очень нехорошее решение. Сами знаете - если неприятность может случиться, она случается. Или, в данном случае, появление в базе невалидных и/или несогласованных данных - это всего лишь вопрос времени. Как - в результате программной ошибки, сбоя, необдуманных или злонамеренных действий, дело десятое, но оно точно будет. Не должны формы заниматься таким контролем, они должны выполнять только первичную валидацию данных, то есть их слово "сойдёт" далеко не окончательное.
Например, фамилия часто обязательна с точки зрения сущности, но в БД может быть не обязательной, если, например, сначала из одной системы мы получаем идентификаторы физических лиц, а из другой уже информацию об их персональных данных. Т.е. мы физически никак в таком кейсе не можем объявить фамилию сразу обязательной с точки зрения БД.
А это как раз пример сложного ограничения. Но тем не менее вполне реализуемый на уровне подсистемы контроля целостности СУБД. В вашей схеме - для такой сущности требуются признаки "необходимо получить идентификатор" и "необходимо получить персональную информацию", по которым будут работать демоны, обращающиеся во внешние сервисы с соответствующими запросами. И если первый признак получил значение "выполнено", то поле идентификатора становится обязательным, а если и второй признак, то и поле фамилии. Да, получится немного обратная ситуация - БД не даст изменить значение признака без заполнения значения логически связанного поля. Но главное, что это приведёт к ошибке, детектирующей нештатную ситуацию, требующую внимания и обработки, и заблокирует появление в таблице невалидной записи.
Даже если всё это забота внешнего для СУБД программного кода, отказ от валидации на уровне хранения данных - неразумно. Тем более что проверка выполняется только в момент изменения записи, то есть способна создать ощутимую дополнительную нагрузку в СУБД лишь в случае массированных пакетных операций.
Нет, я не предлагаю контроль целостности данных выносить на уровень клиента. Как раз мое предложение в том, что часть проверок будет на бэке и для этого нужно в артефакте "Описание экранных форм" сослаться на алгоритм бэка, где эта логика обязательности поля будет расписана.
За все остальные комментарии благодарю, думаю, будет полезно читателям-аналитикам понимать возможные "подводные камни" в случае описания именно физ. модели и почаще обращаться к разработчикам/архитекторам за консультацией)
А как такую постановку согласовать с заказчиком?
Обычно делю постановку на 2 блока:
1 блок - последовательность действий пользователя, с макетами форм и ожидаемыми реакциями системы. На языке, понятном заказчику.
Этот же блок используется для тестирования и для подготовки пользовательской инструкции.
2 блок - это техническая часть: архитектура, объекты, алгоритмы и т.д. По ходу текста ссылки на разделы 1го блока.
Тут смотря, какие у заказчика требования. Бывают заказчики, которые с удовольствием хотят посмотреть и техническую часть. Но если заказчик больше про "бизнес", то я бы предложила с ним согласовывать артефакты "Варианты использования" и "Описание экранных форм" (в целом, как вы и делите). Но при этом внутри них, на мой взгляд, уже не желательно размещать какую-то техническую информацию, чтобы не вводить в заблуждение. И, скорее всего, этих артефактов будет недостаточно. Заказчик захочет какой-нибудь очевидной трассируемости - как из конкретного пункта его ТЗ появляется какой-то вариант использования, может быть карту пользовательского пути, схему экранных форм. Тут нужно точно обговаривать ожидания от состава и шаблоны постановок с обеих сторон.
Постановка на разработку с заказчиком не согласуется, с заказчиком согласуется ТЗ.
Не увидел в перечне артефактов "требований". Получается, что вы их "перемалываете" в готовые схемы данных? Или, например, у вас отдельный шаг согласования требований перед этапом разработки ЧТЗ? Или требования указаны наряду с другими UC (например, в формате user story)?
Какой подход к внешней документации (описания протоколов интеграции разрабатываемой системы и т.п.)?
Ну и плюс непонятно, как производится разработка алгоритмов и баз данных (физической модели) - у вас аналитиков есть эксперты по используемым системам/технологиям (что бы понимать их ограничения). Или тут речь о том, что бы избавить исполнителей разработчиков от именования сущностей и т.п. ?
У нас отдельный шаг согласования требований. Т.е. шаблоны, которые у меня выше, подразумевают, что требования уже согласованы, все всем понятно, нам нужно просто передать все в работу команде.
Внешнюю документацию мы условно делим на входящую и отчетную. Входящая - грубо говоря то, что мы обязаны согласовывать перед тем, как приступить к разработке - ТЗ, форматы обмена данных с какими-то другими системами (если там исполнители другие) и т.д. Отчетная - это ПМИ, пользовательские инструкции и другие документы. Согласуем их с заказчиком уже при приемке работ.
При написании алгоритмов, физической модели аналитики могут проконсультироваться с разработкой, либо потом разработка на этапе получения постановки может указать - "так не можем, потому что есть такие ограничения".
А почему в ТЗ смешиваются "что" и "как" ? То есть почему названия сущностей, схему данных и т.п. придумывает аналитик, а не разработчик?
Согласен, физическую схему (типы полей, индексы) должен тюнить разработчик, но логическую (какие сущности и как связаны) обязан дать аналитик, иначе это не аналитика, а просто хотелки
Схему данных разработчику доверять делать нельзя. Ибо она должна быть конситентной для всего предприятия, а это часто сотни разработчиков из десятков команд. То же самое с нейминг конвециями. И даже с типами данных. Это уровень архитектуры
Все зависит от конкретной команды и проекта. Например, если в целом проект какой-то небольшой был и мы дорабатывали что-то существующие, то описывали физические модели. Потому что там вся разработка сводилась к тому, что с "нуля" ничего не делаем, просто обогащаем, что есть (добавить поле "комментарий" в таблицу такую-то). Если же очень много новых сущностей, то лично я за то, что отдавать логические модели (на большинстве проектах у нас было именно так).
Взгляд backend разработчика. Постановки такого уровня детализации, с физической моделью данных и описанием алгоритмов ожидаешь скорее от архитекторов. То есть специалистов с высокой технической экспертизой и знанием задействованного стека технологий. От аналитика скорее ждешь абстракций выше, что нибудь вроде диздок... Вы не слишком тянете одеяло на себя? Может ведь не хватить компетенций...
это видимо потому что нету у них архитекторов. А так да, я в роли архитектора всегда модель данных делаю сам и никому не доверяю
Насчет физической модели написала свое мнение выше. Насчет алгоритмов - мы не описываем алгоритмы уровня взаимодействия сервисов между собой. Не нужно понимание стека технологий, чтобы, например, описать алгоритм проверки. Это в большей степени бизнесовая последовательность шагов, которая выполнятся системой. Пример на каждый шаблон постараюсь описать в следующей статье, чтобы не возникало лишних вопросов.
Насчет "не хватить компетенций" - аналитики в любом случае не работают в вакууме от другой команды, если команда аналитики слабая и все по итогу переделывается архитекторами/разработчиками, то меняются процессы и шаблоны постановок. В статье поделилась тем, как работает у нас, причем на нескольких проектах.
Хороший шаблон, но есть нюанс: если аналитик рисует физическую модель данных до согласования с бэкендером, в 90% случаев ее приходится переделывать. Разработчик знает нюансы нормализации, индексов и производительности конкретной СУБД лучше. Я бы оставил аналитику логическую модель, а физику отдал бы техлиду или сеньору, чтобы не делать двойную работу
Я тоже за логическую, но на практике встречалась и с тем, что описывали физическую (как раз выше отвечала на подобный комментарий, это в основном проекты, где мало разработки с "нуля", много доработок уже существующего), поэтому указала обе модели в статье.
Насчет 90% не согласна) Но тут все зависит от компетенций команды аналитики.
Удваиваю. Кстати, ровно то же самое происходит, когда аналитик пытается проектировать UI
Для UI лучшей постановкой будет ссылка на хороший и качественный макет в figma с отрисовкой логики работы. Для backend, имхо, лучше всего подходит принцип черной коробки - нюансы реализации аналитик все равно не знает, поэтому вход такой, эффект такой, выход такой. Самое сложное возникает в задачах клиент-серверного взаимодействия - там и контракты согласовывать надо, и для фронта описывать API, для бекенда входные параметры.
В идеальной жизни вообще бы такой макет figma, который сразу можно экспортировать в верстку) Но практика показывает, что такое возможно только для зрелых систем, где происходит не очень много изменений от общего процента функций системы, и на все есть актуальные (соответствующие реализации) макеты. Иначе становится очень дорого идеальные макеты поддерживать. Чаще всего используются прототипы средней точности.
Принцип черной коробки по мне имеет смысл в командах, где не предполагается системного аналитика. Тогда вполне может быть такой расклад: стейкхолдер отдал требования, продакт/бизнес-аналитик дополнительно проработал и отдал сразу в разработку.
Все зависит от состава команды.
Успех задач клиент-серверного взаимодействия - либо fullstack-разработчик либо здоровые коммуникации между frontend и backend-разработчиком и аналитиком. В целом без общения внутри команды никуда, какие бы идеальные постановки не были.
Разве разработать макет не проще чем разрабатывать прототип? И что такое прототип средней точности? Используя прототипы “средней точности", как вы следите за качеством поставляемого UI? И в конце концов, почему системный аналитик занимается макетами и прототипами?!
P.S. У вас имеется ~50 уникальных экранных форм в вашей системе, с множеством логики на данных экранах. Не справедливо ли будет утверждение о дороговизне поддержки с множеством изменений и к вашему же описанному в статье подходе?
Для меня прототип "средней точности" - схематичный макет, где показываем какие атрибуты/кнопки мне нужны, где примерно, и что хочу видеть. Но разработчик в любом случае делает по дизайн-системе и из тех фронтовых компонентов, что под нее были разработаны. Как раз за счет этого и обеспечивается качество поставляемого UI.
Системный аналитик может сам разработать прототипы "средней точности" в случае, если экраны типовые.
Насчет утверждения о дороговизне - не справедливо. Привлечение дизайнера - это плюс чч на разработку сразу же. При этом без аналитики уточняющей макет это все равно в разработку не отдать. Да, уточнять нужно будет меньше, но все равно нужно. К тому возникают сложности сразу с внесением небольших изменений - поменять нейминг, столбцы местами - вечно "дергать" дизайнера и удлинять процесс разработки.
Тут у меня сразу вопрос: а надо ли писать, так, чтобы не было вопросов со стороны разработки?
Я как раз набросывал статью по этому поводу, но она пока крайне сырая, поэтому пока не публикую. Но первая идея, что задачи всё равно надо обсуждать, поэтому при постановке задачи, вопросы должны быть.
Однозначно должны быть, только через вопросы и общение можно прийти к единому пониманию, плюс, разработчик со своей стороны всегда может задать вопрос, который возникнет только у него, т.к. он больше всех погружен в техническую реализацию, а специфика технической реализации порой может заставить переработать и даже весь UI и даже какие-то архитектурные основы проекта.
На мой взгляд, однозначно нужно к этому стремиться. Но могу сказать, что полное отсутствие вопросов всегда пугает нас) Тут нужна золотая середина - и постановки сразу максимально адекватные со стороны аналитика и критическое мышление тех, кто это в работу принимает.
Со временем, когда получаешь одни и те же вопросы, можно дорабатывать шаблоны постановок, писать чек-листы для самопроверки себя, как аналитика и т.д. Таким образом приходя к хорошему взаимопониманию внутри команды.
Постановка на разработку — это описание, которое прикладывается к задаче на разработку. Ее еще называют описанием постановки задачи (ОПЗ), частным техническим заданием (ЧТЗ), спецификацией на разработку.
Это именно начальная спецификация?
В качественную постановку на разработку должны входить следующие артефакты.
Описание экранных форм — определяет правила работы каждого элемента интерфейса, документирует состояния и переходы.
Модель данных — определяет схему сущностей, связи, а также атрибутивный состав сущностей.
Варианты использования — пользовательские сценарии использования (use case).
Алгоритмы — пошаговая логика, определяющая поведение системы при взаимодействии с ней.
Это всё — довольно конкретные вещи. Если же думать только про постановку на разработку, то следует ожидать систематического описания (анализа) предметной области. Начинать следует, скорее, с алгоритмов, то есть — снизу вверх. Остальное допускает довольно широкий выбор. Мы можем использовать различные таблицы для различных сущностей, а можем загрузить различные сущности в одну таблицу, но иметь иерархию сущностей. А уж каково разнообразие экранных форм! Любую форму можно представить одним длинным листом, а можно и мастером с возможностью возврата на предыдущие шаги. Какой смысл что-то фиксировать? Иногда забавно наблюдать какой-нибудь выпадающий список, который, на самом деле, можно заменить набором элементов, явным образом присутствующих на странице. И много чего похожего.
Помню в универе изучали rational rose который, в теории, должен был по сабжу закрывать все вопросы =D Отношения к разработке не имею, но всё равно это воспоминание позабавило.
Статья хорошая, а вот заголовок плохой :) Как показывает жизнь - если ни у кого нет вопросов, то это дурной знак, т.к. никто толком ничего не читал и не осмысливал. Значит все пойдёт "по бороде" при разработке (в лучшем случае), тестировании (уже хуже) или эксплуатации (ваще караул)
В целом направление у вас правильное, странно видеть под такой статьёй столько комментариев. По всей видимости большинство выдерает куски из контекста, не понимая процесса разработки ПО, и придерается к мелочам. Или не способны связать в одно целое пару абзацев любой статьи. Это раз. Два - это то, что с аналитиком, способным написать для разработчика подробную и грамотную постановку, я встречаюсь все реже и реже, к сожалению.
забавноe совпадение - прошлой осенью чуть чуть не попал в тимлиды в одно из подразделений Ланит. Возможно, общались бы сейчас.
как выше написали, станно что аналитик отдает "разжеванные" структуры данных разработчикам.
В прошлом часто обсуждал с архитекторами (обратная связь от разработчиков) решения - бывало что находились грубые ошибки когда исправления было поздно вносить (дизайн подписан) - обжегшись пару раз, архитекторы обсуждали дизайн с техническими экспертами в теме. Кто не врубался и лепил решение по принципу "а че таково, все просто" и приходил на консультацию когда что то не работало в UAT (в DEV обычно данных мало, проскакивало) - получал потом героические усилия и бессонные ночи перед сдачей проекта. Иногда приходилось лепить хитроумные костыли когда схему в том же индексе, к примеру, было не поменять для поиска.
Что обидно - когда все сделано по уму и без превозмоганий - премий не было, а вот героическое исправление косяка в дизайне "в горячем цеху" премировались, при этом на меня смотрели косо "а что ж ты не предупредил?". Во первых, я ни сном ни духом не знал об этом проекте и решении, а во вторых никто ничего не спрашивал. При этом мне премии не было.
Если работал с бизнес аналитиком который иногда назывался архитектором, то по сути, архитектуру скидывали нам, всю техническую часть - сверху могли отдать только самое общее приблизительное решение, не заморачиваясь техническими деталями. Обычно делали два-три варианта на рассмотрение, либо список рекомендаций.
Спасибо автору за в целом справедливое и правильное (имхо) описание смысла постановок.
Статистически всего того, что есть в статье для типового проекта и среднего сотрудника (сферического в вакууме) достаточно.
Но как вредный и душный человек по сути - не могу ни вставить свои пять копеек. Простите =).
Данная статья полезна тем, кто хочет сам написать постановку впервые и не знает с чего начать. Тогда берет это за основу и вперед погнали.
Я сам ПМ. И работал на разных проектах. Ниже накидаю то, что видел на практике.
На практике (в реальных кейсах и реальных командах) всплывают разные кейсы:
постановки по такой структуре оцениваются на весьма большое число часов. И чем выше число часов - тем скорее всего не попадание факта в план оценки.
скиллов разработчиков не хватает для чтения многобуков и им бы что-то конкретнее да попроще, да декомпозированнее. На одном из моих проектов, например, такие постановки читали только тимлид, QA, PM да PO. Обычные разрабы спотыкались на первых же абзацах (пропускали детали постановки). Поэтому согласовывали с PO да заказчиками мы такие вот постановки, но на ЧТЗ на команду это не работало. Так например бэку нужно было больше инфы для воспроизводимости: стенд с фикс настройкой, предзаданные данные, отметка по ролевой модели (под кем должна была отрабатывать серверная логика) + спецификация по отработке ошибок + алгоритм расписанный на "пальцах" (рисовали в Миро или Excel). Фронтам же и ещё часто требуются ссылки на Ui kit, требовались пометки какой именно UI компонент юзать и с какими его настройками.
крч, такие постановки сильно человекозависимы. Способен их человек читать или понимать. Как ПМ первое что мы сделали с командой - это сделали соглашение кому и что надо видеть в постановке и договорились кто и как делает постановки да ЧТЗ. Из моего опыта - такие постановки как у автора - это для тимлидов, техлидов и QA пишутся аналитиком. А вот реальные задачи для трекера с декомпозицией - это уже лиды пишут из постановки на конкретно технарском языке (компоненты + ручки + состояния) и последовательность/зависимости нарезанных задач. Тогда можно играться в скрам и на стендапах это все отслеживать, чтоб не облажаться на тестировании да приемке задачи.
по сути разработчикам нужно видеть в постановке то, что нужно именно им для разработки. Отдельные пункты ЧТЗ и постановок от аналитики могут быть избыточными, или наоборот неполными. Прежде чем писать постановку стоит показать структуру типовой постановки конкретной команде и спросить все ли им хватает или не хватает по данному проекту. Обычно есть уточнения и пожелания.
Сюда еще накину такой смысл: в идеале постановки должны соответствовать зрелости команды и процессам компании. Отдельным людям достаточно просто направление, цель и задачи фичи дать - и они сами по красоте развернут все, быстро покажут на демо и доработают под конкретного заказчика. Другим достаточно ЧБ схематичного прототипа с типовым golden case (дальше они сами задолбают вопросами). Третьим же нужна чуть ли не пошаговая инструкция по шагам что, где и как надо изменить/добавить. Четвертым же сразу нужные ещё и тест-кейсы по которым будут написаны авто-тесты и под которые будут подгоняться реальные задачи на разработку.
Зарезюмирую: для старта написания постановок (если не знаешь как вообще) - крутой материал. Для практики - стоит учитывать реальных разрабов, заказчиков и команды.
Автору - мне бы было более ценно от вас услышать экзотические изменения в постановках, что требовались заказчикам или командам и зачем именно. Это если вдруг вы решитесь на ещё одну статью.
Могу накинуть за/кроме автора :) Не экзотика, просто обыденность, но может будет интересно. Экспозиция - серверная разработка, спутниковое вещание, все довольно абстрактно и запутанно.
Заказчик однажды честно сказал, что не понимает ничего (в одной монструозной фиче один из самых погруженных в технику менеджеров заказчика так прямым текстом и написал :) Поэтому к докам стали прилагать короткое описание с самыми основными тезисами. Не истории/кейсы, а чтоб понятно.
Одно время была благородная попытка дизайнеров вести все макеты для всех UI серверных продуктов. И из постановок картинки экранов от аналитика типа убрать (везде ссылаться на id элементов в макетах). На очередной 1001 однообразной таблице умер очередной дизайнер и было принято волевое решение ограничиться UI kit и вернуть картинки экранов от аналитика
Тексты UI с переводами. Тоже боль, 100500 похожих текстов с переводами на 100500 похожих таблиц. В какой-то момент при переносе очередного текста из доки с требованиями в гит умер очередной фронт разработчик. В итоге теперь тексты UI аналитики льют в гит сами, переводы текстов из постановок убрали.
Вечная борьба текст-диаграмма. Одно время все алгоритмы дублировались диаграммы-текст. В какой-то момент умер очередной аналитик в попытке актуализировать 1001 диаграмму. В итоге количество диаграмм в постановках сильно сократилось, победила исчерпывающая полнота текста и таблиц. Но менее наглядно, да
Благодарю за комментарий и за то, что поделились опытом.
Постановка на разработку - это все-таки как ни крути артефакт процесса на разработку, тут 100% нужно согласовывать шаблоны со всеми лидами (имею ввиду PM, лид разрабов и тд), что именно в таком формате нам всем будет ок. И точно все зависит от зрелости и компетенций самой команды, согласна с вами.
Насчет экзотических изменений подумаю, спасибо. Это видимо будет что-то из разряда самые дорогие факапы)
Нет единого "правильного" набора артефактов и тем более наполнения шаблонов для постановок. Потому что это всё слишком зависит от контекста, в котором эти артефакты планируется применять: состава и компетенций команды, особенностей рабочих процессов, используемых технологий и пр. Поэтому когда в начале статьи вы пишете, что хотите поделиться своим видением, там же где-то надо было обозначить специфику организации работы на вашем проекте.
Лучше один раз увидеть, чем сто раз услышать. У меня такие вопросы:
Можете показать пример полноценной постановки по вашей методике для конкретной реально существовавшей и выполненной задачи?
В каком проценте постановок вы следуете всем собственным рекомендациям? В каком — лишь их части? В каком вообще забиваете на правила?
О каком размере команды идёт речь в вашем случае? Замечали ли какую-нибудь разницу в подходах в зависимости от сложности задач и количества участников?
Замечали ли разницу в подходах при работе с хорошо задокументированными системами (если вообще сталкивались с такими) и с системами без проектной документации?
Документация должна облегчать общение, а не быть самоцелью.
Не проще для постановки на ui сделать нормальные макеты для разработчиков и отдавать уже их? Будто бы на описание каждого элемента в таблице уйдет больше времени, чем на нормальную верстку, а понимать это и в случае чего вносить изменения гораздо сложнее. Часто бывает так, что дизайнер не предусмотрел какие-то вещи и требуются корректировки, как вы это на уровне таблиц сделаете нормально. Или у вас дизайном занимается аналитик?
Для себя отметил, что лучшей формой постановки тз на ui является макет с основными элементами интерфейса + описание работы этого интерфейса, содержащее основную информацию для его реализации: подсказки при наведении, текст, описание действий при нажатии на кнопки и т.п.
>все зависит от компетенций команды
количество букв в заметке можно было сократить до одной фразы из коммента :D
чтобы ни у кого не было вопросов
А зачем такая цель вообще? Во-первых, она идеалистична и почти недостижима. Чтобы даже приблизиться к желаемому, временные затраты превысят выгоды. Во-вторых, вопросы — это не плохо. Вопросы позволяют узреть противоречия в постановке и переосмыслить требования. Часто нужен именно баланс качественной предварительной аналитики и командной работы, когда результат будет доведён до желаемого качества.
Как написать постановку на разработку, чтобы ни у кого не было вопросов