Подрядчик столкнулся с нехваткой объема работ. Должен ли я выполнять ни один, некоторые или все запросы клиента?

Я подрядчик в проекте по разработке программного обеспечения, который является чем-то вроде кошмара и страдает от Scope Creep .

Предыстория:
Я взялся за проект по разработке веб-приложения для клиента. Я должен был работать с разработчиком, сотрудником клиента, который, как я думал, был опытным разработчиком, но, как оказалось, имел очень ограниченные знания в веб-разработке. Устное соглашение заключалось в том, что другой разработчик будет делать весь интерфейс (HTML, CSS, JavaScript). Мои ошибки включают (но не ограничиваются);

  • согласие на ускоренный график проекта (я сказал 12 недель, но меня сократили до 4 недель),
  • фиксированная цена проекта, думая, что другой разработчик может внести свой вклад
  • соглашаясь на проект, не заставляя их четко излагать все свои потребности (анимация, интеграция webgl и т. д.).

Прошло 6 недель, и я реализовал функции, указанные в контракте (5 шаблонов, аудиофункция, настраиваемые сообщения, интеграция настраиваемых полей).

Проблемы:

  • Клиент продолжает добавлять новые запросы. Он считает их расширениями/изменениями функций, которые я согласился сделать в контракте, но на самом деле эти изменения требуют значительного времени.
  • Разработчик вносит ошибки.
  • Разработчик должен поддерживать проект после моего ухода, но у него нет навыков или опыта даже для его развертывания.
  • Я пытался обучить его развертыванию. В настоящее время у него проблема, из-за которой он не может скомпилировать проект в рабочем режиме, но у меня он отлично работает на 2 разных компьютерах и ОС. Он не может это исправить, поэтому и он, и клиент думают, что это мой проект.

Что я хочу сделать:
на данный момент я хочу оставить их с проектом как есть. Это неприятно, но я считаю, что реализовал функции, указанные в контракте. Я выставил счет клиенту двумя частями, 50% через 2 недели (которые были оплачены) и еще 50% через 3 недели после этого (еще не оплачены). Я готов отказаться от второй части, и, надеюсь, это убережет от судебных исков, даже если моя репутация может пострадать.

Какие действия мне доступны? Должен ли я или я обязан решить проблему младшего разработчика? Если младший не может это исправить, клиент не может поддерживать/развертывать проект.

Стоит ли отказываться от оказания техподдержки разработчику? Должен ли я согласиться на некоторые изменения, которые хочет клиент? Должен ли я сказать «нет» всем им?

Соглашение только устное? Имейте в виду, что на юридические последствия лучше ответить в другом сообществе Exchange.
@MrRipstein спасибо за ваш комментарий. Мне нужны этические и практические советы, а не юридические. Имеется письменный подписанный контракт с указанием общей суммы гонорара, списка функций/элементов, которые должны быть произведены (расплывчато), срок выполнения проекта (уже пройден).
Ваш вопрос может быть более актуальным (и получить более подробные ответы) на сайте freelancing.stackexchange.com.
Есть ли в договоре описание результатов? И никакие «Сделай мне сайт» за один не считаются, потому что содержание сайта неоднозначно.
@ValarMorghulis Да, в нем перечислены результаты. Такие вещи, как A responsive website, Should be a progressive web app, A case study page that details X vision and approach, The ability for non-technical users to create custom posts, Compatibility across IE11+, FF (last 4 versions).... В списке 14 результатов/функций.
@ mk11 похоже, ваш список результатов все еще слишком неоднозначен. Что означает «отзывчивый веб-сайт»? Полностью реагирует на любое разрешение или до определенного предела? Это всего лишь пример, но когда вы делаете проект с фиксированной ценой, вы должны быть предельно конкретны в том, что вы собираетесь доставить .
Выполняете ли вы в настоящее время работу, выходящую за рамки этого контракта, и не получаете за это деньги? Не делай этого.
«Я сказал 12 недель, но они сократили меня до 4 недель» — вау.

Ответы (2)

Один из моих наставников имел долгую карьеру в области заключения договоров и объяснил мне некоторые общие принципы, которые хорошо работали на протяжении всей их карьеры и в моем опыте (хотя у меня ограниченный опыт заключения договоров):

  • Сделайте все возможное, чтобы получить четкие требования. Дважды и трижды проверьте их заранее.
  • Каждый раз, если это не занимает менее 5 минут, когда вас просят сделать что-то, чего нет в контракте, вы должны об этом говорить, даже если вы собираетесь это сделать. Удовлетворенность клиентов огромна, и если вы собираетесь дать кому-то что-то, вам нужно убедиться, что они знают, что вы делаете им одолжение, и это позволит вам использовать это как рычаг в других переговорах. Когда вы собираетесь это сделать, используйте такие формулировки, как: «Это не было частью нашего первоначального соглашения, но, возможно, я могу помочь».
  • Избегайте выполнения какой-либо значительной работы, которая не была конкретно указана в первоначальном соглашении. Если вы дадите людям что-то бесплатно, они будут меньше вас ценить (это бессмысленно, но это правда).
  • Не будь слабаком. Если вы выполнили свой контракт, требуйте оплаты в полном объеме. Не предлагайте потерять 50% денег, которые они должны вам, потому что их разработчик некомпетентен и они хотят что-то бесплатно.

Чтобы конкретно применять эти принципы, вы должны:

  • Объясните, что вы завершили все части проекта, предусмотренные в контракте.
  • Объясните, что человек, работающий с их стороны, не выполнил свою часть контракта.
  • Перечислите всю проделанную вами работу, которую должен был выполнить ваш коллега в их организации, а также всю работу, которую вы проделали помимо контракта.
  • Требуйте оплаты в полном объеме, прежде чем приступать к дальнейшим работам над проектом.
Небольшое замечание: у моего знакомого начальника отдела видеопроизводства была система. У него было четыре ламинированных синих карточки с надписью «Кстати» крупным жирным шрифтом. Когда парк и мощность были готовы, он отдавал карты продюсеру. Он сказал им: «Кстати, вы получаете 4 балла за вещи, которые вы забыли указать в требованиях. Я вообще не буду жаловаться, но каждый из них стоит вам карты. Когда ваши карты закончились, все готово». Решил много проблем и заранее установил четкие ожидания.
Я бы не решился делать карты, так как некоторые вещи, которые вы забудете, могут увеличить объем проекта, по крайней мере, для CS: «кстати, мне это нужно для интеграции с нестандартной базой данных». Но мне нравится, что он четко устанавливает ожидания и вызывает всякий раз, когда добавляется что-то новое.
Не пытаюсь предложить это как конкретный план. Я пытаюсь сказать, что если вы заранее установите ожидания, вы все станете счастливее. Вы должны позволить некоторую гибкость, но вы должны держать ее управляемой.

ИАНАЛ , но:

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

Однако, ЕСЛИ вы считаете, что некоторые части контракта все еще остаются невыполненными, вам следует привести их в порядок как можно быстрее и уйти.

Я не вижу ничего неэтичного в том, чтобы оставить законченный проект только потому, что клиент хочет большего. Они должны знать лучше, чем заключать контракт, который не совсем то, что они хотели. Это жизнь, они получили то, на что согласились.

Подрядчик столкнулся с нехваткой объема работ. Должен ли я выполнять ни один, некоторые или все запросы клиента?
СпросиСетьПолитика конфиденциальности1y, 0v