Customer development

У бизнес-разработчиков за дедлайнами, сроками, клиентами и большими запусками может складываться впечатление, что инфраструктура выстраивает свой воздушный замок, который далек от того, что происходит в действительности. Захотев это изменить, Алексей Данилов из разработки перешел в команду инфраструктуры последние два года он развивает ее в Яндекс.Вертикали а это Яндекс.Работа, Яндекс.Недвижимость, auto.ru и Яндекс.Объявления.

Особенность Яндекс.Вертикалей ребята одновременно и бизнес-юнит Яндекса, и обычная IT-компания. Благодаря первому, у них есть возможность использовать яндексовую инфраструктуру, но, благодаря второму, разработчики смотрят на весь стек и используют то, что им удобно. Алексей сегодня поделится с нами, как это можно сделать более удобно и ближе к пользователям (в его случае к разработчикам). А также о том, почему на инфраструктуру сейчас надо смотреть как на продукт и какие вызовы это приносит команде, но что это дает в конечном итоге компании.

Infrastructure

Под инфраструктурой я подразумеваю всё, что окружает бизнесовый код и помогает ему от начала разработки фичи до момента ее доставки. Это и базы данных, и балансировка, и мониторинг, и CI с CD. Сюда же относятся особенности разработки/работы, библиотеки, тестирование, бизнес аналитика, бизнес-специфичные возможности и много чего еще. Это как завод, на котором вместо ручного труда автоматизированы все процессы, и результат мы получаем более быстрый и более качественный.:

При этом я рассматриваю инфраструктуру как единую платформу, а не набор разрозненных частей, которые я перечислил выше. И это уместно для компании любого размера. В облаках Amazon Web Services, Yandex Cloud автоматизация может строиться, например, на основе terraform. У вас может быть собственное железо или вы его где-то арендуете и на нем может быть развернут Kubernetes, Nomad, что-то еще. Команда тоже может быть любой от нескольких человек, которые в основном используют bash или terraform, и до сотен, со своими велосипедами.

И тогда возникает вопрос как добиться идеальной инфраструктуры Platform as a Service, который мы реализуем для наших пользователей, и вообще каковы критерии идеальности? Нам не нужно разрабатывать еще один Amazon или Kubernetes поэтому достаточно небольшой и простой системы, но у нас должна быть возможность ее расширения под наши use cases. Например, если у нас есть какие-то особенные АБ-тесты, особенные условия доставки (например, канареечный релиз ) и особенные правила безопасности это как раз то, что должна закрывать инфраструктура.

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

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

Infrastructure/Platform as a product (PaaP)

Сначала мы, конечно, смотрели в сторону сторонних приложений. Например, мы серьезно рассматривали Spinnaker от Netflix. Но он написан на Java, а у нас все пишут на Go, и мы не хотели добавлять еще один язык. Во-вторых, он не поддерживает Nomad и Yandex.Cloud. Следовательно, нам пришлось бы его прилично дорабатывать и интегрировать с нашими внутренними особенностями, что практически равно форку. Поэтому мы стали писать свое.

Изначально мы задумывали Shiva как абстракцию над деплоем (в нашем случае над Nomad) и как multicloud. Но сейчас она уже приросла различными системами и интегрируется со всем, что у нас внутри есть:

Основная ее часть представлена в GitHub в виде карты сервисов. Она изменяется посредством пул-реквестов, конфигурирует балансировку, контролирует деплой и различные пайплайны доставки, SOX, PCI DSS и т.д. То есть это одно описание для полноценной работы:

Архитектура Shiva в упрощенном виде выглядит так:

Сервис постоянно развивается и сейчас он уже частично похож на продуктовый: есть БД, вокруг которой построены различные микро-сервисы, есть небольшие legacy-компоненты (компонент Updater и Shiva смотрят в одну базу) и т.д. То есть с технической точки зрения он развивается как обычный бизнесовый сервис.

UI мы реализовали в Telegram, а впоследствии написали WEBовский. Telegram-бот это CLI over Telegram все команды задаются в формате CLI, но дополнены различными контекстными действиями, кнопками и т.д. Нам нравится этот подход, потому что он кросс-платформенный, его легко обновлять и к нему всегда есть доступ. Можно спокойно обновить или откатить свой сервис в случае проблем. А также очень удобный механизм нотификации, когда вы получаете уведомление о начале процесса деплоя прямо в тележку.

И хоть WEB и получился удобным, все равно часть пользователей остается в Telegram. Потому что UX меняется в профессию приходит очень много молодых разработчиков. Мы привыкли к WEB, мы привыкли использовать Telegram-боты и вообще общаться в чате. С другой стороны, мы хоть и думаем сделать CLI с такой же функциональностью, но понимаем, что запросов на это не было.

Экономика

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

Но у инфраструктуры нет доходов, тогда как на этой схеме есть и доходы, и расходы. Доход от инфраструктуры равен 0 это расход компании, а ROI будет отрицательным: сколько инвестиций не вкладывай, они не отбиваются:

Profit = Revenue - Cost = 0 - X

Есть, конечно, плюшки в виде, например, бесконечного LTV (LifeTime Value) то есть наши клиенты от нас никогда не уйдут. Но в целом эта метрика нам не подходила, и мы стали думать в сторону velocity (скорость разработки), потому что ее довольно легко преобразовать в деньги. Например, если мы ускорили разработку на час в неделю, то это нетрудно соотнести со средней зарплатой у 500 разработчиков и получить какой-то видимый профит. Вообще инфраструктура это именно velocity, то есть скорость доставки ценности пользователю. Но у нас это не глобальная метрика, потому что velocity зависит от очень многих факторов. : Если смотреть сверху, то можно выделить:

• code время написания самой логики ;

• infrastructure code время написания инфраструктурного кода (код логов, метрик, алертов и т.д.)

• environments время на настройку переменных окружения, секретов и т.д.;

• delivery время, затраченное на доставку.

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

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

Следующим нашим пунктом разработки инфраструктуры как продукта стало внедрение user story.

User story

User story это фундамент любой продуктовой разработки и используется он в любых гибких методологиях идущих от Agile. Это не детальное описание задач давайте прикрутим здесь кнопку, которая будет делать вот это. User story это намерение пользователя: какую проблему пользователь решал, как он пытался её решать, почему он её решал, почему она возникла, и, наконец, как мы можем её решить. Разумеется, из user story выводится очень много различных решений. Но сам User story не является им это основа для решения и инструмент для выявления исходной проблемы.

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

Приведу для примера две наши внутренние истории.

Пример 1. Залипает обработчик Кафки. Чинится только рестартом сервиса. Фикс в пути. Хочется иметь способ быстро перезапустить контейнеры.

Проблема была понятной и мы предложили сделать команду restart -l prod my_service, в которой указывается слой сервис, чтобы сервис рестартился через телеграм бота.

Пример 2. При обновлении конфигурации хочется перезапустить сервис без указания версии.

Решением стало: /run -l prod -v 1.0.7 my_service -> /run -l prod my_service.

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

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

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

Customer development (сustdev)

Инструмент сложный в продуктовой разработке, но в случае инфраструктуры он очень прост потому что мы разрабатываем новый продукт (фичу, решение или какую-то часть нашей системы) не сразу через код, а через пользователя. Можно даже провести ниндзя-сustdev, находясь в переговорке в ожидании какой-нибудь встречи или попивая кофеечек на кофе-поинт. Да и сам процесс не очень сложный:

1. Выявляем потенциальную проблему (строим гипотезу), формируем идею или решение, но не внедряем ее, а идем к пользователям, чтобы поговорить с ними об их потребностях/болях/проблемах.

2. Встречаемся с ними, например, на кофе-поинте или на рабочем месте. Можно пообщаться и в Зуме. И в обсуждении можно обнаружить, что проблема пользователям не важна она не так много времени занимает и не так сильно его напрягает, но зато у него есть более важные проблемы.

3. Прорабатывая решение вместе, мы получаем либо изначальное успешное решение (если определили проблему верно) или более успешное (поняв из общения, что волнует пользователей) то есть в выигрыше все.

Например, у нас не было истории деплоев, и мы понимали, что нам она нужна. Мы напридумывали очень много сложных вещей, вплоть до того, чтобы в Telegram с помощью пейджинга показывать список последних 10 сервисов и уже думали, как же их спейджить туда-обратно и т.д. Но пообщавшись с разработчиками, мы поняли, как история начинается у большинства из них: они видят на графиках аномалию и м нужно посмотреть, не было ли деплоя не новая ли версия принесла эту аномалию?

Эта история решилась довольно просто. Мы добавили время деплоя в аннотации на Grafana, и теперь видя какую-то аномалию, можно понять, не было ли деплоя, в том числе деплоя зависимых сервисов. Эта история, кстати, ускорила у нас создание WEB UI.

А потом мы пообщались с тимлидами и выяснили, что они это видят совсем по-другому:

Developer: Я вижу по графикам проблемы нужно проверить, не связано ли это с выкаткой новой версии (см. график выше).

Team leads: Нужна возможность посмотреть кто, что, когда и зачем катил в прод:

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

Портреты пользователей и сервисов

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

• Разработчики: бэкенд, фронтенд и инфраструктура;

• Team leads;

• Тестировщики/Автотестировщики;

• Аналитики;

• Менеджеры, продукты, руководители.

По сути частичное отражение рабочих позиций :)

А портреты сервисов можно классифицировать по типу, языку или размеру. Первые бывают внутренними (realtime api, back api, async, cron, gateway, и т.д.), DB, внешними, saas и т.д. И они богатая точка роста, потому что это место отказа каких-то инфраструктурных частей. Это и наша точка роста, которую мы рассматриваем в будущем для себя.

Языки разработки мы рассматриваем нечасто, но иногда приходится смотреть: почему эта история возникает, у кого она возникает, потому что, например, у java и node.js бывают небольшие различия в работе, и это приходится учитывать.

По размеру портреты сервисов могут быть: function, microservice, service, monolith, distributed monolith и т.д. И если мы, например, понимаем, что проблематика идет из распределенного монолита, то отказываем в этой истории, потому что у нас хорошей практикой считаются мироксервисы и нашим PaaS мы популяризируем и упрощаем жизнь именно с ними..

Вот для примера портрет сервиса БД. С помощью этой карты ставятся бэкапы, происходит доступ к БД на чтение/запись и т.д. Плюс, сам сервис в свои зависимости прочерчивает эту карту, и мы знаем, что это за карта и от чего она зависит то есть, мы знаем, что сервис А зависит от базы данных В:

Feature request

Но одно дело найти проблему. Совершенно другое когда приносят уже готовое решение. Это самая богатая тема, которую можно использовать себе на благо.

Конечно, у нас есть проблемы:

• Технически грамотный пользователь может принести уже готовое решение, например: Сделайте такой API, в БД все сохраните, и на этом хватит.

• Личное знакомство потому что иногда мы отказываем в feature request или говорим, что будем делать по-другому, и возникает небольшой конфликт.

Но есть и решения:

• Превращать в user story находить проблематику: узнавать, с какой проблемой столкнулся пользователь и как пытался решать;

• Смотреть на доработку в контексте портретов кто к нам пришел, что за сервис, о чем идет речь;

• Спорную доработку или ту, в которой мы не уверены, проверять через castdev, потому что все-таки feature request приносит один пользователь и непонятно, насколько это ценный функционал для всех;

• Механизм голосований/рейтинга это самый мощный инструмент. Он не нов, используется во всех хороших продуктовых разработках, например, в терминале Тинькофф-Инвестиции. У них открытые feature request, где люди открыто голосуют и в итоге в работу идут те, что в топе:

Внутри это также можно легко реализовать, потому что мы работаем в рамках одного issue-трекера. Например, здесь фильтры по нашим feature request:

Из интересного: мы недавно этот вид сделали через наш WEB не таким формальным и увидели, что люди с большей охотой голосуют за идеи то есть это тоже важно:

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

Roadmap

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

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

Кстати, как получать обратную связь?

• Тикеты и подписки на них. В нашем случае это самый рабочий инструмент, потому что мы работаем в одной компании, и в одном трекере.

• Большие посты анонсы. Несколько раз в квартал мы делаем большие анонсы, где рассказываем про всю большую функциональность и опять же получаем фидбэк. Иногда мы получаем негативные отзывы, например: Зачем вы это делаете, если можно взять вот это и то. Тогда мы либо объясняем, либо понимаем, что, может и правда можно реализовать более просто.

• У нас есть групповой чатик в Telegram/Slack/Microsoft Teams. В основном мы там собираем обратную связь, хотя он работает как инструмент технической поддержки, а также в нем выкатываем нововведения с небольшими инкрементальными релизами.

• Открытые встречи для вопросов/ответов. Мы пока что провели её только один раз, но результат был неплохой.

• Еще можно встречаться на демо продуктовой разработки и там отвечать на вопросы. Но мы не проводим демо сейчас для нас это большая потеря времени.

• Еще можно использовать индекс потребительской лояльности NPS (Net Promoter Score). Это простые анкеты: насколько вы удовлетворены нашим сервисом, насколько вам удобно базовые вопросы для того, чтобы собрать общую статистику лояльности пользователей. Мы не используем NPS, потому что из чата получаем и критику, и позитив, а остальных записываем как нейтральных пользователей.

MVP

После планирования хочу напомнить про инструмент MVP (Minimum Viable Product). Это известный подход, но в инфраструктуре есть нюансы. Мы, как любой бизнесовый продукт, выкатываем частично недоделанный продукт, где-то не самый удобный, но минимально рабочий. Потому что мы не можем делать 2-3 месяца какую-то историю, выкатить её, получить средний фидбэк и потом еще месяц переделывать:

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

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

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

Overkill

Важно понимать, когда продуктовый подход становится слишком сложным. Бизнесовые команды становятся настолько большими, что состоят из множества людей с разной направленностью и спецификой. Есть product owner, цель и задачи которого выстраивать roadmap и определять, какие из историй делаются. Есть product менеджер, UX-специалисты, разработчики, тестировщики и т.д. Когда большие истории разбиваются только по user story и пытаются делать с добавлением какой-то пользовательской ценности. Всё это очень круто, но сейчас для нашей команды это overkill. Как в принципе, и A/B-тестирование.

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

• Стараться понять: Зачем? То есть не Разработчик хочет 500 Тб БД, а: Разработчику нужно сохранять информацию о машинках (которую мы никогда не сохраняли) тогда мы сможем работать вместе над одной проблемой пользователя

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

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

• Обязательно нужен механизм голосования за идеи для того, чтобы упростить scoring задач.

• Собирать roadmap и сделать его открытым.

• Периодически собирать аналитику не сложные и большие графики, но чтобы плюс-минус понимать, что происходит у пользователей.

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

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

Итог

В заключении рекомендую книгу Психбольница в руках пациентов Алана Купера я ее прочитал очень давно и с огромным удовольствием, она меня вдохновила. Сейчас настало время, когда ее стоит рекомендовать не только product owner, продуктовым разработчикам, дизайнерам, но и команде инфраструктуры. Там очень много полезных примеров, в которых можно найти себя.

Подытоживая:

• Разговаривайте со своими пользователями, находите проблематику надо искать проблемы, а не решения.

• Относитесь к внутренней инфраструктуре как к единой платформе, как к единому PaaS.

• Разрабатывайте PaaS как полноценный внутренний продукт.

• Используйте проверенные простые продуктовые подходы, но только те, которые окажутся простыми. Если тот или иной подход (тот же сustdev или портреты пользователей) кажется сложным, возможно, сейчас их не стоит использовать.

• Повышайте ценность PaaS (скорость/расходы разработки/поддержки).

• Создавайте современные интерфейсы.

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

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

Профессиональная конференция DevOpsConf 2021 пройдёт 31 мая и 1 июня этого года в Москве, в отеле Radisson Slavyanskaya. Расписание уже сформировано. На сайте вы можете познакомиться с программой и спикерами.

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

До встречи в оффлайне!

Потому что государство это продукт. Со своими метриками, экономикой, жизненным циклом. У граждан-пользователей есть и лайфтайм, и отток, и средний чек. Да и цели те же: найти свою нишу на мировом рынке, решить боли пользователей, повысить выручку и капитализацию. Только вот чиновники, которые управляют нашими странами, угробили бы любой стартап примерно сразу.

Рыба с головы портится

Что, если проблема человечества не в перенаселении или глобальном потеплении? Не в бедности, неравенстве и даже не в культуре потребления? Вдруг это всё только следствия?

Думаю, единственная настоящая проблема человечества невероятно хреновый менеджмент.

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

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

Феномен стартапов

Интересно, что хреновость менеджмента распределена неравномерно.

Мы наблюдаем тотальную некомпетентность руководства многих государств, но потрясающий профессионализм в успешных IT-стартапах.

Вероятно, причина в том, что государства могут выживать, будучи неэффективными. При обилии природных ресурсов, например. Или если держать население в нищете. А лучше и то, и другое вместе.

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

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

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

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

Давайте порассуждаем, какие IT-методологии было бы классно внедрить в управление государством.

Приоритезированный бэклог

Я открываю новостной Telegram-канал и вижу новые законы, один интереснее другого:

• Депутаты переименовали улицы

• Депутаты запретили аниме

• Депутаты запретили критиковать власть

• Депутаты увеличили штрафы для водителей

• Депутаты запретили Telegram

То есть вместо системной работы над ключевыми метриками они пытаются лечить отдельные симптомы костылями да заплатками. Цитируя классику: What is going on inside their head?.

Кто-то скажет: Ну, это отдельные скоморохи всякую ерунду предлагают.

Нет.

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

А во-вторых, невозможно представить, чтобы в профессиональной среде кто-то всерьез такое предлагал. Его бы сразу поставили в тупик простейшими вопросами:

• Что будет считаться успехом и как ты измеришь результат?

• Как, по-твоему, это будет внедряться и контролироваться?

• Как это поможет решить ключевые проблемы государства?

Тот трэш, который мы наблюдаем, возможен только в среде насквозь некомпетентной.

Но, постойте, почему это кажется таким знакомым?

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

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

Поиск точки роста

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

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

Культура гипотез

Откуда берутся гипотезы в здоровом стартапе?

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

Но чиновники выше этой суеты они просто полагаются на чуйку!

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

Не нужны никакие догадки. Любой продакт вам скажет, как искать релевантные гипотезы. Хотите развивать малый бизнес? Идите к предпринимателям и проводите глубинные интервью. Хотите прокачать туризм? Анализируйте опыт стран, которые на этом собаку съели. Хотите понять, что не так с дорогами? Изучайте статистику ДТП на карте.

Риск-менеджмент

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

Конечно, это сложнее, чем раскатать сразу и на всех.

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

Выручает то, что большинство этих законов настолько плохо продуманы, что внедрить и проконтролировать их выполнение попросту невозможно.

Конечно, так быть не должно.

Не вижу ни одной причины, почему бы не обкатать закон сначала на маленькой аудитории или не устроить A/B-тест для оценки его влияния.

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

MVP

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

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

Аналитика и дашборды

Как понять какая партия приносит пользу государству, а какая ему вредит?

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

Какие инструменты стартапов могли бы тут помочь?

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

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

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

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

Human-centered design

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

Кхм, извините, в последнем вопросе во мне тоже проснулся депутат.

Что было бы со стартапом, который использует неудобный, некрасивый, устаревший дизайн? Вероятно, он потерял бы пользователей, которые ушли бы к конкуренту.

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

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

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

Бонус: пьеса Стыдоба. Или как чиновник продуктом управлял

Трагикомедия в 4-х действиях.

Действующие лица: продакт, чиновник, сисадмин, офис-менеджер, народные массы.

Действие первое

День до голосования на пост Chief Product Officer в крупном стартапе. Пасмурный опен-спейс с запотевшими окнами. Народные массы мнутся в нетерпении. Входит продакт с микрофоном.

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

(Голос из толпы). Ску-у-учно!

Слышится неодобрительный гул толпы.

(Другой голос). Почему печенье заканчивается в четверг, что нам делать в пятницу?

П р о д а к т (сконфуженно). Но Позвольте Ведь вовсе не о том

Н а р о д (в едином порыве). Прочь! Позор! Прочь!

Продакт, понурившись, спешно покидает помещение.

Действие второе

Место действия то же. Входит чиновник в дорогом костюме.

Ч и н о в н и к. Привет, народ! Я вас люблю!

Толпа одобрительно аплодирует.

Ч и н о в н и к (грозя кулаком куда-то в сторону). А этим всем мы покажем! Нечего тут! Ишь!

Слышится радостное улюлюканье из зала.

Ч и н о в н и к. Я так скажу. К черту метрики! На хрен аналитику! Мы должны поднять всем зарплаты! Вдвое!

Толпа восторженно рукоплещет.

Ч и н о в н и к. Вместе мы сделаем наш продукт великим! Снова!

Народ ликует.

О ф и с - м е н е д ж е р (кричит из толпы). Я хочу от тебя детей! Мой голос за тебя!

Действие третье

Серверная. Темно, холодно. Сисадмин пьет чай. Входит чиновник.

Ч и н о в н и к. Хочу победить на выборах. Подшамань мне голоса. Вот бабла тебе принес.

С и с а д м и н. Ок.

Действие четвертое

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

Ч и н о в н и к. Поувольнять, значица, оунеров энтих. Сестру туда поставлю и Димку своего.

Ненадолго прерывается, чтобы прожевать креветку.

Ч и н о в н и к. А еще неприкосновенность для руководства. И никакого контроля чтоб за расходованием средств. И обеспечить мне личного водителя, а то несолидно как-то...

Чешет пузо и переворачивается на другой бок. Шезлонг жалобно скрипит.

Ч и н о в н и к. Да! Про бездельников этих не забыть же. Увеличить штрафы за опоздания. И зарплаты порезать! А то ишь повадились!

Занавес

Короче, Склифосовский!

Ключевая мысль, которую я хочу донести, управление государством в нынешнем виде устарело. Модель, где сотни популистов перекрикивают друг друга, а потом голосуют это пережиток прошлого. Сегодня можно принимать обоснованные и взвешенные решения на основе кастдева и аналитики. И это не должны быть решения-законы. Это должны быть решения-гипотезы.

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

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

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

В современном мире всё большую популярность приобретает методика под названием customer development для тестирования идей и гипотез о будущем продукте. Методику придумал "крёстный отец Кремниевой долины" Стив Бланк.
Одним из числа сильных инструментов в "разработке клиентов" является интервью, когда вы можете побеседовать с респондентом. Однако им не всегда можно воспользоваться ввиду разных причин, которые условно можно свести к объёму бюджета и имеющемуся времени. Но во многих ситуациях можно воспользоваться опросом. Причём опросом, который можно автоматизировать за счёт применения чат-бота и нейронной сети для определения смысла слов, которые написал респондент в ответ на заданный вопрос.

В этой статье сконцентрируюсь на алгоритме работы чат-бот для проведения опроса. Как сделать чат-бота для VK писал в отдельной статье на Хабре. Использовал: Python, MySQL, API VK и готовую нейросеть от RusVectores.

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

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

• Нейросеть для понимания смысла текста, вводимого пользователем

• База данных для хранения вопросов интервью

• Описание алгоритма работы чат-бота

Нейросеть для понимания смысла текста, вводимого пользователем

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

В данном решении была использована готовая нейросеть от сервиса RusVectores, обученная на корпусе НКРЯ с использованием алгоритма word2vec CBOW с длиной вектора 300.

НКРЯ это совокупность русскоязычных текстов, Национальный Корпус Русского Языкав полном объёме. Содержит 270 миллионов слов, объём словаря 189 193 слова.

Word2vec CBOW алгоритм, благодаря которому слово на естественном языке представляется в виде числового вектора. Т.е. определяет координату слова в смысловом пространстве. CBOW это аббревиатура Continuous Bag of Words. Она обозначает алгоритм, который есть в word2vec. Данный алгоритм называют моделью мешка слов, он предсказывает слово по контексту. Ещё один алгоритм в word2vec - Skip-gram предсказывает контекст по слову.

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

Более подробно о word2vec можно почитать в статье "Немного про word2vec: полезная теория".

О векторном представлении слов (эмбеддинге) хорошо и с примерами описано в статье "Что такое эмбеддинги и как они помогают машинам понимать тексты".

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

Чтобы создать такой набор векторов почти для 200 000 слов и постоянно иметь к ним доступ, нужно располагать вычислительными мощностями. Т.к. у меня таких мощностей нет, я воспользовался доступным онлайн сервисом RusVectores.

База данных для хранения вопросов

Для проведения опроса я подготовил табличку с вопросами и разместил её в базе данных MySQL. Как видно из рисунка ниже, вопросы имеют ответвления, похожие на древовидную структуру или структуру графа.

В базе данных таблица с вопросами выглядит так (фрагмент):

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

Описание алгоритма работы чат-бота

Начало опроса

По договорённости с пользователем он заходит на страницу сообщества в ВК и инициирует диалог, нажав кнопку Сообщение.

Бот здоровается и спрашивает разрешения начать опрос. Текст приветствия задавал в разделе "Управление" "Сообщения" на странице сообщества в ВК.

Если пользователь ответил что-то близкое по смыслу со словом да, то бот начинает задавать вопросы. Как определить, что пользователь одобрил старт интервью? Для этого как раз нужна нейросеть, чтобы определить смысловую близость введённых пользователем слов к словам: да, можем, можно, начинай, ок. Для этого воспользуемся API сервиса RusVectores.

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

фрагменты кода из bot_methods.py
_{модуля, в котором реализованы все методы бота}

def _identify_phrase(user_id, user_message):    """    identify start question or greeting    return number of phrase in database    """    # identification variable, on start set "I don't know"    identi = 'I dont know'    # find in database current position in conversation between user and chatbot    identi = get_current_position_in_conversation(user_id)    if identi != 'err':        # if the conversation has just begun        if identi == '0':            # define greetings            similarity = _get_similarity(user_message, u'привет здравствуйте добрый')            if similarity > 0.5:                identi = "greetings"            else:                # define start interview or not                identi = _start_or_not(user_message)        # if the conversation continues        elif identi == '1':            # define start interview or not            identi = _start_or_not(user_message)        else:            pass                return identi

Вначале определим возможность начать опрос исходя из ответа пользователя с помощью метода _start_or_not():

def _start_or_not(user_message):    """    define <identi>: start or don't start interview    """    if user_message != 'старт' or user_message != 'Старт':        _identi = 'I dont know'        # define if user agree to start interview        start = _get_similarity(user_message, u'да можем можно начинай ок')        # define if user don't agree to start interview        later = _get_similarity(user_message, u'нет позже потом завтра')        if start > later and start > 0.15:            _identi = 'start'        elif later > start and later > 0.15:            _identi = 'later'    else:        _identi = "start"    return _identi

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

def _get_similarity(text1, text2):    """    Function return similarity between text1 and text2    text1 - user message    text2 - key words    """    text1.strip()  # delete empty space on start and end of string    text2.strip()    text1_words = text1.split(' ')    text2_words = text2.split(' ')    similarity = 0.0 # init variable    try:        for word1 in text1_words:            if word1 != '':                for word2 in text2_words:                    if word2 != '':                        # prepare url for request to API rusvectores.org                        # url example https://rusvectores.org/ruscorpora_upos_cbow_300_20_2019/дело__папка/api/similarity/                        url = '/'.join(['https://rusvectores.org/ruscorpora_upos_cbow_300_20_2019',                                         word1 + '__' + word2, 'api', 'similarity/'])                        # GET request to API rusvectores.org                        r = requests.get(url, stream=True)                        # sum similarity of couple of words                        similarity = similarity + float(r.text.split('\t')[0])    except Exception as e:        log_exception = str(e)    # average similarity    similarity = similarity/len(text2_words)    # return similarity between text1 and text2    return similarity

Переменная similarity содержит числовое обозначение смысловой близость фраз text1 и text2. Чем ближе similarity к 1, тем ближе фразы по смыслу.

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

фрагмент кода из mysqldb_methods.py
_{модуля, в котором реализованы все методы для работы с MySQL базой данных}

def get_current_position_in_conversation(user_id):    """    find in database current position in conversation between user and chatbot    using in bot_methods.py    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_num` FROM `conversations` WHERE `user_id`=%(user_id)s LIMIT 1"        cursor.execute(query, {'user_id': user_id})        result = cursor.fetchone()        if result is None:            identi = '0'        else:            identi = result[0]        conn.close()    except Exception as e:        identi = 'err'        return identi

Таким образом мы обрабатываем три сценария взаимодействия с чат-ботом:
- старт опроса (понимаем согласен пользователь начать опрос или нет с помощью функции _start_or_not()),
- обмен приветствиями, если пользователь поздоровался (понимаем по смысловой близости к словам приветствия с помощью функции _get_similarity());
- движение по структуре вопросов с помощью функции get_current_position_in_conversation() для определения текущего положения в структуре вопросов.

Давайте рассмотрим движение по структуре вопросов более подробно.

Стоп-слова

Одним из важных моментов является удаление "стоп-слов", т.е. слов, которые можно с лёгкостью удалить из предложения и при этом его смысл не потеряется. Вот набор стоп-слов, которые я использовал в данном проекте:

stop_words = [u'а',u'большой',u'бы',u'быть',u'в',u'весь',u'вот',u'всей',u'вы',u'говорить',u'год',u'для',u'до',u'еще',u'если',u'же',u'знать',u'и',u'из',u'или',u'к',u'как',u'который',u'мочь',u'мы',u'мне',u'на',u'наш',u'него',u'нее',u'них',u'но',u'о',u'один',u'она',u'они',u'оно',u'оный',u'от',u'ото',u'по',u'с',u'свой',u'себя',u'сказать',u'та',u'такой',u'такое',u'только',u'тот',u'ты',u'то',u'у',u'что',u'это',u'этот',u'я']stop_characters = [u'.',u',',u' - ',u'- ',u' -',u':',u';',u'?',u'',u'!',u'_',u'(',u')',u'=',u'+',u"#",u'$',u'@',u'%',u'*',u'   ',u'<',u'>','1','2','3','4','5','6','7','8','9','0']

С помощью метода _clear_text() очищаю предложение от стоп-слов:

Движение по структуре вопросов

Для определения в каком направлении опроса двигаться исходя из ответов респондента воспользуемся функцией _define_conversation_way():

def _define_conversation_way(user_message, identi):    """    define in which way we are goin to?    """    # all questions, unless  3 has two ways: 'yes' (positive) or 'no' (negative)    if identi != '3' and identi != '6':        yes = _get_similarity(user_message, u'да заказывал просить')        no = _get_similarity(user_message, u'нет никогда')    elif identi == '6':        # the question number 6 has different ways: 'delivery' or 'self-delivery'        yes = _get_similarity(user_message, u'заказываю доставку')        no = _get_similarity(user_message, u'еду сам ищу аналог')    elif identi == '3':        # the question number 3 has different ways: 'from store' or 'delivery'        yes = _get_similarity(user_message, u'магазин сам')        no = _get_similarity(user_message, u'доставка почта все перечисленное курьер дом')    if yes > no and yes > 0.15:        _way = 'yes'    elif no > yes and no > 0.15:        _way = 'no'    else:        _way = 'I dont know'    return _way

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

bot_methods.py
_{полный код модуля, в котором реализованы все методы бота}

# -*- coding: utf-8 -*-"""Bot methods.Realizes all what bot can do."3. Использование API сервиса RusVectores"https://github.com/akutuzov/webvectors/blob/master/preprocessing/rusvectores_tutorial.ipynb"""import re  # for work with regular expressionsimport requests  # for using HTTP requestsfrom bot_config import stop_wordsfrom bot_config import stop_charactersfrom mysqldb_methods import get_current_position_in_conversationfrom mysqldb_methods import get_question_from_DBfrom mysqldb_methods import write_current_question_number_for_userdef get_bot_answer(user_id, user_message):    """    using in views.py    make answer to user    """    answer = ''    # delete stop-words and punctuation characters in sentence    user_message = _clear_text(user_message)    # identify what to do: start or continue conversation    identi = _identify_phrase(user_id, user_message)    if identi == 'greetings':        answer = get_question_from_DB('1')        write_current_question_number_for_user(user_id, '1')    elif identi == 'start':        answer = get_question_from_DB('2')        write_current_question_number_for_user(user_id, '2')    elif identi == 'later':        answer = "Когда у вас будет возможность пройти интервью напишите мне 'старт'."    elif identi == 'I dont know':        answer = "Я не совсем вас понимаю...\nУточните, пожалуйста."    elif identi == 'end':        answer = "Спасибо за ваше участие в интервью!"    else:        # if top-level question: 1, 2 or 3 etc.        if len(identi) == 1:            # define in which way we are goin to?            way = _define_conversation_way(user_message, identi)            if way == 'yes' or way == 'no':                if way == 'yes':                    # going to positive way                    question_num = '.'.join([identi,'1','1'])                if way == 'no':                    # going to negative way                    question_num = '.'.join([identi,'2','1'])                answer = get_question_from_DB(question_num)                if answer != 'None':                    write_current_question_number_for_user(user_id, question_num)                else:                    question_num = str(int(identi) + 1)                    answer = get_question_from_DB(question_num)                    write_current_question_number_for_user(user_id, question_num)            else:                # if way='I dont know'                answer = "Я не совсем вас понимаю...\nУточните, пожалуйста."        else:            # if subquestion: e.g. identi=2.1.1 or 3.2.2 etc.            identi_numbers = identi.split('.')            next_num = str(int(identi_numbers[2]) + 1)            question_num = '.'.join([identi_numbers[0],identi_numbers[1],next_num])            answer = get_question_from_DB(question_num)            # if we get end of subquestions in this top-level-question            if answer == 'None':                # going to the next top-level question                question_num = str(int(identi_numbers[0]) + 1)                # checking that the question is the last                if _is_the_last_question(question_num):                    answer = get_question_from_DB(question_num)                    question_num = 'end'                else:                    # is not the last question                    answer = get_question_from_DB(question_num)                        write_current_question_number_for_user(user_id, question_num)            return answerdef _is_the_last_question(question_num):    """    define is the last question?    by the condition (len(identi) == 1) of the function "get_bot_answer"    question_num has lenght 1    """    is_the_last = True    question_num = str(int(question_num) + 1)    question = get_question_from_DB(question_num)    if question != 'None':        is_the_last = False    return is_the_lastdef _define_conversation_way(user_message, identi):    """    define in which way we are goin to?    """    # all questions, unless  3 has two ways: 'yes' (positive) or 'no' (negative)    if identi != '3' and identi != '6':        yes = _get_similarity(user_message, u'да заказывал просить')        no = _get_similarity(user_message, u'нет никогда')    elif identi == '6':        # the question number 6 has different ways: 'delivery' or 'self-delivery'        yes = _get_similarity(user_message, u'заказываю доставку')        no = _get_similarity(user_message, u'еду сам ищу аналог')    elif identi == '3':        # the question number 3 has different ways: 'from store' or 'delivery'        yes = _get_similarity(user_message, u'магазин сам')        no = _get_similarity(user_message, u'доставка почта все перечисленное курьер дом')    if yes > no and yes > 0.15:        _way = 'yes'    elif no > yes and no > 0.15:        _way = 'no'    else:        _way = 'I dont know'    return _waydef _identify_phrase(user_id, user_message):    """    identify start question or greeting    return number of phrase in database    """    # identification variable, on start set "I don't know"    identi = 'I dont know'    # find in database current position in conversation between user and chatbot    identi = get_current_position_in_conversation(user_id)    if identi != 'err':        # if the conversation has just begun        if identi == '0':            # define greetings            similarity = _get_similarity(user_message, u'привет здравствуйте добрый')            if similarity > 0.5:                identi = "greetings"            else:                # define start interview or not                identi = _start_or_not(user_message)        # if the conversation continues        elif identi == '1':            # define start interview or not            identi = _start_or_not(user_message)        else:            pass                return identidef _start_or_not(user_message):    """    define <identi>: start or don't start interview    """    if user_message != 'старт' or user_message != 'Старт':        _identi = 'I dont know'        # define if user agree to start interview        start = _get_similarity(user_message, u'да можем можно начинай ок')        # define if user don't agree to start interview        later = _get_similarity(user_message, u'нет позже потом завтра')        if start > later and start > 0.15:            _identi = 'start'        elif later > start and later > 0.15:            _identi = 'later'    else:        _identi = "start"    return _identidef _clear_text(sentence):    """    delete stop-words and punctuation characters in sentence    """    try:        # sentence to low-case        sentence = sentence.lower()        # delete stop-characters        for char in stop_characters:            sentence = sentence.replace(char, '')        # delete stop-words        words_of_sentence = sentence.split(' ')        result = ''        for word in words_of_sentence:            if word not in stop_words:                result = result + ' ' + word    except Exception as e:        result = str(e)    return resultdef _get_similarity(text1, text2):    """    Function return similarity between text1 and text2    :param text1: user message    :param text2: key words    """    text1.strip()  # delete empty space on start and end of string    text2.strip()    text1_words = text1.split(' ')    text2_words = text2.split(' ')    similarity = 0.0 # init variable    try:        for word1 in text1_words:            if word1 != '':                for word2 in text2_words:                    if word2 != '':                        # prepare url for request to API rusvectores.org                        # url example http://rusvectores.org/araneum_none_fasttextcbow_300_5_2018/дело__папка/api/similarity/                        url = '/'.join(['http://rusvectores.org/araneum_none_fasttextcbow_300_5_2018',                                         word1 + '__' + word2, 'api', 'similarity/'])                        # GET request to API rusvectores.org                        r = requests.get(url, stream=True)                        # sum similarity of couple of words                        similarity = similarity + float(r.text.split('\t')[0])    except Exception as e:        log_exception = str(e)    # average similarity    similarity = similarity/len(text2_words)    # return similarity between text1 and text2    return similarity

Как видно из кода, с помощью метода write_current_question_number_for_user() бот сохраняет в базу данных текущую позицию в диалоге с пользователем. Это необходимо для того, чтобы бот понимал какой следующий вопрос нужно задать респонденту.
Функция get_question_from_DB() возвращает текст вопроса из базы данных для того, чтобы бот задал его в чате.

Для удобства приведу полный код модуля с методами для работы с базой данных:

mysqldb_methods.py
_{полный код модуля, в котором реализованы все методы для работы с MySQL базой данных}

# -*- coding: utf-8 -*-"""Methods for work with MySQL database."""import MySQLdb  # before using it do in ssh: pip install mysqlclient""" import configuration variables for connect to MySQL database:"""from mysqldb_config import HOSTfrom mysqldb_config import USERfrom mysqldb_config import PASSWORDfrom mysqldb_config import DATABASEdef write_current_question_number_for_user(user_id, question_num):    """    write question number to database for this user    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        if question_num == '2':            query = (                "INSERT INTO `conversations`(`user_id`, `question_num`) "                "VALUES (%s, %s)"            )            data = (user_id, question_num)        else:            query = (                "UPDATE `conversations` "                "SET `question_num`=%s "                "WHERE `user_id`=%s "            )            data = (question_num, user_id)        cursor.execute(query,data)        conn.commit()  # commit transaction        conn.close()    except Exception as e:        exception = str(e)def get_current_position_in_conversation(user_id):    """    find in database current position in conversation between user and chatbot    using in bot_methods.py    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_num` FROM `conversations` WHERE `user_id`=%(user_id)s LIMIT 1"        cursor.execute(query, {'user_id': user_id})        result = cursor.fetchone()        if result is None:            identi = '0'        else:            identi = result[0]        conn.close()    except Exception as e:        identi = 'err'        return identidef get_question_from_DB(question_num):    """    return question text from database    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_text` FROM `questions` WHERE `question_num`=%(num)s LIMIT 1"        cursor.execute(query, {'num': question_num})        result = cursor.fetchone()        if result is not None:            question_text = result[0]        else:            question_text = "None"        conn.close()    except Exception as e:        question_text = str(e)        return question_text

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

скрипт views.py
_{"точка входа" для приёма сообщений пользователя и отправки ответов бота в чат}

# -*- coding: utf-8 -*-from __future__ import unicode_literalsimport jsonimport threading  # for async executing tasks with VK APIimport vk  # vk is library from VKfrom django.views.decorators.csrf import csrf_exemptfrom django.shortcuts import renderfrom django.http import HttpResponsefrom bot_config import *  # import token, confirmation_token and over constants from bot_config.pyfrom bot_methods import get_bot_answer@csrf_exempt  # exempt index() function from built-in Django protectiondef index(request):  # requested url    if (request.method == "POST"):        data = json.loads(request.body)  # take POST request from auto-generated variable <request.body> in json format        if (data['secret'] == secret_key):  # if json request contain secret key and it's equal my secret key            if (data['type'] == 'confirmation'):  # if VK server request confirmation                """                For confirmation my server (webhook) it must return                confirmation token, which issuing in administration web-panel                your public group in vk.com.                Using <content_type="text/plain"> in HttpResponse function allows you                response only plain text, without any format symbols.                Parameter <status=200> response to VK server as VK want.                """                # confirmation_token from bot_config.py                return HttpResponse(confirmation_token,                                     content_type="text/plain",                                     status=200)            if (data['type'] == 'message_new'):  # if VK server send a message                # t - is new thread to async execute answer_to_message()                t = threading.Thread(target=_answer_to_message, args=(data,))                t.start()                return HttpResponse('ok', content_type="text/plain", status=200)    else:        return HttpResponse('see you :)')# send anser to user messagedef _answer_to_message(data):    session = vk.Session()    api = vk.API(session, v=5.5)    user_id = data['object']['user_id']    user_message = data['object']['body']    # get bot answer    answer = get_bot_answer(user_id, user_message)    # token from bot_config.py    api.messages.send(access_token = token, user_id = str(user_id), message = answer)

О том как устроена структура файлов приложения, его настройка описывал в подробностях в отдельной статье на Хабре.

Успехов!

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

Всем мы знаем, что пользователи делятся на группы в соответствии с пользовательскими метриками и долей рынка продукта (АВСDX-сегментация). И это деление говорит нам: делайте все в продукте для A, максимум, B-сегмента - для самых платящих и лояльных клиентов. И не обращайте особого внимание на не сводящих экономику продукта жалующихся и мало платящих сегментов С и D.

Сегодня, в преддверии старта курса "Product Manager IT-проектов" совместно с Сергеем Колосковым, преподавателем Otus и автором канала Fresh Product manager мы написали пост, как найти платящий сегмент для трех разных кейсов.

Если есть метрики / аналитика по продукту

1. Анализ Частотность - Деньги - Дата последнего действия (RFM - анализ по классике): таблица из баллов по показателям Recency давность (как давно ваши клиенты что-то у вас покупали), Frequency частота (как часто они у вас покупают), Monetary деньги (общая сумма покупок). Зная эти три метрики в общем виде, находятся лидеры по сумме, они и становятся для нас выявленным платящим сегментом. Например,

R - Recency:

1. 0-30 дней: 5,100 покупателей/подписчиков

2. 31-60 дней: 12,300

3. 61-90 дней: 32,800

4. 91-180 дней: 75,000

5. 181-365 дней: 123,400

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

F - Frequency:

1. 16+ покупок/действий

2. 11-15

3. 5-11

4. 2-4

5. 0-1

M = Monetary

1. $1001+

2. $601-1000

3. $351-600

4. $201-350

5. $0-200

Таким образом, мы получим без малого 125 групп. Клиенты 5R-5F-1M могли обратиться к вашим услугам лишь разово, потратив немалую сумму, но не рассчитывая на долговременное сотрудничество. А вот 5R-3F-1M с большей вероятностью стали недовольны услугами компании или потеряли к ней интерес. 1R-1F-1M сливки вашего клиентского списка. Если вы верно избрали пределы групп R, F и M, то этот сегмент должен быть крайне мал не более 5% адресной базы. Что бы вы ни делали, вам уже вряд ли удастся испортить отношения с такими клиентами.

2. Проблемно-решенческие интервью (как часть CustDev) с целью выявления общих паттернов и характеристик среди платящих (от 8 проблемных интервью на предполагаемый сегмент с проверкой гипотез) - проводим проблемно-решенческое интервью с целью выявления связи между гипотезой и сегментом. Сегмент может оказаться не один, необработанные сегменты можно взять из полного или упрощенного (по нескольким показателям) RFM - анализа. Идеально, когда CustDev дополняет RFM - анализ и наоборот. О том, как правильно проводить кастдевы, какие вопросы и как задавать в обзоре от канала Fresh Product manager.

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

Если нет метрик и аналитики по продукту

1. Упрощенный RFM-анализ (по выручке, по среднему чеку) - собирается из того, что можно собрать из бек-энда продукта или опросов по возможным показателям. Иногда их достаточно для выявления сегментов. То есть, самая простая выгрузка из базы и логов.

2. Сегментированные опросы - сбор ответов на вопросы внутри продукта, которые выявляют паттерны поведения. Возможны настройки вопросов для пользователей с определенным поведением. Опросы лучше использовать именно с точки зрения проверки количества сценариев: вопрос - это формулировка проблемы, ответы - варианты решений. Эти цифры можно использовать для показателя Охват в фреймворке приоритизации гипотез (например, RICE). Те сценарии, что набрали мало ответов, с точки зрения продукта не нужны.

3. CustDev с целью выявления инсайтов для построения аналитики. И, конечно, проведение проблемно-решенческих интервью, в которых будут результаты упрощенного RFM - анализа или опросов. Цель все та же - нужно выявить посредством открытых вопросов схожие паттерны поведения и объединяющие факторы. В тему - отличный блог Синди Альварес, автора книги Продукт, который купят и канал с моими заметками про CustDev

Если нет продукта и аналитики

1. CustDev с целью формирования сегментов и проверки гипотез (От 40 проблемных интервью). Когда нет никаких зацепок и аналитики, собираются гипотезы как для продуктов, так и для сегментов - активных пользователей продуктов. Гипотезы самые смелые, проверка самая приключенческая.

2. Информационные способы привлечения клиентов (выставки, вебинары, статьи, рассылка). Здесь скорее про минимально необходимые рабочие продукты без привлечения кода (MVP), когда непонятно, для кого продукт. Разного рода инфоповоды могут стать привлечением самого полезного сегмента, важно, со всеми познакомиться и узнать, что между представителями общего.

3. Проверка поисковых запросов в Яндексе/Google (Wordstat и прочие) как мониторинг монетизации и необходимости продукта по семантике, проверка наличия целевой аудитории посредством проверки пула запросов в поисковиках. Важно копать именно узкие целевые запросы. Например репетиторы по математике покажет популярность для сегментов ОГЭ/9 класс, городов и пересечение с другими предметами.

На этом всё. Приглашаем вас посетить бесплатный демо-урок по теме: CJM (customer journey map): от гипотез до продуктового сценария

Читать ещё:

• No-code: продакты против больших трат денег