17 абсолютных «НЕТ!» для заказчика
14-06-2010 | Автор: Yaroslav.CH |
Рубрика: Общение
Метки: Заказчику, Разработчику
65
Некоторое время назад, в блоге была опубликована занимательная статья «10 абсолютных «НЕТ!» для фрилансера». Судя по количеству просмотров и комментариев, материал оказался достаточно популярным, а сама тема — животрепещущей. Кроме того, в комментариях прозвучал призыв с другой стороны «баррикад» — написать такой же «НЕТ»-перечень, но для заказчика.
Выполняя пожелание читателей, в этой статье я постарался выделить мои 17 основных пунктов, на которые я, выступая в роли заказчика, всегда отвечаю категорическим — «нет».
Не забывайте, что обсуждение — приветствуется и самые интересные «НЕТ»-комментарии, содержащие обоснованные советы заказчикам, обязательно будут опубликованы в этой статье со ссылкой на автора.
1. У меня нет брифа, можем ли мы обсудить все вопросы устно? Нет.
Бриф является основополагающим фактором на стадии начального общения между заказчиком и исполнителем. Как показывает моя личная практика, в случае отсутствия у исполнителя подобного документа, весь процесс сводится к устному обсуждению, при котором трудно запомнить и здраво оценить все необходимые моменты.
Кроме того, если у разработчика нет выработанного практикой перечня вопросов к клиенту, то возникает сомнение как минимум — в удобстве работы с ним, а как максимум — в его профессиональной пригодности. Пример моего брифа на разработку информационного сайта вы можете найти в статье «Бриф на разработку сайта».
2. Могу ли я не писать техническое задание, ограничившись только бизнес-запросом? Нет.
Техническое задание — второй после брифа документ, но стоящий с ним на одной ступени важности. Вести разработки серьезных проектов без полноценного технического задания — себе дороже как для заказчика, так и для исполнителя.
Нужно помнить, что ТЗ — однозначный документ, призванный четко определять 98% основных составляющих разработки. Оставшиеся 2% — скидка на потенциальную неидеальность ТЗ, а именно — форс-мажоры и неявные определения, которые встречаются практически в каждом проекте.
Причем стоит обратить внимание на то, что степень «подробизма» технического задания может варьироваться, в зависимости от сложности проекта. Например, в определенных случаях, в роли ТЗ может выступать и дизайн сайта.
3. Я не буду писать смету, ограничимся полной суммой. Ок? Нет.
Каждый проект, вне зависимости от его размера, обязательно состоит из этапов и итераций — не имеет значения, больших или маленьких. Полная сумма за проект не позволит мне как заказчику представить себе реальное количество этапов, а в случае каких-либо изменений (как в сторону увеличения объема проекта, так и в сторону уменьшения) не даст возможности безболезненного увеличить или уменьшить бюджет. Соответственно стоимость каждого этапа (описанного в ТЗ) должна быть отражена в смете.
4. Я не буду выписывать четкие тайминги, но ориентировочно этот проект можно сделать за месяц-два. Ок? Нет.
Тайминги — обязательная составляющая часть ТЗ. Понятно, что исполнитель может ограничиться исключительно дедлайном и стараться просто в него уложиться. Но, к сожалению, как показывает практика, так получается далеко не у каждого исполнителя, а многие заказчики любят передвигать сроки в связи с «внезапно возникшей выставкой, конференцией, приездом большого начальства» и т.д. Четко зафиксированные тайминги позволяют проекту с одной стороны развиваться по плану, а с другой — производить изменения в графике без серьезного ущерба для обеих сторон.
5. Я не буду предоставлять отчеты — они занимают слишком много времени. Ок? Нет.
Отчетность — не менее важная составляющая любого проекта, чем бриф или технического задание. Заказчик должен понимать — на каком этапе находится проект, какой объем выполнен, где есть задержки, отставания и прочее. Для исполнителя отчетность позволяет в случае возникновения вопросов со стороны заказчика, всегда продемонстрировать текущий и ранее согласованный с заказчиком статус, что позволит убрать опросы из серии: «а почему так долго?», «а чем Вы сейчас занимаетесь?», «а я думал, что это уже готово!» и т.д.
С точки зрения сложности формирования отчета, никаких проблем на самом-то деле нет, поскольку каждая итерация уже выписана в смете и таймингах — остается лишь объединить эти три документа и методом «copy-paste» писать отчеты.
6. Я зарегистрирую Вам доменное имя и предоставлю хостинг. Ок? Нет.
Доменное имя заказчик должен регистрировать только сам. В случае технической неосведомленности, исполнитель должен предоставить заказчику свои рекомендации по выбору регистратора и самой процедуре покупки доменного имени. Если же заказчик категорически настаивает на покупке домена разработчиком, последний может это сделать, но исключительно в интересах заказчика. Более подробно о причинах такой позиции вы можете прочесть в статье «Почему вы должны сами регистрировать доменное имя».
Хостинг должен приобретаться только у профессиональной компании — благо, их количество на рынке более чем достаточно, а цены более чем демократичны. Количество «домашних» хостингов в последнее время стало идти на убыль, но по сей день присутствует большое количество студий, размещающих клиентские проекты на своих площадках. Чаще всего, цена такого хостинга равна его стоимости у профессионального хостера, но как и с доменным именем, момент переноса сайта, размещенного на такой площадке, вызывает очень большую головную боль.
7. У меня есть своя отличная CMS, будем разрабатывать сайт на ней! Нет.
Вне зависимости от объема проекта, я всегда рекомендую заказчикам использовать «массовую» систему правления сайтом. С одной стороны это позволит не зависеть от одного разработчика, в случае разрыва с ним отношений по тем или иным причинам, а с другой — рассчитывать на лучшее качество системы. Более подробно о причинах такой позиции вы можете прочесть в статье «12 причин не использовать самописные CMS».
8. Могу ли я получить 100% предоплату? Нет.
Предоплата это, наверное, самый большой «подводный камень» в отношениях между заказчиком и исполнителем. Первый не хочет платить за еще даже не скроенную рубашку, а второй — не хочет начинать процесс «кройки и шитья» без уверенности в том, что заказчик вообще заплатит. На мой взгляд, для того, чтобы обойти эту «гору», оптимальнее всего либо предоплачивать каждый этап работы (см. пункты о ТЗ и таймингах), либо же, если такой вариант неудобен, оплачивать выполнение всего проекта равными долями, например 33% или 50%.
Но 100% предоплата является явным перекосом в сторону исполнителя. Некоторые подрядчики приводят в пример заказ мебели, окон или полиграфической продукции, указывая на обязательную 70-100% предоплату заказа. Однако нужно не забывать, что в указанных случаях в стоимость конечного продукта входит не только непосредственная работа исполнителя, но и привлечение контрагентов для приобретения материала для последующего изготовления товара. И, в случае отказа заказчика от оплаты, подрядчик будет вынужден покрывать задолженности перед контрагентами из своих средств, что по понятным причинам недопустимо.
Грамотным аналогом такого подхода в разработке сайтов мог бы стать вариант предоплаты на сумму приобретения доменного имени и хостинга в интересах заказчика, но только вот представить себе вариант, при котором указанный «материал» будет оценен в 70% от стоимости проекта, лично я не могу.
9. Согласны ли Вы, что каждые переговоры должны быть оплачены? Нет.
Есть такая категория исполнителей, включающая в смету пункт, называющийся «личные встречи с заказчиком», «переговоры с заказчиком» и подобные ним. Смысл заключается в том, что каждое обсуждение проекта, кем бы оно ни было инициировано, должно покрываться заказчиком в качестве оплаты за потраченное время разработчика.
С одной стороны, в таком подходе есть свой резон — некоторые заказчики любят постоянно встречаться лично, пренебрегая возможностями не только e-mail, но даже и телефона. С другой стороны, многие исполнители довольно беззастенчиво вписывают в смету до 40-50 часов общения с заказчиком без серьезной на то необходимости — например, при разработке сайта-визитки.
На мой взгляд, наиболее оптимальным вариантом является вписывание ограниченного количества часов, которые действительно необходимы для непосредственного общения — например, обсуждение брифа, дебрифинг, согласование сметы и т.д., а также, установление определенного «резерва времени», предназначенного для решения тех или иных ситуаций, необходимых для выполнения работ. Все остальные коммуникации сводятся исключительно к электронной почте и редким телефонным переговорам — в рамках необходимости. А будет ли использован резерв — зависит от потребностей обеих сторон.
10. Предварительная оптимизация сайта — отдельный пункт сметы! Нет.
В последние годы, большинство заказчиков стало четко понимать, что вопросы и процессы разработки сайта неразрывно связаны с его оптимизацией и последующей раскруткой. Поэтому, адаптация сайта под поисковые системы — настройка генерации правильных мета-тегов (и функции их ручной корректировки), ЧПУ в ссылках и прочие элементы подготовки сайта к оптимизации должны быть изначально включены в стоимость разработки. Кроме того, необходимо учитывать, что большинство современных CMS изначально предоставляют подобный функционал, а считать его включение и настройку отдельным пунктом сметы — это уже перебор.
11. У меня много заказов, но я возьмусь и за Ваш проект! Нет.
Каждый исполнитель должен уметь говорить «нет». Если в данный момент у подрядчика существует перегрузка по проектам, оптимальнее отказаться от его услуг — в большинстве случаев, даже с полным «надрывом жил», успеть завершить проект в срок не получится — «проверено электроникой». В итоге это приведет к выяснению причин и с практически 100% долей вероятности — разрывом отношений, и как следствие — срывам сроков запуска.
13. У меня есть отличный дизайнер, Вы легко сможете с ним договориться! Нет.
Я никогда не ограничиваю разработчика в вопросах привлечения субподрядчиков, но все отношения с ними исполнитель моего проекта должен вести сам. Если он его рекомендует, значит он готов нести за него ответственность, а значит я могу даже и не знать об участи в проекте третьего лица. Разводить себе «зоопарк» из исполнителей, вести с каждым отдельные переговоры и множить себе головную боль я не хочу.
14. Я профессионал и не буду Вас консультировать по разработке проекта — просто доверьтесь мне! Нет.
Чисто психологически — нельзя доверять человеку, если ты не понимаешь что и как он делает. Да, я могу согласиться с тем, что ни у одного разработчика нет особого желания тратить время на обучение заказчика хотя бы основным премудростям разработки сайтов, но четко пояснить все необходимые"вешки" проекта и их преимущества для заказчика, он обязан. Более подробно о причинах такой позиции вы можете прочесть в статье «3 правила, позволяющие получить рекомендацию заказчика»
15. Я недостаточно полно оценил проект, можем ли мы увеличить бюджет? Нет.
Есть такая категория исполнителей, которая изначально, в процессе тендера, называет заниженную цену на выполнение проекта, а в процессе работы начинает ссылаться на необходимость увеличить бюджет по причине изначальной неверной оценки. Подобный подход позволяет получить заказ, а после, при должном опыты, еще и выбить из заказчика дополнительную сумму. В части случаев, заказчик, уже связанный договорными отношениями и предоплатой, идет на уступки и повышает бюджет.
Об этической стороне вопроса мы сейчас говорить не будем — мораль у каждого своя, но именно для того, чтобы избежать подобных «несуразиц», и необходимы бриф, техническое задание и полная смета проекта.
16. Я не хочу называть себя и буду использовать только никнейм? Нет.
Я никогда не договариваюсь о сотрудничестве с исполнителями, которые не готовы назвать свои реальные имя и фамилию. С одной стороны, мне очень неудобно общаться с использованием исключительно никнеймов, с другой — я предпочитаю ознакамливаться с отзывами о данном исполнителе, а с третьей — если человек не готов себя назвать, его потом будет труднее искать в случае возникновения проблем. Подробнее об этом читайте в статье «Стоит ли использовать никнейм при работе с клиентами?»
17. Могу ли я обращаться к Вам в любое время? Нет.
У каждого человека есть рабочие часы и часы отдыха. Учитывая практику, в том числе и мою собственную, работать по вечерам и часто ночам, я предпочитаю изначально оговаривать с исполнителям часы общения — исключая форс-мажорные обстоятельства. Например, даже тот факт, что я открыл письмо в 2 часа ночи еще не означает мою готовность обсуждать все детали, в нем содержащиеся.
18. У меня отключили интернет и я не могу закончить проект, давайте перенесем сроки? Нет.
Наличие или отсутствие интернета, работоспособность компьютера и его программного обеспечения, баланс мобильного телефона и прочие технические аспекты должны контролироваться исполнителем самостоятельно. Например, не так уж дорого стоит купить себе пакет «резервного» мобильного интернета, который позволит работать вне зависимости от работоспособности основного интернет-канала.
«Больных тётушек» или «умирающих бабушек» подобным образом, конечно, не предусмотришь, но в этом случае я обычно верю только один раз — я понимаю, что у человека может быть две бабушки, но поверить в эпидемию, выкашивающую их в течении срока реализации одного проекта могу с трудом.
А какие абсолютные «нет» в общении с исполнителями есть у вас?
Совет от Matt: Ещё думаю стоит добавить требование показать предыдущие работы. Иногда разработчик может сослаться на анонимность клиентов и то, что они не хотят свои сайты демонстрировать. Стоит сказать «нет» в таком случае.
Интересные факты истории, науки, психологии, литературы, техники. На сайте http://hidden-facts.info Вы можете расширить свой кругозор, познавая новое или переоценивая уже известное.
3 
170 
13
Пожалуй, только предоплата. Никакой необходимости платить ее нет. Если исполнитель сильно мнительный, можно оплачивать по факту мелкие этапы работы.
@justsoblogger: спасибо за комментарий.
Зачастую дело не столько во мнительности исполнителя, сколько с одной стороны в далеко не патологической честности заказчиков, а с другой — в заинтересованности исполнителя. Согласитесь, всегда приятнее работать, когда ты знаешь, что тебя хотя бы на часть суммы, но не кинут.
Для заказчика же предоплата означает вовлеченность в проект — многие до оплаты первого счета относятся к проекту как к чему-то очень теоретическому и далекому от реализации. Причем этот момент просматривается в большинстве случаев моей практики — до внесения денег, большинство клиентов долго собирается, совещается, меняет решения, договоренности и прочее. Но стоит оплатить первый счет, как ситуация меняется и все начинают мыслить рационально и в рабочем русле, скорее уже думая о том, что время уходит, а проект — стоит.
Есть и еще один момент, которым мне приходилось пользоваться как исполнителю — предоплата в качестве оценки консультационных услуг. Одним из таких примеров могу назвать ситуацию, при которой мне пришлось практически обучать основам web-дизайна — полиграфического дизайнера, которого попросту навязал заказчик. В итоге ничего толкового из этого проекта не вышло, по причине «бесконечности проекта» — все время менялись условия, структура, дизайн и прочее, а у меня уже вышли все сроки, отведенные на этот проект. В результате мы просто договорились, что предоплата уйдет в качестве стоимости консультаций и обучения и заказчик будет дальше решать вопросы сам. Откровенно говоря, я очень сомневаюсь, что без предоплаты, мне удалось бы получить эти деньги — бывали и такие прецеденты.
@justsoblogger:
Без предоплаты нет смысла работать. Нет желания, стимула и т.д. и т.п. Какого чёрта я буду работать, если не уверен в заказчике? Точно также, как и заказчик, который не хочет платить за ещё не сделанную работу, я не хочу делать работу неоплаченную хотя бы частично.
Бывают исключения, но они только подтверждают правило.
Теперь по статье. Форм-мажоры можно и нужно учитывать. Если у человека в день загрузки проекта на хост сдох инет или умерла бабушка, нужно подходить с пониманием, иначе вам светит полная гибель как заказчика. Пойдут слухи, что вы бесчувственный идиот, который ни черта в жизни не понимает. Я лично не буду браться за проект, если буду уверен в неадекватности заказчика. И вам не советую.
Стараюсь использовать свою CMS, потому что это удобней мне, заказчику плевать, я смогу оперативно вносить коррективы и видоизменять движок. Иначе мне придётся сидеть и курить форумы вместо работы. А включать своё обучение в смету я не привык.
В 95% я сам регистрирую домен и предоставляю хостинг на своём сервере. Потому что заказчику абсолютно плевать, а мой сервер настроен так, как нужно мне и моим скриптам. Но я на этом не настаиваю. Просто заказчику обычно нужно, чтобы всё само сделалось и работало. И страшные слова «домен» и «хостинг» он старается слышать только 1 раз в год, когда оплачивает счёт. Да и вообще обычно сводится всё к обозначению «платим за сайт», в которое включается оплата домена, хоста, поддержка, обновления и т.д.
@Never Lex: спасибо за комментарий.
Сдох интернет — должен быть резервный? нет никаких проблем его организовать. Умерла бабушка — одну бабушку я пойму, но если поперменно будут умирать бабушки, болеть тёти, страдать диареей кумовья — я могу что-то и заподозрить :)
Неадекватность заказчика — его нежелание понимать факт разгильдяйства разработчика? ;)
А потом кто-нибудь другой, например я, получает эту CMS и долго курит отсутствующие мануалы, а зачастую и комментарии, пытаясь понять — что это за штука-то такая :) А у заказчика открываются глаза на тот факт, что ему по-сути, нужно делать весь сайт с нуля.
А бывает и так, что разработчик по условиям договора вообще не согласен отдать даже БД сайта, мотивируя это интеллектуальной собственностью на БД, как на составляющую часть CMS.
То есть по-сути, это личное удобство, поставленное выше потенциальных проблем :)
Самомобучение не должно входить в смету заказчика, за исключением того факта, если он выбрал определенного исполнителя, но хочет выполнить проект на неизвестной этому исполнитеклю системе. А курить форумы, книжки и мануалы все равно придется — что для своей системы, что для чужой.
Тут все зависит от заказчика — в большинстве случаев проблемы начинаются в том случае, если возникает необходимость смены разработчика.
Я предпочитаю четко объяснять заказчику преимущества использования профессионального хостинга перед «домашним». В сущности, нет никакого отличия — при поддержке, заказчик точно так же слышит «хостинг» и «домен» раз в год :) Если он хочет платить за все это сам — никаких проблем, причем часть заказчиков в принципе хочет заниматься этим самостоятельно, чтобы никто ни от кого не зависел.
Нет. Резервный инет как и электрогенератор это необязательные атрибуты. Причём это атрибуты скорее большой компании, чем фрилансера-одиночки. Выйти из ситуации обычно можно, но стоит ли оно того? Платите ли вы достойную сумму, чтобы обеспечивать ваши капризы и вольности природы, электриков и т.д.? Если сумма сметы объективно не завышена, то и говорить не о чём.
Есть приоритетные заказы, которые выгодно делать любым путём, но они довольно редки. У меня недавно выключили свет. На всём районе выключили. Хотел купить еды — даже супермаркеты были закрыты. Я мог поехать на другой конец города с нетбуком и работать там, но я этого не сделал. Не было мотивации и оплаты моих расходов.
На счёт стечения обстоятельств. Это бывает и всегда выглядит подозрительно. Но ведь на самом деле может случиться целая череда неприятностей. Я не к тому, чтобы всё спускать на тормозах, а к тому, что нужно понимать, когда человек филонит, а когда действительно не может работать.
Совсем нет. Имелось в виду то, что заказчик может быть роботом, который мыслит только понятиями «договор» и «деньги». Мне лично не приятно работать с такими. Имхо, если человек не понимает смысла слова «форс-мажор», то олн неимоверно глуп.
Я не пытаюсь выстроить для себя цепь отмазок в раздолбайстве. Я понимаю свои недостатки и готов держать ответ за свои ошибки. Но я не буду отвечать за то, что выключили свет, а у меня под рукой не было запасного генератора.
Никто из моих заказчиков пока не уходил к другому исполнителю. О привязке по CMS никто из них не думал, уверяю вас. Просто удобно обслуживаться у одного человека.
Не слышал о таком. Это чудеса прямо какие-то :)
Мои заказчики видят тут только минусы. Да и я тоже. Если мне они могут позвонить и решить проблему в течении часа, то крупные хостинговые компании отличаются крайне наплевательским отношением к поддержке. К тому же все вопросы решаются только со мной. Зачем ещё привлекать людей?
Если же у человека хватает мозгов, чтобы оплачивать домен и хостинг самостоятельно, то я буду только рад. Главное, чтобы это был не самый дешёвый, постоянно глючащий хостинг с отсутствующей поддержкой. Потому что, когда сайт лежит, клиенты обычно звонят всё равно мне. Я же типа делал, я должен знать. Приходится им объяснять что к чему, и они звонят в суппорт хост. компании, где их посылают на 3 буквы. Я люблю, чтобы мои клиенты были довольны, а не занимались беготнёй и бюрократией.
Насчет форс-мажора — тут палка о 2 концах. Относишься к вопросу халатно ровно до тех пор, пока самого не прижмет. А вот потом начинаешь понимать людей.
Как ты верно подметил — верить людям нужно, но один раз.
Или как вариант... я некоторое время назад выпадал из рабочего процесса, потеряв близкого человека, но даже эти несколько дней всегда носил с собой кпк + нетбук, для чего-то экстренного.
При этом обращающимся с вопросами кратко излагал ситуацию (копипаст шаблона) и предлагал детально описать проблему в письме, чтобы решить ее как только представится возможность (в течение дня).
Ни один из обратившихся в итоге больше не побеспокоил. Через несколько дней я сам обратился к ним, и все вопросы были закрыты.
@Never Lex: коммент на месте и никуда не пропал :)
Это все равно, что сказать — «я — электрик. У меня есть одна отвертка, но если она сломается, весь дом будет сидеть без света, пока я ее не починю».
Не думаю, что недорогой пакет мобильного интернета за 50 гривен в месяц не станет слишком дорогой страховкой на случай возникновения проблем.
То есть сумма каждого заказа должна быть завышена на 50 гривен, чтобы предотвратить потенциальные проблемы? Ок, готов внести подобный «резерв» в стоимость заказа. Хотя, при этом, повторяя пример с отверткой, мне пока что ни разу не приходилось так делать.
Это и есть форс-мажор, но свет обычно дают максимум в течении суток. Если мне понадобится опуликовать проект вот просто здесь и сейчас то, или я приеду за файлами, или оплачу транспортные расходы исполнителя. Это нормально и адекватно.
Нас слегка качает из стороны в сторону — форс-мажор не есть разгильдяйство. Бабушка и правда может умереть, а кумовья — отравиться неспелым арбузом. Но когда исполнитель сначала что-то долго тянет и крутит хоботом, а потом бабушка «внезапно!» заболеват — что-то тут не так.
Согласен, но есть выход — уведомить об этом заказчика и порекомендовать ему другого исполнителя, который может продолжить проект. Нормальное и вежливое решение — проблемы бывают у каждого, но нужно уметь их решать. Именно в этом случае можно сохранить нормальные отношения с заказчиком и не испортить себе репутацию.
Однако есть одна проблема — если сайт разабатывается на своей CMS, информация о которой есть только у одного разработчика, найти «сменщика» не получится — а это уже проблема, поскольку клиент уже потратил не только предоплату, но и определенное количество времени, которое придется каким-то образом компенсировать.
Если перечитать статью, то можно увидеть, что как раз о ситуации «пропал свет» я не писал вообще. И именно потому, что для фрилансера покупать дизель-генератор слишком уж накладно, а студия всегда может решать проблему, распустив сотрудников по домам для завершения заказа.
Все когда-нибудь происходит впервые :) Я никоим образом не пророчу, но есть а) ситуации, которые от нас не зависят — кирпич на голову и б) зависящие от определенных факторов — например, я знаю клиента, которому пришлось переделывать весь сайт лишь только потому, что разработчик сказал — «сорри, мне это все неинтересно, я уезжаю на ПМЖ в Канаду».
Согласитесь, в сущности — никаких претензий быть не может. Ну правда, решил себе человек уехать — подвернулся случай, ну не будет же он ради клиентских сайтов оставаться и продолжать работать. Сервер он честно проплатил еще на полгода и предупредил, что всем заказчикам нужно искать себе новый «дом».
Ответ на «зачем?» содержится в примере выше. А вопросы с хостингом тоже решает не заказчик, а поддержка его сайта — как бы она не выглядела. А насчет хостинга... не знаю, я в саппорт обращаюсь крайне редко — в основном мне хватает инструментов и функционала панелей.
При этом, если завтра у меня поменяется концепция, я четко знаю, что все мои клиенты останутся при своих сайтах и у них не будет никаких проблем.
Не совсем понятен этот момент — почему клиент должен сам звонить в поддержку? Если я занимаюсь проектом клиента, то он звонит только мне и решает свои проблемы только со мной. А уже я оформляю запросы в поддержку, связываюсь с ней и решаю возникшие неурядицы.
Над резервным пакетом я думал, но пока не реализовывал, так как пока не считаю, что вышел на достаточно профессиональный уровень, чтобы учитывать форс-мажоры. Я пока работаю довольно дёшево, часто потому что мне интересно, поэтому неожиданности не предусмотрены.
Тогда получается, что клиента платит Вам за общение с техподдержкой + платит техподдержке. Имхо проще платить одному человеку. Он быстрее и дешевле решит все проблемы.
С остальным в принципе согласен. Мы просто взглянули на вопрос с немного разных ракурсов.
На счёт массовой CMS — если нужно что-то простенькое, то можно и ей обойтись. Но имхо не стоит воротить сложные вещи на популярных CMS. Это только замедляет работоспособность и затормаживает проект.
@Never Lex: честно говоря, не вижу взаимосвязи между профессиональным уровнем и подготовленность к форс-мажорам — разве только те, у кого уровень достаточно высок, должны заботиться о клиентах? А цена — она не настолько высока, да и, кроме того, никто ведь не мешает его использовать при любых иных, кроме проблемных, обстоятельствах. Например, на презентациях или при обсуждении с клиентом определенных вопросов — интернет есть далеко не в каждом кафе, а в офисах часто закрыт для сторонних подключений.
Нет, клиент платит за поддержку своего сайта — от А до Я, в которую в частности входит и решение вопросов с хостером, регистратором и т.д. Клиентов, которых я поддерживаю только на уровне общения с саппортом хостера у меня нет — зачем они мне нужны, да и им тоже смысла ровным счетом никакого. Другое дело, что я рекомендую хостинг с адекватной техподдержкой, а не «у Ашота в подвале».
«Простенькое», к сожалению или счастью, имеет тенденцию вырастать в «крупненькое» :), а если сделать первоначальный вариант на «личной» CMS, а развивающийся — на массовой, то к чему были траты на первоначальный? С другой стороны, сайт-визитку можно сделать что на том же WordPress, что на самописной CMS, думаю, с абсолютно одинаковой скоростью.
@SibNext:
Форс-мажор — ситуация совершенно иного порядка. В жизни может возникнуть всякое и потому рассчитывая тайминги на проект, всегда предпочтительно оставлять для себя (как со стороны заказчика, так и исполнителя) определенный запас времени, который в случае возникновения проблемных ситуаций, позволит не сорвать сроки.
Уверен, что при описанном тобой подходе, не смотря на возможные неудобства, клиенты легко и адекватно восприняли положение дел.