Alexey Rybak

2021-12-20 12:23:36 Survey’2021 зум-митап и дискуссия
Уже завтра, во вторник, 21-го декабря в 18:30 по Москве соберемся на зум-митап, посвященный исследованию бекенда, который мы делали в ноябре со Sveta Danilchenko. Собрали дофига данных, но расскажу об основном. Всего будет две части - про рынок и техническая.

Первая будет посвящена рынку зарплат в России. Данные поделены по респондентам из российских компаний, отдельно из международных компаниий, и по респондентам, которые работают на ИП по удаленке на международные компании. Так же мы выделили в отдельную категорию staff/principal, т.к. понятие "senior" давно уже значительно размыто. Думаю, это исследование чуть лучше отражает текущую реальность, и где мы все вдруг оказались в последний год. Сравним эти цифры с другими исследованиями и поговорим про процессы, которые происходят. Эта первая часть может быть интересна эйчарам, рекрутерам, нанимающим менеджерам и вообще всем, кто хочет быть в курсе.

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

Приходите. Вот страница мероприятия, его можно добавить себе на фейсбуке:
https://www.facebook.com/events/1245314045979998. Мероприятие пройдет в формате зум-звонка (https://us02web.zoom.us/j/84428307039...), и также будет youtube-стрим вот тут https://www.youtube.com/alexeyrybak. Открыть/Комментировать

2021-11-08 12:06:08 Изучая данные исследования

Этот пост - в поддержку исследования, которое мы проводим уже вторую неделю, собирая ответы на большой опрос инженеров и руководителей. Мы его назвали “исследование бекенда”, но на самом деле, там и много вопросов про инфраструктуру, и мотивацию, и рыночную ситуацию. В исследовании уже приняло участие несколько сотен человек, но самое интересное – в когортах, и для этого нам нужно ещё минимум несколько сотен участников. Поэтому если вы вдруг не участвовали - пожалуйста, примите участие, это займет всего 10-15 минут: https://bit.ly/3EBbgdM

Из интересного про мотивацию и деньги на скорую руку:
- Диапазон требований по ЗП оказался значительно шире, чем я думал. Отчасти это продиктовано тем, что выше 70% участников - это опытные сотрудники, уровней senior и выше. Отчасти - заметной долей участников работающий из-за границы или на иностранного работодателя. Конкретных цифр пока не назову, но до 250 тысяч рублей на руки зарабатывает примерно 35%, остальные - выше.
- Абсолютное большинство, выше 50%, основным триггером смены работы называли “неповышение ЗП при выросшем рынке”. Воистину, 2021й год - кошмар работодателя.
- Абсолютными лидерами по непривлекательности для сотрудников являются два типа компаний: Государственные и Беттинговые компании. С заметным отставанием - Крипта, Порно и Аутсорс. Перспективы устройства в стартапы считают возможным выше 90% участников, что не может не радовать.
- Менее 25% хотят принципиально работать на родине, остальные активно ищут или готовы рассмотреть вариант отъезда на работу за границу. Кажется, это самый низкий показатель, который я вообще видел в своей жизни, и это очень печально.

Эти и кучу других результатов про самую распространенный СУБД, про типы и компоненты инфры, кто самые популярные облачные провайдеры - всё опубликуем чуть позже. Пожалуйста, примите участие в исследовании, чтобы оно было максимально полным: https://bit.ly/3EBbgdM Открыть/Комментировать

2021-10-07 12:05:15 Не понял, кто конкретно вам нужен?

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

С бизнесовой точки зрения нас устроит довольно большое количество комбинаций: недостаток какой-то квалификации у одного кандидата может быть скомпенсирован соответствующими компетенциями у других членов команды. Этим другим членом может быть и нанимающий менеджер: возможно, что-то придется взять на себя самому и передавать/развивать в процессе дальнейшей работы. При таком подходе вероятность быстрее и удачно отстроить направление выше, чем искать “мага”, который сам молча придет и построит всё – ждать такого мага можно бесконечно (и всё равно облажаться в конце-концов).

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

Разговор, будучи срежиссированным таким образом, показывает много о кандидате, создает базу для более доверительных отношений. Но требует очень аккуратной отстройки в процессе, поскольку пугает “технарей-аналитиков”. Если я чувствую, что человеку всё-таки сложно посмотреть на задачу "сверху" – стараюсь на ходу подобрав к опыту кандидата какой-то конкретный сценарий, хотя в идеале это должен быть диалог. К сожалению, такой подход всё равно отсеивает недостаточно рисковых чуваков, но может это и к лучшему – всё-таки мне важно, чтобы люди были готовы работать в неопределенной, динамичной среде. Открыть/Комментировать

2020-12-09 13:52:53 6 признаков о*уенных инженерных компаний

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

- Продуктовость. Вы делаете полезный продукт, либо уже получаете много бабла от пользователей (а не от инвесторов) либо максимально приближаете этот момент, нанимаете классных чувяков и вместе зажигаете, пользователи вас боготворят и всем советуют ваш продукт, и всё это позволяет вам не скатиться в адище, степеней и вариаций коего тьма.
- Пассионарность. Вы пушеры, не сидите на жопе ровно, не боитесь быстро релизить и править на ходу (если конечно вы не ядерные реакторы делаете), стремитесь планировать, не боитесь сигнализировать о проблемах, не боитесь расцеплять задачи на компоненты, формализовать зависимости, принуждать к формальным договоренностям а не к расплывчатым формулировкам. Короче, вы подталкиваете все проекты и задачи вперёд, а не разбредаетесь как зомби по своим углам.
- Мастерство. Вы копаете вглубь и вширь, вы не готовы работать по инструкции, не понимая внутреннего устройства, вы постоянно совершенствуетесь и задаете себе вопрос “что и как стоит улучшить”. вообще тут должно быть “доброжелательное мастерство” потому что вы ещё должны помогать и не прятать/“торговать” знаниями, но тут есть риск утонуть в прилагательных, "незанудное доброжелательное мастерство" и так далее.
- Адаптивность. Вы трезво оцениваете результат, авторское эго не вгоняет вас в дичь, вы слушаете коллег и пользователей, препарируете всё, что доставляет неудобства, приоритезируете и снова и снова постоянно стремитесь к улучшениям
- Кросс-командные процессы. Вы выстроили процессы так, чтобы ваши команды эффективно пилили совместные проекты и ничего не тормозило. У вас разумный баланс между четко очерченной ответственностью и командным духом, транспарентностью и удобством коммуникации. У вас не ведутся подковерные игры, вы не тянете одеяло на себя, у вас не принято анальное огораживание, войны группировок и прочие антипаттерны больших коллективов (лично я убежден, что в такой формулировке это либо возможно исключительно в маленьком коллективе в несколько сотен человек максимум либо невозможно вовсе - поэтому "не принято" можно заменить на "минимизировано").
- Компания как государство. Вы строете эффективное, удобное, предсказуемое “государство”. Вы по возможности максимально формализовали понятия ”наш” и “не наш”, подстроили под это дело процесс найма, но при этом вы понимаете, что чем вы больше, тем больше среди ваших сотрудников типичных представителей популяции, поэтому экстремальность селекции сбалансирована потребностями роста. Тем не менее, к вам не попадают лишние люди, а если попали и не меняются - быстро компанию покидают. Вы инвестируете достаточно в процессы и практики, в “коллективное мастерство”, но всегда ставите выше потребности бизнеса, который эти косты оплачивает. Все в курсе крупных показателей бизнеса, что происходит, куда вы идете, какие у вас самые важные результаты. Вы получаете достаточное количество “спасибо”, во всех смыслах. Вы гордитесь своим продуктом и своей ей работой, считаете справедливой компенсацию, а всю систему вокруг удобной и разумно справедливой.

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

2020-10-26 16:06:11 Митап Feedme::Оnline#4: "Управление разработкой в горизонтальных компаниях"

В эту пятницу 30 октября в 16:00 проведу 4-й митап нашей фейсбук-группы "Управление и разработка больших IT-проектов" (https://www.facebook.com/groups/feedme.ru). Участвуют руководители разработки из Райффа, Циана и Майндбокса. Узнаем, как работают "гибкие" и "горизонтальные" подходы на больших масштабах, работает ли Large Scale Scrum, действительно ли в таких компаниях нет функциональных иерархий, и чем в таких компаниях занимаются CTO и технические руководители. Разберем типичные проблемы: коллективная vs персональная ответственность, комьюнити или жесткие профессиональные иерархии, узкие или взаимозаменяемые специалисты, четкие сроки и умение планировать или "власть команды" и noestimates. Что приходилось менять, ломать, что получилось, а то нет - на практических кейсах.

Участвуют:
- Сергей Кононенко, CTO в Райффайзенбанке
- Никита Прудников, CTO в Mindbox
- Михаил Юматов, руководитель разработки в Циан

Формат, как и прежде: интерактив в Zoom, стриминг в YouTube. Стриминг будет на канале https://www.youtube.com/c/AlexeyRybak/live, а для доступа в Zoom нужно зарегистрироваться на таймпэде: https://feedme.timepad.ru/event/1462940/.

Enjoy! Открыть/Комментировать

2020-08-11 19:08:46 Микросервисы - I

Куча народу рассуждает в парадигме “монолит - отстой, микро-сервисы - рулят”. Считаю, что дихотомия “монолит” vs “микро-сервисы” является ложной.

На пальцах об этих понятиях:
* Монолит – одно “большое” приложение с кучей функций
* Микро-сервисы – порезанный на отдельные сервисы монолит

Монолит содержит множество зависимостей, поэтому, типа, он тяжелый в разработке, в раскладке и в поддержке, а микро-сервисы, типа, нет.

Но ведь сервисной архитектуре – десятки лет, она прекрасно себя зарекомендовала. Термин SOA (service oriented architecture) появился в 90-х, API Mandate Безоса - в 2002-м. Чем же “микросервисная” архитектура отличается от “сервисной”?

В приведенной выше формулировке – ничем. Это моя сознательная ошибка и упрощение. Дихотомия должна быть трихотомией: монолит / сервисы / микро-сервисы. Отличие “монолита” от “сервисов” описано выше – оно совершенно понятное, “бизнесовое”. А вот отличие “микро-сервиса” от “сервиса”... его уже не так просто объяснить и продать!

Микро-сервисы стали популярными тогда же, когда стали массово топить за контейнеры и cloud-native архитектуры. Потому что микро-сервисы на самом деле невозможны без перехода на cloud-native платформы. Классическим требованиям к микро-сервисам (или cloud-native приложениям) имени Heroku “12-factors” не отвечает куча современных open source компонент, на которых строится огромное количество проектов. Переход на cloud-native платформу с фазы “монолита” тянет за собой миллион костов, но большинство бизнесовых проблем решается в рамках перехода к сервисной архитектуре, которая не требует перевода инфраструктуры на cloud-native платформу.

Волшебным образом микро-сервисы и cloud-native стали синонимами “масштабируемый”, “изолированный”, “легкий в разработке и поддержке” – но это не так, вернее, это не единственный способ обеспечить все эти замечательные качества. Поэтому дихотомия “монолит” vs ”микро-сервисы” – увы, просто манипуляция. Открыть/Комментировать

2020-08-04 16:45:24 Alexey Rybak pinned «О себе Привет! Давайте познакомимся. Я – Алексей Рыбак, CTO в агрегаторе такси “Везёт”. Мой опыт - 20+ лет, из которых больше половины я проработал в Мамбе и Badoo, пройдя путь от руководителя отдела разработки гаражного стартапа до главы разработки миллиардной…» Открыть/Комментировать

2020-08-04 16:43:36 Alexey Rybak pinned «День сисадмина Сегодня день сисадмина. Поздравляю с этим праздником всех - сисадминов, IT-директоров, "девопсов", сетевых инженеров, мониторщиков - всех, кто занимается эксплуатацией! Желаю вам, чтобы коллеги и начальство были доброжелательны и благодарны…» Открыть/Комментировать

2020-07-31 19:21:12 День сисадмина

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

Сисадмины сыграли в моей жизни охренеть какую важную роль. Все крутые чуваки, которых я знал/читал/слушал в конце 90-х - “сисадминили”. Я на всю жизнь запомнил сисадмина Васю, и как он на меня посмотрел в 1999-м году, когда на вопрос “Какую систему тебе ставить?” услышал “Винду”. Поэтому при первом же удобном случае я поставил себе волшебный донецкий дистрибутив Black Cat Linux, и хотя натрахался я с ним весьма конкретно, но именно Васина укоризна была началом увлекательного путешествия.

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

В-общем кто сисадминит, тот крут! А кто разрабатывает, но не сисадминит - посисадминьте хотя бы 127.0.0.1. Сильно поможет в будущем, даже если ваше “сисадминство” сведётся к использованию веб-морды облачного провайдера. Открыть/Комментировать

2020-06-04 15:00:51 CTO vs CIO (продолжение)

А если производство собственное, то это кардинально меняет дело. "Эксплуататору", "админу" сложнее отстроить производство, создать, возглавить организацию разработчиков. Тут уже идеален “программист”, и это – CTO (или “техдир”). При этом у CTO всё равно будет куча эксплуатационных задач. Поэтому программисту, который от таких задач убегает, стать CTO большой компании будет крайне непросто.

Выводы. Больше внешних подрядчиков и эксплуатации - это CIO, “админ”. Больше собственной разработки – CTО, “программист”. Замените везде “программист” на “разработчик”, и всё вышесказанное будет справедливо не только для софтверных, но и для хардверных компаний. В реальной жизни будет комбинация “своей” и “внешней” разработки, но всегда можно грубо оценить пропорцию, чего больше. Наконец, от эксплуатации не убежать, но по моему скромному опыту проще “разработчику” осилить “эксплуатацию”, чем “админу” – “программирование” или “разработку”. Открыть/Комментировать