Web-студия №1 рассказала, почему конфликтуют клиенты и веб-разработчики - и это не только деньги

Поделиться

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

Marketing.by поговорил о типичных конфликтных ситуациях между веб-разработчиками и клиентами с Иваном Панасюком, заместителем директора по коммерческим вопросам компании «Новый сайт», которая уже второй год подряд получает от «Рейтинга Байнета» первое место в рейтинге беларуских web-студий.

577_oooo.plus.png

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

- Самая популярная причина для конфликта, конечно же, деньги?

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

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

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

Конфликтные ситуации из-за стоимости проекта происходят из-за особенностей нашего рынка. В более развитых странах в основном стараются придерживаться модели гибкой разработки – Time&Materials, когда обрисовывается некий scope проекта и разработчик движется короткими шажками, не проектируя сильно далеко. А заказчик оплачивает фактические трудозатраты команды.

giphy.gif

В Беларуси клиенты на Time&Materials готовы редко, в подавляющем большинстве заказчики приходят с бизнес-требованиями, а не способами их технической реализации. Что я имею в виду: задача «должен быть личный кабинет с возможностью формирования бухгалтерских документов» технически может быть выполнена 10 способами: первый потребует десять часов команды, а десятый – тысячу часов. Задача будет решена и там, и там, но с разной степенью эффективности, внешним видом и т.д.

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

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

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

giphy (1).gif

- Еще причины для конфликтов есть?

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

Бывает, что в госорганизациях получение результата ставится на одно из последних мест (хотя декларируется все как нужно). А на первый план выходит внутренняя борьба сотрудников, каждый из которых пытается решить свои политические цели и не дает другим заслужить лишнюю звездочку перед руководством.

Из-за качества разработки конфликтов не так много – видя портфолио, можно заранее сформировать примерные ожидания. Хотя, если компания заказала за 100 долларов сайт качеством не хуже, чем у Apple, то конфликт, конечно возникнет :)

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

giphy (2).gif

- Есть инструменты, как еще на этапе договореностей скорректировать ожидания заказчика?

- Сделать на 100% это невозможно. Ведение протоколов и рассматривание примеров не всегда помогает, все равно человек склонен запоминать то, что выгодно ему.

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

- Хорошо, в процессе вы начинаете понимать - начинается конфликтная ситуация. Что предпринимаете?

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

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

Если мы прощелкали и конфликт выскочил, начинается этап переговоров. Модели поведения здесь могут быть разными - в зависимости от проекта. Иногда приходится идти на уступки и брать убытки на себя, иногда получается доказать заказчику, что необходимо доплатить. Но до судебных разбирательств доходим очень редко, почти всегда удается договориться.

- Можно ли в конфликтной ситуации не только завершить проект, но еще и разойтись друзьями?

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

sup-bro-_background_.gif

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

- Какие советы вы могли бы дать компаниям, которые собираются разрабатывать сайты?

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

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

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

fa8d38f28940fb3ca0195e2096e555e1.gif

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

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

Поделиться
Материалы по теме:
Обсуждение:
Читайте также: