Контракты под "agile-проект": так ли страшны переговоры с заказчиком при разработке "софта"?
Давно вынашиваемая идея - попытаться "простыми словами" передать юристу суть контракта на разработку софта в "эджайл-проектах". Да, безусловно, на юридическом языке речь может идти об одном из двух. Либо об услуге в понимании гражданского кодекса, либо о подрядном заказе разработки у исполнителя. Сразу обозначим, что аспект авторских прав (часто всплываемый среди первых ассоциаций "разработка софта - значит, защитить нужно IP-rights") оставим в стороне, да исключительно чтоб не сместить основной фокус.
Консультація виконавця
Итак, "эджайл-проект" - чего в нём больше - услуги или подрядого заказа? Ответ возможен здесь (как и для любого начинания заказать разработку ПО) "и так, и так". Да суть "эджайла" в "гибкости", а это как? Напомним ключевой момент - классически в услуге исполнитель отвечает за процесс, тогда как для подряда важен больше результат. На практике же "чистую" модель встречаем мы совсем нечасто. Ведь при соприкосновении с любым интерактивным мероприятием (а "софт" при разработке он такой) мы, как минимум, не можем исключать сам процесс взаимодействия сторон в процессе работы. Соответственно, уже не есть "чистый подряд", в котором важен только результат. С другой стороны, не можем также исключать вполне конкретные (в определенном приближении) ожидания сторон от того, чем "на выходе" должно завершится сотрудничество. И потому "чистая услуга", где создаваемая ценность потребляется на протяжении всего процесса взаимодействия, также редко может удовлетворить "покупателя" и "продавца". И потому любая разработка будет практически всегда предполагать своего рода смесь услуги и подряда. Исключениями могут быть некие крайности, как например: аутстаффинг ИТ-команд (как некая полярная точка услуги) или конфигурация достаточно простых приложений на базе имеющихся "полуфабрикатных" наработок (как полярность разработки под требования, "снятые сразу").
А чем же уникален здесь "эджайл-проект"? Пожалуй, тем, что это договор-регламент взаимодействия "на поле" для двух команд - команды заказчика и команды исполнителя. В том, что "игра по правилам" - это загол успеха. И даже когда нет на входе требований, в процессе взаимодействия они "рождаются" уже "легализированными", а значит, на выходе уже есть.
Априори по закону нельзя навязать заказчику "незаказанный сервис", как и "незаказанный результат". И этот момент, на первый взгляд, можно попробовать представить против жизнеспособности концепции контракта под "эджайл-проект". Да с правильным подходом и такой аргумент способен выдержать конструктивную критику. При этом важно помнить, что любое "гибкое эджайл-сотрудничество" должно вплести в контракт одновременно и элементы делегирования (как например, на базе распределения ролей в проекте).
И тогда мы вполне можем рассчитывать, что всё, "прошедшее сквозь эджайл-процесс", выходит из него уже легально согласованным заказчиком. А будет ли это означать, что "эджайл-проект" в принципе всегда даёт фору исполнителю? Нет. Он просто органически переносит бремя переговоров по сути создаваемого продукта с первых лиц компании (при заключении договора) на привлечённых в команду профессионалов своего дела (в ходе реализации проекта). Да и на крайний случай, досрочного прекращения проекта ещё никто не отменял, ну или опцию "вывода кого-то из команды" (как некий "серединный вариант", аналог, своего рода, "красной карточки" сфолившему игроку). И пожалуй, это просто ещё один из моментов, которые важно иметь в виду юристу, при сопровождении контракта под "эджайл-проект".
