10 типичных ошибок при закрытии сделки

Материал подготовлен специально для блога SPECIA агентством Heads and Hands
02_big

Есть ошибочное мнение, что качество проекта формируется при его завершении, то есть в момент сдачи проекта клиенту, на этапе тестирования. Но на самом деле это не так. Качество проекта формируется на стадии продажи. Тот факт, насколько хорошо проработан проект на этапе старта, влияет на то, каким будет проект в конце.

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

На этапе продажи закладываются основные вехи проекта. Если сравнить проект с пошаговой стратегией типа “Героев Меча и Магии”, то на продаже проект мы видим как полностью закрытую карту и непонятно еще, каким он получится в итоге. Чтобы открыть “туман войны” без потерь важно определить все возможные риски на старте.

И вот они, стандартные ошибки, которые поджидают студии и агентства (хотя на самом деле, эти ошибки отлично подходят и для заказчика):

1.Неправильно выбрана методология ведения проекта.

maxresdefault

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

2.Не согласованы условия по разглашению информации.

Для агентства важно иметь проекты в своем портфолио. Это дополнительная ценность для агентства, т.к. кейсы в портфолио приводят новых клиентов. И если проект делается под NDA, то стоимость такого проекта может быть увеличена на 10-15% в связи с тем, что агентство теряет возможность публикации кейса. Это важно обговорить на старте проекта и обязательно включить в условия договора. Со стороны клиента тоже важно обговорить все детали по разглашению информации уже на старте, чтобы потом не возникло претензий. Если существует риск того, что информация в таком кейсе может быть подана не под нужным клиенту ракурсом, то можно разрешить публикацию с предварительным согласованием. В таком случае клиент контролирует процесс.

3.Тайминг проекта.

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

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

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

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

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

4.Гарантийная поддержка.

maxresdefault (1)

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

Клиенту важно понимать также и какая аудитория будет пользоваться его продуктом, чтобы вычислить возможные баги на закрытии, т.е. сделать акцент на тестировании на конкретных устройствах (например, больше на Android или больше на Учздщкук, если это корпоративный продукт для компании, где основной браузер — Explorer) и т.п.

5. Описание задач.

Еще одна частая ошибка — ХЗ (художественное задание) или ТЗ не сделано или не прикреплено к договору. В целом — это очевидная ошибка, но иногда происходят случаи, когда с клиентом не подписан документ, в котором будет описан объем работ. Для проектирования мы обычно составляем спецификацию, для дизайна — художественное задание, а разработка описывается в задании техническом. Все эти документы должны быть созданы на старте проекта и будут являться приложением к договору. В случае, если в процессе работы появятся задачи, которые не были обговорены на старте и не описаны в ТЗ или другом документе, можно говорить о дополнительной оплате таких работ. Если нет документа, то все доработки исполнитель будет делать за свой счет.

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

6. Этапность оплаты работ / закрытие этапов.

Skills

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

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

7.Смета.

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

8.Определение ответственных лиц со стороны клиента.

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

9.Проговорить способ общения (что удобнее) и время/частоту.

Для разных клиентов удобны будут свои варианты общения — почта, скайп, телефон, различные мессенджеры. Лучше всего это проговорить на старте, чтобы в процессе ведения проекта всем сторонам было удобно. Также бывают разные клиенты — одни любят общаться чуть ли не каждый день, другие на долгое время пропадают. Для команды проекта важно оперативно получать ответы на вопросы в процессе разработки, при этом много времени тратить на созвоны будет неправильно. Поэтому лучше на старте обговорить, что, скажем, раз в неделю клиент точно будет выходить на связь и давать ответы на вопросы. А если есть очень срочные вопросы, то срок реагирования на них — не более 1 дня. Клиенту также важно обговорить со студией, как ему будет удобнее проводить созвоны и встречи. Клиент должен на старте согласовать со студией, что та будет предоставлять ему отчетность в каком-то виде каждую неделю, например (статус проекта). Также клиент должен попросить подрядчика обеспечить ему промежуточные результаты работ — например, пригласить в Hockeyapp, чтобы смотреть билды или заливать на тестовый сервер промежуточные версии веб-сайта. Клиент должен сам проверять ход течения проекта. Ошибка, когда клиент вообще не погружается в процесс и подключается только на закрытии проекта, обычно результатом в таком случае он недоволен, но исправить что-то на этом этапе уже значительно сложнее.

10. Проверка юридического лица клиента.

Сейчас есть инструменты для проверки юридического лица онлайн, можно всегда посмотреть основную информацию о клиенте. Место регистрации юр.лица, банк, в котором у него будет счет, — все это может накладывать определенную ответственность и расходы на агентство, поэтому на этапе продажи важно это проверить. Клиенту также важно обязательно проверить юр. лицо студии. Важно запросить у студии регистрационные документы, выписку из ЕГРЮЛ. Это должно быть действующее юр. лицо, существующее (желательно) не менее 3х лет (с даты регистрации), можно запросить также отчетность, данные по директору, у студии должен быть счет в проверенном банке. Обязательно нужно проверять закрывающие документы от студии, чтобы там все было корректно, т.к. зачастую не все студии имеют грамотных фин. специалистов, и если для студии это будет не критично, то для клиента как раз правильно составленный акт — гарантия того, что у налоговой не возникнет лишних вопросов.

Связанные посты