Андрей Шапиро написал о схеме преобразования данных в системе с интерфейсом.

— Любая информационная система — последовательность шагов по преобразованию данных;
— Каждый шаг — преобразователь, «чёрный ящик», получающий данные и выдающий результат их обработки. На этом шаге может вызываться внутренний или внешний сервис, выполняться функция программы, работать человек (получать информацию, интерпретировать её, принимать решения и вводить новые данные и команды);
— Предохранитель не допускает, чтобы в преобразователь попадали неподходящие данные. В интерфейсе предохранителем служат искусственные ограничители и обратная связь;
— В умных системах преобразователи умеют работать с самыми разными вариантами ввода (но добиться этого — инженерная задача). В системах поглупее усиливается предохранитель, который подсказывает, что не так с вводом и каким должен быть запрос, чтобы система смогла его обработать;
— Преобразователь в общем случае исполняет некоторую бизнес-логику, перебирает сочетания условий (входные данные) и выдаёт подходящее конкретному сочетанию решение (выходные данные). Удобно записывать их в форме таблиц решений (применяются в нотации DMN);
— Эти таблицы можно соединить в цепь преобразований и таким образом получить полную схему обработки данных;
— Лучше не включать несколько полей ввода в один преобразователь, так как количество вариантов перебора сильно увеличивается, и удобнее разделять ответственность между разными преобразователями;
— А некоторые поля, в которых справочник допустимых значений в предохранителе зависит от входных данных, могут потребовать нескольких преобразователей.

#analysis

Роман Черных написал, почему роль бизнес-аналитика устарела.

— Раньше он переводил расплывчатые пожелания бизнеса в технические требования;
— Например, в ответ на запрос «автоматизировать отдел продаж» собирал требования, документировал процессы и создавал спецификации с диаграммами вариантов использования;
— Сейчас недостаточно переводить запросы (фиксировать требования), надо проектировать продукты, которые решают проблемы пользователей и приносят прибыль;
— Этим совместно занимаются разные специалисты от продакта (определяет, что именно делать, например, зачем автоматизировать отдел продаж?) до системного архитектора;
— Бизнес-аналитик может стать продакт-менеджером, если ему ближе рыночный анализ, формирование идеи продукта, стратегии и метрики;
— Либо UX-аналитиком, если ближе исследование поведения пользователей и тестирование гипотез;
— Либо системным аналитиком, если ближе технические детали и понимание того, как работает система.

#analysis

Елена Плинер написала, как подключаться к задачам с высокой степенью неопределённости, работая попроектно.

— С неполными вводными на старте минимально нужно 40 часов, чтобы заложить основу будущего проекта;
— Даже работая по схеме Time and materials клиент хочет знать примерный срок, бюджет и что он получит;
— Сначала надо собрать и систематизировать вводные (от 5 часов): презентации и текстовые описания, внутренние документы, скриншоты, фото с доски, наброски от руки и так далее;
— Иногда вводные приходят в созвонах, переписках и голосовых, что требует дополнительной обработки и структурирования;
— Может появиться список недостающей информации (метрики, списки конкурентов), а также нераскрытых или двусмысленных описаний, которые требуют конкретизации;
— В итоге получится структурированный список вводных, ссылок на документы, описание проекта (цель, задачи, целевая аудитория, контекст, заявленные проблемы), глоссарий;
— Удобно собрать всё в одном месте, например на FigJam-доске;
— Туда же можно добавить саммари по созвонам, кто за что отвечает в команде заказчика, план проекта, который потом дополнится ссылками на артефакты и их статусами, отчёт о потраченном на проект времени;
— Анализ занимает от 20 часов и зависит от количества и полноты вводных, числа ролей и ключевых сущностей, сложности бизнес-логики, а также желаемого набора артефактов (не все они нужны заказчикам);
— Сильно влияет степень вовлечённости заказчика — как быстро он отвечает на вопросы;
— Артефакты: описание функциональности (возможности и зависимости), схемы бизнес-процессов (последовательность операций, перемещение и обработка данных, граница между онлайном и офлайном), описание пользовательских ролей (чем занимаются, как принимают решения и взаимодействуют друг с другом), сущностей (ключевые объекты, их свойства, связи с другими объектами), сценарии (user stories), список внешних процессов, матрица «Роль × действие × сущность» и базовые правила доступа (CRUDL);
— В процессе анализа фиксируются ключевые требования к интерфейсу, предварительные предложения и решения по дизайну, появляются вопросы;
— Ответы на некоторые вопросы могут требовать времени. Чтобы не тормозить процесс, иногда можно договориться с командой о временных гипотетических ответах;
— Проектирование занимает от 15 часов (зависит от количества сценариев и ролей) и опционально. Артефакты: информационная архитектура (карта экранов), юзерфлоу, опционально мокапы и вайрфреймы.

#process #analysis

Андрей Шапиро написал о вопросах, направляющих проектирование.

— Вопрос — коммуникационный инструмент направленного размышления;
— В проектировании чаще всего имеют дело с вопросами исследовательскими (определение области, которую надо изучить подробнее) и проблематизирующими (постановка задачи);
— В начале проекта, когда идёт снятие задачи, проектировщики иногда не понимают, куда двигаться дальше;
— Чтобы задать качественные вопросы, надо начать исследование и минимально погрузиться в предметную область;
— Основа мышления — создание в голове схем, отражающих модели реальности. Обнаружив отсутствие важных деталей или нарушение логики в построении схем, мы можем это исправить;
— Вопросы позволяют подсветить себе или проектной группе эти проблемные места. Белое пятно — полное отсутствие понимания (по аналогии с картами до великих географических открытий). Серая зона — место, где понимание туманно, и мы это знаем;
— Есть практики ненаправленного интуитивного творческого поиска (вроде поиска образа в каракулях), но в проектировании нужны более надёжные направляющие;
— Ими могут быть следующие артефакты, уточняющие устройство человеческой деятельности: структура потоков, процессы как цепочки последовательных действий и событий, типичные ситуации и способы принятия решений в них, структура внутреннего устройства объекта, структура взаимодействий объектов и так далее;
— Получив новую порцию знаний в диалоге с экспертами и представителями заказчика, проектировщик обновляет картину и подсвечивает вопросами новые моменты для уточнения;
— Беглость приходит с опытом. Не страшно, если новая пачка вопросов появляется между встречами;
— Шаблонные вопросы позволяют снизить неопределённость на старте. Всегда есть фаза предварительного анализа замысла, выяснения сути задачи, её границ и целей заказчика;
— Всегда важно, как будут построены отношения, каковы у сторон ожидания друг к другу, из чего будет строиться процесс, как будет достигаться результат;
— Примеры вопросов о бизнесе клиента: Как вы работаете? На чём зарабатываете? Где вы берёте клиентов? Какой канал продаж самый эффективный?
— Есть ещё вопросы, демонстрирующие проблемы, когда вы уже увидели проблему, а собеседник — нет;
— Большую часть времени проектировщик задаёт вопросы сам себе. Это проблематизирующие вопросы, в которых сформулирована задача. Например: «Как проверяющий узнает, что по портфелю заново запущена проверка?»;
— Шаблоны таких вопросов: Как сделать так, чтобы появился <отсутствующий пока желаемый эффект> или исчез <наблюдаемый нежелательный эффект>? Как или за счёт чего будет работать <отсутствующий пока механизм> с <таким-то результатом на выходе>? Что, где и как поменять в системе, чтобы удовлетворить <новому требованию>?

#analysis