Ваша компания, далёкая от 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 и сложные сайты
У нас в Зионек есть два основных направления работы (или если угодно, две темы) — с одной стороны, мы внедряем CRM, что не требует особого визуального дизайна; и с другой стороны, мы разрабатываем Интернет-магазины и корпоративные порталы, где визуальный дизайн как раз нужен. Наш подход в этих случаях различается. В данной статье мы расскажем о том, как у нас устроена работа без брифов на CRM-направлении.
Это кейс компании Зионек. Мы внедряем CRM, разрабатываем корпоративные порталы, Интернет-магазины и сложные высоконагруженные системы.
Выявление потребностей клиента при внедрении и кастомизации CRM
Когда речь идёт о CRM, то тут главное внимание — на бизнес-процессах. Нам нужно понять компанию нашего заказчика, как и что там происходит. Нам нужно понять те точки, где можно улучшить, автоматизировать, сократить время и издержки на реакции — то есть то время, которое уходит на те или иные рутинные работы.
И вот здесь самое главное в нашем подходе — это то, что вообще никаких брифов мы не даём клиентам. Мы пришли к этому не сразу; мы прошли разные стадии отказа от брифов, но уже несколько лет, как мы полностью от них отказались и разработали свой собственный подход к выявлению потребностей заказчика. При этом мы используем нашу собственную, специально нами разработанную форму ТЗ.
Но сначала давайте увидим, что происходит, если разработчик просит клиента заполнить бриф.
Проблемы с брифом: что происходит, если используется бриф
Обычно, если вы используете бриф, то получается так: на первой стадии, вы присылаете клиенту этот огромный word-документ, и задача клиента — его заполнить. Это сама по себе большая и долгая работа, но клиент её делает, он думает, что это необходимо, и заполняет этот самый бриф.
Конечно, клиентам совсем не нравится заполнять брифы, это 100% так, никакого открытия тут нет — все разработчики прекрасно знают, что клиенты не любят заполнять брифы!
И вот на следующем этапе — после того, как бриф заполнен, когда уже начинается какой-то процесс работы или первые встречи — получается, что эти же самые вопросы, которые были в брифе, люди спрашивают ещё раз. Это происходит постоянно, и в результате, у всех людей, вовлечённых в процесс, нет никакого ощущения ценности брифа, и понимания зачем он вообще нужен — зачем тогда был бриф, если мы снова обсуждаем то, что уже туда писалось?
Поэтому мы в Зионек никаких брифов не заполняем, никаких брифов клиентам не высылаем.
Наш подход к “брифованию без брифов” при внедрении и кастомизации CRM
У нас для CRM есть своя собственная разработанная форма ТЗ, которая вовсе не огромный word-документ на 300 страниц, а excel-файл с вложенными листами, в котором клиент визуально понимает, как будет работать его система, где будут и какие автоматизации; там обозначены обязательные поля и видно, что будет происходить с коммуникациями; и так далее. По сути, этот документ — это наше ТЗ, у которого наш особый дизайн. Очень важно тут то, что его заполняет не клиент; этот документ заполняет наш специалист, во время интервью с клиентом — заполняет в реальном времени, отталкиваясь от того, что говорит клиент, что он рассказывает о своём бизнесе, о своих процессах и своих потребностях.
Таких встреч может быть одна или две, это зависит от объёма проекта, и на них наш консультант всё прорабатывает, а затем соответственно согласовывает с клиентом законченный документ. В среднем это занимает одну-две недели — разработка вот этого технического задания, — но после этого ни разу не было проблем с приёмкой работ и с пониманием у заказчика, что он получит на выходе.
Важный аспект — это то, что мы делаем записи всех созвонов (с разрешения клиента, разумеется), чтобы потом можно было освежить в памяти, о чём мы договорились. В результате, на любом этапе, когда у нас возникают сомнения — мы возвращаемся к записи либо комментариям и не дёргаем клиента, то есть мы экономим его время.
Таким образом, весь наш процесс устроен так, чтобы, с одной стороны, мы всегда могли точно понять, что именно хочет клиент, во-вторых, всё это задокументировано, и в-третьих, мы специально всё организуем так, чтобы тратить как можно меньше времени клиента на эту работу.
Если бы, допустим, мы просили заполнять брифы — то очевидно, что во-первых, клиент бы потратил на это много времени, а во-вторых, у нас несомненно всё равно бы возникли вопросы, и несмотря на бриф и потраченные на него усилия, нам всё равно пришлось бы созваниваться и выяснять их. А это значит, что всё равно у нас обязательно должен быть отлаженный процесс документирования того, что нам говорит клиент на таких созвонах. Поэтому мы просто вообще не просим клиента делать то, что можно не делать, и концентрируемся на том, чтобы полностью понять и задокументировать его потребности с минимальными затратами его времени.
Ещё одна важная сторона нашего процесса — экономия времени клиента
Мы — 1С франчайзи. В тех случаях, когда мы берём проект полностью, мы естественно и делаем всю работу «под ключ» — и сайт, и 1С. Однако, в других случаях мы отвечаем только за какую-то одну из частей, и вот тогда мы взаимодействуем напрямую с подрядчиками нашего заказчика, минуя его, чтобы максимально экономить его время. Другими словами, технический вопрос мы задаём именно нужным людям, и мы стараемся всё решать таким образом, чтобы для клиента это всё было незаметно: он ставит задачу — мы делаем, мы всё решаем сами, насколько только можем.
Конечно, другие вопросы — организационные, управленческие — мы, разумеется, решаем только с клиентом. Клиент нужен по серьёзным вопросам, где без него решить невозможно — там, где нужно его видение, согласование, где вопрос касается его бизнеса. Все же технические вопросы мы решаем без него.
Очень важно то, что когда мы осознанно стараемся изолировать заказчика от всех технических вопросов (настолько, насколько возможно), это не только экономит его время. Это ещё экономит наше время, а главное — это повышает качество процесса и качество создаваемой системы. В выигрыше все — и заказчик быстрее получает более качественную систему.
Что думают клиенты о работе без брифов
Несмотря на огромные преимущества работы без брифа, мы видим, что все новые клиенты всегда просят прислать бриф. Когда мы им объясняем, что с брифом не так, и как мы работаем, и что брифов не будет — все клиенты всегда очень радуются. Ещё бы! А потом, когда мы объясняем ещё и почему мы так работаем — все радуются вдвойне. Понятно, что сначала клиенты радуются, потому что им не надо всё это заполнять, все эти сотни страниц — это круто. А второй момент, они радуются, что при этом мы сами за них всё напишем — а от них требуется просто рассказать. Поговорить любят все, а если при этом ещё и решатся их проблемы — это же великолепно!
При этом, конечно, мы на самом-то деле брифуем клиента и документируем его ответы, но при этом мы задаём только нужные вопросы. И при этом не все, которые были бы в брифе, это понятно — ведь некоторые вопросы можно и не задавать, когда вы общаетесь напрямую, уже многое вы знаете, или же оказывается, что клиент уже ответил вам более полно на заданный ранее вопрос. Поэтому у нас есть просто стандартные вещи, которые мы точно спросим, и затем всегда появляются новые элементы, когда клиент начинает свой процесс рассказывать. Всегда появляется что-то нестандартное, и мы соответственно углубляемся туда, чтобы всё охватить.
Мы, конечно, не сразу пришли к такому процессу — у нас шла эволюция наших собственных процессов, но теперь наш метод “брифования без брифов” каждый раз доказывает свою эффективность — и с точки зрения качества результата, и с точки зрения времени разработки, и с точки зрения экономии времени клиента. После этого в 100% случаев клиент доволен.
Отказ от брифов при разработке сайтов, корпоративных порталов и Интернет-магазинов
В следующей, второй части статьи, мы разберём наш метод выявления потребностей клиента в случаях, когда необходим визуальный дизайн — при разработке корпоративных порталов и Интернет-магазинов.
Дополнительные технические аспекты эффективной работы без брифов.
Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.
И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/ и вот наша страница контактов. Пишите, звоните — мы вас поймём, проконсультируем, поможем!
