Не могу согласиться с принипом «покупай то, что больше всего подешевело». На мой взгляд нужно наоборот, покупать то, что не подешевело — это говорит о том, что спрос на эту недвигу стабилен и цена не является перегретой. Например хороший домик в Санта-Монике как стоил 2-3 млн.$ так и стоит. И когда туда приедешь то становится понятно, что в таком месте всегда будут желающие жить.
Мы пришли к тому, что рамки проекта должны быть:
А — жесткими (не меняться под давлением заказчика)
Б — понятными клиенту.
А также необходимо чтобы процесс ведения проекта был описан и задокументирован как приложение к договору.
Собственно вторая задача решается созданием и приложением к договору устава проекта, в котором описано сколько вариантов дизайна предоставляется, как требования по модификации дизайна отражаются на стоимости. Описано все проектное управление, критерии приема промежуточных этапов и т.п. В общем это должен быть документ — библия проекта, по которой надо работать. В итоге будет счастлив и разработчик (т.к. проблема с расширением рамок клиентом решается) и заказчик.
По поводу заказчика кажется не логично, не правда ли?
А опыт показывает что это так, работает золотое правило «чем больше подписей, тем счастливее клиент». Например, устава нет, заказчик говорит «хочу исправить цвета, расположение, фон» и т.п. Вариант без устава «ну сколько можно?.. давайте уже принимать дизайн...» — обиженно говорит PM исполнителя. Заказчик обижается тоже, думая «ну что за негодяи, это же так просто!». «ну ладно, сделаем :(» говорит PM исполнителя. В итоге себестоимость растет, отношения ухудшаются.
И вариант с уставом «это в рамки проекта не входит, смотрите вот в уставе написано. если это делать то нужно выделить дополнительное финансирование — эта процедура тоже описана в уставе». Заказчик «а… ну да. ок, давайте оставим как есть.». И никаких обид.
По поводу ТЗ на дизайн. Конечно. Называется Художественное Задание (ХЗ). Дополнительно к вашим пунктам нужно добавить: цель, которую должен решать дизайн.
А — жесткими (не меняться под давлением заказчика)
Б — понятными клиенту.
А также необходимо чтобы процесс ведения проекта был описан и задокументирован как приложение к договору.
Собственно вторая задача решается созданием и приложением к договору устава проекта, в котором описано сколько вариантов дизайна предоставляется, как требования по модификации дизайна отражаются на стоимости. Описано все проектное управление, критерии приема промежуточных этапов и т.п. В общем это должен быть документ — библия проекта, по которой надо работать. В итоге будет счастлив и разработчик (т.к. проблема с расширением рамок клиентом решается) и заказчик.
По поводу заказчика кажется не логично, не правда ли?
А опыт показывает что это так, работает золотое правило «чем больше подписей, тем счастливее клиент». Например, устава нет, заказчик говорит «хочу исправить цвета, расположение, фон» и т.п. Вариант без устава «ну сколько можно?.. давайте уже принимать дизайн...» — обиженно говорит PM исполнителя. Заказчик обижается тоже, думая «ну что за негодяи, это же так просто!». «ну ладно, сделаем :(» говорит PM исполнителя. В итоге себестоимость растет, отношения ухудшаются.
И вариант с уставом «это в рамки проекта не входит, смотрите вот в уставе написано. если это делать то нужно выделить дополнительное финансирование — эта процедура тоже описана в уставе». Заказчик «а… ну да. ок, давайте оставим как есть.». И никаких обид.
По поводу ТЗ на дизайн. Конечно. Называется Художественное Задание (ХЗ). Дополнительно к вашим пунктам нужно добавить: цель, которую должен решать дизайн.