Ваша компания, далёкая от IT, внедряет у себя CRM, и ваш подрядчик говорит: «Вам нужна лицензия на 1С-Битрикс24. Именно с приставкой “1С”. Без “1С” не подойдёт». Что он имеет в виду и почему не подойдёт?
Эта статья поможет быстро разобраться, что означает приставка «1С» в 1С-Битрикс24 — и вообще, какие технические различия скрываются за различными названиями версий Битрикс.
Это статья подготовлена компанией Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы. Обращайтесь к нам в Зионек с самыми сложными задачами по интеграции и автоматизации бизнес-процессов
Что такое 1С и что такое Битрикс? Краткая история изменения названий.
Когда-то в прошлом, две совершенно разные компании развивали два совершенно разных семейства продуктов.
Фирма 1С давала своим продуктам названия, которые начинались с «1С» — «1С:Предприятие», «1С:Бухгалтерия» и так далее.
Компания Битрикс продавала систему для создания сайтов и управления контентом (CMS) и тоже включила название своей компании в название продукта: «Битрикс: Управление Сайтом».
А потом эти две компании создали совместное предприятие, которое назвали 1С-Битрикс. И теперь, названия продуктов Битрикс получили приставку 1С и стали напоминать названия других продуктов фирмы 1С. Внутри, однако, эти два семейства продуктов остались совершенно разными. Похожи только названия.
Три главных продукта Битрикс
Итак, несмотря на наличие 1С в названии, семейство продуктов Битрикс полностью отличается от продуктов 1С:Предприятие. Их развивают, по сути, разные компании, точно так же, как они это делали изначально. Главных продуктов Битрикс три:
1С-Битрикс: Управление Сайтом (БУС) — система для создания сайтов и управления ими (CMS, Content Management System — система управления контентом). Не включает в себя CRM.
Битрикс24 — облачный сервис для управления бизнесом (CRM, Customer Relationship Management — система управления отношениями с клиентами).
1С-Битрикс24 — коробочная версия Битрикс24, включает в себя все возможности 1С-Битрикс: Управление Сайтом.
Это собственно всё, что вам нужно знать, чтобы не запутаться. Названия у продуктов очень похожи, но если заранее понимать, что вам нужно внимательно смотреть на всё название целиком, то вы застрахуете себя от покупки неправильной версии или не того продукта, который вам нужен.
Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.
И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!
Зачем заказчику ТЗ? Для чего вообще разрабатывать ТЗ и какая выгода заказчику от того, что оно правильно написано? Что сделать, чтобы оно получилось именно таким — правильно составленным и полезным?
Давайте начнём с конца. Как правильно.
Техническое задание и успех разработки
Позвольте мне начать эту статью не с того, кто, как и почему делает что-то неправильно, а с конца — и описать, как всё должно быть на самом деле, чтобы всё получилось хорошо и работы по созданию новой системы и внедрению завершились успехом.
Однако, что такое успех?
Успех — это когда заказчик получает именно такую систему, какая ему нужна; и при этом именно в те сроки, и за те деньги, о которых договаривался с исполнителем (а может быть, даже быстрее и дешевле, а система получается более функциональна).
Для того, чтобы достичь этого успеха — исполнителю/разработчику нужно очень точно знать, в очень конкретных и чётких технических терминах, какие конкретно работы ему предстоит осуществить.
А вот тогда, когда исполнителю/разработчику это на самом деле неясно, и новые задачи вдруг неожиданно всплывают в процессе выполнения работ — вот тогда-то и оказываются сроки — сорванными, а затраты превышают запланированный бюджет.
И вот выходит на сцену Техническое Задание.
Техническое Задание — чёткий и детальный технический документ, полностью описывающий все те работы, которые предстоит осуществить исполнителю, чтобы система получилась именно такой, какая нужна заказчику. При этом, оно написано так, что понятно и заказчику, и техническому специалисту. Одновременно ТЗ показывает заказчику, сколько все эти работы будут стоить.
Это кейс компании Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы.
Великолепно, когда у обеих сторон есть такой детальный документ, в котором заказчику ясно видно, что будет представлять из себя система, которую он заказывает; а разработчику ясно видно, в чётких технических терминах, какие конкретно работы ему предстоит осуществить. Это спасение для обеих сторон и заранее снимает все будущие вопросы, заранее разрешает конфликты, и является основой для приёмки законченных работ заказчиком.
Откуда же берётся такое ТЗ? Кто его пишет так, чтобы оно получилось одновременно и совершенно конкретным, детальным, и пригодным к тому, чтобы разработчик мог немедленно начать его реализовывать, и при этом, чтобы заказчик прекрасно видел и понимал, какая система у него будет?
Всё просто: такое ТЗ может составить, и должен составить — сам исполнитель.
Составление ТЗ — то есть технического задания на проектируемую систему — это первый этап разработки. И так же, как и вся остальная разработка, этот её первый этап — составление ТЗ — является ответственностью и обязанностью исполнителя — того самого, который будет реализовывать саму систему на следующих этапах.
Функциональные требования для разработки ТЗ
Для того, чтобы исполнитель мог составить ТЗ, нужно, чтобы заказчик рассказал ему, что собственно требуется от будущей системы. Эта информация называется «Функциональные Требования».
В отличие от ТЗ (технического документа в специальном формате), функциональные требования можно изложить и передать исполнителю в любом удобном виде (в том числе нарисовать на салфетке, написать на листочке А4 или рассказать на созвоне в Зуме), и эти требования описываются в терминах бизнеса заказчика (а не на техническом языке разработчика).
Затем, исполнитель вникает в суть и детали Функциональных Требований заказчика, принимает различные решения о том, как такая система должна быть реализована, и на основе этого составляет подробное Техническое Задание.
Именно перевод функциональных требований в конкретные технические понятия и задачи, выбор нужных программных компонентов, фреймворков, платформ, библиотек и так далее, и является сутью работ при составлении технического задания.
Сам процесс разработки ТЗ занимает существенное время и ресурсы исполнителя и может быть весьма длительным (в зависимости от сложности проекта), но в результате этого этапа получается тот самый документ (ТЗ), понятный и заказчику, и исполнителю, в котором подробно и в технических терминах разработчика, детально изложено, что собственно требуется разработать (т.е. исполнить).
Созданное таким образом ТЗ становится далее частью договора на дальнейшую разработку и основой для расчета сметы на работы.
Что же пошло не так?
А теперь, после такого длинного спойлера выше— описания того, как всё должно быть, когда всё правильно — давайте посмотрим, почему иногда оказывается, что что-то идёт не так.
Время от времени появляются заказчики, которые уверены, что именно перед ними стоит задача «написать ТЗ». Иногда заказчики даже приходят к специалистам-разработчикам с «готовым ТЗ», которое где-то скачали, как готовую школьную домашку. Почему случилось так, что термин «ТЗ» почти повсеместно (кроме области профессиональной разработки) применяется вместо правильного термина «Функциональные Требования»? Откуда взялась эта ошибка в мышлении людей? Ведь заказчик не обладает компетентностью , позволяющей вести разработку или руководить ею, а разработка ТЗ — это первый этап разработки самой системы.
Источник проблемы, скорее всего, в том, что специальный термин «Техническое Задание» (обладающий очень узким и конкретным смыслом), оказался слишком сильно похож на обычное бытовое слово «задание» — а оно, в свою очередь, в быту ничем не отличается от слова «задача». Задача — это и «поставить задачу в CRM», это и записаться к врачу, это и школьная задача на умножение, с которой ребёнок просит ему помочь.
Детям задают в школе разные «домашние задания», родители пытаются усадить детей делать эти «задания»; спрашивают, какую оценку ребёнок получил за то или иное «задание» и так далее. Задания вполне могут быть и устными, и неконкретными, и непонятными, а в процессе выполнения очень часто меняются: никакой чёткости в них нет, никто чёткости не ждёт, и всё это воспринимается спокойно. Со школьных времён всё это слилось в один мутный образ, который теперь мешает нам внятно думать.
В результате, слово «задание» с детства стало в нашей жизни настолько бытовым и нечётким, что уже выросшие взрослые, ставшие заказчиками различных работ, предполагают, что если просто «подробно и детально описать, что нам нужно» — то это описание и будет являться Техническим Заданием для исполнителя (разработчика). «Мы же, в конце концов, описываем серьёзные технические вещи, а не рецепт пирога, — думает заказчик, — значит, у нас получилось Техническое Задание». Увы, это не так.
Очень широкое бытовое использование слова «задание» мешает осознать тот факт, что специальный термин «Техническое Задание» означает совершенно другую вещь. Это вовсе не подробное описание того, что заказчик хочет видеть в своей системе. На самом деле, это описание того, что исполнитель будет разрабатывать, чтобы создать систему, которую хочет видеть заказчик. Да, заказчику этот документ всё равно будет понятен, но разница огромна.
Разные разработчики создают разные ТЗ — как выбрать?
Из всего написанного выше должно быть очевидно, что для одного и того же набора функциональных требований, разные исполнители разработают разные ТЗ. Они будут отличаться техническими деталями, возможно — разными техническим подходами, используемыми библиотеками, платформами и так далее.
Важно, что и системы, построенные на основе этих разных ТЗ, будут иметь различное качество и функциональность — ведь по сути, это будут разные системы. Не забудем, что ТЗ — это первый этап разработки.
Уровень ТЗ соответствует уровню разработчика
Откуда берётся эта разница в качестве ТЗ (и соответственно, в качестве будущей системы)?
У разных исполнителей — различный опыт и уровень экспертизы в инструментах разработки и интеграции. Очевидно, что более опытный разработчик досконально понимает, как использовать все возможности инструментов, знает их особенности и ограничения (в том числе недокументированные), имеет большой опыт их применения в самых разных ситуациях и в состоянии построить систему быстрее и с более высоким качеством. Эта экспертиза будет отражена и в ТЗ, которое разработает опытный исполнитель.
Различная глубина понимания требований заказчика и его бизнес-процессов. Это также связано с количеством и сложностью осуществлённых проектов, опытом и экспертизой разработчика. Глубина понимания бизнес-процессов и опыт внедрения различных сложных систем напрямую влияют на качество ТЗ и качество готовой системы.
Наличие ранее разработанных собственных библиотек, которые решают типичные задачи клиентов. У опытных разработчиков и интеграторов есть большая коллекция готовых и отлаженных компонентов; они запланируют их использование в проекте и соответственно отразят это в ТЗ. Для заказчика это означает, что его система будет готова быстрее и будет иметь более высокое качество и функционал.
И разумеется, разные ТЗ будут предполагать различную стоимость и сроки основного этапа разработки, различную стоимость владения готовой системой, различную будущую расширяемость, и в конечном итоге, совершенно разный бизнес-результат в долгосрочной перспективе.
Более того, совсем необязательно они все будут полностью удовлетворять требованиям заказчика на этапе приёмки! Недостаточно опытный разработчик вполне может ошибиться уже на этапе разработки ТЗ и в конце работы окажется, что «готовая» система сразу же потребует существенных доработок.
Как мы разрабатываем ТЗ в Зионек
Мы в Зионек за много лет накопили очень большой опыт внедрения сложных систем и разработали собственные методы составления ТЗ и выявления потребностей и функциональных требований клиентов — при этом у нас различные подходы к разработке ТЗ для веб-порталов и для внедрения CRM.
Благодаря большому опыту в сложной разработке, мы очень хорошо понимаем, какие подводные камни могут таить в себе те или иные особенности функциональных требований, которые озвучивает заказчик, как эти технические проблемы обходить, и для многих у нас уже есть готовые решения.
Для многих задач у нас есть собственные компоненты и библиотеки.
Наш большой опыт даёт нам возможность выделять главное для бизнеса и приоритетно внедрять именно это главное.
Мы всегда предлагаем заказчику более эффективные, простые и экономичные решения вместо сложных, но в то же самое время, наша экспертиза позволяет нам разработать программные компоненты любой сложности, если это необходимо для успешной интеграции.
Мы специально фокусируемся на том, чтобы экономить время и бюджет заказчика.
Подробно о нашем подходе мы написали в следующих статьях:
Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.
И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!
Заключительная статья о том, как мы в Зионек работаем без брифов — и в результате экономим клиентам время и деньги
Уже много лет как мы в Зионек отказались от брифования клиентов. Мы создаём сложные высоконагруженные системы, внедряем и кастомизируем CRM, и разрабатываем корпоративные порталы и Интернет-магазины — и всё это без брифов. В двух предыдущих статьях этой серии мы рассказали о нашем процессе выявления потребностей клиентов (при внедрении CRM и при веб-разработке), а эта, заключительная статья — о важных технических аспектах процесса нашей работы и инструментах, которые важны для нашего процесса.
Тестирование как важная часть нашего процесса
С точки зрения разработки, важнейший элемент нашего подхода — у нас на всех стадиях присутствует ещё и тестировщик. Прежде, чем мы решаем показать что-то клиенту, у нас это обязательно проверяет тестировщик. При этом на некоторых проектах мы используем автоматическое тестирование — автотесты. То есть, для кого-то мы делаем авто-тесты, а для кого-то ручное тестирование.
Наша замена Selenium: браузер Hat для тестирования web-приложений
Качественные инструменты для тестирования для нас чрезвычайно важны, и поэтому мы серьёзно вложились в разработку качественного решения для тестирования, на которое невозможно наложить санкции и заблокировать его использование. Это браузер Hat — open-source разработка Евгения Сомова, Ведущего тестировщика в Зионек, которая по сути заменяет Селениум (Selenium) — браузер со встроенной технологией автоматизации тестирования Web приложений. Наша компания поддерживает этот проект, и в результате, мы и сами имеем возможность использовать качественный инструмент, и мы также видим ценность в том, чтобы этот инструмент был с открытым кодом и его могло использовать и развивать максимально широкое сообщество программистов.
Интерфейсные окна браузера Hat
Особенность браузера Hat в том, что автотесты напрямую выполняются в браузере — без Selenium и WebDriver.
Встроенный фреймворк HatFramework содержит достаточное количество методов, необходимых для выполнения основных задач автоматизации тестирования. Для описания скриптов автотестов используется язык программирования C# и встроенный редактор кода. Также в качестве редактора можно воспользоваться Visual Studio. Удобный интерфейс браузера отображает все шаги выполнения теста с подробным описанием событий. Результаты проверки формируются в отчет и отправляются на указанную почту. Запуск автотестов возможен из командной строки операционной системы Windows — это пригодится при использовании автотестов в популярных средствах непрерывной интеграции, таких как Jenkins, TeamCity, GitLab CI/CD.
Другой наш важнейший инструмент — система контроля версий. Мы используем везде git — на сегодняшний день, это самая современная система контроля версий, всё остальное практически устарело.
Как ни удивительно, несмотря на огромную ценность использования git, пользуются этим инструментом далеко не все разработчики (мы просто это знаем по тому, что нам рассказывают наши клиенты). Конечно, для клиента это плохо.
Мы же используем git на 100% — мы всё разрабатываем, показываем клиенту, и всё делаем через систему контроля версий. А потом, когда клиентам устанавливаем «боевую» версию, мы это также делаем через git. У нас есть некий стенд — это одновременно пространство для наших тестов и то, как мы показываем клиенту текущую работу. Соответственно, после разворачивания на системе клиента «боевой» версии, дальнейшее взаимодействие идёт таким же образом — что-то мы показываем на тесте, и соответственно, когда клиент это принимает, мы это перекидываем с помощью git на текущую «боевую» версию («прод» в терминологии разработчиков); и, так как мы используем git, то мы не можем потерять какие-то изменения, которые внесли, а в случае чего — можем быстро откатиться назад.
Вот пример, почему это так важно. Допустим, разработчики создают некую новую функциональность и изменения могут затронуть, предположим, 20 файлов. Как понять — какие файлы были затронуты? Особенно, если этот процесс длится неделю-две? Непонятно. А система контроля версий будет знать, какие файлы были изменены. А если её при этом ещё и правильно вести и вносить номер задачи либо фичи, либо номер баг-фикса, то можно точно знать, какой конкретный баг-фикс какие именно файлы затрагивал, и какой конкретно код этих файлов затрагивался. Это визуально видно и можно обеспечивать исправление конкретных ошибок, и при этом остальная разработка продолжается совершенно независимо.
Тот факт, что процессы исправления багов и разработки новой функциональности идут независимо друг от друга, чрезвычайно важен — то есть мы исправляем баги и одновременно, параллельно, развиваем систему клиента, кастомизируем, ведём разработку новой функциональности. Это очень ценно.
Мы используем миграции для баз данных
Для баз данных мы используем миграции. Это примерно то же самое, что git для кода. Всегда, когда нужно переносить базу данных — например настройки, какие-то новые таблицы, новые изменения — мы это делаем с помощью миграции.
Благодаря этому модулю, отправка писем в коробочной версии работает так же, как в Облачном Битрикс24: вы просто создаёте ящики (столько ящиков, сколько вам нужно) в разделе «Почта» в CRM и спокойно пользуетесь, без дополнительных настроек. Модуль работает в почтовом клиенте CRM, в контактах, лидах, сделках и т.д.
Модуль уже настроен на работу с почтой Mail.RU, Яндекс.Почта и Google Mail, но если вам нужно добавить свой SMTP сервер, то это легко сделать в настройках. Это чрезвычайно удобный компонент, полностью снимающий головную боль при настройке почты в коробочной версии 1С-Битрикс24. Всем горячо рекомендую, вот ссылка: https://marketplace.1c-bitrix.ru/solutions/zionec.smtp/
Мы задаём технические вопросы правильным людям
Когда у нашего клиента есть IT-команда, мы всегда взаимодействуем напрямую с техническими специалистами или подрядчиками, минуя клиента с тем, чтобы максимально экономить его время — то есть технический вопрос мы задаём именно нужным людям, и мы стараемся всё решать таким образом, чтобы для клиента это было незаметно: он ставит задачу — мы делаем, мы всё решаем сами, насколько только можем.
Конечно, другие вопросы — организационные, управленческие — мы, разумеется, решаем только с клиентом. Клиент нужен только по серьёзным вопросам, где без него решить невозможно — там, где нужно его видение, согласование, где вопрос касается его бизнеса.
Предыдущие статьи этой серии: Как мы в Зионек выявляем потребности клиента — без брифов и головной боли
Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.
Мы часто берёмся за большие и сложные проекты, но умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!
Продолжение рассказа о том, как мы в Зионек выявляем потребности клиента — без брифов и головной боли
Это вторая статья из серии, в которой мы подробно разбираем процесс, принятый в Зионек для выявления потребностей клиента. Мы отказались от заполнения брифов, и это экономит массу времени заказчиков, что весьма их радует. Также, сильно повышается скорость и качество разработки, и это радует заказчиков ещё сильнее. При этом, у нас ни разу не было проблем с приёмкой работ; никогда не было случая, чтобы клиент получил не то, что он «на самом деле имел в виду». Заказчик получает именно то, что хочет, и 100% наших заказчиков остаются довольны результатом. Всё это — без брифов. Нет, это не чёрная магия; в этих статьях мы подробно разбираем наши методы и как нам это удаётся.
Предыдущая статья была посвящена особенностям работы без брифов при внедрении и кастомизации CRM. Эта статья — продолжение, и тут мы рассмотрим наш подход в случаях, требующих визуального дизайна, таких как корпоративные порталы и Интернет-магазины. (Третья статья будет посвящена техническим особенностям нашего подхода и нашему инструментарию, который является неотъемлемой частью наших процессов)
Но для начала вспомним, чем плохи брифы.
Что не так с брифом: почему брифы не работают
Если вы используете бриф, то обычно получается так: на первой стадии, вы присылаете клиенту этот огромный word-документ, и задача клиента — его заполнить. Конечно, клиентам совсем не нравится заполнять брифы, и все разработчики это прекрасно знают. Это сама по себе большая и долгая работа, но клиенты её делают: они думают, что это необходимо, и заполняют этот самый бриф.
И что же происходит с брифом дальше? А на следующем этапе — после того, как бриф заполнен, когда уже начинается какой-то процесс работы или первые встречи — часто оказывается, что эти же самые вопросы, которые были в брифе, люди спрашивают ещё раз. Это происходит постоянно, и в результате, у всех людей, вовлечённых в процесс, нет никакого ощущения ценности брифа, и нет понимания, для чего он нужен вообще.
Это одна из важных причин (однако, не единственная), из-за которых мы отказались от брифов. С тех пор мы никаких брифов не заполняем, и никаких брифов клиентам не высылаем.
Что же мы делаем вместо этого?
Выявление потребностей клиента без брифов. Веб-сайты и Интернет-магазины (там, где требуется визуальный дизайн).
Первый шаг — установочная встреча
Напомню, что мы всё делаем несколько иначе в случаях внедрения CRM — то есть там, где не нужен визуальный дизайн (см. предыдущую статью). Тогда же, когда визуальный дизайн как раз нужен, на первой установочной встрече с клиентом мы просим примеры “что нравится” — то есть, какие сайты похожи на то, что заказчик хотел бы у себя реализовать. И конечно, мы внимательно слушаем, что заказчик хочет рассказать о своих задачах и своём видении. Это прекрасно работает в онлайне, и при этом мы ведём запись всей встречи, чтобы мы могли пересмотреть всё снова.
Второй шаг — сразу дизайн, созвоны и проработка
После того, как мы поговорили с клиентом и уяснили примерный вид того, что он хочет — мы не создаём никаких ТЗ; вместо этого, мы рисуем дизайн в Фигме. Рисуем несколько главных страниц, на выбор, с учётом того, что нам рассказал заказчик. После того, как заказчик выбирает какую-то концепцию — то, что ему понравилось — мы начинаем уже её прорабатывать. И собственно, мы как таковое ТЗ не делаем вообще, потому что мы документируем всё комментариями в Фигме. Например, если есть какой-то сложный функционал — допустим, калькулятор — то разработчики, верстальщики, клиент и дизайнер могут пообщаться, и непосредственно всё поймут и всё задокументируют там же в Фигме.
Все встречи автоматически документируются
Тут есть несколько важных аспектов.
Во-первых, все такие обсуждения и встречи можно делать онлайн — мы встречаемся очень часто онлайн по сложным моментам и всегда их проговариваем и всё это вносим в комментарии, чтобы потом ни у кого не было вопросов насчёт того, как этот функционал работает.
Во-вторых, мы делаем записи этих созвонов — с разрешения клиента, разумеется — чтобы потом можно было освежить в памяти, о чём мы договорились. То есть на любом этапе, всегда, когда у нас возникают сомнения — мы возвращаемся к записи либо комментариям и не дёргаем клиента, то есть мы экономим его время.
Таким образом, весь наш процесс устроен так, чтобы, с одной стороны, мы всегда могли точно понять, что именно хочет клиент, во-вторых, всё это сразу оказывается задокументировано, и в-третьих, мы специально всё делаем так, чтобы тратить как можно меньше времени клиента на эту работу.
Если бы, допустим, мы просили заполнять брифы — то очевидно, во-первых, клиент бы потратил на это много времени, а во-вторых, у нас несомненно всё равно бы возникли вопросы, и несмотря на бриф и потраченные на него усилия, нам всё равно пришлось бы созваниваться и выяснять их. И при этом, мы всё равно должны были бы создать эффективный процесс для документирования того, что выяснилось на встречах и созвонах. Поэтому мы просто-напросто вообще не просим клиента делать то, что можно не делать, и концентрируемся на том, чтобы полностью понять и задокументировать его потребности с минимальными затратами его времени.
На всех этапах у нас присутствует тестировщик
Прежде, чем мы что-то показываем клиенту, это обязательно проверяет тестировщик. Мы в принципе не показываем нашему клиенту ничего, что не прошло предварительное тестирование. Подробно об этом аспекте нашего процесса, и об инструментах, которые мы специально для этого создали, мы рассказываем в третьей статье этой серии.
Как мы действуем с проблематичными дизайнерскими идеями, у которых могут быть проблемы с реализацией
В веб-разработке, вполне может быть так, что допустим — нарисовали дизайн, а потом, на следующем этапе, стало ясно, что его невозможно запрограммировать так, как он нарисован: либо это будет на самом-то деле плохо, либо слишком сложно технически (и соответственно, дорого). Мы от этой проблемы полностью ушли, вот каким образом.
На всех встречах присутствуют верстальщики и разработчики
У нас на всех этапах обязательно присутствуют (может быть даже и незримо) верстальщики и разработчики. Поэтому, наш человек сразу скажет, что, например, с точки зрения вёрстки вот так вот рисовать нельзя, потому что это будет очень сложно реализуемо, или может быть, там баги какие-то могут быть. Другими словами, если в какой-то идее есть некая сложность для реализации, для отображения в интерфейсе взаимодействия с пользователями, особенно с учётом платформ — Битрикс либо ещё какой-то платформы — то мы это сразу узнаем, и соответственно сразу поймём, что так делать не нужно.
По этой причине, у нас никогда не получается так, что нарисован дизайн, а потом его нельзя запрограммировать или это будет совсем не то, что ожидалось.
Благодаря тому, что наши верстальщики и разработчики вовлечены в проект с самого начала — с этапа предварительного дизайна — мы просто изначально не предлагаем клиенту варианты, которые будут плохи с той или иной точки зрения.
Важная разновидность плохого дизайна: неоправданно дорогие решения
Варианты, которые удорожат клиенту разработку — это важная разновидность плохих вариантов дизайна. Понятно, что в принципе можно сделать всё, что угодно — но мы понимаем, что гораздо лучше предложить клиенту более выгодный для него вариант, который при этом не проиграет ни в качестве, ни в красоте, ни в удобстве, и при этом будут достигнуты цели клиента.
Мы всегда помним о бизнес-целях нашего дизайна — а они состоят в том, чтобы привести посетителя сайта туда, куда нужно, чтобы он пришёл. Так, например, в случае Интернет-магазина, эта цель — покупки, то есть наименьшее количество кликов до покупки, и нужно, чтобы покупатели не отвлекались от процесса покупок и не потерялись по пути.
Разумеется, мы делаем не только Интернет-магазины, но бизнес-цель есть у любого сайта и у любой страницы, и всегда нужно, чтобы будущие посетители сайта — клиенты нашего заказчика — не отвлекались от этой цели; для того, чтобы к ней привести, используются разные механики пользовательского интерфейса и взаимодействия с пользователем (UI/UX), и мы выбираем те, которые наиболее эффективны.
Как мы пришли к такому процессу
Мы, конечно, не сразу пришли к тому методу работы без брифов, который используем сейчас — наши собственные процессы изменялись постепенно.
Сначала мы писали вордовские документы, и у нас были брифы, как у всех. Мы видели, как с ними плохо, и искали решение.
Позже, мы стали делать прототипы без дизайна — блоки, на которые можно кликать и перейти на другой блок. Однако, в итоге и такие прототипы оказались плохи. Дело в том, что когда человек смотрит на прототип, ему кажется, что всё хорошо. Однако, когда это ложится на дизайн, то становится видно, что где-то что-то работает неправильно: например, становится сложно, или появляются какие-то лишние шаги. Поэтому мы отказались от прототипов.
Сейчас мы сразу рисуем дизайн и в нём уже вносим правки. И вот, наконец, это тот подход, который работает отлично и каждый раз доказывает свою эффективность со всех точек зрения: и с точки зрения качества результата, и с точки зрения времени разработки, и с точки зрения экономии времени клиента. После этого в 100% случаев клиент доволен.
Что думают клиенты о работе без брифов
Все клиенты, конечно же, очень радуются работе без брифа. Никто не хочет делать долгую сложную работу, если выясняется, что её делать не надо, и это, конечно же, очень приятно. А когда мы объясняем клиентам ещё и почему мы так работаем и показываем преимущества нашего метода — все радуются вдвойне!
IT-команда клиента
Мы стараемся комплексно оказать услугу, то есть мы настраиваем и сайт и всё окружение вокруг, если клиент не против.
Однако, некоторые компании хотят установку и настройку делать сами, и в этом случае мы консультируем их администраторов — как это сделать, какие правильные настройки внести и так далее.
Дополнительные технические аспекты эффективной работы без брифов
Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.
Мы часто берёмся за большие и сложные проекты, но умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!
