В предыдущей статье мы рассмотрели, чем плохой договор отличается от хорошего. В этот раз подробнее остановимся на таких понятиях как Заказ на услугу (Work Order – WO), зачем нужны Соглашение об уровне услуг (Service Level Agreement – SLA) и Состав услуги (Service Design Package – SDP).
Напомню, что удобная для использования конструкция типового международного договора выглядит следующим образом:
Заказ на услугу (Work Order – WO) – это приложение к договору, в котором указывается конкретная услуга, стоимость и сроки ее предоставления, и обязательно - конкретный размер ответственности за неисполнение.
Например, если вы находитесь на этапе идеи, то логично, что первый ваш Заказ должен содержать услугу проектирования мобильного приложения. Иначе вы не узнаете точную стоимость реализации вашей идеи, ведь каждый разработчик будет представлять себе разные приложения. Поэтому, если вы проектируете – то в Заказе укажите: проект, стоит две тысячи долларов, должен быть сделан за 20 дней, иначе разработчик платит штраф в размере 1% за каждый день просрочки.
Что касается штрафов за неисполнение – это ваша гарантия. Поэтому всегда помещайте их в договор и на этапе согласования сразу поймете, насколько серьезная перед вами компания и готова ли она обеспечить реальные финансовые гарантии.
В свою очередь Заказ должен ссылаться на Соглашение об уровне услуг (SLA) и Состав услуги (SDP). Эти два документа формируют тело услуги, определяют результаты сотрудничества.
Для того, что бы понять, что такое SLA надо понять разницу между услугой и сервисом.
Услуга – это то, что вам оказывают, например, проектирование или разработка.
Сервис – это то, как вам оказывают услугу.
SLA – это про сервис. А SDP – про услугу.
Таким образом, Соглашение об уровне услуг – это оболочка услуги, которая делает работу с компанией удобной. Как и с договором проведу аналогию:
В таком соглашении можно прописать что угодно. Например, кто участвует в проекте и на какой позиции, что такое рабочее время и время для обращений, какие каналы коммуникаций вы используете, как быстро стороны реагируют на сообщения, доступ к мониторам сотрудников, расписание онлайновых встреч, персональный менеджер или массажист и т.п. При этом надо понимать, что качество сервиса будет влиять на итоговую стоимость услуги.
Чтобы не переплатить, старайтесь указывать оптимальные параметры – только то, что действительно нужно. Как правило, для общения с командой разработки достаточно скайпа и почты, пары встреч, продолжительностью не более 2х часов, обычное рабочее время с 10 до 18, временем реакции на сообщения не более 1 часа и так далее.
По установленной традиции приведу аналогию для документа Состав услуги (SDP):
SDP – это техническое тело услуги, вроде как техническое задание, но шире. Например, для того же проектирования SDP может включать следующие входные и выходные параметры:
- Состав работ.
Например, анализ конкурентов, портреты пользователей, концепция дизайна, разработка иконки, прототипирование и т.д. Состав работ и нормы времени каждой операции (работы состоят из небольших операций) определяют стоимость услуги в целом. Если у вас есть детальные операции со временем, то вы всегда сможете их корректировать. Например, иконку делает дизайнер и тратит на это 4 часа. Час дизайнера – 20$ следовательно ваша иконка вам обойдется в 80$. Вы можете представить, что за эти деньги вы получите довольно простую иконку. Вы вольны потратить больше времени дизайнера и получить крутую иконку. Так можно оговорить каждую операцию. И тогда вы будете точно уверены в том, что и как вам предоставляют.
- Требования к проекту.
Например, к тестовым устройствам, инфраструктуре, составу команды разработки, географии и т.д. Эти требования влияют на стоимость разработки. Например, если вы в требованиях укажите поддержку iOS и Anroid устройств, то это обойдется вам в два раза дороже, чем приложение на Android.
- Итоги сотрудничества.
Например, техническое задание, прототип, иконка, портреты пользователей, дизайн, ключевые показатели и другие результаты. Итоги сотрудничества напрямую зависят от состава работ. Тут тоже можно сэкономить. Проверяйте, чтобы в итогах не попадались лишние позиции. Например, если ваша цель визуализировать свою идею для инвесторов – то вам не нужна детальная схема приложения и полностью «нарезанный» технический дизайн. Достаточно будет концепта проекта, рабочего прототипа и технического задания (для оценки стоимости разработки у разных разработчиков). Можно ещё добавить продающую презентацию. Такой пакет наглядно покажет инвесторам ваш подход к делу и повысит шансы на сделку.
При высоком бюджете на разработку приложений или сайта особенно важно уделять пристальное внимание содержанию договора.
Хороший договор гарантирует вам хороший результат и исключит риски плохой реализации.
Удачи в ваших проектах и хорошего дня!
