Убийца Excel: как no-code адепту подступиться к заказчику

Мы занимаемся развитием конструктора баз данных и веб-приложений (no-code, low-code) и много времени проводим в разъяснениях, что же это такое. Кроме прямых доводов, как, например, загрузка более полумиллиарда записей в наш конструктор, приходится работать с весьма неожиданными вопросами и возражениями.

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

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

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

airtable.com – замена Excel и Google-таблиц: этакий Excel на стероидах

creatium.io – конструктор сайтов, претендующий на «всё-в-одном»

bpium.ru – российский аналог Airtable с элементами автоматизации

directual.com – конструктор баз данных, процессов и форм

integram.io – конструктор баз данных и веб-приложений

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

Что умеют конструкторы no-code

Перечисленные сервисы обычно заявляют о таких ценностях:

1. Всё просто и интуитивно понятно даже для новичка

2. Можно быстро и самостоятельно собрать продукт «без кода»

3. Большое количество проектов и довольных клиентов

4. Если чего не хватает, то можно легко интегрироваться с другими сервисами

5. Хорошие отзывы реальных пользователей

6. Большое сообщество специалистов, готовых помочь

7. Доступно множество шаблонов и наработок, бесплатных и платных

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

Локальная лицензия на установку конструктора на серверах заказчика, включающая сопровождение – устранение дефектов и установка обновлений.

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

Сопровождение – почасовая оплата пакетами по 10-20-50 часов. Это консультации и доработки по проекту, но чаще это просто нахождение в дежурном режиме в готовности быстро помочь в случае необходимости.

Наша целевая аудитория – бизнес от 50 до 700 человек, у кого есть свой отдел IT и/или бюджет для найма разработчиков со стороны. Чаще все таки разработкой занимаются свои сотрудники – 2-3 человека из тех, кто что-то программирует в компании, например, ERP и разную локальную автоматизацию. У них достаточно компетенций чтобы сопровождать IT-продукты или быстро написать что-то несложное.

Глоссарий

ЛПР – лицо, принимающее решение о покупке

Босс, ЛДПР – лицо, действительно принимающее решение (окончательное)

Действующие лица:

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

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

Сотрудники – в основном, мощный костяк сопротивления переменам, просто люди, приспособившиеся к текущим условиям. Часто проект нацелен на уменьшение вреда от них (воровство, безответственность)

Энтузиасты – единичные сотрудники, ждущие перемен и помогающие проекту из совершенно разной мотивации

Потребность ЛПР – улучшать, укреплять и упрощать своё IT-хозяйство, в частности, внедрять и сопровождать новые продукты. Обычные его проблемы: нет нормальной управленческой отчетности, потому что программа многое не позволяет. Он следит за трендами IT и иногда изучает новые инструменты.

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

Так возникает идея проекта, который состоит в замене главной IT-системы компании или создании новой большой системы для управления чем-либо ключевым (логистикой, заказами, договорами, объектами, проверками, аттестациями и т.д.). Например, давайте сделаем ERP или продвинутую CRM:

Проект возникает не от хорошей жизни. Часто у участников присутствует заметный скепсис, а в четверти случаев на стороне заказчика можно даже наблюдать некоторое отчаяние. В любом случае, у инициаторов нет уверенности в успехе – по статистике 84% IT-проектов завершаются не в срок, вне бюджета или с худшей отдачей, чем ожидалось.

В половине случаев (50%) у ЛПР есть некое подобие ТЗ, иногда (25%) проработанное до степени готовности к точной оценке. В 75% случаев есть эксели и подобные таблицы/материалы/системы, которые используются как суррогат задуманного проекта, и по которым можно в принципе понять что происходит и создать нормальное IT-решение.

ЛПР ищет решения на рынке, потому что и сам стремится улучшить своё положение, получить бонус, пополнить резюме.

Как правило, выбор ЛПР таков, если смотреть по убыванию его риска:

А. Развивать самописные системы, которые есть в компании вместе с кучей экселей

Б. Закупить или доработать продукт из линейки 1С

В. Ничего не делать

Г. Найти готовый продукт

Д. Найти новый, более мощный, инструмент разработки или технологию

Е. Заказная разработка под ключ на стороне

В последних трёх случаях риск провала достаточно высок, и надо убедить ЛПР, что он всё предусмотрел и всё очень четко понимает. В этих случаях также наиболее высок риск саботажа со стороны сотрудников клиента.

Недостатки вариантов

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

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

В. Ничего не делать – нет бонусов и удовлетворения амбиций, недовольство начальства

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

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

Е. Заказная разработка – миллионы за проект и, если мы говорим о большом проекте в рамках компании, этот вариант весьма редко рассматривается, потому что люди со стороны сделают всё плохо, не зная специфики и не беря полную ответственность

Где здесь мы

Мы – это вариант Д, но с привлечением консультантов и, возможно, покупкой лицензии.

Схема сходу непривычна для ЛПР, поэтому даже сам формат решения ещё нужно донести. Обычно это требует около двух часов разговора с прогретым клиентом. То есть, с тем, кто уже что-то слышал, знает, где-то читал или просто сам является энтузиастом и изучает новое (таких не более 20%).

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

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

Ещё небольшая часть уже находится в отчаянии, потому что уперлись в фатальные ограничения, например:

Знакомство с продуктом

Итак, ЛПР в надежде попадает в мир ноукода и начинает знакомство:

Если первый пункт сходу не сработал, то, вопреки мнению директологов, клиент – ЛПР – все таки прокручивает лендинг дальше. Это удивительная вещь, но мы получали звонки и выслушивали примерно такое: я просмотрел весь ваш сайт, почти ничего не понял, расскажите мне!

Сайт и звонок создают у клиента понимание, что, вероятно, он сможет успешно выполнить проект:

Что можно считать преимуществами варианта с конструктором

Основное – стоимость (скорость) разработки и доработок.

Второе – минимум ограничений, свойственных конструкторам.

Третье – высокая скорость работы и низкие требования к ресурсам.

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

Обычно на первой встрече (очно или в зум/мит/мост) мы показываем многие вещи на лету: загружаем данные, настраиваем структуру данных, раздаем права, делаем отчеты и формы, выводим данные в виде графиков, объясняем работу шаблонизатора и SPA (режим Single page application).

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

Например, мы загружаем в базу данных пару десятков тысяч записей за полминуты, а потом показываем какова была нагрузка (порядка 20% ЦПУ и 80МБ памяти) на этот сервер, в котором 1 ядро и 1ГБ памяти, и на котором сейчас работают и другие пользователи.

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

Предложение на сайте, которое мы выдаем разогретому клиенту

Онбординг

Первый шаг (необязательно) – регистрация в сервисе, чтобы просто посмотреть, что это действительно работает. Возможно прохождение интерактивных уроков (около 1 часа), а может это просто прокликивание нескольких пунктов меню. Почему-то ЛПР почти всегда хочет сделать что-то своими руками.

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

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

Во время контакта клиент получает ответы на оставшиеся вопросы и убеждается в нашей готовности сотрудничать.

После контакта идет заказ демонстрации или счета на оплату первой фазы – прототип, проработка ТЗ, иная аналитика. Обычно первая фаза – это 30-50 тысяч предоплаты, чтобы проверить на что способен подрядчик.

Что интересует ЛПР

В хорошем случае клиент достает ТЗ или его аналог и начинает спрашивать по списку – можно это, а это, а это, а с этим как? Иногда у него есть эксели, которыми он может поделиться. Бывает поток мыслей в Miro, MindMap или чём-то подобном. В худшем случае – это скрины экранов.

ЛПР просит показать многие вещи, хотя обычно не ожидает, что ему будут что-то показывать, а ожидает чистый маркетинг. В этом есть преимущество – когда вы можете показать что-то практически на любой вопрос.

Список вопросов примерно такой:

После ответов на все эти вопросы (те самые 2 часа) у ЛПР не остается сомнений в пригодности продукта и он занят мыслями, как будет продавать это Боссу.

Оформление и стоимость

Далее ЛПР идет к Боссу и продает ему этот выбор. Босс не колеблется с решением, если ЛПР сам уверен и может убедительно ответить всего на 2-3 вопроса. В рамках компании это незначительные затраты и всех больше волнуют риски, негатив и принципиальная реализуемость проекта. Торга обычно нет, он не имеет смысла, Босс и ЛПР воспринимают подрядчика как своего рода спасителя и не хотят его пока прессовать.

Обычно, можно с приемлемой точностью оценить проект в часах или деньгах, опираясь на количество сущностей, которые фигурируют в ТЗ или рассказе клиента, а также количество экранных форм и интеграций. Первую грубую оценку можно дать уже после первого общения с клиентом. Например, выслушаем около получаса, как устроено его пищевое производство, и говорим, что полностью своими силами сделаем его за 400 тысяч рублей, а как консультанты для его программистов – за 80 тысяч.

Ориентировочная стоимость проекта при выполнении его силами заказчика с помощью консультантов-аналитиков будет от 400 до 600 тысяч рублей, реже – в пределах миллиона рублей.

Для сравнения, подобный проект при заказной разработке будет стоить от 1.5 до 3 млн рублей при тех же существенных рисках.

Сопротивление программистов

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

До 2017 года это не удавалось никому, поэтому мало кто из профессионалов верит в такую возможность, а каждый пятый из них активно сопротивляется ей.

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

Выводы

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

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

Заказчикам мы предлагаем взглянуть смелее на подобные предложения и не пожалеть немного времени на тестирование гипотезы с конструкторами. А разработчикам мы советуем изучить направление no-code и low-code разработки – там уже есть работающие инструменты и методики.

Спасибо!