Проектирование архитектуры для SaaS сервисов, интернет-магазинов

Проектирование архитектуры, создание технического решение, подбор компонентов и сервисов

15%стоимости разработки продукта составляет проектирование
9ключевых артефактов проектирования используем
200часов команды на средний проект
Подробнее
Награды 6 наград 4 номинации в UI/UX
рейтинги Профиль Evergreen — Clutch Рейтинг Evergreen — CMSMagazine Профиль Evergreen — Behance Все Все

Суть проектирования как услуги

Чтобы начать разработку, нужно сперва подготовить проектную документацию. В случае с простыми проектами, используется прототип, краткая функциональная спецификация и user stories. В большинстве случаев для решений, создаваемых на базе готовых систем и не нужно много проектной документации, потому что уже есть аналоги и в принципе понятно что нужно сделать и как оно должно работать, система, которая ложится в основу (cms, crm, lms, erp и т.п.) уже содержит набор базовых функций и продумывать все нюансы их работы не нужно.

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

Давайте не будем делать проектирование?

  • Зачем тратить время на проектирование, если есть SCRUM (AGILE)?

    “Не тратя время мы быстренько начнем разработку” или “Эрик Рис в книге Lean Startup говорит что планировать не нужно, нужно быстрее делать продукт”. – Такое нам иногда говорят клиенты.


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


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


    Эта аналогия справедлива и для ИТ. Есть простые проекты, где всё очевидно и которые можно “просто сделать” имея достаточно опыта реализации подобных решений, но действительно интересные и необычные проекты требуют внимательного подхода и глубокой проработки до того как будет написана первая строчка кода. Более того это никак не противоречит итерационным и гибким методологиям разработки - SCRUM, Lean Startup и другие известные методики никак не предполагают отказ от проектирования. Скорее речь идет о том что нужно отказаться от избыточного проектирования там где это возможно и за счет этого сэкономить бюджет и время. Но попытка отказаться от проектирования вовсе и начать реализовывать непонятное и непродуманное решение может обернуться гораздо большими тратами.

  • Нам нужно быстрее начать, у нас нет на это времени!

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


    Реальный пример из жизни:
    Компания F вложила около $120 тысяч в разработку решения по автоматизации процессов маркетинга и продаж на базе CRM системы именитого международного вендора. Разработка стартовала под лозунгом “нам нужно это за пол года” и на проект времени не нашлось. В итоге уже ближе к запуску системы выяснилось что система очень медленно работает, неудобна в обслуживании и создает больше проблем чем решает. В итоге систему с горем пополам внедрили в абонентский отдел, проект закрыли и начали разработку новой системы. На этот раз решили писать свою с нуля. Но за это время поменялась экономическая ситуация и руководство поставило задачу - написать своё дешево и за 3 месяца. Конечно в таких условиях заниматься проектированием времени уже не было и мобилизовав внутренних программистов компания сразу приступила к разработке. Как вы думаете, получила ли она решение своих проблем и во сколько это в итоге обошлось?

15% стоимости

– доля проектирования в общей стоимости продукта

Проектирование направлено на уменьшение неопределенности

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

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

“Я не хочу заплатить за проект чтобы узнать, что реализация моей идеи стоит в 10 раз больше, чем я думал!”

Понимаем. Но вы же наверняка знаете что 70% ИТ проектов в принципе не запускаются и замораживаются в процессе? Проектирование избавляет вас от дорогих иллюзий. Хорошая новость в том, что даже узнав о том что проект стоит дороже или является более технически сложным, чем вы изначально думали, ничто не заставляет вас его прекращать - всегда можно упростить, отказаться от сложных функций и проверить гипотезу на минимальной версии, как и предлагает Эрик Райс в Lean Startup, можно найти инвестиции или попробовать поэтапный запуск. Здесь решать вам какую степень риска и неопределенности вы хотите принять. Если вы готовы к повышенному риску - тогда минимизируйте затраты на проектирование и ищите того кто обладает схожим опытом, чтобы хоть как-то обезопасить проект от провала. 

Почему вам всё-таки нужно проектировать?

  • Всё равно проект не закрывает 100% вопросов, зачем его тогда делать?

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

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

    Если это как-то резонирует с вашими мыслями - это значит что вы видели плохие проекты и не видели хорошие. Скажите, представляете ли вы предельно чисто и ясно в каждой детали реализацию вашей идеи? 90% людей на этот вопрос скажут “да, представляю, но есть нюансы которые мне не до конца понятны и требуют уточнения” (10% скажут “нет, я понимаю в общих чертах, мне не помешает ваша помощь, ребята, чтобы я лучше понял как это должно работать). Если вы относитесь к первой группе, то скажите, сталкивались ли вы когда-либо с тем, что в процессе выяснения деталей, вы развиваете свою идею вплоть до того что в итоге решаете сделать принципиально иным способом чем вам казалось правильным изначально, при этом вы очень довольны результатом?


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


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


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

  • Покажите, что надо написать и как, дайте шаблон, а мы сами заполним!

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

    Если вы всё же хотите рискнуть, используйте наш Чек-лист ТЗ

Артефакты проектирования Evergreen

slogan-img

Листайте, чтобы увидеть остальные причины

  1. Общая концепция проекта включает в себя видение проекта, анализ конкурентной среды, бизнес-потребность и бизнес-идею проекта.
  2. Границы продукта определяют собой то что должно в итоге получиться и что мы не планируем пересекать (если мы пересечем эти границы, это будет уже другой продукт).
  3. Примерный расчет рентабельности и выбор метода реализации на основании возможной окупаемости.
  4. UI прототип и детальные user stories создаем для того чтобы описать все детали взаимодействия пользователей с нашей системой.
  5. Анализ и описание бизнес-процессов (БП) проектируемой системы. Обычно уже есть у наших клиентов в каком-то виде, мы стараемся получить их в качестве вводных и начать разбирать их на сущности и подпроцессы. В итоге анализа создаем следующие документы, в зависимости от проекта:
    • user stories верхнего уровня абстракции
    • use cases для описания сценариев взаимодействия между несколькими системами/персонами/сущностями
    • user flow - сценарии работы пользователя с системой (объединяют в себе ЮС и кейсы, показывают полный процесс от начала до конца)
  6. Общая техническая концепция проекта
    • Выбор типа архитектуры (монолитная или компонентная)
    • Декомпозиция монолитной архитектуры на компоненты (Например: загрузка файлов, отправка почты, работа с документами, чат).
    • Общая компонентная техническая схема проекта. Взаимодействие компонентов между собой. (Например, загружать можно и из галереи и из чата)
    • Нефункциональные требования к системе: безопасность, доступность (браузеры и ОС), масштабируемость, производительность (нагрузки сервера), ограничения (бизнес правила и политики корпорации), пр.
  7. Детализированная техническая схема компонентов
    • Описание необходимых сервисов для работы компонента. R&D и подбор совместимых сервисов. (Пример для загрузки файлов необходим сервис APi через который будут отправлять и получать файлы).
    • Разбивка на микросервисы
    • Схема взаимодействия сервисов/микросервисов
  8. Схема стека технологий
    • Подбор стека software реализации под каждый компонент. Проведение R&D совместимости.
    • Решение tech cases.
    • Подбор стека hardware реализации если таковая имеет место
    • Подбор рекомендаций по настройке и размещению проекта на продакшене
    • Анализ совместимости UI интерфейсов и сервисов
  9. Проектирование этапов разработки и внедрения проекта: схема этапов разработки разбита по этапам и с группировкой по компонентам/сервисам.
  10. Организация процесса и команда необходимая для реализации проекта
  1. Общая концепция проекта включает в себя видение проекта, анализ конкурентной среды, бизнес-потребность и бизнес-идею проекта.
  2. Границы продукта определяют собой то что должно в итоге получиться и что мы не планируем пересекать (если мы пересечем эти границы, это будет уже другой продукт).
  3. Примерный расчет рентабельности и выбор метода реализации на основании возможной окупаемости.
  4. UI прототип и детальные user stories создаем для того чтобы описать все детали взаимодействия пользователей с нашей системой.
  5. Анализ и описание бизнес-процессов (БП) проектируемой системы. Обычно уже есть у наших клиентов в каком-то виде, мы стараемся получить их в качестве вводных и начать разбирать их на сущности и подпроцессы. В итоге анализа создаем следующие документы, в зависимости от проекта:
    • user stories верхнего уровня абстракции
    • use cases для описания сценариев взаимодействия между несколькими системами/персонами/сущностями
    • user flow - сценарии работы пользователя с системой (объединяют в себе ЮС и кейсы, показывают полный процесс от начала до конца)
  6. Общая техническая концепция проекта
    • Выбор типа архитектуры (монолитная или компонентная)
    • Декомпозиция монолитной архитектуры на компоненты (Например: загрузка файлов, отправка почты, работа с документами, чат).
    • Общая компонентная техническая схема проекта. Взаимодействие компонентов между собой. (Например, загружать можно и из галереи и из чата)
    • Нефункциональные требования к системе: безопасность, доступность (браузеры и ОС), масштабируемость, производительность (нагрузки сервера), ограничения (бизнес правила и политики корпорации), пр.
  7. Детализированная техническая схема компонентов
    • Описание необходимых сервисов для работы компонента. R&D и подбор совместимых сервисов. (Пример для загрузки файлов необходим сервис APi через который будут отправлять и получать файлы).
    • Разбивка на микросервисы
    • Схема взаимодействия сервисов/микросервисов
  8. Схема стека технологий
    • Подбор стека software реализации под каждый компонент. Проведение R&D совместимости.
    • Решение tech cases.
    • Подбор стека hardware реализации если таковая имеет место
    • Подбор рекомендаций по настройке и размещению проекта на продакшене
    • Анализ совместимости UI интерфейсов и сервисов
  9. Проектирование этапов разработки и внедрения проекта: схема этапов разработки разбита по этапам и с группировкой по компонентам/сервисам.
  10. Организация процесса и команда необходимая для реализации проекта

Пример: страховая компания, интеграция коробочной CRM в отдел продаж

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

Артефакты проектирования:

  1. Новая воронка продаж
  2. Поля для карточки сделки, контакта, организации
  3. Процесс продажи каждого продукта (user flow с участием менеджера + всех связанных систем, база для детальной схемы интеграции)
  4. Схема интеграции между промежуточным ПО, amoCRM, сайт
  5. Требования к разработке (API всех систем и связи между ними конкретными методами)

Результат проектирования:

  • Есть описание (техническое и пользовательское) всех алгоритмов систем. Тех. требования к интеграции этим системам.
  • Коробка CRM настроена для тестовой интеграции и опытно-контрольного использования (перед финальной интеграцией с продакшн-средами всех систем).

Следующий этап после проектирования - опытно-контрольное тестирование процесса продажи одного продукта с участием CRM + все связанные системы (от поступления заявки с сайта до печати договора)

Пример: сеть ресторанов - система автоматизации БП операционной деятельности ресторана

— Делается MVP-версия для обкатки идеи, далее планируется расширить продукт до облачного решения по подписке SaaS (software as a service)

Артефакты проектирования:

  1. Анализ БП ресторана как основы автоматизации БП любого ресторана. Итог анализа:
    • юзер сториз верхнего уровня абстракции
    • use cases для описания сценариев взаимодействия между несколькими системами/персонами/сущностями
    • user flow - сценарии работы пользователя с системой
  2. Информационная архитектура с сущностями и полями
  3. Общая концепция проекта
  4. Техническая архитектура

Результат работы: Есть описание (техническое и пользовательское) всех алгоритмов систем. Технические требования к интеграции этим системам.

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

Вы хотите уверенности при разработке?

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

Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.