Что за токсичная обстановка в конце статьи? Почему-то удары CI мужчины это весело.. давайте нарисуем как CI бьют по голове разработчика Машу, и посмотрим на комментарии. Пусть лучше никто никого не будет бить, ни мужчин ни девушек.
Если рассматривать, например, "Карту" как целый сервис, то его также, как и указано в статье, можно разбить на отдельные графические элементы и описывать логику уже каждого из них. И в этой статье рассмотрены требования, которые будут в большей степени реализованы frontend-разработчиком: охватить всю логику, в том числе back, которая как "бóльшая часть айсберга" скрыта от пользователей, не было целью статьи.
В будущем я хочу составить описание для целых типовых сервисов, с которыми сам сталкивался в работе аналитиком, например, формы регистрации и авторизации, формы обратной связи, в том числе и упоминаемого тобой раздела уведомлений – логики в них и подобных сервисах будет много. И тогда это смогло бы стать также подспорьем для аналитика в том, чтобы при проектировании этих сервисов ничего не забыть.
Как понимаю для таких сервисов уже существуют целые модули, которые разработчик может настроить под нужды своего IT-продукта и использовать. Проверка аналитиком того, все ли возможные вариации в логике таких модулей учтены как раз и может помочь в составлении таких статей в помощь аналитикам.
Не совсем понятно, какую задачу позволяет решать предложенный чеклист для проработки требований к UI. Если речь про то, чтобы не забыть указать такие детали, как формат отображения значения, валидации введённого значения, состояние элемента в зависимости от условий и т. п. — то это применимо скорее для относительно простых элементов вроде поля ввода, выпадающего списка, чекбоксов
Именно эту задачу и решает: описание логики отдельных графических элементов.
Но этого разве мало? Разве это не первый шаг, с которого должна начинаться работа по описанию логики работы элемента? Такого описания для графических элементов я нигде не нашёл (хотя и встречал в открытом доступе дизайн-системы компаний, но в них было описание элементов для UX-дизайнеров) и составил такой чек-лист сначала для себя, а теперь делюсь со всеми аналитиками. Думаю, лучше иметь такой чек-лист под рукой, чем всегда надеяться на память, упуская какие-то вопросы и тратить время на то, чтобы их вспоминать. Памятка получилась большой, и будет ещё больше, пополняясь новыми элементами и вопросами – для первой итерации должно быть достаточно )
Мы имеем и кнопку "Назад", и кнопку "Продолжить", что уже само по себе вносит некоторое недоумение.
А в чём заключается противоречение, когда на одной и той же странице находится обе эти кнопки?
Ожидается, что кнопка "Назад" — это отмена произведённых изменений и возврат к предыдущему режиму/состоянию, а кнопка "Продолжить" — это часть многошаговой процедуры
Кем ожидается? Реализация страницы происходит исходя из потребностей. Вы можете сами проверить, что в Госуслугах при прохождении услуги логика кнопки "Назад" и "Продолжить" как раз сохраняет все введённые значения и загруженные документы как на предыдущих шагах при возвращении "Назад", так и при возврате обратно вперёд по кнопке "Продолжить". Наши аналитики видели в этом потребность и именно так проектируют услуги. И именно такой вариант я указал на скриншоте в качестве примера.
В других случаях, например, в режиме мастера, вы правы, может быть актуальным при возвращении назад сброс всех введенных значений на последующих окнах. Я лишь привёл пример, и в контексте Госуслуг пример корректный.
Во-вторых, подсказки нужны всегда.
Значит я как минимум правильно сделал, что указали вопрос про подсказки в полях в памятке, чтобы аналитик мог его себе задать и принять осознанное решение об их указании.
В целом, многое из того что было указана в памятке является не то чтобы обязательным, а тем, что сделает работу с информацией удобнее. Например, в таблицах хорошим тоном является закреплять верхнюю строку, делать фильтрацию и позволять сортировать данные, но может быть так, что в каком-либо конкретном спринте на реализацию всего и сразу не хватает ресурсов, поэтому аналитику необходимо по крайней мере распределять что и когда нужно будет из этого всего "обязательного для дружелюбного интерфейса" реализовывать.
В-третьих, наиболее странным в документации оказывается описание поля "Кем выдан". Мало того. что все заранее заданные ограничения должны в явном виде присутствовать на форме, и пользователь должен иметь возможность контролировать свой ввод, так он ещё должен знать, что ему делать, если у него больше 256 символов (про это не слова, хотя это — явный дефект архитектуры).
255 символом – это много. Нет в реальности такого названия органа, выдающего паспорт, которое бы превысили это количество. Поэтому в большинстве случаев (если пользователь вносит реальные данные из своего паспорта) пользователь никогда не дойдёт до этого ограничения. И именно поэтому я и не стал заранее загружать пользователя информацией об этом ограничении. Вот если пользователь введёт туда данные какие-то иные – вот тогда ограничение сообщит ему о том превышено допустимое количество символов.
Это моё решение так спроектировать систему с учётом контекста, который я указал выше. В статье указан пример, а Вы можете закладывать ту логику в таких случаях, которую считаете нужной.
На самом деле, здесь крайне полезным был бы радикальный способ отображения информации, иногда используемый в бумажных документах, вынуждающий людей иногда писать печатными буквами, когда для каждой отдельной буквы имеется свой элемент ввода (как при вводе чисел из сообщения при авторизации)
Подскажите, а есть ли у Вас примеры используемых на сайтах или приложениях ввод символов в таких вот квадратиках, как это обычно бывает в бумажных документах? Как раз в бумажных документах это используется, чтобы человек делал запись не прописными, а печатными буквами, чтобы потом было легче эти символы распознать, но при вводе с клавиатуры такая потребность уже отпадает
Сразу видно, сколько позиций в запасе. Это же касается и других полей.
Сколько Вы, например, заложили бы таких квадратиков для ввода символов в таком поле "Кем выдан"? Чтобы это определить необходимо узнать все названия органов, выдающих паспорт, и далее найти самое длинное и указать такое количество квадратиков, чтобы это самое длинное название смогло поместиться. Скорее всего такое исследование станет избыточным, и ресурсы лучше направить на другие задачи.
Я, конечно, не говорю о такой простой возможности отрисовывать макет реального паспорта (справа от формы) для само контроля пользователя. Было бы очень информативно.
Согласен, что хорошая практика сообщать пользователям о том, где в бумажном документе находится то поле, данные с которого необходимо записать в поле в виде скриншота. Видимо, паспорт РФ используется часто, поэтому здесь в этом скриншоте потребности не увидели, но для других документов такие подсказки могут быть полезными.
Хороший продукт не требует документации для пользователей, и он должен в себе содержать интуитивно понятный интерфейс, подсказки.
Но хороший продукт требует в каком-либо виде документацию о логике его работы для команды разработки, иначе не видя всю логику работы продукта легко сделать требования противоречивыми или даже второй раз случайно реализовывать подобное, что уже есть реализовано. Для команды разработки всё время проверять логику работы продукта смотря на то как он работает неудобно, а вот работать с логикой продукта в его графическом проекте и спецификациях, где все требования упорядочены – удобно, а значит качество разработки будет выше и будет экономия времени в работе.
Вы, конечно, говорите о внутреннем документировании, но оно же, если оно хорошо организовано, то оказывается основной для конечного продукта и документации к нему.
Да, в предложении "И чаще всего жертвуют именно документированием — отдают разработчикам тезисно записанные в таск-трекере требования, подкреплённые устным объяснением" я говорю именно о внутреннем документировании, спецификации, SRS.
Если продукт разрабатывается сверху-вниз, то разве не должно быть так, что типы и логика элементов жёстким образом определяются в ходе разработки. Ведь, когда мы разлагаем задачи более высокого уровня абстракции в композиции задач более низкого, то мы именно способом построения композиции предписывает выбор и настройку вполне конкретных элементов управления?
Графические элементы являются "болванками", содержащими в себе определенную функцию: "Поле для ввода" отличается от "Выпадающего списка" – каждый из них несёт в себе определенный смысл, логику работы с данными. Но в рамках уже этой логики могут содержать разновидности, определить которые как раз и можно благодаря памятке:
В "Поле для ввода" вводятся значения по маске или произвольно – это уже настраивается в зависимости от потребности (если вводиться строго регламентированные значения – маска нужна; если нет – ввод произвольный)
В "Выпадающем списке" возможен контекстный поиск – и это также настраивается по потребности (мало значений – не нужен; значений много – стоит добавить)
В памятке собраны все такие вопросы, которые помогают эти разновидности определить, чтобы аналитик никакой из вопросов не упустил
Это моё мнение
Не очень понятно, почему с самого начала возникают какие-то элементы.
Например, у нас есть форма авторизации пользователя, и сначала имеется задача, которая решается этой формой — сама авторизация. От пользователя нужно получить логин и пароль, но это можно сделать различными способами.
В этой статье я не стал расписывать логику целых функций, например, какие вопросы нужно задавать, чтобы реализовать авторизацию, в ходе которых можно прийти к тому или иному способу. Я взял масштаб меньше, сами конкретные графические элементы.
В будущем, мне действительно интересно расписать также работу различных функций, и расписать также больше бэковскую логику.
В этой статье тема сужена до работы с требованиями к графическому интерфейсу пользователей (GUI), чтобы на этом примере показать что именно может помочь аналитикам в работе.
Я рад говорить правду, и рад, если получается обосновать то, что не уделение времени документированию – опасный путь, приводящий к стремительной потере качества, а потом ещё и того же самого драгоценного времени. Надеюсь, как можно большее количество руководителей смогут согласится с этим, и смогут балансировать между скоростью разработки и качеством продукта
В памятке собрано много вопросов, и я также надеюсь, что они покрываюсь большую часть логики работы элементов, и работая с ней можно существенно упростить свою жизнь, а для новичков-аналитиков – закрепиться в IT и быстрее стать полезным для своей команды
К сожалению, я не совсем понимаю ваш комментарий, и как он связан со статьёй (
Кому удобно пройти процедуру в тестовом режиме? Какую именно процедуру? Что имеется в виду под эдаким в середине пути, и почему это неприятно узнавать, если работа ведётся в тестовом режиме? Почему в режиме мастера (как понимаю того, кто в тестовом режиме имеет права модератора), этапы проходятся с реальными данными? О каких именно информационных системах идёт речь?
Пример самих требований, которые составлены по методике, по вопросам из памятки, указаны на скриншоте, который подписан так: "Пример таблицы с фиксированными требованиями по каждому элементу интерфейса"
Прочитал твою статью! Будем надеяться, что со временем сможем ещё больше шаблонизировать процесс описания требований к интерфейсу, захватывая всё больше элементов и функций, упрощая работу как аналитикам, так и всей остальной команде по работе с требованиями
В Agile участники команды должны быть взаимозаменяемыми, а значит, что обратный поток возможен! У кого-то может быть больше компетенций, поэтому в ходе проектирование решения аналитик может советоваться с ним или уже предлагаемый аналитиком вариант решения валидируется дизайнером/проектировщиком или разработчиком. Все работают над одной задачей, и если есть лучшие решения, то, конечно, их нужно выдвигать, обсуждать и принимать
По правильному мы не должны собирать от заказчиков готовые решения (так как они могут их не знать или представлять неверно), а должны спрашивать про то что они хотят получить и какие проблемы хотят решить – заказчик знает цель, а аналитик помогает ему проложить путь к этой цеди. Далее уже собрав от них бизнес-требования мы должны сами спроектировать решения, которые подходили бы для достижения их целей и решения их потребностей
В ходе проектирования должно складываться понимание какие графические элементы должны быть на той или иной странице и большая часть того, как они должны работать. По некоторым же нюансам работы этих элементов, думаю, правильным будет задать заказчику эти конкретные вопросы по элементам письменно (но сформулировав вопросы в простом для их понимания языке), и предложить ответить ему так, как ему самому будет удобно: устно при встрече, по телефону или письменно. Если встреча устная, то нужно вести запись разговора. Далее остаётся проверить, упорядочить и задокументировать его ответы на "техническом языке" в спецификации
Я наоборот открыто рассказал о проблемах, с которыми сталкиваются в Agile аналитики, из-за чего не могут делать свою работу качественно, и предложил решение, благодаря которому можно экономить время и прийти к этому качеству
Спасибо за разработанный сервис! При попадании в ДТП всегда испытываешь стресс, а с таким инструментом можно пошагово и без ошибок оформить европротокол, да ещё и сэкономить время на посещение страховой
Спасибо, что поделились примером проведения custdev-исследований, что и позволило сделать максимально полезный сервис
Вы делаете великое дело! Сначала в Госуслугах сделали текст и UX проще. Теперь в документах сделаем язык ведомств проще, а далее ведомства работая с такими документами привыкнут к таком языку, и это уже перейдёт в их подсознание и станет обыденным в работе: и так все ведомства станут взаимодействовать с гражданнами через простой заботливый текст
Впереди ещё много ведомств, и чем большему количеству поможем, тем больше распространим идею: "Госуслуги – Проще чем кажется", во благо всех
Information
Rating
1,493-rd
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Что за токсичная обстановка в конце статьи? Почему-то удары CI мужчины это весело.. давайте нарисуем как CI бьют по голове разработчика Машу, и посмотрим на комментарии. Пусть лучше никто никого не будет бить, ни мужчин ни девушек.
Спасибо! Срезонировало с пирамидой Дилтса
Спасибо, что поделились своим опытом!
Подскажите, а какие русскоязычные курсы, тренажеры и сертификации по Скраму Вы посоветуете?
Если рассматривать, например, "Карту" как целый сервис, то его также, как и указано в статье, можно разбить на отдельные графические элементы и описывать логику уже каждого из них. И в этой статье рассмотрены требования, которые будут в большей степени реализованы frontend-разработчиком: охватить всю логику, в том числе back, которая как "бóльшая часть айсберга" скрыта от пользователей, не было целью статьи.
В будущем я хочу составить описание для целых типовых сервисов, с которыми сам сталкивался в работе аналитиком, например, формы регистрации и авторизации, формы обратной связи, в том числе и упоминаемого тобой раздела уведомлений – логики в них и подобных сервисах будет много. И тогда это смогло бы стать также подспорьем для аналитика в том, чтобы при проектировании этих сервисов ничего не забыть.
Как понимаю для таких сервисов уже существуют целые модули, которые разработчик может настроить под нужды своего IT-продукта и использовать. Проверка аналитиком того, все ли возможные вариации в логике таких модулей учтены как раз и может помочь в составлении таких статей в помощь аналитикам.
Именно эту задачу и решает: описание логики отдельных графических элементов.
Но этого разве мало? Разве это не первый шаг, с которого должна начинаться работа по описанию логики работы элемента? Такого описания для графических элементов я нигде не нашёл (хотя и встречал в открытом доступе дизайн-системы компаний, но в них было описание элементов для UX-дизайнеров) и составил такой чек-лист сначала для себя, а теперь делюсь со всеми аналитиками. Думаю, лучше иметь такой чек-лист под рукой, чем всегда надеяться на память, упуская какие-то вопросы и тратить время на то, чтобы их вспоминать. Памятка получилась большой, и будет ещё больше, пополняясь новыми элементами и вопросами – для первой итерации должно быть достаточно )
Наталья, спасибо, что поделилась реальными практиками из жизни продукт-оунера, что помогли достичь результатов в сплочении команды!
Спасибо, Олег, за интерес к этой теме!
Было интересно с тобой обсудить статью. Ты крутой аналитик, раз есть такая любовь работать с текстом. Будем на связи!
А в чём заключается противоречение, когда на одной и той же странице находится обе эти кнопки?
Кем ожидается? Реализация страницы происходит исходя из потребностей. Вы можете сами проверить, что в Госуслугах при прохождении услуги логика кнопки "Назад" и "Продолжить" как раз сохраняет все введённые значения и загруженные документы как на предыдущих шагах при возвращении "Назад", так и при возврате обратно вперёд по кнопке "Продолжить". Наши аналитики видели в этом потребность и именно так проектируют услуги. И именно такой вариант я указал на скриншоте в качестве примера.
В других случаях, например, в режиме мастера, вы правы, может быть актуальным при возвращении назад сброс всех введенных значений на последующих окнах. Я лишь привёл пример, и в контексте Госуслуг пример корректный.
Значит я как минимум правильно сделал, что указали вопрос про подсказки в полях в памятке, чтобы аналитик мог его себе задать и принять осознанное решение об их указании.
В целом, многое из того что было указана в памятке является не то чтобы обязательным, а тем, что сделает работу с информацией удобнее. Например, в таблицах хорошим тоном является закреплять верхнюю строку, делать фильтрацию и позволять сортировать данные, но может быть так, что в каком-либо конкретном спринте на реализацию всего и сразу не хватает ресурсов, поэтому аналитику необходимо по крайней мере распределять что и когда нужно будет из этого всего "обязательного для дружелюбного интерфейса" реализовывать.
255 символом – это много. Нет в реальности такого названия органа, выдающего паспорт, которое бы превысили это количество. Поэтому в большинстве случаев (если пользователь вносит реальные данные из своего паспорта) пользователь никогда не дойдёт до этого ограничения. И именно поэтому я и не стал заранее загружать пользователя информацией об этом ограничении. Вот если пользователь введёт туда данные какие-то иные – вот тогда ограничение сообщит ему о том превышено допустимое количество символов.
Это моё решение так спроектировать систему с учётом контекста, который я указал выше. В статье указан пример, а Вы можете закладывать ту логику в таких случаях, которую считаете нужной.
Подскажите, а есть ли у Вас примеры используемых на сайтах или приложениях ввод символов в таких вот квадратиках, как это обычно бывает в бумажных документах? Как раз в бумажных документах это используется, чтобы человек делал запись не прописными, а печатными буквами, чтобы потом было легче эти символы распознать, но при вводе с клавиатуры такая потребность уже отпадает
Сколько Вы, например, заложили бы таких квадратиков для ввода символов в таком поле "Кем выдан"? Чтобы это определить необходимо узнать все названия органов, выдающих паспорт, и далее найти самое длинное и указать такое количество квадратиков, чтобы это самое длинное название смогло поместиться. Скорее всего такое исследование станет избыточным, и ресурсы лучше направить на другие задачи.
Согласен, что хорошая практика сообщать пользователям о том, где в бумажном документе находится то поле, данные с которого необходимо записать в поле в виде скриншота. Видимо, паспорт РФ используется часто, поэтому здесь в этом скриншоте потребности не увидели, но для других документов такие подсказки могут быть полезными.
Хороший продукт не требует документации для пользователей, и он должен в себе содержать интуитивно понятный интерфейс, подсказки.
Но хороший продукт требует в каком-либо виде документацию о логике его работы для команды разработки, иначе не видя всю логику работы продукта легко сделать требования противоречивыми или даже второй раз случайно реализовывать подобное, что уже есть реализовано. Для команды разработки всё время проверять логику работы продукта смотря на то как он работает неудобно, а вот работать с логикой продукта в его графическом проекте и спецификациях, где все требования упорядочены – удобно, а значит качество разработки будет выше и будет экономия времени в работе.
Да, в предложении "И чаще всего жертвуют именно документированием — отдают разработчикам тезисно записанные в таск-трекере требования, подкреплённые устным объяснением" я говорю именно о внутреннем документировании, спецификации, SRS.
Графические элементы являются "болванками", содержащими в себе определенную функцию: "Поле для ввода" отличается от "Выпадающего списка" – каждый из них несёт в себе определенный смысл, логику работы с данными. Но в рамках уже этой логики могут содержать разновидности, определить которые как раз и можно благодаря памятке:
В "Поле для ввода" вводятся значения по маске или произвольно – это уже настраивается в зависимости от потребности (если вводиться строго регламентированные значения – маска нужна; если нет – ввод произвольный)
В "Выпадающем списке" возможен контекстный поиск – и это также настраивается по потребности (мало значений – не нужен; значений много – стоит добавить)
В памятке собраны все такие вопросы, которые помогают эти разновидности определить, чтобы аналитик никакой из вопросов не упустил
Это моё мнение
Ты верно говоришь — в статье мы упустили этапы сбора требований от бизнес-заказчика или в ходе CusDev, и их валидирование, но это сделано осознано. В комментарии выше https://habr.com/ru/companies/rtlabs/articles/730806/comments/#comment_25490288 я описал процесс сбора требований.
В этой статье я не стал расписывать логику целых функций, например, какие вопросы нужно задавать, чтобы реализовать авторизацию, в ходе которых можно прийти к тому или иному способу. Я взял масштаб меньше, сами конкретные графические элементы.
В будущем, мне действительно интересно расписать также работу различных функций, и расписать также больше бэковскую логику.
В этой статье тема сужена до работы с требованиями к графическому интерфейсу пользователей (GUI), чтобы на этом примере показать что именно может помочь аналитикам в работе.
Олег, спасибо что уделил время и детализировал информацию! Так действительно стало понятнее
Спасибо, что отметил мою статью!
Я рад говорить правду, и рад, если получается обосновать то, что не уделение времени документированию – опасный путь, приводящий к стремительной потере качества, а потом ещё и того же самого драгоценного времени. Надеюсь, как можно большее количество руководителей смогут согласится с этим, и смогут балансировать между скоростью разработки и качеством продукта
В памятке собрано много вопросов, и я также надеюсь, что они покрываюсь большую часть логики работы элементов, и работая с ней можно существенно упростить свою жизнь, а для новичков-аналитиков – закрепиться в IT и быстрее стать полезным для своей команды
К сожалению, я не совсем понимаю ваш комментарий, и как он связан со статьёй (
Кому удобно пройти процедуру в тестовом режиме? Какую именно процедуру? Что имеется в виду под эдаким в середине пути, и почему это неприятно узнавать, если работа ведётся в тестовом режиме? Почему в режиме мастера (как понимаю того, кто в тестовом режиме имеет права модератора), этапы проходятся с реальными данными? О каких именно информационных системах идёт речь?
Денис, привет!
Пример самих требований, которые составлены по методике, по вопросам из памятки, указаны на скриншоте, который подписан так: "Пример таблицы с фиксированными требованиями по каждому элементу интерфейса"
Антон, привет!
Прочитал твою статью! Будем надеяться, что со временем сможем ещё больше шаблонизировать процесс описания требований к интерфейсу, захватывая всё больше элементов и функций, упрощая работу как аналитикам, так и всей остальной команде по работе с требованиями
В Agile участники команды должны быть взаимозаменяемыми, а значит, что обратный поток возможен! У кого-то может быть больше компетенций, поэтому в ходе проектирование решения аналитик может советоваться с ним или уже предлагаемый аналитиком вариант решения валидируется дизайнером/проектировщиком или разработчиком. Все работают над одной задачей, и если есть лучшие решения, то, конечно, их нужно выдвигать, обсуждать и принимать
Спасибо за положительный отзыв!
Павел, привет!
По правильному мы не должны собирать от заказчиков готовые решения (так как они могут их не знать или представлять неверно), а должны спрашивать про то что они хотят получить и какие проблемы хотят решить – заказчик знает цель, а аналитик помогает ему проложить путь к этой цеди. Далее уже собрав от них бизнес-требования мы должны сами спроектировать решения, которые подходили бы для достижения их целей и решения их потребностей
В ходе проектирования должно складываться понимание какие графические элементы должны быть на той или иной странице и большая часть того, как они должны работать. По некоторым же нюансам работы этих элементов, думаю, правильным будет задать заказчику эти конкретные вопросы по элементам письменно (но сформулировав вопросы в простом для их понимания языке), и предложить ответить ему так, как ему самому будет удобно: устно при встрече, по телефону или письменно. Если встреча устная, то нужно вести запись разговора. Далее остаётся проверить, упорядочить и задокументировать его ответы на "техническом языке" в спецификации
Спасибо за положительный отзыв! Надеюсь, и дальше смогу шаблонизировать методы детализирования требований, благодаря чему работать станет легче
Я наоборот открыто рассказал о проблемах, с которыми сталкиваются в Agile аналитики, из-за чего не могут делать свою работу качественно, и предложил решение, благодаря которому можно экономить время и прийти к этому качеству
Спасибо за разработанный сервис! При попадании в ДТП всегда испытываешь стресс, а с таким инструментом можно пошагово и без ошибок оформить европротокол, да ещё и сэкономить время на посещение страховой
Спасибо, что поделились примером проведения custdev-исследований, что и позволило сделать максимально полезный сервис
Вы делаете великое дело! Сначала в Госуслугах сделали текст и UX проще. Теперь в документах сделаем язык ведомств проще, а далее ведомства работая с такими документами привыкнут к таком языку, и это уже перейдёт в их подсознание и станет обыденным в работе: и так все ведомства станут взаимодействовать с гражданнами через простой заботливый текст
Впереди ещё много ведомств, и чем большему количеству поможем, тем больше распространим идею: "Госуслуги – Проще чем кажется", во благо всех