Команда программистов. Самые частые способы развода

Денис Гордиенко, генеральный директор Bright Mobile, о популярных разводах программистов.

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

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

Один из моих клиентов начал разработку с ребятами, которых нашёл на Воркспейсе – фриланс-площадке, где заказывают сайты, приложения, рекламные кампании и прочее из IT-направления. Договор на разработку был на не слишком большую сумму, но в нём содержались некоторые любопытные детали. Самый бросающийся в глаза – сроки.

По классике этапы прописываются с фиксированной стоимостью и фиксированными сроками. Здесь же стояла интересная формулировка, заключающаяся в том, что «предварительные сроки составляют 30 рабочих дней, но исполнитель может в одностороннем порядке увеличить сроки разработки», причём максимально возможные сроки разработки составляли… 400 календарных дней!

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

Я проконсультировался с юристом, и тот сообщил мне, что по факту у заказчика руки связаны: он изначально был уведомлён о возможном увеличении срока, и сам же подписал договор. В нём не был прописаны причины, по которой могут произойти задержки, а по каким не могут, про форс-мажорные обстоятельства (для которых нужна справка с МЧС) не было ни слова.

Решения тут может быть два. Первое – прописывать строгие временные рамки, но, например, с оговоркой, что если заказчик будет затягивать согласование, эти затянутые сроки будут добавлены к общему сроку работ. Это правильно, ведь исполнитель тоже должен быть защищён: вечно ждать клиента он не в состоянии, у него и так есть, чем заняться. Некоторые студии ещё добавляют некоторый штраф за простой программиста, это тоже считаю нормальным.

Чтобы всё было по-честному и справедливо для обеих сторон, нужно согласовать, какие форс-мажорные обстоятельства реально могут повлиять на сроки. Со стороны исполнителя – это защита, во-первых, от долгого согласования, чтобы заказчик не тянул и не требовал потом сдать быстрее, а во-вторых, от чрезмерного количества правок, которые может потребовать от него клиент.

Со стороны заказчика – гарантия своевременного получения сайта или приложения без затягивания сроков, чтобы к концу оговариваемой даты у него на руках было готовый продукт хотя бы на тестирование. Хотя бы – потому что приложение ещё может не принять третья сторона – стор, от которого тоже многое зависит. Но если есть *. apk-файл, его можно передать на проверку. Или сайт, если речь о веб-разработке – и при наличии багов исполнитель в рамках гарантийного срока их должен будет исправить.

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

Есть и третий вариант — это поискать готовое решение для своей идеи и доработать только некоторые нюансы под себя. Например, мы сделали RTPlatform — основу для биржи услуг, по статистике клиенту требуется кастомизировать, с нашей помощью, только 20% объёма, связанного с уникальностью идеи.

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

Для чего это делается? Я, как руководитель команды разработки, прекрасно понимаю, что если присылают по одной ошибке раз в один-два дня, это очень сильно напрягает. Программист потратил час на исправление одного бага, взялся за следующую работу, а тут ему бац, и приходит ещё один баг. Так и новую работу не успеть, и на баги надо тратить кучу времени.

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

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

Как от этого оградиться?

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

И вы присылаете списки правок уже не в конце, а по каждому объёму работ, который вам предоставили на согласование. Нужно будет проговорить, что отдельные этапы работ будут согласованы отдельно, и исполнитель не будет начинать следующий этап, пока не доделает предыдущий. Это касается и каркасов, и серверной части, и дизайна, и мобильных приложений, и сайта.

Большую роль здесь играет также понятие критического и некритического бага. Объясняю на пальцах: критический баг – это то, что мешает исполнению ключевого бизнес-процесса. К примеру, вы решили зайти в админку и отредактировать какой-либо элемент в списке. Вы заходите, жмёте на редактирование, но вместо этого выскакивает ошибка. Такой баг – критический, т. к. редактирование неосуществимо.

А вот если всё работает не так, как должно, но исполнению задач это не мешает, баг будет считаться некритическим. Например, съехала вёрстка: вы отредактировали элемент, но на фронтенде он выглядит криво.

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

Резюмируя: в первую очередь важно пройти все функциональные моменты, чтобы все они были успешно завершены – и в админке, и в выполнении с клиентской части, где вы тестируете приложение как пользователь. Затем вы готовите список критических и некритических ошибок, например, по дизайну и других мелких недочётов, и добавляете их в единый список.

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

Здесь не столь важно юридическое составление договора или его приёмка, а работа в рамках его исполнения, а вкупе с ней ваши ответственность и внимательность к багам. Большой ошибкой будет считать, что если последним пунктом прописаны «тестирование и отладка», то можно их до этого момента не проводить, т. к. исполнитель сам всё будет проверять (а если что-то не так, он вернёт вам все деньги). Рассчитывать на такое не стоит, и юридическая практика, и здравый смысл говорят об обратном.

Очень важно, если вы дойдёте до финала негативных отношений с исполнителем, определиться с тем, какая сумма будет заложена на тестирование и отладку. Иногда бывает так, что их преподносят как «бесплатные».

Заказчик на это очень хорошо покупается: здорово же, исполнитель и ошибки сам найдёт и исправит тоже сам, за свой счёт. Но на деле всё это далеко не так, потому что исполнитель всегда закладывает 10-20% времени на исправление ошибок, и в бюджете они тоже есть. Зато остаётся свобода для махинаций, как у одного моего клиента.

Его предыдущие разработчики пступили очень оригинально: сначала начали тянуть с исправлением багов и сливаться, не желая ничего править, а потом, когда клиент пригрозил им обратиться в суд, ответили, что тестирование и отладка – бесплатные, а раз так, то и вопросов никаких быть не может.

Клиент в суд пошёл всё равно, только это, как минимум, нервы, а как максимум, ему пришлось за свой счёт проводить экспертизу. Для понимания: стоит это удовольствие от 60 до 300 тысяч рублей в зависимости от объёма приложения, эти деньги замораживаются, пока организация не вынесет окончательное решение, а уже затем, в зависимости от вердикта судьи, деньги либо остаются у экспертизы, либо возвращаются клиенту, если будет доказана вина исполнителя (который и должен будет оплатить экспертизу).

Но даже при таком успешном раскладе есть два негативных момента: во-первых, серьёзно морозятся деньги, ведь судебные издержки могут занимать от полугода до двух-трёх лет, и на свой проект деньги надо искать в другом месте (или ждать, пока не окончится суд). Второе – на руки по итогу клиент получил исходники с багами, и искать команду, которая взялась за работу с такими багами, было непросто.

Не стоит рассчитывать, что к вам выстроится очередь программистов, которые будут исправлять чужие ошибки: такого не бывает. Заказчик в таком случае может либо плюнуть, попытавшись по максимуму вытащить из старого проекта деньги, либо ждать, пока кто-то доведёт всё это до ума, но всё это долго, трудно и нервозно. Поэтому вывод: на тестирование и отладку, будучи заказчиком, я бы закладывал 20-30% денег, и в случае сдачи нерабочего продукта и отказа исполнителем его дорабатывать, подавал бы в суд.

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

Пишите, интересна ли вам такая рубрика, и присылайте свои договоры. Найду что-то «оригинальное» — обязательно расскажу в следующих статьях. Будьте внимательнее, удачи и успехов!