7 ошибок, которые совершают заказчики перед стартом разработки. Опыт переговоров с клиентами

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

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

Чтобы разобраться, как надежно защитить свои инвестиции, мы обратились к нашему руководителю департамента продаж Ольге Трифоновой. Она помогла проанализировать скрытые ловушки ИТ-рынка и дала ценные комментарии. В статье мы подробно разобрали 7 критических ошибок, которые совершают заказчики перед стартом разработки.

Ошибка #1 Бизнес-цель? Разберемся по ходу дела

Согласно аналитике до 70% ИТ-проектов терпят крах еще до старта разработки. Причина кроется в фундаментальной ошибке — отсутствии четко сформулированной бизнес-цели. Выступая в роли заказчика, вы нередко приходите к подрядчикам с запросом на создание конкретного инструмента, забывая о первопричине — реальной проблеме вашего бизнеса.

В международной практике этот феномен называется Lack of Business Alignment (отрыв ИТ-решений от бизнес-стратегии). Ошибка возникает, когда показатели коммерческой эффективности подменяются бесконечным списком функций. Такие системы быстро превращаются в дорогое Shelfware (ПО, пылящееся на полке), принося компании на 56% меньше финансовой ценности, чем планировалось изначально.

Более того, отсутствие оцифрованной бизнес-цели часто толкает компании к бездумному переносу своих же управленческих ошибок в ИТ-инфраструктуру.

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

Ошибка #2 Сделайте нам так же, только лучше

Как часто вы показываете разработчикам интерфейс технологического гиганта и уверенно говорите: «Нам нужно примерно так же»? Эта фраза настолько распространена, что давно стала абсолютной классикой в IT-сфере.

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

Для решения конкретной бизнес-задачи почти всегда достаточно реализовать не более 20% от того функционала, который вы видите у гигантов. Секрет успешного старта кроется вовсе не в слепом копировании, а в умении грамотно отсекать лишнее.

Именно поэтому наши эксперты рекомендуют сфокусироваться на разработке MVP (минимально жизнеспособного продукта). Вместо создания сложного и дорогого долгостроя вы получаете шанс стремительно выйти на рынок. Вы на практике проверяете бизнес-гипотезы, собираете бесценную обратную связь от живых пользователей и развиваете систему шаг за шагом.

Ошибка 3 Все участвуют. Никто не отвечает

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

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

Ошибка #4 Бюджетирование методом оптимизма

Практически на каждой первой встрече звучит вопрос: «Сколько стоит разработка программного обеспечения?». Это абсолютно нормальный вопрос. Но проблема возникает тогда, когда заказчик ожидает услышать точную стоимость, не рассказав практически ничего о будущем проекте.

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

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

Ошибка #5 Выбор подрядчика по принципу «Зачем платить больше?»

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

Посмотрите, как эта ловушка выглядит на практике:

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

Ошибка #6 Давайте без аналитики

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

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

Вместо того чтобы оплачивать разработку сложного, тяжеловесного и в итоге бесполезного функционала, вы с помощью аналитиков жестко отсекаете все лишнее.

Ошибка #7. «Ну, недели две?»

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

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

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

Вместо заключения. Как сделать безопасный первый шаг?

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

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

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

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

Оставьте заявку на бесплатную оценку проекта. Давайте обсудим, как превратить вашу идею в надежный ИТ-продукт.