Договор на разработку — agile, waterfall или out staff?
Программист программирует, заказчик платит. Что же в этом сложного? Зачем те договоры, если и так все понятно. Кхм … возможно, где-то в идеальном мире, это и сработало бы, но в наших бурных буднях все не так просто.
Для урегулирования отношений между компанией разработчиком программного обеспечения заключают договоры, закрепляющие договоренности на бумаге, чтобы, если вдруг что — «а-та-та, смотри пункт 5, подпункта 6, статьи 9 раздела 5» 🙂
С одной стороны, максимально подробные договоры, предусматривающие все возможные ситуации, которые могут произойти во время разработки и после нее, это хорошо, но есть ли смысл переписывать кодексы в договор? Более того, в максимально детальных договорах иногда забывают о ключевых пунктах. С другой стороны, без договора, или с «договором на салфетке», в случае конфликта интересов, в суде будет не так-то просто обеим сторонам. Если интересуют такие споры, в частности, по разработке веб-сайтов — можете почитать нашу интересную статью на эту тему.
Какой тип договора на разработку софта выбрать?
Этот вопрос, конечно, не такое серьезное как выбор языка программирования для программиста — начинающего, но все же серьезное.
Waterfall
Итак, чем характерные waterfall договора?
В таких договорах четко указывается техническое задание, которое, как правило, сочетается Сторонами в Приложении и сразу подписывается. Бывают кейсы, когда Заказчик подписывает такое техническое задание, даже не читая его, а затем, когда результат не соответствует ожиданиям, оказывается в самом техническом задании также указано совсем не то, что хотел бы видеть Заказчик. Добрым советом для Заказчика, который не разбирается в технических нюансах и для какого то техническое задание выглядит как иероглифы, будет проконсультироваться с другим независимым разработчиком прежде чем утверждать техническое задание на предмет того, соответствует ли оно его ожиданиям. Именно соответствие техническому заданию в судебной практике часто становится предметом экспертизы и решающим в спорах о некачественном предоставлении услуг по разработке программного обеспечения.
Agile
Хорошо, с этим понятно. Четкие условия, точное ТС, сроках, конкретные суммы. А что это за чудо — agile договор? Как это можно сделать договор на методологию разработки? Бред. Не совсем. Логика все же есть. В этом договоре закрепляются основные лейтмотивы идеи и концепции гибкой разработки — а именно, постоянное сотрудничество между Заказчиком и Исполнителем.
Более того, они скорее хорошие партнеры чем Клиент и подрядчик. А целесообразно в этом договоре расписывать все эти юзер-стори, бэк-лог, стори борд, ретроспектива, манифесты? Интересно, как на все это посмотрит суд, если вдруг что-то. В agile договоре, в украинских правовых реалиях в любом случае должны быть существенные условия, характерные для договоров разработки софта. Предмет договора, цена, сроки и те условия, которые будут определены как существенные сторонами. Все подробные условия коммуникации между Сторонами можно разместить в соответствующем разделе — «Взаимодействие Сторон». Калькуляцию стоимости конкретных пользователь стори можно расписать, так же как и спринты — этапы в рамках общего срока предоставления услуг.
Такие виды договоров набирают все большую популярность среди разработчиков и заказчиков, ведь довольно часто процесс разработки является длительным и условия рынка, под который создается продукт меняются. Именно адаптивность к возможным изменениям, постоянное сотрудничество и нацеленность обеих сторон на успешный релиз продукта является основным преимуществом agile договоров.
Out staff
Еще одним вариантом урегулирования отношений может быть out staff договор. В этом случае Заказчик получает в свое распоряжение конкретные часы конкретных специалистов по скиллы, которые описаны в договоре. Такие специалисты оказывают услуги в пределах заявленных навыков. При этом, работу таких специалистов может координировать менеджер, часы которого также продаются в рамках аутстаф договора. Такой вариант подходит для опытных заказчиков, или тех, кто имеет понимание в сфере разработки софта, и соответственно, сможет получить пользу именно от такого алгоритма работы.
В таких договорах фиксируются количество часов конкретных специалистов, стоимость таких часов, в зависимости от специализации и навыков лиц, привлеченные.
Same, but different (одинаковое, но иначе)
Конечно, все это разделение договоров на разработку софта на waterfall договоры, agile контракты и аутстаф соглашения достаточно условно. Ключевые, по нашему мнению, различия были указаны выше и в зависимости от конкретного кейса и существа правоотношений можно выбрать нужный формат. А еще — можно разработать определенный mixed agreement, который будет включать элементы всех трех договоров 🙂
В любом случае, для Заказчика важно получить конечный результат и все исключительные имущественные авторские права на него. Более того, это все Заказчику хочется получить за понятную плату и в определенный срок. Для разработчика же важно будет ясно и четко выписать свои обязанности и выполнив их, получить оплату, а также не указать в договоре того, что гарантировать Исполнитель не может.
Конечно, это лишь верхушка айсберга и в будущих статьях мы более подробно остановимся на конкретных аспектах таких договоров. Если же есть конкретный вопрос по этому поводу, или же Вы хотите провести тест на адекватность и подводные камни для Вашего договора на разработку софта — кликайте на контактную форму. 😉
Тарасюк Антон
Managing Partner