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
Вы говорите о вариантах, когда клиентов тупо доят дяденьки в галстуках. К сожалению бывает и так. Но перед тем, как делать заказ на кругленькую сумму, всегда стоит послушать отзывы и мнения других клиентов. Если заказчик попал на удочку таких «бизнесменов», то он сам виноват. В данном случае он лох.
Я же говорю именно о качественном обслуживании. Когда пожелания заказчика внедряются быстро и довольно недорого. Совершенно всегда разработчик 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, которые являются массовыми — стоимость будет выше, поддержка медленней, но при этом Вы не будете зависеть только от меня, имея возможность всегда выбрать другого разработчика, в том случае, если возникнут какие-либо спорные моменты.
Понятно, что эти варианты озвучены очень грубо, на практике они должны звучать гораздо мягче и более «выгодно», но быть они должны.
Это уже вопрос несколько иного порядка — он отностся к моменту ценообразования, и пропорции между качеством и стоимостью.
Опыт большой, к сожалению или к счастью :) Но Вы не совсем правильно меня понимаете — я не рассчитываю на кидок, я просто изначально готов к тому, что он вообще может произойти. А это не совсем одно и то же.
Более того, я никогда никого огульно не обвиняю в желании обязательно кинуть заказчика, но при этом знаю, что в ситуации «я или изаказчик», всегда выбирается «я» — это вообще общечеловеческое, своя рубашка всегда ближе к телу, чем к тушке малоизвестного заказчика :)
Поэтому, оптимальнее изначально подстраховаться и иметь возможность легко минимизировать последствия, чем видеть картину в розовых тонах, а потом вляпаться по самые уши. Если проблема будет — ок, я к ней готов. Если не будет — отлично, я рад, что все прошло на «ура».
Так что это не «ожидание кидка», это страховка — так же как, например, с автомобилем. КАСКО покупается не потому, что водитель обязательно расчитывает въехать в столб, а по причине потенциально существующей возможности ДТП или ПДТЛ.