Проблемы в разработке сервисов: как сократить количество правок в конце проекта

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

Необходимое условие развития бизнеса — повышение операционной эффективности. Один из способов оптимизировать расходы компании и при этом добиваться более высоких результатов — цифровизация бизнес-процессов. Сегодня 61% компаний применяет различное ПО для автоматизации своей работы, причем 53% из них замечает плохую совместимость софта от разных производителей.

Этот факт толкает бизнес на запуск собственных продуктов для автоматизации. По данным аналитиков, 76% отечественных компаний теперь самостоятельно разрабатывают софт.

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

С какими проблемами сталкиваются компании в разработке

Как IT-аутсорс компания мы сразу заметили повышение спроса на запуск продуктов для бизнеса в 2022 году. Часто заказчики приходили уже после нескольких попыток сделать сервис. Так мы стали замечать схожие причины, по которым запуск продуктов проваливается или откладывается.

Во время подготовки к докладу на ProductCamp мы решили систематизировать проблемы бизнеса во время разработки. Запустили несколько опросников в продуктовых чатах и узнали мнение 60 продактов и проджект-менеджеров из средних и крупных компаний.

Какие трудности выделили:

1. Длинные цепочки согласований. Статью про их причины и последствия можно прочитать здесь.
2. Высокая стоимость разработки. Материал о способах её сокращения — по ссылке.
3. Запрет на использование No-code и SaaS-решений из-за политики безопасности компаний. Разбор этой проблемы — здесь.
4. Правки после разработки — о проблеме говорим в этой статье.

Из-за чего возникают правки после разработки

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

У этого явления несколько причин:

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

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

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

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

4. Появление новых требований к продукту. Классическая разработка с нуля занимает от 6 месяцев до нескольких лет. За это время стратегия компании или принцип работы департаментов могут измениться. Нововведения в бизнес-процессах приведут к необходимости адаптировать продукт.

Последствия правок после разработки

1. Дополнительные затраты времени и денег на исправление ошибок и внесение изменений.
2. Ухудшение отношений между заказчиком и исполнителем. Каждая сторона начнёт сомневаться в компетентности друг друга. Это портит микроклимат в компании и провоцирует череду разбирательств. 
3. Снижение качества продукта. Изменения после разработки могут отразиться на скорости работы сервиса и появлению программных ошибок. 

Как мы решили проблему правок после разработки

70% российских компаний использует lode-code технологии, чтобы удешевить и ускорить разработку. Чтобы удовлетворить запрос рынка, мы запустили собственную low-code платформу Oberton. 

Oberton позволяет:

• разрабатывать сервис под конкретные бизнес-требования. Создаём полноценный цифровой продукт, адаптированный к процессам работы заказчика; 
• собрать демо-стенд за 5 дней. Это часть готового продукта, которую можно «потрогать» — перейти по вкладкам, заполнить данные, вывести таблицу и так далее. С помощью демо легче управлять ожиданиями стейкхолдеров и тестировать интерфейс на конечных пользователях;
• разработать веб-сервис за ~2 месяца;
• легко развивать продукт. Сервис, разработанный на Oberton, открыт для любых интеграций и добавления новых функций. Предоставляем полную проектную документацию. Любой python-разработчик сможет вносить изменения в сервис;
• реализовывать разработку силами минимального количества участников. Для запуска хватает команды минимум из 4 человек: менеджера проекта, бизнес-аналитика, python-программиста и тестировщика;
• переиспользовать наработки. Если во время разработки идея продукта поменяется, уже готовую часть можно переиспользовать для новых разделов.
  
  На базе Oberton можно сделать любой B2B-сервис: LMS, ERP, HR-портал, CRM, B2B-магазин, PIM-систему и даже то, что ещё не придумали.

Итого

Oberton помог сократить количество правок после разработки на наших проектах в два раза. Демо-стенды позволяют заказчикам быстро понять, как будет выглядеть и работать новый сервис. Если со стороны бизнеса появляются новые требования к продукту — их легко реализовать.

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