Или очередная история про белое и серое.

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

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

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

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

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

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

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

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

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

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

Этот пост — выжимка из моей беседы с Даниилом Пилипенко, создателем компании SymbioWay, занимающейся подбором и оценкой IT-специалистов для сторонних компаний и предоставляющей услуги аутстаффинга.

Даниил — профессиональный разработчик с 18-летним стажем. Начал свой путь с младшего программиста на Java. Через шесть лет стал руководителем отдела разработки, изучил PHP и JavaScript. В данный момент, кроме работы по подбору персонала, проводит карьерные консультации, выступает в качестве спикера на конференциях и вебинарах, преподает флагманский курс по Java в Skillbox. 

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

IT-рынок: какие изменения произошли, оценка текущей ситуации и ожидания в будущем

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

Весной 2020 года наблюдался «пандемийный спад», а затем резкий рост рынка с лета 2020 года по конец 2021-го. В декабре 2021-го спрос на разработчиков вырос почти в три раза, и количество вакансий в пике приблизилось к 86 тыс. по сравнению с примерно 32 тыс. в конце марта 2020 года.

Любые кризисы приводят к тому, что экономические пузыри лопаются. Ровно это и произошло со спросом на разработчиков этой весной. Отмечу, что это общемировой тренд и такая картинка наблюдается не только в России. В итоге количество вакансий вернулось к тому, каким бы оно было, если бы рост происходил обычным «допандемийным» темпом. Это хорошо видно на графике выше.

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

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

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

Что касается самих разработчиков, пожалуй, февраль 2022 года был самым напряженным и переломным моментом для них. Как мы знаем, после февраля (и затем в сентябре) из страны уехало большое количество IT-специалистов. Однако, по нашим данным, около 50% из них продолжают работать на российские компании. Ну и сейчас, в ноябре, некоторые специалисты по разным причинам снова начинают возвращаться из-за рубежа.

Реально ли сейчас начать карьеру и устроиться на позицию junior-разработчика?

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

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

Во-вторых, такие инструменты, как Tilda, имеют довольно ограниченный функционал: с его помощью мы можем легко сделать пару страничек, но какой-нибудь серьeзный продукт вроде «Яндекс Маркета» на нем не напишешь. Да и в будущем вряд ли кому-то удастся создать универсальную систему, которая будет писать любую другую систему без участия человека.

В-третьих, учитывая текущие реалии и массовый отъезд программистов уровня middle и senior, компаниям ничего не остается, как нанимать junior-разработчиков. Например, junior-разработчики, которых сейчас воспитывают в том же Skillbox, при грамотно составленном резюме, имея определенную базу и навыки, находят себе работу в течение месяца после окончания курса. Этот факт доказывает, что спрос на джунов по-прежнему высок.

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

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

С чего начать

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

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

Третий — найти работу применение своим знаниям и навыкам. Чтобы поддерживать и расширять экспертность в любом деле, необходимо постоянно практиковаться. Для этого недостаточно придумывать себе задачи «на покодить» или учиться на курсах. Важно как можно быстрее перейти на профессиональный уровень и найти вариант, где вы каждый день занимаетесь разработкой.

Что не рекомендуется делать на старте карьеры

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

Минимальный арсенал junior-разработчика

• знание синтаксиса языка;

• понимание принципов объектно-ориентированного программирования;

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

• знание языка запросов SQL (для backend-разработки);

• понимание принципов клиент-серверного взаимодействия, базовое знание протокола HTTP и стандарта REST;

• опыт работы с Git и командной строкой; 

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

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

В сфере программирования есть несколько ветвей. Первая, веб-разработка, — самое обширное направление во всем мире (по разным оценкам, более 50% всего программного обеспечения в мире — это именно веб-приложения). Веб-разработка подразделяется на направления frontend- и backend-разработки.

Вторая крупная ветвь — мобильная разработка. Другие ветви — разработка десктопных приложений, игр, встроенного и системного программного обеспечения, разработка для Data Science и другое.

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

Если же желания работать с визуальной частью нет, а хочется, наоборот, знать и понимать, как устроена серверная часть веб-приложений, как она взаимодействует с frontend’ом и с мобильными приложениями, то стоит рассмотреть для себя backend-разработку.

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

Как выбрать язык программирования

Выбор языка существенно зависит от того, какое направление в программировании вы выберете.

Возьмем, к примеру, веб-приложения и frontend-разработку. В этом примере выбор языка очевиден — это JavaScript и в качестве дополнения TypeScript.

Если же мы рассмотрим топ языков для backend-разработки, то увидим, что треть всех вакансий в РФ и, соответственно, первое место в топе уже многие годы принадлежит языку Java.

Второе место в топе и примерно 15% всех программистских вакансий отдано Python. В этом году чуть сдал свои позиции и занимает третье место язык PHP. Четвертое почетное место в топе у языка Go. И, кажется, он скоро сможет пробиться выше. Вот эта первая четверка языков закрывают около 75% рынка. А далее, на пятом месте? идет C#. Его доля на сегодняшний день около 10%. Спрос на С# с каждым годом снижается.

Теперь попробуем сравнить языки backend-разработки между собой. К примеру, Go и PHP — языки программирования, применяющиеся в основном для создания веб-сайтов и веб-приложений. Напротив, Java и Python — более универсальные языки, на них пишут практически всё, и выбор одного из них в качестве своего первого языка выглядит очень логично.

Если задаться вопросом, насколько каждый из них подходит для enterprise-разработки, то Java будет являться несомненным лидером. Все банковские и платежные системы, Госуслуги, «Яндекс Маркет», «Яндекс Музыка» в значительной мере написаны на Java. 

Вторым критерием для сравнения Java и Python является порог вхождения. И тут уже побеждает Python.

Давайте посмотрим, как выглядит вывод в консоль традиционного «Hello, world!» на двух языках.

Действительно, на первых этапах Python кажется проще для изучения (пример кода нам это доказывает), но, изучив Java, в дальнейшем можно легко переходить практически на любой другой язык: Kotlin, PHP, С# и тот же Python. Если же вначале изучить Python, то с него «прыгнуть» куда-то еще будет немного сложнее.

Третий критерий сравнения — спрос. Если мы посмотрим рынок РФ, то спрос на Java практически в два раза превышает спрос на Python. Если же посмотреть на мировой рынок, то все будет наоборот — Python сегодня в мировых лидерах. Например, такую активно развивающуюся сферу, как Data Science, язык Python оккупировал более чем на 90%.

Стоит сказать про языки Kotlin и Swift, которые практически полностью заняли собой мобильную разработку на Android и iOS.

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

Самым правильным вариантом для старта карьеры является «начать пробовать» и, собственно, начать писать код. И не очень важно, на каком именно языке. Главное — начать.

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

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

Есть еще одна важная рекомендация: если вы хотите стать программистом, не стоит идти «в обход» — например через верстку, тестирование или DevOps. Есть риск потерять много времени, занимаясь нелюбимым делом. Даже если вход в разработку видится вам сложным, не стоит искать другие пути. Все трудности будут вам по плечу, если у вас будет интерес. И тяжeлый вход в самое желанное направление будет гораздо эффективнее с точки зрения затрат времени и ресурсов, чем любой «обходной путь».

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

Чтобы стать профессионалом, нужно получить опыт и преодолеть как можно больше трудностей.

С чего начать изучение языка программирования 

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

Итогом обучения должна стать в идеале разработка какого-то пусть и небольшого, но полезного проекта. Например, в Skillbox на курсе по Java мы предлагаем по итогам обучения разработать поисковый движок. На подобных задачах можно полноценно ощутить, что такое создание систем с нуля на MVC-фреймворке, закрепить навыки работы с базой данных и языком запросов SQL, попробовать работу с файлами, научиться получать и обрабатывать HTTP-запросы и формировать HTTP-ответы в соответствии со стандартом REST. Без этих базовых знаний об успешном трудоустройстве можно даже не мечтать. Мало знать только синтаксис языка и уметь писать голый код, нужно понимать, как написать код так, чтобы получилась рабочая система или мало-мальски готовый продукт.

Можно ли научиться программировать на курсах?

Курсы и школы бывают разные. Есть школы, у которых все курсы хорошие, а есть школы, где можно выделить только пару достойных курсов. Любой курс разрабатывает специалист (или команда специалистов), поэтому его успех зависит от методики и профессионализма этого конкретного специалиста или команды. 

Можно попробовать отыскать для себя хороший курс по программированию по следующем критериям:

• продолжительность курса от шести месяцев и больше; 

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

• в программе курса есть много тем, пересекающихся с требованиями в вакансиях по данной специальности;

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

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

К сожалению, все чаще можно наблюдать проблему с трудоустройством у выпускников курсов по программированию, которые не доучились или обучались на слабом курсе. Был тут интересный случай: однажды, ко мне на карьерную консультацию пришел мужчина 57 лет, который окончил курс по frontend-разработке и не мог устроиться на работу. Он был уверен, что вся его проблема кроется в возрасте. Но на консультации выяснилось, что он не может написать ни одной строчки кода и просто-напросто не имел практики, изучив только термины и теорию. Поэтому совет для него звучал так: сначала нужно изучить основы (я дал ему конкретный перечень, что и где можно быстро и бесплатно изучить), разместить резюме, устроиться на работу и только потом уже вспоминать, сколько ему лет. Кстати, карьера этого человека сложилась отлично: сначала он устроился на работу верстальщиком и в течение года вырос до младшего frontend-разработчика.

Правильный курс может стать отличной базой для старта карьеры. Остается только вопрос мотивации и интереса самого человека. Если человек занимается чем-то вовлеченно, то он постоянно думает о своем деле и непрерывно практикуется, например на pet-проекте. Комбинация из курса и вовлеченности в дело помогает ему найти работу и стать настоящим профессионалом.

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

Hard и soft skills на старте карьеры: что важнее

С учетом сегодняшнего дефицита программистов на рынке, hard skills на старте более весомы. Важно хорошо уметь писать код, решать задачи. Существует мнение, что в первую очередь человек должен быть разумный, а дальше он всему научится. Моe персональное мнение состоит в том, что soft skills можно прокачать в процессе работы. А вот то, насколько человек технически подкован, на старте карьеры очень важно, и обучать его основам программирования не всегда есть ресурсы.

На рынке мнение о том, что важнее — hard или soft skills, разделяется ровно пополам. На нескольких своих последних выступлениях я проводил опрос, и эта статистика подтверждается: примерно половине руководителей важнее soft skills, а другой половине — hard skills.

Чем junior, middle и senior отличаются друг от друга?

На эту тему есть две шутки. Первая: junior еще не может работать самостоятельно, а senior — уже не может. Вторая: junior приходит к своему руководителю с вопросами, а middle — с ответами. Выводы из этих шуток следующие: основное, что отличает программистов разных грейдов друг от друга, это уровень их самостоятельности. Безусловно, уровень самостоятельности — это комплексный показатель, отражающий одновременно и hard skills, и soft skills.

Тестирование кода: важный навык хорошего разработчика

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

Методика выявления настоящего профессионала в программировании

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

Идеальное собеседование — это один рабочий день, когда мы просто сажаем человека на текущие задачи и в конце дня смотрим, как он с ними справился. Но обычно такой возможности нет, и тогда на собеседовании мы устраиваем live coding, по которому становится понятны опыт, грейд, наличие или отсутствие интереса и образ мышления соискателя.

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

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

Итоги

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

Привет, Хабр!

На связи VS Robotics. Мы по–прежнему занимаемся машинным обучением и автоматизацией решений на базе речевых технологий.

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

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

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

Для чего нам потребовался АI-генератор скриптов

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

Но так или иначе, вся работа робота описывается скриптом, то есть определенным сценарием действий.

Ниже на рисунке 1 мы изобразили, как выглядит часть скрипта робота. Слева пример алгоритма работы робота в виде блок-схемы (пошаговой инструкции), а справа сценарий в виде кода.

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

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

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

Общая схема работы AI-генератора

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

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

Транскрипции проходят 6 этапов прежде чем превратиться в скрипт и отправиться на финальную доработку в визуальный редактор (другой продукт компании).

Архитектуру решения схематично можно представить так.

MVP AI-генератора скриптов оформлен как Python веб-приложение, упакованное в контейнер, который развернут в kubernetes. Теперь подробнее расскажем, что происходит на каждом шаге.

Этапы 1-2: составление лога и очистка фраз

На первом шаге мы объединяем все тексты диалогов в формате «оператор» — «абонент» в одну большую таблицу – общий лог. Каждому диалогу присваивается id, а реплики внутри каждого диалога упорядочиваются по хронологии. Каждая строка в общем логе содержит в себе id диалога, сторону диалога, фразу и время высказывания.

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

В качестве второго этапа мы очищаем фразы от слов и фраз — «паразитов», таких как: «имею в виду», «проще говоря», «типа» и т.д. Предложения, избавленные от этих конструкций, удается более точно отделять друг от друга на этапе 4 – «Кластеризация».

Этап 3: векторизация

Здесь мы векторизуем, то есть превращаем текстовые фразы в числовой вид – векторы. Делаем это при помощи предобученной модели language-agnostic BERT. Мы используем урезанную версию модели — Подаем модели на вход по очереди фразы из общего лога, а на выходе получаем 768-мерный вектор (CLS-эмбеддинг), отражающий смысл целого предложения. В текущей версии AI-генератора мы используем именно модель LaBSE, так как полученные от нее векторы давали лучшие для нас результаты на последующих этапах.

Этап 4: кластеризация

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

Затем мы непосредственно проводим кластеризацию, то есть группировку похожих по смыслу фраз при помощи реализации алгоритма community detection из библиотеки sentence_transformers.

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

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

Этап 5: Process Mining

Пятый этап – Process Mining – или исследование процессов. На этом этапе наша задача отыскать генерализованную структуру диалога на основе различных вариантов этих диалогов из лога оператора.

Мы рассматриваем диалог как процесс. Это последовательность размеченных высказываний оператора (или этапов). Для формирования генерализованной структуры мы отбираем только наиболее частотные и строгие последовательности высказываний, применяя алгоритм heuristic miner.

На выходе получаем визуальное представление диалога как процесса – граф реплик оператора. И в данном примере мы видим, что в логе есть последовательность AD, но в итоговую схему она не попала как редкая.

Успешность визуального представления мы измеряем четырьмя метриками.

Интересно, что совершить переход от кластеризации к Process Mining нам удалось благодаря совету, полученному в NLP-коммьюнити. Обсуждая задачу в одном из профессиональных сообществ, мы получили рекомендацию. Высказанное предположение у нас получилось реализовать.

Этап 6: Создание заготовки скрипта

На следующем этапе мы превращаем визуальное представление процесса диалога в заготовку скрипта.

Скрипт робота-оператора – это главным образом, последовательность состояний произнесения (speech_state) и слушания (listening_state).

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

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

Результат работы

На этапе MVP, мы примерно оценили КПД от нашего AI-генератора скриптов.  Здесь должна звучать барабанная дробь…Нам удалось сократить время разработки скрипта в 12 (!) раз.

Мы продолжаем работать над AI-генератором скриптов. Например, создаем интерфейсы для работы в нем. Но основная задача — автоматизировать «дообучение робота». Мы хотим, чтобы модель самостоятельно анализировала базу звонков, совершенных по созданным скриптам, и совершенствовалась.

Но это будет уже совсем другая история…

Всем привет! Мы команда Dev’s Battle. В этом посте расскажем о том, как мы создавали для нашего продукта (MMO RPG игра в телеграм) собственную систему аналитики

Зачем проекту аналитика?

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

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

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

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

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

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

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

Для системы аналитики мы выбрали Grafana . Данное решение возможно будет победнее, чем дашборды в Tableau, но зато полностью бесплатное, супер гибкое и кастомное (с помощью запросов PostgreSQL и небольших скиллов в визуализации можно сделать очень приемлемые дашборды).

Cтек для аналитики: Grafana, PostgreSQL, Docker

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

Как создавали систему дашбордов?

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

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

Система дашбордов 2.0 (скрины далее)

1. Main stats — сюда мы вынесли основные для нас метрики: количество активных игроков, DAU, WAU, Retention, Рефферальные ссылки и воронку онбординга с конверсиями по этапам

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

3. Marketing&Sales — третий дашборд вобрал в себя данные по маркетингу, статистике переходов, продаж и конверсий. Его мы еще дорабатываем по мере развития монетизации продукта.

Какие показателя для нас самые важные?

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

Кстати если эту статью все таки читают продукты, проджекты и бизнес аналитики, поделитесь своими идеями, что нужно добавить или вынести из этого списка? (Будем супер благодарны, да и надеемся, что аудитория VC это оценит)

Итак, наша заветная семерка:

1-Day Retention. Процент вернувшихся пользователей — ключевой показатель работоспособности мобильных игр. Retention rate в принципе один из фундаментальных показателей в управлении продуктом.

1-Day Retention показывает процент пользователей, которые возвращаются в нашу игру на следующий день после первого запуска. Так, например, если удержание на второй день составляет 50 %, это означает, что 50 % новых пользователей зашли в игру на второй день.

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

N-Day Retention. Процент вернувшихся пользователей в зависимости от количества дней. Мы считаем для 1, 3, 7, 14 и 28 дня. Отображаемый в виде воронки данный показатель отлично показывает в какой момент пользователю становится скучно.

В нашей случае, показатель удержания снижается от 46% на 1 день до 15% через 28 дней игры, что уже является неплохим показателям для старта, хоть работать конечно есть над чем!

DAU/WAU. Метрики пользовательской активности за определённый период: за день (daily active users — DAU), за неделю (weekly active users — WAU). Эти метрики показывают нам число уникальных игроков, которые в течение конкретного временного промежутка хотя бы раз проявили активность в нашей игре.

Как правило, эти метрики используют разработчики мобильных приложений. Для них это своеобразная мера успешности продукта. На основе DAU/WAU/MAU определяют степень «привязанности» к приложению и планируют стратегию дальнейшего продвижения.

Onbording Funnel (воронка онбординга). Это не совсем метрика, скорее набор конверсий между этапами в процессе онбординга нового пользователя. Тем не менее, для нас данный показатель оказался крайне ценным.

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

Кстати благодаря этой воронке мы увидели, что теряем 60% пользователей на обучении и внеся пару простых правок сумели понизить показатель до 27%

Wealth distribution — показывает нам распределение игровой валюты между игроками. Очень занятная метрика, которая говорит о балансе в игре или об его отсутствии. Распределение мы смотрим по персентилям игроков — % денег который принадлежит топ 1%, 5%, 10% и 20% игрокам.

Кстати сейчас, 1% богатейших игроков принадлежит 26% всех денег. Наверно, это не очень хорошо, но зато цифра очень близка к реальному миру (фан факт 1% жителей США владеют 32% всего богатства в стране. Так что у нас тут симулятор рыночной экономик развивается ))

Conversions / Payments по когортам — классические показатели монетизации. Считаем, как % от новых пользователей за неделю, которые воспользовались платными функциями игры.

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

REF Count — наша кастомная метрика, которая позволяет отслеживать работу рефферальной системы. Наша игра бесплатная (Freemium) и мы делаем большую ставку на виральность и шеринг, а с помощью UTM-меток можем отслеживать работоспособность всей этой системы.

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

Это не все метрики, что мы собираем, но сейчас для развития проекта считаем перечисленные наиболее значимыми.

Как аналитика помогает нам сегодня?

Мы наконец-то перешли от хаотичных тестов и движения по наитию к реальным продуктовым гипотезам и решениям на основе данных. Конечно, не все фишки мы успели реализовать (например, все еще ленимся наладить нормальную систему А/Б тестов), но практика управления проектом уже выросла до новых высот.

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

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

А главное, этот продукт работает! И уже помогает сотням начинающих разработчиков развивать свои hard skills в программировании.

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

Уже больше полгода назад крупнейшие BI вендоры прекратили работу в России. Мы в компании Vizuators, имея многолетний опыт разработки и консалтинга в Tableau, столкнулись с необходимостью тестировать альтернативные инструменты, которые подошли бы нашим клиентам. 

Одним из наиболее привлекательных для нас вариантов стала платформа визуальной аналитики Дельта BI. Под катом мы говорим о том, что получит и потеряет «таблошник», перейдя на Дельта BI.

Общие впечатления от тестирования Дельта BI

При всем скепсисе к любым альтернативам Tableau в Дельта BI нам удалось воспроизвести >95% функционала. Продукт позволяет создавать модели данных, настраивать ETL процессы, не ограничивать себя в выборе визуализаций. Удобно делиться результатами работы с коллегами. 

Приятным сюрпризом стало то, что инструмент близок к новому поколению BI — Augmented analytics (расширенная аналитика). Это подход к анализу данных, который использует машинное обучение и обработку естественного языка для автоматизации процессов анализа, обычно выполняемых специалистом.

Особенности Дельта BI от общего к частному

Мы не стремились сравнить два инструмента напрямую — у каждой компании свои критерии оценки. Сначала опишем показавшиеся нам фундаментальными отличия Дельта BI от Tableau. Затем сосредоточимся на различиях в возможностях лицензий. Итак, что же приобретут и потеряют пользователь и разработчик при переходе с Tableau на Дельта BI.

Весь цикл работы с данными в одном инструменте. Вместо нескольких инструментов — TS, Tableau Prep и самого Tableau Desktop — в Дельта BI работа с данными на всех этапах ведется в едином веб-интерфейсе. Этапы работы распределены по внутренним блок-модулям. Это создание модели данных, построение расчетов, визуализация, сборка дашбордов, настройка публикации и создание динамических иллюстраций.

Интерфейс НЕ схож с Tableau. В каких-то областях он скорее напоминает продукты Microsoft. Но остаются узнаваемы панель с мерами, измерениями и рабочая область для построение визуализации. А вот области для настройки дизайна устроены схоже с Excel (выбор шрифта) и PowerPoint (выбор темы «презентации»).

Встроенные моделирование и ETL. Физический и логический уровни моделирования в Tableau и Дельта BI похожи. При этом на физическом уровне мы подготавливаем и обрабатываем данные в самом инструменте, не пользуясь аналогами Tableau Prep. 

Другая логика создания вычислений. В Дельта BI вычисления создаются тремя способами: прямо на графике; через функционал drag-and-drop; через ручной ввод формул. В синтаксисе есть сходства и с Tableau, и с Power BI.

Иной подход к визуализациям. Вместо их гибкой настройки в Tableau Дельта BI предлагает работать с 56 визуализациями «из коробки».

Лицензии Дельта BI — Creator и Viewer 

В Дельта BI есть только 2 варианта лицензий — для тех, кто пользуется дашбордами (Viewer), и для тех, кто их создает (Creator). Начнем с первых. 

Возможности лицензии Viewer в Дельта BI

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

2 варианта редактирования визуализации «на лету». Непосредственно на дашборде можно менять не только тип визуализации, но и менять один разрез данных на другой (например, категорию на подкатегорию). Второй вариант — редактирование с помощью опции Анализ дальше. Этот функционал может снять нагрузку на отдел разработки и порадует тех бизнес-пользователей, которым хочется больше самостоятельности.

Есть функционал исследования данных. Он позволяет получить первые аналитические выводы без разработки каких-либо визуализаций. Например, увидеть, какая категория товаров (или регион) «делает» основную часть продаж. Какой из разрезов внес наибольший вклад в результаты продаж.

Drill-down деревья — еще один способ исследовать данные в Дельта BI без разработки дашборда. Он в какой-то мере повторяет предыдущий, но в другом представлении. С ним мы можем увидеть долю самого «влиятельного» сегмента в разных разрезах данных.

Возможность сделать Zoom in для изучения узкого среза данных. Например, когда на линейном графике отображена динамика показателей за несколько лет, мы можем детально рассмотреть небольшой период времени, в который заметили аномалию. Функционал также доступен лицензии Viewer «из коробки» и не требует специальных настроек со стороны разработчика.

Сильный функционал фильтрации. В отличие от Tableau пользователь в Дельта BI имеет в распоряжении иерархические и календарные фильтры «из коробки».

Иначе реализованы всплывающие подсказки (тултипы). Если в Tableau в тултип можно встраивать визуализации, в Дельта BI этого сделать не получится. Во всплывающую подсказку здесь можно добавить только меры. Это может стать некоторым разочарованием для бизнес-пользователей.

Что порадует Creator в Дельта BI?

Встроенный ETL. В Дельта BI несколько вариантов построения модели данных. Интеллектуальная модель строит модель данных и ETL процесс автоматически. В профессиональном режиме разработчик делает всё это сам (при это Дельта позволяет развертывать ML). Облегченная модель помогает пользователю строить ETL и модель данных в пошагово. Также в Дельта BI есть возможность подключиться к базе данных или хранилищу напрямую.

Обращение к языкам программирования не требует дополнительных настроек. Пользоваться Python или R в Tableau можно только после преднастроек, а в Дельта BI это доступно «из коробки».

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

Широкий функционал временных расчетов. Их можно проводить прямо на визуализации. Кроме того, в специальной папке Дельта BI позволяет делиться расчетами с коллегами (и, например, создать библиотеку калькуляций для метрик, используемых разными разработчиками).

Большие возможности редактирования таблиц. В таблицах по категориям и подкатегориям в Дельта BI настраивать можно всё вплоть до столбцов и видов строк. А еще здесь есть возможность задавать разную ширину для столбцов таблиц. В Tableau же при создании нескольких мер и настройке одного столбца автоматически корректировалась ширина остальных столбцов. Осталось только удержаться в границах разумного.

На одной оси размещается несколько мер. Функционал двойных осей (dual axis в Tableau) реализован шире. На оси вместо двух можно разместить столько мер, сколько потребуется.

Широкий функционал формирования и редактирования KPI. В Tableau мы привыкли создавать KPI при помощи листов. В Дельта BI это встроенная визуализация.

Автоматическая настройка интерактивных взаимодействий (экшенов). В Tableau приходится настраивать экшены самостоятельно. В Дельта BI они настраиваются автоматически. Если нужно понять, как одна визуализация влияет на другие, можно посмотреть все интерактивные связи между визуализациями, и при необходимости донастроить их через менеджер.

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

Сетка «из коробки». В Tableau для того, чтобы построить сетку, используются контейнеры. И это не всегда быстрый и приятный процесс. В Дельта BI сетку можно добавить парой кликов. Выбираем, сколько хотим сделать блоков (как ячейки для новой таблицы) и добавляем в них визуализации.

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

По чему в Дельта BI может скучать Creator Tableau?

• референсные и константные линии. В Tableau есть вкладка Аналитика, которая помогает дополнять визуализации итогами, прогнозами или референсными и константными линиями. В Дельта BI этот функционал тоже реализован, но без возможности добавлять референсные и константные линии;

• гибкая настройка диаграмм. В Дельта BI визуализации преднастроены. Но пакета обычно хватает и дорабатывать приходится крайне редко;

• быстрое создание псевдонимов (алиасов). В Tableau можно быстро менять названия данных прямо в рабочей области. В Дельта это приходится делать на уровне модели данных или добавив вычисления;

• иерархия фильтров и вычислений. В Tableau фильтры и вычисления отрабатывают с определенной последовательностью. В Дельта BI такой логики нет, здесь фильтрами отсекается определенный срез данных и на основе выборки строится визуализация. Если нужно понизить уровень детализации, пользуемся функцией маркера данных в вычислениях — аналогом LOD.

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

Системные требования Tableau и Дельта BI похожи

В Дельта BI можно подключаться к данным в режиме прямого подключения (Live) и режиме извлечения данных: в Дельта — In-memory, в Tableau — Extract. Требования к ОЗУ у Дельта BI ниже, чем у Tableau.

Весь функционал, который был доступен в Tableau и не охвачен в этой статье, так или иначе реализован в Дельта BI. Мы готовы помочь разобраться в инструменте и оценить стоимость перехода. Обращайтесь за консультацией.