Веб-разработчики: «Только мы сами можем превратить клиента в м*дака»

На прошлой неделе на DK.RU вышла колонка генерального директора «АРК Девелопмент» и сервиса по доставке правильного питания UNIKFOOD Никиты Попова, где он рассказал, с какими трудностями столкнулся, когда заказывал сайты для своих компаний. Еще раньше предприниматель Иван Зубарев поделился своей историей, как вложил 1,5 млн руб. в разработку сайта, но в итоге остался ни с чем.

 

Тема вызвала бурные обсуждения как со стороны предпринимателей, так и со стороны разработчиков. В редакцию DK.RU обратились несколько владельцев компаний по созданию сайтов, которые хотели бы ответить на претензии заказчиков. Приводим мнение двоих из них. 

 

«В момент, когда мы взяли заказ — он стал нашей проблемой»

 

— Часто мы сталкиваемся с непониманием в отношениях между IT-компаниями и их заказчиками. Когда заказчик недоволен — его претензии примерно понятны. Они ярко выражены в колонке Никиты Попова. Условно эту позицию можно описать так: «Все IT-разработчики — криворукие уроды». В ответ обычно транслируется: «Вы профаны, сами ничего не понимаете, заказывать IT не умеете». 

 

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

 

Общая цель и ответственность

 

Первое, о чем надо договориться при работе над любым, в том числе IT проектом, – об общей для всех участников цели. Мысль простая: «Прежде чем придумывать ответ на вопрос: «Как будет устроен сайт», надо ответить на вопрос: «А какая от него должна быть польза?»

 

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

 

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

 

Главная ошибка в кейсе, который рассказал Никита Попов, в том, что общение шло про то, как выглядит сайт, а не про то, как он добивается цели. Это, в целом, значит, что менеджмент разработчика не справился со сложным клиентом.

 

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

Взаимное уважение

 

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

 

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

 

Мы не должны объяснять заказчику, как делать его бизнес — он лучше нас в нем разбирается. И точно так же мы не должны позволять формулировать требования в терминах хотелок и принимать решения в нашей зоне компетенции за нас. Мы отвечаем за то, чтобы то, что мы сделали, работало. В момент, когда мы позволяем принимать решения за нас, ответственность размывается, возникает риск потери управления проектом. Это прям красный флаг – надо срочно что-то в проекте чинить. 

Все это внутри JetStyle называется «Принцип мудака Шредингера» и значит следующее: только мы сами можем превратить клиента в мудака. Не бывает плохих клиентов, бывает потеря управления. Уважайте клиента, относитесь к нему по-человечески и вовремя говорите «Нет». Тогда и клиент будет нас уважать. 

 

Цена вопроса

 

И наконец, про деньги. Никита называет цифры «больше 350 тысяч за сайт». Мне это кажется и большой, и маленькой суммой сразу. Давайте, я расскажу историю. 

 

Позавчера ко мне пришел мой друг с вопросом: «Сколько сейчас стоит сделать дизайн сайта и логотип?». Он хотел начать розничный медицинский бизнес. Я ему сказал, что начиная бизнес, не надо платить за дизайн сайта ничего. Что логотип тоже подождет. А сайт можно сделать, например, на Тильде за ноль рублей. Да, придется потратить собственного мозга и времени.

 

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

 

Итог

 

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

 

— Заказчик не берет сайт с полки в супермаркете, он заказывает его разработку. Качество сайта напрямую будет зависеть не только от качества процесса его производства, но и от качества контроля этого процесса со стороны заказчика.

 

Выберите ответственного сотрудника внутри компании

 

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

 

Как выбрать подрядчика

 

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

 

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

 

Обратите внимание на дизайн сайтов, на удобство пользования. Перейдите на сами сайты и попробуйте пройти путь посетителя сайта от начала и до конца. Достигает ли посетитель цели?

 

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

 

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

 

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

 

Посетите офис подрядчика — это даст вам возможность увидеть реальный размер компании. Попросите показать технический отдел, отдел дизайна. Если у подрядчиков нет собственного отдела разработки, не стоит ему заказывать сайт со сложной бизнес-логикой.

 

При выборе платформы сайта обратите внимание, что создать сайт на готовом, популярном решении (Bitrix, Wordpress, Joomla и многие другие) будет быстро и дешево. Но любые изменения логики работы под требования заказчика будут проходить тяжело, и вряд ли будут сделаны качественно.

 

Выбор самописной CMS зависит от того, на каком фундаменте построена система. Если это всемирно используемые фреймворки Zend, Symfony или Yii, то такой сайт может поддерживаться и развиваться силами подрядчика, собственного отдела разработки или компанией, в штате которой есть квалифицированные программисты.

 

После серии встреч у вас останется 2-3 компании, которые вам понравились больше других. 

 

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