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

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

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

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

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

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

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


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

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

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

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

По результатам общения мы фиксируем следующие исходные данные для будущего проекта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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