Некоторое время назад, в блоге была опубликована занимательная статья «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: Ещё думаю стоит добавить требование показать предыдущие работы. Иногда разработчик может сослаться на анонимность клиентов и то, что они не хотят свои сайты демонстрировать. Стоит сказать «нет» в таком случае.