17 абсолютных «НЕТ!» для заказчика
14-06-2010 | Автор: Yaroslav.CH | Просмотров: 1,332
Рубрика: Общение
Метки: Заказчику, Разработчику
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 Вы можете расширить свой кругозор, познавая новое или переоценивая уже известное.
Пожалуй, только предоплата. Никакой необходимости платить ее нет. Если исполнитель сильно мнительный, можно оплачивать по факту мелкие этапы работы.
@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:
Форс-мажор — ситуация совершенно иного порядка. В жизни может возникнуть всякое и потому рассчитывая тайминги на проект, всегда предпочтительно оставлять для себя (как со стороны заказчика, так и исполнителя) определенный запас времени, который в случае возникновения проблемных ситуаций, позволит не сорвать сроки.
Уверен, что при описанном тобой подходе, не смотря на возможные неудобства, клиенты легко и адекватно восприняли положение дел.