Долгие согласования — проблема №1 в IT-разработке: как нам удалось сократить их сроки

Привет! На связи Creonit. Разрабатываем цифровые сервисы с 2015 года.

В кризисные времена на первое место в менеджменте организаций выходит вопрос эффективности бизнес-процессов. Сейчас многие компании ищут способ снизить издержки, в том числе за счёт автоматизации. Этот факт, а также уход иностранных вендоров с рынка подхлестнули тренд на разработку собственных B2B-сервисов. По данным аналитиков, 76% отечественных компаний из крупного и среднего бизнеса теперь самостоятельно разрабатывают софт.

Как показывает практика, разработка более 70% таких проектов не завершается в оговоренные сроки. Одна из главных причин — это долгие согласования.

Как осознали эту проблему

Весной 2024 года мы готовились к продуктовой конференции ProductCamp. Руководитель Creonit — Антон Макаров — выступал с докладом о запуске нашей собственной платформы для low-code разработки Oberton. Статью по мотивам его выступления можно прочитать тут. 

Запуск Oberton стал ответом на вызовы, которые стоят перед бизнесом во время разработки цифровых продуктов. В рамках подготовки к докладу мы обобщили проблемы компаний в создании B2B-сервисов. Провели ревью сделок за последние 3 года, а также запустили несколько опросников в продуктовых чатах и опросили 60 продактов и проджект-менеджеров из разных сфер бизнеса. 

Выделили 5 самых частых проблем, из-за которых проекты ставят на стоп или не завершают вовремя:

1. Длинные цепочки согласований.
2. Высокая стоимость разработки.
3. Запрет на использование No-code и SaaS-решений из-за политики безопасности компании. После событий 2022 года и массового ухода вендоров с рынка бизнес заинтересован хранить всё на своих серверах.
4. Отсутствие культуры создания продуктов с нуля силами инхаус-команды. Внутренняя разработка хорошо справляется с поддержкой сервисов, но не у всех команд есть опыт запуска цифрового продукта с нуля. В таких случаях часто обращаются за аутсорс-разработкой, а потом забирают продукт на развитие инхаус.
5. Правки после разработки.

В этой статье поговорим о причинах и последствиях долгих согласований. В следующих частях разберём остальные проблемы из топ-5.

Боль линейной структуры управления

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

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

Особенно ярко это наблюдение подтвердилось, когда мы проводили обзор сделок за 3 года. 

Заказчики делились историями, как:

1. Пытались разработать ERP-систему, но 7 месяцев проводили исследования и собирали требования от разных департаментов бизнеса. В конце этапа топ-менеджмент остановил проект, потому что не удалось сформировать общее видение продукта.
2. Финансирование проекта менялось 3 раза за год из-за кризисных ситуаций. После каждого урезания бюджета разработку приходилось передавать новой аутсорс-команде и проходить этапы оценки, подготовки смет и составления технического задания заново. Далее — согласовывать каждый документ с несколькими руководителями компании. 
3. Хотели переехать из Excel в собственный веб-сервис, но разработка встала, потому что «просто не получилось» (прямая цитата).

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

Причины долгих согласований

1. Много лиц, принимающих решения. Нужно учитывать требования разных департаментов. Пока все дадут фидбэк — пройдут недели. Много звеньев и кросс-функциональных согласований затягивают проект. Согласования порой длятся дольше самой разработки.
2. Отпуска, болезни и прочее. Если отсутствует стейкхолдер или лид направления, согласования чаще всего откладываются, пока ответственное лицо не вернётся.
3. Особенности планирования. Сдвиг контрольных точек приводит к сдвигу всего проекта. В планах согласования обычно занимают небольшое время, а в реальной жизни они растягиваются на срок в 3-4 раза больше.
4. Нет сформированных definition-of-done. Нет метрик, которые позволят понять, что этап завершён успешно. В итоге дизайн-макеты или новую функцию дорабатывают месяцами.
5. Email vs созвоны. На письма люди отвечают дольше — их могут просто не замечать неделями. Это затягивает получение обратной связи. При этом решать вопросы на созвонах тоже не всегда получается. Если никто не модерирует беседу, вместо решения текущей задачи участники могут уйти в обсуждение частных проблем. Например, как импортировать базу данных и переносить атрибуты из одного сервиса в другой.
6. Осознание недостатков проектирования на поздних этапах разработки. 
7. Заблуждение, что «если мы ошиблись с первой версией, то легко найдём время и деньги, чтобы переделать интерфейс».

Как согласования влияют на проект

Долгие согласования ещё не помогли ни одному проекту. 

Самые частые последствия — это:

1. Задержки в выполнении задач. Длительные периоды ожидания обратной связи растягивают разработку и сдвигают контрольные точки проекта. В итоге продукт запускают позже оговоренного срока.
2. Увеличение стоимости проекта. Если для разработки сразу выделили целую команду, она может простаивать в ожидании согласования этапа без задач. Кроме того, доработки после обратной связи — это дополнительные затраты. 
3. Снижение удовлетворённости заказчиков. Когда в проект инвестировали время и деньги, но в итоге так и не получили желаемого результата — это всегда большое разочарование. Как итог — продукт могут отложить в долгий ящик или закрыть насовсем.

Как придумали выход из этой ситуации

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

Продукт, который позволит:

1. разработать веб-сервис за ~2 месяца;
2. внедрять готовый продукт в IT-инфраструктуру компании-заказчика, добавлять в него любые интеграции и функции по необходимости:
3. работать с готовой дизайн-системой и собирать интерфейс из существующих элементов.

Важной задачей было дать бизнесу максимум вариантов использования продукта без кастомизации ядра. Чтобы с помощью одного инструмента можно было сделать LMS, ERP, HR-портал, CRM, B2B-магазин, PIM-систему и даже то, что ещё не придумали.

Так появился Oberton — наша собственная платформа для low-code разработки.

Преимущества Oberton

1. Исключает проблемы с долгими согласованиями. Система автоматически генерирует интерфейс — не нужно закладывать ресурсы на дизайн и фронтенд-разработку. Меньше этапов — меньше согласований. 

2. Стейкхолдерам сразу понятно, что им предлагают. За 5 дней на Oberton можно сделать демо-стенд с готовыми страницами и кнопками, который можно «потрогать».

3. Стоимость ниже, чем при классической разработке. Для запуска проекта достаточно минимальной команды из четырёх человек: менеджера, системного аналитика, python-разработчика и QA-инженера. Это снижает фонд оплаты труда команды и позволяет запустить продукт за меньшую стоимость. В то же время для классической кастомной разработки требуется команда минимум из 7 человек.

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

5. Результат разработки передаём заказчику в виде исходного кода.

Итого

Долгие согласования — проблема компаний даже с отлаженными процессами и готовыми регламентами для работы. У этого явления много причин: от занятости стейкхолдеров до споров во время созвона. 

Запуск B2B-сервиса не обязан быть стрессом для нескольких отделов бизнеса и исполнителей. Разработать веб-сервис можно за 2 месяца на базе Oberton. Если вам интересно, как он работает, напишите нам на сайт, обсудим ваши задачи и сделаем демку вашего решения. 

В следующей статье подробнее расскажем, как наша low-code платформа помогает снижать стоимость разработки.