Идеальный сценарий разработки IT-решений для корпораций
Adeptum Digital Production делится советами и нюансами в разработке IT-систем для руководителей направлений «Индустрии 4.0»![Идеальный сценарий разработки IT-решений для корпораций](https://pics.rbc.ru/v2_companies_s3/resized/960xH/media/company_press_release_image/898468f2-049a-40c2-a073-8fd1aba7e3a5.jpg)
![Антон Клименков](https://pics.rbc.ru/v2_companies_s3/resized/200xH/media/interviewee_photo/fa0cfad0-53da-433e-840a-588db96c2a9e.jpg)
Имеет опыт разработки сложных цифровых продуктов для ведущих корпораций СНГ в нефтегазе, финтехе, логистике. В портфолио проекты для «Газпромнефть», «МТС», «Газпромбанк», «Лента», QIWI, «Сбер». Успешно запускал IT-стартапы на рынках России, Европы и США. Экспертиза: построение продуктовых команд, IT-консалтинг, разработка и интеграция комплексных высоконагруженных систем, горизонтальные организации.
Для выхода на новый уровень автоматизации недостаточно просто оцифровать какие-то процессы и ждать технологического прорыва. Необходим комплексный подход к разработке и внедрению информационных технологий внутри корпорации.
IT-консалтинг: старт с правильного исследования
Без полномасштабного исследования невозможно сделать масштабную IT-систему. Все участники процесса от согласующих до разработчиков должны иметь полную аналитику за счет исследований рынка, возможностей корпорации и команды разработки. На этом этапе участвуют ЛПР, ЕОЛы. Если команды не провели исследования и не нашли основные точки, проблемы, решения — высока вероятность сделать то, чем никто не будет пользоваться.
Определение цели: внутренний или внешний продукт
Определили зачем корпорации продукт и должен ли он работать на внешнюю сторону потребителей:
Если продукт внутренний, то портрет пользователей ясен — это сотрудники корпорации. Осталось разобраться с их потребностями и проанализировать среду:
- кто основные пользователи: должности и отделы?
- какие задачи решает продукт?
- какие задачи не решает продукт?
- сильные и слабые стороны;
- сравниваем: существующие решения внутри компании и ваш продукт.
Например, если вы разрабатываете инструмент для упрощения рабочих процессов на месторождении, обязательно проконсультируйтесь с сотрудниками, исследуйте процессы, соберите обратную связь, и только после начинайте думать над решением, как это сделали мы.
Если внешний, то тут нужна статистика и аналитика рынка. Важно понять запросы и страхи потенциальных пользователей:
- чего сейчас не хватает рынку?
- что выпустили коллеги и как?
- какая нужна функциональность?
- от каких продуктов люди устали?
Кроме того, следите за изменениями на рынке и поведением пользователей, чтобы продукт оставался актуальным и соответствовал ожиданиям клиентов.
IT-консалтинг на первом этапе — важнейший шаг для создания действительно нужного продукта. За счет этих процессов вы добьетесь не только общего вектора разработки, но и получите системную аналитику по задачам, которые лягут в ТЗ и ФТТ.
Антон Клименков, CEO Adeptum Digital Production.
Спроектировать архитектуру
Это фундаментальный этап разработки серьезного IT-проекта, на котором определяется общая структура и организация будущего решения.
Подробно разберем этот процесс:
- Выбор архитектурного стиля. Начнем с выбора наиболее подходящего архитектурного стиля, который определит основные принципы организации системы. Например, это может быть монолитная архитектура, микросервисы, клиент-серверная архитектура или распределенная архитектура.
- Определение компонентов системы. Систему разбиваем на компоненты, которые выполняют конкретные функции. Это включает в себя определение модулей, сервисов, баз данных, и других элементов, которые будут взаимодействовать между собой.
- Установление принципов коммуникации. Определение способов и механизмов, с помощью которых компоненты системы будут обмениваться данными — вопросы синхронности и асинхронности коммуникаций.
- Разработка базы данных. На этом этапе определяется структура базы данных, выбираются СУБД (системы управления базами данных), проектируются таблицы и связи между ними. Важно учесть требования к производительности и масштабируемости.
- Управление данными и хранение. Определение стратегии управления данными, включая механизмы резервного копирования, восстановления и обеспечения безопасности данных. Также рассматривается вопрос масштабируемости хранилищ данных.
- Система безопасности и авторизации. Проектирование механизмов защиты данных и системы авторизации. Это включает в себя определение прав доступа, шифрования данных, мониторинга и аудита событий.
- Масштабируемость и отказоустойчивость. Разработка архитектуры, способствующей масштабированию системы по мере роста нагрузки. То есть горизонтальное масштабирование, использование облачных сервисов и кластеризацию.
- Управление конфигурациями и развертыванием. Определение методов развертывания продукта на серверах клиента, настройку окружения, управление зависимостями и версиями компонентов.
- Мониторинг и аналитика. Разработка механизмов мониторинга системы, которые позволяют отслеживать производительность, выявлять проблемы и анализировать данные для оптимизации работы системы.
- Документирование архитектуры. Важная часть процесса — создание подробной документации по архитектуре системы. Так команда разработки и поддержки точно и быстро поймет, как работает система.
Системный анализ, UX/UI, интерфейсы
1. Выявление узких мест в процессе. На этом этапе необходимо провести анализ текущих бизнес-процессов и систем, идентифицировать конкретные этапы, которые могут тормозить процесс или вызывать ошибки.
2. Поиск путей решения и автоматизации. После предложить конкретные решения для улучшения бизнес-процессов.
3. Создание макетов и прототипов. Для наглядной демонстрации предлагаемых изменений разработать макеты и прототипы системы, включая конкретные интерфейсы, экранные формы и взаимодействия.
4. Тестирование макетов и прототипов. Провести тестирование созданных макетов и прототипов, акцентируя внимание на конкретных сценариях использования.
5. Решения. На основе результатов анализа и тестирования, важно предложить конкретные решения, такие как изменения в структуре организации, внедрение новых технологий или обучение сотрудников.
6. Документирование. Задокументировать все выявленные проблемы, решения и изменения с указанием конкретных шагов для их реализации.
Разработать ценность, а не софт
Теперь переходим к разработке «сердца» продукта. Этот этап аналогичен строительству стен и инженерии здания. Мы создаем код и компоненты, которые обеспечивают функциональность, необходимую для бизнес-процессов заказчика.
Разработка продукта для enterprise-клиентов — это намного больше, чем просто создание программного кода. Это сложный и многогранный процесс, ориентированный на достижение ценности для клиента и продуктивное использование гипотез. Каждый спринт = ценность. Этому учит Agile, который мы так любим.
Но не забываем также про привычные требования enterprise-заказчиков:
Важно учитывать стандарты и требования корпоративных структур, работающих, например, по методологии «Водопад». Это классический подход, где каждый этап разработки происходит последовательно и строго определен в начале проекта. Но, например, внутри команды можно спокойно использовать гибкий и мягкий Agile. Чтобы заказчик был уверен в стабильности и надежности продукта, несмотря на гибкость внутренних процессов разработки.
Так что такое ценность в продуктовой разработке? Это момент, когда исполнитель меняет внутренние процессы заказчика, то есть внедряет что-то новое и полезное в бизнес-структуру корпорации, а также оптимизирует часть процессов. За этим заказчик и приходит.
Обучить отделы, протестировать и запустить продукт
Перед внедрением продукта важно провести подготовительные работы: установку оборудования, совместную настройку серверов и сетей, а также настройку систем безопасности. А после, естественно, запустить итоговое тестирование и приемо-сдаточные работы в контуре корпорации.
Дальше, после подготовки инфраструктуры и установки продукта, важно обучить сотрудников компании и создать хорошую систему техподдержки. Мы, например, пишем пользовательские сценарии и документацию для администраторов сервиса. Также готовимся к возможным проблемам и вопросам пользователей, чтобы быстро реагировать и решать проблемы.
После запуска проследите за работой продукта с помощью аналитики и метрик. Если что-то идет не так — меняйте стратегию. То есть, исправляйте ошибки, обновляйте продукт или добавляйте новые функции.
Иногда разработка идет не так, как нам хочется
В этом блоке поговорим про ошибки, которые могут негативно повлиять на разработку IT-продукта.
- Не изучаем организационную культуру заказчика. Каждая корпорация имеет свою культуру. Если в начале не выяснить, какая система там выстроена и не наладить тесный контакт с менеджментом корпорации — будет тяжко.
Ведь любой шаг требует длительного согласования с разными руководителями отделов. Плюс, они не сконцентрированы только на одном процессе — у них широкая зона ответственности. Это тормозит разработку.
Но благодаря Agile и Scrum можно выстроить супер здоровую коммуникацию: организовывать короткие итерации и частые проверки результатов, чтобы быстро получать обратную связь.
Это сокращает цикл согласований и ускоряет разработку, несмотря на изначально громоздкую структуру процессов.
- Не смотрим в перспективу. Не все думают о том, как продукт будет жить и расти. Главное, что «сейчас работает» — а как будет через год, никого не волнует. Это главная ошибка.
- Не работаем с данными. Корпорации — это куча данных. Если не продумать, как с ними работать, то можно попасть в джунгли из байтов и битов, и потом вылазить оттуда будет сложно.
- Не масштабируем и забываем про возможную нагрузку. Продукт, который работает для пятерых, может вдруг сломаться, когда клиентов станет сто тысяч. Масштабируемость — важная вещь.
- Не говорим с продуктовой командой заказчика. Если не разговориться с заказчиком, командой и остальными игроками — будет бардак. Придется несколько раз выстраивать коннект.
- Не даем заказчику подумать самому. Важно не спорить и не настаивать на своем. Со временем заказчик сам придет к тем решениям, которые уже висят в бэклоге и имеют больше плюсов.
Необходимо стараться аргументировано подталкивать заказчика к верным решениям и мощным результатам. Так выстраивается продуктивное долгосрочное сотрудничество.
Подводим итоги
Разработка продукта для корпораций — это не просто кодить и тестить, это еще и думать о корпоративной культуре и правилах безопасности. Выстраивать отношения с бизнес-заказчиком, управлять метриками, помогать искать точки роста и автоматизации, внедрять новые технологии, обучать новой системе и поддерживать заказчика на каждом этапе разработки.
![Идеальный сценарий разработки IT-решений для корпораций](https://s.rbk.ru/v1_companies_s3/media/news_body_images/47b503ff-4f5e-4c7a-ac18-585cdb49ecea.jpg)
Интересное:
Новости отрасли:
Все новости:
Публикация компании
Достижения
Профиль
Контакты
Социальные сети