Comments 28
Хорошая статья. Но договор договором, а если заказчик не собирается исполнять договор? Или платит большие деньги, но при этом хочет свою форму договора?
Насколько я понимаю, если какая либо сторона не соблюдает условия договора, то на нее можно подать в суд.
Форма договора может быть любая, но в любом случае, договор должен составляться на взаимовыгодных условиях, иначе вы рискуете, остаться и без этих больших денег.
Форма договора может быть любая, но в любом случае, договор должен составляться на взаимовыгодных условиях, иначе вы рискуете, остаться и без этих больших денег.
Поэтому и описаны этапы 2 и 3, насколько я понимаю. А если заказчик хочет свою форму договора, то имеет смысл либо вносить туда те пункты, без которых вы принципиально не согласны работать, либо, если это не получается, просто отказываться от заказа. Такая история грозит вам очень большими рисками, даже несмотря на «платит большие деньги».
Что делать в случае неисполнения договора заказчиком каждый может определить для своей компании сам: судиться, договариваться, разрывать договор.
Главный вопрос — почему заказчик его не исполняет, возможно ответ на этот вопрос даст решение.
Другая форма договора — почему нет, если большие деньги полностью нивелируют все возможные риски. Если нет и вы не можете туда добавить то, что важно для вас, лучше отказываться от такого договора.
Опять же, нет никакого универсального метода (договора), который позволит решить все проблемы раз и навсегда.
Главный вопрос — почему заказчик его не исполняет, возможно ответ на этот вопрос даст решение.
Другая форма договора — почему нет, если большие деньги полностью нивелируют все возможные риски. Если нет и вы не можете туда добавить то, что важно для вас, лучше отказываться от такого договора.
Опять же, нет никакого универсального метода (договора), который позволит решить все проблемы раз и навсегда.
По поводу «поиграться шрифтами»: я плохо понимаю, как дизайн можно загнать под ТЗ. Имхо, невозможно регламентировать творчество, а дизайн — это творчество, которое преследует определенные цели.
Имеется в виду что клиент начинает докапываться до дизайна по мелочам, вносить различные правки, которые замедляют процесс сдачи проекта. А на счет загонять дизайн в ТЗ — без этого никак, не выкидывать же этот пункт полностью из документа, иначе его никто не оплатит. Тут возможно берется сложность проекта, опыт ответственного дизайнера, его консультация по времени, так примерно и прикидывается.
Например, архитектура (строительство домов) — это вещь и творческая, и предельно регламентированная.
То же самое и с сайтостроением. Если правильно выстроен процесс, то там творчество находится на своём месте, а инженерия на своём.
Процессы создания дизайна хорошо можно рассказать на предпроектной презентации, объяснив чем грозит игра со шрифтами и какую цель несет дизайн.
Как я уже писал выше, нельзя выстроить стену, которая раз и навсегда оградит от всех проблем…
То же самое и с сайтостроением. Если правильно выстроен процесс, то там творчество находится на своём месте, а инженерия на своём.
Процессы создания дизайна хорошо можно рассказать на предпроектной презентации, объяснив чем грозит игра со шрифтами и какую цель несет дизайн.
Как я уже писал выше, нельзя выстроить стену, которая раз и навсегда оградит от всех проблем…
Тоже пришли к выводу, что прописывать заранее необходимо как можно больше. И зачастую даже не для того, что бы потом иметь возможность “махать кулаками“, а для того, что бы заказчик сам понимал как и что будет делаться. Ибо вы на 100% правы, что ЛПР зачастую даже не читают договор.
Интересно, что именно у вас является результатом работ по завершении этапа Проектирование?
По результатам проектирование:
1. Интерактивный прототип.
2. Отчет о тестировании прототипа фокус-группой (если в процессе тестирования выявлены нарушения сценариев использования, они устраняются и тестирования проводится вновь).
3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
1. Интерактивный прототип.
2. Отчет о тестировании прототипа фокус-группой (если в процессе тестирования выявлены нарушения сценариев использования, они устраняются и тестирования проводится вновь).
3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
Честно говоря не понял про ТЗ, которое может меняться в процессе проектирования. Имелось ввиду, в процессе разработки?
Если да, как вносите поправку к первоночальной стоимости, доп. соглашениями к договору? Или это как-то отдельно в договоре обговаривается?
ТЗ является последней работой в рамках Проектирования. Я не представляю, как можно писать ТЗ, если не определены методы достижения целей и задач проекта.
Чтобы все обкатать придуманные идеи, создается и тестируется прототип. Уже после того, как он полностью готов, оттестирован и все сценарии выполняются, он описывается в ТЗ.
Наверно, фраза ТЗ постоянно меняется некорректна, скорее ТЗ постепенно рождается в процессе проектирования.
В договоре, конечно, оговорено, что дополнительные работы, не оговоренные прототипом и ТЗ, выполняются по доп.соглашениям.
Чтобы все обкатать придуманные идеи, создается и тестируется прототип. Уже после того, как он полностью готов, оттестирован и все сценарии выполняются, он описывается в ТЗ.
Наверно, фраза ТЗ постоянно меняется некорректна, скорее ТЗ постепенно рождается в процессе проектирования.
В договоре, конечно, оговорено, что дополнительные работы, не оговоренные прототипом и ТЗ, выполняются по доп.соглашениям.
это все хорошо и правильно, как если бы собрались все хорошие люди и убили всех плохих. На практике это все не реально. Можно сколько угодно умничать, пока не столкнешься с практикой. Большие системы могут только год изучаться для построения ТЗ, а за это время изменяются быстрее, чем пишется ТЗ. Взять например Укртелеком. Сроки любой разработки тоже будут сорваны — не зависимо от того есть ТЗ или нет. Любой. От укртелекома до Сталкера, от Дюка до Дума. :)
А так — для сферического коня Шрёдингера в ваккууме — все верно — без ТЗ и предоплаты нельзя даже «здрасьте» говорить…
А так — для сферического коня Шрёдингера в ваккууме — все верно — без ТЗ и предоплаты нельзя даже «здрасьте» говорить…
Статья описывает реальную практику нашей компании. Без договора нельзя «здрасьте» говорить. ТЗ разрабатывается не до договора, а в рамках договора.
В случае больших систем их изучение — это отдельный проект, который имеет свои задачи, свою смету и свои результаты.
В случае больших систем их изучение — это отдельный проект, который имеет свои задачи, свою смету и свои результаты.
Все правильно, но процесс изучения крайне сложно укладывается в сроки и смету (попробуйте описать одной цифрой и датой поиск Янтарной Комнаты или воды на Марсе). Кроме того, когда он закончен, система к тому времени уже изменилась опять. Так что любой договор на эту тему — опять фикция. Его надо будет корректировать, продлевать и пр…
Плюс не каждому заказчику можно пояснить, что написание ТЗ стоит 100500 долларов. И ваши конкуренты выиграют тендер еще на этапе ТЗ. А итог все равно простой — проблема заказчика должна быть решена.
Плюс не каждому заказчику можно пояснить, что написание ТЗ стоит 100500 долларов. И ваши конкуренты выиграют тендер еще на этапе ТЗ. А итог все равно простой — проблема заказчика должна быть решена.
В такой модели, о которой вы говорите, предложенная схема действительно не работает. Работает консалтинг с почасовкой.
В той модели, с теми заказчиками (а они не мелкие) и в том рынке, где работаем мы, предложенная схема работает. Да, она не работает для полётов на Марс, но и не должна.
Что касается ценовой конкуренции — мы в неё не играем, так что если конкуренты выиграют этот тендер, честь им, хвала, и удачи в работе с клиентом.
В той модели, с теми заказчиками (а они не мелкие) и в том рынке, где работаем мы, предложенная схема работает. Да, она не работает для полётов на Марс, но и не должна.
Что касается ценовой конкуренции — мы в неё не играем, так что если конкуренты выиграют этот тендер, честь им, хвала, и удачи в работе с клиентом.
Почему вы решили, что вам необходимо сразу и до рубля посчитать стоимость поиска воды на Марсе? Об этом как раз идет речь во 2 части статьи: посчитать все и сразу и точно невозможно.
Вы можете с достаточной степенью точности посчитать стоимость проектирования, а на основании проработанных прототипов и ТЗ оценить стоимость разработки. Но даже в случае, если эта сумма измениться, вы можете ее пересмотреть и изменить. Все это было и у нас, пока не поменяли подход к делу.
Кстати, кто-то вообще работает по скраму и успешно продает такой подход.
Вы можете с достаточной степенью точности посчитать стоимость проектирования, а на основании проработанных прототипов и ТЗ оценить стоимость разработки. Но даже в случае, если эта сумма измениться, вы можете ее пересмотреть и изменить. Все это было и у нас, пока не поменяли подход к делу.
Кстати, кто-то вообще работает по скраму и успешно продает такой подход.
Согласен с автором статьи. Сейчас правда мы поменяли существенно процесс, т.к., хоть и занимаемся заказной разработкой, но умудряемся работ по настоящему скраму, что немного облегчает задачу договоренностей.
Из моего опыта.
Встречал, приближенно, три типа заказчиков.
1. Хочу вот такую штуку. Без техзадания. Без требований. Устное или письменное перечисление благих пожеланий.
2. Вот техзадание. Все довольно подробно, но без конкретных требований.
3. Техзадание и список требований со скриншотами, таблицами, порядком и принципами работы, описанием оборудования и моделей девайсов.
В первом случае, при попытке наладить диалог, выяснить требования, составитьь какой-никакой план, обосновать бюджет заказчик пропадает. Если повезет и он таки появится на связи, то с гордостью сообщает, что нашел исполнителя в два-три(!) раза дешевле.
Во втором случае все доходит до планирования работ. Попытки обосновать проектирование и подробный список требований, договора с включением списка требований, как критерия исполнения договора приводят к тому, что заказчик отказывается от услуг. В качестве причины — нашел в 1,5-2 раза дешевле.
В третьем все проходит на ура, список требований, как часть договора, готовится техпроект, утверждается, начинается разработка. Принимается, подписывается акт приемки. Все довольны, заказчик остается с вами и в дальнейшем снабжает проектами и работой. Как причину объясняет, что у нас все быстро, качественно, то что надо, в срок, и в 2-3 раза дешевле.
Имхо, когда заказчик точно знает, что хочет, то знает чего от исполнителя требовать. И адекватно стоимость и качество оценивает.
Встречал, приближенно, три типа заказчиков.
1. Хочу вот такую штуку. Без техзадания. Без требований. Устное или письменное перечисление благих пожеланий.
2. Вот техзадание. Все довольно подробно, но без конкретных требований.
3. Техзадание и список требований со скриншотами, таблицами, порядком и принципами работы, описанием оборудования и моделей девайсов.
В первом случае, при попытке наладить диалог, выяснить требования, составитьь какой-никакой план, обосновать бюджет заказчик пропадает. Если повезет и он таки появится на связи, то с гордостью сообщает, что нашел исполнителя в два-три(!) раза дешевле.
Во втором случае все доходит до планирования работ. Попытки обосновать проектирование и подробный список требований, договора с включением списка требований, как критерия исполнения договора приводят к тому, что заказчик отказывается от услуг. В качестве причины — нашел в 1,5-2 раза дешевле.
В третьем все проходит на ура, список требований, как часть договора, готовится техпроект, утверждается, начинается разработка. Принимается, подписывается акт приемки. Все довольны, заказчик остается с вами и в дальнейшем снабжает проектами и работой. Как причину объясняет, что у нас все быстро, качественно, то что надо, в срок, и в 2-3 раза дешевле.
Имхо, когда заказчик точно знает, что хочет, то знает чего от исполнителя требовать. И адекватно стоимость и качество оценивает.
Если заказчик сливается по причине «нашёл в два раза дешевле» — это прекрасно. Если заказчик выбирает только по цене, с ним не получится нормального проекта — пусть мучаются другие.
В третьем случае, по сути, получается, что заказчик уже сам (или с чьей-то помощью) прошёл этап проектирования, и вписывает подрядчика исключительно под разработку. При отсутствии изменения требований в ходе проекта, действительно, результат получается лучше.
Просто в первом и втором случаях существуют ещё внятные заказчики, которые при грамотном предпроектном общении покупают проектирование. Вот с такими тоже имеет смысл работать.
В третьем случае, по сути, получается, что заказчик уже сам (или с чьей-то помощью) прошёл этап проектирования, и вписывает подрядчика исключительно под разработку. При отсутствии изменения требований в ходе проекта, действительно, результат получается лучше.
Просто в первом и втором случаях существуют ещё внятные заказчики, которые при грамотном предпроектном общении покупают проектирование. Вот с такими тоже имеет смысл работать.
Хороший обзор пунктов в договорах от Андрея Терехова.
Sign up to leave a comment.
Как снизить риски взаимодействия с клиентами в три этапа