Для выхода на новый уровень автоматизации недостаточно просто оцифровать какие-то процессы и ждать технологического прорыва. Необходим комплексный подход к разработке и внедрению информационных технологий внутри корпорации.
Без полномасштабного исследования невозможно сделать масштабную IT-систему. Все участники процесса от согласующих до разработчиков должны иметь полную аналитику за счет исследований рынка, возможностей корпорации и команды разработки. На этом этапе участвуют ЛПР, ЕОЛы. Если команды не провели исследования и не нашли основные точки, проблемы, решения — высока вероятность сделать то, чем никто не будет пользоваться.
Определили зачем корпорации продукт и должен ли он работать на внешнюю сторону потребителей:
Если продукт внутренний, то портрет пользователей ясен — это сотрудники корпорации. Осталось разобраться с их потребностями и проанализировать среду:
- кто основные пользователи: должности и отделы?
- какие задачи решает продукт?
- какие задачи не решает продукт?
- сильные и слабые стороны;
- сравниваем: существующие решения внутри компании и ваш продукт.
Например, если вы разрабатываете инструмент для упрощения рабочих процессов на месторождении, обязательно проконсультируйтесь с сотрудниками, исследуйте процессы, соберите обратную связь, и только после начинайте думать над решением, как это сделали мы.
Если внешний, то тут нужна статистика и аналитика рынка. Важно понять запросы и страхи потенциальных пользователей:
- чего сейчас не хватает рынку?
- что выпустили коллеги и как?
- какая нужна функциональность?
- от каких продуктов люди устали?
Кроме того, следите за изменениями на рынке и поведением пользователей, чтобы продукт оставался актуальным и соответствовал ожиданиям клиентов.
«IT-консалтинг на первом этапе — важнейший шаг для создания действительно нужного продукта. За счёт этих процессов вы добьетесь не только общего вектора разработки, но и получите системную аналитику по задачам, которые лягут в ТЗ и ФТТ».
Антон Клименков, CEO Adeptum Digital Production.
Это фундаментальный этап разработки серьёзного IT-проекта, на котором определяется общая структура и организация будущего решения. Подробно разберём этот процесс:
- Выбор архитектурного стиля. Начнём с выбора наиболее подходящего архитектурного стиля, который определит основные принципы организации системы. Например, это может быть монолитная архитектура, микросервисы, клиент-серверная архитектура или распределённая архитектура.
- Определение компонентов системы. Систему разбиваем на компоненты, которые выполняют конкретные функции. Это включает в себя определение модулей, сервисов, баз данных, и других элементов, которые будут взаимодействовать между собой.
- Установление принципов коммуникации. Определение способов и механизмов, с помощью которых компоненты системы будут обмениваться данными — вопросы синхронности и асинхронности коммуникаций.
- Разработка базы данных. На этом этапе определяется структура базы данных, выбираются СУБД (системы управления базами данных), проектируются таблицы и связи между ними. Важно учесть требования к производительности и масштабируемости.
- Управление данными и хранение. Определение стратегии управления данными, включая механизмы резервного копирования, восстановления и обеспечения безопасности данных. Также рассматривается вопрос масштабируемости хранилищ данных.
- Система безопасности и авторизации. Проектирование механизмов защиты данных и системы авторизации. Это включает в себя определение прав доступа, шифрования данных, мониторинга и аудита событий.
- Масштабируемость и отказоустойчивость. Разработка архитектуры, способствующей масштабированию системы по мере роста нагрузки. То есть горизонтальное масштабирование, использование облачных сервисов и кластеризацию.
- Управление конфигурациями и развёртыванием. Определение методов развертывания продукта на серверах клиента, настройку окружения, управление зависимостями и версиями компонентов.
- Мониторинг и аналитика. Разработка механизмов мониторинга системы, которые позволяют отслеживать производительность, выявлять проблемы и анализировать данные для оптимизации работы системы.
- Документирование архитектуры. Важная часть процесса — создание подробной документации по архитектуре системы. Так команда разработки и поддержки точно и быстро поймёт, как работает система.
- Выявление узких мест в процессе. На этом этапе необходимо провести анализ текущих бизнес-процессов и систем, идентифицировать конкретные этапы, которые могут тормозить процесс или вызывать ошибки.
- Поиск путей решения и автоматизации. Для улучшения бизнес-процессов предложить конкретные решения.
- Создание макетов и прототипов. Для наглядной демонстрации предлагаемых изменений разработать макеты и прототипы системы, включая конкретные интерфейсы, экранные формы и взаимодействия.
- Тестирование макетов и прототипов. Провести тестирование созданных макетов и прототипов, акцентируя внимание на конкретных сценариях использования.
- Решения. На основе результатов анализа и тестирования, важно предложить конкретные решения, такие как изменения в структуре организации, внедрение новых технологий или обучение сотрудников.
- Документирование. Задокументировать все выявленные проблемы, решения и изменения с указанием конкретных шагов для их реализации.
Теперь переходим к разработке «сердца» продукта. Этот этап аналогичен строительству стен и инженерии здания. Мы создаём код и компоненты, которые обеспечивают функциональность, необходимую для бизнес-процессов заказчика.
Разработка продукта для enterprise-клиентов — это намного больше, чем просто создание программного кода. Это сложный и многогранный процесс, ориентированный на достижение ценности для клиента и продуктивное использование гипотез. Каждый спринт = ценность. Этому учит Agile, который мы так любим.
Но не забываем также про привычные требования enterprise-заказчиков:
«Важно учитывать стандарты и требования корпоративных структур, работающих например по методологии «Водопад». Это классический подход, где каждый этап разработки происходит последовательно и строго определён в начале проекта. Мы, например, внутри команды спокойно используем гибкий и мягкий Agile. То есть, заказчик должен быть уверен в стабильности и надёжности продукта, несмотря на гибкость внутренних процессов разработки».
«Важно учитывать стандарты и требования корпоративных структур, работающих например по методологии «Водопад». Это классический подход, где каждый этап разработки происходит последовательно и строго определён в начале проекта.
Мы, например, внутри команды спокойно используем гибкий и мягкий Agile. То есть, заказчик должен быть уверен в стабильности и надёжности продукта, несмотря на гибкость внутренних процессов разработки».
Антон Клименков, CEO Adeptum Digital Production.
Так что такое ценность в продуктовой разработке? Это момент, когда исполнитель меняет внутренние процессы заказчика, то есть внедряет что-то новое и полезное в бизнес-структуру корпорации, а также оптимизирует часть процессов. За этим заказчик и приходит.
Перед внедрением продукта важно провести подготовительные работы: установку оборудования, совместную настройку серверов и сетей, а также настройку систем безопасности. А после запускаем итоговое тестирование и приемо сдаточные работы в контуре корпорации.
После подготовки инфраструктуры и установки продукта, важно обучить сотрудников компании и создать хорошую систему техподдержки. Мы, например, пишем пользовательские сценарии и документацию для администраторов сервиса. Также готовимся к возможным проблемам и вопросам пользователей, чтобы быстро реагировать и решать проблемы.
А после запуска следим за работой продукта с помощью аналитики и метрик. Если что-то идёт не так — меняем стратегию. То есть, исправляем ошибки, обновляем продукт или добавляем новые функции.
В этом блоке поговорим про ошибки, которые могут негативно повлиять на разработку IT-продукта.
- Не изучаем организационную культуру заказчика. Каждая корпорация имеет свою культуру. Если в начале не выяснить, какая система там выстроена и не наладить тесный контакт с менеджментом корпорации — будет тяжко.
Ведь любой шаг требует длительного согласования с разными руководителями отделов. Плюс, они не сконцентрированы только на одном процессе — у них широкая зона ответственности. Это тормозит разработку.
Но благодаря Agile и Scrum можно выстраивать супер здоровую коммуникацию: организовывать короткие итерации и частые проверки результатов, чтобы быстро получать обратную связь.
Это сокращает цикл согласований и ускоряет разработку, несмотря на изначально громоздкую структуру процессов.
- Не смотрим в перспективу. Не все думают о том, как продукт будет жить и расти. Главное, что «сейчас работает» — а как будет через год, никого не волнует. Это главная ошибка.
- Не работаем с данными. Корпорации — это куча данных. Если не продумать, как с ними работать, то можно попасть в джунгли из байтов и битов, и потом вылазить оттуда будет сложно.
- Не масштабируем и забываем про возможную нагрузку. Продукт, который работает для пятерых, может вдруг сломаться, когда клиентов станет сто тысяч. Масштабируемость — важная вещь.
- Не говорим с продуктовой командой заказчика. Если не разговориться с заказчиком, командой и остальными игроками — будет бардак. Придётся несколько раз выстраивать коннект.
- Не даём заказчику подумать самому. Важно не спорить и не настаивать на своем. Со временем заказчик сам придёт к тем решениям, которые уже висят в бэклоге и имеют больше плюсов.
Необходимо стараться аргументировано подталкивать заказчика к верным решениям и мощным результатам. Так выстраивается продуктивное долгосрочное сотрудничество.
Разработка продукта для корпораций — это не просто кодить и тестить, это ещё и думать о корпоративной культуре и правилах безопасности. Выстраивать отношения с бизнес-заказчиком, управлять метриками, помогать искать точки роста и автоматизации, внедрять новые технологии, обучать новой системе и поддерживать заказчика на каждом этапе разработки.