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