Читать «Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов» онлайн - страница 9

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

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

Разные продукты для одинаковых целей пользователей.

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

Заметки и истории

Ограничения

Творить – не мешки ворочать

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

Но в самом конце проекта, когда оставалось лишь оформить закрывающие документы, заказчик сообщил, что хочет полностью изменить проект и получить ещё несколько эскизов. Я назначил ту же цену, что и за разработку первых трёх эскизов, на что он выдал: «За что такие деньги? Творческие поиски – это вам не мешки ворочать!»

И лишь спустя несколько лет я понял, в чём была моя ошибка. Я недостаточно подробно обсудил ценообразование – и заказчик подумал, что стоимость разработки первых эскизов является «входным билетом» в бесконечные творческие поиски. Хорошо, что человек попался, способный слушать и слышать. Несмотря на неловкость ситуации, мы не стали разрабатывать новые эскизы и запустили утверждённую реализацию.

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

4 – Какие нужны документы

Управляемая гибкость

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

С одной стороны, необходимую гибкость может обеспечить создание «рамочного» договора и дополнительных соглашений к нему («заказов»). Такой подход будет удобен в большинстве проектов, но может не применяться в очень крупных организациях или, например, в госкомпаниях.

Вы сможете делить заказы по проектам или отдельным этапам – в зависимости от ситуации.

Рамочный договор и заказы.

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