Вот пример из опыта о том, как обслуживать продуктовую практику, чтобы она приносила оценимую пользу. Это груминг по дизайн-макетам: команда смотрит на визуализацию фичи и вместе с разработкой прикидывает, насколько все реализуемо и трудоемко. Здесь удобнее всего поймать, что слишком дорого и что упростить, пока макеты не ушли в работу. Как раз тут обратиться можно и к FFF: резать надо, пока еще есть что резать, и такой груминг дает шанс не упустить момент.
Зачем вообще городить такой трудоёмкий процесс? Ну, вот допустим дизайнер не показал макеты разработке, а понес сразу клиенту, тому все понравилось, ушло в работу. А на макетах оказалось нарисовано то, что мы технически не закладывали и в разумные сроки не вытянем. Придется все переигрывать задним числом, когда объем уже утвержден, а время расписано. Груминг ровно для того и нужен, чтобы этот сценарий не случился.
Держится все на заранее понятном распределении ролей. Аналитик проверяет, что макет отвечает требованиям, защищает идею клиента. Дизайнер следит за пользовательским опытом и целостностью дизайн-системы, защищает пользователя. Разработка оценивает техническую сторону: можно ли заменить тяжелый компонент на простой, сколько времени все это займет.
Один красивый, но тяжелый элемент иногда стоит непропорционально дорого, и здесь решающий голос у разработки.
Высказаться про цвета и композицию может каждый, но чтобы не упороться в коллективное рисование дизайна всей командой, но по вопросам эстетики право вето все же за дизайнером. Это тоже важно помнить.
И еще правило: не подменять чужую роль. Каждый знает, где его голос решающий, а где совещательный, и поэтому встреча не превращается в срач. Это и есть обслуживание практики: задать понятные правила, по которым она работает каждый раз.