IT-консалтинг: старт с правильного исследования

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

Определение цели: внутренний или внешний продукт?

Определили зачем корпорации продукт и должен ли он работать на внешнюю сторону потребителей: 

Если продукт внутренний, то портрет пользователей ясен — это сотрудники корпорации. Осталось разобраться с их потребностями и проанализировать среду:

• кто основные пользователи: должности и отделы?
• какие задачи решает продукт?
• какие задачи не решает продукт?
• сильные и слабые стороны;
• сравниваем: существующие решения внутри компании и ваш продукт. 

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

Если внешний, то тут нужна статистика и аналитика рынка. Важно понять запросы и страхи потенциальных пользователей:

• чего сейчас не хватает рынку?
• что выпустили коллеги и как?
• какая нужна функциональность?
• от каких продуктов люди устали?

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

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

Антон Клименков, CEO Adeptum Digital Production.

Спроектировать архитектуру

Это фундаментальный этап разработки серьёзного IT-проекта, на котором определяется общая структура и организация будущего решения. Подробно разберём этот процесс:

1. Выбор архитектурного стиля. Начнём с выбора наиболее подходящего архитектурного стиля, который определит основные принципы организации системы. Например, это может быть монолитная архитектура, микросервисы, клиент-серверная архитектура или распределённая архитектура.
2. Определение компонентов системы. Систему разбиваем на компоненты, которые выполняют конкретные функции. Это включает в себя определение модулей, сервисов, баз данных, и других элементов, которые будут взаимодействовать между собой.
3. Установление принципов коммуникации. Определение способов и механизмов, с помощью которых компоненты системы будут обмениваться данными — вопросы синхронности и асинхронности коммуникаций.
4. Разработка базы данных. На этом этапе определяется структура базы данных, выбираются СУБД (системы управления базами данных), проектируются таблицы и связи между ними. Важно учесть требования к производительности и масштабируемости.
5. Управление данными и хранение. Определение стратегии управления данными, включая механизмы резервного копирования, восстановления и обеспечения безопасности данных. Также рассматривается вопрос масштабируемости хранилищ данных.
6. Система безопасности и авторизации. Проектирование механизмов защиты данных и системы авторизации. Это включает в себя определение прав доступа, шифрования данных, мониторинга и аудита событий.
7. Масштабируемость и отказоустойчивость. Разработка архитектуры, способствующей масштабированию системы по мере роста нагрузки. То есть горизонтальное масштабирование, использование облачных сервисов и кластеризацию.
8. Управление конфигурациями и развёртыванием. Определение методов развертывания продукта на серверах клиента, настройку окружения, управление зависимостями и версиями компонентов.
9. Мониторинг и аналитика. Разработка механизмов мониторинга системы, которые позволяют отслеживать производительность, выявлять проблемы и анализировать данные для оптимизации работы системы.
10. Документирование архитектуры. Важная часть процесса — создание подробной документации по архитектуре системы. Так команда разработки и поддержки точно и быстро поймёт, как работает система. 

Системный анализ, UX/UI, интерфейсы

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

Разработать ценность, а не софт

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

Разработка продукта для enterprise-клиентов — это намного больше, чем просто создание программного кода. Это сложный и многогранный процесс, ориентированный на достижение ценности для клиента и продуктивное использование гипотез. Каждый спринт = ценность. Этому учит Agile, который мы так любим. 

Но не забываем также про привычные требования enterprise-заказчиков:

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

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

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

Антон Клименков, CEO Adeptum Digital Production.

Обучить отделы, протестировать и запустить продукт 

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

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

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

Иногда разработка идёт не так, как нам хочется

В этом блоке поговорим про ошибки, которые могут негативно повлиять на разработку IT-продукта. 

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

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

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

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

• Не смотрим в перспективу. Не все думают о том, как продукт будет жить и расти. Главное, что «сейчас работает» — а как будет через год, никого не волнует. Это главная ошибка.
• Не работаем с данными. Корпорации — это куча данных. Если не продумать, как с ними работать, то можно попасть в джунгли из байтов и битов, и потом вылазить оттуда будет сложно.
• Не масштабируем и забываем про возможную нагрузку. Продукт, который работает для пятерых, может вдруг сломаться, когда клиентов станет сто тысяч. Масштабируемость — важная вещь.
• Не говорим с продуктовой командой заказчика. Если не разговориться с заказчиком, командой и остальными игроками — будет бардак. Придётся несколько раз выстраивать коннект.
• Не даём заказчику подумать самому. Важно не спорить и не настаивать на своем. Со временем заказчик сам придёт к тем решениям, которые уже висят в бэклоге и имеют больше плюсов. 

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

Подводим итоги

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