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

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

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

У цифровых систем на производстве есть две ключевые задачи: 

–  прозрачность сбора и консолидации данных – вы должны знать, что происходит на производстве; 

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

Программное обеспечение – неотъемлемая часть автомобиля

Исследование аналитиков McKinsey показывают, что разрыв между скоростью и качеством производства у механических агрегатов автомобилей между лучшими и худшими автомобильными компаниями составляет всего 1,5-2 раза. В то время как разрыв в производстве программного обеспечения для новых моделей между топами и замыкающими списка автопроизводителей уже в 3-6 раз. 

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

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

Проникновение программного обеспечения на рынок автопромышленности в цифрах

Несколько тенденций подчеркивают растущую важность автомобильного программного обеспечения. Первый связан с быстрым расширением рынка программного обеспечения и электротехники/электроники, среднегодовой темп роста которого, как ожидается, составит 12% в период с 2020 по 2030 год, что более чем в три раза превышает ожидаемый рост продаж автомобилей в целом. Области самого сильного роста  включают функции программного обеспечения (CAGR 11%), а также интеграционное тестирование (12%).

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

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

Проблема наиболее серьезна с большими модулями, которые становятся все более сложными, такими как информационно-развлекательные и передовые системы помощи водителю (ADAS). Производительность этих модулей примерно на 25–35% ниже, чем у традиционного глубоко встроенного программного обеспечения.

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

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

Путь снижения сложности при одновременном повышении эффективности

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

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

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

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

–  Где программное обеспечение разрабатывается внутри организации, включая местоположение, разработчиков и партнеров;

–  Как разрабатывается программное обеспечение с учетом методологий разработки, таких как agile-at-scale, или изменений в процессах разработки и тестирования.

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

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

Аспект 1 – Какое программное обеспечение разрабатывается: архитектура, дизайн и требования

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

Упрощение архитектуры программного обеспечения автомобиля

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

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

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

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

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

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

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

Методы проектирования, ориентированные на пользователя

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

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

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

Где разрабатывается программное обеспечение: организация, места, разработчики и партнеры

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

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

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

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

Получите доступ к лучшим разработчикам и привлекайте их, а также растите потенциал внутри

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

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

​​Определите четкие стратегии «производи или покупай» и разработайте партнерскую экосистему

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

–  этап процесса разработки, такой как системная интеграция или приемочное тестирование;

–  стек программных технологий;

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

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

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

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

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

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

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

Как разрабатывается программное обеспечение: Agile-практики, разделение, тестирование

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

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

Внедрение agile

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

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

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

Взаимозависимости с разработкой оборудования

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

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

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

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

Однако есть исключения. Например, некоторые пионеры автомобилестроения внедрили методологии Agile, такие как масштабируемая гибкая структура (SAFe), для управления своими всеобъемлющими операциями по исследованиям и разработкам.

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

Поскольку OEM-производители переходят на agile-процессы, они также должны:

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

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

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

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

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

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

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

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

Как и в случае с agile-методами, лишь немногие игроки автомобильной отрасли внедрили методы непрерывной интеграции или автоматизированного тестирования в масштабе. Если они обратят эту тенденцию вспять, они смогут одновременно снизить риск запуска и резко повысить производительность. По нашему опыту, компании увеличили производительность более чем на 40%, сократив плотность остаточных дефектов более чем на 60%.

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

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

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

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

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

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

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

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

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

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

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

Обновление наборов инструментов разработки

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

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

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

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

–  Уменьшить плотность дефектов, разрешив использовать строгие критерии качества, что потенциально снижает частоту отказов на 50 процентов.

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

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

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

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

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

Итог:

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

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

UX-исследование и погружение в домен клиента

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

Что входит в UX-исследование:

1. Анализ бизнеса клиента 

– Определяем бизнес-цели

– Проводим сбор и анализ требований

– Выявляем технические ограничения

– Изучаем специфику бизнеса и бизнес-процессы

2. Анализ конкурентов

– Изучаем ситуацию на рынке, что уже реализовано, чего рынок желает.

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

– Изучаем фидбек пользователей конкурентных IT-продуктов.

– Проводим сравнительный анализ функциональности и дизайна конкурентов.

Путь к качественному UX лежит через дизайн-мышление

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

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

– низкая конверсия из-за неудобного или сложного инструмента;

– потеря пользователей и прибыли продукта;

– сценарии, заложенные в дизайн и функциональность, не реализуются пользователем;

– гипотезы, реализованные без учета пользователя, оказываются нежизнеспособными;

– потерянные деньги при разработке на избыточные функции продукта.

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

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

Рис. 1.  Как создается новый продукт

Применяем принципы дизайн-мышления 

Далее расскажем, как мы применяем принципы дизайн-мышления при UX-проектировании у себя в Konig Labs. Схематично процесс дизайн-мышления выглядит так:

Рис. 2. Процесс дизайн мышления

(с) Источник изображения skillbox.ru

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

1 этап: Эмпатия 

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

Здесь мы наблюдаем, вживаемся в роль пользователя, общаемся с ним, выявляем скрытые потребности.

2 этап: Фокусировка

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

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

3 этап: Генерация идей

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

Прежде чем перейти к следующему этапу, стоит рассказать о функциональной карте, 

которую мы используем для отображения общей концепции продукта. В ней удобно структурировать собранную информацию, оценивать объем работ и расставлять приоритеты. Уровень детализации зависит от конкретного продукта и может содержать Use Cases, User Stories, схему архитектурного решения, Road Map и пр. 

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

Рис. 3. Пример функциональной карты

4 этап: Прототипирование

Лучше 1 раз увидеть, чем 100 раз услышать. Наглядная демонстрация концепции всегда даст лучшие результаты, нежели объемные презентации и документация с описанием концепции. 

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

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

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

Преимущества прототипирования 

Сейчас может возникнуть вопрос: ведь есть же MVP (minimal viable product) и PoC (proof of concept), зачем нам прототипы? Если сравнить сроки и цены на разработку дизайна прототипа и разработку MVP, ответ будет очевиден. 

У прототипирования есть определенные преимущества:

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

– поможет собрать обратную связь с целевой аудитории и вовремя обнаружить слабые места реализации, исправить которые на стадии проектирования UX намного (!) дешевле, чем на стадии разработки проекта, где уже задействован backend/frontend и прочие;

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

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

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

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

5 этап: Юзабилити-тестирование

На этом этапе мы, наконец, переходим к проверке гипотезы и оценке UX-дизайна продукта его целевой аудиторией. Здесь мы отдаем предпочтение коридорным и качественным методам тестирования: 

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

– качественное тестирование – Customer Discovery, глубокое интервью целевой аудитории продукта на основе Hi-Fidelity прототипа. При необходимости мы помогаем составить вопросы для Customer Discovery и провести его. 

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

Резюмируем

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

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

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

Пример применения подхода в действии можно посмотреть в кейсе  “Воркшоп: от идеи до MVP”. 

Начинаем с требований

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

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

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

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

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

Про выбор архитектуры

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

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

Монолитное решение

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

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

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

Микросервисы

Архитектура, построенная на основе микросервисов – подход, набравший огромную популярность последние лет десять. Весьма распространен в больших проектах с долгим жизненным циклом, когда разработкой занимается несколько команд, каждая из которых отвечает за свои несколько микросервисов. В нашем блоге уже была статья про микросервисы, если интересно вникнуть в детали, читайте здесь: Микросервисы и CQRS: оптимизируем затраты на продукт.

Среди явных плюсов: система разбита на модули, каждый из которых поддерживается определенной командой разработки, независимые публикации отдельно взятых микросервисов (допустим, в системе развернуто два микросервиса A и B, мы можем обновить микросервис B, не затронув при этом микросервис A). В то же время, приходится мириться с определенными ограничениями и иметь в виду, например, что для качественной разработки требуется высокая квалификация специалистов. Плюс ко всему, не стоит забывать и о том, что, несмотря на кажущуюся гибкость в разделении бизнес-процессов на так называемые ограниченные контексты, стоит обязательно позаботиться о системе логирования и мониторинга (о записи действий приложения в специальный файл и о сборе, хранении метрик по инфраструктуре приложения). Более того, микросервисы должны уметь общаться друг с другом – реализуется это посредством различных протоколов, таких как http, amqp и других. Т.е., в отличие от монолита, здесь дополнительно нужно продумать и реализовать API.

Serverless

Serverless – данный подход стал применяться сравнительно недавно (последние несколько лет). Его суть в том, что облачный провайдер (по примеру AWS, Azure и др.) предлагает воспользоваться т. н. бессерверными вычислениями – пользователям теперь не надо заботиться о конфигурировании и поддержке сервера – за вас все делает провайдер (сколько ресурсов потребуется – столько провайдер и предоставит). 

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

С другой стороны, есть палка о двух концах – это управление бюджетом. Провайдер предлагает определенные расценки за использование ресурсов, которые можно посчитать в калькуляторе на сайте. Вот только есть нюанс динамически выделяемых ресурсов – к этому вопросу стоит относиться крайне внимательно – об этом будет рассказано более подробно ниже. Так что советуем не закрывать статью, вдруг дальше будет написано, где находится Янтарная комната… 🙂

Наши мысли

Итак, что мы имеем? Монолит как самый популярный вариант, микросервисы, как пример слабо связанной архитектуры и serverless – эдакий многообещающий вариант построения приложений. Ах, да, чуть не забыли – команду backend-разработчиков из двух человек 🙂

Посовещавшись, пришли к выводу, что микросервисы мы отметаем по причине того, что бизнес-модель не является сложной (даже если забегать вперед с возможными дополнениями) в связи с четко поставленными требованиями к конечному продукту для пользователей. Да, зарекаться не стоит, но взвесив все “за” и “против” решили оставить для более детального рассмотрения два варианта: монолитное решение и serverless.

Использование монолита и serverless: детально

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

Рис. 3. Сервисы AWS, необходимые в backend-части

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

Монолитное решение

Инфраструктурный вопрос

Рис. 4. Предложенный вариант архитектуры backend’а, построенной на базе монолита

Из схемы на рис. 4 видно, что в системе есть мобильный клиент. Далее из мобильного приложения отправляется запрос в облачную инфраструктуру AWS, а конкретно,в виртуальную машину Ec2 instance. Запрос первым делом попадает на сервер nginx, который отвечает за перенаправление запроса в наше приложение. Что собой представляет приложение? 

Это приложение, написанное на Python, со всеми необходимыми нам endpoint’ами, бизнес-логикой и т.д., запущенное и работающее в Docker-контейнере. Все остальные необходимые сервисы – это просто компоненты, созданные однажды. Хранилище файлов можно удобным образом выделить в S3. В качестве сервера БД выступает RDS (Relational Database Service). Так как в системе предусмотрена отправка email-уведомлений, то можно использовать либо Sendgrid, как на схеме, либо AWS SES (Simple Email Service). 

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

Оценка трудозатрат на разработку (с учетом на одного разработчика)

Рис. 5. Трудозатраты на разработку монолитного решения

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

Затраты на хостинг

* Исходим из расчета на 1000 активных пользователей системы

Рис. 6. Затраты на хостинг

Итого: ~ 265$ / месяц

Плюсы

1. Традиционная кодовая база. Можем сменить хоста в любой момент и практически ничего менять не придется
2. Упрощенная схема инфраструктуры (общий сервер почти для всего, если не используем выделенные сегменты инфраструктуры)
3. Ec2 запущен в режиме 24/7, поэтому нет проблемы «холодного старта»
4. Довольно предсказуемая ценовая политика, что весьма важно!

Минусы

1. Повышенная ответственность со стороны разработки: настройка веб-сервера nginx, настройка логирования, настройка мониторинга сервисов приложения. Плюс необходима соответствующая квалификация разработчиков.
2. Масштабирование. Нет гарантии, что однажды не упремся в пороговое значение.  Для горизонтального масштабирования необходима настройка, что само по себе непросто (стоимость будет увеличиваться в разы).
3. Если захотелось бесплатно поднять БД, то придется настроить бэкапы и мониторинг самостоятельно. Это сложнее, чем просто «выставить галочку» в RDS «мне нужны бэкапы каждый день в 24:00», а значит и стоимость работы все равно будет недешевой. 
4. При изменении чего-либо в конфигурации сервера не всегда получается понять, что пошло не так
5. Авторизацию в серверной части, например, придется реализовывать самостоятельно

Serverless

Инфраструктурный вопрос

Рис. 7. Архитектура serverless backend’а приложения

В данном случае система выглядит немного интересней 🙂 

Нет привычных nginx’а, Docker’а, вместо них появились какие-то Lambda с нумерацией от 1 до N, Step Function, Cognito… На самом деле все не очень сложно. Если вспомнить, что serverless тесно связано с понятием FaaS, то можно увидеть, что вместо единого API у нас получились разрозненные lambda-функции, каждая из которых отвечает за свой endpoint. Например, чтобы создать пользователя в системе (выполнить POST-запрос /users) мы вызываем определенную lambda-функцию, задача которой создавать пользователей – ничего более!

Тот блок, который помечен как Step Function – долгая задача, выполняющаяся асинхронно (дело в том, что мы не можем блокировать выполнение http-запроса до момента получения результата, потому как алгоритм нахождения ошибок может выполняться десятки секунд, а пользователь не очень хочет видеть заблокированный экран приложения).

Cognito – мощный сервис авторизации пользователей в системе.

Оценка трудозатрат на разработку (с учетом одного разработчика)

Рис. 8. Трудозатраты на разработку

Чуть позже сравним 🙂

Затраты на хостинг

* Исходим из расчета на 1000 активных пользователей системы

Рис. 9. Затраты на хостинг – serverless

Итого: ~ 250$ / месяц

Плюсы

1. Подход развертывания конфигурации через template.yaml, который, имеет очевидные достоинства в виде четко структурированного файла с описанием AWS инфраструктуры + любые изменения отслеживаются Git’ом (можно выявить проблемы, связанные с изменением конфигурации) + хорошо документировано на официальном сайте.
2. Lambda-функции являются изолированными, удобно тестируются, для каждой из них создана своя группа для мониторинга.
3. Cloud Watch – очень удобный инструмент для сбора логов и мониторинга сервисов AWS. Для Python есть мощная библиотека boto3, которая позволяет выполнять любые операции с сервисами AWS.
4. Удобный CI/CD (с использованием environment-переменных): dev-stack/prod-stack/etc.
5. Мы не заботимся об обслуживании lambda-функций, мы лишь пишем код и точка. Хотя нет, не точка – еще платим деньги, сколько – не известно – вот такая простая математика, все зависит от ситуации. Тогда почему этот пункт в плюсах?..

Минусы

1. Высокий порог вхождения при отсутствии опыта. 
2. «Холодный старт» у lambda-функций – специфическое ограничение, для нашего проекта некритично.
3. Грамотная настройка IAM-политик и их полное соблюдение требуют соответствующей квалификации специалистов, что есть не всегда.
4. Кодовая база достаточно плотно завязана на AWS-провайдере.
5. Зачастую, невозможно предсказать нагрузку и предотвратить автомасштабирование (пример – черная пятница), что ведет к непредсказуемым затратам.

Подведение итогов

Рис. 10. Сравнение стоимостей

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

• Заказчик имеет положительный опыт разработки с использованием инфраструктуры AWS  и настаивает на serverless;
• решение выглядит масштабируемым, т. е. со стороны разработки «практически» не потребуется ничего предпринимать с ростом нагрузки. Те затраты, которые понес заказчик в начале, с лихвой окупятся при масштабировании. А это значительный плюс по сравнению с монолитным решением;
• SAM – об этом будет рассказано более подробно в следующей в статье;
• Со стороны команды разработки, действительно хотелось опробовать современный подход в разработке, поэтому остановились на serverless 🙂

Плохая новость №1

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

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

Плохая новость №2

Есть такой забавный подход к разработке ПО — условно можно назвать «подход Звезда» — когда на работу берут мощного опытного парня, ставят его в центр, а вокруг образуется звезда из кодеров. Уже не разработчиков — а именно кодеров. Тимлид / Архитектор генерит UML диаграммы с детализацией вплоть до конкретных классов и интерфейсов — а кодеры бездумно реализуют его концепцию. Кодеру вообще не надо думать — за него думает Архитектор. Более того — кодер НИКОГДА и не научится думать с таким подходом. А если даже и умел когда-то думать — то со временем разучится.

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

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

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

Плохая новость №3

Есть ещё так называемые Архитекторы-Астронавты. Любители накручивать абстракции на абстракции, намазывать сложность поверх сложности, и так далее. Очень хорошо их описал Джоэль Спольски ещё в 2001-м году. Ну, действительно, вы же взяли очень умного парня на фуллтайм. Надо же ему чем-то заняться… не код же писать, в самом деле. Вот он и ходит туда-сюда, задумчивый. Продумывает очередную гениальную идею реализации стандартной, в общем-то, функциональности новым, революционным методом. Очень сложным, разумеется. Он же не дурак, чтобы делать просто. И это — третья плохая новость. Такой человек не просто будет бесполезно жрать огромную зарплату — он ещё и вреда нанесет столько, что потом с двумя бригадами ассенизаторов не разгребешь.

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

Ищем решение

А что же делать? — спросит удивлённый читатель.

На это есть два ответа: простой и сложный. Простой — брать на вооружение подход «Звезда», но делать это осознанно. Понимая, что микросервисы могут принести в дальней перспективе множество проблем. Понимая, что вы делаете своего Архитектора узким местом, бутылочным горлышком, повышая Bus Factor. Понимая, что вы низводите своих разработчиков до уровня кодеров, и им это не очень-то понравится. Понимая, что проблема воспитания кадров встанет ещё сильнее, и подходить к её решению придётся очень серьёзно.

Просто, не правда ли? 🙂

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

Принять задачу – не значит понять

Наверняка многим знакома ситуация, когда объясняешь задачу — не так важно, коллеге или подчинённому. Скажем более общо: сотруднику.

Так вот — объясняешь задачу. Тебе она предельно понятна, и вроде объяснил хорошо. И контекст передал. И все относящиеся к этому письма переслал. И ссылки скинул.

И вот — сидишь, занимаешься уже совсем другими делами. А тут он приходит — я, говорит, не понял, у меня вопросы.

Отвечаешь.

Снова приходит. Снова вопросы.

Отвечаешь.

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

Или наоборот.

Скинул всю инфу, написал инструкцию, подошёл — задавай, мол, вопросы.

Нет у человека вопросов.

Точно нет?

Точно нет.

Прям всё понятно?

Да, предельно понятно.

Ну, окей, делай.

Отходишь с некоторым сомнением в душе.

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

Само собой, тебя бомбит — какого, мол, чёрта ты не уточнил, друг ты мой ситный? Что мне теперь с этим результатом, мать его через три прогиба, делать??

Разводит руками.

Или вот, например, — задачу передал, и вроде всё обсудили, и вопросы были заданы.

Приходишь через оговоренное время — а он сидит, чем-то другим занимается.

Почему?? — спрашиваешь.

Тут возможны два варианта:

• Или он задачу передал какому-то другому Васе, а когда тот её сделает — чёрт не знает. Надо идти, уточнять у Васи.
• Или на него упало ещё стопицот других задач, и он банально не успевает. Так-то, по-честному, — может быть, и вообще забыл. Но говорит, что не успевает.

Что с этим всем делать

В общем, кто в курсе за DISC, — уже сообразили, что это были, соответственно, Красный, Синий, Жёлтый и Зелёный.

Каждому надо ставить задачу по-разному, и контролировать тоже по-разному.

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

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

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

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

Нам ведь с ними, блин, работать.

Подобрать оптимальное решение

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

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

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

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

О ценности нашего сотрудничества мы побеседовали с руководителем компании Ювелирам.рф, Андреем Титовым. 

• Какие цели Вы ставили перед собой на старте нашего сотрудничества?

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

• Рассматривали ли Вы ещё кого-то для консультации и сопровождения разработки ИТ-продукта? Если да, то как искали подрядчика, как принимали решение?

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

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

• Можете ли Вы описать, какую ценность в рамках проекта у меня получилось Вам дать?

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

• Как Вы теперь представляете ситуацию, если бы Вы делали проект самостоятельно? Какие риски могли бы возникнуть?

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

• Что Вам понравилось больше всего в рамках сотрудничества со мной? Что можно было бы улучшить в будущем и на что обратить внимание?

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

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

Заключение

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

То есть, в первую очередь, таким клиентам нужна услуга консультации, помогающая разобраться, что к чему в сфере ИТ, как правильно оценить свою идею ИТ-продукта, составить грамотное ТЗ либо вообще работать без ТЗ, какую команду подобрать для реализации проекта, а какую для продукта или MVP, как настроить менеджмент, контроль качества, DevOps  и т.д.

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

Пример шаблона MVP

В таблице приведен пример описания MVP системы мониторинга распределенной системы центров обработки данных, одним из элементов которой является RPA-технология (чат-бот) для оптимизации определенных процессов, связанных с администрированием оборудования.

• User Story Mapping – создание карты пользовательских историй. 

Этот этап позволяет правильно определить объем MVP для оптимального использования средств. На данном этапе результаты проделанной работы – пользовательские истории, опережающие индикаторы, описанный процесс – сводятся воедино в карте пользовательских историй.    В данном примере на верхнем уровне (в блоках голубого цвета) находятся опережающие индикаторы, на которые новое решение должно влиять, уровнем ниже (в желтых блоках) – бизнес-процесс, в котором работают пользователи, разбитый на шаги, а ниже – расписаны минимальные решения, которые могут повлиять на каждую метрику в рамках каждого шага процесса.

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

• Запустить пилот и отслеживать метрики. 

На этом этапе минимальный жизнеспособный продукт вводится в тестовую эксплуатацию и предоставляется первым пользователям, отслеживается, как работы, и исправляются обнаруженные дефекты. После того, как пользователи начали работать с системой (ИТ-решением, продуктом), и в системе появились данные, начинается работа с аналитикой – опережающими показателями.    “Линейка”, составленная на этапе формулировки гипотезы и MVP, предоставляет четкий и понятный инструмент для калибровки действий относительно дальнейшего развития продукта. Также, на этом этапе снимается и фиксируется обратная связь от пользователей.    В случае, если гипотеза подтверждена, после этого этапа повторяются подобные циклы работ, связанные с расширением функционала. Каждое последующее улучшение ИТ-решения проходит через цикл “Разработать – Оценить результат – Сделать Выводы”. Такой итерационный подход позволяет установить факты и соотнести свои предположения с действительностью. Поэтапное внедрение RPA-инноваций с помощью MVP позволяет постепенно уменьшать число операций, выполняемых человеком, тем самым снижать вероятность ошибки и повышать надежность решения. 

Заключение 

Инновации являются одним из ключевых факторов развития как частного бизнеса, так общества и государства в целом. Ранее компании концентрировались на повышении качества продукции и сервиса, вели ценовую конкуренцию. Современная действительность требует от бизнеса системного подхода к инновациям.    Корпорации уверенно осваивают и внедряют инновации. Для этого у них есть ресурсы и инфраструктура: собственные фонды и акселераторы, мероприятия, корпоративные школы, командировки во всея святых инноваций – Кремниевую долину.  Как среднему бизнесу угнаться за передовиками инноваций и сохранить свою релевантность на рынке? Для тех, кто не в состоянии самостоятельно осилить данную инициативу предлагается начать с проведения форсайт-сессий или развивать партнерские связи в части разработки и управления инновационными ИТ-продуктами.    Консалтинг и проверка зарождающихся инициатив на прочность – один из способов решения этой задачи. Структурировать идею нового технологичного продукта или сервиса можно на воркшопе “Проработка идеи ИТ-продукта и запуск валидации с помощью MVP”.

Back to MVP

Впрочем, вернёмся к нашим баранам.

Для начала давайте в двух словах определимся, что же такое этот самый MVP.

Minimal Viable Product – это тот самый минимум, который можно дать рынку “на пощупать”, собрать обратную связь и определиться: развивать ли его дальше, или положить на полку до лучших времён. Соответственно, прежде, чем разрабатывать MVP, нам необходимо определиться – что же будет тем самым минимумом, которого будет достаточно для прощупывания рынка.

И вот здесь-то и появляется почва для непонимания и путаницы.

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

Давайте посмотрим, как это обычно происходит в парадигме проектного подхода, и сравним с продуктовым подходом.

Проектная парадигма

Маркетолог, на основании исследования рынка США, обнаружил потребность российского рынка в определённом продукте. В США такой продукт уже есть, там есть фичи А, Б, В, Г и Д, спрос растёт, появляются конкуренты. Эти фичи решают определённые проблемы пользователей – и исследование российского рынка показывает, что те же проблемы есть у российских пользователей, и решаются они так же плохо и неудобно, как это было в США до выхода нового продукта.

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

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

И всё же. И всё же. Уважаемые менеджеры проектов, положа руку на сердце, разве редко бывает такое, что заказчик, получив готовый продукт, искренне ему удивляется? Да, он где-то сам недодумал. Да, он где-то сам недопонял, подписывая мокапы, дизайн и ТЗ. Это нормально для человека – не до конца понимать, как будет выглядеть и работать конечный результат.

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

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

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

Но представим, что та же проектная команда остаётся развивать продукт. Что же получится?

Маркетолог проводит очередное исследование рынка и предлагает включить в продукт фичу Е. Команда уточняет требования, составляет ТЗ, устанавливает тройственное ограничение – и выкатывает новую фичу через месяц. Работают аналитики, работают технические писатели, работает менеджер проекта, составляя диаграммы Гантта или критического пути, работают разработчики, тестировщики, внедренцы. Если потом оказывается, что фича неэффективна или даже вредна – можно завести проект по её удалению.

В целом этот оверхед не очевиден никому – ни маркетологу, ни менеджеру проекта, ни членам команды. Все при деле, все эффективно работают. Со временем даже документирование можно свести к минимуму. А оверхед всё равно есть.

Где? Давайте попробуем найти в сравнении.

Продуктовая парадигма

В продуктовом подходе всё происходит совсем иначе. Повторюсь, не так важно, Scrum ли это или другой фреймворк.

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

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

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

Ещё один немаловажный момент – разработка продукта заканчивается только со смертью продукта. В этом ключевое отличие от проектного подхода, который всегда конечен. Покуда продукт живёт, им активно пользуются – будут возникать запросы на изменение функциональности и добавление новых фичей. И здесь на подиум выходит Minimal Marketable Feature (минимально полезная функциональность).

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

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

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

Ещё одна особенность MVP подхода – умение делать буквально из говна и палок (shit and bricks). Это звучит страшно для любого менеджера проекта или архитектора – и прекрасно для предпринимателя. Если неизвестно, “выстрелит” ли новая идея – незачем вкладывать в неё сотни тысяч долларов и надеяться на лучшее. Лучше сделать за несколько тысяч что-то, чем можно пользоваться, и привлекать инвестиции на уже существующую пользовательскую базу.

Можно поспорить, что разработка MVP – лишь небольшой эпизод жизненного цикла продукта. Что MVP можно разрабатывать в рамках проектного подхода, и потом обогащать его MMF в рамках всё того же проектного подхода. Да, так вполне можно работать. Это существенно увеличит цикл обратной связи и не даст ситуативно пользоваться решениями “на коленке”. Это изолирует команду разработки от бизнес-ценности создаваемого продукта. Но так вполне можно работать – и так довольно часто работают. Дальше я постараюсь показать, почему так происходит, и почему это не совсем верно.

Почувствуйте разницу

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

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

При этом ключевой проблемой в получении этой выгоды является способность снимать обратную связь. Команда должна понимать, на какие бизнес-метрики ориентируется MVP или MMF. Какую информацию – системную, пользовательскую и иную – необходимо снимать, мониторить, контролировать. К сожалению, часто можно наблюдать картину, когда команда занимается только разработкой по ТЗ. Обслуживают продукт другие люди, они же собирают кучу какой-то информации, третьи люди эту информацию анализируют, а четвёртые думают, что с этим делать. Максимум, чем занимается в этом смысле команда – даёт возможность сбора метрик, подключая логи и другие инструменты, и делает дашборды для администраторов и аналитиков. В результате получается, что функциональность системы создают люди, не понимающие бизнес-смысла того, что они создают.

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

Подытоживая – хочу отметить, что продуктовый подход НЕ ЛУЧШЕ проектного. Каждый лучше в рамках своей применимости. 

Штука в том, что очень часто – вот прямо ОЧЕНЬ ЧАСТО – разработку MVP ведут в проектной парадигме. И получают при этом результаты. Хороший менеджер и хорошая команда – залог попадания в тройственное ограничение.

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

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