ЗАПРОСИТЬ КОМ.ПРЕДЛОЖЕНИЕ
Нажимая на кнопку, вы соглашаетесь с политикой конфиденциальности
ЗАКАЗАТЬ ЗВОНОК
Нажимая на кнопку, вы соглашаетесь с политикой конфиденциальности
Новости

Заказная разработка: 3 важных этапа до заключения контракта с подрядчиком

Заказная разработка — сложная сфера с точки зрения удовлетворенности заказчика результатом выполненных работ. Случается так, что бюджет потрачен, а итог не устроил клиента. Основатель и генеральный директор ИТ-компании bobday Борис Кухлев рассказывает, как выходить на разработку правильно и какие этапы предварительного обсуждения проекта помогут избежать ошибок.

Для кого статья


  • Эта статья заинтересует заказчиков услуг по разработке софта, сайтов, приложений и ИТ-продуктов.
  • Также она будет полезна исполнителям в сфере заказной разработки, так как объясняет, через какие этапы проводить заказчика перед тем, как заключать договор.


Как клиенты выбирают исполнителей в ИТ


За заказной разработкой приходят разные клиенты. На процесс выбора исполнителя влияют два фактора.

  1. Кто приходит с запросом — сам заказчик (ЛПР) или его сотрудник/сотрудник из компании-посредника. Если к подрядчику обращается заказчик, ответственный за принятие решения, то доконтрактный этап проходит бодро и продуктивно. Если же к потенциальному исполнителю приходит сотрудник заказчика или менеджер компании-посредника, то процесс переговоров затягивается, ведь участник со стороны заказчика «не свободен» в принятии решения, а согласовывает все свои действия с ЛПРом.
  2. Насколько сложны и бюрократизированы процессы в компании. Как правило, это связано с масштабом бизнеса: чем больше компания, тем больше точек контроля и сложнее процедуры принятия решения. Крупные компании обычно затягивают с выбором и заключением контракта. Средний и малый бизнес более оперативны в этом плане.


А что же с подрядчиками?


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


Мы подготовили для вас PDF брошюру с 12 советами по выбору ИТ подрядчика.



У bobday есть три конкурентных преимущества:

  • 20+ лет опыта в разработке, большая насмотренность и высокий уровень компетенций.
  • Структурирование задачи — наш уникальный подход к реализации проекта заказчика.
  • Ответственность за проект. Мы ведем проект вместе с клиентом и несем ответственность за конечный результат. Разработчики bobday не просто пошагово выполняют формальное ТЗ, но по ходу разработки вносят изменения и предлагают конструктивные решения, которые позволят решить реальную проблему клиента.

С чего начинается общение с клиентом


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


1 Этап. Знакомство с компанией


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

На встрече мы «вытаскиваем» максимум информации о текущем положении дел в компании в контексте проблемы, которую хочет решить клиент. Также слушаем видение клиента: как он хочет изменить ситуацию. Важно понимать не только ту часть, которую клиент хочет автоматизировать, но и в целом бизнес клиента. Понимание бизнес-процессов напрямую связано с содержанием проекта. Важно прояснить несколько ключевых моментов.


  • Симптомы и проблемы. Какие проблемы клиент планирует решить через автоматизацию. Важно разделять симптомы и проблемы. Часто клиент формулирует не проблему, а лишь симптом. Нам приходится нырнуть глубже, и тогда нам открывается скрытая часть айсберга, о которой клиент не упомянул.
  • Результаты. То, как клиент видит будущую систему или сервис. Какие есть критичные требования и ограничения.
  • Эффекты, которые заказчик рассчитывает получить по результатам внедрения ПО. Понимание эффектов, которые ждет заказчик — хорошее подспорье в разработке, которое позволяет скорректировать подход к проекту и его содержание.
  • Симптомы, проблемы, результаты и эффекты должны иметь логическую связь. Иначе проект будет неполноценным и не даст результат, которого ждет заказчик.


2 Этап. Видение проблемы и решение


По результатам общения мы фиксируем следующие исходные данные для будущего проекта:
  • Текущая ситуация клиента. Важно, чтобы клиент понимал, правильно ли мы видим его проблемы.
  • Цели и задачи, которые нужно решить через автоматизацию.
  • Функциональная модель будущей системы — схематично. Это крайне важный артефакт для дальнейшей разработки, даже если модель не детальная, а верхнеуровневая. Схематичная визуализация дает представление о функциях и их взаимосвязях.
  • Описание ключевых функций.
  • Оценку по объему работ в разрезе ключевых функций.

3 Этап. Выход на обсуждение с КП


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

Личная встреча и презентация КП помогает прояснить спорные моменты. Мы отвечаем на вопросы клиента, если ему что-то непонятно. Мы снимаем недопонимание с помощью конкретных примеров реализованных проектов. Это весьма эффективный путь «перетянуть» клиента на свою сторону.

Мы отражаем в КП и доносим клиенту через прямую коммуникацию следующие моменты:

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

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

  • Оценка объема работ в разрезе функций. Время и затраты на реализацию.

Заказная разработка: трудности переговоров


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


Клиент не понял, почему так дорого/дешево


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

Мы в bobday проводим экспертную оценку проекта по разработке ПО. Чтобы повысить точность, мы прорабатываем функциональный состав будущей системы или сервиса и обсуждаем его с клиентом. Затем проводим оценку работ в разрезе функций. Эту работу выполняет один эксперт, затем выносит результаты анализа на обсуждение с группой, в составе которой главный аналитик, архитектор и директор по разработке. Если в оценке есть неточности, их тут же находят. Только после утверждения внутри компании конечная стоимость проекта попадает в КП и озвучивается клиенту.


Клиент не сформулировал проблему


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

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


Клиент не заинтересован в решении проблемы, но хочет закрыть задачу


Иногда к нам приходят специалисты из компаний за решением конкретной задачи по поручению руководства. Мы начинаем работать и на предварительном этапе понимаем, что проблема больше и глубже. Мы объясняем это заказчику, но сталкиваемся с нежеланием слушать наши доводы. В такой ситуации есть два варианта. Первый: сделать так, как просит клиент, который, по правилам торговли, всегда прав. Второй: попытаться убедить его, что необходимо подойти к решению проблемы с другой стороны. Мы всегда начинаем со второго пути. И если мы видим, что заказчик не настроен на решение проблемы, но пришел закрыть задачу, которую поставил босс, то мы фикисируем его «хотелки» и работаем с ними. Как правило, второй путь приводит к тому, что клиент вскоре возвращается и говорит, что мы были правы, но ему стало это очевидно только теперь.


У клиента большой и долгий проект


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

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


В заключение


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