Добро пожаловать в мир новых соглашений, где сеть фастфуда может войти в стратегический альянс с ИТ-компанией и каким-нибудь государством, а потом построить цепочку типа B2B2C, G2B2C и B2B2B. Слышали про экосистемы? Это речь и про них тоже.

Крупный бизнес понял, что можно и нужно продавать свои промежуточные продукты наружу. То есть стал API-ориентированным и простым для интеграций. Это в сочетании со вторым переходом человечества в онлайн (спасибо вирусу) породило очень много новых стратегических альянсов. Странных потому, например, что можно объединяться с самым злостным конкурентом: во-первых, вы друг друга понимаете, во-вторых, имеете данные по рынку, в-третьих, можете этот рынок вместе развивать.

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

Дружить с конкурентами выгодно

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

Стратегические альянсы создают новые возможности для всех участников. Взять, к примеру, сотрудничество онлайн-ритейлера Amazon.com и сети универмагов Kohl’s. С некоторых пор клиенты Amazon, решив вернуть товар, могут отнести его в любой магазин Kohl’s. Для Amazon это решило проблему нехватки физических торговых точек, а Kohl’s принесло дополнительный трафик покупателей: каждому, кто сдал покупку, вручается купон на скидку. Примерно то же самое было с известной маркой товаров для детей Toys R Us: после нескольких неудачных лет компания смогла вернуться в обойму благодаря стратегическому партнёрству с интернет-гипермаркетом Target.com.

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

Союз конкурирующих фирм генерирует новые цепочки ценностей. Те же авиаперевозчики — конкуренты по определению. Но в конце 90-х авиакомпании начали объединяться. Теперь пассажиры могут выбирать из большего варианта стыковочных рейсов, тратить меньше времени на пересадки и пользоваться едиными программами лояльности. Сейчас каждая авиакомпания старается подчеркнуть не свою «самость», а принадлежность к одному из мировых альянсов. Это классический пример перехода от модели B2C к B2B2C: взаимодействие бизнес-структур повышает общую ценность продукта и снижает стоимость.

Альянсы создают и другие ценностные цепочки, например, G2B2C — от власти к бизнесу и далее к потребителю. Классический пример — сайт «Госуслуги» и вообще электронное правительство, когда с помощью партнёрства государства и IT-компаний издержки взаимодействия людей с властными структурами значительно снизились. Помните, сколько стояли в очереди, чтобы получить номер на авто 10 лет назад? Я вот почти забыл.

В сфере высоких технологий пандемия подстегнула коллаборацию. Как отмечают исследователи из International Data Corporation (IDC), всё больше компаний, как дружественных, так и конкурирующих, обменивается данными, знаниями, приложениями, операциями и опытом. При этом, по прогнозу IDC, в будущем эта тенденция сохранится. Например, уже к концу нынешнего года доходы компаний, которые делятся данными со своей бизнес-экосистемой, будут на три процента выше, чем у предпочитающих конфиденциальность. А к 2026 году четверть всех приложений для госструктур и частных заказчиков будет разрабатываться консорциумами в рамках их бизнес-экосистемы.

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

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

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

Против кого подружились?

Цель сотрудничества конкурентов зависит в числе прочего от скорости разработки новых продуктов в отрасли. Например, стратегический альянс вполне может быть создан для установления таких правил рынка, чтобы новым игрокам было тяжелее расти. А в IT-сфере с её космическими темпами стратегические альянсы могут формироваться для ускорения исследований, разделения расходов на НИОКР и создания технологических стандартов.

Приостановка работы на российском рынке западных IT-игроков толкает российские компании в объятия друг друга, стимулирует кооперацию с бывшими конкурентами из стран БРИКС и ЕАЭС. Для сферы высоких технологий сейчас вообще открываются невиданные возможности: развивать технологический суверенитет можно чуть ли не по всем направлениям начиная с операционных систем. И здесь масса задач, с которыми в одиночку не справиться. По некоторым направлениям придётся начинать вообще с нуля, другие уже в работе. Например, летом прошлого года образовался консорциум российских разработчиков САПР, теперь они вместе бьются над проблемой национального масштаба — обеспечением российского стека в области систем автоматического проектирования. Полноценных российских программ CAD/САЕ на рынке сейчас нет, и это создаёт проблемы прежде всего для стратегических отраслей, таких, как атомная энергетика, космос и другие. Цель государства — к 2027 году снизить на этом направлении зависимость от заграницы до 20 %. То есть 80 % рынка должны занимать российские компании! В одиночку с такой задачей не справиться никому.

Ещё один альянс IT-компаний, теперь уже глобальный, сформировался, чтобы устранять пробелы в системах безопасности операционных технологий. Operational Technology Cyber Security Alliance (OTCSA) должен снизить риски использования высокотехнологичных решений на промышленных предприятиях. А в 2020 году появился альянс, занимающийся безопасностью ПО с открытым исходным кодом. В Open Source Security Foundation вошли такие гиганты, как Microsoft, Google, IBM.

Некоторые коалиции создаются для развития новых направлений и рынков: это искусственный интеллект, 5G, 6G, сквозные цифровые технологии, облачные решения, квантовые вычисления. Другие — для обслуживания определённых отраслей: госсектора, авиаиндустрии, автомобилестроения, ритейла, транспорта, металлургии. Третьи — чтобы ускорить разработку перспективного продукта, например, в разработке систем «умный город» или беспилотного шаттла. Облачные технологии и сети доставки контента (CDN), радиоэлектроника и безопасность удалённых подключений. Во всех случаях предполагается, что объединение компетенций даст синергетический эффект, позволяя и до заявленных целей добраться быстрее, и отдачу получить, превышающую вклад каждого участника.

Бывают и менее возвышенные мотивы, например, союз против общего бизнес-противника. Группа компаний, в числе которых — Linux Foundation, Google и Western Digital, пытается в пику Intel выпустить чипы с открытыми спецификациями. А Siemens, SAP и BMW объединились с тем, чтобы выдавить из немецкого автопрома облачные технологии Amazon и Google. Кстати, зависимость Европы от облачных решений американских компаний беспокоит даже функционеров Евросоюза: ЕС намерен вложить 10 миллиардов евро в создание собственной индустрии облачных вычислений.

Местами странные слияния

Поглощение или слияние — это тоже стратегия сотрудничества с конкурентами. По данным McKinsey & Company, объём и количество M&A-сделок в прошлом году били рекорды. Особенно это касалось высокотехнологичных компаний, средств массовой информации, телекоммуникаций и здравоохранения.

Зачем? Например, это новые экспертизы. Компания Accenture приобрела часть бизнеса компании DI Square, чтобы использовать её консалтинговую экспертизу в области систем управления жизненным циклом продукции (PLM) и приложений (ALM). Atos покупает Cloudreach, чтобы получить доступ к облачным технологиям, а Epam приобретает Optiva Media — одного из лидеров цифрового телевидения. Группа «Вартон» вместе с долей в отечественном разработчике процессорных ядер CloudBear приобретает приоритетный доступ к передовым технологиям компании, которые планирует интегрировать в собственные продукты.

Ещё один побудительный мотив проглотить конкурента — попытка выйти на принципиально новый рынок или укрепить позиции на имеющемся. Так, «Альфа-Групп» стала единоличным владельцем компании «Манго Страхование», успевшей освоиться на рынке онлайн-страховых услуг. Группа компаний «Международный аэропорт Шереметьево» для увеличения пассажиропотока приобрела «Библио-Глобус» и т. п.

Попытки добиться присутствия в регионах нередко становятся целью M&A-сделок, тот же «Ростелеком» с целью проникновения на Урал приобрёл интернет-провайдера «АйТиЭм Холдинг» из Екатеринбурга и «Архангельской» — крупного регионального оператора платного ТВ и доступа в Интернет. Покупка конкурента — один из кратчайших путей выхода и на международный рынок.

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

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

Создать стратегический альянс могут самые разные компании, например, вендор плюс вендор. Здесь объединились два поставщика систем хранения данных: DEPO Computers и Raidix. В результате клиенты получили унифицированные серверы, построенные исключительно на российских компонентах.

Участниками коалиции могут стать крупные отраслевые игроки. Так было при создании совместного предприятия «ГПМ Дата», учредителями которого стали медиахолдинг «Газпром-Медиа» и компания «МаксимаТелеком». Альянс займётся разработкой решений на основе анализа и обработки больших данных, машинным обучением и другими прорывными технологиями.

Полноправными участниками стратегических альянсов могут стать государственные институты развития. Прекрасный тому пример — создающаяся АНО «Открытый код», одним из учредителей которой может стать Центр компетенций по импортозамещению в сфере ИКТ. В альянс войдут как этот госинститут, так и вендоры, и отраслевые игроки: «Яндекс», ВТБ, «Газпром нефть», «Ростелеком» и другие.

Совместная разработка Accenture и SAP, анонсировавших вывод на рынок нового облачного продукта, может иллюстрировать сотрудничество IT-компании и вендора. Наработки Accenture, интегрированные с SAP Intelligent Asset Management, помогут компаниям повысить операционную безопасность и снизить затраты на обслуживание систем.

Есть множество примеров коллаборации вендоров и отраслевых игроков. Летом прошлого года несколько немецких гигантов — BMW, Volkswagen, Siemens, SAP, Bosch и другие — создали консорциум, который займётся технологиями квантовых вычислений и их внедрением в промышленность. Тогда же появился ещё один консорциум, в него, в частности, вошли Microsoft, Toyota, Nissan и Panasonic. Эти компании будут обмениваться информацией о недостатках ПО автомобилей, чтобы предотвратить угоны и кражу данных из бортовых систем. А консорциум морских грузовых перевозчиков Global Shipping Business Network совместно с Oracle, Microsoft Azure, AntChain и Alibaba Cloud запустил платформу блокчейн, способную отслеживать контейнеры по всему миру.

Coopetition и его правила

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

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

У coopetition — сотрудничества с соперниками — есть свой свод правил. Одно из них гласит, что, если вы откажетесь от коллаборации с конкурентом, ваше место займёт кто-то другой. И тогда ваш конкурент выиграет от сотрудничества с ним. Ещё одно правило в том, что партнёрство нужно структурировать так, чтобы одна сторона не чувствовала себя зависимой от другой.

Примеров успешного взаимодействия конкурирующих фирм немало. Ford и Toyota нашли возможность вместе работать над внедорожниками-гибридами, Apple закупает экраны у Samsung. Можно ли представить конкурентов непримиримее? Можно: это Apple и Microsoft в 90-е годы. Но в 1997-м две компании забыли о распрях и начали сотрудничать. Microsoft согласилась на поддержку Office для Mac, а Apple пообещала сделать Explorer браузером по умолчанию. Microsoft даже инвестировала в компанию Стива Джобса $150 миллионов, это здорово поддержало его детище в трудный момент. А Microsoft таким образом избежала обвинений со стороны антимонопольных служб.

Есть немало примеров успешного кобрендинга. Это Nike & Apple, BMW & Louis Vuitton, CoverGirl & Lucasfilm — список можно продолжать. Правда, здесь объединяются всё-таки не конкуренты, а компании, работающие в разных сегментах и даже отраслях.

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

Итак

Создание стратегических альянсов, в том числе и с конкурентами, — это тренд, который, похоже, будет развиваться. Даже самые злейшие конкуренты могут найти точки, взаимодействие в которых даст синергетический эффект и обеспечит выигрыш для всех. В сфере высоких технологий это справедливо вдвойне: объединение усилий позволяет экономить ресурсы при разработке продуктов, снижать расходы на НИОКР и создавать единые стандарты.

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

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

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

Или “Мне бы такую работу, чтобы поменьше работы.”:)

В данном посте хотелось бы затронуть такую очень известную и много где описанную тему как предобработка табличных данных в Data Science. Вы можете задать вопрос: “А зачем нам это нужно, ничего нового то тут не скажешь?”. Действительно, что может быть банальнее обработки табличных данных для моделей машинного обучения. Но мы постараемся собрать как можно больше информации в одном ультимативном, если так угодно, гайде, и подадим его через призму автоматического машинного обучения (AutoML). 

Дисклеймер: все описанные нами ниже подходы не являются единственно верными. Мы использовали их при развитии нашего open-source AutoML фреймворка FEDOT, у которого безусловно есть свои особенности как в архитектуре, так и в парадигме разработки. Несмотря на то, что мы реализовали довольно объемный блок предобработки изолированно от основной архитектуры проекта, он определенно пропитан духом ядра библиотеки. Приступаем!

Пролог (“Я не чувствую своих признаков. — У тебя их нет!”)

Сначала стоит прояснить (на всякий пожарный), что подразумевается под предобработкой табличных данных в Data Science. Это набор операций, который позволяет трансформировать данные таким образом, чтобы модели машинного обучения могли на таких данных корректно обучаться. В широком смысле в предобработку входит исходная очистка данных (удаление нечитаемых ячеек и столбцов и т.д.), устранение пропусков, кодировка категориальных значений, нормализация данных, удаление выбросов. Ниже в этом посте мы будем понимать под предобработкой только первые три блока. Если хотите подробнее почитать про предобработку табличных данных и какой она бывает, то можете начать с Предварительная обработка данных и продолжить c Data Preprocessing: Concepts.

Итак, потребность для внедрения блока предобработки таблиц (получившегося в итоге довольно большим), в AutoML-фреймворк возникла у нас с командой совсем не сразу. Поначалу нам было достаточно минимальной функциональности: заполнить пропуски, обработать категориальные признаки, нормализовать — передать на вход модели. Однако в течение последних нескольких месяцев у нас появилась задача запустить наш фреймворк на большом количестве датасетов из OpenML, kaggle и прочих источников (например, с ресурса “Departamento de ciencia de computadores”). И только тогда мы поняли насколько в  тепличных условиях мы растили фреймворк до этого — алгоритм не смог запуститься больше чем на половине датасетов. Для запуска мы брали 46 табличных наборов данных, большая часть из которых предназначалась для решения задачи классификации. С этого момента начинается наш путь.  

Немного про набор данных: размеры таблиц изменялись от совсем маленьких (748 строк на 5 столбцов для “blood-transfusion-service-center”) до довольно больших (4.9 млн строк на 42 столбца для “KDDCup99_full”). Общее количество элементов (умножение количества строк на количество столбцов) изменялось от нескольких тысяч до нескольких сотен миллионов. Всё это нам нужно было для возможности проверить адекватность работы алгоритмов на разных размерах данных (Рисунок 2).

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

Исследование (“Наши люди AutoML без предобработки не запускают”)

Перед тем как начать писать собственные костыли, мы решили посмотреть как подобную проблему решали наши коллеги из других команд. Оговоримся сразу, что рассматривать будем наиболее критические изменения в данных, преобразования в духе “трансформация одномерного target массива в вектор-столбец” подразумевается, что производится при необходимости в любой сколько-нибудь крупной AutoML библиотеке. 

Начнём с фреймворка H2O, где эксплуатируется следующая структура. Предобработка предшествует запуску AutoML алгоритма. В препроцессинге классический джентльменский набор: автоматическое определение типов, кодирование категориальных признаков при помощи OneHotEncoding’a, заполнение пропусков и нормализация при необходимости. Также имеется возможность опциональной предобработки для некоторых моделей — например не для всяких требуется нормализация и т.д. Немного интересных фактов: H2O версии 3.28.1.2 успешно запустился на 24 датасетах из 46.

Популярный академический фреймворк TPOT не является в полной мере “end-to-end” решением, в отличие от H2O. Поэтому большую долю предобработки библиотека оставляет на стороне пользователя, концентрируясь на оптимизации пайплайна. Тем не менее в структуре TPOT есть методы, отвечающие за усвоение входных данных. В частности, в препроцессоре происходит проверка на наличие пропусков, есть различные стандартизаторы и нормализаторы. Разделение на категориальные и вещественные признаки происходит на основе количества уникальных значений в столбце. В отличие от H2O опциональной предобработки не предусмотрено — препроцессинг выступает единым блоком предшествующим запуску эволюционного алгоритма для поиска модели. Пусть предобработка не является сильной стороной данного фреймворка, он широко известен и довольно надежен. Хотя вычистить исходный датасет всё же рекомендуется перед подачей данных. Например, фреймворк не переваривает наличие строковых типов данных в массивах.

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

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

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

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

Реализация (“Надежная, как швейцарские часы”)

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

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

Какие особенности можно выделить у этой таблицы с признаками: 

• В признаке 1 присутствуют значения плюс минус бесконечность;

• В признаке 2 слишком много пропущенных значений;

• В признаке 3 присутствует пропуск. Также отметим, что признак принимает только два возможных значения: 1 и 10;

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

• Признак 5 бинарный категориальный и имеет пропуск;

• Признак 6 содержит в себе типы данных float и string;

• Целевая переменная содержит пропуски. При этом представлена в виде сырых меток, представляющих собой строки.

Начинаем двигаться слева направо. Сначала заменим все значения плюс минус бесконечность в признаке 1 на nan. Далее удалим признак 2, потому что он содержит слишком много пропущенных значений (порог у нас в фреймворке задан как 90% объектов).

После удалим объект из обучающей выборки, значение целевой переменной для которого неизвестно — id 2.

После этого применим LabelEncoder, чтобы перевести метки ‘> 10’ и ‘<= 10’ в 0 и 1 соответственно. Устраним отступы в строках в признаке 4.

Небольшое лирическое отступление. Реализация OneHotEncoding’а в sklearn (а у нас в AutoML мы под капотом используем именно такую реализацию) поддерживает обработку бинарных категориальных признаков и обработку новых категорий, которых операция предобработки не видела во время обучения в тренировочной выборке. Первое значит, что если в таблице имеется категориальный бинарный признак, то его не будут увеличивать путём раздувания до нескольких столбцов. Второе значит, что если в тренировочной выборке были категории, например, “средний” и “маленький”, а в тестовой выборке “большой”, то алгоритм сможет продолжить работу без ошибки. Проблема только в том, что одновременно две этих опции не работают: нужно выбрать, либо одно, либо другое. Мы решили, что для нас важнее, чтобы фреймворк не проседал при обработке новых категорий. 

Поэтому бинарные категориальные признаки (количество уникальных категорий в которых не больше двух) следует обрабатывать отдельно. Так и поступаем с признаком 5, — конвертируем значения в “1” и “0”.

Наконец, признак 6. Для него критически важным оказывается результат работы системы определения типов, которая также была реализована как часть предобработки. Она работает абсолютно одинаково для всех столбцов. Но сначала обозначим проблему: в признаке с float значениями есть знак ‘?’, и когда вы такой датафрейм загрузите к себе, то обнаружите, что pandas заботливо перевёл все числа в строки. Звучит не так страшно, однако если количество уникальных значений в признаке велико, а для энкодинга используется One Hot Encoding, то вас удивит размер получившейся после преобразования таблицы. 

К решению. При помощи map мы просматриваем каждый элемент столбца и определяем из каких типов данных состоит столбец и в каких элементах какие типы расположены. В случае с этим столбцом выясняется, что количество уникальных значений намного больше, чем должно быть в категориальном признаке (может конкретно в этом фрагменте это и не так, но будь таблица чуть побольше, то это сразу стало бы заметно). Тогда алгоритм пытается привести столбец к типу float и попутно помечает все значения, которые в этот тип привести не может как nan. Таковым оказывается знак “?” в строке 4 (Таблица 6).

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

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

Еще бóльшая реализация (“Я требую продолжения банкета!”)

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

Главная задача дополнительной обработки табличек — не позволить модели во время выполнения упасть с ошибкой. Рассмотрим на примере заполнения пропусков. Если алгоритм “понимает”, что если пропуски не заполнить, то пайплайн не сможет обучиться, то применяется стратегия заполнения пропусков по умолчанию. Если же в структуре пайплайна есть модели, способные данные с пропусками усвоить, то таблица пройдёт далее нетронутой. Тогда возникает вопрос: “Так почему же не предобработать данные сразу, заполнить пропуски и применить энкодер? Надежней же.”. Дело в том, что способов заполнения пропусков существует довольно много, равно как и способов энкодинга много больше двух. Поэтому ограничивать пространство поиска только одним способом не хочется — AutoML алгоритм сам разберётся как ему лучше преобразовать данные, чтобы получить самую точную модель. 

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

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

• могут переработать данные и устранить проблему (наличие пропусков например);

• могут данные пропустить через себя, но при этом не устраняют источник ошибки;

• при проведении операций над данными вызывают ошибку.

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

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

Представим, что в структуре пайплайна никаких операций предобработки не имеется и у алгоритма стоит необходимость заполнить пропуски и закодировать категориальные значения по умолчанию. Сначала разберёмся с пропусками: они присутствуют в признаках 1, 3, 5 и 6. Для столбцов 1 и 6 применяется самая обычная стратегия заполнения пропусков средним значением. Интереснее со столбцами 3 и 5, — столбцы содержат числовые значения, однако количество уникальных значений, которые могут принимать показатели в этих столбцах, не превышает двух. А много ли вы знаете числовых признаков, которые принимают всего два значения? — Не давая на размышление 15 сек, предположим, — признак скорее всего обозначает присутствие или отсутствие чего-либо у объекта. Объект либо имеет, например, хвост, либо не имеет. Полутонов вводить тут не стоит. Поэтому в таких столбцах заполним значения мажоритарным классом. В случае, если количество категорий равно (это в действительности случается исчезающе редко), то для бинарного признака пропуски заполняются всё таки средним значением. 

С категориями проще — стратегией кодировки по умолчанию является OneHotEncoding (Таблица 8).

Развязка (“Честно говоря, моя дорогая, мне наплевать”)

Попробуем повторить все те навороты, которые мы реализовали в ходе разработки блока предобработки в AutoML фреймворке. 

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

В обязательную входит: 

1. Замена значений плюс минус бесконечность в признаках и целевом столбце на nan

2. Удаление признаков, число пропущенных значений в которых превышает 90%

3. Удаление объектов из таблицы, для которых неизвестно значение целевой переменной (nan в target)

4. Перевод меток в целевом столбце из строкового формата в целочисленный

5. Устранение отступов в строковых объектах в признаках

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

Дополнительная:

1. Анализ структуры пайплайна на наличие операций заполнения пропусков — заполнение пропусков при необходимости;

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

Все приведенные выше модфикации позволяют фреймворку запускаться на рассмотренных датасетах (даже на самых страшных) именно с фразой из названия раздела.

Позволю себе и читателю здесь немного остановиться и поразмышлять. Всё что было описано выше это сложная техническая задача (без шуток). Но интересна ли она исследователю или заказчику? — скорее всего нет. Всю эту возню с данными обычно хочется проскочить как можно быстрее и перейти к разработке модели, ведь именно это самая захватывающая часть. Только представьте, сколько кода потребовалось бы написать, чтобы предобрабатывать данные таким образом. Так не лучше ли отдать всю предобработку на сторону AutoML алгоритмов?

import numpy as np  from fedot.core.data.data import InputData  from fedot.core.pipelines.node import PrimaryNode  from fedot.core.pipelines.pipeline import Pipeline  from fedot.core.repository.dataset_types import DataTypesEnum from fedot.core.repository.tasks import Task, TaskTypesEnum   train_input = InputData(idx=np.arange(0, len(features)), features=features, target=target, task=Task(TaskTypesEnum.classification), data_type=DataTypesEnum.table)   pipeline = Pipeline(PrimaryNode('scaling'))  pipeline.fit(train_input)  preprocessed_output = pipeline.predict(train_input)  transformed_data = preprocessed_output.predict

Эпилог. Эксперимент (“Тебя запустют, а ты досчитай!”)

Поскольку запускать фреймворк на всех таблицах дело небыстрое, мы подготовили небольшой игрушечный датасет в репозитории automl-crash-test. Таблица для решения задачи классификации совсем небольшая, но представляет собой собирательный образ всего того плохого, с чем мы столкнулись во время запусков на всех 46 датасетах. 

Если захотите запустить свой любимый фреймворк на этих данных — welcome. Пройти такой краш-тест на самом деле не так то просто как кажется. А выбить хороший скор (ROC AUC 1.0) — результат просто отличный. Набрать ROC AUC 1.0 на тестовой выборке для данной таблицы возможно только корректно предобработав хотя бы некоторые столбцы, отбросив все ненужные и оставив нужные. 

Ниже приведен пример запуска фреймворка FEDOT (версия 0.5.2) на этих данных. Результат выполнения программы для нас самый заветный — никаких ошибок не возникло и мы смогли получить финальное решение. Также весь код и зависимости для запуска есть в репозитории.

from fedot.api.main import Fedot from sklearn.metrics import classification_report, roc_auc_score  from data.data import get_train_data, get_test_data  train_features, train_target = get_train_data()  test_features, test_target = get_test_data()   # Task selection, initialisation of the framework  fedot_model = Fedot(problem='classification', timeout=timeout)   # Fit model  obtained_pipeline = fedot_model.fit(features=train_features, target=train_target) obtained_pipeline.show()   # Make predictions predict = fedot_model.predict(test_features)  predict_probs = fedot_model.predict_proba(test_features)

Финальная метрика на тестовой части — 1.0 ROC AUC.

Заключение (“Вы привлекательны, я чертовски привлекателен… Чего время терять?”)

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

Естественно, что все описания стоит рассматривать через призму разработки AutoML инструмента, который в нашей парадигме должен работать надежно там, где junior Data Scientist быстро и надёжно работать не сможет (или сможет, но не очень надежно или не очень быстро). И, возможно, если такая предобработка подошла для наших моделей, она сможет подойти и вам для ваших.  

Полезные ссылки:

• Репозиторий open-source AutoML фреймворка FEDOT

• Канал NSS Lab — анонсы наших новых статей и выступлений, посвященных AI/ML

• Репозиторий с «грязными» таблицами automl-crash-test

В выступлении со своеобразным гайдом по предобработке табличных данных участвовали: Сарафанов Михаил и команда NSS lab

Многие наши клиенты используют для сетевой защиты популярные межсетевые экраны нового поколения (NGFW). С их помощью компании анализируют входящий и исходящий трафик, предотвращают вторжения, строят VPN-тоннели до конечных устройств и так далее. Кто-то приобретает аппаратные или виртуальные NGFW и администрирует их сам, кто-то арендует у нас ресурсы и получает NGFW как сервис. 

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

В статье на примере отечественного UTM UserGate покажу варианты страховки: от временного переключения на отечественный файрвол до полной замены NGFW. 

С чем столкнулись клиенты и чего боятся

Когда компания приобретает NGFW в собственность, она фактически платит по двум моделям: 

• Разовый платеж за программно-аппаратный комплекс или виртуальный аналог. Чаще всего в стоимость физического или виртуального аплайнса уже входит техподдержка.

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

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

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

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

Что нужно уточнить перед внедрением

1. Приватный NGFW или публичный сервис по подписке. В обычной ситуации клиент выбирает приватное решение на своих ресурсах, если хочет сертифицироваться по требованиям ФСТЭК. 

   NGFW по сервисной модели (или MSS) чаще выбирают, если хотят передать администрирование квалифицированным специалистам, а своих в штате нет.

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

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

3. Каковы требования к отказоустойчивости: нужен ли клиенту кластер и в каком режиме. 

4. Какие модули NGFW необходимы клиенту и для чего. Здесь специалисты определяют параметры подписки на дополнительные модули.

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

6. Где находятся ресурсы клиента. Этот пункт тоже влияет на схему подключения. Например, если клиент уже размещается в наших ЦОД с MSS NGFW, мы можем организовать стыковую сеть между UserGate и клиентскими ресурсами. 

   Если клиент находится на своей площадке, то вместо стыка инженеры построят IPSec-туннель между облаком с NGFW и клиентской площадкой. Главный минус здесь – производительность. 

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

Если хочется сразу переехать

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

Тогда стандартная схема размещения ресурсов за MSS NGFW в нашем облаке будет такой:

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

• в отдельном сегменте DMZ размещены почтовые релеи, обменники;

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

Переезд на UserGate аналогичен процессу миграции на другие MSS NGFW, о чем мой коллега уже рассказывал. Напомню основные моменты:

1. Сначала все сетевые настройки и настройки безопасности переносятся “как есть”: старый конфиг переезжает на UserGate. Чтобы избежать простоя при миграции, инженеры заранее согласуют технологическое окно и детально документируют все параметры: 

   • как сегментирована сеть, 

   • какие VLAN’ы используются,

   • какие типы сетей: routed, isolated (если речь про виртуализацию),

   • как клиент выходит в интернет,

   • как все мониторится,

   • какие NAT-трансляции используются.

   Затем создается отдельная ВМ на UserGate, туда подаются VLAN’ы. Все правила доступа переносятся со старого оборудования, создаются NAT-трансляции с новыми адресами. Инженеры тушат интерфейс на старом NGFW и поднимают интерфейс с таким же адресом на UserGate. Параллельно клиент меняет DNS и последовательно переключает все VLAN’ы. 

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

3. После настраиваем необходимые модули NGFW: IPS, контроль приложений, антивирус. Сначала профили безопасности ставим в режим мониторинга и наблюдаем за срабатываниями, чтобы не заблокировать лишнее. И только потом совместно с клиентом договариваемся о правилах блокировки.

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

Если хочется сначала протестировать

Клиент облака может защитить ресурсы и заодно проверить “на вшивость” UserGate за счет одной из временных схем.

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

2. Поставить UserGate “в разрыв” между интернетом и клиентским файрволом. Это временный вариант, который требует совсем небольших изменений в сетевой инфраструктуре. Трафик будет фильтроваться на UserGate с актуальными сигнатурами, а настройки клиентского NGFW сохранятся на старом оборудовании и переносить их не придется.

   Выглядит схема так: 

   

   В этом случае на UserGate переносятся только правила межсетевого экранирования и настраиваются выбранные модули NGFW: сначала в режиме мониторинга, и только после согласования с клиентом – в режиме блокировки. По договоренности с клиентом также можно добавить на UserGate NAT-трансляции или публикацию ресурсов.

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

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

   

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

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

Что и как можно защитить отечественным UserGate

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

Российская специфика. Здесь у импортозамещения есть формальная и практическая сторона. Начну с формальной – для тех, кому важна сертификация.  

UserGate сертифицирован ФСТЭК России: 

• по требованиям к межсетевым экранам (4-й класс, профили А и Б);

• по требованиям к системам обнаружения вторжений (4-й класс);

• по 4 уровню доверия. 

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

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

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

На UserGate есть модули, которые интересуют клиентов чаще всего: 

• IPS, 

• антивирус,

• контент-фильтрация,

• URL-фильтрация

• IPSEC-VPN-тоннели,

• SSL-VPN,

• Mail security,

• контроль мобильных устройств.

Но помимо этого есть специфическая защита, например, поддержка АСУ ТП (Scada). Полный список модулей можно посмотреть здесь. 

Итак, даже в текущей нестабильной ситуации у нас есть выбор, как решить проблему ухода западных NGFW: 

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

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

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

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

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

Итак, по порядку.

Маркетолог-многорук без вдохновения и перспектив

Лето. Очередной рабочий день в офисе на позиции интернет-маркетолога. Официально я был руководителем отдела маркетинга, а на самом деле работал один на две компании и всё делал сам. Постоянно мониторил результаты таргетинга в фейсбуке, зарывался в таблицах для корректировки директа. Будем откровенны — мне это не нравилось. 

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

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

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

Удачный случай подсказал, куда пойти

У моего знакомого была веб-студия Roobinium, и он рассказал мне о следующей проблеме. Среди его клиентов существовало два типа заказчиков:

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

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

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

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

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

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

Работа в роли UX-дизайнера

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

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

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

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

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

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

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

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

Во время UI-дизайна происходит визуализация проекта: подбор цветовых схем, детальная проработка расположения элементов. Допустим, в рамках прототипа UX-проектировщик заложил слайдер в определенном месте. Задача UI-дизайнера — отобразить, как именно он будет выглядеть: в виде трех точек или галочек по бокам, или же будет использован какой-либо другой паттерн. На этой же стадии готовится мобильная версия и дизайн-система, набор компонентов дизайна. 

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

Найм или фриланс — пока выигрывает найм

В начале января 2020 года я приехал в родной Ростов-на-Дону на операцию. Планировал побыть в России полгода и вернуться в Таиланд. Но пандемия внесла свои коррективы. 

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

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

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

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

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

Сейчас в Спортмастере я работаю со внутренней системой, которая позволяет взаимодействовать с карточками клиентов, обращениями, заказами и прочим. Для этого проводилось большое исследование, интервью с пользователями, просмотр записей экрана, прослушивание записей разговоров с клиентами, составление User Story Map совместно с заказчиками и непосредственное UX-проектирование. Мне приятно, что моя работа поможет оперативно решать любые вопросы клиентов и облегчит работу сотрудников.

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

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

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

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

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

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

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

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

Это подтверждает и совместное исследование Нетологии и агентства AGIMA — только 36% опрошенных дизайнеров обучались своей профессии вузе, а 64% –– изучали необходимые навыки самостоятельно или с помощью дополнительных курсов. При этом почти 80% опрошенных специалистов, и начинающих, и продвинутых, при необходимости получить новые знания по профессии, обращаются к онлайн-курсам.

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

Татьяна Смирнова,

руководителя Центра развития карьеры Нетологии

Я не так давно начал изучать Python, и решил,  что мне необходима портативная сборка.  Причин для этого несколько, но статья не об этом. Если вам такое не нужно, дальше можно не читать. Во время поисков решения этой задачи часто сталкивался с вопросами людей по этой теме, но однозначного решения так и не нашел, но ответы некоторых пользователей натолкнули на верное решение. Почему VS Code? Ну, просто у них есть версия “portable”, так она гордо называется на сайте, но скачав ее, возникает вопрос, а как к тебе приделать Python?

 Сразу оговорюсь, целью было сделать полноценно переносную версию из связки Python + среда разработки + Git (для изучения).  В статье все расписал максимально подробно, так же на github закину файлы со всеми изменениями, и вам останется только создать структуру каталогов как у меня. Если хотите все разложить по своему- читайте-исправляйте,  по аналогии думаю не сложно будет сделать под себя.

Что нам потребуется:

1. Winpython

2. Cmder full – замена командной строке

3. VS code portable — качаем по ссылке .zip нужной разрядности, но для универсальности лучше 32бит

Если вам не нужен Git или Cmder их можно не добавлять, так же можно добавить portable Git отдельно, добавляется по аналогии с Cmder.

Настройка WinPython

Извлекаем Winpython в любое удобное место. Я ставил версию Winpython32-3.8.10.0dot, она последняя поддерживает Windows 7. После извлечения папку назвал ” WPy32-38”, можете обозвать как нравится, но дальше в статье я буду ее называть так.

И так заходим в нашу папку “WPy32-38”, дальше нас интересует папка “t” вот в нее мы и извлекаем Cmder и VS code. Это уже обязательное условие.

После извлечения VS Code настраиваем по инструкции с оф.сайта, так же это сработает и для миграции уже установленного VS Code. Для портативной версии достаточно внутри папки VS Code создать папку ”data” и в ней папку “user-data”.  

Должно получится как-то так:

|- VSCode-win32-x64-1.25.0-insider  |   |- Code.exe (or code executable)  |   |- data  |   |   |- user-data  |   |   |   |- ...

Cmder просто извлекаем рядом с VS code. Папку с проектами я разместил рядом с WPy32-38, были разные варианты размещения, для быстрой активации Venv, но полноценного варианта так и не нашел, об этом подробнее в конце статьи.

|- WPy32-38  |   |- projekt  |   |- t   |   |   |- VSCode  |   |   |- Cmder

С размещением файлов и папок разобрались, теперь все это надо прописать.

Первым делом открываем блокнотом  файл «..\..\WPy32-38\scripts\env.bat»

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

Помните я писал что расположение важно? Так вот если у вас пути к папкам свои исправляем на данном этапе. Этот код располагаем после 55 строки примерно, между другими подобными блоками

Это для установки папки с Cmder

rem ****************** rem handle Cmder if included rem ****************** if not exist "%WINPYDIRBASE%\t\cmder\vendor\" goto cmder_bad set CMDER_HOME=%WINPYDIRBASE%\t\cmder\vendor\ set CMDER_EXE=init.bat set CMDER=%CMDER_HOME%%CMDER_EXE% set CMDER_PKGDIR=%WINPYDIRBASE%\cmder\ :cmder_bad

Это для установки папки с Git

rem ****************** rem handle GIT if included rem ****************** if not exist "%WINPYDIRBASE%\t\cmder\vendor\git-for-windows\cmd\" goto git_bad set GIT_HOME=%WINPYDIRBASE%\t\cmder\vendor\git-for-windows\cmd\ set GIT_EXE=git.exe set GIT=%GIT_HOME%%GIT_EXE% set GIT_PKGDIR=%WINPYDIRBASE%\t\cmder\vendor\git-for-windows\ :git_bad

Так же после строки   ” if %ERRORLEVEL% NEQ 0” (у меня это 26 строка) в поле “set”  дописываем пути к Cmder и Git, можете просто заменить этим:

set "PATH=%WINPYDIR%\Lib\site-packages\PyQt5;%WINPYDIR%\Lib\site-packages\PySide2;%WINPYDIR%\;%WINPYDIR%\DLLs;%WINPYDIR%\Scripts;%WINPYDIR%\..\t;%WINPYDIR%\..\t\mingw32\bin;%WINPYDIR%\..\t\R\bin\i386;%WINPYDIR%\..\t\cmder\vendor;%WINPYDIR%\..\t\cmder\vendor\git-for-windows;%WINPYDIR%\..\t\cmder\vendor\git-for-windows\cmd;%WINPYDIR%\..\t\cmder\vendor\git-for-windows\bin;%WINPYDIR%\..\t\cmder\vendor\git-for-windows\mingw32\bin;%WINPYDIR%\..\t\Julia\bin;%WINPYDIR%\..\n;%PATH%;"

На данном этапе все настройки для WinPython мы сделали.

Переходим к настройке VS Code

Для запуска используем ..\WPy32-38\VS Code.exe. Возможно при первом запуске будут ошибки, пока их просто игнорируем и открываем настройки.

 ..\WPy32-38\t\VSCode\data\user-data\User\ settings.json

// Указываем путь для питона "python.interpreterPath": "${env:WINPYDIR}\\\\python.exe",  // Указываем путь для для проектов и соответсвенно для “venv”  "python.venvPath": "${workspacefolder}/.venv",  "python.venvFolders": [       ".venv",       "${workspacefolder}/.venv"  // Указываем путь до Cmder  "terminal.integrated.profiles.windows": {         "Cmder": {           "path": "${env:windir}\\System32\\cmd.exe",           "args": ["/k", "${env:WINPYDIRBASE}\\t\\cmder\\vendor\\init.bat"]         },  // Тут путь для GIT, и соотвественно появится выбор командной строки GIT,можно не добавлять.         "GIT": {           "path": "${env:WINPYDIRBASE}\\t\\cmder\\vendor\\git-for-windows\\git-cmd.exe",         }       },  //Устанавливаем Cmder по умолчанию   "terminal.integrated.defaultProfile.windows": "Cmder",   //Активируем GIT    "git.enabled": true  //Прописываем путь до GIT     "git.path": "${env:WINPYDIRBASE}\\t\\cmder\\vendor\\git-for-windows\\cmd\\git.exe",

После сохранения требуется перезапуск VS Code.

Проверка прописанных модулей

Для проверки открываем командную строку “Ctrl+~” , если видите там лямбду, Cmder подцепился и работает. Пишем в командной строке git —version, получили версию, значит и git нормально прописали.

Пробуем запускать проект и проверяем активировался ли venv, если нет, то проверяем предлагает ли VS Code его как рекомендуемый. Опять нет? Тут я нашел только один вариант, если вы знаете что виртуальная среда создавалась в этой же версии питона, то просто вводим в терминале VS Code : python –m venv venv и делаем перезапуск VS Code, но зависимости ставить повторно не придется. Так же не могу сказать как активировать виртуальную среду другой версии. Просто, по какой-то причине, стандартная команда для активации venv у меня не срабатывает. Тут уже тестируйте-смотрите. Возможно кто-то подскажет путь решения данной проблемы.

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