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 Вы можете расширить свой кругозор, познавая новое или переоценивая уже известное.
Пожалуй, только предоплата. Никакой необходимости платить ее нет. Если исполнитель сильно мнительный, можно оплачивать по факту мелкие этапы работы.
@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:
Форс-мажор — ситуация совершенно иного порядка. В жизни может возникнуть всякое и потому рассчитывая тайминги на проект, всегда предпочтительно оставлять для себя (как со стороны заказчика, так и исполнителя) определенный запас времени, который в случае возникновения проблемных ситуаций, позволит не сорвать сроки.
Уверен, что при описанном тобой подходе, не смотря на возможные неудобства, клиенты легко и адекватно восприняли положение дел.
Расширять самописную CMS наоборот проще.
БРАВО!
Я Ваши советы коллегам в офф- лайн даже передам...
Потому что это ГЛОБАЛЬНАЯ ТЕМА — как для фриласнса, так и для агентств.
У меня был случай, когда бюджет на раскрутку проекта был с 6-ю нулями (это в прошлой жизни было )), и то подрядчики выпендривались по полной!
Тут все очень структурировано и разложено шаг за шагом...
100% полезности.
Большое человеческое спасибо
@Never Lex: проще — для кого? :)
@Elle: спасибо за столь высокую оценку :)
@© Yaroslav.CH: конечно для разработчика. Но если изначально иметь в планах работу с разными исполнителями, то нужно и бюджет заранее увеличить и быть готовым к глюкам и торможению при переходе от исполнителя к исполнителю.
@Never Lex: ок, а как переходить от исполнителя к исполнителю, если а) используется самописная CMS первого исполнителя и б) проект расположен на сервере первого исполнителя?
На самом деле я прекрасно понимаю подобную позицию — для разработчика действительно гораздо выгоднее «подсадить» заказчика на свою поддержку и спокойно продолжать получать профит от нее. Но с точки зрения заказчика, подобный вариант далеко не оптимален — а в данном случае я смотрю на ситуацию именно со стороны заказчика.
@© Yaroslav.CH:
Был у меня один заказчик, так у него по неопытности был реализован один проект, на самописной CMS (на яве) располагалось это все хозяйство только на хостинге авторов CMS. И за любое изменение функционала выставлялись такие счета, что рот не выговорит.
Заказчик просил пару раз подправить там по мелочи. А я как глянул, там такой аццкий функционал админки, что даже телепату трудно будет разобраться.
К чему это я — к тому, что солидарен с твоим ответом )
Значит вы заведомо не доверяете исполнителю. А это уже плохо. Намного лучше один проверенный исполнитель, чем толпа фрилансеров на бирже, которые не понятно будут ли завтра присутствовать на этом рынке или нет.
Дело в том, что так удобней и заказчику и исполнителю. Заказчик платит деньги и не о чём не беспокоится. А исполнителю удобно работать. Всё это ускоряет и улучшает качество обслуживания.
@SibNext: а со своей стороны могу рассказать похожий пример — у заказчика был проект на Microsoft CMS, вещи настолько неизвестной у нас, что разработками на ней занималась аж одна-единственная компания. То есть, по-сути, можно считать, что эта система была практически равна уровню любой самописной системы. Так вот за банальнейшую форму обратной связи из 4-х(!) полей с сохранением результатов в базе и простейшим админ-интерфейсом, позволяющим просматривать эти самые результаты просто в форме списка, компания захотела ни много, ни мало — $800.
Выбор, естественно, был очень прост — или платить, или переносить сайт на другую систему. Не трудно предположить, что заказчик, отдышавшись, выбрал второй вариант.
Так что и я с тобой полностью солидарен :)
@© Yaroslav.CH:
Правда у них был и второй вариант — платить абонентку за обслуживание сайта — там цифры тоже под $1000 в месяц. Как-бы с одной стороны и сумма небольшая, а с другой, что это за CMS, в которой для незначительных изменений требуется разработчик, да еще и за приличные денежки.
Вы говорите о вариантах, когда клиентов тупо доят дяденьки в галстуках. К сожалению бывает и так. Но перед тем, как делать заказ на кругленькую сумму, всегда стоит послушать отзывы и мнения других клиентов. Если заказчик попал на удочку таких «бизнесменов», то он сам виноват. В данном случае он лох.
Я же говорю именно о качественном обслуживании. Когда пожелания заказчика внедряются быстро и довольно недорого. Совершенно всегда разработчик CMS намного лучше разбирается в ней, чем кто-либо другой. Поэтому целесообразней в таком случае проект разрабатывать на специальной, подогнанной под заказчика CMS. А свой хостинг гарантирует простое решение множества проблем.
@Never Lex: я вообще мало кому доверяю :) И не потому, что подозреваю всех в желании сделать целенаправленную гадость, а потому, что жизнь научила — при выборе «я или другие», человек всегда выбирает «я», пусть даже его будут мучать страшные угрызения совести :)
Если разработчик завтра решит поменять концепцию и повысить стоимость на свои услуги — и может даже не потому, что он такой гад, а потому, что жизнь так сложилась — я хочу иметь возможность здраво оценивать возможность увеличения бюджета со своей стороны и, если пойму, что не тяну новые цены — искать другого исполнителя.
И это абсолютно не означает, что я буду обязательно менять исполнителей как перчатки, выискивая их по биржам подешевле. Отнюдь, я вообще предпочитаю стабильность во всем. Но иметь возможность выбора я должн всегда — это основное условие.
Кроме того, у меня (как и, думаю, у любого исполнителя) есть часть заказчиков, которые периодически обращаются ко мне с доработками ранее созданных для них сайтов, и за разного рода поддержкой. И хотя их сайты работают на массовых CMS, они не ищут другого подрядчика — им это не нужно, поскольку все во мне устраивает.
Нет проблемы удержать заказчика, если исполнитель — адекватен и удобен. А насчет доверия — у меня есть отдельная статья на эту тему, называется «Формула отличного результата или Станьте профессиональным заказчиком». Почитай, если интересна эта тема.
@SibNext: ну не могу сказать, что $1000 за поддержку сайта ежемесячно — это «небольшая сумма». В таком случае сайт должен приносить в месяц как минимум вдвое больше, иначе он станет просто черной дырой для денег.
Кроме того, знаю я эту «шутку юмора» абонентской платой — за штуку мы вам будем контент размещать и баги править, а любые разработки должны оцениваться отдельно. В итоге получается все ровно тоже самое, только еще на $1000 дороже :)
@© Yaroslav.CH: Поймите. Я не стараюсь удержать клиента у себя. Я стараюсь сделать:
— проще для себя
— выгодней для заказчика.
@© Yaroslav.CH:
Бесспорно.
Но мы то тут и говорим про сайты, которые продают и приносят прибыль ;)
@Never Lex: нет, я говорю об абсолютно реальных ситуациях, которые происходят повсеместно, вне зависимости от наличия на исполнителе галстука или футболки с пингвином :)
В корне неверная позиция. Не думаю, что Вам самому приятно, если Вас начинают разводить при покупке или оплате той или иной услуги, в которой Вы не разбираетесь. Например, в автосервисе. Есть такая вещь как профессиональная этика и про нее не стоит забывать.
Кому жемчуг — мелковат, а кому супчик жидковат :) «Довольно недорого» без возможности поменять исполнителя — это по-сути, чистейшей воды кабала. Хочешь уйти, но расходы будут вдвое больше, чем первоначальные вложения.
Правильно, поэтому в случае возникновения проблем, при переходе (вынужденному или желаемому) к новому разработчику, последний чаще всего говорит — «да зачем Вам вот это, давайте перейдем на мою систему — все будет проще и быстрее!». И так вот каждый раз...
В каком смысле — «подогнанной под заказчика»? неужели Вы каждый раз переписываете свою CMS под каждого заказчика в отдельности? Ведь не так же, правда? То есть, по-сути, Вы предлагаете точно такой же вариант, как и массовая CMS — унифицированную систему, но доступ к исходникам и структуре имеете только Вы. Тогда в чем реальное преимущество Вашей системы перед массовой?
Честно скажу, я пока что в разработке, назовем их так, «стандартных» проектов еще не сталкивался с ситуацией, при которой мне требовался какие-то мега-специализированные настройки хостинга для реализации задачи. О «нестадарте» и уникальных проектах говорить не будем — там свои примочки и чаще всего используется или VDS, или выделенный сервер.
@Never Lex:
Это понятно — естественно, любому разрабочику проще работать с тем, что он написал сам, чем разбираться в чужих изысках кода.
А вот этот момент я не улавливаю вообще — в чем же заключается эта самая выгода?
Дешевле обслуживание? Наврядли, чаще всего цена выстраивается исходя из почасовой ставки разработчика (пусть он ее и не называет вслух, но считает, отталкиваясь от каких-то своих переметров). А на какой системе он это делает — не суть важно.
Быстрее? Для стандартной задачи всегда используются стандартные наработки, а под какую систему они существуют — уже не важно. А для нестандартных задач, скорость и качество реализации зависит от уровня знаний и к системе не имеют никакого отношения.
Безопаснее? Нет, поскольку один разработчик не может включать в себя и отличного программера и прекрасного аудитора.
Удобнее? Не факт, поскольку в этом случае блестящий программист и аудитор должен быть еще и отличным юзабилистом.
Стабильнее? Чаще всего на «домашнем» сервере начинают сильно экономить, стараясь впихнуть в ограниченный объем ресурсов — маусимум проектов. А когда встает проблема апгрейда, цены на хостинг начинают увеличиваться.
И так далее. К сожалени, не вижу я реальных преимуществ для клиента, при 100% зависимости от одного разработчика, а минусов — порядочный воз, часть из которого я перечислил в комментариях выше и в отдельной статье, ссылка на которую есть в статье.
Вы меня не так поняли. Я говорил о том, что я предоставляю качественные услуги. Если заказчик позарился на цены в 100 баксов за сайт, то он скоро поймёт как ошибся. Но это его проблемы, я не буду его жалеть. Любой здравомыслящий человек понимает, что за качество платят не копейки. Не золотые горы, но и не копейки.
Об остальном спорить не имею желания. Тут наши позиции ясны. Вы очень недоверчивы и рассчитываете на кидок. Я же работаю честно, поэтому могу позволить себе работать не совсем стандартно.
@SibNext: как минимум — стараемся :)
Дело-то все в той проблеме, которую ты сам отлично знаешь — сделать сайт еще не означает получать от него прибыль. Поэтому при таких стоимостях абонентки, проще с самого начала пофиксить расходы и сменить столь жадного разработчика на более скромного и адекватного. Что, как я понимаю, твой заказчик с упехом и сделал :)
@Never Lex:
Я ни в коем случае не подвергаю это утверждение ни малейшему сомнению — я говорю лишь о том, что нужно изначально предоставлять заказчику возможность выбора, позволяя ему самостоятельно определяться с тем, как именно он хочет работать с исполнителем. Грубо говоря, есть два варианта:
1. Я могу сделать сайт на своей CMS, это будет быстрее и дешевле, но размещается только у меня и поддержка тоже осуществляется только мной.
2. Я могу сделать сайт на CMS X или Y, которые являются массовыми — стоимость будет выше, поддержка медленней, но при этом Вы не будете зависеть только от меня, имея возможность всегда выбрать другого разработчика, в том случае, если возникнут какие-либо спорные моменты.
Понятно, что эти варианты озвучены очень грубо, на практике они должны звучать гораздо мягче и более «выгодно», но быть они должны.
Это уже вопрос несколько иного порядка — он отностся к моменту ценообразования, и пропорции между качеством и стоимостью.
Опыт большой, к сожалению или к счастью :) Но Вы не совсем правильно меня понимаете — я не рассчитываю на кидок, я просто изначально готов к тому, что он вообще может произойти. А это не совсем одно и то же.
Более того, я никогда никого огульно не обвиняю в желании обязательно кинуть заказчика, но при этом знаю, что в ситуации «я или изаказчик», всегда выбирается «я» — это вообще общечеловеческое, своя рубашка всегда ближе к телу, чем к тушке малоизвестного заказчика :)
Поэтому, оптимальнее изначально подстраховаться и иметь возможность легко минимизировать последствия, чем видеть картину в розовых тонах, а потом вляпаться по самые уши. Если проблема будет — ок, я к ней готов. Если не будет — отлично, я рад, что все прошло на «ура».
Так что это не «ожидание кидка», это страховка — так же как, например, с автомобилем. КАСКО покупается не потому, что водитель обязательно расчитывает въехать в столб, а по причине потенциально существующей возможности ДТП или ПДТЛ.
@© Yaroslav.CH: конечно заказчику предоставляется выбор CMS. Я не настаиваю на своём хостинге и своей CMS, я говорю, что так будет легче, быстрее и дешевле (что правда). И заказчик обычно размышляет так, что лучше он не будет иметь дел с другими исполнителями, хостингами и доменами.
Понимаю. Благодаря опыту, вы стали излишне подозрительны и лишены какой-то наивности. Имхо, к сожалению.
@Never Lex: а если не секрет — из каких систем предоставляется выбор?
Думаете, в работе наивность приносит хоть какую-то пользу? :)
@© Yaroslav.CH: Зависит конечно от проекта, но вменяемыми считаю немногие системы. Например, Drupal.
Наивность? Да :) Приносит. Без неё меньше удовольствия от работы.
@Never Lex: чувствуется легкая предвзятость :)
Хм, то есть потенциальная возможность проблем — будоражит нервы? ;)
предвзятость конечно есть. У каждого есть своё мнение. На Друпале я также проекты делаю кстати, и на платных движках тоже. Когда это целесообразно конечно же. Некий риск? Конечно. И работаю я потому, что мне интересно.
Деньги ведь не главное, хоть и немаловажное. Когда веб разработка перестанет быть для меня интересной, задумаюсь на счёт смены профессии. Но пока что вижу только множество направлений, куда стоит стремиться и развиваться. Сухой расчёт и конвеер усыпляют эмоции. А человек живёт именно эмоциями, а не деньгами.
@Never Lex: о движках спорить не буду — это уже вопрос личных предпочтений и у каждого они свои. КТо что любит, кому что нравится — тот на том и работает, в холиворах смысла нет ни малейшего :)
Не совсем понял — в чем именно заключается риск при работе с платными движками?
Вот это и есть один из тех моментов, о которых я говорю — если завтра Вам надоест заниматься разработкой, кто будет поддерживать сайты клиентов, созданные на Вашей CMS и заниматься их апгрейдом и разработкой нового функционала?
Согласен, но неужто эмоции могут вызывать только проблемы? Для меня, например, гораздо более позитивным является ощущение удачно завершенного проекта, возможно, некоей доли гордости от того, что я решил какую-то нестандартную и интересную задачу и т.д. Но проблема — это просто проблема и ее нужно решать, а потому — зачем создавать лишние?
@© Yaroslav.CH: Да нет. Я не только о проблемах говорил, а в общем. И не надоест мне, я уверен. Потому что СТОЛЬКО всего интересного :)
Тем более, я порядочный человек и бросать клиентов не буду в любом случае.
На счёт риска — что-то там случилось с сохранением комментария. Это должен был быть другой абзац.
@Never Lex: ну, в таком варианте могу только пожелать удачи, развития и творческих достижений :) Спорить о том, что будет или не будет — дело неблагодарное :)
Само собой, но я знаком с ситуациями, когда и бросить не получается, и делать не хочется. Ничего приятного в таком состоянии нет :)
Честно говоря, никогда не встречался с «выпадением абзацев» в комментариях.
Интересная статейка, пункта сметы о переговорах с клиентом я еще не встречал! Думаю, что за такое деньги брать вообще нагло!
Я вот во фрилансе уже 7 месяцев. И стараюсь заказчикам не говорить нет. Так как это мой хлеб. Но за статью все равно спасибо, почерпнул много нового для себя.
О круто все расписано, я как раз собираюсь организовывать веб-студию, надо будет давать это менеджерам почитать, а потом проводить экзамен поэтим вопросам
Вот недавно заказывал интернет магазин, обзвонил где-то 10 студий, только две нормально и адекватно что-то объяснили, привыкли халтурить
Хорошо написано! Всё чётко и по делу! А правила действительно жизненные!
Каждый пункт по своему верен, но всегда в конкретно взятой ситуации есть свои нюансы, где будет и заказчику и исполнителю выгодно.
Отличные советы, что уж сказать! Все по делу и без воды. Сам я и фрилансер, и заказчик. Так что изучаю подробно ваши записи. :)
Согласен со всеми пунктами и особенно с теми, что касаются планов. А по поводу задержек по болезням там разных родственников — да пожалуйста, хоть неделю пропускайте, только за задержку сдачи проекта — штраф, в виде сокращения суммы вознаграждения. Ещё думаю стоит добавить требование показать предыдущие работы. Иногда разработчик может сослаться на анонимность клиентов и то, что они не хотят свои сайты демонстрировать. Стоит сказать «нет» в таком случае.
Спасибо за советы. Понравились обе статьи, что про заказчиков, что про фрилансеров. Буду стараться придерживаться этих советов.
Кто не привык смолоду планировать и сметировать, тот всю жизнь делает «пока хватит денег» и это по-русски! Это прорыв «вслепую».
А те, кто пытается просчитывать все варианты, наталкиваются на те, которые не предусмотривали!
@Matt: спасибо за комментарий.
Добавил Ваш совет в статью со ссылкой на Ваш блог :)
«У меня много заказов, но я возьмусь и за Ваш проект!» — по своему опыту могу сказать, что в 60% случаев эта фраза означает, что работа будет выполнена с огромным опозданием и в 40% — что окажется вовсе недоделанной. Действительно, лучше не «загружать работой» (безответственного) фрилансера, а заказать у того, кто намерен чётко уложиться в сроки.
В принципе всё написано правильно,...это в идеале так должно быть. Вот только никогда так не бывает :) По своему опыту скажу, большинство заказчиков даже не знают что обозначают слова «домен» и «хостинг»...а следовательно, всё вышеперечисленное для них вообще темный лес.
Для меня это ещё тёмный лес, пытаюсь во всём этом разобраться. Спасибо за статью!
Для заказчика же предоплата означает вовлеченность в проект — многие до оплаты первого счета относятся к проекту как к чему-то очень теоретическому и далекому от реализации. Причем этот момент просматривается в большинстве случаев моей практики — до внесения денег, большинство клиентов долго собирается, совещается, меняет решения, договоренности и прочее. Но стоит оплатить первый счет, как ситуация меняется и все начинают мыслить рационально и в рабочем русле, скорее уже думая о том, что время уходит, а проект — стоит.
Мне по-началу было сложно говорить нет даже на некоторые вопросы из этого списка, особенно когда заказов мало. Но теперь уже понимаю, что себе дороже
Все равно в договорах все расплывчато расписывается и мало кому удается вернуть деньги за не выполнение очевидных пунков
Лучше работать хотя бы по частичной предоплате. Это подтверждает, что обе стороны настроены серьезно и готовы сотрудничать.
Отличная статья!!
Ещё я говорила «нет», когда исполнитель начинал ломить астрономические суммы даже не вникнув в проект.
Плюс, если исполнитель начинал на первой встречи всё критиковать. Во-первых, это непрофессионально и глупо, а во-вторых, без сопливых разберёмся.
И ещё пожалуй, когда исполнитель пытался давить, выуживая информацию, которая в реализации данного проекта ему абсолютно не нужна.
Огромное спасибо автору за данную ниформацию! Очень интереснаая и полезная статья... особенно понравилась картинка))) Подходит под смысл данной статьи.
Спасибо за статейку, но по поводу сметы тут тяжело составить точную сумму (для меня например) Есть ряд нюансов которые вылазят в процессе, поэтому стоит предварительно предупреждать, что сумма не есть окончательной, потому что...
@Mediamapa: спасибо за комментарий.
До подписания, смета в любом случае будет оставаться ориентировочной. Более того, до подписания ТЗ составить финальную версию сметы вообще прктически нереально.
Но в этом «нет» я имел ввиду несколько иную ситуацию — часто исполнители просто говорят «вот это будет стоить ХХХ долларов». Так не годится — хотя бы потому, что чаще всего сайт выглядит как конструктор и потому можно отказаться от разработки определенных модулей на начальном этапе, включив их в качестве последующей доработки.
Такой вариант оптимальнее и для заказчика и для исполнителя.
Самое сложное в общении — сказать нет, но не испортить отношение с исполнителем. Все правильно: нужно изначально ставить жесткие рамки условий и требовать их выполнения. Когда просят о том, что сейчас обсуждаем начерно, а потом обсудим подробно — лучше сразу отказать. Не люблю необязательных людей, пусть это будут партнеры, пусть исполнители или заказчики, без разницы.
Я сейчас как раз взялся за новый серьезный проект и заказал разработку ЦМС. На счет дальнейшей независимости собираюсь предъявить разработчику необходимость комментирования кода (если комментариев не будет), я думаю этого достаточно что бы в дальнейшем продолжить разработку без привязки к одному кодеру.
Так как я сам программист, я думаю что комментирования и так подразумеваются...поэтому сразу ему ничего по этому поводу не сказал...
Godfather написал(а):
Из моей практики могу сказать, что абсолютно не обязательно — количество кодеров, которые пишут полноценные и адекватные комментарии к коду равно в лучшем случае 10% от общей массы. И даже не потому, что не могут или плохие программисты — просто лень, ну и подспудная мысль, мол, «чем разбираться в коде — проще будет мне заплатить за новую разработку».
Если вы предлагаете клиенту услуги по созданию, продвижению сайта на непонятом «чатловком языке» программеров и веб мастеров — в 50% клиент вас не поймет, будет пугаться что сам как осел. Нежнее... не заваливаете его непонятным «контентом», дайте понять что и он чего то понимает. Очень хорошо, если вы показываете как у других перспективных людей ...дизайн...и. т.д. Спрашивайте клиента на примерах !
Да, с заказчиком надо как можно строже, но не перегибать.
Но и уступать нельзя, иначе на шею сядет.
В крайнем случае можно зарегистрировать домен по доверенности от заказчика.