Недавно я покинул уютные объятия Фейсбука, за время моего существования превратившегося в Мету. К счастью успел продать последний Транш RSU по 350 , перед их обвалом до 305, известный в узких кругах эффект ухода Валеры

Лондон однако решил не покидать и в середине декабря начал работать Head of Data Science в Blockchain.com

Правда сейчас я скорее себя чувствую Head Of Data Engineering и Analytics, так как в DS в блоке входят инженерия данных, продуктовая аналитика, BI и машинное обучение. Как завещал знаменитый продолжатель пирамидостроения - сначала необходимо реализовать базовые потребности

Буду время от времени писать сюда свои мысли, наблюдения и статьи, которые мне показались интересными

Попробую добавить возможность комментировать

После работы в больших корпорациях и стартапах, я начал работать в чем-то среднем, уже не стартап, но еще не корпорация и как след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.

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

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

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

Ребята подготовили от меня промокод babushkin на 30%. Подключайтесь и смотрите выступление на www.it-nights.ru
Правда я не знаю какие в итоге опыты будут ставить на мне в прямом эфире.

В России мне посчастливилось поработать в нескольких компаниях гигантах на очень интересных позициях. Интересны они были смесью высоты и новизны , приправленные необходимостью делать что-то новое. Например, в Х5 моим Боссом был Управляющий Директор Х5 Технологии, а скип менеджером СЕО. Нужно было немного-нимало помочь выстроить МЛ и Дата Аналитику с нуля. Как говорил Черномырдин: что бы мы ни делали — получается одно и то же: либо КПСС, либо автомат Калашникова. В моем случае чтобы я ни делал, получаются еще и А/Б тесты

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

В Ноябре я смог наконец добраться до тех же позиций в Лондоне, что были у меня в Москве. Снова СЕО мой скип менеджер, вновь нужно делать что-то новое и отлаживать существующее и я уже вижу, как на горизонте маячит А/Б тестирование.

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

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

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

Я задумался, что же является причиной такого подхода, кроме понятной жадности любого менеджера в надежде заграбастать побольше людей, бюджетов, власти и естественное недоверие ко всему новому и лишь условно контролируемому? Одно из объяснений, пришедших мне в голову звучало так: Opex и Capex.

Дело в том, что существует два типа расходов, богоугодный Capex и нечестивый Opex. Если у компании есть 1 млрд рублей активами, это хорошо, увеличивает ее ценность и уверенность в завтрашнем дне. Представьте, что компания купила здание за 1 млрд рублей и поместила его на своей баланс. Баланс по-прежнему 1 млрд, а затраты компании на покупку здания были списаны в Capex. Если мы потратим 1 млрд рублей на зарплаты, это грустно, эти деньги навсегда покидают компанию и заставляют всех печально смотреть им вслед. С другой стороны, если мы наймем бригаду строителей и купим материалов, а затем построим здание, то их зарплаты мы можем тоже списать в Capex, ведь результатом их труда стало здание, которое мы поставили на баланс. Я думаю, вы сами можете продолжить логическую цепочку что так можно делать практически с чем угодно. Мне кажется, это может быть одной из причин бешеного спроса на IT специалистов, все делают свое и повторяют одно и тоже

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

Впрочем, от платформы А/Б тестирования я не отступлюсь

#CoolStory

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

Читатели пишут альтернативные мнения про капекс и опекс.

"Кстати я уже говорил но тот подход к opex и capex сильно нетипичен для контор в которых я работал, я не знаю про сверхбольшие публичные, но условный средний CFO американской конторы средне-большого размера, и особенно стартапа, будет двумя руками топить за Opex (примерно с этими аргументами) https://www.10thmagnitude.com/opex-vs-capex-the-real-cloud-computing-cost-advantage/

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