Вверхнеуровневый документ и политика в области качества

Данная статья — короткий ликбез о процессе проектирования интерфейсов, не включая этап реализации финальных макетов. Что в него входит и почему все происходит именно в такой последовательности. О том, как организовать информацию по задаче, чтобы она помогала, а не мешала проектировать. О том, как поэтапно подходить к созданию макетов, увеличивая детализацию с каждой итерацией. Делюсь своим опытом и опытом коллег из Byndyusoft.

Кому будет полезно

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

Первый шаг. Систематизация требований

Проблема. На старте проекта или задачи дизайнер перегружен информацией. Вводные данные, вопросы, идеи и другие мысли роятся в мозгу, создают тревогу и ощущение «каши» в голове.

Решение. Раскладывать информацию «по кучкам» в различные цифровые артефакты.

Люди могут решать в уме только простые математические уравнения. Чтобы справиться с системой дифференциальных уравнений с тремя неизвестными решающий, наверняка, воспользуется дополнительными инструментами: калькулятором, бумагой, ручкой, интернетом.

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

В этом дизайнеру призваны помочь инструменты аналитики, перечисленные ниже. Для краткости указаны только названия инструментов и их предназначение. К каждому инструменту добавлена ссылка на подробное описание. Все инструменты стоят того, чтобы изучить их отдельно.

Event Storming. Инвентаризация пользовательских действий, экранов для вывода информации и взаимодействующих систем через разметку процесса ключевыми событиями. Почитать: Introducing EventStorming

Журнал проектирования. Инструмент для структурированного хранения и контроля входящего потока информаци. Почитать: Журнал проектировщика.

Фрагмент текстового мудборда. Важно сформулировать, что именно понравилось и что хочется позаимствовать

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

Второй шаг. Верхнеуровневый макетный граф

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

Решение. Создать «дешевую» версию макетного сценария.

Чтобы детально и достоверно отрисовать один макет важно понимать, с какими макетами он будет связан и как все вместе эти экраны образуют конечный интерфейс, решающий задачу пользователя. Если не понять весь путь заранее, велика вероятность ошибиться и потратить много времени на экран, который придется переделывать или вообще выбросить.

Сконструировать макетный путь за минимальное время помогает инструмент Breadboards. По сути, мы выписываем названия экранов а также элементы взаимодействия, доступные на них. Затем связываем все элементы между собой.

Фрагмент из книги “Shape Up” by Basecamp

Выглядит просто и понятно, строится максимально быстро. Однако при создании такой структуры оголяются детали и связи, которые дизайнер просто не мог бы учесть, если бы рисовал начисто один единственный макет.

Иногда нужно пойти чуть глубже и представить как приблизительно будет выглядеть макет из дальней части пути. Для такого представления можно использовать Fat Marker Sketches — подход, когда будущий макет намеренно рисуется толстым маркером, чтобы избежать высокой детализации и, следовательно, больших временных затрат.

Алгоритм создания макетов

Проблема. От возможных вариантов интерфейсных решений голова идет кругом.

Решение. Придерживаться определенного алгоритма создания макета, искусственно ограничивая себя.

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

Дело в том, что решений можно создать множество, но непонятно, как из них выбрать наиболее подходящее. Особенно трудно это сделать, когда дизайнер не ограничен рамками дизайн-системы, и в проекте еще не сформировалась четкая номенклатура UI элементов.

В данном случае спасти от паралича выбора и избыточной траты времени может осознанное движение по макету в следующем порядке: от главного к второстепенному, от содержания к форме.

Под движением от главного к второстепенному я подразумеваю подход Epicenter Design: в первую очередь на макет помещается его основная ценность, суть. Вспомогательные элементы размещаются в оставшемся пространстве. Часто дизайнеры сваливают на фрейм все подряд, не думая о порядке размещения. В таком случае корневой функциональности может не достаться должного пространства. Подход Epicenter Design делает интерфейс более ориентированным на цели пользователя и помогает проектировщику правильно расставлять приоритеты при сборке макета.

Карточка товара в OZON. Соль страницы — фото, название и цена товара, а также возможность его приобрести — находятся в эпицентре, а все остальное аккуратно размещено в оставшемся пространстве.

Что касается движения от содержания к форме, то здесь речь идёт об алгоритме верстки. Лично мне близок алгоритм, предложенный Игорем Штангом.

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

Проблема. Использование нерелевантных данных при проектировании макетов делает конечный UI непригодным для реальной эксплуатации.

Решение. Стремиться к максимальной полноте и точности данных при создании макетов.

Рассмотрим, на какие вопросы отвечает проектировщик интерфейсов при наполнении макетов данными.

Вопрос №1. Какие данные потребуются пользователю?

Мы в Byndyusoft называем процесс детализации пользовательских историй инвентаризацией. Именно во время инвентаризации удобнее всего определять перечень необходимых пользователю данных. И, конечно, лучше всего, если истории детализируются совместно с заказчиком или с его валидацией.

Фрагмент USM, в котором каждая история «инветаризирована»

Привязывать данные к пользовательским историям выгодно, потому что таким образом данные «мапятся» сразу на определенные моменты времени и, в некоторых случаях, на конкретные макеты. А появление необходимого количества нужной информации в нужный момент времени, как писал Bret Victor в своей книге “Magic Ink” — важнейшее конкурентное отличие графических интерфейсов от печатных источников информации.

Вопрос №2. Где взять данные?

Существует несколько способов «добычи» данных.

Придумать данные самостоятельно. Самый быстрый и наименее точный способ. Особенно если дизайнер плохо знаком с предметной областью. Советую к нему не прибегать.

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

Получить реальны данные. С продакшена, из БД или с физических носителей, если создаваемая система еще не оцифрована. Реальный данные — самые точные и надежные. На их получение может уйти время, но оно того стоит.

Сгенерировать данные с помощью рандомайзеров. Многие данные (юридические лица, ФИО, даты, числа определенной длины) можно «замокать» с помощью генераторов из интернета. Этот способ чаще всего используется как вспомогательный, в совокупности с реальными данными. Ниже приведена подборка ресурсов, на которых удобно создать некоторые форматы данных.

• randomus.ru — числа, пароли, имена, никнеймы
• rand.by — дата, время
• barcode.tec-it.com — штрих-коды
• qrcode.tec-it.com — QR-коды
• brandbucket.com и genlogo.com — названия компаний. На английском и русском соответственно

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

Коллекция данных, собранная коллегой из Byndyusoft

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

Пример работы с данными

Представим, что мы в роли администратора склада хотим увидеть принятые на склад товары и сравнить их фактическое количество с ожидаемым. При спешном и невнимательном подборе данные для интерфейса будут выглядеть примерно так:

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

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

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

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

Но, опять же, общение с пользователями и анализ реального положения дел на складах дали понять, что за одну приемку может приниматься большое количество SKU, что соответствующим образом отразилось в интерфейсе.

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

Заключение

Резюмируя все, что написано выше, дизайнеру предлагается перед началом работы над макетами выполнить три процедуры:

• Систематизировать требования. Это поможет освободить мыслительный ресурс и не забивать «оперативную» память.
• В явном виде задать последовательность будущих макетов. Это позволит заранее учесть некоторые связи и зависимости.
• Определить, какие данные и в каком порядке будут расположены на макетах. Благодаря этому вы облегчите себе выбор для визуализации данных и сделаете ваши макеты максимально приближенными к реальному продукту, с которым предстоит работать пользователям.

Выполнив эти шаги вы сможете, наконец, заняться тем, что, по мнению людей не из профессии, является основой работы UX/UI специалиста – подбором шрифтов, двиганьем кнопок, добавлением фильтров, ссылок, и.т.д.

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

Впервые материалы из этой статьи были показаны на конференции DUMP 2022 в Екатеринбурге.

Единый договор с перевозчиком. Анализ некоторых положений. Часть 3 Логистический рынок насыщен вариантами новых цепей доставок Развивать инфраструктуру МТК Север – Юг нужно со всех сторон Эксперт о новеллах валютного законодательства и логистике Большинство участников транспортно-логистической отрасли положительно оценивают состояние рынка Кабмин одобрил эксперимент по онлайн-продаже алкоголя Мировая логистика избавляется от перегрузок

В Сбере создали «Рабочее место D-people» — удобный сервис для исследователей данных, который позволил сократить время разработки и вывода модели в производство с более чем трех месяцев до одного дня. CDO Сбербанка Борис Рабинович рассказывает о фабрике, лаборатории и супермаркете данных, а также о новом клиентском опыте дата-специалистов.

Чтобы оперативно принимать решения на основе данных, необходимо вовлечь в работу с ними как можно больше сотрудников. Какие шаги предприняли в Сбере, чтобы быстро и с разумными затратами проверять различные гипотезы, находить эффективные решения и за считанные часы вводить в эксплуатацию модели на базе машинного обучения? Как на платформе «Фабрика данных» появилось «Рабочее место D-people» и что за этим последует, рассказывает номинант CDO Award 2021 Борис Рабинович, CDO Сбербанка, старший управляющий директор, директор департамента управления данными Сбербанка.

– Как зарождался data-driven-подход в Сбере?

После того как мы поняли, что с текущими темпами роста наших объемов данных масштабировать текущую архитектуру будет очень дорого, было принято решение о запуске программы создания «Фабрики данных». В рамках этой программы была разработана новая, современная архитектура, принята политика управления данными, внедрены функция и вертикаль CDO, началась проработка централизованных политик управления корпоративными данными и качеством данных.

– Чем занимается ваш департамент?

Миссия департамента — создание эффективной и доступной для всех подразделений банка среды работы с данными. Он отвечает за разработку, внедрение и сопровождение платформы, а также за управление корпоративными данными.

По смыслу и платформа, и департамент разделены на этапы жизненного цикла данных: загрузка, внутренняя обработка, предоставление данных. Отдельные классы задач — работа с интегрированными данными и сопровождение в режиме 24×7.

Поначалу программа создания «Фабрики данных» воспринималась бизнесом как пассив и факультативная нагрузка, поскольку платформа развивалась в соответствии с приоритетами, поставленными в основном технологическим блоком. Чтобы изменить это отношение, мы поменяли парадигму — пошли от задач бизнеса: определили ключевые проекты бизнес-блоков, связанные с данными, разобрались, что требуется от платформы этим проектам, сделали бэклог задач, привязанный к вехам этих проектов, распределили такие задачи по командам в департаменте и включили в эти команды представителей бизнес-блоков. Кроме того, мы ввели понятие «поколение платформы». Каждая смена «поколений» характеризуется качественным скачком, произошедшим в результате запуска ключевых бизнес-проектов.

В течение двух лет мы организовали подключение к платформе более 250 источников данных, выстроили инструменты для конкретных пользователей. Сейчас каждый третий трайб (группа команд. — Прим. ред. ) имеет на платформе свои решения. Количество решений выросло с 12 на конец 2019 года до 90 на конец 2020-го. Это масштабные аналитические системы, каждая из которых решает множество задач.

– Что собой представляет «Фабрика данных»?

Это платформа, которая на данный момент состоит из более 100 элементов и сервисов, таких как компонент загрузки данных в реальном времени, журналирование действий пользователя, аудит, проверка прав доступа, карта данных как средство навигации, механизм проверки качества данных, механизм распространения данных и т. п. Все эти процессы увязаны и работают так, чтобы в нужное время в нужном месте у наших клиентов были данные и решения. Часть платформы — промышленная область, где процессы выполняются без участия людей (по расписанию и для интеграции с внешними системами). Другая часть связана с процессом разработки, будь то инженерия, создание отчетов, аналитика или задачи data science.

– В чем заключается политика Сбера в работе с данными?

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

Это верхнеуровневый документ, в котором структурированы и описаны ключевые вопросы работы с данными в банке и опорные точки, на которые мы ориентируемся: качество данных, описание данных, владение данными, предоставление прав доступа к данным.

Жизнь не стоит на месте, мы понимаем, какие области надо развивать, и сейчас выходит уже третья версия политики. На 2021 год стоит задача внедрить управление жизненным циклом данных — программу ILM (Information Lifecycle Management), чтобы обеспечить сквозное управление данными на всех этапах — «от рождения до смерти».

У нас не было подхода к «смерти» данных, но сейчас ясно: объем такой, что некоторые данные хранить нецелесообразно — мы их никак не используем, а они занимают место и стоят денег. Особое внимание направлено на все, что связано с конфиденциальными и персональными данными. Мы должны очень четко понимать, где они «живут», как мы их используем и обезличиваем для разных целей применения и как удаляем. Кроме того, все операции с данными необходимо выполнять в строгом соответствии с правилами действующего законодательства в части персональных данных, банковской тайны и других чувствительных данных.

Будет и четвертая версия политики, действие которой распространится на работу с данными не только Сбербанка, но и всей экосистемы. Нет предела совершенству.

– «Кладбище» данных еще не организовали?

Устроить «чердак» данных перед уничтожением — это хорошее предложение, я подумаю. Тема важная, потому что объемы данных Сбера колоссальны. В «Фабрике данных» около 12 Пбайт полезных данных, а с учетом репликаций — около 40 Пбайт. А кроме того, есть еще транзакционные системы, их копии — с ними объемы данных ушли уже далеко за сотню петабайт. Стоит их хранение очень прилично. Поэтому нам предстоит разобраться, нужно ли это хранить и можно ли перевести их хранение из «горячего» в «холодное». Фрагментарно это уже делается, но задача CDO — сделать это системно на уровне всего банка.

– Какие задачи превалируют: направленные на оптимизацию процессов или на создание новых продуктов и сервисов?

У меня три приоритета. Первый и основной — дать возможность бизнесу эффективно реализовывать на платформе все его задачи. Цель каждого из 90 решений — заработать денег и минимизировать потери банка. Второй важнейший приоритет — высочайшие стандарты кибербезопасности платформы. Третий — ее надежность и эффективность. При этом я слежу за тем, чтобы банк получал максимальный эффект, тратя минимальные деньги.

– Какую цель перед собой ставили, начиная работу над проектом D-people?

Ставилась цель — существенно повысить эффективность работы сотрудников D-people (дата-инженеры, дата-сайентисты, дата-аналитики) за счет сокращения времени создания и вывода моделей в промышленную эксплуатацию. Для этого и создавали единое рабочее место. Когда была запущена программа AI-трансформации, в банке появились сотни дата-сайентистов и еще больше дата-инженеров, которые готовят фичи (наборы данных, на которых работают модели. — Прим. ред. ). Если для такой армии созданы оптимальные условия работы (инструменты, доступные данные и пр.), то это в конечном итоге отражается на эффективности компании. Ради этого все и затевалось. Созаказчиком тут выступил розничный бизнес, трайб «Массовая персонализация», возглавляемый Игорем Зарубинским, где сосредоточено большинство D-People розницы.

Основные процессы для исследователей данных — это разработка моделей, анализ их работы, вывод в эксплуатацию и проверка результатов. Но фактически на это коллеги тратили лишь 10–15% времени, остальное занимала рутина — получение инфраструктуры, прав доступа, самих данных, разрешения на вывод модели в промышленную эксплуатацию. В любой крупной организации каждый элемент этой цепочки — длительный процесс. В результате на создание прототипов и проверку гипотез тратились не недели, а месяцы.

– Когда началась работа и какие задачи решали в первую очередь?

Ключевой компонент — лаборатория данных — появился в 2019 году. Это инфраструктура, которая доступна пользователям для прототипирования, проверки гипотез и разработки моделей.

Первая проблема заключалась в длительности процесса получения данных — заказа, получения согласований и разрешений для разовой загрузки данных на сервер. Мы обсудили с коллегами наболевшие вопросы и выяснили, что они хотят концентрироваться на своем ключевом навыке — строить модели, а не тратить время на решение «коммунальных» вопросов.

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

И мы сосредоточились на том, чтобы многократно ускорить получение результата, выстроив новую цепочку процессов и совместив их с инструментарием, компоненты которого интегрированы друг с другом. Сделали супермаркет данных, позволяющий заказать любые доступные в банке данные.

Товары на «полках» нашего супермаркета — это дата-сеты, построенные на основе копий систем — источников информации, с полным описанием атрибутного состава и другой необходимой информации. К выбранным дата-сетам можно заказать доступ: кладешь в корзину, выбираешь к какому времени они нужны, куда их нужно выгрузить и нажимаешь кнопку «Заказать». Формируется подписка. Данные отгружаются c указанной заказчиком периодичностью. Параллельно в этом же интерфейсе происходит предоставление прав доступа.

Также мы запустили магазин инфраструктуры, где можно выбрать виртуальный сервер необходимой конфигурации — с нужным числом ядер, объемом памяти и «начинкой». Заказываешь — и в течение часа разворачивается Hadoop и создается твой персональный сервер. Специально для тебя! Получается новый клиентский опыт: развернув сервер, заказываешь данные в супермаркете, получаешь права доступа — и эти данные автоматически отгружаются на твой сервер.

На следующем шаге дата-сайентисту нужны инструменты. Поэтому рабочее место D-People наполнено всеми современными инструментами обработки данных (spark, hive и пр.), UI (hue, Jupyter Hub) и библиотеками.

Когда сервер развернут со всеми инструментами и современными библиотеками, дата-сайентист начинает делать фичи и моделировать. Следующая задача — вывести витрину фичей и саму модель в промышленную эксплуатацию. Вывод витрины занимает до недели, но это разовая акция, а вот для вывода самой модели, когда витрина уже есть, мы сделали модельный DevOps, оптимизировав этот процесс до 4 часов.

Таким образом, весь цикл организационной работы дата-сайентиста сжат с трех с лишним месяцев до одного дня.

– Какие источники данных использовались?

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

– Какие платформы применяются в работе с данными?

Источниками служат главным образом legacy-системы на базе Oracle, основное хранение данных осуществляется в Hadoop в сборке от Cloudera. С помощью OGG (Oracle Golden Gate) и Apache Kafka мы ежедневно поставляем данные как в пакетном режиме, так и в реальном времени. Движок супермаркета данных и инструмент для загрузки данных — наша собственная разработка на Java, фронтенд сделан на JavaScript. Лаборатория данных обладает динамической инфраструктурой под управлением OpenStack/OpenShift и позволяет динамически развернуть необходимые сборки (Hadoop/Spark/РСУБД), содержащие все нужные инструменты для дата-сайентистов. Инструментарий DevOps AI для прототипирования витрин и моделей с последующим выводом в эксплуатацию строится на стандартном наборе Jenkins, BitBucket, Nexus и прочих решений open source — тут мы ничего не изобретаем.

– С какими сложностями пришлось столкнуться в проекте D-people?

Проблем было несколько: технологическая, процессная и человеческая.

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

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

Но наиболее сложной была человеческая история: необходимо было убедить людей в том, что мы делаем действительно нужные, полезные и перспективные вещи. Добиться, чтобы люди начали доверять созданному нами решению, стали амбассадорами нового бренда и начали «переманивать» коллег выходить из привычных им систем, убеждать их в том, что новое решение эффективнее и за ним будущее.

– Что стало главным достижением этого проекта?

Ключевой эффект — сокращение времени дата-сайентиста на построение модели с трех месяцев до дней. Этот проект обеспечил единое окно к океану данных всему сообществу дата-инженеров и дата-сайентистов. Время доступа к данным сократилось с нескольких недель до часа, получение вычислительных мощностей — с нескольких месяцев до часа. Также инструмент позволил быстро выводить разработанное решение в промышленную эксплуатацию.

– Какие результаты своей деятельности вы считаете главными и как оцениваете свою роль в реализуемых проектах банка?

Первый результат — команда, второй — передовая платформа.

Одним из ключевых изменений стало новое представление о «Фабрике данных» в банке. Мы внедрили совместную ответственность за части платформы тех бизнес-блоков, которые наиболее заинтересованы в результате или создании того или иного компонента. Например, за компоненты загрузки и распространения данных совместно с блоком технологий отвечают розничный и корпоративный блоки. Во главу угла были поставлены проекты, приоритетные для бизнес-блоков. Мы разбираемся до «винтиков» в том, что нужно сделать, чтобы этот проект «полетел», и устанавливаем для команд сроки, чтобы обеспечить бизнесу нужную функциональность в нужное время. В итоге и у сотрудников, и у руководства сложилось другое представление о платформе.

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

– Как платформа будет развиваться дальше?

Количество требований к платформе возросло за год с 250 до 750. В стратегии до 2023 года обозначены задачи, связанные с надежностью уже запущенных инструментов, которые нам предстоит поддерживать, c ростом количества источников и подписок. Кроме того, для улучшения клиентского опыта мы внедряем еще одно цифровое решение — рабочее место аналитика. Так как практически каждый сотрудник банка работает с отчетностью и данными, мы хотим, чтобы у любого из них был инструмент, с помощью которого он может видеть аналитику своего подразделения и делать отчеты.

Данные генерируются во все больших объемах, и выигрывает тот, кто максимально оперативно реагирует на события. Учитывая быстрый рост экосистемы, мы хотим перейти на работу в реальном времени и иметь возможность реагировать на миллионы транзакций. Мы поставили цель — обеспечить обработку более 10 млн транзакций в секунду (это события, которые генерируют наши клиенты во всех каналах одновременно). Поверх этих данных будет выстраиваться рекомендательная система реагирования на действия клиента во всех каналах.

Следующее направление — оптимизация, уменьшение стоимости инфраструктуры и переход на собственные сборки программных продуктов. Мы сделали свою сборку стека Hadoop, назвали ее Sberbank Data Platform, также будет собственная сборка реляционной БД Greenplum. Такие сборки при наших объемах данных позволят существенно снизить стоимость инфраструктуры.

Еще одна тема, как я уже говорил, — внедрение концепции управления жизненным циклом информации.

– А каким вы видите дальнейшее развитие проекта D-People?

Одна из перспективных задач — вывод всей платформы в SberCloud (SberCloud — это наш облачный провайдер). Мы хотим вывести платформу как набор интегрированных друг с другом дистрибутивов, чтобы дать возможность нашим дочерним компаниям строить на них свои решения. Рабочее место D-People — основной компонент облачной платформы, который позволит любому сотруднику загрузить свои данные и выполнить свою задачу. Эта инфраструктура уже до конца текущего года станет доступна внешнему миру.

В соответствии с ГОСТ ISO 9001 (п. 4.2.1) политика в области качества является обязательным документом системы менеджмента качества (СМК) компании.

В соответствии с ГОСТ ISO 9000 (п. 3.2.4) политика в области качества (quality policy) – это намерения и направление деятельности организации в области качества, официально сформулированные высшим руководством. В виде примечаний в указанном ГОСТе также добавляется, что политика в области качества согласуется с общей политикой организации и обеспечивает основу для постановки целей в области качества. Принципы менеджмента качества, изложенные в настоящем стандарте, могут служить основой для разработки политики в области качества.

Из всего вышесказанного следует, что политика в области качества – это обязательный документ, который является частью СМК компании и разрабатывается высшим руководством компании. В принципе, вполне понятно. Но как выглядит этот документ? Что он должен содержать и содержит? Давайте рассмотрим более подробно.

Структура и содержание документа «Политика в области качества»

На основе требований стандартов ГОСТ ISO серии 9000 высшее руководство компании должно обеспечивать, чтобы политика в области качества (ГОСТ ISO 9001, п. 5.3):

• Соответствовала целям компании
• Включала обязательства высшего руководства компании соответствовать требованиям СМК, а также обязательства по повышению результативности СМК
• Создавала основы для постановки и анализа целей в области качества
• Была доведена до персонала компании и понятна ему
• Анализировалась на постоянную пригодность

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

Рекомендации по разработке и содержанию документа

При разработке документа следует придерживаться следующих правил:

• Документ, как правило, является небольшим (1-2 страницы)
• Не следует раздувать документ и добавлять «воду», каждое предложение должно содержать чёткие определения и фразы
• Документ должен быть основан на общей политике и целях компании
• Обязательства высшего руководства о соответствии требованиям СМК и по повышению результативности СМК можно оформить в виде вступительного предложения (первый абзац документа)
• В Политику можно включить пути достижения целей в области качества. При этом можно «не экономить» на путях и упомянуть про различные методы повышения качества компании, например: эффективные действия руководства компании, изучение спроса и предложения на рынке, сотрудничество с партнёрами и поставщиками, повышение квалификации сотрудников и т.д.
• Допускается выделение основных моментов (цели, пути) с помощью средств форматирования документа, например, изменение шрифта (жирность, курсив, размер)

Допускается включать в политику и цели в области качества. При этом важно помнить про требование ГОСТ ISO 9001 (п. 5.4.1): «цели в области качества, включая необходимые для выполнения требований к продукции, должны быть установлены в соответствующих подразделениях и на соответствующих уровнях организации. Цели в области качества должны быть измеримыми и согласуемыми с политикой в области качества». Отсюда следует, что в политику можно включить верхнеуровневые цели компании в области качества, при этом они должны быть измеримыми. Детализацию целей по подразделениям можно оформить в виде отдельного документа, который будет более часто проверяться на актуальность, и в который будут более часто вноситься изменения.

Доведение политики до персонала

В соответствии с ГОСТ ISO 9001 (п. 5.3) политика в области качества должна быть доведена до сотрудников компании, и сотрудники должны её понимать.

При проведении сертификационного или инспекционного аудита инспектор обязательно проверит данное требование. Он может спросить у любого сотрудника компании про политику и цели в области качества. Поэтому политика в области качества должна быть доведена до каждого сотрудника компании. Как это сделать?

Ни в коем случае не принуждайте сотрудников заучивать наизусть этот документ! Сотруднику достаточно:

• знать о существовании этого документа
• прочитать хотя бы один раз и примерно представлять содержание документа
• уметь показать проверяющему, где расположен этот документ

Один из возможных и проверенных способов доведения политики до сотрудников – это выполнение следующих простых действий в процессе подготовки компании к сертификации на ISO 9001:

• Размещение документа на общедоступном информационном ресурсе компании (например, на внутреннем корпоративном портале, где располагается вся документация СМК)
• В процессе обучения сотрудников работе в соответствии с СМК обязательно сделать акцент на документе «Политика в области качества»: объяснить важность документа, место расположения, правила поведения при сертификационном и инспекционном аудитах.
• Как показывает практика, одним из действенных методов является отдельная директива в приказе компании о разработке и внедрении СМК. Например, приказ может содержать пункт типа «Руководителю каждого подразделения довести сведения об СМК (и политике) до каждого сотрудника. При этом руководитель несёт полную ответственность за каждого подчинённого сотрудника в области знаний СМК компании». И тогда каждый руководитель предпримет все методы, чтобы его сотрудники знали всё об СМК компании.

Анализ Политики на постоянную пригодность

Политика, как и любой документ СМК, обязательно должна время от времени проверяться на актуальность. Такую проверку следует запланировать в плане проведения внутренних аудитов. Частота проверки может зависеть от количества и детализации целей в области качества: чем больше целей, тем чаще следует проводить анализ политики. Если цели детальные и устанавливаются для каждого подразделения, то проверку актуальности политики в области качества следует поручить внутренним аудиторам каждого подразделения в части, относящейся к данному подразделению.

ВНИМАНИЕ: Пожалуйста, не забывайте указывать ссылку на источник при использовании материалов данной статьи на других ресурсах. Спасибо!

ML System Design Doc – Reliable ML

Шаблон документа для дизайна ML-систем от телеграм-канала Reliable ML

Что такое ML System Design Doc

ML System Design документ – это по сути сводный план по построению системы машинного обучения для решения конкретного запроса бизнеса в вашей компании.
Его стоит применять на этапе дизайна вашей системы, чтобы в итоге ваше решение было полезным для бизнеса, а именно: могло быть внедрено, работало после внедрения и приносило реальную пользу.

А для того, чтобы этот план было проще построить, и чтобы итоговая система, действительно, приводила к результату, мы в сообществе Reliable ML разработали шаблон такого документа.

Зачем нужен ML System Design Doc

Дизайн-документ, созданный на этапе проектирования системы, помогает Data Science подразделению:

• Структурировать собственные мысли: БТ, архитектура решения, результат, применение
• Задать все критические вопросы бизнесу, уточнить бизнес-требования
• Понять бизнес-процесс и нюансы применения ML-системы
• Понять, что реализация проекта возможна и какие ожидают трудности
• Синхронизировать ожидания технической и бизнес-команд
• Установить стандарты работы

Как составить ML System Design Doc

• Прочитать краткие рекомендации по процессу заполнения документа (workflow) – здесь.
• Посмотреть детальный доклад о том, что такое ML System Design Doc и о том, как, когда и зачем его составлять – тут.
• Приступить к работе!

Примеры дизайн-документов по шаблону Reliable ML

• Команда Reliable ML готова помочь вам с работой над составлением дизайн-документа – включая ревью самой системы.
• В приоритете проекты, которые готовы выложить финальный документ в открытый доступ (без NDA части) – как в разделе выше.

Материалы для дополнительного погружения в тему

• Верхнеуровневый шаблон ML System Design Doc от Google и описание общих принципов его заполнения.
• ML Design Template от ML Engineering Interviews
• Статья Design Documents for ML Models на Medium. Верхнеуровневые рекомендации по содержанию дизайн-документа и объяснение, зачем он вообще нужен
• Краткий Canvas для ML-проекта от Made with ML. Подходит для верхнеуровневого описания идеи, чтобы понять, имеет ли смысл идти дальше.

Представим, что нужно узнать стоимость и сроки разработки, но исполнитель не торопится озвучивать предложение, дает большие «вилки», а для точности просит ТЗ, хотя ему уже все предоставили. Разбираемся, почему так происходит и что с этим делать.

Понимание задачи

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

• Задача. В чем ценность?
• Решение. Как выполним?
• Работоспособность. Решение соответствует задаче?
• Результат. В каком виде ожидается результат?
• Срок. Когда нужен результат и почему?
• Ограничения. Что может повлиять на работу?
• Референсы. Делал ли кто-то что-нибудь подобное? Как мы можем это применить?

Этот алгоритм подходит для любой ситуации, даже самой мелкой бытовой:

• Задача: украсить комнату картиной;
• Решение: вбить в стену гвоздь;
• Работоспособность: гвоздь выдержит картину;
• Результат: картина висит на стене и радует глаз;
• Срок: успеть до прихода гостей на выходных;
• Ограничения: нужно сделать днем, чтобы не мешать соседям;
• Референсы: у друзей картина здорово смотрится над диваном.

Пример специально упрощен, потому что как мы увидим, в жизни задачи часто формулируются в виде готового решения. В данном случае — «вбить в стену гвоздь». Это ловушка.

Подмена задачи решением

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

С 1960-х в корпоративном мире популярна карикатура с качелями на дереве. Она высмеивает то, как разные отделы интерпретируют и реализуют проектные требования. Ожидаемо, сатира прижилась и в области разработки информационных систем. Для многих это иллюстрация испорченного телефона, хотя это лишь следствие, а первопричина — за пределами изображения. Заказчик не описал свою проблему. Заказчик описал решение — качели.

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

Для масштабных задач эта проблема не менее актуальна. Перенесемся в сферу IT и посмотрим, как может выглядеть подмена:

• «Нужно разработать кастомную ERP-систему»;
• «Хотим запустить мобильное приложение на iOS и Android»;
• «Ищем пять сениор-фронтендеров на проект»;
• «Сделайте SPA на React».

Неопытного исполнителя здесь ничего не насторожит. Более того, он радуется такой заявке, если она соответствует профилю услуг. А опытные знают, что это не задачи.

Здесь начинается самое интересное. Озвучив решение, клиент ждет от исполнителя предложение. В этот момент одни начнут доставать звонками и просить заполнить бриф, тогда как другие пришлют оформленные КП с приблизительной стоимостью.

Какой из подходов правильный, а какой нет, мы судить не будем. У каждого свои методы работы. Кто-то действует на авось, кто-то планирует расширять смету после старта работ, кто-то по модели fixed-price вообще не работает.

Главное, что проект подвергается рискам на самом старте — ведь может оказаться, что:

• подойдет и коробочная ERP с готовыми модулями для интеграций;
• приложением будут пользоваться работники с Android;
• на проекте еще не готовы дизайн и API, фронтендеры будут простаивать;
• под текущий стек и требования лучше подходит Vue.

Причина

Проблема с подменой связана с устройством контрактной работы. Как обычно происходит? Компания решает, что ей нужно что-то автоматизировать или оцифровать. Она обращается к IT-поставщикам или объявляет тендер.

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

Исполнитель выполняет контракт. На проекте срабатывают всевозможные риски, вследствие чего страдает внутреннее качество. После сдачи исполнитель получает деньги и умывает руки, а система оказывается не приспособленной к задачам компании и дорогой в поддержке и развитии. Компания решает все переделать. Цикл повторяется.

Нарушить порочный круг можно. Далее рассмотрим как.

Истинное предназначение ТЗ

Традиция контрактной работы в том, чтобы требовать от исполнителя четкого соответствия ТЗ, соблюдения сроков и бюджетов. Уровень проработки самого ТЗ остается за рамками этой работы.

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

Обратите внимание, «как надо» — это решение, а оно часто оказывается неработоспособным. В интеллектуальном труде сначала нужно понять для чего, и только потом как.

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

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

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

Далее поговорим о содержании и качестве проработки самих требований.

Типы требований

Все проектные требования принято делить на четыре категории:

Бизнес-требования

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

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

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

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

Пользовательские требования

Если бизнес-требования должны отражать потребности бизнеса, то пользовательские требования — потребности пользователей системы. Иными словами, пользовательские требования — это задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе (например, «регистрация на обучающий курс», «бронирование отеля» и т.д.).

Их выявлением и документированием может заниматься аналитик из команды исполнителя либо специализированная организация, согласовывая результаты работы с заказчиком.

Функциональные требования

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

Нефункциональные требования

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

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

Как описывать требования

Пользовательская история — это краткое утверждение о потребности пользователя, сформулированное на повседневном языке. Формируется по следующему шаблону:

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

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

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

Формат удобен тем, что не требует много времени для составления, а также большого объема документации. Но с их помощью не всегда можно описать альтернативные варианты развития событий или какие-то сложные кейсы. Для таких случаев можно применять сценарии использования.

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

Структура сценариев использования может различаться на разных проектах, но, как правило, должна содержать:

• название и идентификатор;
• наименования действующих лиц;
• входные и выходные условия;
• триггер, запускающий описываемый сценарий;
• пошаговое описание нормального и альтернативных направлений развития сценария;
• исключения;

Сценарии использования более подробны, в сравнении с пользовательскими историями, и потому более удобны для разработчиков, но в то же время на их написание уходит больше времени.

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

В каком формате хранить требования

Требования к продукту фиксируются в проектной документации. Состав документации зависит от степени сложности и объемов проекта и может включать техническое задание, высокоуровневое проектирование, спецификацию на разработку, устав проекта и т.д.

Документ о концепции и границах (vision and scope document) содержит описание бизнес-контекста и концепции продукта, исходные данные, цели и задачи, критерии успеха и ограничения. Этот документ можно назвать верхнеуровневым; он нужен, чтобы зафиксировать основные ожидания от продукта.

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

Спецификация требований (specifications) описывает функции и ограничения разрабатываемого продукта. Документ включает общее описание продукта, классов пользователей, которые будут с ним взаимодействовать, операционной среды, различных ограничений по дизайну и реализации, функций системы, а также требований к данным, внешним интерфейсам и пр.

Техническое задание (statement of work) содержит подробности реализации проекта, а также описание порядка контроля и приемки системы, состава работ по вводу ее в действие, требования к документированию и источники разработки. Однако в зависимости от проекта, какие-то разделы могут объединяться, добавляться или убираться.

Упрощая, можно сказать, что спецификация — это документ о том, как создать продукт, а ТЗ — о том, как создать и запустить. Но на практике границы размыты. Важно не название, а суть итогового документа, чтобы на его основании любая команда разработчиков смогла понять, как именно нужно реализовать желаемый продукт.