БЛОГ

Игра по правилам

22.01.2014

Игра по правилам

Господа, людей можно разделить на три группы:
- те, кто занимается разработкой сайтов,
- те, кому разрабатывают  сайт,
- асоциальные личности, которым безразлична судьба мира.

В связи с этим предлагаю поднять животрепещущую тему: рассмотрим ситуацию, когда вместо хорошего веб-проекта получается кусок шлакоблока, скрепленного сплошным негативом. Вроде бы, и заказчик горел душой за будущий сайт, и разработчик вложил кучу сил и энергии, а на выходе имеем конфликт и результат, не удовлетворяющий ни одну из сторон.

Виной всему один прискорбный факт: кто-то играет не по правилам.

Возьмем идеальную ситуацию: перед стартом проекта заказчик и разработчик желают одного – быстро и качественно разработать сайт согласно утвержденным требованиям. Они подписывают договор, ТЗ (техническое задание), тайминг, и начинают плодотворное сотрудничество.

В идеальной ситуации все участники проекта «играют по правилам»: быстро предоставляют необходимые данные, выдают результат в срок, делают все возможное, чтобы проект соответствовал утвержденным требованиям.  Обе стороны настроены на результат. Все планы и сроки рушатся обычно по одной банальной причине – из-за человеческого фактора, который невозможно предугадать и предусмотреть.

Завершим с идеальной ситуацией: как уже было подчеркнуто раннее, в ней все играют по правилам. Дизайнер предоставляет креативные макеты в указанный срок, клиент сразу дает адекватные комментарии, программист ваяет фееричную верстку и админку, менеджер завязывает сверху бантик – и  вуаля, проект готов.

Теперь перейдем к жестокой действительности: за всю свою обильную карьеру менеджера веб-проектов я не встречал ни одного заказа, в котором все участники всегда играли бы по правилам. Думаю, виновата статистика: у каждого участника есть десятки (если не сотни) моментов, когда можно нарушить правила, и вполне естественно, что хотя бы один раз кто-то их да нарушит. Ну а дальше все катится снежным комом.

Мораль данной статьи проста до чертиков: играйте по правилам. Если вы решили их нарушить, будьте готовы к тому, что нарушение последует и с другой стороны. Это до банального логично, но очень многие этого не понимают. Если вы желаете сдать проект максимально быстро и сделать его качественно, играйте по правилам, и никому другому не позволяйте их нарушать.

Тактика игры по правилам касается любой области деятельности человека: работы, отдыха, отношений… Нас же интересует только область веб-дизайна, потому предлагаю рассмотреть близкие нам нюансы игры по правилам на трех основных уровнях.

Заказчик

Не верьте банальностям – клиент не всегда прав, как бы ему этого не хотелось: порой он заносчив, вспыльчив и чванлив. Однако, для нашего примера возьмем среднестатистического клиента, вполне адекватного и нацеленного на результат.

Обычно клиенты требуют одного – сдать проект как можно скорее. Они могут еще не понимать, что именно им нужно, не задумываются о стоимости, но они уверены в одном: сайт должен быть готов еще вчера! Позиция понятна, и, в некоторых случаях, вполне оправдана. В остальных же это та самая ситуация, когда заказчик первым нарушает правила, которые сам же задал.

Самый банальный и одновременно частый пример – задержка с предоплатой. При подписании договора так же утверждается тайминг – детальный график всех этапов работ над сайтом. В этом тайминге русским по белому написано: утром предоплата, вечером старт работ по разработке сайта. Клиент адекватен, потому полностью согласен с такими условиями.

Тогда почему он не понимает, что, в случае двухнедельной задержки оплаты, сроки так же сдвигаются на две недели? И почему не понимает банальной логики разработчика: раз клиент легко сдвигает сроки, то не такой уж проект и горящий?

То же самое касается подачи комментариев к макетам: клиент кричит, что сайт нужен позавчера, названивает каждые полчаса, получает макеты и пропадает на неделю. После этого он врывается в жизнь разработчика с комментариями, требует внесения правок через час, получает макеты и вновь пропадает на неделю.

В данной ситуации разработчик делает вполне логичный вывод, что, раз клиент тянет с комментариями целую неделю, то несколько часов задержки особой роли не сыграют. И, естественно, он не прервет работу над другим проектом, чтобы потратить 1 час на ваш и ждать реакции еще неделю.

Игра по правилам требует скорости не только от исполнителя, но и от заказчика. Однажды сдвинув сроки, заказчик создает прецедент, которым может воспользоваться и разработчик. Не давайте им такой возможности, не создавайте прецедента, если не желаете нарушения правил противоположной стороной.

У меня был проект, работа над которым заняла год: клиент постоянно пребывал в командировках, и на каждое утверждение макета уходил примерно месяц – причем форсировать не было возможности, так как с клиентом просто не было связи. Ну, бывает, ситуация понятная…однако каковым же было мое удивление, когда через год клиент спустил на меня всех собак в связи с затяжкой сроков? Не помогли даже предъявленные письма, которые я ему слал каждые 2-3 дня с требованием комментариев по макетам…но вернемся к адекватным ситуациям.

Следующими важными этапами для клиента являются предоставление данных хостинга и содержания. Разработчик физически не сможет перелить сайт на хостинг клиента, если тот не предоставит ему настроек; точно так же он не сможет наполнить сайт содержанием, если содержания в наличии нет. Оба эти момента обсуждаются на первой встрече и прописываются в тайминге, потому задержка со стороны клиента зачастую объясняется обычной невнимательностью или откровенным разгильдяйством.

Так же, у разработчика свой график проектов, в котором рассматриваемый проект не является единственным, потому, пожалуйста, предоставляйте данные в срок. Если вы затяните на неделю, и разработчик начнет работать над другим проектом, он не сможет прерваться в ту самую секунду, как получит информацию от вас – ему сначала придется закончить работу. Только после этого он сможет заняться вашим проектом, потому не удивляйтесь, что сроки изменятся.

Поймите простую логику: если правила вам важны, то вы их придерживаетесь; если вы их нарушаете, то не так уж они и важны. Понимая это, разработчик начнет вести себя соответственно. Не нарушайте правила! Как только вы их нарушаете, вторая сторона понимает как само собой разумеющееся, что они больше не имеют особой силы.

Разработчик

Самый часто встречающийся вариант нарушения правил разработчиком – затягивание сроков. Дизайнеру не пришло вдохновение, клиента не устроили 3 макета и пришлось рисовать еще 7, программирование заняло больше ожидаемого времени…

Опять таки, возьмем  идеальную ситуацию: все участники процесса адекватны, профессиональны и лояльно относятся к своим обязанностям. Если это не так, то вопрос быстро решается через отдел кадров. В этом случае задержка сроков – это ошибка менеджера веб-проектов: недопинал, недостучал по голове, неправильно донес информацию, поручил работу не тому человеку. Адекватный менеджер не должен допускать таких ошибок: его ответственность в соблюдении правил гораздо выше, чем ответственность клиента.

Клиент в данном случае волен создавать и нарушать правила. Как уже говорилось раньше, нарушение правил клиентом приводит к их девальвации. Однако, если первым правила нарушил разработчик – ждите грозы. Тут уж клиент оторвется по полной: вспомнит и про условия договора, и про тайминг, и про вашу профпригодность. Однако, основная опасность грозит менеджеру не со стороны клиента.

Клиент может заказать картину Репина, а дизайнер выдаст Квадрат Малевича, упрется мышкой в пол, что это его видение, и потребует отправки макета клиенту. Либо дизайнер сдаст результат в срок, клиент – утвердит макет, а потом вдруг вяснится, что в макете левые шрифты или что разработанный и утвержденный дизайн не удастся сверстать согласно требованиям клиента (прописанным в договоре, на секундочку).

Менеджер должен не только максимально точно соблюдать техническое задание и тайминг, он обязан контролировать каждого участника проекта со своей стороны: сидеть на голове у дизайнера, приносить кофе программисту, предварительно уговорив его поработать сверхурочно, помочь наполнить сайт контент-менеджеру…И он должен четко и ясно давать понять клиенту, что не допустит апокалипсиса в виде прямого общения клиент-дизайнер или клиент-программист.

Ответственность менеджера при игре по правилам превышает ответственность любого другого участника проекта, потому тщательно подумайте, выбирая человека на эту позицию – потом аукнется.

Форс-мажор

Форс-мажор в процессе разработки сайта – это обстоятельства, напрямую не зависящие ни от заказчика, ни от разработчика. Эти обстоятельства нужно просто объяснять друг другу и терпеливо сносить возможные задержки. Как правило, они не занимают много времени.

Сюда можно отнести обновление NS, оплату хостинга, получение и обновление настроек, DOS-атаки, технические работы на стороне хостеров и так далее. В таких задержках обычно нет вины участников проекта, потому они не относятся к тактике игры по правилам.

Вывод из этой статьи можно сделать один: если вы утверждаете определенные правила, будьте готовы им следовать. Нарушение правил одной стороной почти всегда ведет к нарушению правил другой. Это только в математике минус на минус дает плюс, здесь же получим кучу негатива и взаимных обвинений.

С другой стороны, качественная игра по правилам гарантирует приятное сотрудничество и удовлетворение результатом. Играйте по правилам, и к вам потянутся люди.