Как отказаться от брифов в веб-разработке и какая от этого польза. (Сложная разработка без брифов, часть 2)

Это вторая статья из серии, в которой мы подробно разбираем процесс, принятый в «Зионек» для выявления потребностей клиента. Мы отказались от заполнения брифов, и это экономит массу времени заказчиков, что весьма их радует. Также, сильно повышается скорость и качество разработки, и это радует заказчиков ещё сильнее. При этом, у нас ни разу не было проблем с приёмкой работ; никогда не было случая, чтобы клиент получил не то, что он «на самом деле имел в виду». Заказчик получает именно то, что хочет, и 100% наших заказчиков остаются довольны результатом. Всё это — без брифов. Нет, это не чёрная магия; в этих статьях мы подробно разбираем наши методы и как нам это удаётся.

Предыдущая статья была посвящена особенностям работы без брифов при внедрении и кастомизации CRM. Эта статья — продолжение, и тут мы рассмотрим наш подход в случаях, требующих визуального дизайна, таких как корпоративные порталы и Интернет-магазины. (Третья статья посвящена техническим особенностям нашего подхода и нашему инструментарию, который является неотъемлемой частью наших процессов)

Но для начала вспомним, чем плохи брифы.

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

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

Это одна из важных причин (однако, не единственная), из-за которых мы отказались от брифов. С тех пор мы никаких брифов не заполняем, и никаких брифов клиентам не высылаем.

Что же мы делаем вместо этого?

Напомню, что мы всё делаем несколько иначе в случаях внедрения CRM — то есть там, где не нужен визуальный дизайн (см. предыдущую статью). Тогда же, когда визуальный дизайн как раз нужен, на первой установочной встрече с клиентом мы просим примеры “что нравится” — то есть, какие сайты похожи на то, что заказчик хотел бы у себя реализовать. И конечно, мы внимательно слушаем, что заказчик хочет рассказать о своих задачах и своём видении. Это прекрасно работает в онлайне, и при этом мы ведём запись всей встречи, чтобы мы могли пересмотреть всё снова.

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

Тут есть несколько важных аспектов.

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

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

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

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

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

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

У нас на всех этапах обязательно присутствуют (может быть даже и незримо) верстальщики и разработчики. Поэтому, наш человек сразу скажет, что, например, с точки зрения вёрстки вот так вот рисовать нельзя, потому что это будет очень сложно реализуемо, или может быть, там баги какие-то могут быть. Другими словами, если в какой-то идее есть некая сложность для реализации, для отображения в интерфейсе взаимодействия с пользователями, особенно с учётом платформ — Битрикс либо ещё какой-то платформы — то мы это сразу узнаем, и соответственно сразу поймём, что так делать не нужно.

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

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

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

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

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

Мы, конечно, не сразу пришли к тому методу работы без брифов, который используем сейчас — наши собственные процессы изменялись постепенно.

Сначала мы писали вордовские документы, и у нас были брифы, как у всех. Мы видели, как с ними плохо, и искали решение.

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

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

Все клиенты, конечно же, очень радуются работе без брифа. Никто не хочет делать долгую сложную работу, если выясняется, что её делать не надо, и это, конечно же, очень приятно. А когда мы объясняем клиентам ещё и почему мы так работаем и показываем преимущества нашего метода — все радуются вдвойне!

Мы стараемся комплексно оказать услугу, то есть мы настраиваем и сайт и всё окружение вокруг, если клиент не против.

Однако, некоторые компании хотят установку и настройку делать сами, и в этом случае мы консультируем их администраторов — как это сделать, какие правильные настройки внести и так далее.

Помимо нашего нестандартного брифования, у нашего процесса есть ещё несколько особенностей, повышающих скорость и качество разработки. Мы их вынесли в отдельную статью: “Наша замена Selenium и другой инструментарий. Сложная разработка без брифов, часть 3”

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

Мы часто берёмся за большие и сложные проекты, но умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!