Как дорабатывать договор чтоб видеть все исправления

Отслеживание изменений и отображение исправлений

Кнопка

Совет. Видео не на вашем языке? Попробуйте выбрать Скрытые субтитры .

Проверьте, как это работает!

Включите функцию «Исправления», чтобы отобразить все изменения в документе, а также — функцию «Показать исправления», чтобы увидеть все интересующие типы исправлений.

Отслеживание исправлений

Чтобы отслеживать изменения, на вкладке Рецензирование нажмите кнопку Исправления. Внесите в документ необходимые правки, и они будут записаны в Word.
Чтобы перестать отслеживать изменения, на вкладке Рецензирование нажмите кнопку Исправления. Новые изменения перестанут фиксироваться в Word, а уже внесенные останутся отмеченными в документе.

Показать исправления

На вкладке Рецензирование щелкните в раскрывающемся списке «Исправления» стрелку вниз Отобразить для проверки.
Выберите подходящий вариант.
- Исправления: в этом режиме строки, в которых были внесены изменения, обозначаются красными линиями на полях.
- Все исправления: в этом режиме каждое исправление в тексте выделяется другим цветом и подчеркиванием.
- Без исправлений: в этом режиме обозначения исправлений скрыты и документ отображается после принятия всех изменений.
- Оригинал: в этом режиме документ отображается в исходном виде.
В раскрывающемся списке Показать исправления выберите интересующие типы исправлений.
- Примечания
- Добавления и удаления
- Форматирование
- Выноски
- Конкретные пользователи

Как работать с текстом и правками клиентов: советы копирайтерам

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

Как работать с текстом и замечаниями заказчиков, чтобы не переписывать текст по несколько раз и не оставить клиента недовольным?

Как минимизировать правки до начала работы

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

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

Еще до начала сотрудничества проговорите, сколько кругов правок вы готовы сделать. Если работаете с клиентом первый раз, то объясните ему, что значит “круг правок”.

Круг правок — это исправления, которые вы вносите один раз. Вы отдаете написанный текст заказчику. Заказчик говорит, что нужно изменить, и возвращает текст. Вы вносите все правки и снова отдаете текст клиенту. На этом первый круг правок закончен.

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

Брифуйте клиента, чтобы получить четкое техническое задание. Иногда заказчикам сложно выразить словами, что именно они хотят видеть в тексте. И ваша задача — помочь им сформулировать свои мысли. Для этого и существуют брифы. Заказчики без труда отвечают на конкретные вопросы, а вы получаете четкую и понятную информацию, на основе которой можете написать хороший текст.

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

Перед тем как писать текст, изучите всю доступную информацию. Не только ту, которую присылает вам клиент. Найдите сайт компании, ее профили в соцсетях, отзывы клиентов компании на сайтах-отзовиках и т.д. Все это поможет вам сделать текст максимально полезным и интересным.

Работайте поэтапно. Сначала согласуйте с клиентом идею, потом план текста, потом сам текст. Так проще будет скорректировать работу, если на каком-то этапе вы с заказчиком неверно поймете друг друга.

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

Если правильно провести предварительную работу с заказчиком и получить от него максимум информации, то правки могут вообще не понадобиться.

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

Как работать с замечаниями клиентов

Иногда фрилансеры расстраиваются и раздражаются, когда заказчик оставляет в тексте подчеркнутые предложения или даже целые абзацы, которые надо исправить. Еще бы! Не очень-то приятно признавать, что твоя работа не понравилась.

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

Прочитайте все комментарии заказчика, но не спешите сразу же исправлять текст. Созвонитесь с клиентом и узнайте, что именно надо переделать. Так проще всего понять, что конкретно не устраивает заказчика. В переписке он может отвечать на ваши вопросы непонятными фразами, вроде: “Добавьте деталей и красок”. А в живом разговоре вы сможете сразу же направить беседу в нужное русло и уточнять хоть каждое произнесенное заказчиком слово. Это поможет вам понять, как работать с текстом дальше.

Внимательно выслушайте все замечания клиента и для себя разделите их на 3 категории:

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

Что делать с каждой категорией правок — понятно по их названию.

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

Если понимаете, что правки сделают текст хуже, объясните это клиенту. Не с позиции: “Ты ничего не понимаешь в текстах”. Просто вежливо аргументируйте свое мнение. Если бы заказчик сам во всем разбирался, он бы не обратился за помощью к специалисту. Поэтому вы имеете право сказать, как будет лучше и почему.

Если вы объяснили клиенту свою позицию, а он все равно настаивает на своем — сделайте так, как он просит. Но объясните риски, расскажите, что сработает, а что нет.

Обсуждайте правки с клиентом, проводите совместную работу. Вы не должны противостоять друг другу, наоборот — всеми силами помогать. Возможно, вместе вы придумаете что-то такое, к чему не пришли бы поодиночке. И в итоге заказчик получит крутой результат для своего бизнеса, а вы зарекомендуете себя как хороший специалист.

10 золотых установок при работе с правками

Если вам неприятно всякий раз, когда клиент присылает вам текст для исправления, постарайтесь научиться воспринимать эту ситуацию по-другому. При работе с правками повторяйте:

Правки — это не критика, а пожелания.
Заказчик знает свой бизнес гораздо лучше меня.
Клиент не издевается, он хочет получить хороший материал.
Клиент не всегда прав, но к нему надо прислушиваться.
Все люди разные, поэтому невозможно быть идеальным исполнителем для каждого.
Заказчики правят сам текст, а не меня как специалиста.
Если клиент вносит правки, значит, он внимательно читал текст и заинтересован в результате.
Если правок много, это не значит, что текст плохой.
Не надо исправлять все бездумно. Лучше согласовывать правки и задавать вопросы заказчику.
Правки помогают мне взглянуть на текст с другой стороны и расти как специалисту.

Правки — это часть работы копирайтера. Не стоит расстраиваться, если клиент не принял текст с первого раза. Помните, что вы с клиентом не враги и не пытаетесь выяснить, кто круче. У вас одна цель. Вам не нужно никому ничего доказывать и пытаться переспорить заказчика. Ваша задача — самому понять, как работать с текстом, донести свою точку зрения до заказчика и сделать так, чтобы и вы, и клиент остались довольны сотрудничеством.

Как дорабатывать договор чтоб видеть все исправления

(9) и (10)
даже если взять просто вариант: юрист сам стартует компл процесс, затем идет согласование, на котором юристу приходит задача ознакомление с результатами согласования, где он может распечатать лист согласования.
Затем явно идет процесс утверждения, так вот директору необходимо видеть этот лист согласования. расскажите как у вас настроено? Юрист печатает лист согласования и как файл добавляет его в предмет процесса? И тогда директор видит лист согласования?

Если пользователь имеет доступ к внутреннему документу, то ему доступна и вся ветка процессов и задач по этому документу. Соответственно, директору ничего не мешает самому нажать на печать листа согласования либо посмотреть дерево процессов на закладке «Процессы и задачи».

(13) а не проще включить визы согласования и смотреть/печатать лист согласования сразу из внутреннего документа? Доступ к документу не обязательно даст доступ ко всем процессам по документу.

(14) визы включены. Пользователю лень заходить во внутр документ и нажимать закладку визы. С этим разобрались. спасибо. Либо смотрим в справочнике, либо пишем кнопку на задаче. которая работает как кнопка в справочнике.
Еще вопрос, если позволите.
У меня комплексный процесс. Стартует его пользователь.
Внутри есть процесс согласования. Задача «Ознакомление с результатами согласования» поступает пользователю, стартовавшему процесс. А как можно настроить, чтобы эта задача приходила в юридическую службу? У нас именно юристы отправляют на повторное согласование.

(15) Можно поставить в шаблоне согласования автором какого нибудь человека из юр отдела. На сколько помню автором может быть только пользователь, роль или группу не поставить.

(16) в Автоподстановках нет автора шаблона.
Решила сделать следующим образом:
1. пользователь стартует комплексный процесс «Заявка на создание договора с контрагентом», прикрепляет нужные документы по контрагенту. Поступает задача начальнику юр отдела, создать элемент спр. Внутренние документы, тут заполняемый объект- спр внутр . документы. Начальник перенаправляет на нужного ему юриста. Юрист создает внутр документ, указывает ответственного (пользователя, который стартовал процесс), вносит сам договор, регистрирует его вручную (это юр так решили). при регистрации документа внутр. стартует компл процесс «Согласование договора», в котором инициатор уже юрист, а пользователь лишь — ответственный за документ (он есть в автоподстановках). Первый процесс завершается, когда юрист нажимает кнопку исполнено. Второй идет по согласованию, основной предмет в этом процессе — внутр. документ. таким образом, во внутр документ. автоматом подставляются визы при согласовании и меняется его статус.
Если у кого есть замечания, прошу.

Касаемо (15) — у нас в комплексном процессе добавляется процесс «Ознакомление» на тех этапах, где требуется. Т.е. может быть: 1) Согласование (руководитель ЦФО, бухгалтерия, кто-то еще) 2) Ознакомление (перечень сотрудников) 3) Регистрация (отдел делопроизводства) 4) Согласование (юридический отдел) 5) Утверждение (например, ген. дир).

Задача «Ознакомление с результатом. » во внимание не принимается, просто она есть для уведомления пользователя, стартовавшего процесс.

В комплексном процессе можно указать лицо, контролирующее ход процесса. Ему будет создана соответствующая задача. По умолчанию это автор самого процесса.

(18)Спасибо за развернутый ответ. Почему я привязалась к этой задаче «Ознакомление с результатами согласования»? тк мне необходимо, чтобы юристы могли отправлять несколько раз договор на повторное согласование. Мне нужно сделать, так что если есть замечания, повторное согласование обязательно. Хочу реализовать это через процесс согласование и задачу «Ознакомление с результатаи согласования». Может быть есть другой путь, который я не вижу?

(19) Если у Вас в комплексном процессе настроено следующим образом:

1) Процесс согласования
— сотрудник А
— сотрудник Б (после согласования сотрудником А, либо паралельно с ним)
— и т.п.
2) Любой другой процесс (утверждение, ознакомление, исполнение)

то, при отклонении задачи согласования сотрудником А или Б процесс не пойдет далее в пункт 2) и вернется автору с причиной отклонения. Соответственно автор после исправления замечаний может повторно стартовать комплексный процесс, но уже вручную удалив в нем из пункта 1) тех сотрудников, которые ранее согласовали и оставив только тех кто отклонил.

(20)Все верно. ТОлько в моем процессе на доработку документ должен возвращаться юристу. Значит юрист должен быть автором.

(21) Вы можете в момент когда один из сотрудников в пункте 1) имеет замечания стартовать дополнительный процесс (не обязательно комплексный), который будет направлен юристу с текстом того, что нужно исправить. После его завершения и проверки сотрудник, который направил замечания, может выполнить свое согласование.

Читать:

Какой телевизор лучше самсунг или филипс

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

6 типичных ошибок при заключении договоров на разработку ПО

В очередной раз хотим затронуть тему, когда компания разработчик ПО выполняет свою работу, но заказчик не хочет ее оплачивать. И судя по количеству публикаций на подобную тему, актуальность данного вопроса для отечественных разработчиков ПО растет.

Описанная ниже ситуация — это ситуация из жизни. В момент написания статьи данная ситуация еще не получила окончательного положительного разрешения для компании разработчика ПО (далее будем называть ее ИТ компания, название компании в данный момент раскрыть не можем), с которым мы работаем вот уже более года по взысканию семизначной суммы задолженности. Возможно, для кого-то данная статья окажется полезной и позволит избежать подобной участи, либо позволит минимизировать возможные потери если ситуация еще не сильно запущена.

Предыстория

В конце 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, будем рады помочь, по условиям договоримся.

Отслеживание изменений и отображение исправлений

Проверьте, как это работает!

Как работать с текстом и правками клиентов: советы копирайтерам

Как минимизировать правки до начала работы

Как работать с замечаниями клиентов

10 золотых установок при работе с правками

Похожие статьи

Как дорабатывать договор чтоб видеть все исправления

6 типичных ошибок при заключении договоров на разработку ПО

Предыстория

Выявленные ошибки

В заключении

Похожие записи