Описанная ниже ситуация — это ситуация из жизни. В момент написания статьи данная ситуация еще не получила окончательного положительного разрешения для компании разработчика ПО (далее будем называть ее ИТ компания, название компании в данный момент раскрыть не можем), с которым мы работаем вот уже более года по взысканию семизначной суммы задолженности. Возможно, для кого-то данная статья окажется полезной и позволит избежать подобной участи, либо позволит минимизировать возможные потери если ситуация еще не сильно запущена.
Предыстория
В конце 2014 году между ИТ компанией и заказчиком был заключен договор на внедрение 1С. Дело идет к концу года, и как всегда это бывает, заказчик хочет все быстро и как можно дешевле. Обычная ситуация. Предварительные переговоры прошли успешно. Дело дошло до заключения договора. Договор был подготовлен ИТ компанией, конструкция его была достаточно простой. Данная форма договора использовалась достаточно длительное время и до определенного момента проблем не вызывала. По требованию Заказчика в договор были внесены ряд изменений. Поскольку сроки выполнения работ зафиксированные в договоре поджимали и для того чтобы не затягивать согласование документа он был подписан в том виде, в котором его хотел видеть Заказчик.
Проект идет полным ходом. Проведено проектирование, подготовлено ТЗ, начато его согласование. Как это часто бывает, Заказчик не спешит с согласованием проектной документации. ИТ компания принимает решение начать разработку на основе еще несогласованного ТЗ на свой страх и риск. Остается чуть более двух недель до завершения работ по разработке и ТЗ наконец-то согласовано. Сроки сдачи работ при этом официально сдвинуты не были. Было уже понятно, что в определенный договором срок уложиться не удастся. Одним из требований заказчика было начать работать в новой системе сразу после новогодних праздников. Исполнитель решил рискнуть, начать эксплуатировать часть подсистем созданного программного решения как планировалось, т.е. сразу после новогодних праздников, выполнив для этого во время новогодних каникул подготовительные работы. Но как это обычно бывает в подобной ситуации, белый пушистый зверек подкрался незаметно. Пойдя на поводу ИТ компания недооценила инертность специалистов заказчика, а также взяла на себя обязательства выполнить ряд работ не оговоренных в договоре, задействовав для этого часть ресурсов занятых разработкой, что в свою очередь снизило ее скорость. А возникшие проблемы в ходе опытной эксплуатации реализованных подсистем переключили оставшуюся часть разработчиков на тушение пожаров. Разработка остального функционала фактически встала. Возник кризис управления внутри проектной команды исполнителя. Взаимоотношения с заказчиком стали усугубляться.
В какой-то момент с заказчиком удалось найти общий язык, по крайней мере так казалось ИТ компании. Сроки выполнения работ были давно пройдены. В какой-то момент стали появляться признаки того что заказчик просто вьет из исполнителя веревки и платить не собирается. Стало понятно, что дело пахнет керосином. Позднее эти подозрения стали оправдываться. Только в этот момент было решено привлечь для консультаций специалиста по договорным отношениям и возврату дебиторской задолженности.
В процессе анализа договорной и первичной документации был выявлен ряд существенных ошибок, которые сводили к нулю шансы получить деньги за выполненную работу. От того, с какими документами вы подойдете к судебному процессу, если избежать его уже невозможно, зависит исход дела, положительный или отрицательный. О том, какие документы необходимы и о том, как их правильно оформить планируем рассказать в следующей статье, пишите в комментариях к данной статье, если вопрос для вас актуален, это будет для нас стимулом к написанию.
Выявленные ошибки
Первая ошибка – обтекаемо сформулирован предмет договора. Но был сформулирован следующим образом «…Заказчик поручает, а Исполнитель принимает на себя обязательства по поставке и внедрению программного обеспечения 1С: Предприятие 8 согласно Приложения №2…». Приложение 2 содержало мало конкретики, по форме это была спецификация с указанием видов работ и трудозатрат по ним. Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации. Он исходил из буквального значения слов и выражений зафиксированных в договоре, такой же точки зрения придерживался суд, игнорируя факт создания составного программного продукта в рамках выполнения обязательств по договору.
Немного судебной практики:
Статья 431 ГК РФ при толковании условий договора судом принимается во внимание буквальное значение содержащихся в нем слов и выражений. Буквальное значение условия договора в случае его неясности устанавливается путем сопоставления с другими условиями и смыслом договора в целом.
Если правила, содержащиеся в части первой настоящей статьи, не позволяют определить содержание договора, должна быть выяснена действительная общая воля сторон с учетом цели договора. При этом принимаются во внимание все соответствующие обстоятельства, включая предшествующие договору переговоры и переписку, практику, установившуюся во взаимных отношениях сторон, обычаи, последующее поведение сторон.
Вторая ошибка – заведомо не выполнимые сроки исполнения работ. Одним из требований заказчика были очень сжатые сроки на выполнение работ. Заказчик хотел начать эксплуатировать систему сразу после новогодних праздников. Процесс согласования договора затянулся, но сроки выполнения проекта сдвинуты не были. Первый сдвиг сроков произошел по вине заказчика, когда он затянул согласование проектной документации, влиять на это договор не позволял. Также не был учтен возможный внутренний конфликт интересов между службами компании заказчика. В процессе сдачи работ конфликт интересов дал о себе знать. Службы ответственные за принятие работ по своим направлениям не спешили это делать, ссылаясь на текущую загруженность. Также одно из ключевых лиц компании, по инициативе которого был начат проект, потеряло к нему интерес. Что также способствовало организационному сопротивлению. В конечном итоге срок сдачи работ был превышен более чем на 6 месяцев.
Третья ошибка – отсутствие подробного технического задания. Созданное в процессе выполнения работ ТЗ на разработку конфигурации на базе стандартной конфигурации 1С: Предприятие 8 было не достаточно хорошо проработано. Оно содержало только общие сведения о создаваемой конфигурации, а также имело ссылки на функционал (печатные формы, некоторые алгоритмы работы и т.д.) существовавшей ранее у заказчика информационной системы, и которая продолжала в этот момент эксплуатироваться в силу того, что новая информационная система еще не была полностью готова. За время проекта существующая ИС еще и продолжала модифицироваться специалистами заказчика. Соответственно исполнителю приходилось вносить модификации в создаваемую ИС с учетом модификаций старой системы. Все это в совокупности привело к трудностям при сдаче работ.
Четвертая ошибка – исполнитель согласился на требования заказчика внести ряд условий в договор явно не выгодных для себя, но поскольку сроки поджимали и представители заказчика не хотели договариваться по условиям договора руководство ИТ компании приняло решение пойти по пути наименьшего сопротивления. Напомню, это был конец 2014 г., санкции, отсутствие других заказов и т.д, картина типичная для многих небольших ИТ компаний, которые хватаются за любую работу и руководствуются принципом «главное начать, а там просмотрим». Условия договора были сформулированы таким образом, что за каждый день просрочки выполнения работ исполнитель должен был выплатить крупную неустойку. Через некоторое время размер неустойки вырос до такого уровня, что рентабельность проекта стала практически нулевой и неуклонно стремилась стать минусовой. Этому способствовала слабая организация работ внутри проекта, и неспособность оперативно справиться с возникшими проблемами проекта из-за нехватки ресурсов, которые были рассчитаны исходя из прогнозируемого по условиям договора объема работ, и не были рассчитаны на его увеличение. С учетом кабальных условий приходилось идти на компромисс с заказчиком и выполнять все его пожелания. Также ситуация усугубилась за счет того, что для продолжения проекта требовалось внешнее финансирование, привлечение которого было сильно затруднено.
Пятая ошибка – в договоре четко не определена процедура приема выполненных работ. Согласно договору, для подтверждения факта выполнения работ достаточно было предъявить акт сдачи-приемки, при наличии возражений со стороны заказчика, он должен был предоставить исполнителю мотивированный отказ в течение оговоренного в договоре срока. После завершения каждого этапа проекта исполнитель предъявлял заказчику акты сдачи-приемки работ. РП заказчика должен был организовать приемку работ, задействовав для этого соответствующих специалистов. Из-за отсутствия необходимых полномочий РП заказчика не мог и не хотел влиять на сроки приемки работ. Исполнитель также не мог влиять на сроки приемки работ, поскольку договором не была оговорена последовательность действий в процессе приемки и отсутствовала ответственность заказчика за задержки. Исполнителю приходилось прилагать массу усилий для сдачи работ заказчику.
Шестая ошибка – четко не определены правила ведения документооборота в рамках проекта. Стороны не согласовали каким образом будут обмениваться документами и информацией в рамках проекта. Бумажные документы в рамках проекта (проектные, первичные и т.д.) передавались представителям сторон лично в руки без фиксации факта их передачи. Для оперативной передачи документов и коммуникаций также использовалась электронная почта, но подобный способ обмена не был предусмотрен договором. В последствии, когда дело дошло до суда, у сторон не было возможности ссылаться на документы и информацию, переданные по электронной почте, доказать передачу бумажных документов вообще не представлялось возможным.
Немного судебной практики:
Пункт 3 статьи 75 АПК РФ гласит, что документы, полученные посредством факсимильной, электронной или иной связи, в том числе с использованием информационно-телекоммуникационной сети «Интернет», а также документы, подписанные электронной подписью или иным аналогом собственноручной подписи, допускаются в качестве письменных доказательств в случаях и в порядке, которые установлены договором.
Постановление Федерального арбитражного суда Московского округа от 17 мая 2013г. по делу N А40-102005/12-57-977 отказывая истцу в удовлетворении его требований, суд указал на:
• предусмотренную договором простую письменную форму документооборота между сторонами;
• отсутствие условий о возможности исполнения договора по электронной переписке;
• отсутствие ссылок на электронные адреса, определяемые сторонами в качестве допустимых для передачи какой-либо информации;
• невозможность установить принадлежность адреса ответчику и его сотрудникам;
• адрес электронной почты зарегистрирован на домене kameya.ru, который является доступным для использования неограниченным кругом лиц.
Постановлением ФАС дальневосточного округа от16.11.12 №Ф03-5177/2012 был отклонен довод Истца о передаче спорных претензий ответчику по электронной почте. Причинами такого вывода суда послужили как не предоставление доказательств согласования сторонами использования электронных документов в претензионном порядке по спорному договору так и тот факт, что передача претензий по электронной почте не свидетельствует об их получения истцом.
В заключении
- Четко формулируйте предмет договора, чтобы исключить двусмысленное его понимание;
- Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.;
- Указывайте реально осуществимые сроки выполнения работ с учетом времени, необходимого на согласования проектной документации и приемо-сдаточные мероприятия. Предусматривайте увеличение сроков выполнения работ, на случай задержек со стороны заказчика сроков согласования проектной документации или выполнения работ находящихся в его зоне ответственности, а также его ответственность за подобные действия или бездействия;
- Описывайте порядок сдачи работ, документально фиксируйте сам факт передачи заказчику результата работ и документации по проекту (проектной, первичной и т.д.).
- Описывайте порядок коммуникаций, каким образом будет вестись переписка при выполнении работ, указывайте ФИО уполномоченных лиц, их адреса электронной почты, телефоны. Просите подтверждения наличия полномочий у доверенных лиц (доверенность, приказ о наделении полномочиями).
- Кроме того, при заключении договора или при его исполнении рекомендуем избегать прямых ссылок на ГОСТы или иные нормативные документы, это поможет избежать злоупотреблений со стороны заказчика, если созданное вами ПО или проектная документация не будет полностью соответствовать требованиям ГОСТов, если конечно это явно не предусмотрено договором.
- И последняя рекомендация, не поддавайтесь на давление со стороны заказчика ни в момент заключения договора, ни в процессе его исполнения, не соглашайтесь на заведомо не выгодные для вас условия. Лучше откажитесь от контракта, сэкономите нервы и деньги. Работайте только с теми, кто готов выполнять свои обязательства, ну и конечно сами их выполняйте.
Надеемся, что данная статья окажется для читателей полезной и изложенные в статье рекомендации помогут избежать негативных последствий и долгих судебных процессов.
Если есть вопросы задавайте. Если кто-то попал в похожую ситуацию, пишите на адрес itjus@yandex.ru, будем рады помочь, по условиям договоримся.
Комментарии (47)
AstorS1
10.11.2016 23:11Ситуация, когда на два юриста бывает три мнения тоже часто случается. Казус, как говорят юристы.
Decker
11.11.2016 00:18+2Немного непонятен абзац:
«Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации.»
Если заказчик подразумевал под предметом исполнения договорных обязательств установку типовой конфигурации без какой-либо ее модификации, то к чему вообще были доработки? Нестыковка какая-то. Т.е. если заказчик утверждал что ему была нужная типовая конфа без доработок, то фактически она у него уже была и предмет спора как таковой не существовал.
Либо в приведенном абзаце что-то напутано, либо я чего-то не так понял.VolCh
11.11.2016 07:41+1Скорее разная терминология. При работах по платформам типа 1С это не редкость. Заказчик «почему-то» уверен, что купив «коробку» он получил всё, что ему нужно, только надо что-то настроить в Конфигураторе. Что Конфигуратор — это, по сути, полноценная интегрированная среда разработки и
любыеочень многие действия в нём можно отнести если не к dev, то к devops, заказчик просто не в курсе.
itjus
11.11.2016 18:08Предмет договора звучал так: «Заказчик поручает, а Исполнитель принимает на себя работы по поставке и внедрению программного обеспечения 1С: Предприятие 8 согласно Спецификации №1 (Приложение №2 к Договору), являющейся неотъемлемой частью договора».
Спецификация содержит 5 этапов выполнения работ: Поставка ПО, Анализ и проектирование, Обучение пользователей, Настройка и адаптация системы, Опытно-промышленная эксплуатация. Этапы, соответственно кроме поставки ПО, содержали перечень работ, и не все из них можно было однозначно трактовать.
Таким образом, использованные в договоре формулировки позволили Заказчику считать, что была произведена просто настройка стандартной конфигурации 1С: Предприятие без ее модификации.
Toshiro
11.11.2016 05:51+5"… ИТ компания принимает решение начать разработку на основе еще несогласованного ТЗ на свой страх и риск..."
>>> Все остальное можно не читать. Просто кому-то никто не рассказал про ГОСТ34 и РД50. Разработку начинают на основании технического или рабочего (иногда техно-рабочего) проекта (ТП/РП), а вовсе не ТЗ. То что многие компании пытаются «сэкономить» пропуская этот этап и не затрачивая ресурсы на соответствующих специалистов разумеется приводит к идиотским решениям и ситуациям. Скупой платит дважды))dyhmichail
11.11.2016 16:14Полностью согласен. 1С компании им лишь бы продать, рискуют и иногда проигрывают нормальное явление.
polifill
11.11.2016 21:33-1Вы совершенно не в курсе.
1С: Предприятие — это ОЧЕНЬ ГИБКО ДОРАБАТЫВАЕМАЯ система.
Львинная доля бабла идет не с продаж, а с доработок под КОНКРЕТНОГО КЛИЕНТА.
Стоимость доработок может превышать стоимость «коробки» в десятки и даже сотни раз — легко.
vozhd99
11.11.2016 16:15Только в данном случае скупой не собирается платить по договорным отношениям вообще, так как стороной исполнителя не были выполнены условия договора.
Если исполнитель выступает и в роли разработчика ТЗ, то на это должен быть отдельный договор, либо данный пункт должен быть включён в основной договор. Со сроками написания, согласования со стороной заказчика.
FDA
11.11.2016 08:01+2Реально бред какой-то. У меня никогда договор не подписывается раньше ТЗ даде для работ с сроком испольнения в несколько месяцев. Да, бывало, что 2-3 недели тратим на ТЗ, а заказчик потом отказывается от подписания договора. Но это единичные случаи. Зато с готовым ТЗ риски минимизированы. Если уже после начала работ заказчик что-то ещё захочет, то оформляем доп. соглашение. Так ведь спокойнее обеим стлронам договора. К чему лишние риски?
sim-dev
11.11.2016 09:57Возможно, вышенаписанное кому-то и кажется бредом, ибо, как я неоднократно убеждался, IT-специфика настолько специфична, что обитает в собственном каком-то пространстве, слабо граничащим с реальной жизнью. Но в РЕАЛЬНОЙ жизни (не IT) сплошь и рядом заключаются договора с «четкими» календарными планами и «конкретными» сметами каждого этапа, первым пунктом которых (я о пунктах календарного плана и смет) следует «РАЗРАБОТКА ТЗ». То есть в договоре фигурируют конкретные сроки и суммы, а объем работ (который, к слову, определяется ТЗ) не известен. И ничего, работают люди как-то…
P.S. Я это просто в качестве ремарки сказал, для сведения. Я не оправдываю ни коим образом эту порочную практику! Но считаю нелишним «познакомить» IT-сообщество с тем, как живут остальные граждане…FDA
11.11.2016 11:50У нас, кстати, основной профиль фирмы — это разработка и производство электроники. ПО тоже делаем, но это вторично. В РЕАЛЬНОЙ жизни без ТЗ или утверждённых тех. требований договор подписывать я бы лично никому не рекомендовал. Если уж объём работ большой и ТЗ будет разрабатываться месяц или более, то лучше всего составить ОТДЕЛЬНЫЙ договор на разработку ТЗ. Да, заказчик теоретически может второй договор на выполнение работ в дальнешем заключить с другой фирмой, но нужно ли это ему? Реально вероятность этого минимальна.
Лично я всегда стараюсь страховаться по полной. К чему лишние проблемы? Это же бизнес, тут и так дел хватает. Дополнительные разбирательства никому не нужны.
juryev
11.11.2016 08:51+7Простите, конечно, но статья изобилует как орфографическими (что для юриста совершенно недопустимо), так и юридическими ошибками.
Дело для исполнителя вовсе не проигрышное, достаточно посмотреть на обширную судебную практику по аналогичным ситуациям в сфере строительства, проектирования, НИР и прочих договоров подряда.
431-я статья здесь ни при чём. «Пункт 3 статьи 75 АПК РФ» ничего подобного, на что ссылается бредовое постановление 4-летней давности, не гласит. В арбитражных судах совершенно спокойно принимаются в качестве доказательств электронные письма, переписка по скайпу и прочее. Собственно, и раньше, до изменений в законодательстве всё это принималось, только нужно было это правильно оформлять.
По сути этого дела: исполнитель договорился об определённых условиях работы, эти условия корректировались по ходу исполнения. Вопрос только в доказывании наличия корректировок и согласований, — для этого подойдёт электронная переписка, отчёты, обмен документами, комментарии представителей заказчика, телефонные звонки.itjus
11.11.2016 18:12-2ст. 431 ГК РФ была приведена для понимания как суд будет определять предмет договора, если формулировки в договоре размыты и имеют неоднозначное понимание.
А так называемое «бредовое постановление 4-летней давности» вполне жизнеспособно и сейчас. Нам удалось с помощью доводов, изложенных в этом постановлении исключить из числа доказательств по делу всю электронную переписку, предоставленную ответчиком в огромном количестве, а также и другие документы, которые не были предусмотрены условиями договора.
VolCh
11.11.2016 10:03+2Работайте только с теми, кто готов выполнять свои обязательства, ну и конечно сами их выполняйте.
По практике подобных конфликтных проектов разных масштабов и с разных сторон (и подрядчика, и заказчика, и приёмщика — редкая роль, — и планируемого эксплуататора, и генподрядчика, и генсубподрядчика, и независимого технического эксперта) проблема в том, что все стороны уверены, что свои обязательства они выполнили, а вторая сторона — нет. Ну или, что не смогли выполнить свои обязательства по вине действий или бездействия другой стороны. И чаще всего это искренняя, насколько могу судить, уверенность, которую лишь пытаются обосновать другим сторонам договора, а также третьим лицам, включая суды, различными доказательствами.
Основная причина, по-моему, настаивание заказчика на фиксированной цене и сроках без чёткого определения фронта работ (или на старте чёткое, а потом вносятся уточнения, изменения, дополнения и т. д.) и согласие на то исполнителя без реалистичных оценок рисков увеличения планируемой трудоёмкости, а то и без реалистичной оценки трудоёмкости в принципе, относясь к фразам о неустойке в договоре как к формальности, «но мы же не такие, чтоб срывать сроки по субъективным причинам, а заказчик поймёт объективные трудности». С другой стороны, зачастую исполнитель настаивает на начале эксплуатации сырой разработки (субъективно исключительно в надежде, что заказчик перейдёт точку невозврата и по любому доведёт внедрение до устраивающего исполнителя этапа), причём не просто сырой, а с отсутствующей функциональностью, вместо предложения пересмотреть сроки ввода в эксплуатацию, надеясь на то, что особых проблем не будет, а они почти всегда появляются и «переключили оставшуюся часть разработчиков на тушение пожаров» вполне закономерно. То, что можно было выявить и исправить в течение нескольких итераций «попытка сдачи»-«багфиксинг», потратив лишь время нескольких людей, приходится делать в ходе уже запущенных процессов эксплуатации, зачастую срывая бизнес-процессы эксплуататора, что приводит, как минимум, к недополученной здесь и сейчас прибыли, а то и прямым расходам, не говоря о потери репутации перед клиентами, когда им вынуждены отказывать в обслуживании или безосновательно требовать с них больше чем они обязаны по договору или сложившимся обычаям в отношениях.
Для всех сторон договора на индивидуальную разработку/настройку ПО следует принять за аксиому, что на этапе заключения договора оценить сроки, трудозатраты, себестоимость для исполнителя и прочие значимые метрики процесса невозможно так, чтобы всех устроил конечный результат, кроме разве что самых тривиальных случаев, поставленных на поток. Процессы разработки, передачи в эксплуатацию и поддержки должен быть изначально построены на том, что видение заказчика о конечном результате будет понято исполнителем на старте проекта неправильно, а при сколь-нибудь значимых сроках или просто отсутствии у заказчика опыта эксплуатации подобного ПО оно будет меняться, а значит любые предварительные оценки сроков и трудоёмкости будут не реалистичными. Если заказчик настаивает на фиксированных сроках и стоимости с различными видами неустоек вплоть до отказа принимать работу в принципе и компенсации полного ущерба даже если просрочка составила один день (реальные случаи), то в сроки и стоимость нужно закладывать все типичные, практически гарантированные риски, как-то:
— задержки с чёткими формулировками требований
— изменения требований в процессе разработки
— неправильное понимание исполнителем даже вроде бы чётко сформулированных требований
— регрессии
— задержки с тестированием и приёмкой
— нетривиальные баги
— траты ресурсов на обучение и поддержку
— просьбы заказчика о жестах доброй воли в счёт дальнейшего сотрудничества
— …
Durimar123
11.11.2016 13:45+1Внедрение в новый год, без ТЗ, но с обязательствами…
ИМХО любому понятно, что засада.
Как любит поговаривать Мавроди: «Лох не мамонт — не вымрет.»
drontgtn
11.11.2016 14:56Имели ли Вы практику работы по зарубежным компаниям? В частности, одна крупная узкоглазая контора повадилась не платить за выполненные работы. Притом контракт есть, работы выполнены в срок, по качеству претензий не поступало, но как только пишешь им об оплате — начинают отмазываться, говорить да-да, конечно конечно, сейчас всё будет, неделя опять молчок, GOTO 10.
itjus
11.11.2016 15:02Чтобы дать подробные рекомендации, о том как поступить в Вашей ситуации нужна более подробная информация.Просим предоставить контактную информацию, чтобы мы могли с вами связаться и обсудить Ваш вопрос более детально.
SergeyUstinov
11.11.2016 16:04+1Станьте ёжиками! :)
«Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.»
Такое ТЗ может появиться после Обследования, Анализа и Дизайна, а это 40-60% всего проекта внедрения.
Если внедрять типовую Бухгалтерию с переделкой пары печатных форм — да, можно такое ТЗ написать ДО старта проекта. Но если что-то более объемное — такое ТЗ можно написать только после выполнения большей части работ.
ClosedSneaky
11.11.2016 16:07+1Проблема в том, что в сфере оказания услуг по настройке
ПО фирмы 1С имеет место систематическая подмена понятий.
Писать надо было в договоре:
Исполнитель обязуется оказать следующий перечень услуг:
1) консультационные услуги в объеме x часов
отв.: Иванов И.И. (1С: Специалист-консультант по прикладным решениям «1С: Предприятие 8» )
2) услуги в объеме y часов по настройке конфигурации такой-то
Отв.:
2.1 Петров П.П. (Специалист" по платформе «1С: Предприятие 8»)
2.2 Сидоров С.С. (1С Специалист по конфигурации такой-то)
3) информационно-технологическая поддержка, период: столько-то месяцев
Отв.:
ФИО ( профессионал по ...)
Копии сертификатов в приложении № таком-то
А то развели антимонию, понимашь: «ТЗ», «по госту».
Это же не сишечка, никакого выхлопа в виде «составного программного продукта», вам принадлежащего у вас нет.
lyderisaz
11.11.2016 16:09+2будем рады помочь, по условиям договоримся
похоже помощь требуется Вам, по условиям договоримся ;)
mortimoro
11.11.2016 16:11+2Меня жизнь уже научила не браться за работу, пока нет четкого ТЗ, в котором каждый пункт не вызывает сомнений. И я всегда делаю наценку из расчета доработок — заранее все предусмотреть нельзя, потому наверняка клиент захочет внести не оговоренные ранее правки. Психология человека устроена так, что ему гораздо приятнее заплатить сразу 400$ и заниматься только творческим процессом, пока продукт не будет доведен до совершенства, чем заплатить 300$ и затем доплачивать по 10$ за каждую дополнительную правку — так у него складывается ощущение обмана.
Еще для себя я выработал правило: не работать с мудаками. Если человек начинает со мной торговаться, я сразу отказываю ему в своих услугах. Правда я работаю только для себя и мне не приходится извращаться, чтобы прокормить бригаду разработчиков, потому имею возможность отказаться от клиента если он мне неприятен.
Тем не менее, статья для меня была полезна — я очень часто упускаю приведенные в ней нюансы, даже не задумываясь об этом. Хоть я и не терплю убытки в семизначных цифрах, но часто трачу время на то, на что можно было не тратить, если бы заранее проработал детали.
DarkTiger
11.11.2016 16:13+3Собственно, ни о чем. «Читайте ТЗ внимательно, читайте договор внимательно» — вот и все.
Мне в подобной ситуации очень помогли юристы, которые в теме были ни уха не рыла. Читаем договор, они просили разъяснить каждую деталь. Вначале я их готов был придушить, потом стал серьезно уважать. Поскольку если они что-то не поняли, то суд уж точно не поймет :)
Было примерно так:
— А что такое «образец»?
— А что такое «работает в соответствии с ТЗ»? (кстати, это я им объяснить так и не смог)
— А если параметры окажутся быстрее заявленных, возможно ли отложить платеж до исправления недостатков?
— Почему не указан способ доставки в терминах Incoterms? Зачем вы здесь полстраницы лирики написали?
— Как мы докажем, что устройство работает или не работает правильно? У нас есть сертифицированные средства измерений?
И так, блин, 3 месяца каждый деньFDA
11.11.2016 17:23Один заказчик тоже пытался придраться с вопросом: «Докажите, что разработанное устройство работает как нужно». Мы ему указали на разделы ТЗ, где были чётко прописаны требования к техническим характеристикам устройства, а также методика приёмки и проведения испытаний. Плюс у нас имелись все необходимые измерительные приборы с действующей поверкой.
Заказчик был приятно удивлён, после этого подобных вопросов больше не возникало. Кстати, он ещё и постоянным нашим клиентом стал :-)DarkTiger
11.11.2016 20:00Попробуйте сделать это для кастомного модуля памяти DDR3 хотя бы. Я уж не говорю про программно-аппаратные средства сложности выше среднего, типа InfiniBand свича или материнки. Да и обычный гигабитный Ethernet роутер может столько геморроя принести, если его испытывать по полной…
FDA
11.11.2016 21:03+1Вы наверное электронику никогда не разрабатывали. Поверьте, сделать можно всё. Нужны только материальные ресурсы и время. Плюс, как я уже писал выше, методика приёмки согласовывается заранее. В ней Вы можете прописать что угодно от простого включения устройства до обширного набора тестов. Вот тут и нужна конкретика, чтобы потом не было мучительно больно сдавать разработку заказчику
DarkTiger
13.11.2016 10:45Да, конечно, и ПМИ тоже никогда не писал :)
Сделать можно все, вопрос, сколько это будет стоить. Не денег даже, а времени специалистов. А есть контрактные обязательства, в которых время прописано.
Для блока питания нужен один подход, для сложной электроники — совсем другой.
Я не хочу меряться, хм, интеллектами, но посмотрите на материнку и представьте себе ПМИ для нее.
Это я к тому, что иногда приходится поступаться перфекционизмом и работать с заказчиком как с партнером, на чистом доверии. Всякое бывает.
hdkr
11.11.2016 16:49-3Спасибо автору статьи и всем кто оставил комментарии с личным опытом. Было очень полезно почитать всё это.
itjus
11.11.2016 17:32-2Большое спасибо за дельные комментарии.
Хотим еще добавить. Позади уже год судебных разбирательств по описанной в статье ситуации, дело близятся к своему логическому завершению. На данный момент пройдено две судебные инстанции. Суд первой инстанции вынес положительное решение в нашу пользу в части взыскания задолженности по работам практически в полном объеме. Суд апелляционной инстанции оставил данное решение без изменения. Рассчитываем на то, что и суд кассационной инстанции оставит это решение без изменения. Но для того чтобы повернуть дело в нашу пользу пришлось приложить достаточно много усилий, особенно на стадии подготовки дела к суду.
Greendq
13.11.2016 01:22Мне интересен этот момент: «Условия договора были сформулированы таким образом, что за каждый день просрочки выполнения работ исполнитель должен был выплатить крупную неустойку. Через некоторое время размер неустойки вырос до такого уровня, что рентабельность проекта стала практически нулевой и неуклонно стремилась стать минусовой. » — неужели у вас законодательство позволяет выставить пени и штрафы, более стоимости контракта? У нас (Молдова) законодательно не разрешается указывать более 10% штрафов от стоимости контракта и пеня не может превышать 0.1% в день. Сделано специально, чтобы не маскировать займы под штрафы.
polifill
13.11.2016 10:13А зачем такая защита от государства?
Ты что, сам дурак, и не видишь что подписываешь?
merlin-vrn
13.11.2016 12:09Где написано, что это защита от государства? Прямо же сказано,
Сделано специально, чтобы не маскировать займы под штрафы.
polifill
13.11.2016 16:04Защита, предоставляемая государством = защита от государства
Разумеется, речь не идет о защите государством от нападения государства же — это было бы нелогично.merlin-vrn
14.11.2016 09:15ну, а речь идёт о защите государства от недобросовестных предпринимателей, маскирующих займы под пеню, а не предпринимателей от государства
itjus
13.11.2016 15:36Российское законодательство не устанавливает предельные суммы начисленных пеней (неустойки) и в некоторых случаях пени могут превысить сумму контракта. Размер пеней (неустойки) может быть снижен судом на основании статьи 333 ГК РФ, но только при наличии соответствующего заявления со стороны ответчика. Также размер ответственности должника может быть снижен, в соответствии с п.1. ст. 404 ГК РФ, если неисполнение или ненадлежащее исполнение обязательства произошло по вине обеих сторон. Суд также вправе уменьшить размер ответственности должника, если кредитор умышленно или по неосторожности содействовал увеличению размера убытков, причиненных неисполнением или ненадлежащим исполнением, либо не принял разумных мер к их уменьшению.
Psih
15.11.2016 03:21Это, помоему общеевросоюзное. У нас в Риге тоже самое — 0.1% в день и не более 10% в общем.
Greendq
15.11.2016 09:43Вполне вероятно, так как наши гармонизируют законодательство с ЕС уже довольно давно. Знакомый юрист объяснял эту фишку с процентами тем, что обычно со штрафов не платят налоги и там можно как-то хитро сэкономить, если займ оформить как вот такой «просроченный» контракт.
Psih
15.11.2016 03:16+1Не ленитесь и дайте составить договора юристу, который занимается поддержкой ИТ компаний (т.е. специализируется или если это фирма, у них это одно из крупных направлений), опишите свою специфику, смотрите как ваши клиенты реагируют и какие ситуации возникают, и отправляйте на следующую итерацию обновлений.
Сэкономит кучу нервов, особенно если сами будете следовать условиям своего договора и вовремя нотифицировать по e-mail и/или почтой с вручением в руки о том, что клиент там, там и там то не успел, то не выполнил, тут затянул.
Ну а если проект более-менее значительный (больше месяца-двух работы), составляйте хотя-бы небольшой описание, а в идеале вообще делайте дополнение к договору с перечнем работ. Это гораздо проще, чем кажется на первый взгляд, требует час-полтора в первый раз, в последующие разы уже от 30 до 60 минут вполне укладываешься.
А про ТЗ вообще нужно вписывать пункт в договор прямо — нет ТЗ, значит ограничиваете возможность клиента выставлять претензии и закладываете 5-10-15% доплаты по контракту. В проектах по крупнее им будет дешевле оплатить разработку ТЗ, нежели платить дополнительные 15% от стоимости.
capjdcoder
Могу пожелать только удачи и хорошего юриста. Хорошо, что на будущее свои ошибки уже увидели.
Greesha
Посоветовать юристу юриста — это уже рекурсия получается. :)
woodhead
Хорошего юриста.