Создание сайта — это не только технический, но и коммуникативный процесс, который требует взаимопонимания и сотрудничества между заказчиком и разработчиком. Как же найти общий язык с профессионалом, который знает все тонкости веб-разработки, но может не понимать ваших бизнес-целей и пожеланий? Как правильно выстроить работу, чтобы избежать конфликтов, задержек и неудовлетворительных результатов? В этом посте мы расскажем, какие правила и рекомендации стоит соблюдать при общении с разработчиком сайта, и какие примеры неудачных проектов из-за плохих отношений заказчика и разработчика стоит избегать.
Какие правила и рекомендации стоит соблюдать при общении с разработчиком сайта?
Какие примеры неудачных проектов из-за плохих отношений заказчика и разработчика стоит избегать?
Существует множество примеров проектов, которые провалились из-за некомпетентности, недобросовестности или недопонимания между заказчиком и разработчиком. Вот некоторыке из них:
В нашей практике таких примеров немного, за 7 лет мы сделали только один сайт, который не смогли запустить. Ситуация была такая: клиенту нужен был сайт с интеграцией специализированной CRM системы. Мы создали сайт, он прекрасно работал. Но на стадии интеграции другой подрядчик залез в код и в буквальном смысле переделал ключевые блоки - корзину, оформление заказа и другие разделы сайта, которые начали давать сбой. Мы не могли помочь, т.к. в чужом коде мы бы утонули и могли еще больше напортачить. Мы предложили клиенту откатиться на предыдущую версию и подключить другую систему. Но, клиент устал от этого и решил работать на старом сайте. Мы очень переживали и пытались помочь как могли, в течение долгого времени вникали и пытались чинить баги, которые вылазили из-за вмешательства. Но, в итоге получилось то, что получилось. Не повторяйте таких ошибок.
Заключайте договр с гарантиями и возможностью отката к рабочей версии. Особенно если подрядчик начинает работать на рабочем сайте.
Какие правила и рекомендации стоит соблюдать при общении с разработчиком сайта?
- Уважайте профессионализм и компетенцию разработчика. Не пытайтесь учить его, как делать его работу, не сомневайтесь в его квалификации и не критикуйте его безосновательно. Доверьтесь его опыту и знаниям, но также будьте готовы к диалогу и обратной связи.
- Сформулируйте четкое и подробное техническое задание. Определите цели и задачи сайта, его структуру, дизайн, функционал, сроки и бюджет. Предоставьте разработчику все необходимые материалы, такие как логотип, тексты, изображения, примеры и т.д. Не меняйте техзадание в процессе работы без веской причины и согласования с разработчиком.
- Выберите удобный канал и формат общения. Согласуйте с разработчиком, как вы будете контактировать: по телефону, почте, мессенджеру, видеозвонку и т.д. Определите, как часто вы будете обмениваться информацией, отчетами и промежуточными результатами. Следуйте правилам нетикета: будьте вежливы, корректны, точны и конструктивны в своих сообщениях.
- Будьте открыты и гибки. Готовьтесь к тому, что разработчик может предложить вам альтернативные решения, улучшения или изменения в вашем проекте. Слушайте его аргументы и мнение, не отвергайте их сразу. Будьте готовы к компромиссам и корректировкам, если они обоснованы и целесообразны.
- Платите вовремя и по договору. Не задерживайте и не урезайте оплату за работу разработчика, если он выполнил все ваши требования и сроки. Не требуйте от него бесплатных дополнительных работ или услуг, которые не были оговорены в техзадании или договоре. Уважайте его время и труд.
Какие примеры неудачных проектов из-за плохих отношений заказчика и разработчика стоит избегать?
Существует множество примеров проектов, которые провалились из-за некомпетентности, недобросовестности или недопонимания между заказчиком и разработчиком. Вот некоторыке из них:
- Quibi: это был сервис для просмотра коротких видео на смартфонах, который прекратил свое существование через полгода после запуска. Одной из причин его неудачи был конфликт между основателями и разработчиками, которые не могли договориться о том, какой должен быть продукт, какой функционал и дизайн он должен иметь, и как он должен работать на разных устройствах.
- Healthcare.gov: это был сайт для регистрации в системе медицинского страхования в США, который был запущен в 2013 году с многочисленными техническими ошибками и сбоями. Одной из причин его неудачи было плохое управление проектом со стороны заказчика, который не смог скоординировать работу нескольких подрядчиков, не смог контролировать качество и сроки работы, и не смог предоставить четкое и единое техзадание.
- Boeing 737 Max: это был самолет, который был запущен в 2017 году, но был приземлен в 2019 году после двух катастрофических аварий, в которых погибли 346 человек. Одной из причин его неудачи была плохая коммуникация между заказчиком и разработчиком, которые не смогли обеспечить безопасность и надежность программного обеспечения, которое контролировало полет самолета, и не смогли предупредить пилотов о возможных рисках и проблемах.
В нашей практике таких примеров немного, за 7 лет мы сделали только один сайт, который не смогли запустить. Ситуация была такая: клиенту нужен был сайт с интеграцией специализированной CRM системы. Мы создали сайт, он прекрасно работал. Но на стадии интеграции другой подрядчик залез в код и в буквальном смысле переделал ключевые блоки - корзину, оформление заказа и другие разделы сайта, которые начали давать сбой. Мы не могли помочь, т.к. в чужом коде мы бы утонули и могли еще больше напортачить. Мы предложили клиенту откатиться на предыдущую версию и подключить другую систему. Но, клиент устал от этого и решил работать на старом сайте. Мы очень переживали и пытались помочь как могли, в течение долгого времени вникали и пытались чинить баги, которые вылазили из-за вмешательства. Но, в итоге получилось то, что получилось. Не повторяйте таких ошибок.
Заключайте договр с гарантиями и возможностью отката к рабочей версии. Особенно если подрядчик начинает работать на рабочем сайте.
