Продолжаю про явное и неявное знание: и вот когда вы считаете, что уже выявили все требования и проработали интерфейс (может быть, даже с дизайнером), и приносите его показывать пользователям, вы считаете, что это уже конец, вся работа сделана.

А для ваших заказчиков в этот момент работа только и начинается! До этого они что-то вам рассказывали, это ничего не значит. А теперь им есть на что посмотреть, есть к чему отнестись. Тут они могут как-то соотнести то, что видят, с тем, как они работают. Знания вытащили из их голов и обособили, эксплицировали. Люди впервые увидели свои неявные знания отдельно от себя и удивились. Теперь их нужно изучить, исправить некоторые моменты, а главное — теперь им понятно, как это будет выглядеть и над чем будет идти работа (над внутренним устройством системы работа пользователей идти не может — оно непредставимо или представимо превратно, если только пользователь сам не был когда-то программистом).

Тут возникает острый конфликт: аналитик думал, что работа уже почти закончена, а пользователь — что работа только началась. Эта мысль поражает неопытного аналитика до глубины души и зачастую выглядит, как издевательство. Особенно когда у пользователей не очень много времени, и встречи по согласованию (как думает аналитик, а на самом деле — по разработке интерфейсов и дополнительных требований) происходят редко. Тут и сроки работ начинают затягиваться, и взаимное недовольство растет.

Что с этим делать? Во-первых, понять и признать, что это происходит. Это, в первую очередь, совет руководителям — а то у них в плане записано обычно "первая встреча — сбор требований, 2 часа", "вторая встреча — согласование экранов, 2 часа", и дальше уже отдали в разработку. Как бы не так.

Во-вторых — ну, как-то нужно решать. Сложно за одну встречу и про требования поговорить, и сразу первичное решение предложить, которое на самом деле только повод поговорить про настоящие требования. Что можно сделать:

➡️ честно запланировать дополнительно 2-3 встречи уже после первоначального эскизного решения;

➡️ сделать "домашнюю работу", и приходить на первую встречу уже с заготовками решения, хотя бы примерными, хотя бы аналогами. Если вы работаете в имеющихся системах — можете показать, как выглядят интерфейсы в них, и обсудить, на что будет похож интерфейс для новой задачи. Если у вас есть дизайн-система — покажите элементы из неё. Если вы делаете новую систему — покажите что-то, что может быть похожим по смыслу. Для системы анализа ЭКГ я использовал в качестве источника вдохновения музыкальный редактор. Если у вас есть бумажные формы, которые вы будете переносить в электронную форму — распечатайте их, покажите, как они могут лечь в интерфейс — вот прямо ножницами порежьте в вклейте в распечатку типовых форм. Ножницы и клей — великая вещь! Всех с началом учебного года, кстати. Если уж совсем ничего нет — пробуйте лего, человечков из настолок и т.п. Да даже стикеры лучше, чем просто текст! На картинке — первая схема "Открытого образования". Сразу стало многое понятнее.

В-третьих — идеальный вариант, это Google Design Sprint или что-то аналогичное. Да, на 5 дней отключиться от рабочих процессов может быть сложно. С другой стороны — ездите же вы на конференции и ходите на тренинги, и ничего. А с точки зрения скорости прохода (времени от идеи до постановки) — выиграете несколько недель.

Как согласовать интерфейсы. Ну ладно, мы разобрались, что, когда пользователь впервые видит интерфейс будущей системы, он не воспринимает это, как финальную версию — а скорее как повод наконец-то подумать, как оно на самом деле будет работать (если вы, конечно, заранее не прорабатывали именно процесс решения задачи, а просто "собирали требования").

Но, допустим, первое впечатление уже получено, и уточняющие требования собраны, и всё уже дважды переделано и вроде мы дошли до стадии утверждения интерфейсов. И с этим очень часто возникают большие проблемы. Они возникают у аналитиков, у дизайнеров и иногда даже у продактов, как ни удивительно. Потому что вместо того, чтобы подтвердить и согласиться, стейкхолдеры в очередной раз начинают просить передвинуть кнопку, добавить ещё пару полей и поиграть со шрифтами. И конца этому не видно.

Что здесь обычно происходит? А происходит неуправляемая встреча. Как такая встреча может быть устроена?

❌ Дизайнер или аналитик просто показывает экран системы. Ну вот мы сделали вот такой экран, есть к нему замечания? Это прямо мощная подача — ведь если стейкхолдер скажет "нет", это может значить, что он что, не заинтересован в системе? Или не успел разобраться, и это сейчас замечаний нет, а потом появятся? Дали ли мы время на то, чтобы ознакомиться? Знаем ли мы сами — каких замечаний мы от этого стейкхолдера хотим услышать? Ещё хуже вопрос "вам нравится?" Тут мы полностью снимаем с себя ответственность и отдаемся в руки человека на другой стороне.

Так быть не должно. Эксперты здесь мы. Мы спроектировали всё правильно — красиво, удобно и логично, и мы за это отвечаем. Не нужно перекладывать решение на человека, который в нём не специалист.

❌ Аналитик показывает экран и начинает рассказывать последовательно про каждый элемент. Не надо так. Люди видят, что нарисовано на прототипе. И понимают, для чего каждый элемент нужен. А если не понимает — кажется, у нас есть проблема. Вот только объяснение делу не поможет — ведь в реальной жизни аналитика или дизайнера рядом не будет, чтобы объяснить, что тут зачем. А визуально человек воспринимает информацию гораздо быстрее, чем на слух. Пока вы рассказываете про каждый элемент, ваш визави уже рассмотрел весь экран, и теперь скучает.

✔️ Как правильно построить презентацию интерфейсов:

1. Рассказать, для каких пользователей создан этот интерфейс (для какой роли или персоны) и в какой ситуации этот пользователь находится, когда использует этот интерфейс.

2. Перечислить сценарии, которые пользователи могут выполнить при помощи этого интерфейса. Обычно есть 1-2 основных сценария и дополнительные, куда входят граничные ситуации, альтернативы, исправления и настройки.

3. Демонстрация прохождения сценария пользователем с какой-то ролью. В качестве пользователя выступает аналитик, либо это предлагается сделать одному из согласующих. Сценарий показывается по шагам, при переходе с одного шага на другой можно спросить у зрителей — понятно ли, как перейти к следующему шагу (как вернуться на предыдущий, как исправить что-то или посмотреть дополнительную информацию). Это закрытый вопрос, он предполагает ответ "да"/"нет". Если на этапе разработки требований вы задавали в основном открытые вопросы, на этапе согласования лучше задавать закрытые вопросы. Теперь это не рассуждения, это вопросы на констатацию факта. Задаем конкретные вопросы — понятен ли этот переход, ясно ли, где мы сейчас, что тут самое важное, где ошибка. Все вопросы на уточнение и выяснение вы, надеюсь, задали заранее.

Если стейкхолдер стремится высказать своё замечание, возвращайте его в ту же схему: про какую роль он говорит? В какой ситуации? Какая цель у пользователя? Что он делает? Что происходит, и что он ожидал?

Часто оказывается, что либо ситуация надуманная и так не бывает, либо в сознании у критика спутаны несколько ролей, либо, возможно, мы действительно пропустили какую-то важную ветвь сценария.

Конечно, про формат нужно предупредить участников заранее. Описание контекста, ролей пользователей и сценариев для демонстрации заранее отправить. И про формат обратной связи рассказать.

В обсуждении списывания времени проскочило совсем дикое сообщение, что в некоторых компаниях запрещают списывать время на совещания и созвоны. Как при этом набрать 8 часов, я не представляю. А те, кто это придумал, видимо, очень далеки от реальности, и уж точно не читали "Мифический человеко-месяц", с его клёвыми фразами типа "программирование — это не сбор хлопка, эту работу нельзя произвольно делить на любое количество частей, и не общаться в процессе".

Вопросы синхронизации и изучения требований требуют времени. Возьмем строгий фреймворк, например Scrum, который обещает выполнение вдвое большей работы за половину времени (это так книга Сазерленда называлась, 'Scrum: The Art of Doing Twice the Work in Half the Time', это название даже испугались на русский переводить, перевели скромно как "Революционный метод управления проектами"). Вот смотрите, что говорит Scrum Guide для спринта длиной в месяц:

8 часов на планирование спринта;
5 часов на дейлики (15 минут в день * 20 дней);
4 часа — спринт ревью;
3 часа — ретро;
16 часов (10% спринта) — Backlog Refinement, совместная проработка требований всей командой (у вас вообще такое есть? Вы про эту практику слышали?..)

Получается 124 часа в месяц, т.е. 6,2 часа в день на работу. Ну, в хороший день у меня тоже так и получается, и это, наверное, максимум, что можно выжать — реальной работы, я имею в виду. На самом деле, что означает 15-минутный дейли? Это значит, что про зависшую задачу ты успеваешь сказать, что она зависла, и тебе нужно обсудить её с тем-то и тем-то ➡️ назначается встреча для решения. Мы же не думаем, что вне ритуалов scrum люди между собой не общаются? Допустим, мы эти встречи тщательно таймбоксим, и их не бывает больше часа в день (ха!). Ещё к этому нужно приплюсовать (или вычесть) время на персональное развитие (1:1, составление планов, выбор конференций/обучения, планирование отпуска и т.п.), кофе и всякую текучку — отведем на это ещё час. Получается примерно 4 часа, что, по моей практике, выглядит уже довольно реалистичным.

Не то чтобы это было хорошо. Но иногда и этих 4 часов нет — например, когда вам дали стажеров или нужно готовить выступление на конференции/внутреннем митапе. В том же скраме, раз мы про него говорим, такими вещами должен заниматься скрам-мастер — убирать из времени команды всё, что мешает (то мебель нужно в новом офисе расставить, то должностную инструкцию себе написать, то распланировать график отпусков на год — всегда есть, чем заняться).

Но знают ли об этом люди, которые берутся трекать время? Мне кажется, первый шаг в любом деле — признание реального положения вещей. Ну не производят люди код или аналитические документы 5 дней по 8 часов. Вон и Scrum говорит — максимально теоретически возможное время — чуть больше 6 часов, к нему нужно стремиться.

И это нормально. При объяснении теории ограничений (ToC) приводят такую аналогию, мне она очень понравилась: как быстрее всего вылить воду из бутылки? Просто перевернуть — вода будет булькать, выходить толчками, т.е., процесс будет регулярно останавливаться и перезапускаться. Если вы раскрутите бутылку и сделаете воронку — вода выльется почти вдвое быстрее, хотя в центре будет пустота — горлышко не будет заполнено. Можно вставить соломинку — горлышко ещё сильнее сузится, но в бутылку будет поступать свежий воздух, и поток станет равномерным. Если в соломинку ещё и подуть — скорость ещё увеличится.

Парадокс: чтобы скорость была выше, часть горлышка должна оставаться свободной. Так и в управлении: ваша цель ведь не в том, чтобы загрузить работников на 100%, а чтобы работа делалась быстрее. Чем равномернее будет поток — тем быстрее получим результат работы. Да, для этого нужно дать приток свежего воздуха 😉 И не занимать полностью весь доступный ресурс. Всё равно не получится, будут остановки и перезапуски. Так не лучше ли это признать с самого начала, и сфокусироваться на гладкости и скорости потока, а не на загрузке людей?

Ну всё, можно считать себя экспертом: Карл Вигерс говорит от требованиях то же и теми же словами, что и я (https://news.1rj.ru/str/systemswing/450), правда, чуть раньше — в 2021 году:

Люди часто говорят о сборе требований к программному проекту, но это создает неверное впечатление. Слово «сбор» предполагает, что требования уже лежат где-то в готовом виде и только и ждут, чтобы их подобрали. Когда я слышу, как кто-то говорит «сбор требований», в моем воображении всплывает картинка сбора цветов или охоты за пасхальными яйцами. Увы, это не так просто.

Требования редко существуют в сознании пользователей в полностью сформированном виде, готовом для передачи бизнес-аналитику или команде разработки, только спроси. Создание набора требований определенно подразумевает этап сбора некой информации, но также включает открытие и изобретение (курсив мой. Смотрите, даже Вигерс пишет, что мы изобретаем требования!). Термин «выявление требований» (requirements elicitation) точнее описывает, как люди из ИТ сотрудничают с заинтересованными сторонами, чтобы изучить, как те работают сейчас, и определить, какие возможности должна предоставлять будущая программная система.

Согласно словарю The American Heritage Dictionary of the English Language (2020), под словом elicitation подразумевается выманивание, вытягивание или провоцирование. Слова «выманивание» и «вытягивание» точнее описывают процесс, чем слова выявление или сбор.

Самые бесполезные вопросы, которые не следует задавать при изучении требований: «Чего вы хотите?» и «Каковы ваши требования?». Такие расплывчатые вопросы вызывают поток множества случайных — но важных, конечно — сведений, смешанных с посторонней информацией и приправленных невысказанными предположениями. Бизнес-аналитик не просто записывает все, что ему говорят заинтересованные стороны. Опытный БА фасилитирует обсуждение, направляя участников на раскрытие имеющего отношение к проблеме знания в структурированном виде.

Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.

Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")

Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что

Две основные практики выявления требований — телепатия и ясновидение. Они не работают. (Урок 13)

Большая группа людей не способна организованно покинуть горящую комнату, не говоря уж о том, чтобы коллективно сформулировать какое-то требование (Урок 14)

И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!

В общем, любопытно. Напишу больше, как дочитаю 📕

Никто не может объять необъятное. Сколько не изучай методы проектирования API, всегда найдется что-то новое. Или старое. Вот, например, текст, который мне раньше не попадался, и идеи, которые в нём приводятся, тоже отдельно не встречались (хотя сам я их использовал при проектировании, так часто бывает).

Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.

Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:

Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.

1️⃣ Перечислите все данные, которые клиентское приложение может захотеть получить или передать в сервис. Назовем их семантическими дескрипторами — они имеют смысл и описывают, что происходит в приложении. Важно: это точка зрения именно клиента! Примеры для приложения для ведения списка дел:
id: уникальный идентификатор каждой записи в системе;
noscript: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")

2️⃣ Нарисуйте диаграмму состояний
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел ➡️ одно дело). Трансформации помечаются как безопасные (идемпотентные) или небезопасные (неидемпотентные). Названия переходов-трансформаций — это тоже семантические дескрипторы.

3️⃣ Согласуйте "магические имена"
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
noscript -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)

(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)

4️⃣ Выберите Media Type
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).

5️⃣ Создайте "семантический профиль"
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).

6️⃣ Напишите или сгенерируйте серверный и клиентский код.

7️⃣ Опубликуйте описание API в каталоге
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).


Вот такие шаги :)

С одной стороны, сейчас звучит немного наивно, с другой — если задуматься, то часто ли мы делаем эти шаги и вообще задумываемся об этих вещах? Нам бы с эндпоинтами и кодами ошибок разобраться...

Мы с уточкой передаем всем подписчикам большой привет с конференции Flow'2024, поздравляем с днём системного аналитика, и желаем удачных проектов, интересных задач, успешного профессионального развития, достижения личных и карьерных целей, а также всеобщего процветания!

Ура! 🎆🎆🎆