Недавно я покинул уютные объятия Фейсбука, за время моего существования превратившегося в Мету. К счастью успел продать последний Транш RSU по 350 , перед их обвалом до 305, известный в узких кругах эффект ухода Валеры
Лондон однако решил не покидать и в середине декабря начал работать Head of Data Science в Blockchain.com
Правда сейчас я скорее себя чувствую Head Of Data Engineering и Analytics, так как в DS в блоке входят инженерия данных, продуктовая аналитика, BI и машинное обучение. Как завещал знаменитый продолжатель пирамидостроения - сначала необходимо реализовать базовые потребности
Буду время от времени писать сюда свои мысли, наблюдения и статьи, которые мне показались интересными
Лондон однако решил не покидать и в середине декабря начал работать Head of Data Science в Blockchain.com
Правда сейчас я скорее себя чувствую Head Of Data Engineering и Analytics, так как в DS в блоке входят инженерия данных, продуктовая аналитика, BI и машинное обучение. Как завещал знаменитый продолжатель пирамидостроения - сначала необходимо реализовать базовые потребности
Буду время от времени писать сюда свои мысли, наблюдения и статьи, которые мне показались интересными
👍27❤1
После работы в больших корпорациях и стартапах, я начал работать в чем-то среднем, уже не стартап, но еще не корпорация и как следcтвие, набросал следующее
A note about redundancy and efficiency in the Data Science department
In theoretical computer science, the CAP theorem states that any distributed data store can only provide two of the following three guarantees:
Consistency - Every read receives the most recent write or an error.
Availability - Every request gets a (non-error) response without the guarantee that it contains the most recent write.
Partition tolerance - The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.
When a network partition failure happens, it must be decided whether to cancel the operation and thus decrease the availability but ensure consistency or proceed with the operation and therefore provide availability but risk inconsistency.
I review the team structure as very close to this, but with different criteria: efficiency and redundancy. As computer science describes, redundancy means having extra or duplicate resources available to support the primary system. It is a backup or reserve system that can step in if the primary system fails. The reserve resources are redundant as they are not being used if everything is working correctly.
What does it mean to the team structure? From what I have seen, the company usually evolve from being efficient to becoming redundant. However, neither being too efficient nor too redundant is good.
Why being too efficient is not good?
If you are too efficient and cover many things with few people, you are at risk. If something happens to these people - the company is in trouble. If your team is 100% efficient and something critical happens - the team cannot cover it. Otherwise, the team is not 100% efficient. The team member does not have time to relax, and the team is relaxed. When people are relaxed, they become curious, explore, come up with new ideas, develop new skills, and be happy overall.
Why being too redundant is not good?
I found that the most challenging in life is to keep balance. Redundance is good - it provides reliability, security, room for improvement and a margin to outlast the crisis. However, too much redundancy creates sloppiness, bad team flow and repel top performers, as it deteriorates the overall vibe and feeling of doing a meaningful and impactful job.
Thus we need to keep the right balance between efficiency and redundancy.
A note about redundancy and efficiency in the Data Science department
In theoretical computer science, the CAP theorem states that any distributed data store can only provide two of the following three guarantees:
Consistency - Every read receives the most recent write or an error.
Availability - Every request gets a (non-error) response without the guarantee that it contains the most recent write.
Partition tolerance - The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.
When a network partition failure happens, it must be decided whether to cancel the operation and thus decrease the availability but ensure consistency or proceed with the operation and therefore provide availability but risk inconsistency.
I review the team structure as very close to this, but with different criteria: efficiency and redundancy. As computer science describes, redundancy means having extra or duplicate resources available to support the primary system. It is a backup or reserve system that can step in if the primary system fails. The reserve resources are redundant as they are not being used if everything is working correctly.
What does it mean to the team structure? From what I have seen, the company usually evolve from being efficient to becoming redundant. However, neither being too efficient nor too redundant is good.
Why being too efficient is not good?
If you are too efficient and cover many things with few people, you are at risk. If something happens to these people - the company is in trouble. If your team is 100% efficient and something critical happens - the team cannot cover it. Otherwise, the team is not 100% efficient. The team member does not have time to relax, and the team is relaxed. When people are relaxed, they become curious, explore, come up with new ideas, develop new skills, and be happy overall.
Why being too redundant is not good?
I found that the most challenging in life is to keep balance. Redundance is good - it provides reliability, security, room for improvement and a margin to outlast the crisis. However, too much redundancy creates sloppiness, bad team flow and repel top performers, as it deteriorates the overall vibe and feeling of doing a meaningful and impactful job.
Thus we need to keep the right balance between efficiency and redundancy.
👍16🔥4
Недавно я улетал из Лондона и прилетал в Москву. На выходе из моего подъезда в Лондоне 5 декабря меня встречал сад. На выходе из Домодедово 5 декабря меня встречала колючая проволока. Два мира, два Шапиро
👍4
Сегодня я проснулся в 5 утра по Москве, что для меня все еще ощущается как два часа ночи по Лондону чтобы поехать в аэропорт и улететь в Казань. Казань я очень уважаю, правда лучше конечно туда летать летом, а не зимой. Впрочем летом почти везде лучше чем зимой, не считая Дубая.
В Казань я лечу чтобы затем поехать в Иннополис на первое образовательное шоу IT Nights. В прямом эфире расскажу об инженерных уровнях и оценке разработчиков. Покажу, как этим пользоваться для того, чтобы расти в грейдах. Из необычного, на меня обещали навесить датчики, регистрирующие пульс и какие-то еще параметры и пугать в прямом эфире во время моего выступления, чтобы оценить как я это перенесу. Даже спросили чего боюсь.
Когда мне было 14 лет, я провел все лето в пионер лагере, в котором не было пионеров. Каждое утро пацаны из моей палаты ставили песню группы многоточие, которая начиналась с фразы: Для всех кто знает что такое потеря, тем, кто прохавал жизнь с самого низа. С тех пор я не боюсь никого, ничего. Кроме себя самого. Поэтому предложил вместо пугалок дать мне гантель или любой другой снаряд и в неожиданные моменты просить что-то с ней делать.
Ребята подготовили от меня промокод babushkin на 30%. Подключайтесь и смотрите выступление на www.it-nights.ru
Правда я не знаю какие в итоге опыты будут ставить на мне в прямом эфире.
В Казань я лечу чтобы затем поехать в Иннополис на первое образовательное шоу IT Nights. В прямом эфире расскажу об инженерных уровнях и оценке разработчиков. Покажу, как этим пользоваться для того, чтобы расти в грейдах. Из необычного, на меня обещали навесить датчики, регистрирующие пульс и какие-то еще параметры и пугать в прямом эфире во время моего выступления, чтобы оценить как я это перенесу. Даже спросили чего боюсь.
Когда мне было 14 лет, я провел все лето в пионер лагере, в котором не было пионеров. Каждое утро пацаны из моей палаты ставили песню группы многоточие, которая начиналась с фразы: Для всех кто знает что такое потеря, тем, кто прохавал жизнь с самого низа. С тех пор я не боюсь никого, ничего. Кроме себя самого. Поэтому предложил вместо пугалок дать мне гантель или любой другой снаряд и в неожиданные моменты просить что-то с ней делать.
Ребята подготовили от меня промокод babushkin на 30%. Подключайтесь и смотрите выступление на www.it-nights.ru
Правда я не знаю какие в итоге опыты будут ставить на мне в прямом эфире.
👍7🤣3❤1
В России мне посчастливилось поработать в нескольких компаниях гигантах на очень интересных позициях. Интересны они были смесью высоты и новизны , приправленные необходимостью делать что-то новое. Например, в Х5 моим Боссом был Управляющий Директор Х5 Технологии, а скип менеджером СЕО. Нужно было немного-нимало помочь выстроить МЛ и Дата Аналитику с нуля. Как говорил Черномырдин: что бы мы ни делали — получается одно и то же: либо КПСС, либо автомат Калашникова. В моем случае чтобы я ни делал, получаются еще и А/Б тесты
Если бы меня попросили описать мое положение в Фейсбуке, я бы использовал гениальную фразу своего польского коллеги, когда он в далеком 2013 году рассказывал в шутку про своего босса. Еще не начальник, а уже скурвился. Да, были какие-то команды, какой-то уровень ответственности и самостоятельности, но все же не то.
В Ноябре я смог наконец добраться до тех же позиций в Лондоне, что были у меня в Москве. Снова СЕО мой скип менеджер, вновь нужно делать что-то новое и отлаживать существующее и я уже вижу, как на горизонте маячит А/Б тестирование.
Уже на первых встречах я заметил разницу. Мы обсуждали какой-то функционал и прозвучала необходимость его реализовать. Моей первой реакцией было: так, наймем пять человек и за три месяца выкатим базовую версию, затем будем улучшать.
Мой босс сказал, значит купим API/сервис у компании, предоставляющей эти услуги
Хорошо, что я промолчал и решил послушать, а затем и подумать. Множество вещей, которые различные компании делают уже не первое десятилетие и продают как сервис, в тех компаниях, в которых работал, покупали далеко не всегда. Вместо этого делали свой сервис или свой продукт. Чаще чем хотелось бы выходило криво, косо, дорого. Бывало, никто этим еще и не пользовался внутри компании, потому что криво и косо. Зато свое. Или пользовались и злились
С другой стороны, казалось бы, купил, пользуешься, пока это тебе нужно, смотришь какой именно функционал тебе нужен, какой не нужен и если очень хочется, то начинаешь делать свое, сначала как fallback, потом как замену, если вообще начинаешь. Конечно, некоторые вещи нужно делать исключительно внутри, например платформу А/Б тестирования или ценообразование, некоторые нужно дублировать для надежности, но далеко не все.
Я задумался, что же является причиной такого подхода, кроме понятной жадности любого менеджера в надежде заграбастать побольше людей, бюджетов, власти и естественное недоверие ко всему новому и лишь условно контролируемому? Одно из объяснений, пришедших мне в голову звучало так: Opex и Capex.
Дело в том, что существует два типа расходов, богоугодный Capex и нечестивый Opex. Если у компании есть 1 млрд рублей активами, это хорошо, увеличивает ее ценность и уверенность в завтрашнем дне. Представьте, что компания купила здание за 1 млрд рублей и поместила его на своей баланс. Баланс по-прежнему 1 млрд, а затраты компании на покупку здания были списаны в Capex. Если мы потратим 1 млрд рублей на зарплаты, это грустно, эти деньги навсегда покидают компанию и заставляют всех печально смотреть им вслед. С другой стороны, если мы наймем бригаду строителей и купим материалов, а затем построим здание, то их зарплаты мы можем тоже списать в Capex, ведь результатом их труда стало здание, которое мы поставили на баланс. Я думаю, вы сами можете продолжить логическую цепочку что так можно делать практически с чем угодно. Мне кажется, это может быть одной из причин бешеного спроса на IT специалистов, все делают свое и повторяют одно и тоже
У меня еще нет ответа, почему же там, где я сейчас, все по-другому. Возможно, скорость важнее, возможно, найм дольше, возможно, зарплаты выше (недавно рассказал зарплату стажера одному синьору, он долго горевал) и выгоднее сначала брать готовые сервисы, использовать их какое-то время и лишь потом принимать решение - делать свое или не нет, может быть дело в доверии или отношении
Впрочем, от платформы А/Б тестирования я не отступлюсь
#CoolStory
Если бы меня попросили описать мое положение в Фейсбуке, я бы использовал гениальную фразу своего польского коллеги, когда он в далеком 2013 году рассказывал в шутку про своего босса. Еще не начальник, а уже скурвился. Да, были какие-то команды, какой-то уровень ответственности и самостоятельности, но все же не то.
В Ноябре я смог наконец добраться до тех же позиций в Лондоне, что были у меня в Москве. Снова СЕО мой скип менеджер, вновь нужно делать что-то новое и отлаживать существующее и я уже вижу, как на горизонте маячит А/Б тестирование.
Уже на первых встречах я заметил разницу. Мы обсуждали какой-то функционал и прозвучала необходимость его реализовать. Моей первой реакцией было: так, наймем пять человек и за три месяца выкатим базовую версию, затем будем улучшать.
Мой босс сказал, значит купим API/сервис у компании, предоставляющей эти услуги
Хорошо, что я промолчал и решил послушать, а затем и подумать. Множество вещей, которые различные компании делают уже не первое десятилетие и продают как сервис, в тех компаниях, в которых работал, покупали далеко не всегда. Вместо этого делали свой сервис или свой продукт. Чаще чем хотелось бы выходило криво, косо, дорого. Бывало, никто этим еще и не пользовался внутри компании, потому что криво и косо. Зато свое. Или пользовались и злились
С другой стороны, казалось бы, купил, пользуешься, пока это тебе нужно, смотришь какой именно функционал тебе нужен, какой не нужен и если очень хочется, то начинаешь делать свое, сначала как fallback, потом как замену, если вообще начинаешь. Конечно, некоторые вещи нужно делать исключительно внутри, например платформу А/Б тестирования или ценообразование, некоторые нужно дублировать для надежности, но далеко не все.
Я задумался, что же является причиной такого подхода, кроме понятной жадности любого менеджера в надежде заграбастать побольше людей, бюджетов, власти и естественное недоверие ко всему новому и лишь условно контролируемому? Одно из объяснений, пришедших мне в голову звучало так: Opex и Capex.
Дело в том, что существует два типа расходов, богоугодный Capex и нечестивый Opex. Если у компании есть 1 млрд рублей активами, это хорошо, увеличивает ее ценность и уверенность в завтрашнем дне. Представьте, что компания купила здание за 1 млрд рублей и поместила его на своей баланс. Баланс по-прежнему 1 млрд, а затраты компании на покупку здания были списаны в Capex. Если мы потратим 1 млрд рублей на зарплаты, это грустно, эти деньги навсегда покидают компанию и заставляют всех печально смотреть им вслед. С другой стороны, если мы наймем бригаду строителей и купим материалов, а затем построим здание, то их зарплаты мы можем тоже списать в Capex, ведь результатом их труда стало здание, которое мы поставили на баланс. Я думаю, вы сами можете продолжить логическую цепочку что так можно делать практически с чем угодно. Мне кажется, это может быть одной из причин бешеного спроса на IT специалистов, все делают свое и повторяют одно и тоже
У меня еще нет ответа, почему же там, где я сейчас, все по-другому. Возможно, скорость важнее, возможно, найм дольше, возможно, зарплаты выше (недавно рассказал зарплату стажера одному синьору, он долго горевал) и выгоднее сначала брать готовые сервисы, использовать их какое-то время и лишь потом принимать решение - делать свое или не нет, может быть дело в доверии или отношении
Впрочем, от платформы А/Б тестирования я не отступлюсь
#CoolStory
👍21❤4
Добавлю, что мой предыдущий пост описывает не какую-то конкретную компанию, но систему в IT в целом. В той или иной степени я видел это везде, где был, а был я много где
👍2
Читатели пишут альтернативные мнения про капекс и опекс.
"Кстати я уже говорил но тот подход к opex и capex сильно нетипичен для контор в которых я работал, я не знаю про сверхбольшие публичные, но условный средний CFO американской конторы средне-большого размера, и особенно стартапа, будет двумя руками топить за Opex (примерно с этими аргументами) https://www.10thmagnitude.com/opex-vs-capex-the-real-cloud-computing-cost-advantage/
Аргумент почему не пилить свое в среднего размера конторе или стартапе примерно такой: нанимать тяжело и медленно, поэтому большинство нанятых лучше кидать на развитие вещей которые делают нашу контору уникальной (основной продукт), а все остальное можно быстро покупать на инвесторские деньги"
"Кстати я уже говорил но тот подход к opex и capex сильно нетипичен для контор в которых я работал, я не знаю про сверхбольшие публичные, но условный средний CFO американской конторы средне-большого размера, и особенно стартапа, будет двумя руками топить за Opex (примерно с этими аргументами) https://www.10thmagnitude.com/opex-vs-capex-the-real-cloud-computing-cost-advantage/
Аргумент почему не пилить свое в среднего размера конторе или стартапе примерно такой: нанимать тяжело и медленно, поэтому большинство нанятых лучше кидать на развитие вещей которые делают нашу контору уникальной (основной продукт), а все остальное можно быстро покупать на инвесторские деньги"
Cognizant
Microsoft Business Group
As a leading innovator on the Microsoft platform, Cognizant brings our consultancy, industry experience and expertise to help your business grow.
👍1
Прочитал недавно статью от 2021 года. Using Synthetic Controls: Feasibility, Data Requirements, and Methodological Aspects
Статья приятна тем, что она понятна. Если я могу понять статью, мое настроение поднимается и я считаю такую статью хорошей.
Статья описывает простой подход к созданию синтетического контроля. Ситуация возникает тогда, когда мы хотим оценить влияние какого-то воздействия, но у нас нет возможности провести полноценный А/В тест, так как нету контрольной группы А. Попробуем создать ее искусственно. Возьмем пул кандидатов и нехитрой регрессией с некоторыми ограничениям (веса положительны, суммируются в единицу, веса должны быть разряжены) создадим взвешенное среднее из этих кандидатов, которое, как мы надеемся, сможет сыграть роль группы А. Мы даже можем попробовать проверить, насколько удачно и надежно получилось. Как плюс - все полностью интерпретируемое.
#ArticleReview
Статья приятна тем, что она понятна. Если я могу понять статью, мое настроение поднимается и я считаю такую статью хорошей.
Статья описывает простой подход к созданию синтетического контроля. Ситуация возникает тогда, когда мы хотим оценить влияние какого-то воздействия, но у нас нет возможности провести полноценный А/В тест, так как нету контрольной группы А. Попробуем создать ее искусственно. Возьмем пул кандидатов и нехитрой регрессией с некоторыми ограничениям (веса положительны, суммируются в единицу, веса должны быть разряжены) создадим взвешенное среднее из этих кандидатов, которое, как мы надеемся, сможет сыграть роль группы А. Мы даже можем попробовать проверить, насколько удачно и надежно получилось. Как плюс - все полностью интерпретируемое.
#ArticleReview
👍10
Сначала я подумал что это нечто вроде Causal Impact от Гугла на минималках, но затем оценил простоту, элегантность и возможность заглянуть в черный ящик
В качестве примера рассматривают изменение ВВП на душу населения в Западной Германии и как на это повлияла объединение с Восточной Германией (figure 1)
Пул Кандидатов с весами (table 2)
И даже что-то вроде предсказательных/доверительных интервалов (figure 4)
К слову статью мне подкинул мой давний друг и бывший коллега, а ныне большой начальник в одном желтом банке - Нерсес Багиян, за что ему большое спасибо
#ArticleReview
В качестве примера рассматривают изменение ВВП на душу населения в Западной Германии и как на это повлияла объединение с Восточной Германией (figure 1)
Пул Кандидатов с весами (table 2)
И даже что-то вроде предсказательных/доверительных интервалов (figure 4)
К слову статью мне подкинул мой давний друг и бывший коллега, а ныне большой начальник в одном желтом банке - Нерсес Багиян, за что ему большое спасибо
#ArticleReview
❤2👍2
Во время моего сегодняшнего выступления на it nights в Инополисе, на мне будет прибор, непрерывно замеряющий пульс. Зрители будут голосовать стоит ли его понизить или повысить и по итогам будет происходить какое то событие. Какое - я и сам не знаю
👍2
Кажется иногда ребята из Карпов Курсес могут быть очень активным с рекламой, правда скорее всего это сама площадка пытается что-то оптимизировать. В целом напоминает определенные образы. На второй фотографии святой Христофор Псеглавый
😁1
Стоит ли публиковать вакансии по аналитике, мл, дата инженерии и прочему здесь. Вакансии от моих друзей или тех с кем или где я работал
Anonymous Poll
85%
Да
15%
Нет
Часть 1/3
Мой друг Нерсес, регулярно скидывает мне контент отличного качества, сегодня речь пойдет о небольшой статье : Building a data team at a mid-stage startup: a short story https://erikbern.com/2021/07/07/the-data-team-a-short-story.html
На мой взгляд mid-stage startup название обманчивое. Описанное очень похоже на процесс построения дата-команды как в большой публичной компании, так и в небольшом стартапе. Статья разделена на отрезкие описывающие первый год Head of the Data Team (HoDT) с чекпойнтами в разные моменты времени. Я приведу их ниже, вместе с тем как это происходило со мной, происходящее со мной будет миксом из событий происходивших в разных компаниях в России и в Лондоне.
Первый день: СЕО и экзеки привечают тебя, we are so excited you are here. Потом оказывается что есть Data Scientist-ы которые тебе не репортят, хотя утверждалось что все репортят тебя. Есть Дашборды, но они не те и туда никто не смотрит. Проводятся какие-то запуски, есть даже какие то цифры - правда при вопросе про стат значимость ПМ отвечает что это не его работа, это твоя работа, кроме того последний раз когда ПМ спрашивал, ему ответили что это займет месяцы сбора данных. Да и вообще, крутые штуки не строятся через инкремент, Стив Джобс не делал А/Б тест Айфона. Crush before deadline - that’s what matters
Идет знакомство с командой - есть куча Ipython ноутбуков, рекомендационные системы, нейронные сетки для прогноза оттока и много чего еще, что то прикольное, что то нет. Почти везде куча спагетти кода, сложный препроцессинг данных, непонятный ETL, все это работает только если запускать правильные скрипты в правильном порядке и ничего из этого нет в продакшене. Почему нет? Потому что инженеры говорят что это очень сложный проект
Общение с директором по логистике не такое радужное, он говорит что не уверен, что ему нужна помощь дата саентистов,.
Вот бизнес аналитики, это то что ему надо, у него куча вопросов к ним. Если взглянуть на эти вопросы, они выглядят следующим образом: какая конверсия, если Тикет разрешен менее чем за час и какая, если более чем за час. Кроме того у него есть МОДЕЛЬ. После просмотра модель оказывается очень запутанной штук в Гугл доке, с кучой VLOOKUPs и данными, которые должны быть copy-pasted в нужную колонку в нужном формате. Данные обновляются ежедневно и выход модели определяет приоритеты это дня. Кроме того этот док рассчитывает кому и сколько платить из вендоров
Что было у меня в первые дни: Успел поймать момент, когда другой департамент пытался завести своих дата саентистов, потому что ему не уделяли достаточно внимание и остановить это. Увидел схожие проблемы с принятием решений на основе данных. К моему удивлению, несмотря на обилие PhD в команде, качество кода не вызывало оторопи, да, есть что улучшить, но выглядит достойно. Большинство команд и руководителей страдает от отсутствия базового анализа и пока не задумывается о чем-то большем. Экзеки были very excited. Те люди, чьи сотрудники работали в Эксельках были настроены скептично
Неделя после выхода на работу: Проводится реорганизация дата команды, выделяется инфраструктурная команда. Из описания вакансий вымарывается машинное обучение и искусственный интеллект. Ты пообщался с Дата Саентистами которые тебе не репортят и они говорят: “I've always wanted to become a data scientist, and I can't wait to learn from you” . Созваниваешься с другом у которого есть курсы по SQL и договариваешься об их проведении. Делаешь презентацию про АБ тестам и как они работают. Общаешься с бизнес аналитиками из логистики - они вменяемые ребята, но предыдущий их опыт общения с дата командой оставляет желать лучшего. Кто то из них знает SQL и если дать им доступы к базам данных, работа пойдет веселее чем через Эксель. С ключевыми людьми, которым нужна работа с данными, ставятся регулярные встречи для понимания куда и как идти
#CoolStory
Мой друг Нерсес, регулярно скидывает мне контент отличного качества, сегодня речь пойдет о небольшой статье : Building a data team at a mid-stage startup: a short story https://erikbern.com/2021/07/07/the-data-team-a-short-story.html
На мой взгляд mid-stage startup название обманчивое. Описанное очень похоже на процесс построения дата-команды как в большой публичной компании, так и в небольшом стартапе. Статья разделена на отрезкие описывающие первый год Head of the Data Team (HoDT) с чекпойнтами в разные моменты времени. Я приведу их ниже, вместе с тем как это происходило со мной, происходящее со мной будет миксом из событий происходивших в разных компаниях в России и в Лондоне.
Первый день: СЕО и экзеки привечают тебя, we are so excited you are here. Потом оказывается что есть Data Scientist-ы которые тебе не репортят, хотя утверждалось что все репортят тебя. Есть Дашборды, но они не те и туда никто не смотрит. Проводятся какие-то запуски, есть даже какие то цифры - правда при вопросе про стат значимость ПМ отвечает что это не его работа, это твоя работа, кроме того последний раз когда ПМ спрашивал, ему ответили что это займет месяцы сбора данных. Да и вообще, крутые штуки не строятся через инкремент, Стив Джобс не делал А/Б тест Айфона. Crush before deadline - that’s what matters
Идет знакомство с командой - есть куча Ipython ноутбуков, рекомендационные системы, нейронные сетки для прогноза оттока и много чего еще, что то прикольное, что то нет. Почти везде куча спагетти кода, сложный препроцессинг данных, непонятный ETL, все это работает только если запускать правильные скрипты в правильном порядке и ничего из этого нет в продакшене. Почему нет? Потому что инженеры говорят что это очень сложный проект
Общение с директором по логистике не такое радужное, он говорит что не уверен, что ему нужна помощь дата саентистов,.
Вот бизнес аналитики, это то что ему надо, у него куча вопросов к ним. Если взглянуть на эти вопросы, они выглядят следующим образом: какая конверсия, если Тикет разрешен менее чем за час и какая, если более чем за час. Кроме того у него есть МОДЕЛЬ. После просмотра модель оказывается очень запутанной штук в Гугл доке, с кучой VLOOKUPs и данными, которые должны быть copy-pasted в нужную колонку в нужном формате. Данные обновляются ежедневно и выход модели определяет приоритеты это дня. Кроме того этот док рассчитывает кому и сколько платить из вендоров
Что было у меня в первые дни: Успел поймать момент, когда другой департамент пытался завести своих дата саентистов, потому что ему не уделяли достаточно внимание и остановить это. Увидел схожие проблемы с принятием решений на основе данных. К моему удивлению, несмотря на обилие PhD в команде, качество кода не вызывало оторопи, да, есть что улучшить, но выглядит достойно. Большинство команд и руководителей страдает от отсутствия базового анализа и пока не задумывается о чем-то большем. Экзеки были very excited. Те люди, чьи сотрудники работали в Эксельках были настроены скептично
Неделя после выхода на работу: Проводится реорганизация дата команды, выделяется инфраструктурная команда. Из описания вакансий вымарывается машинное обучение и искусственный интеллект. Ты пообщался с Дата Саентистами которые тебе не репортят и они говорят: “I've always wanted to become a data scientist, and I can't wait to learn from you” . Созваниваешься с другом у которого есть курсы по SQL и договариваешься об их проведении. Делаешь презентацию про АБ тестам и как они работают. Общаешься с бизнес аналитиками из логистики - они вменяемые ребята, но предыдущий их опыт общения с дата командой оставляет желать лучшего. Кто то из них знает SQL и если дать им доступы к базам данных, работа пойдет веселее чем через Эксель. С ключевыми людьми, которым нужна работа с данными, ставятся регулярные встречи для понимания куда и как идти
#CoolStory
Erik Bernhardsson
Building a data team at a mid-stage startup: a short story
You are brought into a startup to run their three-person data team. This is a story about teams and organization, and how you spend a year getting the team to a good place.
👍9❤3
Часть 2/3
Что было у меня в первые недели: Проводится реорганизация, выделяется инфраструктурная команда и ad hoc команда. Ты пообщался с Дата Саентистами (или теми людьми, которые думаю что они DS) не репортящими тебе и они говорят: “I've always wanted to become a data scientist, and I can't wait to learn from you”. Созваниваешься с другом у которого есть курсы по SQL и договариваешься об их проведении. Делаешь презентацию про АБ тесты и как они работают. Общаешься с бизнес аналитиками из других подразделений - они вменяемые ребята, но предыдущий их опыт общения с дата командой оставляет желать лучшего. Кто то из них знает SQL и если дать им доступы к базам данных, работа пойдет веселее чем через Эксель. С ключевыми людьми, которым нужна работа с данными, ставятся регулярные встречи для понимания куда и как идти
Два месяца после выхода на работу: Команда выросла, кто то работает на инфру, остальные раскиданы по конкретным продуктовым командам. Об это сообщено в рамках компании. Нанимая новых людей - их нанимают в конкретную команду, зачастую продуктовую или инфру
Что было у меня Команда выросла, разделена на три команды: Data Engineering/infra, Squad team, Ad-hoc team из ad-hoc team растет a/b testing platform. Об это сообщено в рамках компании. Нанимая новых людей - их нанимают в конкретную команду, DE/Ad-hoc/Squad
Полгода после выхода на новую работу С утра письмо, один человек уходит из команды, хочет заниматься исследованиями в машинном обучение. Что-ж, нет смысла его отговаривать, кроме того это было неизбежно. В команде достаточно людей которым нравится текущая работа, они знают немного SQL, немного Software Eng - самое главное у них есть желание разбираться в данных. Например один из членов команды смог поймать проблему в онбординге пользователей и тем самым повысить конверсию на 21% - это стало возможно только благодаря новой структуре данных, полученной после ETL
Встреча с СЕО и экзеками по поводу проектов запущенных в прошлом квартале. CMO демонстрирует новый лендинг, его делали 20 инженеров и успели к дедлайну. По итогам презентации все смотрят на СЕО, она молчит, потом спрашивает, какие метрики - как изменилась цена привлечения пользователя. Оказывается расчет метрик по результатам АБ есть где то в аппендиксе, но они не прокрасились, стат значимой разницы нет. СМО говорит что цифры еще могу измениться и нужны месяцы для сбора данных, так говорит дата команды, но даже при этом стоимость привлечения юзера выглядит не очень.
Что было у меня Было что люди уходили, потому не было нейроночек, а нужны были аналитики. Топ менеджмент начал смотреть на метрики а спрашивать про стат значимость и понимать что тест надо крутить какое то длительное время. Качественные данные позволили понять, что есть места где можно много заработать. В некоторых случаях Топ менеджмент говорит что надо крутить тест долго - так нам сказала дата команда.
Девять месяцев после выхода на новую работу Почти все проекты с машинным обучением пошли в никуда, кроме одного. Есть интересный проект по рекомендациям. DS которая его сделала умеет во Flask и может сделать приложеньку, которая будет выплевывать результаты. PM команды вовлечен и хочет шипнуть этот проект как можно быстрее. К сожалению твой DS не умеет в нагруженные системы, но для 1% пользователей сделать может, звучит как АБ.
Аналитики из логистики пишут гигантские SQL запросы, твоя команда помогает их переписывать и оптимизировать. Директор логистики говорит что как только вы начали работать вместе, его аналитики стали гораздо продуктивнее, он сделает все чтобы нанять еще людей тебе в команду, чтобы они помогали его ребятам
Что было у меня МЛ проектов было побольше , где можно было без мл - делали без него. Однако прогноз спроса, антифрод, различные сегментации и аплифты - делали через машинное обучение. В основном вся помощь на другие подразделения компании происходила через Ad-hoc, для которого другие директора не жалели ресурсов
#CoolStory
Что было у меня в первые недели: Проводится реорганизация, выделяется инфраструктурная команда и ad hoc команда. Ты пообщался с Дата Саентистами (или теми людьми, которые думаю что они DS) не репортящими тебе и они говорят: “I've always wanted to become a data scientist, and I can't wait to learn from you”. Созваниваешься с другом у которого есть курсы по SQL и договариваешься об их проведении. Делаешь презентацию про АБ тесты и как они работают. Общаешься с бизнес аналитиками из других подразделений - они вменяемые ребята, но предыдущий их опыт общения с дата командой оставляет желать лучшего. Кто то из них знает SQL и если дать им доступы к базам данных, работа пойдет веселее чем через Эксель. С ключевыми людьми, которым нужна работа с данными, ставятся регулярные встречи для понимания куда и как идти
Два месяца после выхода на работу: Команда выросла, кто то работает на инфру, остальные раскиданы по конкретным продуктовым командам. Об это сообщено в рамках компании. Нанимая новых людей - их нанимают в конкретную команду, зачастую продуктовую или инфру
Что было у меня Команда выросла, разделена на три команды: Data Engineering/infra, Squad team, Ad-hoc team из ad-hoc team растет a/b testing platform. Об это сообщено в рамках компании. Нанимая новых людей - их нанимают в конкретную команду, DE/Ad-hoc/Squad
Полгода после выхода на новую работу С утра письмо, один человек уходит из команды, хочет заниматься исследованиями в машинном обучение. Что-ж, нет смысла его отговаривать, кроме того это было неизбежно. В команде достаточно людей которым нравится текущая работа, они знают немного SQL, немного Software Eng - самое главное у них есть желание разбираться в данных. Например один из членов команды смог поймать проблему в онбординге пользователей и тем самым повысить конверсию на 21% - это стало возможно только благодаря новой структуре данных, полученной после ETL
Встреча с СЕО и экзеками по поводу проектов запущенных в прошлом квартале. CMO демонстрирует новый лендинг, его делали 20 инженеров и успели к дедлайну. По итогам презентации все смотрят на СЕО, она молчит, потом спрашивает, какие метрики - как изменилась цена привлечения пользователя. Оказывается расчет метрик по результатам АБ есть где то в аппендиксе, но они не прокрасились, стат значимой разницы нет. СМО говорит что цифры еще могу измениться и нужны месяцы для сбора данных, так говорит дата команды, но даже при этом стоимость привлечения юзера выглядит не очень.
Что было у меня Было что люди уходили, потому не было нейроночек, а нужны были аналитики. Топ менеджмент начал смотреть на метрики а спрашивать про стат значимость и понимать что тест надо крутить какое то длительное время. Качественные данные позволили понять, что есть места где можно много заработать. В некоторых случаях Топ менеджмент говорит что надо крутить тест долго - так нам сказала дата команда.
Девять месяцев после выхода на новую работу Почти все проекты с машинным обучением пошли в никуда, кроме одного. Есть интересный проект по рекомендациям. DS которая его сделала умеет во Flask и может сделать приложеньку, которая будет выплевывать результаты. PM команды вовлечен и хочет шипнуть этот проект как можно быстрее. К сожалению твой DS не умеет в нагруженные системы, но для 1% пользователей сделать может, звучит как АБ.
Аналитики из логистики пишут гигантские SQL запросы, твоя команда помогает их переписывать и оптимизировать. Директор логистики говорит что как только вы начали работать вместе, его аналитики стали гораздо продуктивнее, он сделает все чтобы нанять еще людей тебе в команду, чтобы они помогали его ребятам
Что было у меня МЛ проектов было побольше , где можно было без мл - делали без него. Однако прогноз спроса, антифрод, различные сегментации и аплифты - делали через машинное обучение. В основном вся помощь на другие подразделения компании происходила через Ad-hoc, для которого другие директора не жалели ресурсов
#CoolStory
👍11❤1
Часть 3/3
Прошел год после выхода на новую работу Идет планирование. Раньше это были дебаты, сейчас это ревью метрик и прокси метрик - есть целая иерархия метрик. Работа с ПМами дала свои плоды, они часто подтверждают свои результаты выкладками из аб или инсайтами из данных. Дата Аналитики помогли найти несколько багов за счет Exploratory Data Analysis. Идут работы по атрибуции для маркетинга. Тест рекомендашек оказался крайне успешным, но раскатить на 100% не так просто. СЕО дала зеленый свет - будем подключать инженеров. Множество тестов оказались безрезультативными или даже негативными. Но теперь это не провал, а повод понять что наша картина мира не совпадает с реальностью и нужно проводить дополнительные исследования
Что было у меня Примерно через год мы начали приносить деньги - ряд проектов выстрелил, иерархия метрик и внедрение культуры АБ тестирования заняли больше времени. Атрибуцией занялись с самого начала. Множество тестов оказались серыми или даже негативными, но это не провал, это норма. Уровень успешных тестов заметно выше того, что я видел в других местах, это вызывает уважение. Работа с ПМами дала свои плоды, они часто подтверждают свои результаты выкладками из аб или инсайтами из данных
#CoolStory
Прошел год после выхода на новую работу Идет планирование. Раньше это были дебаты, сейчас это ревью метрик и прокси метрик - есть целая иерархия метрик. Работа с ПМами дала свои плоды, они часто подтверждают свои результаты выкладками из аб или инсайтами из данных. Дата Аналитики помогли найти несколько багов за счет Exploratory Data Analysis. Идут работы по атрибуции для маркетинга. Тест рекомендашек оказался крайне успешным, но раскатить на 100% не так просто. СЕО дала зеленый свет - будем подключать инженеров. Множество тестов оказались безрезультативными или даже негативными. Но теперь это не провал, а повод понять что наша картина мира не совпадает с реальностью и нужно проводить дополнительные исследования
Что было у меня Примерно через год мы начали приносить деньги - ряд проектов выстрелил, иерархия метрик и внедрение культуры АБ тестирования заняли больше времени. Атрибуцией занялись с самого начала. Множество тестов оказались серыми или даже негативными, но это не провал, это норма. Уровень успешных тестов заметно выше того, что я видел в других местах, это вызывает уважение. Работа с ПМами дала свои плоды, они часто подтверждают свои результаты выкладками из аб или инсайтами из данных
#CoolStory
👍8❤2
У меня есть друг и его зовут Адам Елдаров. Сейчас он CPO (Chief product officer) в youdo.com и отвечает за всю продуктовую часть этого сервиса. Наш общий друг постоянно называет его C3PO и Адам не обижается. Мы дружим с ним уже года три или четыре, хотя я до конца не уверен, потому что за все это время мы так ни разу и не ездили с ним вместе на гелике и не стреляли в воздух из калаша, возможно я ему и не друг вовсе.
Кроме продуктовой работы, Адам умеет писать код, разбирается в мл опс и девопс, машинном обучении и аналитике. Или старательно делает вид, но у меня не хватает квалификации его разоблачить, оцените например это видео https://m.youtube.com/watch?v=F-j0G0lrjFw
Кстати это именно он писал здесь коммент, мол чего это вы делали платформу АБ тестирования так долго и вдесятером, я один за две недели справился
Ещё он автор этого документа, https://youdo.notion.site/Product-Skills-Track-32bdfbe6b6c64bd182474c2050fa19d8 product skills track
Если бы у меня была своя компания и мне пришлось бы платить свои деньги, чтобы другие люди делали работу, я бы хотел нанять туда Адама.
К сожалению сегодня нанимаю не я, а он и не меня, а аналитика. В первом комментарии я сброшу описание, здесь скажу по деньгам. 200-300 тысяч рублей в месяц на руки база для аналитика и 300-400 для Лида. Правда чего хочется от Лида в первом комменте не будет. Возможно это неслучайно
Также Адам утверждает что премий нет и придется ему поверить. Хотя я не верю
#friends
Кроме продуктовой работы, Адам умеет писать код, разбирается в мл опс и девопс, машинном обучении и аналитике. Или старательно делает вид, но у меня не хватает квалификации его разоблачить, оцените например это видео https://m.youtube.com/watch?v=F-j0G0lrjFw
Кстати это именно он писал здесь коммент, мол чего это вы делали платформу АБ тестирования так долго и вдесятером, я один за две недели справился
Ещё он автор этого документа, https://youdo.notion.site/Product-Skills-Track-32bdfbe6b6c64bd182474c2050fa19d8 product skills track
Если бы у меня была своя компания и мне пришлось бы платить свои деньги, чтобы другие люди делали работу, я бы хотел нанять туда Адама.
К сожалению сегодня нанимаю не я, а он и не меня, а аналитика. В первом комментарии я сброшу описание, здесь скажу по деньгам. 200-300 тысяч рублей в месяц на руки база для аналитика и 300-400 для Лида. Правда чего хочется от Лида в первом комменте не будет. Возможно это неслучайно
Также Адам утверждает что премий нет и придется ему поверить. Хотя я не верю
#friends
YouTube
078. Как в YouDo машинное обучение катится в продакшен – Адам Елдаров
- Как деплоить, скейлить и управлять жизненным циклом ML моделей?
- Как настроить процесс дообучения и переобучения модели?
- Как выстраивать масштабируемые микросервисы для моделей машинного обучения?
- Как версионировать модели при разработке и код пайплайнов?…
- Как настроить процесс дообучения и переобучения модели?
- Как выстраивать масштабируемые микросервисы для моделей машинного обучения?
- Как версионировать модели при разработке и код пайплайнов?…
👍11❤1