Блог компании exness

FinTech. А что защищать?

22.09.2020 14:11:12 |

Автор: admin

Всем привет,

Минутка деанона, меня зовут Анатолий Маковецкий, я Security Team Lead в Exness.
Сразу извинюсь перед теми, кто ожидает увидеть технический write-up, здесь его не будет. Также в материале описаны настолько очевидные на первый взгляд вещи, что даже не факт, что они являются таковыми, но вы резонно можете меня спросить, как меня наняли и когда я уже перестану притворяться безопасником (ответ на картинке под катом) :).

Погнали.

Изображение: Telegram канал Information Security Memes (http://personeltest.ru/aways/t.me/infosecmemes)

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

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

Да, правильно, настоящая информационная безопасность зиждется на процессах, ISO, 27k в зубы и пошли выносить мозги ИТ и топ-менеджменту, все расскажем, все разложим, обоснуем и покажем, никто не поспорит, ведь, надо, только станут ли наши процессы в полях лучше от внедрения очередного стандарта?

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

Фото: s.66.ru

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

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

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

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

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

Примечание: *

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

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

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

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

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

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

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

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

Примечание: **

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

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

В финтехе есть деньги.

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

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

На изображении ниже схема информационных потоков одного из наших продуктов :)

Изображение: сериал DuckTales Walt Disney Television Animation

Также уход от парадигмы, что мы защищаем только информацию, позволил понять еще один тип ценных ресурсов, которым я пренебрегал ранее, но он присутствует у всех, хотя и является довольно неоднозначным взаимоотношения, которые могут быть партнерскими отношениями с поставщиком клиентов/трафика, либо с провайдером услуг связи/сервиса безопасности/инфраструктуры. Конечно, раньше я всегда неявно рассматривал это, но в контексте реализации угрозы в вакууме, из разряда Business Continuity Plan и Disaster Recovery Plan, а здесь оно трансформировалось в сознании во вполне осознанный актив, который стоит идентифицировать и защищать, что расширяет наше покрытие, так как мы начинаем двигаться в этом отношении не только от известных угроз, но и от самого актива, как от объекта потенциально подверженного неизвестным угрозам, но не об этом сейчас.

Если посмотреть ближе, то деньги виднеются со всех сторон:

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

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

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

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

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

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

Если этот материал не провалится по полной, то дальше постараюсь более подробно и практически-ориентированно раскрыть основные подходы, инструменты и субъективное видение таких тем, как:

Мой велосипед на тему моделирования угроз (если будет спрос на него, так как велосипедов и без моего хватает);
(Не)доверие и безопасность;
Bug Bounty, как мы это делаем и к чему стремимся;
Замечания об особенностях русскоязычного рынка ИБ-специалистов после длительного опыта в качестве интервьюера;
Что должно драйвить безопасность.

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

Всем добра и сбалансированного профессионального подхода!

Подробнее..

Категории: Информационная безопасность , Блог компании exness , Моделирование угроз , Управление безопасностью , Процессы в безопасности , Угрозы безопасности , Безопасность в финтехе

Семь бед один ответ как мы решали проблему постоянных исправлений

11.12.2020 18:19:05 |

Автор: admin

Приветствую, Хабр! Меня зовут Павел Воропаев, я Software Engineer в компании Exness. Ранее успел поработать в разных российских компаниях в качестве фулстек разработчика, разработчика баз данных Oracle, Python-разработчика и тимлида. По случаю завершения моего испытательного срока я решил написать статью, в которой бы хотел поговорить о том, как можно оптимизировать процесс погружения в задачу. Я расскажу о накопленном ранее опыте, и о том как мой опыт выручил меня, когда я пришел в Exness. В примерах буду описывать взаимодействие микросервисов с помощью sequence diagram.

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

В чем проблема?

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

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

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

Как это можно исправить?

На предыдущих местах работы я встречал такой алгоритм работы:

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

...

еще исправления;
долгожданное завершение задачи.

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

Тогда алгоритм работы станет следующим:

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

Почему так важно описать техническое решение до самой реализации:

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

Как я применил этот опыт в Exness?

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

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

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

Пример

Ниже описанный пример является собирательным из различных ситуаций.

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

После выяснения технических деталей понять задачу можно так:

собрать микросервис, в нем сделать одну POST метод API с названием reject_old_requests;
в этом метод API надо получить данные из БД, в запросе указать фильтры по пользователю, статусу и дате;
по каждой заявке сменить статус в сервисе, который управляет заявками;
затем отправить запрос в сервис нотификации, чтобы уведомить пользователей об изменении статуса заявки.

Диаграмма последовательности для этой задачи могла бы выглядеть так:

и на какие ошибки можно было бы напороться:

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

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

Как бы выглядела диаграмма после исправлений:

Какая польза от диаграмм?

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

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

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

Диаграммы однозначно помогут с:

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

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

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

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

Подробнее..

Категории: Программирование , Python , Блог компании exness , Проектирование , Хорошие практики , Диаграммы последовательности , Погружение в проект , Документирование

Тимлиды. Много и сразу. Как выбрать и развивать

26.06.2020 18:17:05 |

Автор: admin

Всем привет! Меня зовут Андрей Новиков, я руководитель разработки в одном из подразделений компании Exness, и совместно с Леной Скворцовой, нашим HR BP, мы хотим вам рассказать про то, как выбираем тимлидов в командах разработки, как их развиваем и как растим под жарким кипрским солнцем.

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

Наша инфографика на 01/06/2020

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

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

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

Процесс выбора;
Talentpool;
Программа развития;
IDP;
Уроки и советы.

Процесс выбора

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

Для этого весь процесс мы разделили на несколько этапов:

Самостоятельная подготовка;
Собеседование;
Калибровка результатов.

Самостоятельная подготовка

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

Собеседование

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

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

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

Калибровка результатов

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

Talent Pool

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

Программа развития

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

Программа базового менеджмента

Развитие лидерства команды
- Роли менеджмента
- Цикл управления
- Ситуационное лидерство
Навыки влияния
- Управление вовлеченностью
- Типы личностей
- Избегание манипуляций
Навыки влияния и оценка деятельности
- 1-1 встречи
- Оценка 360
- Как предоставлять негативный фидбек
Управление собственной продуктивностью
- Приоритеты
- Типы планирования
- Энерджи-менеджмент
Мотивация
- Мотивация или вовлечение
- Теория мотивации
- Gallup Q12

Программа операционного менеджмента

Инцидент менеджмент;
Гибкие методологии разработки (Scrum, Kanban);
Фасилитация встреч;
Процесс найма;
Процесс адаптации;
Увольнение;
Разбор сложный кейсов;
Зарплата.

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

IDP (Individual Development Plan)

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

Процесс составления и развития по IDP выглядит так:

Подготовка. На первичной встрече тимлид и Learn & Development (L&D) специалист/ HR обсуждают те области, где сотрудник чувствует неуверенность/ хочет расти. Это беседа с примерами из ежедневной работы руководителя, цель которой понять, что конкретно хочется улучшить. Как в идеале выглядит результат? Чем это поможет бизнесу?
Составление IDP. IDP это список книг, статей, подкастов, видео, фильмов, активностей для прокачки конкретного скилла. На каждый скилл, как правило, включаем чтение/ видео/ активность, чтобы, как говорится, и в теории, и на практике.
Развитие. После того, как IDP готов, мы приступаем к работе над ним. Один раз в месяц тимлид и L&D специалист/ HR встречаются, чтобы посмотреть, работает ли IDP, стоит ли его подкорректировать, и чем еще можно помочь. IDP это рабочий инструмент, который может меняться и дополняться. Например, после результатов 360 мы часто дополняем IDP, если видим, что конкретная компетенция просела.

Как выбрать компетенции для IDP? Задача L&D специалиста и тимлида на первой встрече понять на примерах, какая компетенция нуждается в улучшении.
Обычно все компетенции в IDP попадают в три основные области скиллов в компании: business acumen (понимание бизнеса и отрасли), operational excellence (execution) и leadership (soft skills, так необходимые руководителю). Для тимлидов первая версия IDP в основном заключалась в работе над leadership, а именно people management.
Как мы измеряем прогресс? Как всегда фидбек! Это и личный фидбек от коллег, и результаты 360, и, конечно же, отзывы тимлидов про свое развитие.

Уроки и советы

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

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

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

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

Подробнее..

Категории: Управление проектами , Управление персоналом , Карьера в it-индустрии , Управление разработкой , Управление командой , Карьера , Управление людьми , Менеджмент , Блог компании exness , Тимлид , Idp , Teamlead , Teamleading , Talentpool , Менеджмент в it

Простые средства информирования внутри компании

14.08.2020 16:23:02 |

Автор: admin

Всем снова привет!

Вроде бы еще не так давно я рассказывал, как выглядит обмен знаниями в Exness глазами новичка, и вот уже снова есть, что рассказать!

На самом деле, гибкость и скорость это два больших плюса в любом бизнесе. И на работу knowledge managera это влияет в огромной степени.

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

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

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

У нас в компании никто ничего вовремя не узнаёт...

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

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

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

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

Кому реально надо, тот и так узнает!

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

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

Более того, бывают такие ситуации, когда вы лучше знаете, кого аффектит планируемый апдейт. А если человек даже не подозревает, что вы готовите что-то, что может изменить его business as usual, как он должен предугадать ваши действия?

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

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

Это все долго и сложно. Лучше фичи быстрее пилить!

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

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

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

Конечно, без работающего продукта на рынок выйти не получится. Важность разработки никто не умаляет. Но раз в месяц экспортнуть список задач из JIRA, добавить к каждой описание в 3-5 слов, скопировать это в письмо и нажать кнопку Отправить, это ведь не займет много времени, верно? Да вы и так, скорее всего, что-то подобное для руководства составляете и отправляете.

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

Куда писать? Чем пользоваться?

Конечно, каналы информирования могут быть разными. Чем пользоваться зависит от культуры конкретно вашей компании. Если у вас приняты чатики в Slack и почта, заведите себе отдельный канал для новостей и ежемесячный дайджест с помощью email-рассылки. Самое главное, что следует помнить и понимать люди разные, и информацию они предпочитают получать по-разному. А еще люди не пользуются сервисами, которые им неудобны. Даже если начальник заставляет.

Поэтому нельзя рассчитывать, что вашу рассылку прочтут 100% нуждающихся в информации коллег, а чатик в Slack не будет на Mute у половины аудитории. А значит, нужно создавать столько каналов информирования, сколько возможно. Как у нас говорят чтобы из каждого утюга звучало. Тогда есть какие-то шансы достучаться до каждого сотрудника, предоставить ему информацию тем способом, которым он готов ее получать.

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

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

Так а сами-то вы что делаете?

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

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

Блог базы знаний и Blog Yellow Pages

Все знают, что в каждом спейсе Confluence есть такая сущность, как Блог? А кто из вас им пользуется?

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

На блог можно подписаться. Тогда о каждом новом посте вам будет падать уведомление в почту.

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

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

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

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

Мы назвали этот ресурс Blog Yellow Pages, и теперь любой заинтересованный в конкретной теме сотрудник может зайти и посмотреть последние новости по интересующей сфере бизнеса или продукту.

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

В общем, как видите, ничего сложного. Коробочные возможности Confluence, 30 секунд, чтобы скопировать новость из соцсети, вставить ее в редактор блога и пометить нужными лейблами. Но это уже не только соцсеть, за которой не всем удобно следить.

Ежемесячный почтовый дайджест

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

В Exness почта использовалась мало. Вероятно, так сложилось исторически. Но никто не мешал (и не мешает сейчас) нам поработать над ее оживлением.

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

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

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

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

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

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

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

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

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

Онлайн-встречи с экспертами

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

Но как это сделать в условиях удаленки? Как добиться того, чтобы выступление эксперта не превратилось в Yet Another Webinar с говорящей головой и не очень хорошо подготовленной презентацией.

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

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

Имея в компании потребность в понимании различных наших продуктов, мы решили организовать проект, который назвали Live Updates. Это не совсем вебинар. И даже не столько вебинар, сколько полноценная мини-конференция в Zoom с использованием платформы для онлайн-опросников Slido.

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

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

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

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

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

Во время выступления мы продолжаем собирать вопросы от публики. Почему это делается не голосом или в чате Zoom? Slido решает сразу две проблемы.

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

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

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

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

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

В общем, добавляйте мероприятиям интерактива, и будет получаться не хуже, чем в офлайне!

А дальше что?

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

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

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

Не хотим knowledge managera! Что делать?

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

Итак, кто может заменить вам менеджера по управлению знаниями?

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

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

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

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

Подробнее..

Категории: Управление проектами , Управление персоналом , Митапы , It-компании , Блог компании exness , Управление знаниями , Knowledge management , Knowledge sharing , Внутренние коммуникации , Блог , Рассылка

Discovery бэклог как не упустить важное

18.09.2020 12:15:01 |

Автор: admin

Всем привет! Меня зовут Юля, я отвечаю за развитие продукта Social Trading в Exness. Немного обо мне. Работаю в продуктовой разработке восемь лет в роли продакта. Начинала заниматься этим, когда эта роль в российских компаниях так даже и не называлась. Сейчас мы вместе с командой делаем продукт, который позволяет трейдерам с небольшим опытом инвестировать на финансовом рынке. Если кратко, суть в том, что эти трейдеры копируют понравившиеся стратегии более опытных трейдеров.

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

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

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

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

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

Теперь расскажу, какие источники используем мы. Итак, поехали.

Первый пункт плана послушать клиента

Пожалуй, самый очевидный источник, но это не уменьшает его ценность.

Клиенты непрерывно делятся фидбеком: оставляют отзывы в сторах, комментарии в соцсетях и на форумах, пишут сообщения в службу поддержки. Может, проще оставить их без внимания, это ведь работа саппорта разбираться с обращениями клиентов? Или все-таки лучше выжать максимум из ситуации и взглянуть на это как на массовый, бесплатный канал получения идей в режиме 24х7? В Exness мы постоянно читаем, что пишут клиенты в сторах и в письмах в службу поддержки (стоим в копии переписки), имеем чат с саппортом и сразу фиксируем все идеи.

На а как получить фидбек клиентов по конкретному вопросу? Здесь помогут исследования лично, по телефону или online; глубинное интервью, опрос, UX-тестирование. Все зависит от задачи и наличия времени. Исследование можно легко провести самому online: множество сервисов вам в помощь или же попросить саппорт, продажи. Последние с радостью примут предложение, ведь какой sales откажется от позитивного повода для контакта с клиентом?

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

Так, одним из самых популярных пожеланий инвесторов было добавление Stop Loss и Take Profit (автоматическое закрытие инвестиции при достижении определенной суммы). Мы запустили эту фичу в августе. Посмотрим, как отразится это на общем уровне NPS, и какое пожелание будет в топе в сентябре.
Там же запускаем быстрые опросы инвестиционный профиль, предпочтения по рынкам и так далее.

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

Интервью проводим по фреймворку Job to be done, он позволяет получить максимум инсайтов юзера. Каждый раз узнаем массу нового, так как продукт развивается, а клиенты все разные, и они также развиваются вместе с нами.

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

Данные не умеют говорить, но задают вопросы

У продуктов обычно существуют целевые метрики, по которым измеряется его успех. Если метрик нет, то лучше сделать так, чтобы они появились. Метрики и цели по ним часто являются результатом каскадирования метрик компании, измерителями достижения цели продукта (например, в виде OKR, Objectives and Key Results) или же синтезом этих двух вещей. Например, число активных пользователей, время, проводимое в приложении одним пользователем за период, доход на одного пользователя, NPS.

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

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

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

Покажу на примере. Наша цель в 5 раз увеличить число активных пользователей (активный пользователь имеет открытую инвестицию на 7 день после регистрации и позднее). Мы смотрим на конверсию скачивания в первую инвестицию, сравниваем с аналогичным показателем в другом продукте Exness (мобильное приложение для самостоятельного трейдинга). Видим, что там конверсия в полтора раза выше, хотя по идее наш продукт более простой и направленный на массового потребителя. Начинаем смотреть глубже: для разных стран, разных типов трафика разница почти везде есть, особенно большая для рекламного трафика. Берем самую популярную страну и рекламный трафик, строим воронку по каждому шагу и видим, что самое большое отличие на шаге пополнения баланса. Встречаемся с коллегами, просим поделиться секретом успеха, и все оказывается просто. Все мы изначально внедрили стандартный процесс: клиент кликает в Сделать депозит, заполняет анкету о себе, прикрепляет документы, потом выбирает платежное средство. Коллеги сделали A/B тест, где просто поменяли местами эти шаги и сначала дали выбрать платежное средство. Пользователь на первом шаге видит, что есть удобный для него способ пополнения (клиентам это очень важно, так как в разных странах распространены совершенно разные способы). И дальше он уже готов потратить время на заполнение анкетных данных. А/В тест показал свой эффект, коллеги раскатали на всех. Уже через неделю мы запустили аналогичный тест у себя, который также показал статистически значимый прирост в конверсии.

Конкуренты формируют ожидания, или куда движется рынок

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

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

А что в это время делают ведущие digital-сервисы?

Ведущие локальные и мировые digital-сервисы также формируют привычный клиентам опыт и ожидания, даже если работают на другом рынке. Если клиент смог оплатить в Интернет-магазине одежды покупку через Apple Pay, он захочет оплатить также и бронирование отеля. Ну и не зря эти ведущие сервисы ведущие. У них можно черпать идеи по стандартным юзер-сценариям, таким как регистрация, онбординг, каталоги товаров/ услуг, платежные сервисы и так далее.

О чем могут рассказать коллеги

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

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

Стратегия компании

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

А что за продукт мы вообще строим

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

Сотрудничество внутри компании

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

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

Продуктовой команде тоже есть, что добавить

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

Подытожим

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

Ну и небольшие заметки по тому, как фиксировать идеи наилучшим образом:

Ориентироваться в списке из 200 идей сложно, поэтому лучше сразу систематизировать их по темам, инициативам, каким-то крупным логическим кускам;
Если изначально идея была сформулирована как проблема, то лучше зафиксировать наиболее четко смысл проблемы и рядом вариант решения в виде гипотезы. Когда начинаешь заниматься этой проблемой, может оказаться, что есть лучшее решение;
Любая задача делается не просто так, а чтобы, как мы уже говорили выше, прокачать какую-то метрику или в рамках стратегических инициатив. Мы прямо в документе сделали соответствующий раздел, где перечислили их. Он позволяет при добавлении идеи или проблемы заматчить ее с целями. И те идеи, которые не матчатся, сохраняются, но отдельно.

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

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

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

Подробнее..

Категории: Управление проектами , It-компании , Управление продуктом , Product management , Блог компании exness , Backlog , Управление бэклогом

Как скомпилировать Python

12.02.2021 16:06:23 |

Автор: admin

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

Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь PyInstaller-ом, а про честную Ahead-of-time компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат.

Объясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: Ahead-of-time (AOT), когда весь код компилируется до запуска программы и Just in time compiler (JIT), когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором.

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

Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart;
Just in time compiler: Lua, С#, Groovy, Dart.

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

Смотря на эту таблицу, можно заметить определенную закономерность: статически типизированные языки находятся в обеих строках. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично.

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

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

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

С апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в блоге проекта. А для компиляции используется еще одна утилита от тех же авторов mypyc. Погуглив немного, я нашел достаточно большую статью Путь к проверке типов 4 миллионов строк Python-кода про становление и развитие mypy (на Хабре доступен перевод: часть 1, часть 2, часть 3). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на go или на cython. В результате проект пошел по третьему пути написание своего AOT python-компилятора.

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

Думаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а mypy как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что mypyc может компилировать и не аннотированный код!

Функция bubble_sort

Для примера рассмотрим функцию сортировки пузырьком.Файл lib.py:

def bubble_sort(data):n = len(data)for i in range(n - 1):for j in range(n - i - 1):if data[j] > data[j + 1]:buff = data[j]data[j] = data[j + 1]data[j + 1] = buffreturn data

У типов нет аннотаций, но это не мешает mypyc ее скомпилировать. Чтобы запустить компиляцию, нужно установить mypyc. Он не распространяется отдельным пакетом, но если у вас установлен mypy, то и mypyc уже присутствует в системе! Запускаем mypyc, следующей командой:

> mypyc lib.py

После запуска в проекте будут созданы следующие директории:

.mypy_cache mypy кэш, mypyc неявно запускает mypy для разбора программы и получения AST;
build артефакты сборки;
lib.cpython-38-x86_64-linux-gnu.so собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension.

CPython Extension встроенный в CPython механизм взаимодействия с кодом, написанным на С/C++. По сути это динамическая библиотека, которую CPython умеет загружать при импорте нашего модуля lib. Через данный механизм осуществляется взаимодействие с модулями, написанными на python.

Компиляция состоит из двух фаз:

Компиляция python кода в код С;
Компиляция С в бинарный .so файл, для этого mypyc сам запускает gcc (gcc и python-dev также должен быть установлены).

Файл lib.cpython-38-x86_64-linux-gnu.so имеет преимущество перед lib.py при импорте на соответствующей платформе, и исполняться теперь будет именно он.

Ну и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл main.py с кодом запуска сортировки:

import libdata = lib.bubble_sort(list(range(5000, 0, -1)))assert data == list(range(1, 5001))

Получим примерно следующие результаты:

До

После

real 5.68

user 5.60

sys 0.01

real 2.78

user 2.73

sys 0.01

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

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

Функция sum(a, b)

Скомпилируем функцию суммы от двух переменных:

def sum(a, b):return a + b

Перед запуском компиляции я ожидал увидеть примерно следующий код на С:

int sum(int a, int b) {return a + b;}

Однако результат оказался cущественно иным (код немного упрощен):

PyObject *CPyDef_sum(PyObject *cpy_r_a, PyObject *cpy_r_b){return PyNumber_Add(cpy_r_a, cpy_r_b);}

Рассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса PyObject, по сути это внутренние CPython структуры. Далее компилятор должен сложить эти объекты, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc?

Как оказалось, все очень просто: он просит CPython самостоятельно сложить эти аргументы. Функция PyNumber_Add это внутренняя функция СPython, которая доступна из расширения, ведь СPython отлично умеет складывать свои объекты.

Взаимодействие CPython c Extension можно изобразить следующим диалогом:

А посчитай-ка мне функцию sum для A, B;

Хорошо, но скажи сначала, сколько будет A + B;

Будет С;

Хорошо, тогда держи ответ - С.

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

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

Функция sum(a: int, b: int)

Итак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во множественном взаимодействии CPython - Extension. Но как это побороть?

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

def sum(a: int, b: int):return a + b

Скомпилированный результат на C (немного очищенный):

PyObject *CPyDef_sum(CPyTagged cpy_r_a, CPyTagged cpy_r_b) {CPyTagged cpy_r_r0;PyObject *cpy_r_r1;cpy_r_r0 = CPyTagged_Add(cpy_r_a, cpy_r_b);cpy_r_r1 = CPyTagged_StealAsObject(cpy_r_r0);return cpy_r_r1;}

Главное, что можно заметить: функция существенно поменялась, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось.

Теперь CPyDef_sum получает на вход не указатели на PyObject, а структуры CPyTagged. Это все еще не int, но уже и не часть CPython, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция sum работает только с int и обойти аннотацию не получится.

Далее происходит вызов CPyTaggetAdd вместо PyNumber_Add. Это уже внутренняя функция mypyc. Если заглянуть в код CPyTaggetAdd, то можно понять, что там происходит проверка диапазонов значений a и b, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение:

if (likely(CPyTagged_CheckShort(left) && CPyTagged_CheckShort(right))) {CPyTagged sum = left + right;if (likely(!CPyTagged_IsAddOverflow(sum, left, right))) {return sum;}}

Таким образом, наш диалог CPython - Extension превращается из абсурдного в нормальный:

А посчитай-ка мне функцию sum для A, B;

Хорошо, тогда держи ответ С.

Функция bubble_sort(data: List[int])

Настало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для data:

def bubble_sort(data: List[int]):

Скомпилируем результат и замерим время сортировки:

Без компиляции

С компиляцией, без аннотации типов

С компиляцией и аннотацией типов

real 5.68

user 5.60

sys 0.01

real 2.78

user 2.73

sys 0.01

real 1.32

user 1.30

sys 0.01

Итак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального!

Пара слов о mypyc

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

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

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

Эти ограничения носят принципиальный характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код gcc отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока резутльт таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно 20 % модулей, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил.

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

Nuitka

Уже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы Nuitka сильно напоминает описанный выше. Разница заключается в том, что Nuitka компилирует Python модуль в С++ код, который также собирается в СPython Extension. Дополнительно существует возможность собрать весь проект в один исполняемый файл, тогда уже сам CPython подключается к проекту как динамическая библиотека libpython.

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

Завершение

Недавно один мой коллега высказал мнение, что mypy сильно усложняет ему жизнь: из текста ошибок невозможно понять, чего он от меня хочет, а анализатор из PyCharm немного лучше. Теперь я понимаю, что он недооценивает mypy. Так как он намного большее, чем просто синтаксический анализатор. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание mypy в пайплайн проекта инвестиция не только в поиск ошибок, но и будущий перфоманс приложения. Мне очень понравилось, что взаимодействие с CPython осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне наиболее безопасным (учитывая, что mypyc до сих пор в альфе). Конечно, использовать ли mypyc на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить mypyc, тем более, что сделать это просто, если вы уже используете mypy.

P.S.

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

Подробнее..

Категории: Python , Высокая производительность , Компиляторы , Блог компании exness , Compiler , Mypy , Nuitka

Apple WWDC 2020 что нового в тестировании iOS

03.07.2020 18:07:41 |

Автор: admin

Привет, меня зовут Сергей, и я тестирую iOS приложения в Exness. В конце июня 2020 г. закончилась очередная WWDC. Давайте разберемся, что же она принесла нового в мир тестирования iOS приложений.

Но вначале краткий исторический экскурс: Apple WWDC (WorldWide Developers Conference), или просто даб-даб, это конфа, которую Apple с конца восьмидесятых проводит в Калифорнии. В этом году конференция впервые прошла в онлайн-формате. И если раньше билеты разыгрывались в лотерее, и тем, кто не получил желанного email, оставалось довольствоваться видео с сайта https://developer.apple.com/videos/, то в этом году по понятным причинам других вариантов не было: видео смотрели все.
Итак, что же там можно было высмотреть по тестированию?
Сразу оговорюсь, что на WWDC 2020 не было какой-то большой общей сессии, посвященной тестированию в экосистеме Apple, как в прошлые годы (Testing in Xcode 2019 и Whats new in testing 2018, 2017). Новинки тестирования в 2020 размазали на шесть мини-сессий. Поехали!

XCTSkip для ваших тестов

В Xcode 11.4 добавили новый API для управления запуском тестов в зависимости от условий XCTSkip.
Часто в тестах, особенно интеграционных, есть условия или требования, которые нелегко замокать. Например, приложение имеет какой-то специфический функционал для айпада, который не работает на айфоне. Или какие-то фичи для конкретной версии операционной системы.
И раньше, когда тесты доходили до подобных кейсов (проверка айпад-only функционала на iPhone), стоял выбор:

Закончить выполнение тестового набора;
Пометить тест как пройденный и пойти дальше;
Зафейлить тест.

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

Подробнее тут и тут.

Обработка прерываний и алертов в UI тестах

Обработка прерываний и алертов была в XCTest и раньше, однако в сессии механизм его работы был раскрыт более подробно. Мне показалась интересной новая функциональность, добавленная в Xcode 11.4, iOS/tvOS 13.4 и macOS 10.15.4, а именно, сброс пермишенов (aka protected resources).
Суть в следующем: если раньше вы, например, в тесте #1 дали приложению доступ к камере или контактам, то потом, в тесте #2, #n этот доступ так просто не отобрать. Чтобы сделать это, придется переустанавливать приложение.
Теперь с помощью API для сброса авторизации для protected resources можно отобрать ранее выданный доступ:

Class XCUIApplication {open func resetAuthorizationStatus(for: XCUIProtectedResource)}

Сброс настроек для пермишенов заставляет приложение вести себя так, как будто оно ни разу до этого не запрашивало у пользователя доступ к protected resources.
Это позволяет пройти все пути с выдачей и забором пермишенов для контактов, календаря, фото, микрофона, камеры и геолокации. На iOS еще дополнительно можно сбросить доступ к Bluetooth и Keyboard network access, а начиная с Xcode 12 / iOS 14, к данным Health. На Mac OS можно сбросить доступ к директориям Desktop и Downloads.
Ниже пример, как сбросить доступ приложения к фото:

// Examplefunc testAddingPhotosFirstTime() throws {let app = XCUIApplication()app.resetAuthorizationStatus(for: .photos)app.launch()// Test code...}

Важно помнить, что часто (но не всегда) при сбросе пермишенов приложение убивается.

Подробнее тут, тут и тут.

Устраняем лаги анимации с помощью XCTest

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

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

Триаж и диагностика упавших тестов

Часто починка упавших тестов это боль, которая занимает много времени и ресурсов.
В Xcode 12 появится новое API, которое должно облегчить починку упавших тестов. API должно помочь быстрее ответить на вопросы: что, как, почему и самое главное где упало?
Если раньше после того, как тест упал, приходилось искать место падения в
Issue navigator или report navigator, то с Xcode 12 процесс поиска упростился: теперь место падения подсвечивается в самом тесте.
Ошибка с выделением серым цветом появляется, если строка обращается к какой-то другой строке в дальнейшем:

И красным цветом, если ошибка произошла непосредственно в этой строке:

Удобная новая фича открытие редактора кода не в отдельном окне, а прямо в report navigator:

Кроме того, в Xcode 12 добавился новый объект XCTIssue, который, помимо того, что инкапсулировал в себя данные об ошибках, которые ранее собирал в себе XCTest (сообщение, путь, номер строки и флаг Expected), теперь добавляет:

Distinct types;
Detailed description;
Associated error;
Attachments.

Подробнее тут и тут.

Пишите тесты для того, чтобы они падали

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

Используйте человекочитаемые сообщения в ассерt`ах:

Убедитесь, что используйте подходящий для вашей ситуации тип ассерt`а:

Unwrap'те optional'ы, чтобы ваши тесты падали, выбрасывая ошибку, а не крашились. Swift предоставляет несколько способов для этого, но в тестах, как правило, используют XCTUnwrap, который являет собой упрощение конструкции guard let.

Используйте waitForExistence() вместо sleep() для асинхронных ожиданий.

Используйте XCTContext.runActivity() для повышения читабельности лога выполнения теста:

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

Подробнее тут.

Получайте результат тест рана быстрее

Обидно, когда утром в понедельник вы обнаруживаете, что запущенная в пятницу вечером длинная джоба так и не отработала до конца, зависнув на середине или вообще в самом начале. И вам предстоит начать рабочую неделю с разбора полетов: почему это произошло? Как избежать подобной ситуации в будущем? ~~Как я мог спустить девять тысяч на коктейли за один вечер?~~
В Xcode 12 появились инструменты для защиты от зависаний. Это новая опция тест плана Execution Time Allowance.
Когда опция включена, Xcode устанавливает временной лимит исполнения каждого теста.
Если лимит превышен, Xcode делает следующее:

Собирает отчет (spindump);
Убивает зависший тест;
Перезапускает тест раннер, чтобы оставшаяся часть сьюта смогла выполниться.

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

Еще это можно сделать опцией команды xcodebuild:

xcodebuild option-default-test-execution-time-allowance <seconds>

Аналогично можно задать максимальное время выполнения теста:

xcodebuild option-maximun-test-execution-time-allowance <seconds>

Даже если вам нужно задать время выполнения для какого-то конкретного теста или тестового класса, то это тоже возможно с помощью executionTimeAllowance API:

Class XCTestCase: XCTest {var executionTimeAllowance: TimeInterval // с округлением до минуты}

Точная настройка выполнения того или иного теста позволит вам сэкономить время, но и это еще не все, что можно сделать для ускорения прохождения длинного тест сьюта.
Xcode 12 позволяет запускать тесты на нескольких девайсах одновременно. Эту фичу назвали Parallel Distributed Testing. Польза от запуска тестов на нескольких девайсах очевидна приличная экономия времени.

Но, к сожалению, есть и подводные камни: порядок запуска тестов в параллели не детерминирован, нет никакой гарантии, что на девайсе #1 после теста номер 5, будет выполнен тест номер 6. Этот факт обязательно нужно учитывать при планировании запуска тестов с помощью Parallel Distributed Testing.
Вообще идея запусков тестов в параллели не нова. Такая возможность была и до Xcode 12, но именно в Xcode 12 появилась возможность запускать тесты на реальных девайсах (пока только с помощью xcodebuild).

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

xcodebuild test    -project MyProject.xcodeproj    -scheme MyProject    -parallel-testing-enabled YES    -parallelize-test-among-desinations    -destination 'platform=iOS,name=iPhone 11'    -destination 'platform=iOS,name=iPad pro'

Подробнее тут.

На этом обзор новых тесто-фич с WWDC 2020 закончен. Спасибо, что дочитали до конца. Надеюсь, эта статья будет вам полезной. Happy testing!

Подробнее..

Категории: Разработка под ios , Тестирование мобильных приложений , Ios разработка , Swift , Wwdc 2020 , Блог компании exness

Токсичный руководитель казнить нельзя помиловать

31.07.2020 14:18:55 |

Автор: admin

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

У медали всегда две стороны. Одна из статей на Хабре на эту тему задает важный вопрос: до какой степени стоит щадить нежную душу коллеги, который не справляется со своей задачей? Будет ли комментарий в Jira: Сделано плохо, сейчас же переделать рассматриваться как признак токсичности? Что делать организации, когда незрелые сотрудники не могут сработаться с жестким, требовательным руководителем?

Последние несколько лет тема токсичности в командах разработки приобрела размах и популярность, хотя применительно к менеджменту термин токсичного поведения появился в Америке еще в 90-х. "Темная сторона лидерства" была признана частой проблемой управления с деструктивным влиянием на бизнес в целом. Интерес к токсичному управлению побудил теоретиков изучить модели такого поведения и искать способы нейтрализовать его в рамках организации. Одна из теорий, например, базируется на трех составляющих: (1) личностные характеристики руководителя, (2) так называемые последователи и (3) окружение, позволяющее подобное поведение. В исследованиях также можно встретить положительные, хотя и краткосрочные эффекты такого лидерства и массу советов организациям в таких случаях.

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

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

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

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

А что скажет сторона ответчика?

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

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

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

Токсично или нет? Попробуй на вкус!

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

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

До сих пор не существует объективного механизма по определению степени токсичности в поведении менеджера, однако есть процессы, помогающие указать на негативные тенденции в организации:

1. Регулярный и обязательный сбор обратной связи по методу 360.

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

Сделайте опрос регулярным и неизбежным, раз в 3 или 6 месяцев, и со временем сотрудники привыкнут к возможности сказать свою правду хоть куда-то;
Вопросы и индикаторы должны быть известными и постоянными, чтобы каждый раз не было сюрпризов, что сейчас хотят услышать о сотрудниках;
Не HR владеет процессом, а менеджмент: продвигает, дает обратную связь и принимает некомфортные решения. Если же отношение к 360 как к очередному нововведению, нужному только для HR, это не будет работать;
Иногда поможет полная анонимность, когда даже технически невозможно определить респондента. Однако будьте осторожны, чтобы не превратить 360 в анонимные жалобы и сплетни без подтверждения фактов, что еще больше навредит вашей культуре;
И обязательный элемент, который нельзя пропускать ни в коем случае обратная связь тем, на кого собирался фидбэк, и принятие соответствующих решений.

2. Исследования вовлеченности (engagement survey)

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

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

3. Опросы типа Пульс

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

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

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

4. Научные шкалы токсичности

Например, Шкала токсичности от Эндрю Шмидта, который предложил методику и опросник определения токсичности в команде.

В своем опросе Шмидт основывается на пяти признаках токсичного руководителя, таких как: нарциссизм, самореклама, жесткость управления, непредсказуемость и авторитарное лидерство. Кстати, нарциссизм является чуть ли не основным визуальным признаком токсичного лидера: идеальный внешний вид, излишняя самоуверенность и самовлюбленность, что можно заметить даже на собеседовании с таким руководителем и сделать соответствующие выводы.
Опрос представляет собой набор утверждений о поведении руководителя с 6-ти бальной шкалой, что позволяет избежать тенденции центральных оценок. Одной из сложностей проведения такого опроса является невозможность объяснить такому руководителю, почему задаются подобные странные вопросы за его спиной (например, Мой руководитель думает, что он умнее других). Однако при исследовании токсичности конкретного менеджера можно проводить интервью, используя те же утверждения и получая ответы в реальном времени.

5. Whistleblowing процедуры и анонимные каналы обратной связи

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

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

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

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

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

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

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

Подробнее..

Категории: Управление персоналом , Карьера в it-индустрии , Управление разработкой , Блог компании exness , Токсичный руководитель , Токсичный персонал , Whistleblowing , Метод 360 , Шкала токсичности , Пульс-опросы , Engagement survey , Треугольник карпмана

Кому на рынке труда жить хорошо? Или записки рекрутера в 2020-м году

09.11.2020 16:20:11 |

Автор: admin

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

Меня зовут Аня, я занимаюсь поиском талантов уже более шести лет, последние три из них в сфере IT. Сейчас я часть замечательной команды Talent Acquisition в Exness. В этой статье хочу поделиться своими мыслями и некоторыми рекомендациями с ракурса человека, ежедневно вступающего в переговоры с кандидатами на совершенно разные роли и знающего, что происходит сейчас с требованиями к соискателям, и как они сами себя ощущают. Моя цель предупредить и вооружить. Не так пафосно и драматично, но всё же =) Давайте обо всём по порядку.

За 5-6 лет до (краткий экскурс в ситуацию прошлых лет)

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

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

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

Кто виноват? (текущая ситуация)

Итак, если продолжить тему про молодых специалистов, можно отметить, что количество вакансий для них упало, если даже сравнивать начало 2019-го и 2020-го годов. К примеру, крупная хантинговая платформа hh.ru приводит в своих исследованиях следующий график:

Здесь мы видим, что количество вакансий упало на 34% относительно прошлого года и теперь значительно ниже количества кандидатов. Это создаёт проблему поиска работы для людей в возрасте 22-25 лет, чего не было в предыдущие годы.

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

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

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

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

Что делать?

Как отмечает Алёна Владимирская (известный хедхантер России) в одном из своих интервью, если вы чувствуете, что относитесь к группе риска, и ваше положение в компании уязвимо, самое время составлять план по поиску работы, если не уверены, действия те же. Ссылка на интервью, кому интересно.

Но какие сферы бизнеса стоит рассмотреть сейчас? Кто будет расти в текущих условиях?

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

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

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

Также растёт спрос на антикризисных специалистов, юристов, занимающихся банкротствами.

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

Из наблюдений за настроем кандидатов

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

Можно отметить, что многие сейчас не готовы менять работу. Если на текущем месте пока всё более-менее стабильно, люди не очень охотно идут на контакт и рассматривают новые возможности. Также до пандемии мы активно релоцировали людей из разных стран, чаще всего из России, Украины, Беларуси, но сейчас это делать сложнее. И есть тенденция к более осторожному отношению к переезду: многие не готовы релоцироваться из-за нестабильной ситуации в мире и закрытия границ. Оживление, пожалуй, мы наблюдаем среди кандидатов из Беларуси и, например, Ливана, но это связано с политическими и экономическими проблемами в этих странах. В целом же, соискатели стали более пассивными.

Часть последняя, заключительная

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

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

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

Как мы видим, всё не так страшно, и есть-таки луч света в тёмном царстве и способы не выпасть из обоймы.

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

Автор статьи: Анна Михайловская, Talent Specialist в Exness.

Подробнее..

Категории: Управление персоналом , Карьера в it-индустрии , Карьера в it , Карьера программиста , Блог компании exness , Карьера ит-специалиста

Биткоин и криптовалюты перспективы в условиях современной финансовой системы

16.07.2020 16:05:50 |

Автор: admin

Уже три года прошло с того момента, когда биткоин пробил историческую отметку в 3000 долларов и устремился штурмовать новые максимумы, создав волну хайпа вокруг криптовалют. Известно, что появление новой технологии сначала создает ажиотаж, приводящий к появлению финансового пузыря, затем, через несколько лет начинается реальное развитие технологии: так было, например, с интернет-компаниями. Что мы можем сказать про блокчейн и криптовалюты сегодня, в 2020 году?

Здесь уместно разделить развитие блокчейн-технологий и статус биткоина как инструмента для альтернативных инвестиций.

Блокчейн-технологии

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

Большие компании, такие как Amazon, IBM и Walmart, ищут варианты использования блокчейна в цепочке поставок, управления данными и администрировании проектов. Согласно информации TechCrunch, найм специалистов по блокчейн-технологиям вышел на второе место по динамике роста.

Интересный тренд наблюдается в развитии так называемых Baas-проектов (Blockchain as a service), когда пользователи могут строить свои блокчейн-сети на базе существующих решений. Так, например, Amazon и Microsoft уже предлагают решения Baas своим пользователям.

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

Основным препятствием для развития индустрии остается регулирование со стороны государства: обращение криптовалют пока связано с нехваткой законодательной базы и отсутствием контроля. Случай с блокчейном TON от Telegram широко известен в индустрии: сама компания Павла Дурова была оштрафована со стороны комиссии по ценным бумагам США на 18.5 миллионов долларов, и собранные с инвесторов средства в размере 1.2 миллиарда долларов было предписано вернуть инвесторам. Проект Meta 1 Coin был также заморожен SEC в марте 2020 года. Также рынок до сих пор помнит историю проекта Libra, который был запущен компанией Facebook в сотрудничестве с другими компаниями, как, например, Visa, Spotify и Shopify. Вследствие критики властей, Facebook и Visa были вынуждены дистанцироваться от проекта.

Биткоин как актив

Наблюдая за поведением биткоина по время обвала рынков в марте 2020 года, можно отметить, что несмотря на падение котировок BTCUSD до уровня 4500, биткоин достаточно быстро восстановился, и случилось это быстрее, чем восстановление фондового рынка США, однако уровень в 10000 преодолеть он пока не смог. Так или иначе, игроки рынка обрели уверенность в том, что спрос на биткоин существует, и равновесная цена в 10000 пока держится довольно стабильно.

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

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

Начиная с февраля, эмиссия американского доллара составила около 4 триллионов долларов: так ФРС поддержала упавший потребительский спрос в США во время кризиса Covid-19. Процентные ставки по доллару США также опустились практически до нулевого значения, что подогревает интерес как к традиционным, так и альтернативным инвестициям.

Другой известный инвестор, Уоррен Баффет, наоборот, пессимистично смотрит на биткоин и его перспективы: по его заявлению, биткоин не обладает какой-либо стоимостью и с ним нельзя делать ничего другого, кроме как продать кому-то. В то же время известно, что Уоррен Баффет встречался с представителями крипто индустрии в феврале 2020 года: например, с главной Tron Джастином Саном и другими крипто боссами.

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

Развитие производных инструментов

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

Так, по информации из отчета Tokeninsight, только в первом квартале 2020 года оборот торгов по фьючерсам на биткоин достиг $2.1048 триллиона, что составляет рост более чем на 300% по сравнению со средним значением за 4 квартала 2019 года.

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

Для тех же, кто не планирует заниматься спекуляциями, а хотел бы хеджировать свои криптовалютные портфели, развитие рынка фьючерсов тоже полезно, поскольку ранее существовал только один надежный инструмент хеджирования фьючерс на биткоин на бирже CME. Он, однако, является довольно дорогим решением: размер контракта в 5 биткоинов и гарантийное обеспечение в 50% от суммы контракта (около $25000 по состоянию на июль 2020) не позволяет многим игрокам рынка работать с его помощью.

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

Другие криптовалюты

Что происходит с другими криптовалютами летом 2020 года?

Многие альткоины так и не оправились после жесткой посадки 2018 года, спровоцированной обвалом биткоина. На графике ниже представлена сравнительная динамика BTC, ETC, ETH и XRP. Пока мы видим, что единственной альтернативной криптовалютой биткоину является Etherium. Именно поэтому некоторые криптовалютные биржи предоставляют возможность торговать фьючерсами на него.

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

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

Выводы

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

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

Подробнее..

Категории: Финансы в it , Криптовалюты , Блог компании exness , Блокчейн , Биткоин , Btcusd

Волки не с Уолл-стрит как миллениалы развернули рынок, и что к этому привело

01.10.2020 14:20:35 |

Автор: admin

Привет сообществу! Меня зовут Станислав, я занимаюсь торговлей на финансовых рынках (фондовый, срочный и валютный рынок) более 15 лет и в блоге буду рассказывать вам интересные истории из мира финтеха и индустрии трейдинга. Stay tuned.

Брокерская индустрия сегодня находится на волне серьезных перемен и это уже не просто красивая метафора, а реальность, которая вплетается в жизнь далеких от финансовых рынков людей. Если еще вчера термины брокер и биржа вызывали устойчивую ассоциацию с людьми в черных пиджаках и галстуках, то сегодня уже не только миллениалы (люди, рожденные между 1981 и 1996 годом), но и представители поколения Z (тем, кому сейчас немногим больше двадцати лет) осваивают финансовые рынки. И не только осваивают, но и бьют профессионалов с Уолл-стрит в их собственной игре. Как это возможно?

Об этом мы и поговорим в сегодняшней статье.

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

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

До 2000-х годов взаимодействие клиента с брокером происходило по телефону. Вы наверняка помните кадры из фильма Волк с Уолл-стрит, которые показывали всю степень цинизма брокеров и незащищенность простых, далеких от финансового рынка клиентов. Далее, коммуникации стали осуществляться через Интернет и торговые терминалы (программы для отправки заявок). Развитие технологий снизило порог входа на финансовые рынки: скоростной Интернет и повышение производительности серверов позволили брокерам обрабатывать огромное количество небольших клиентских заявок за доли секунды, а удаленное открытие клиентских счетов позволило упростить подключение новых клиентов к торговым системам. Как это повлияло на финансовый рынок?

Умные деньги против обычных

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

Кадр из фильма Волк с Уолл-стрит (Источник: Pinterest.ru)

Индустрия хедж-фондов в конце 20-го века приобрела большую популярность: выпускники университетов Лиги плюща стремились работать в одном из подобных фондов и стать частью умных денег. На самом деле, результативность умных денег вовсе не такая высокая как принято считать (большинство активных управляющих и вовсе проигрывают доходности фондового индекса на большой дистанции). Однако, наблюдения показывают, что эмоциональные решения и реакция на новости больше присущи частным инвесторам, в то время как умные деньги строят свои стратегии, чаще основываясь на фундаментальных оценках. Об этом говорят исследования рыночного сентимента, проводимые CNN.com. Массовый интерес к активам со стороны большинства участников рынка наблюдается вблизи рыночных пиков.

Источник: сnn.com

Есть, конечно, исключения и из этого правила. Например, недавно стало известно, что японский Softbank покупал опционы на инструменты фондового рынка беспрецедентно большими объемами в конце августа 2020 года, непосредственно перед падением, и это далеко не первый пример поведения этого игрока: в декабре 2017 года он занял большую позицию по биткоину прямо перед его падением и зафиксировал убыток в 160 миллионов долларов уже зимой 2018 года. Поэтому величина не обязательно дает возможность заглянуть в будущее.

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

Лавина ETF

Либерализация финансовых рынков началась с появления инструментов коллективного инвестирования. Сначала это были взаимные фонды (Mutual funds), но они были и остаются доступны только для граждан США. Революцией, которую никто не заметил, стало появление так называемых биржевых фондов, или exchange traded funds (ETF). Их суть довольно проста: приобретая долю такого фонда на бирже за несколько сотен долларов, частный инвестор получает возможность следовать за доходностью фондового индекса или повторять какую-либо стратегию, которую исполняет менеджер фонда (например, инвестирование в облигации или товарный рынок). Средства пайщиков фонда соединяются вместе и составляют единый пул, который уже инвестируется в ценные бумаги.

Самый известный ETF, который носит название SPY (его еще называют спайдером), следует за доходностью индекса S&P500 (самый известный фондовый индекс США) и был запущен в 1996 году. На сегодняшний момент его чистые активы составляют более 300 миллиардов долларов.

Рост активов под управлением фонда SPY (Источник: ycharts.com)

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

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

Рост фондового индекса S&P500 (Источник: macrotrends.net)

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

Если вы смотрели фильм Игра на понижение (Big Short), вы помните одного из ключевых персонажей, доктора Майкла Бурри, который предсказал мировой финансовый кризис 2008 года. В конце 2019 года он дал интервью Bloomberg, в котором рассказал, что видит надувающийся пузырь на рынке ETF, который может вызывать серьезные последствия на рынке.

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

По мнению доктора Бурри, есть два потенциально опасных следствия из этого процесса: во-первых, усиление пассивных стратегий (а следование за индексом называют пассивной стратегией) приводит к стихийному росту цен на акции, которые входят в фондовый индекс: при этом никого из инвесторов ETF не волнует качество бизнеса компаний, акции которых входят в индекс. Они просто их покупают, потому что индексы растут, вызывая самоисполняющееся пророчество. Мы это хорошо видим сегодня, наблюдая безудержный рост акций Apple, Microsoft и Amazon (именно они составляют от 15% до 30% доли индексных ETF). В них деньги сегодня не инвестируются, а паркуются. Это вызвано, конечно, не только ETF-инвесторами, но они вносят свою посильную долю в этот процесс.

Рост технологических акций (Источник: Tradingview.com)

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

Революция Robinhood

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

Известное в США мобильное приложение Robinhood, запущенное в 2014 году, получило необычайную популярность за последние несколько лет, особенно среди молодежи. Идеология приложения отсутствие комиссий и некий бунтарский дух противопоставления нового старому. Старый мир в этом контексте представляют скучные люди в пиджаках, транслирующие устаревшие ценности, а новый мир люди Интернета и соцсетей. Маркетологи эксплуатируют этот конфликт уже давно: компания Apple, например, когда-то выпустила рекламу, представляющую компанию IBM в виде тоталитарного оруэлловского большого брата. Сегодня старый мир начинает уступать позиции и в брокерском бизнесе.

Отсутствие комиссий в приложении Robinhood объяснялось большим охватом аудитории приложения и возможностью зарабатывать на премиум-подписках (за 5$ в месяц можно получить доступ к маржинальной торговле и другие опции).

Источник: robinhood.com

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

Пользователи Robinhood, как и полагается поколению соцсетей, вовсе не разобщены, а вполне себе управляются блоггерами из Youtube, Twitter, TikTok и ведущими частных каналов в Slack, Telegram и других мессенджерах. Ведущие соответствующих каналов не имеют степени CFA и других регалий финансового рынка, а просто выражают свое мнение на онлайн-трибунах, и убедительней всех выглядит тот, кто звучит уверенно и говорит на одном с публикой языке.

Например, философия Stocks only go up (Акции только растут в цене) активно продвигается одним из топовых рыночных блоггеров Дэйвом Портным, за которым в настоящее время следует почти 2 миллиона подписчиков. Многие стараются действовать аналогично.

Источник: Twitter.com

По данным Robintrack.net, пользователи Robinhood во время биржевого краха 2020 года, вызванного пандемией коронавируса, вели себя почти как единый фонд, который покупает упавшие в цене акции, вызывая рост их цены: их интересовали не только акции технологических гигантов, но и компании, готовящиеся к банкротству (Hertz, JC Penny и др.). Акции авиалиний, которые терпели большие убытки, тоже стали целями трейдеров из Robinhood.

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

График цены акции Hertz (Источник: tradingview.com)

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

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

Если посмотреть на логику принятия решений пользователями Robinhood с помощью сайта Robintrack.net, становится понятно, что они покупают все тот же набор технологических акций (Apple, Microsoft, Amazon) и акции стоимостью около 10 долларов. Почему 10 долларов? Потому что они дешевле.

Таблица лидеров популярности среди пользователей приложения Robinhood (Источник: Robintrack.net)

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

Выводы

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

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

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

Подробнее..

Категории: Финансы в it , Акции , Блог компании exness , Фондовый рынок , Финтех , Robinhood , Финансовый рынок , Трейдинг , Etf , Aapl , Tsla , Миллениалы

	Русский
	English

Блог компании exness

В чем проблема?

Как это можно исправить?

Как я применил этот опыт в Exness?

Пример

Какая польза от диаграмм?

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

Процесс выбора

Самостоятельная подготовка

Собеседование

Калибровка результатов

Talent Pool

Программа развития

Программа базового менеджмента

Программа операционного менеджмента

IDP (Individual Development Plan)

Уроки и советы

У нас в компании никто ничего вовремя не узнаёт...

Кому реально надо, тот и так узнает!

Это все долго и сложно. Лучше фичи быстрее пилить!

Куда писать? Чем пользоваться?

Так а сами-то вы что делаете?

Блог базы знаний и Blog Yellow Pages

Ежемесячный почтовый дайджест

Онлайн-встречи с экспертами

А дальше что?

Не хотим knowledge managera! Что делать?

Первый пункт плана послушать клиента

Данные не умеют говорить, но задают вопросы

Конкуренты формируют ожидания, или куда движется рынок

А что в это время делают ведущие digital-сервисы?

О чем могут рассказать коллеги

Стратегия компании

А что за продукт мы вообще строим

Сотрудничество внутри компании

Продуктовой команде тоже есть, что добавить

Подытожим

Функция bubble_sort

Функция sum(a, b)

Функция sum(a: int, b: int)

Функция bubble_sort(data: List[int])

Пара слов о mypyc

Nuitka

Завершение

P.S.

XCTSkip для ваших тестов

Обработка прерываний и алертов в UI тестах

Устраняем лаги анимации с помощью XCTest

Триаж и диагностика упавших тестов

Пишите тесты для того, чтобы они падали

Получайте результат тест рана быстрее

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

А что скажет сторона ответчика?

Токсично или нет? Попробуй на вкус!

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

Умные деньги против обычных

Лавина ETF

Революция Robinhood

Выводы

Категории

Последние комментарии