SAP инструментарий инвестиций. Design

SAP на сайте https://apphaus.sap.com/toolkit опубликовал широкий спектр инструментов поддержки реализации инноваций - Innovation Toolkit. Эти инструменты, по замыслу SAP, позволяют организовывать, масштабировать и реализовывать инновации в организациях.

SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.

Explore. Исследование. Определение наиболее значимых бизнес-вызовов и наиболее ценных бизнес решений. Участвуют "лидеры бизнеса" и ИТ.

Discover. Открытие. Цель этапа «Открытие» — формирование глубокого представления о проблемах, которые необходимо решить. Для этого используются методы наблюдения, интервью и исследование рынка. Здесь вы найдете различные ресурсы, которые помогут вам пройти этот этап.

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

Deliver. Поставка решений. Разработка архитектуры решения создающих ценность (добавленную стоимость) для бизнеса и для конечных пользователей. SAP предлагает программную платформу - SAP Business Technology Platform. Конечно, это не исключает других платформ, но сайт то SAP, и этим определяется выбор платформы для поставки решения.

Run & Scale. Запуск и масштабирование решений в компании.

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

1. люди (people),
2. процессы (process),
3. место (place),
4. лидерство (руководство) (leadership),
5. технологии (technology).

Этап - Проектирование (design)

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

Результаты этапа:

• Анализ идей и выбор лучших для прототипирования.
• Создание прототипа для демонстрации работоспособности идеи.
• Разработка целевой технической архитектуры предлагаемого решения с учетом мнений заинтересованных сторон.
• Получение отзывов о предлагаемых решениях.

Шаг 1. Формирование идей

Генерация идей структурированным и творческим способом.

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

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

Успешная сессия требует открытого мышления, готового приветствовать любые идеи, как "реальные" так и "нереальные". Позже будет время решить и оценить, а пока нужно воспринимать каждую идею как возможность.

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

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

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

Шаг 2. Идея "на салфетке"

Краткое описание идей, буквально - на салфетке, полученных в ходе мозгового штурма. Расстановка идей по приоритетам.

Не все идеи, генерируемые во время мозгового штурма, ясные и полные. Краткое описание - это документ, который помогает команде поименовать идею, сделать набросок идеи, указать целевую группу, инновационный аспект, ценность идеи для бизнеса и для целевых пользователей. Для этого:

• Держите рядом с собой стикеры с выбранными идеями. Начните с того, что дайте идеям имя и краткое описание.
• Создайте грубый набросок, отражающий суть идеи.
• Укажите, кому будет полезна идея, и перечислите все возможные группы пользователей. Затем опишите ценность каждой идеи с точки зрения разных целевых групп. Используйте разные цвета для каждой группы пользователей.
• Опишите все аспекты, которые делают идею уникальной или инновационной по сравнению с другими, подобными существующими решениями.
• Оцените идею по шкале от 1 до 10 с разных точек зрения: ценность для бизнеса, устойчивость, инновационный потенциал и ценность для пользователей. Суммируйте все оценки, чтобы получить общий балл. Этот балл можно использовать для определения приоритета идей.

"Салфетка идей" примерно может выглядеть так:

Шаг 3. Руководство по созданию прототипа

Создание модели, которая делает идею осязаемой и готовой к проверке.

Зачем делать прототип?

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

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

Когда прототипировать?

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

Уровень детализации прототипа.

Выделяют горизонтальное или вертикальное прототипирование.

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

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

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

Шаг 4. Раскадровка видения

Создание наглядного рассказа об использовании решения.

Зачем создавать раскадровку видения?

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

Когда создавать раскадровку видения?

Раскадровка видения используется на этапе проектирования для определения будущего сценария и создания прототипа, демонстрирующего работу идеи.

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

Пример раскадровки видения:

Шаг 5. Обратная связь

Получение обратной связи от пользователей, заинтересованных сторон, экспертов. Структуризация полученных отзывов.

Отзывы группируются в таблице отзывов со следующими колонками:

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

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

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

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

 

Пример структуризации отзывов:

Шаг 6. Презентация инвестору

Представление для утверждения решения руководству и ключевым заинтересованным сторонам.

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

Можно предложить оформить текущее решение на одном слайде, указав:

• Заказчик решения.
• Необходимость решения.
• Само решение.
• Рыночный сегмент.
• Ключевое преимущество решения.
• Конкурентная ситуация.
• Уникальный отличительный признак решения.

Шаг 7. Вариант использования - диаграмма Use-Case Blueprint

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

Цель схемы вариантов использования — перейти от проектного мышления к архитектурному мышлению. Действия, ориентированные на пользователя, сопоставляются с техническими аспектами архитектуры, такими как данные, системы и технические возможности.  Диаграмма Use-Case Blueprint ориентирована на пользователя и является мостом к творческому мышлению и методологии дизайн-мышления.

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

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

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

Пример диаграммы.

Шаг 8. Базовая архитектура решения

Описание существующих приложений и ИТ-компонент, соответствующие варианту использования.

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

Требуемые операции:

• Список всех текущих приложение и ИТ компонент для повторного использования.
• Понимание зависимостей между идентифицированными ИТ компонентами (функциональная зависимость в терминах запрос/ответ и в терминах информационных потоков).
• Список пользователей и ролей, взаимодействующих с ИТ компонентами.

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

Пример презентации базовой архитектуры решения:

Шаг 9. Концептуальная схема решения

Создание высокоуровневого представления предлагаемого решения.

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

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

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

Пример концептуальной схемы решения.

Шаблон концептуальной схемы решения.

 Шаг 10. Диаграмма реализации решения

Техническое описание предполагаемого решения с помощью строительных блоков решения.

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

Технология построения диаграммы:

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

Пример диаграммы реализации реализации:

Шаблон диаграммы реализации решения:

Шаг 11. Список архитектурных решений

Документирование архитектурных решений и рассуждений.

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

Для документирования строится таблица с колонками:

• Идентификатор.
• Решение.
• Причина выбора (обоснование).

Шаг 12. Концептуальная модель данных

Описание информационных объектов.

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

Информационные объекты (сущности), обрабатываемые строительными блоками решения, наносятся на диаграмму. Информационные объекты идентифицируются однозначным именем, для них добавляются атрибуты или свойства с соответствующими типами данных. Типы данных - простые, например, «число», «строка», «дата». Информационные объекты связываются отношениями. Для отношений указывается множественность. Разные типы отношений отображаются по разному. Например, ассоциация представляется сплошной линией между двумя объектами и описывается глаголом.

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

Пример концептуальной модели данных:

Шаг 13. Модель программного обеспечения

Модель показывает, как архитектура и строительные блоки решения распределяются по ИТ-инфраструктуре.

Цель модели - дать представление о том, как развертывается решение, а именно определяется среда размещения и развертывания программного обеспечения в разрезе строительных блоков решения.

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

Пример модели программного обеспечения:

Шаблон модели программного обеспечения:

Когнитивное заблуждение - пренебрежение знаменателем

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

• Сосуд А содержал 10 шариков, 1 из которых был красным;
• Сосуд Б содержал 100 шариков, 8 из которых были красными.

Какой вы бы выбрали? 

Ваши шансы на выигрыш составили бы 10 % в случае с сосудом А и 8 % в случае с сосудом Б, так что правильный ответ как будто прост. На деле оказалось иначе: 30–40 % испытуемых выбрали сосуд с большим количеством выигрышных шариков, предпочтя, таким образом, меньший шанс на победу.

Дэвид Каннеман называет такую ситуацию пренебрежение знаменателем (denominator neglect).

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

Если прочесть, что «вакцина, предотвращающая развитие смертельной болезни у детей, в 0,001 % случаев приводит к инвалидности», риск кажется небольшим. 

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

Второе предложение затрагивает вас иначе, чем первое: оно вызывает в мозгу образ ребенка, искалеченного вакциной, а 99 999 благополучно привитых детей словно отступают в тень. 

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

Эффект фрейминга

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

Вот две базовых рамки: СОХРАНИТЬ или ПОТЕРЯТЬ.

• Согласитесь ли вы на игру, в которой с 10 %-ной вероятностью выиграете 95 долларов и с вероятностью 90 % проиграете 5 долларов?
• Заплатите ли вы 5 долларов за участие в лотерее, в которой есть 10 %-ная вероятность выиграть 100 долларов и 90 %-ная вероятность не выиграть ничего?

Оба варианта идентичны. В обоих случаях вы выбираете неопределенную перспективу: стать богаче на 95 долларов или беднее на 5 долларов.

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

То есть: «проигрыш» вызывает более сильные негативные эмоции, чем «затраты».

Решение — согласиться или отказаться — принимается под воздействием слов и человек будет склоняться к гарантированной сумме, обозначенной рамкой «СОХРАНИТЬ», и отказываться от того же варианта, обозначенного рамкой «ПОТЕРЯТЬ». Но не всегда. Одни участники в большой степени зависели от рамки, установленной формулировкой. Другие чаще делали выбор независимо от рамки. Это позволило классифицировать выбор с помощью индекса рациональности лица, принимающего решение.

Еще один пример фрейминга

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

• Если будет принята программа А, 200 человек будут спасены.
• Если будет принята программа Б, с вероятностью 1/3 будут спасены 600 человек и с вероятностью 2/3 никто не спасется.

Подавляющее большинство респондентов выбрали программу А: они предпочли гарантированный исход игре.

Изменим формулировку программы.

• Если будет принята программа А', 400 человек умрут.
• Если будет принята программа Б', с вероятностью 1/3 никто не умрет и с вероятностью 2/3 умрут 600 человек.

Последствия программ А и А' идентичны, равно как и последствия программ Б и Б'. Однако при рамках, установленных второй формулировкой, большинство участников выбрали «игру».

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

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

Не все рамки одинаковы: очевидно, что некоторые рамки лучше подходят для описания (или осмысления), чем другие. Рассмотрите следующую пару вопросов:

• Женщина купила два театральных билета по 80 долларов. Придя в театр, она открывает кошелек и обнаруживает, что билеты пропали. Купит ли она еще два билета, чтобы посмотреть спектакль?
• Женщина идет в театр, собираясь купить два билета по 80 долларов. Она открывает кошелек у театральной кассы и обнаруживает, что из кошелька пропали 160 долларов, предназначавшиеся для покупки билетов. Можно воспользоваться кредиткой. Купит ли женщина билеты?

Респонденты, которым предъявлялся только один из вариантов задачи, пришли к разным выводам в зависимости от рамок формулировки. Большинство сочли, что женщина, потерявшая билеты в первой истории, пойдет домой, не увидев спектакля; и большинство решили, что женщина, потерявшая деньги, все равно купит билеты.

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

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

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

* * *

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

Например, предпочтения врачей и пациентов в гипотетических вариантах лечения рака легких сильно менялись в зависимости от того, описывался ли возможный исход в терминах смертности или выживаемости. Хирургическое вмешательство, в отличие от радиотерапии, означает риск смерти в ходе лечения. Как следствие, хирургический вариант выглядел относительно менее привлекательным просто потому, что статистика исходов лечения описывалась в терминах смертности, а не в терминах выживаемости.

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

Роли и обязанности по управлению продуктом

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

• Владелец продукта.
• Менеджер продукта.
• Технический менеджер.
• Дизайнер взаимодействия.

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

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

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

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

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

Инфографика о внедряемых технологиях автоматизации (июль 2022)

Согласно опроса McKinsey "Your questions about automation, answered" от 8 июля 2022 года - инфографика о внедряемых технологиях автоматизации.

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

Ссылка на обзор:

https://www.mckinsey.com/business-functions/operations/our-insights/your-questions-about-automation-answered?cid=other-eml-alt-mip-mck&hdpid=905f89a5-0cd0-4144-a9d6-732bed62a0f5&hctky=1520452&hlkid=2428dc90a22044a5a01a219158a61b2e

Недостатки ООП

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

По мотивам Object Oriented Programming is an expensive disaster which must end
(http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end)

Кстати, о парадигамах программирования можно ознакомиться в Википедии - их много! Но в данной статье раскрываются два тезиса:

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

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

12 вещей, которые должны быть преимуществами ООП, но на самом деле таковыми не являются

• Инкапсуляция.
• Полиморфизм.
• Наследование.
• Абстракция.
• Повторное использование кода.
• Преимущества дизайна.
• Сопровождение программного обеспечения.
• Принцип единой ответственности (Single Responsibility Principle, SRP).
• Принцип открытия/закрытия (Open/closed principle).
• Принцип разделения интерфейса (Interface segregation principle, ISP).
• Принцип инверсии зависимостей (Dependency inversion principle).
• Статическая проверка типа.

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

Инкапсуляция

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

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

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

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

Полиморфизм

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

Зачем нам полиморфизм? Мы хотим гибкости в способах управления исполнением. Но языки ООП обеспечивают гибкость только на основе сигнатуры метода, и сигнатура почти всегда ограничена типами параметров, передаваемых в метод. Так в чем тогда преимущества полиморфизма, если они весьма относительны.

Есть и другие способы гибкой диспетчеризации исполнения.

Наследование

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

Но в программировании ООП наследование опасно. К недостаткам использования наследования объектов можно отнести следующие.

• Большая иерархия наследования. Чрезмерное использование наследования может привести к иерархии наследования, которая имеет несколько уровней глубины. Такими большими иерархиями наследования становится трудно управлять. Их трудно поддерживать из-за того, что производный класс уязвим для изменений, внесенных в любой из производных классов, что и  приводит к хрупкости. Есть еще соображения производительности: создание экземпляров таких классов включает вызов конструкторов по всей иерархии наследования. Плюс требования к памяти "выше среднего" для таких объектов. Примером такого класса - класс javax.swing.JFrame в библиотеке Java Swing, который имеет шесть уровней наследования.

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

• "Разрыв" инкапсуляции. Наследование в ООП - это прежде всего механизм повторного использования исходного кода, а не механизм повторного использования двоичных объектов. Но прозрачность характера наследования ООП зависит от того, является ли автор производного класса автором базового класса или имеет ли он доступ к деталям реализации базового класса. Это нарушает один из других принципов объектно-ориентированного программирования -  инкапсуляцию.

Джошуа Блох в своей книге «Эффективная Java» говорит: «Предпочитайте композицию наследованию». Это симптоматично, что ООП пришлось отказаться от такой мощной идеи как инкапсуляция и признать, что композиция стала предпочтительной стратегией.

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

Абстракция

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

Эта часть относится к ООП: «Абстракция обозначает основные характеристики объекта, которые отличают его от всех других видов объектов и, таким образом, обеспечивают четко определенные концептуальные границы относительно зрительской точки зрения».

Это определение «абстракции» приводит к совету «программа к интерфейсу, а не "программа к реализации класса».

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

Функции производят выход. У функций есть входы и выходы. Входы и выходы - это структуры данных, которые изменяются функциями. В большинстве языков функции построены из последовательности императивов типа: «Сделай то, а потом то ...». Чтобы понять функции, вы должны понимать порядок, в котором они выполняются. Функции понимаются как черные ящики, которые преобразуют входы в выходы. Если я понимаю ввод и вывод, значит, я понял функцию. Это не значит, что я мог написать функцию.

Структуры данных просто есть. Они ничего не делают. Они декларативны по своей сути. «Понять» структуру данных намного проще, чем «понять» функцию. Функции обычно «понимают», наблюдая за тем как они переносят структуру данных типа T1 в структуру данных типа T2.

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

Повторное использование

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

Джон Баркер подчеркивает это:

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

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

Преимущества дизайна (Design Benefits)

Суть преимуществ дизайна в ООП формулируется так: «Кроме того, как только программа достигает определенного размера, объектно-ориентированные программы на самом деле проще программировать, чем не объектно-ориентированные».

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

Джефф Этвуд описал как минимум 2 проблемы с концепцией паттернов дизайна :

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

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

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

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

Сопровождение программного обеспечения

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

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

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

Принцип единой ответственности (Single Responsibility Principle, SRP)

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

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

Принцип открытия/закрытия (Open/closed principle)

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

Принцип разделения интерфейса (Interface segregation principle)

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

ISP - это костыль, который поддерживает ООП. То есть ООП нуждается в поддержке. 

«ISP предназначен для того, чтобы система оставалась изолированной, и, в силу этого, ее было легче реорганизовать, изменить и повторно развернуть». 

Более серьезный вопрос: «Облегчает ли ООП рефакторинг, изменение и повторное развертывание?» 

Если ООП подрывает эти вещи, то ISP - не более чем лекарство для очень больного пациента.

Мы все можем согласиться с тем, что «написание… не требующего пояснений программного обеспечения почти так же важно, как написание рабочего программного обеспечения». Но как создать программное обеспечение, не требующее пояснений? 

Ключевым моментом является выявление базовой модели данных, то есть типов данных и их иерархии. 

Фредрик Брукс однажды сказал: "Покажи мне свои блок-схемы и скрой свои таблицы, и я буду продолжать озадачиваться. Покажите мне свои таблицы, и обычно ваши блок-схемы мне не понадобятся; они будут очевидны". 

Эрик Реймонд: "Покажите мне свой код и скройте свои структуры данных, и я буду продолжать озадачиваться. Покажите мне свои структуры данных, и обычно ваш код мне не понадобится; это будет очевидно".

В объектно-ориентированном языке программирования определения типов данных принадлежат объектам. Поэтому я не могу найти все определения типа данных в одном месте.

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

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

В конце концов, нужно ли вам отказаться от абстракций ООП и перейти к языку более низкого уровня, если вас больше всего беспокоят вопросы эффективности?

Принцип инверсии зависимостей (Dependency inversion principle)

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

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

• Constructor Injection (внедрение конструктора), 
• Setter Injection (внедрение сеттера),
• Interface Injection (внедрение интерфейса).

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

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

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

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

Статическая проверка типа

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

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

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

Идея аутсорсинга разработки программного обеспечения основывалась на некоторых предположениях о том, как должна проводится разработка программного обеспечения. В частности, такой идеи - как идея о «гениальном» архитекторе, поддерживаемом армией дебилов, которые действуют как секретари, программируя под диктовку. ООП был программным эквивалентом тенденции, которая стала распространенной в производстве в 1980-е годы: дизайн должен оставаться в головной конторе а фактическое производство кода должно быть отправлено в страны третьего мира. Работая с UML-диаграммами, написание кода могло быть сведено к простой рутинной работе, в то время как разработкой программного обеспечения могли заниматься провидцы, обладающие эпическим воображением, провидцы, которые могли указать иерархию объектно-ориентированных приложений, которая затем могла быть отправлена ​​в Индию или Вьетнам.

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

SAP инструментарий инвестиций. Discovery

SAP на сайте https://apphaus.sap.com/toolkit опубликовал широкий спектр инструментов поддержки реализации инноваций - Innovation Toolkit. Эти инструменты, по замыслу SAP, позволяют организовывать, масштабировать и реализовывать инновации в организациях.
SAP разработал и представил жизненный цикл инноваций, - от генерации новых бизнес-идей до разработки и предоставления решений. Этот подход ориентирован на человека и состоит из пяти этапов.

Explore. Исследование. Определение наиболее значимых бизнес-вызовов и наиболее ценных бизнес решений. Участвуют "лидеры бизнеса" и ИТ.

Discover. Открытие. Цель этапа «Открытие» — формирование глубокого представления о проблемах, которые необходимо решить. Для этого используются методы наблюдения, интервью и исследование рынка. Здесь вы найдете различные ресурсы, которые помогут вам пройти этот этап.

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

Deliver. Поставка решений. Разработка архитектуры решения создающих ценность (добавленную стоимость) для бизнеса и для конечных пользователей. SAP предлагает программную платформу - SAP Business Technology Platform. Конечно, это не исключает других платформ, но сайт то SAP, и этим определяется выбор платформы для поставки решения.

Run & Scale. Запуск и масштабирование решений в компании.

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

1. люди (people),
2. процессы (process),
3. место (place),
4. лидерство (руководство) (leadership),
5. технологии (technology).

Описание ЭТАПа - "Раскрытие" - Discovery

Как только на этапе "Исследование" определены проблемы и проекты, необходимо перейти к более тщательному их рассмотрению и конкретизировать основные области проекта и определить конкретные требования. Этому посвящены работы этапа "Раскрытие". Возможно также переводить "discovery" как исследование.

Результатом работ этапа "раскрытие" являются:

• Понимание бизнес-проблем с позиции конечного пользователя.
• Генерация дизайн-идей решения.
• Формирование представления о архитектурном ландшафте и сопоставление его с вариантами решений.
• Формирование фундамента для разработки технических аспектов решения..

Шаг 1. Контекстная карта

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

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

Контекстная карта оформляется в виде цветка с лепестками. В центре записывается проблема, на лепестках - идеи, сформулированные в ходе мозгового штурма.

Что такое идея? В данном контексте можно предложить следующее.

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

Идеи, например, могут быть классифицированы следующим образом:

• Продуктовая идея - разработка рыночного продукта.
• Цифровой продукт - создание нематериального продукта, связанного с ИТ технологиями.
• Lean продукт - идея экномии ресурсов.
• Функциональная идея - повышение результативности и эффективности конкретной функции.
• Организационная идея - разработка или совершенствование системы управления.
• Создание актива - создание или приобретение активов, материальных или нематериальных. 

Шаг 2. Разработка руководства полевых исследований

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

 

Следует

1. Разработать протокол интервью. В частности, он должен содержать сведения  о департаменте, о конечном пользователе, дате интервью.
2. Создать рабочую тетрадь с предзаполненными полями и вопросами пользователю.
3. Отправить пользователям рабочую тетрадь для ознакомления.
4. Провести интервью. Желательно, чтобы вопросы задавал один человек, а ответы записывал другой человек. Не следует во время интервью задавать наводящие вопросы или подсказывать пользователям те или иные варианты ответов, идей или решений.
5. Собрать сопутствующие интервью документы, файлы, таблицы или изображения.
6. Подвести итоги каждого интервью с членами группы.

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

Шаг 3. Синтез и визуализация информации

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

или

Шаг 4. Персонажи

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

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

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

Идентификационные характеристики пользователя.

• Фото, имя, возраст, образование и др.

Описание пользователя в контексте решаемой задачи проектирования:

•  Роли пользователя.
•  Цели пользователя.
•  Решаемые задачи.
•  Последовательность и взаимосвязь задач (работ, функций).
• Триггеры или стартовые события, запускающие задачи.
•  Как часто выполняются задачи.
• Длительность задач (работ).

Симпатии и антипатии пользователей.

•  Что нравится?
•  Что расстраивает?

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

Шаблон.

Шаг 5. Карта взаимодействия с пользователем (User Experience Jiurney Map)

На этом шаг создаются сценарии поведения и описываются мотивы пользователей.

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

На этом шаге фиксируется процесс «как есть» (as-is) с ориентацией на человека. Описание процесса «как есть» обычно происходит после проведения интервью с соответствующими группами пользователей и после сбора достаточной информации для понимания текущей ситуации.

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

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

В средней полосе записываются действия пользователя: Какие действия предпринимает пользователь, пытаясь достичь свою цель, выполнить свои задачи?

В верхней полосе записываются мотивы пользователя: О чем думает пользователь во время своего пути и что он чувствует на каждом шагу своего пути?

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

На карте отмечаются "болевые точки" и точки типа "момент истины". 

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

Пример заполненной карты взаимодействия с пользователем:

Шаг 6. Постановка задачи

Решаемая проблема формулируется как изложение возможностей решения проблемы на этапе проектирования. Тем самым создается постановка задачи. Постановка задачи позволяет генерировать идеи на этапе проектирования. Основной вопрос в ходе выработки постановки задачи: "Что мы можем?"

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

Шаг 7. Архитектурные принципы

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

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

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

В общем следует

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

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

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

Шаг 8. Анализ рисков

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

На этом щаге следует определить и кратко описать риски. Затем классифицировать их по уровням риска. Например,

• Высокий риск, связанный с неудачей в реализации архитектурных решений в целом для бизнеса.
• Умеренный риск, связанный с неудачей в реализации архитектурных решений некоторых частей бизнеса.
• Небольшой риск, связанный с тем, что некоторые организационные цели могут быть не достигнуты.

Затем определяются действия для смягчения идентифицированных рисков. После этого пересчитывается уровень риска с учетом принятых мер и вычисляется остаточный уровень риска. Описывается влияние остаточного уровня риска на архитектуру.

Полученные результаты оформляются в табличном виде:

Шаг 9. Контекстная диаграмма решения

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

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

Примерный вид контекстный диаграммы.

Мифы о создании ПО

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

Итак, вот некоторые из сложившихся заблуждений.

1. Цифровая трансформация - это инжерная задача. В частности, ИТ задача.

Но...

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

2. Компании нужно нанять несколько топ-менеджеров, работавших в лучших технологических компаниях для перенацеливания ИТ специалистов для построения нового программного обеспечения. 

Но...

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

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

Но...

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

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

Но...

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

Оригинал текст с мифоми.

https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/four-myths-about-building-a-software-business

McKinsey Quarterly. "Четыре мифа о создании программного обеспечения". 30 апреля 2021 г.