Какие уточняющие вопросы стоит задать заказчику перед стартом разработки

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

Екатерина Баукина, руководитель отдела ведения проектов digital-интегратора DD Planet, вспомнила самые яркие примеры, когда правильные вопросы помогли избежать проблем.

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

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

Оценивая новые фичи, мы с какого-то момента стали делать две оценки: одну на .NET и вторую на 1С-Битрикс – и задавать клиенту наши вопросы. Через несколько месяцев он задумался, а может быть, ему достаточно функционала Tilda для его целей? В итоге он соотнес свои задачи и бюджеты и выбрал менее дорогой вариант.

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

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

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

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

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

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

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

Уточните, есть ли товарный каталог и 1С-интеграция. Кто будет поддерживать актуальность данных в 1C?

Всегда добивайтесь от клиента выгрузки старого товарного каталога до старта работ. Тут целый вал потенциальных ловушек: начиная с неготовности 1С и отсутствия отдельных свойств в базе, полного “зоопарка” в наименовании свойств, по которым должна осуществляться фильтрация, и заканчивая отсутствием у клиента 1С и товарной базы в принципе в каком-либо виде. В таком случае иногда мы даже слышим совет собрать данные по товарам со старой версии сайта (которая уже не поддерживается и к которой нет доступов).

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

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

Задайте клиенту вопрос, как именно он планирует принимать и затем обрабатывать платежи со своего сайта. Если есть платежные системы, сразу уточните, какие.

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

Бывает, что платежная система, которую нужно интегрировать, со своими особенностями или какая-нибудь региональная. Ведь на этапе продаж как? Оцениваем функциональность – интегрируем платежные системы в CMS. Все легко и понятно, и даже есть плагины. Но в нашем случае мы не поленились спросить, а какие именно системы предполагаются. Те, которые нам перечислили, называются Oson, Click и Payme. Это платежные системы Узбекистана, и слышали мы о них, честно говоря, впервые.

Хорошо, что на сайтах документация была в наличии и понять, что это за зверь и как с ним подружиться, было несложно. Но, согласитесь, оценка трудозатрат на интеграцию с таким “зоопарком” будет выше, чем интеграция с привычными Яндекс.Кассой или Сбербанком. Если бы мы опомнились позднее, это грозило бы нам определенными проблемами.

Еще клиента надо спрашивать про возможность оплаты товаров за наличные, если мы делаем такую опцию – хотим ли мы получать обратную связь по статусу заказа. И если хотим, то откуда? Из 1С или CRM, например. В ТЗ может быть указано “обновление статусов заказа”, но никакой интеграции по заказам, которые оплачиваются не онлайн, нигде не прописано.

И последнее. На локальных рынках существует много систем, у которых хорошо если есть API на сайте, но плагинов для Битрикса нет. Необходимо учитывать риски: все интегрируется, но в разные сроки. А именно сроки чаще всего волнуют клиента в первую очередь.

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

Как бы кроссбраузерно вы ни тестировали сайт, лучше сразу знать, на чем будет первый показ и уделить особое внимание проверке под него. Например, один наш клиент уточнил, что у всех его сотрудников, которые будут пользоваться порталом, рабочие телефоны Xiaomi. Следовательно, их мы тестировали в числе первых.

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

Нестандартные и устаревшие версии браузеров и операционных систем – отдельная боль. Уже, наверное, мало осталось тех, кто может открыть сайт в Internet Explorer, но может попасться, например, любитель странных браузеров и разрешений экрана. Зная это, вы сэкономите свое время и нервы клиента.

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

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

И последнее, что важно выяснить, не только оплачен ли хостинг (аналогично истории с оплатой домена), а также у кого к нему есть доступы. У нас в практике был случай, когда доступ к хостингу “ушел” и сайт был взломан. Поэтому за доступами очень важно следить, на доработке сайта все их обновить и удалить лишние – чтобы они были только у вас и вашего клиента, ни у кого больше.

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

А у вас бывали подобные ситуации? Что еще всегда спрашиваете у заказчиков?