8. Результат сотрудничества.
В договоре должна быть указана конкретная сумма и конкретный результат труда, который вы получите за эти деньги. Иначе вы рискуете попасть в постоянное «Доплатите, пожалуйста, и мы все доделаем». Если же исполнитель ошибся суммой, а такое также случается, то всегда можно внести изменения в договор на взаимовыгодных условиях.
Часто заключают договор с использованием почасовой оплаты. В таком случае убедитесь, что есть отдельный пункт, обеспечивающий прозрачный контроль за затраченным разработчиком временем при создании приложения. К примеру, контроль можно осуществлять через сторонний сервис, постоянно следящий за тем, что делает разработчик за своим компьютером, или же видео выполнения работы.
9. Условия оплаты.
Предоплата в разработке программных продуктов – дело естественное, и этого не нужно бояться. На самых ранних этапах разработчики выполняют множество задач, которые остаются за кадром. Об этой работе вы обычно даже не подозреваете, но и она должна быть оплачена. Предоплата позволяет исполнителям качественно работать с самого начала.
Если рассчитываетесь по безналичному расчету, то обычно с подтверждением оплаты проблем не возникает. Если платите наличными, советую получить от разработчика документ, подтверждающий факт оплаты. Документ требуйте в момент оплаты, а не когда-нибудь «завтра». Также на документе должны стоять печать и подпись от компании разработчика.
10. Акт выполненных работ.
Для каждого разработчика наличие акта выполненных работ очень важно. Это документ необходим при налоговых проверках в качестве подтверждения, что все работы по контракту были выполнены и договор считается закрытым. Ни в коем разе не подписывайте акт выполненных работ до того, как все работы будут выполнены, но и не вздумайте шантажировать им разработчика, чтобы он делал то, о чем вы не договаривались. Вам еще наверняка пригодятся его услуги, не нужно портить отношения.
Соглашение с пользователями
Чем точнее в документе учтена специфика сервиса, тем меньше вероятность того, что у вас не найдется адекватного решения при возникновении конфликтной ситуации.
Павел Мищенко, юрист
Одного договора с разработчиком недостаточно. Вам также понадобится заключить письменные договоренности с каждым пользователем мобильного приложения. К счастью, для этого вам не нужно заключать отдельные договоры с каждым из них на бумаге. Вы заключите договоры в электронной форме. Для этого вам необходимо разместить текст договоров в самом мобильном приложении, дать возможность прочитать его каждому пользователю и выполнить действие, подтверждающее согласие с принятием условий договора.
Самые важные договоренности желательно показывать пользователю либо при регистрации учетной записи для пользования приложением, либо сразу после первого запуска. Некоторые используют сообщение о том, что при дальнейшем использовании приложения, пользователь автоматически соглашается с договором. Часто приложением невозможно пользоваться, пока пользователь не сделает пометку о том, что согласен с условиями соглашения, и это правильно.
Пользовательское соглашение, или, как его еще называют, лицензионное соглашение с конечным пользователем (end-user license agreement (EULA)), – это договор, регулирующий отношения между вами, правообладателем приложения и пользователем приложения. Он касается только условий использования мобильного приложения. Похожие соглашения есть практически в любом онлайн-сервисе и приложении для обычного компьютера. В народе их еще называют «лицензией». Имейте в виду, что из-за неверно написанного соглашения вам могут отказать в публикации приложения в магазине приложений.
Одним из самых важных пунктов лицензионного соглашения является отказ от ответственности (Disclaimer). В информационных технологиях его обычно добавляют в любое приложение и сервис, чтобы тем самым обезопасить себя от любых негативных последствий, возникших у пользователя при использовании программы. Это делается для предотвращения проблем у владельца приложения. Те, кто наперед продумывают все юридические последствия, абсолютно правы.
Почитайте соглашения, подписываемые крупными компаниями с пользователями их мобильных приложений. Компании нередко виноваты в ненадлежащей работе своих программ, но вообще не несут никакой ответственности перед пользователями. Берите с них пример, иначе пользователи начнут винить вас не только в каждой вашей ошибке, но и в своих собственных.
Менее важные договоренности, чем пользовательское соглашение, обычно становятся видимыми только после перехода по ссылке или нажатия на кнопку и содержат пункт о том, что если кто-то пользуется мобильным приложением, то автоматически соглашается с данными договорами. К таким договорам относятся публичная оферта и сообщение о конфиденциальности.
Оферта регулирует ваши отношения с пользователем по части оказания услуг и поставки товара, то есть условия купли-продажи. Информация о конфиденциальности описывает, какие данные собираются и как они будут использоваться. Так, например, если приложение собирает личные данные (имейл, имя, телефон и др.), то, скорее всего, вы должны будете уведомить об этом Роскомнадзор, в противном случае рискуете быть оштрафованными. Довольно часто, мобильные приложения отсылают собираемую информацию третьим сторонам, о чем можно найти отдельный пункт либо в лицензионном соглашении, либо в соглашении о конфиденциальности.
Техническое задание
Техническое задание должно обеспечить полное понимание системы для любого человека, прочитавшего этот документ.
Вайсфельд Мэтт, автор книги «Объектно-ориентированное мышление»
Техническое задание пришло к нам из производства. Когда требуется создать какую-то деталь или устройство, то еще до его создания необходимо иметь ясное представление о том, как должен выглядеть результат работы, какие функции будет выполнять устройство, из каких материалов состоять и т. д. Производство немыслимо без технического задания (далее – ТЗ), так как значительно облегчает появление новых гаджетов, вещей и программ.
Никто не спорит, что при производстве вещей все нужно продумывать заранее, создавать чертежи и описывать результат. При производстве интеллектуального продукта, люди не до конца осознают, что его произвести еще сложнее, и все, что относится к производству материальному, также характерно и при производстве интеллектуальном. Также из-за безграмотности некоторых разработчиков появились идеи, что ТЗ не нужно или же это пустая трата денег и времени.
Часто заказчики сами создают ТЗ, не понимая, что у них для этого недостаточно опыта и знаний. Представьте, что вы составляете ТЗ не на разработку мобильного приложения, а на смартфон. Что вы можете в нем прописать, не будучи специалистом? Только то, что знаете как пользователь. Что знает пользователь? Только то, что может пощупать и опробовать лично, часто даже не подозревая, что другие люди могут пользоваться той же моделью смартфона иначе и для других целей. Я уже не говорю о нехватке специальных знаний в дизайне интерфейса и программировании.
