2208
Дмитрий Меньшиков, CTO в продуктовой компании. Вещаю о построении и развитии IT бизнеса, развитии команды, менеджменте и трендах. Обратная связь - @notieinit_bot
⁉️ Что с рынком?
Думаю вы и сами прекрасно видите что происходит: рост компенсации за оказанные услуги разработчиками, превышение спроса над предложением (вакансий больше чем соискателей), падение качества, а также новая негативная тенденция в виде параллельного оказания услуг нескольким заказчикам. Эти пункты и прокомментирую.
Почему происходит рост? Я вижу несколько факторов.
1️⃣ В США и ЕС была произведена денежная эмиссия (то что у нас называют “напечатали денег”) за последние полтора года на огромные суммы, триллионы долларов и евро. Это подстегивает инфляцию и вы уже могли видеть рост цены на дерево, металлы, стройматериалы, недвижимость, землю и т.п., а также эти деньги попадают в IT сектор и выросло количество проектов на которые нанимают. Вот и превышение спроса над предложением.
2️⃣ С началом пандемии строить свои IT продукты начали даже те виды бизнесов, для которых IT совсем не профильная специализация. Владельцы заводов и пароходов, аграрии, банковский сектор и многие другие начали смотреть в сторону IT. Иногда оно им и не нужно, но тут логика проста - главное не упустить возможность, особенно когда есть не пристроенные бабки.
3️⃣ Отток хороших специалистов. К сожалению, часть знакомых перебралась в 2020-2021 в другие страны, а большинство компаний из FAANG начали хантить специалистов из СНГ и релоцировать их в ближнее зарубежье. На данный момент можно лишь сказать, что для хороших специалистов релокация в ЕС или UK является менее выгодной в экономическом плане на фоне СНГ. Мало того, что в ЕС уже сейчас зарплаты до вычета налогов (gross salary) ниже или сопоставимы с зарплатами в СНГ, так и налоговая нагрузка в ЕС/UK выше, а на руки в ЕС/UK (net salary) останется куда меньше. Но люди едут за новым опытом, за стабильностью и порядком, жертвуя снижением дохода.
4️⃣ Профильные ресурсы каждый месяц публикуют новые заоблачнные числа и играют на повышение. Безусловно, это большой плюс для тех кто живет на проценте от проданых специалистов, ведь чем специалист дороже, тем больше можно на нем заработать. Но тут два негативных аспекта. Во-первых, мелкий бизнес и небольшие локальные стартапы с собственным финансированием загибаются, ибо не могут позволить себе нанять людей. Крупные же могут, но это все приводит к монополизации, а монополизация часто приводит к застою отрасли. Да и стоит понимать, что рекордные числа из последних наймов не имеют ничего общего со средним доходом специалистов на рынке, а доля дорогих наймов не превышает на 0.5%.
Еще отмечу, что ранее я уже публиковал свои мысли и давал прогноз на развитие рынка до 2025 года. Мой прогноз не меняется, а я лишь констатирую повышение вероятности его реализации.
Энивей, в таких условиях приходится нанимать и меняться самому, менять подходы к найму. О том какие выводы я сделал и меры предпринимаю будет отдельная серия публикаций. Stay tuned.
🚜 Спустя 8.5 лет я ушел из Авроры, переболел короной, готовлю лайв с приятелем из Google и лайв-батл с гостями из QA Guild (Manual vs Automation).
1️⃣ Закончился мой забег и наступил тот момент, когда я решил уйти из компании. Если так задуматься, то 8.5 лет - это огромный срок и за это время было множество свершений. Были и переключения на разные виды бизнеса, и построение новых бизнесов с нуля, были и непростые ситуации... Самым ценным я считаю собранную команду, которая всегда желала большего и двигаться вперед. Особенно приятно слышать отзывы разработчиков, QA и админов, которых я нанимал и помогал расти, что в их карьере самая сильная техническая команда была именно в Авроре. За качество не стыдно) Да и по культуре собраны были уникальные люди. Можете похвастаться тем, что люди могут самоорганизоваться за 2 дня и выехать на выходные с палатками ⛺️ за город?) Или поехать на горнолыжный курорт 🏂
толпой в 8-12 чел, да и не раз, а из года в год? Всем с кем работал - большой респект, вы в моем сердце навсегда.
Жаль прощаться, но порой стоит остановится, оглянуться и принять решение переходить на следующий уровень, выбить себя из зоны комфорта. Сегодня я перелистываю эту страницу своей биографии!
2️⃣ Еще я успел переболеть короной 🦠... Ну и как настоящий экспериментатор я прошел весь флоу с гос. поликлиниками и семейными врачами. Тут несколько основных поинтов: идиотизм процветает, но с другой стороны, семейные врачи пытаются сделать добро, но система их давит. Примеры идиотизма: только у нас могут догадаться в двух соседних кабинетах принимать коронавирусных с ПЦР тестами положительными на рентген легких, а в соседнем кабинете проводить вакцинацию. Люди рядом в очереди стоят (ну да, куда же без очередей)... Умно, ничего не скажешь. Тем не менее, семейному врачу спасибо, она разделяла прием людей с симптомами и подтвержденным диагнозом от остальных. А что относительно тестов? Делают и делают даже бесплатно, если от семейного врача работающим в государственной поликлинике направление, а если в частной, то никто не принимает в бесплатных лабораториях.
🚑 Никаких специальных карет скорой помощи нет, тех которые должны ездить и у симптомных пациентов делать забор на ПЦР тест. Вместо этого люди должны добираться своим ходом в поликлинику и сдавать сами. Стоит ли упоминать, что большинство с симптомами поедет на общественном транспорте? Т.е. на минуточку... Кафе, рестораны и даже магазины торгующие хозтоварами закрыты, даже те что с антисептиками и замерами температуры на выходе, а общественный транспорт без температурного скрининга и антисептиков осмысленно возит симптомных граждан. Мало того, еще и не гоняют людей с масками на рту и открытым носом... Кстати, на вакцинацию я был еще записан с января, но очередь не дошла до сих пор, а судя по скорости вакцинации, то получу ее между 2042 и 2056 годом (так виджет рассказал).
3️⃣ Пол года я уламывал приятеля из Google записать либо подкаст, либо сделать лайвстрим и поговорить о работе в Google предметно. И этот человек ни разу не средний по рынку специалист, а хардкорный инженер с большим опытом, который работал и работает с софтом камер на телефонах, камерах помощи парковки авто, 360 surround view и тп. Я уже обсудил с ним зоны и свои вопросы, но прошу и вас написать что вам интересно узнать или на какие темы поговорить. Пишите прямо в @noTieInIT_bot или @NoTieInITChat. Анонс будет скоро.
4️⃣ Меня очень часто ввязывают в дискуссии относительно QA Automation vs QA Manual. Я однажды работал с командой автоматизаторов (даже 2 попытки были), а потом отказался. У меня свои мысли когда это мешает продукту и бесполезно потраченные деньги. Потому я попросил ребят из QA Guild поучаствовать в лайвшоу, которые занимаются той самой автоматизаций. Вот и будем искать истину на стыке разных мнений. Скоро будет анонс.
💵 Так как же экономить на этапе оценки требований?Люся Сидорова хотела выйти замуж по расчёту... Но не смогла. Она гуманитарий.
Так уж сложилось на постсоветском пространстве, что большую часть требований пишут Product Manager, Business Analyst или т.п. персоны, а технарей к составлению требований допускают редко. Технарям достается роль в оценке хотелок. При этом почти всегда сперва пишутся требования и логика работы приложения, а затем его передают на оценку технарям.
Напомню про график из предыдущей публикации. Перетраты на исправлениях до 5 раз возникает когда технари и постановщики задачи начинают футболят в друг друга требованиями и оценками.
💊 Самая эффективная рекомендация! Можете ее показать своим менеджерам. Обьясняйте технарям всю задумку и идеи стоящие за этой задачей. Почти всегда инженер, который не просто делает работу, но и понимает зачем ее делает, предложит как срезать острые углы и может предложить слегка видоизменить требования чтобы сэкономить на этапе разработки.
После прохождения этого этапа в отношениях, можно переходить к более высокоуровневым вещам. Например, обучать базовым инженерным практикам нетехнических постановщиков.
В моем опыте были объяснения:
- как работает протокол HTTP, WebSocket
- как ведет себя браузер после запроса загрузки страницы и до закрытия табы
- что такое сессия пользователя
- как происходит балансировка нагрузки и почему два запроса подряд на разных серверах могут выполняться
- что за магия с cookies и local storage
- и многое друго...
❓Почему❓ Вот хочет реализовать постановщик логику работы чатов на WebSocket. В его мире “ДО” нажатие кнопки “отправить сообщение” было неразрывно связано с тем фактом, что сервер получил сообщение в риалтайме и обработал его. Когда объясняешь, что банально в момент отправки соединение может быть не установлено, может быть в процессе реконнекта и тп, то после этого человек уже формирует требования с учетом разных состояний соединения! Когда объясняешь, что у могут быть синхронные и асинхронные запросы, а пока ответ летел клиенту с сервера, то состояние на сервере могло уже поменяться, то качество проработки edge cases и fail-сценариев в требованиях вырастает в разы. Это и создает экономию на этапе написания требований.
Итого, на этом этапе рекомендую составить список “нюансов” из доменной области, задокументировать их и обьяснить детали. Также неплохо иметь чекисты перед выдачей требований. “Учтены ли таймауты в ответах”, “Учтены ли ошибки и проработана ли реакция на них“ и подобные чеклисты будут верными помощниками.
@noTieInIT
Service mesh, онлайн–интенсив 19–21 марта
Слёрм готовит интенсив для тех, кто работает на проектах с развитой или развивающейся микросервисной архитектурой.
Спикер интенсива — Александр Лукьянченко, тимлид в команде архитектуры Авито. Он раскроет механики работы service mesh и поможет подготовиться к внедрению технологии без даунтайма.
Для практики будем использовать проект без service mesh в Kubernetes-кластере. Задача — постепенно внедрить service mesh, отслеживая изменения.
Посмотреть программу на сайте: http://slurm.club/36DXaK8
🐞 Стоимость ошибки и изменений…
Ошибки любят списывать на разработчиков или QA. Это сделать проще всего. Таким поведение грешат менеджеры, ведь проще всего обьяснить своему же руководству о пофейленном проекте или задаче взвалив это на разработчиков. Нетехническим топам рассказать о том, что “разработчики козлы” проще всего, ведь они не могут вникнуть глубоко в суть и разобраться в проблеме. Можно еще уволить исполнителей и взять новых… чтоб наверняка.
⛔️ В современной статьях и литературе (в основном про Agile) приводят вот этот график, который очень упрощен и не показывает истинную трагичность. Всего-то выпилили значения по шкалам… Еще продавцы гибких методологий любят продавать историю, что использование XP практик делает “график плоским”, потому чтоб не профакапить, то юзайте XP.
Происходит это за счет уменьшения времени обратной связи на ошибки. Работая по TDD от момента написания кода до понимания что тесты попадали пройдет несколько минут, потому исправить такую ошибку проще. Это действительно правда, писали об этом Кент Бек и Мартин Фаулер, кстати, но это лишь часть правды.
Сегодня восстанавливаю справедливость! К этому посту я приатачил давно забытый график, но он не утратил актуальность даже спустя 40 лет!. Его автор - Barry Boehm и он опубликовал этот график в книге Software Engineering Economics. На этом графике отображены все этапы в разработке: от формулировки бизнес требований до исправлений в продакшне.
🔍 Расшифрую суть графика на примере. Если на этапе формирования требований к продукту ошибку в требованиях можно предотвратить и доработать за 1 час, то исправление во время разработки уже будет стоить примерно 10 часов. Если проморгать проблему и код ушел на тестирование, то ее исправление может затянуть на 20-50 часов, а если ошибка уехала в релиз, то и вовсе до 1000 часов!
Еще раз. Исправление ошибки на этапе проектирования в 100-1000 раз ниже, чем после выпуска релиза!
Сразу сделаю оговорку, что огромное число в 1000 раз применимо для продуктов с редкими релизами и доставкой софта на физических носителях (в те времена это были дискеты или ленты). Потому можете представить боль, когда клиентам приходилось слать обновления на физических носителях по месяцу и еще обучать персонал как обновление накатить. Сейчас стало чуть проще и накатить фикс можно по интернету и довольно быстро. Но цена все еще высока и это x100 от цены исправлений на этапе составления требований и архитектуры системы.
В нескольких следующих публикациях пойдет речь о практическом опыте исправления ошибок на разных этапах и сложности разгребания проблем из-за недоработки при планировании. Ну и, конечно же, несколько рекомендаций как поменять подход к разработке ПО дабы снизить стоимость ошибки. Stay tuned!
Сорямба. Автопубликация не туда была выставлена.
Но раз уже некоторым нотификейшн пришел, то микропост с анонсом. До всей вот этой истории, буквально за день записали с ребятами из QA Guild подкаст. Он должен выйти на днях. Там много материала про найм, про собеседования и подходы. Даже про бизнес затронули. Потому stay tuned, как только в паблик выложат, то поделюсь.
Еще раз сорри что некоторых тригернул месседж. А если кто хочет почитать про бюджет Украины 2020, то на @FinVam переопубликовано.
Вот прикладываю скриншот с самого первого отзыва. Тем кто умомнился в адекватности.
Напомню, 30 минут кол, 15 минут из них чесание ЧСВ. Потому как такой поток можно родить за оставшиеся 15 минут - загадка.
Околотехнический вопрос.
У меня лента взрывается огромным количеством булшита про Covid-19 (который SARS-Cov2). Я факт-чекаю как сведения про препараты, рассказывая что это булшит, либо делюсь исследоаниями последними. Дорогие подписчики, вам такое интересно? Ниже опрос, потому маякните.
🧨 Apple M1. Если Intel ничего не предпримет, то мы можем увидеть его закат.
Я не фанат Apple, хоть и пользуюсь Apple MacBook Pro 13 еще 2015 года, а недавно выбирал супруге ноутбук и остановился на Apple MaCbook Pro 16, хотя и перебрал множество других недешевых ноутбуков.
То что сейчас происходит - это выбивание стула из под Intel и AMD, никак иначе. Почему? Об этом ниже, в моем факт-чеке.
Сегодня появились в продаже новые MacBook Air, MacBook Pro 13 и Mac mini. Есть первые тесты производительности.
🔥По тесту Geekbench 5 в тесте на 1 ядре Apple M1 3.2 GHz уделывает MacBook Pro 16 на топовом Intel Core i9-9880H 2.6 Ghz и даже iMac 2020 года на топовом Intel Core i9-10910 3.6 GHz. Результаты синтетических тестов 1689 vs 1251 vs 1095.
🔥В multi-core тесте результаты 7288 vs 9021 vs 6869. При этом, у iMac 10 ядер, а у остальных по 8 ядер.
🔥Но! Эти тесты без эмуляции x86, а у M1 архитектура ARM, потому тот же Premier Pro для x86 систем будет медленнее работать. Ранее на Geekbench были замеры в режиме эмуляции и там результаты single core/multi-core были куда скромнее: 1313 и 5888. Но потом с Geekbench данные этих тестов удалили и оставили нативные тесты. Но интернеты помнят все. Даже с эмуляцией это быстрее чем Core i7 и Core i9. А что будет когда Premier Pro и прочие сделают поддержку нативную ARM?
🔥Эти тесты - это синтетика, стоит помнить. У MacBook Air нет вентилятора, а у MacBook Pro есть, потому я предполагал возможность перегрева при длительной нагрузке и будет происходить снижение производительности. Но я уже видел экспорт H264 4K видео и HEVC длиной в 10 минут, которые не привели к снижению производительности. Производительность тупо не падает!
🔥Еще под полной нагрузкой M1 нагрелся до 33 градусов по цельсию на корпусе на Air без вентилятора! Что повергло прямо в шок, ибо MacBook Pro 16 греется до 46-50 градусов, жужа как пылесос.
🔥Работа в Davinci, Final Cut и Premiere Pro с 4K видео работает как нативно (Final Cut), так и с Premiere Pro в режиме эмуляции x86 (Rosetta 2).
🔥Тесты Cinebench показали преимущество над Core i9-9880, 1498 vs 1183 в single core тесте. Правда Ryzen лидирует в multi-core тесте.
🔥Affinity тест: M1 уделывает iMac с AMD 580X
Числа выше говорят за себя. Но вот что еще… Apple подняла цены на официальном сайте на версии с Intel процессорами. Для примера, MacBook Pro 16 с Core i9-9880H, 16Gb RAM и 512Gb SSD стоит $2699. В то время как Apple MacBook Air с M1, 16Gb RAM и 512Gb SSD стоит $1499. При почти одинаковой производительности… Базовый Air против топового Pro… Давление ценой и качеством. Шах и мат Intel, ты зажрался!
@noTieInIT
🥋Навеяло... а как учился я сам? Часть 1.
После прошлого поста мне задали вопрос, мол, "а как ты сам учился, раз курсы поливаешь"?
Тут на меня нахлынули воспоминания и я начал вспоминать. Естественно, я читал книги. В самом начале это были библии языков программирования, которые обучали синтаксису и базовым вещам в разработке. В лицее где я учился, привет ЛНЗ, мы занимались анализом алгоритмов и структур данных, учились думать алгоритмически и решать задачи. Они не касались задачи реального мира и ни одна из решаемых задач мне не пригодилась в дальнейшем в энтерпрайзе. Бесполезно? Нет, это один из трех важнейших векторов, который позволили мне развиться как инженеру. Нас учили думать и понимать ограничения. Именно такие задачи, от собственных игрушек на Pascal до задачек с ACM и классики по Кормену, которые я дебажил дома на x386 с 40 МГц и 8 Мб памяти, научили понимать оптимальность структур данных и сложности алгоритмов. Это не то что сейчас вместо HashMap используют поиск по массиву и не видят разницу. Конечно, не увидишь, когда у тебя минимум 8 ядер по 2.5 Ггц+. Я же довольно рано осознал в чем проблема жадных алгоритмов, NP полных задач и т.п. Как это помогает, спросите? Это помогает искать оптимальное технического решение задачи, а в довесок жизненно необходимо для построения архитектуры в хайлоаде. Как это прокачать? Об этом еще будет отдельный пост, ибо я в рамках плана развития для коллеги подготовил флоу в этом направлении.
Пока же я оставлю интригу, ведь два оставшихся вектора не влезли в один пост, потому продолжение будет завтра, не пропустите!
-=реклама=-
Приглашаем вас на онлайн-трансляцию "Практика применения аналитических инструментов Oracle в дистрибуции Schneider Electric". Представители компании Schneider Electric расскажут, как с помощью Oracle Analytics Cloud они собирают и обрабатывают 90% данных автоматически.
Когда: 7 октября 2020 г. в 11:00 Мск
Принять участие: https://vk.cc/aAwIYe
♿️ Итоги трех кварталов с OKR
Вот подходит к концу третий квартал работы по OKR. Как и отмечали гости на стриме, как и заявлял Джон Дорр, команды учаться работать с OKR и адаптируются 3 квартала. Примерно ту же картину наблюдал и я. Показатели выполнения по OKR за 3 квартала оставляли желать лучшего. Я собрал те факторы, что влияют на выполнение негативно.
🔻 Наличие старых долгов. Когда люди ставят перед собой цели, чего ранее не делали, то забывают про большой пласт незавершенных задач и текучки. Она никуда не девается и над ней продолжают работать дабы добить уже и переключится на цели из OKR. Теоретически было понятно, что так и будет, должно было занять квартал, но затянулось на более долгий срок.
🔻 Работа над предыдущими OKR. После Q1 невыполненные цели частично были перенесены в Q2, частично выпали вообще. Но как и в предыдущем пункте, работы не были остановлены и шлейф тянулся дальше. Не допускайте ошибку! Если цели важны и не доделаны, не ставьте новые пока не завершите старые. Потому переносите все, а если не желаете переносить, то отказывайтесь от любой дальнейшей работы в этом направлении.
🔻 Формулировка целей. Людям нужно давать учиться на ошибках. При теоретической проработке, которую я вынес в статью, было понятно, что цели должны быть конкретными. Команды экспериментировали с целями и часто включали цели вида "увеличить что-то на X%". Данные цели плохи тем, что отсутствует хоть какой-то намек на стратегию по достижению этого увеличения на X%. Цели должны быть понятны, например, сделать A и B. Задача менеджеров и состоит в формирование набора таких целей A и B, которые позволят достигать увеличения желаемого показателя.
🔻 Нарушение правила 3-5 секунд для проверки прогресса целей и ключевых результатов. Забавная была ситуация, когда для одной из целей потребовалось создавать отчет по которому нужно было трекать продвижение. Сам отчет создавался уже в квартале с этой целью, что заблокировало чуть ли не половину квартала трекинг продвижения. Трекинга нет, потому нет возможности следить за выполнением, потому эффективность падает или вовсе не делаются задачи для достижения этой цели. Не мудрите, делайте проще.
Еще была идеологическая реорганизация. Что из этого вышло скоро напишу! Stay tuned.
P.S. Если кто пропустил, то ранее были публикации про фундаментальные факторы сервисных команд, факторы кросс-функциональных команд и сравнение этих подходов между собой.
Выше видео актуально для предпринимателей из Украины. Честно говоря, ошибся каналом и не туда поставил публикацию)
Так что, дорогие мои читатели не из Украины, простите за нецелевое для вас контент. Порадую вас завтра продолжением истории про трансформацию компании.
Ждите!
Вчера в Linkedin постучался психотерапевт, гештальт-психолог и все такое…
Я удивился даже, ведь обычно рекрутеры мне позиции python девелоперов предлагают, реже CEO/COO/CTO, но психолог - это что-то новое. Ну и только сегодня я выяснил, что причина такого интереса - это мое небольшое интервью для друзей, что вышло на этой неделе.
Пошарю его и здесь. Краткие тезисы:
- Что я думаю про 18-и летних синиоров (о господи, были же 23-летние, куда мир катится);
- О том как надо пахать;
- Что такое лидинг и как я менеджерил детей в садике (выпилили историю про то, как менеджерил летом детей колорадских жуков на огороде собирать, жаль);
- Про непопулярные решения;
- Почему топы получают больше;
- Где учится на СТО (нигде).
У меня, кстати, много забавных историй, только я не всегда задумываюсь что интересно вам, дорогие подписчики. Пишите же телегоботу @noTieInIT_bot и я расскажу (в перерывах между повествованиями трансформаций, которые происходят прямо сейчас).
https://www.itblabber.com/post/kak-stat-cto-v-25-let
🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 1.
Когда готовился предыдущий стрим по OKR, то в компании как раз проходили другие трансформационные процессы и они уже воплотились в жизнь. Рано говорить о результатах, но я донесу смысл, а еще хочу пройти по пути размшлений и разьяснений почему была выбрана такая стратегия, какие плюсы и минусы. Поговорить подробнее об этом. Мои вот эти все тексты направлены в первую очередь на углубление в аспекты менеджмента.
Сегодня расскажу о том подходе что был ранее. Проблематика довольно обширна, потому буду частями публиковать, ибо по обьему на небольшой роман бы сгодилось)
В компании была структура где присутствовали сервисные команды. Это когда есть отдельно backend, отдельно frontend, отдельно qa, аналитики… все отдельно. Когда product manager придумывал новую задачу, то она проходила технические команды и оценивался их эстимейт. Замечу, что несколько команд проводили оценку. Вот прошло от нескольких дней до нескольких недель, оценка составлена и принимается решение какие задачи делать. Конечно, на базе эстимейта, ведь мы хотим делать те задачи, которые менее затратны и дают наибольший возможный результат.
WUT? Что тут не так?
🔎 Время от идеи до получения результата значительно растягивается.
🔎 Это бьет негативно по мотивации. Все же хотят видеть результаты своей работы как можно быстрее? Это только тибетские ламы могут медитировать годами на рост сакуры, а в жизни все совсем иначе.
🔎 Переключение контекста. Это отвлекает и продуктивность падает. Об этой теме еще отдельно поговорю, ибо там много что сказать можно.
🔎 Через неделю некоторые узнать свой код не могут, а попробуйте теперь вспомнить детали задачи, которая была написана месяц назад? Это неэффективная перетрата времени.
🔎 Не возникает возможности копать глубоко. Чтобы преуспеть в каком-то деле, нужно совершенствоваться и погружаться в него. При поверхностных действиях результаты будут посредственные. Это чисто статистически, задумайтесь над воронкой.
Еще есть чего не так и негативные, впрочем, как и позитивные аспекты сервисных команд. Об этом в следующей части.
P.S. Друзья, если вам нравится контент, то делитесь им, делитесь каналом. Это очень поддерживает и стимулирует меньше спать и больше думать и писать. Я почти год на одном и том же уровне по количеству подписчиков. Чет тут не чисто)
👁🗨 "Дима, что дальше, ты где?"
За последние месяцы множество людей спрашивало чем я продолжил заниматься после Авроры. Наступил момент, когда я могу сделать анонс.
И так, пол года назад я решил начать сотрудничество с компанией BETER. Это продуктовая компания оперирующая в B2B сегменте, занимается организацией спортивных и киберспортивных турниров, все это стримится в live, строится аналитика, ведется статистика, а данные поставляются B2B клиентам. Цели ставим перед собой довольно челенджевые, а в процессе их достижения буду делится инфой и с вами.
Из нового для себя: добавилось много всего с Amazon AWS, а также появился .NET где много low latency, что прикольно.
Не очень прикольно лишь то, что IT рынок колбасит последний год. Об этом далее пойдет серия публикаций. Не переключайтесь)
Чат канала. Поехали!
Я несколько раз экспериментировал с возможностью оставлять комментарии в телеграме, но функционал настолько кривой, что был вынужден от него отказаться.
Вместо комментариев будет полноценный чат!
Встречайте, @noTieInITChat.
Велкам в чат!
🐞 Потери при недоработках планирования. Часть 2.
Факап из прошлого поста не стоил карьеры людей, но переписывать систему пришлось.
На этот раз собрали функциональные и нефункциональные требования и пришли к выводу, что нужно отказаться от монолита на PHP и строить на базе сервисов на асинхронном языке. Специалистов на рынке было больше со знанием Javascript и вопреки моей большой любви к Java я не рискнул с Java NIO стартовать проект: был большой риск не уложиться в сроки и не найти специалистов из-за крайне малого опыта Java разработчиков на нашем рынке с асинхронным IO.
В этот раз с Сашей, TL этого проекта, мы стирали фломастеры об доски не один месяц (actually, 2). К сожалению где-то потерялась фотка нашей проектной документации, которая была засвидетельствована на стопке листов A4, с рукописным текстом и вырезанных и вклеенных куском логики с других листочков. Жаль конечно, выглядело как Франкенштейн или как лоскутное одеяло… кому как угодно)
На выходе получили систему, которая вот уже 4-5 лет в эксплуатации и переживала смену слоев, но не смену общей архитектуры. Decoupling в действии. Мы потратили на первом этапе несколько месяцев на планирование и устранили теоретические проблемы еще на старте, а вот окупилось это с лихвой, ибо выкидывание целых двух слоев приложения (двух сервисов) заняло 1 неделю ударной работы (вот ссылка на эту часть истории из выступления на конфе, fyi).
Конечно, не все так радужно было и столкнулись с другими проблемами, которые были вызваны наличием большого количества сервисов/микросервисов:
🔸 оркестрация доставляла неудобства, да и еще доставляет дискомфорт по сей день)
🔸 tracing/debugging становится сложным
🔸 service mesh на объемах становится большой головной болью!
Когда писали эти сервисы, то изобретали свои велосипеды для борьбы с этими проблемами. По итогу, потеряли десятки тысяч USD пока обучались работать с service mesh и оркестровать, трейсить и дебажить. Но это все равно меркнет на фоне архитектурных. У вас же есть возможность поучиться на наших ошибках...
🐛 Потери при недоработках планирования. Часть 1.
В этой секции у меня речь о технической стороне пойдет. Потери при подобных недоработках или неверном векторе влияют меньше чем фундаментальные ошибки в требованиях.
Как-то мне достался продукт, который должен был работать с live видео: принимать потоки, транскодировать их в несколько качеств, отдавать пользователям. Одним словом - была работа с realtime. Ответственные лица приняли решение разрабатывать эту часть платформы на базе PHP и успешно полтора года пилили проект. Ну как пилили… Первые 9 месяцев что-то напилили, а остальные 9 месяцев пытались перемотать изолентой весь продукт дабы он не рассыпался. Product Manager хотел двигаться быстрее, перейти к следующим этапам, но все время команды только и выжирал технических долг. Так до меня дошел запрос вмешаться в процесс и разобраться что там творится, принять меры.
После плотной интеграции в продукт, пришли к выводу, что вообще выбран некорректно весь технологический стек и PHP плохо подходит по ряду причин:
🦀 Этот язык через пень-колоду поддерживает работу с асинхронностью, а система должна была обслуживать live видео, где множество процессинга и асинхронных событий. PHP обеспечивает меньшую пропускную способность и провоцирует большое количество затрат времени.
🦀 Он ориентирован на работу со stateless запросами: запрос поступил, скрипты обработки запустились, запрос выполнился и скрипты умерли. Сохранение состояния потоков между стартом-смертью скриптов возможно лишь посредством постоянной сериализации/десериализации данных и сохранения в базы данных или кэши. Это тоже перетрата.
🦀 Запустить процесс другой программы и его контролировать попросту невозможно без запуска сотен процессов, которые еще и блокируются ожидая input/output. Про phpDaemon и т.п. можете не писать, это та еще дрянь если с ней работать плотно.
🦀 При выполнении каждого запроса тратится 50-100ms только на бутстратпинг скрипта, ну и фреймворков заодно, если они есть.
После анализа приняли решение переписывать на другом языке.
Какие затраты? Команда из 6-8 человек полтора года двигалась не туда и это $300-400k слитых в унитаз и потеря как конкурентного преимущества за это время, так и потенциальной прибыли.
А теперь представьте, что у вас на проекте кто-то так факапнулся концептуально и все эти сражения с архитектурой, недоспанные ночи, постоянные баги и их латания - это всего лишь следствия халатности на проработке и потенциально весь отдел могут уволить не из-за их результатов, а ошибки лица принимавшего решение писать на этом стеке?
Welcome to real life, bro.
🎤 Подкаст! Про найм, про ставки и компетенции, про вопросы на собеседованиях и про флоу собеседований. Что выясняет хороший интервьюер?
Несколько недель назад я пришел в гости на подкаст к замечательным ребятам из QA Guild: Ярославу Пернеровскому и Сергею Пирогову. В ходе беседы прошлись по множеству тем связанных с наймом и знаете… этот выпуск содержит информацию, которая является квинтэссенцией моей философии. Сразу обозначу, что речь про IT, хотя 90% применимо к любой индустрии.
♥️ Краеугольный камень: с помощью современных технологий стоит создавать возможности для роста бизнеса, пользуясь этим как преимуществом, а не создавая обратное, когда технологии берут бизнес в заложники.
♥️ Красная линия: делайте всегда все что в ваших силах, не важно строите ли боинг или копаете грядку. Я замечал, что почти все знакомые, которые сделали себя сами, следовали точно такой же стратегии.
Подробности? А Вот темы!
🔹 Про собеседования
🔸 Откуда бабло в продукте
🔹 Сколько стоит нанять нового человека?
🔸 Почему люди обычно фейлятся?
🔹 Ставки vs компетенции
🔸 Про перспективы зарплатного перекоса
🔹 Челенджи найма в продуктовой компании
🔸 Что важно в резюме?
🔹 Какие вопросы задают и почему?
🔸 Кто виноват?
🔹 Влияет ли зп на сложность задаваемых вопросов?
🔸 Флоу собеседования
🔹 Как культурно объяснить, что нет
🔸 Тестовое vs код на гитхабе
Слушать на SoundCloud - https://soundcloud.app.goo.gl/KzFRT
Канал ребят - /channel/automation_remarks
P.S. Спойлерну. Так как ребята лидеры мнений QA комьюнити, то договорились о стриме где будем распинать/защищать автоматизацию тестирования и разберем каким компаниям это будет полезно, а какие может просто убить.
Еще немного годноты. Одна переписка - это рекрутеру, а вторая - техлиду.
Читать полностью…
💩 Самый неадекватный кандидат в моей карьере.
Давненько не было пятничного трешака. Прям история по свежим следам. Проводили очередной скрининг кандидатов на позицию PHP, но кандидат попался крайне неадекватный.
🔹 Назвал техлида лошарой.
🔹 Угрожал рекрутеру и техлиду.
🔹 Написал лживый отзыв и оклеветал компанию и интервьюеров.
🔹 Требовал связаться со мной, чтобы мне рассказать, как техлид тянет компанию ко дну.
Но такие кадры оооочень редко, но встречаются, но на данном примере я написал историю и даю флоу как разруливать такие вопросы. А еще для всех тех, кто ходит по собеседованиям... В публикации даю советы и для соискателей, ведь можно по неопытности угробить общение на собеседовании или даже получить дурную славу, а можно адекватно выйти из любой ситуации и сделать это в выигрышной позиции.
https://habr.com/ru/post/532620/
P.S. А если у кого есть плюсовалка на хабре, то подмогните быстрее вывести в топ. Данке шон!
А еще в дестоп и мобайл версии телеграма есть опция комментирования данного поста. Не стесняемся! Задаем вопросы, комментируем!
@noTieInIT
Еще бенчмарк M1 подьехал. Компиляция WebKit.
Читать полностью…
🥋Навеяло... а как учился я сам? Часть 2.
Внимание, продолжение первой части.
Какой же второй вектор? Это исследование чужого кода, поиск ошибок и уязвимостей. В те времена были самописные форумы, биллинги, сайтики с динамическим контентом, что-то налеплено на первые версии CMS... не так давно появился phpbb и wordpress. Было по фану ковырять публично доступные исходники и думать где может сломаться код, как вызвать переполнение памяти или где программисты нафакапили с фильтрацией данных. Вокруг еще были такие же единомышленники и происходил активный обмен опытом. Времени уходило огромное количество, зато я учился думать с другой стороны, не со стороны только true positive сценария выполнения кода, а с другой стороны, находя кучу мест где код может упасть. Я задаю такие вопросы и на собеседованиях, ведь инженер должен уметь думать как его код может поломаться и предугадывать это. Всех инженеров, по мере возможности, пытаюсь обучить, что это полезный скил, как сбор кубика Рубика в голове.
Третий вектор - бизнес задачи. Они подтянулись уже после. К тому моменту я видел как писали код другие люди и умел анализировать самостоятельно их решения. Было забавно играть в мысленные шахматы и размышлять почему именно такое решение, а не другое, чем руководствовался автор? На этой фазе было важно критическое мышление. По-сути, я строил оптимальный путь решения бизнес задачи с помощью технического языка (привет вектор 1), а потом искал в нем проблемы и улучшал в голове, еще до кодирования (привет вектор 2). Я занялся фрилансом и впрягся в проект, с которого сбежали все разработчики, бросили эту кашу из говнокода на заказчика, глючную и падающую. Проект был еще и нагруженный, ей нужна была отдельная VPS, а ни админов, ни QA не было. Работа для человека-оркестра. Это был чистый кайф! У меня была возможность использовать скилы по анализу производительности и поиска багов, тестировать свои гипотезы и проводить замеры производительности, научиться собирать и анализировать метрики, та даже деплоить без даунтайма я научился еще тогда. За каждой из задач что я решал стояли бизнес задачи: не лежать и не терять деньги пока идет миграция, увеличить пропускную способность, работать с неструктурированными данными, делать отказоустойчивость и т.п. Некому было меня учить, потому оставалось учиться самому, используя статьи от гуру топовых компаний, общаясь онлайн с теми же единомышленниками. Когда же появился Хабра, то это стало откровением, новым толчком для инженерии в СНГ.
Рассказывать я могу часами, настолько обширна эта тема и столько крутых воспоминаний ! Я пытался уместить мысли в сжатую форму и сделать это полезным. Я даю себе отчет, что это может быть интересно лишь тем, кто проходил через такое, а часть людей резонно может подумать "о чем он вообще трет?". Потому... барабанная дробь. Я добавляю новую фичу на канал и открываю возможность комментирования постов!. Велкам, пишите в камменты что вы хотите услышать, куда мне углубиться, ну или просто выражайте свое мнение по вопросу и будем разбирать. Если хотите не публично высказаться, то пишите боту и я вырежу никнейм. Ну что? Погнали!
P.S. Если кто знает, как вернуть моего любимого 🦀 в голосовалке и при этом оставить камменты - напишите плз, я не нашел, жалко краба =(
🐒 Не хочешь программировать - стань разработчиком. Дно пробито.
Для нашего рекрутмента давно уже есть определенные маркеры по кандидатам. Да и собеседующие смотрят на предыдущий опыт и образование. Когда у человека в CV указано, что он выпускние курсов GoIT, компьютерной академии ШАГ, SkillUP, ITEA, то это индикатор того, что с высокой вероятностью будет “все плохо”. Я уже молчу про зашквары самих курсов, а сужу по опыту прошлых собеседований. Вроде по CV все хорошо и закрываем глаза на “сомнительный опыт” таких курсов… доходим по собеседования и в очередной раз убеждаемся, что это было зря потраченное время. После очередной попытки просто перестали смотреть людей с такой “черной меткой”.
Еще ни один человек из знакомых не заявил, что нашел адекватов после этих курсов. Так что если кто из подписчиков выбирает пойти ли на курсы, то задумайтесь. Помимо потраченных денег и времени есть вероятность, что и другие компании не будут серьезно воспринимать как кандидата.
Ниже картинка с рекламы GoIT. Отлично характеризует их контингент и целевую аудиторию… Спасибо, не нужны такие.
🔰Один из важнейших советов при работе по OKR: нужно создавать рабочие стратегические группы!Ведение войны подразумевает два совершенно различных вида деятельности: организация и ведение отдельных боев и увязка боев с общей целью войны. (с) Карл фон Клаузевиц, прусский военачальник, военный теоретик и историк.
При анализе рисков при внедрении OKR я наткнулся на публикацию Harvard Business Review и выводам из публикации посвящен данный пост. В исследовании шла речь о том, что менеджмент часто ставит стратегические цели (стратегические OKR, уровня всей компании), но не задает вектор как эти цели достигать. Цели есть, а стратегии нет. Вероятность неудачи выполнения проектов при подобном классичесмком внедерении OKR составляла более 70%.
Почему так происходило?
1️⃣ Команды не всегда понимают какие их действия приблизят к выполнению стратегических целей.
2️⃣ Командам часто нужны конкретные подсказки какой вектор выбрать.
3️⃣ Не всегда есть полномочия брать отвественность за глобальные и дорогие изменения и за стратегическое планирование.
4️⃣ Ну и люди часто боятся рисковать и считают, что на то и есть менеджментв высшего звена дабы решать куда двигаться.
Эта тема плотно касается лидерства и задействованы очень схожие механизмы.
Что делать?
В том же исследовании упоминалось, что fail rate понижался в разы в тех компаниях, которые создавали инициативные рабочие группы для определения вектора и набора шагов для реализации стратегии. Если не перекладывать отвественность на команды, а давать подсказки и лидерский вижн, что достичь результат можно сделав A, B и C, то команды примут это с высокой вероятностью и будут понимать что же им делать.
Не просто так пост начался со слов Карла фон Клаузевица. Цель военного руководства - выиграть войну. Кросс-функциональные команды очень похожие на автономные дивизии, которые проводят тактические действия. Задача генерального штаба состоит в выработке именно стратегии для дивизий. Когда генерального штаба нет, то сколько боев не проводи, но войну не выиграть. Как говориться, все давно придумали до нас.
Значит нужно создавать подобный генеральный штаб. Так у нас появился BUSINESS & STRATEGIC RING...
🍷 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 3.
Основные минусы сервисных команд я уже привел. Но не стоит думать, что все прям мега плохо и использование их - это ошибка.
У сервисных команд есть большое преимущество. Цена разработки ниже. Когда каждая мини-команда полного цикла (кросс-функциональная) имеет своих разработчиков, тестировщиков и аналитиков, то кто-то обязательно будет простаивать, а кто-то будет перегружен.
Когда люди считают этот простой, то возникает логичное желание "оптимизировать" загрузку и не допустить простоя каждого отдельно взятого человека. Как? Сделать сервисные команды и аутсорсить к ним задачи. Можно масштабировать количество людей в сервисных командах. Если нужно в команде всего 2 человека и они справляются, то ок, пусть будет 2, а если другая команда не справляется с 10 чел, то нужно взять еще парочку.
Вот те 2 человека могут обслуживать не только одну команду, а могут работать с множеством людей. Под обслуживанием я понимаю либо генерацию задач, либо их выполнение. Люди меньше плюют в потолок, на бумаге производительность выше. Стоимость содержания команд ниже.
Экономия может достигать 30%. Но как отмечал уже ранее, для стартапов и продуктов, которые ищут свои ниши, стоит концентрироваться не на экономии ресурсов, а на быстрой проверке гипотез и поиска того самого грааля ниши.
Еще бонусы - это bus factor ниже, т.е. взаимозаменяемость выше. TL меньше переживает, если Иннокентий в саббатикал уедет в Тайланд на год, если у него в сервисной команде еще останется 9 удальцов переднего конца frontend разработчиков.
Контролировать и развивать проще... Особенно для control freaks. Кстати, я и сам контрол фрик и прям делал над собой усилия, чтобы отпускать ситуацию. С сервисными командами появляется больше контроля, больше формализации, больше минералов.
Но пропадает одно - концентрация на общей цели...
@noTieInIT
🎥 Новое видео. Грабеж банками с двойной конвертацией валюты полученной ФОП.
Я ранее писал на канале кусочек этой истории. Вся история в деталях в видео сегодня. Все ФОП работающие с ВЭД и получающие валюту на счёт вынуждены продавать ее банку, а полученную гривну переводить на счёт физика и покупать валюту снова.
На такой операции теряется по 35-50 копеек для доллара и евро, а банк оставляет себе 1.5-2% средств на таком двойном обмене.
Один из подписчиков спросил в комментариях про возможность прямого вывода валюты на свой счёт за рубежом... для ФОП 3 группы на единой налоге. Я связался о свифт департаментом Привата дабы проверить этот флоу и получил зелёный свет.
Но что из этого вышло? Смотрите в видео!
https://youtu.be/xc-6D3_h4Pk
🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 2.
Когда есть целая команда, допустим backend и она сервисная, то ведет она себя как мини-аутсорс. Если не ведет, то с высокой вероятностью скатится в такой мини-аутсорс. В команду вбрасывают грязевой ком из плохо сформулированных задач, а на выходе ожидают Рафаэлло. Но оно все не выходит и не выходит, это чертово Рафаэлло. Знакомо?
Порой начинается охота на ведьм и все скатывается в обвинение разработчиков, а разработчики обвиняют постановщиков. Правы и первые, и вторые. Истинная проблема заключается в том, что у участников процесса происходит отрыв от истинной сути, ради которой задача и ставилась. Сервисной backend команде абсолютно непонятно какую цель преследуют продукты. Сервисная же команда как аутсорс работает Получил... распишись.
Годами я доносил до тимлидов сервисных команд, что стоит вникать в суть задачи, которая прилетает на разработку. Стоит пытаться разобрать мотивацию постановщика и докопаться до сути, поняв какую проблему бизнеса он пытается решить. Очень часто бывает, что задачи ставят уже с детализацией “как сделать”, а не “зачем делать”. Продакт менеджерам я всегда говорю, что сформулируйте цель и проблему, предложите варианты решения, обсудите с исполнителями, аналитиками, службой поддержки свои варианты и послушайте что предлагают люди, которые связаны или влияют на достижение цели.
Наблюдая за результатами моих советов, я пришел к умозаключению, что это не особо сильно помогает и создается больше видимости действий, чем реальных действий. Мало того, увеличилась цепочка коммуникации.
Посчитаем на пальцах. Продакт менеджер проводит встречи с 3 командами, дабы донести свою идею. Тратит на это N часов, включая фоллоу-апы. Если он по-отдельности проводит митинги, то потратит 3*N часов своего времени и суммарно 3*N часов тимлидов. Можно оптимизировать до одного митинга, и тогда затраты всех участников составят 4*N часов. Затем тимлид тратит время на обдумывание, может поэкспериментировать, расписывает эту задачу и доносит до конечного исполнителя. Это еще затраты на коммуникацию с конечным исполнителем. Конечно же, включается испорченный телефон и исполнитель получает не цель продакт менеджера, интерпретацию этой цели из уст тимлида, может цель вообще видоизменится и тимлид свою цель озвучит. Порой возникают трудности и выполнить желаемое не получается. Маховик начинает вращаться в обратную сторону: проходят снова митинги, выяснения что делать и согласования. Если медиатором служит тимлид, то происходит тройная трата ресурса (конечный исполнитель-тимлид, тимлид-менеджер, тимлид-исполнитель). Если еще и переписать после этого задачу придется, то это снова повторные согласования и все по кругу. Ах да, все же заняты, митинги с уточнениями происходят когда у всех есть время. Это смещает срок до получения результата, как уже писал в прошлом посте.
Неэффективненько. Пробовали напрямую менеджера и исполнителей связать, чтобы вовлечь человека в выполнение задачи и наладить прямую коммуникацию. Вылезли другие грабли… Тимлид должен быть в курсе, ибо он же отвечает за работу исполнителя. Все по кругу...
Что еще не так и есть ли выход? Об этом далее… @noTieInIT
👻 Как известно, Google и другие топовые компании мира, такие как: Linkedin, Twitter, Netflix, BMW, Samsung, UBER, Amazon используют метод постановки целей и достижения желаемых результатов — OKR. Сундар Пичаи, CEO Google, даже заявил, что благодаря OKR Google стал той компанией которую мы знаем (нет, это не про империю зла, как уже могли подумать).
Наблюдая за чужим опытом, я начал изучать что такое OKR и как же он помогает. Пару месяцев, читал книги, статьи, собирал чужой опыт по крупицам, общался со знакомыми кто использовал эту методологию. Ну какой я задрот к деталям и качеству вы и так знаете. В конце 2019 я инициировал переход в Aurora Technologies на OKR. После полной пропитки идеей и подходом себя самого, была стадия продажи этого решения другим участникам бордпака. После продажи идеологии, наступил черед формализации и донесения до всех команд и людей информации об этом инструменте. И мы запустились.
Пережили уже 2 этапа планирования и успели поменять некоторые подходы. Проблем с внедрением OKR оказалось немало. Они всплывают и спустя 5 месяцев, а потом от нашего HRD узнал, что ее предыдущая компания адаптировалась почти год к OKR. Кста, минутка рекламы, канал нашего HRD, вот он, на украинском, авторский. Но так как мы знакомы и с CTO этой компании, то с ним я начал обсуждать с чем же они столкнулись.
Слов за слово… и мы уже придумали записать видео с 4 компаниями, которые живут и работают по OKR и имеют разный размер, разную структуру, культуру. Но всем им, в том или ином виде, OKR помогают быть успешными. А потом начались грабли с поставкой техники для записи, затем карантин… Несерьезно пообещать и не сделать, потому мы решили сделать стрим на эту тему!
Встречайте, стрим #2.
🔥 OKR. Опыт внедрения системы целеполагания в компаниях.
Без воды, булшита и всего такого. Кто видел мои доклады и выступления, посты и прогнозы, прекрасно понимает какую концентрацию полезной инфы я стараюсь донести.
Наш звездный состав:
— Алексей Солнцев (CTO, Kasta, ранее известная как ModnaKasta)
— Дмитрий Гринь (CTO, Jooble)
— Евгений Пилянкевич (CEO & CTO, Cossack Labs)
— Дмитрий Меньшиков (кто бы это мог быть? 😄)
Стрим будет бесплатный и интерактивный. Вопросы уже сейчас можно и нужно задать https://app.sli.do/event/qpkn7ib3/live/questions. Вопросы во время стрима чуть ниже имеют приоритет, потому прошу задать в sli.do, а на стриме уточнения. Нам нужно подумать тоже.
Что можно вынести из ивента?
● Ознакомитесь с кейсами от 4-х разных компаний
● Поймете как работает система OKR на практике
● Сможете использовать методологию OKR для себя, команды и для достижения целей компании
● Узнаете заранее о возможных нюансах, сможете учесть все подводные камни, избежать факапов
● Получите от внедрения системе OKR только преимущества (быстрый рост, достижение результатов, синхронизация задач,мотивация команды)
Для кого будет полезно?
Для руководителей, топ-менеджеров, собственников компаний, для HR менеджеров, HR директоров, тимлидов, руководителей направлений и департаментов, для всех людей, которые стремятся увеличить свою эффективность и добиваться целей!
🎥 Ссылка на стрим (жмите кнопку “Напомнить” чтобы не пропустить): https://youtu.be/NuwPzwM5tnw
🍸Чтобы не забыть, сделали и ивент в фейсбуке, чтоб напоминал:
🚀 Если вы не знаете что такое OKR, то я выложил запись и текст. В том же виде, как давал это в Авроре. Я убрал всю воду, консолидировал чужой опыт. Теперь делюсь бесплатно во имя науки!
http://dmenshikov.com/2020-04-21-okr-goal-setting-system/
Друзья, делитесь каналом с друзьями, контент все круче и круче, а органика как-то запнулась. Ничто не мотивирует так двигаться вперед, как ваша поддержка и понимание того, что это приносит пользу.
