Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. Размещение рекламы: @tanyasanovna Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Идеальный отпуск для выгоревших тимлидов
Когда ты становишься руководителем, полностью отключиться от работы невероятно сложно.
Даже в отпуске ты каждые полчаса обновляешь Slack, чтобы узнать, не упал ли сервис, за который ты отвечаешь, не переругались ли дизайнеры с разработчиками, и не решил ли Петя, который подозрительно части обновляет профиль на LinkedIn, все-таки уволиться с концами.
А здоровая менталочка, как мы уже с вами много раз обсуждали, для руководителя невероятно важна, ведь любые проявления тревожности очень быстро переносятся на всю команду.
Так вот, хочу порекомендовать вам классный способ поддержать свое здоровье и эмоциональное состояние, не выделяя самому слишком много времени на планирование восстановительного отпуска.
Ребята из Rehab Family, специализирующиеся на организации психологического восстановления, могут забрать все на себя. Благодаря индивидуальному подходу вам подберут подходящую восстановительную программу с учетом всех нюансов состояния, потребностей и занятости.
Есть разные варианты – и полный отпуск, и совмещение с работой.
Короче говоря, чтобы перезагрузиться от происходящего, приезжайте сменить обстановку и перевести дух наедине с природой в Rehab Family, место ментального здоровья и гармоничного состояния.
👉Все подробности тут
Реклама. Рекламодатель ООО РЕАБИЛИТАЦИЯ. СЕМЬЯ. ИНН 9709003760. Erid: 2Vfnxwtzfoe
Как выполнять решения, с которыми ты не согласен
Представьте, что вы были частью группы, принимающей важное решение, касающееся вашей команды. Например, про закрытие проекта, которым вы занимались. Вы высказали аргументы в защиту своей позиции, яростно спорили с альтернативами, но в итоге было принято решение, с которым вы в корне не согласны. Дальше спорить бессмысленно, остается принять его и исполнить. И вот дальше начинается самое сложное – теперь это решение надо объяснить команде.
Некоторые менеджеры в таких случаях напускают на сеья притворный энтузиазм и начинают подыскивать аргументы, в которые не верят сами. Другие встают в позицию "я прав, а все вокруг мудаки" и ищут поддержки в команде, настраивая ее против всех. Оба подхода – фиговые. Вместо этого попробуйте практиковать "disagree and commit". Будьте прозрачны, объективно объясните аргументы обеих сторон, скажите, что не согласны, что принятое решение правильное, но при этом исполнить его все равно нужно, потому что время дебатов закончилось и вечно буксовать не получится.
Вот еще несколько советов из статьи:
👉Дайте членам команды выговориться на 1-1. Не стоит пытаться переубеждать их, просто поддержите.
👉Максимально избегайте выстраивания ментальности "мы против них", выливая свои фрустрации на команду.
👉Не откладывайте рассказ о неприятных для команды новостях, как бы этого ни хотелось.
👉Будьте последовательны и консистентны, рассказывайте всем одну и ту же честную версию событий.
Еще в статье мне понравился заключительный блок про то, как объявлять письменно о таких больших спорных решениях:
👉Только факты, никаких эмоций.
👉Осветите следующее: кто принимал решение, какие проблемы решались, что именно было решено, на кого влияет решение, когда оно вступает в силу, какие следующие шаги.
👉Если какие-то детали, например, конкретный план действий еще не определены, напишите об этом явно.
👉Запланируйте Q&A сессию, где все смогут задать свои вопросы.
Как показывать свое признание другим людям
В статье много советов как для менеджеров, так и для индивидуальных контрибьюторов. Я выбрал несколько, которые мне понравились:
👉Используя чье-то предложение, или обсуждая чью-то идею на митинге, всегда старайтесь органично упомянуть ее автора.
👉Если кто-то пропустил важную командную встречу или вечернюю посиделку, пришлите ему фотографию, видео или сообщение про то, что его не хватало, и по нему скучали.
👉Если вы знаете карьерные цели своих сотрудников (а вам хорошо бы их знать), старайтесь почаще подкидывать им релевантные возможности – выступить перед нужными людьми, подключиться к проекту, который их разовьет, делегировать подходящую задачу.
👉На митингах старайтесь давать явную возможность высказаться самым тихим и молчаливым участникам.
Умер Даниэль Канеман
Вспоминая когнитивные искажения, нельзя не вспомнить главного их популяризатора, поведенческого экономиста Даниэля Канемана. На прошлой неделе он умер 💔
Если вы по какой-то совсем непонятной причине еще не читали "Thinking Fast and Slow", обязательно запланируйте себе. Лично мне эта книга дала, наверное, самый значимый буст в понимании и себя, и других людей.
Про эффект IKEA
Эффект IKEA – когнитивное искажение, суть которого в том, что люди гораздо более сильнее эмоционально привязаны к вещам, к созданию которых они приложили руку. Одно из исследований даже померяло степень этой привязанности – исследуемые были готовы заплатить на 63% больше за мебель, которую они собирали сами.
Это когнитивное искажение относится не только к мебели и к успеху бизнеса IKEA. Как показывает статья, оно распространяется и на изменения в организациях. Если вы хотите, чтобы оно сработало в вашу пользу:
👉Всегда объясняйте причину внедрения какого-то изменения, и проверяйте, что все участники действительно согласны с решаемой проблемой.
👉Вместо того, чтобы спускать на команду готовое решение, начинайте с драфтов, готовых где-то на 20%.
👉Не просто вовлекайте людей в работу, а делегируйте им проработку конкретных кусков.
👉Давайте людям достаточно времени подумать над вашими предложениями и дать фидбэк.
👉Не бойтесь того, что совместная работа с большим уровнем вовлеченности замедлит вас. На старте вы действительно притормозите, зато отыграете все потери на этапе внедрения изменения.
Когда парное программирование приносит больше всего пользы
В задачах с высокой степенью определенности:
👉Программист, отвечающий за задачу, недостаточно сильный, чтобы быстро с ней справиться. Такое может происходить, например, с джунами. Добавление к нему в пару опытного разработчика поможет и с задачей быстрее справиться, и подкачать навыки джуна.
👉Программист сильный, но недостаточно знаком с кодовой базой. В таком случае парное программирование существенно ускоряет получение контекста.
В задачах с высокой степенью неопределенности скилл и знание кодовой базы уже не настолько критичны, и в целом парное программирование тут полезно почти всегда. Вот почему:
👉Помогает избегать туннельного видения. Часто первое, с чего программист начинает решать неопределенную задачу – написание прототипа. В итоге первоначальная реализация прототипа может сильно ограничить возможные способы решения задачи и создать белые пятна. Второй взгляд сильно помогает с этим бороться.
👉Ускоряет фидбэк луп обсуждения и проверки идей.
👉Помогает побороть психологические блокеры, мешающие приступить к непонятной задаче, и перестать прокрастинировать.
Яндекс открыл регистрацию в Школу менеджеров 2.0
В этом году программа школы станет еще более практикоориентированной и сфокусируется на сложных кейсах из реальной жизни. Студентов школы ждет экспертное наставничество от С-level руководителей Яндекса, актуальные знания по аналитике, архитектуре сервисов, юнит-экономике и маркетингу.
Отборочный процесс включает тестовое задание, видеоинтервью и последующее собеседование в онлайн-формате. Одним из ключевых требований для кандидатов — технический бэкграунд или опыт работы с командами разработчиков.
Прошедших отбор ждет 3 месяца интенсивного обучения: 8 недель онлайн и 4 недели для реализации проекта в команде в офисах Яндекса в Москве, Санкт-Петербурге или Екатеринбурге. Гибкий график позволит совмещать учебу с работой.
Прием заявок уже идет — регистрируйтесь и получите тестовое задание, а чтобы лучше подготовиться, воспользуйтесь подборкой полезных материалов.
Разработчики Yandex Cloud расскажут, что скрыто «под капотом» сервисов
4 апреля мы проведем уже ставший традиционным митап about:cloud – infrastructure, где расскажем об устройстве инфраструктурных и сетевых сервисов.
На встрече мы поговорим:
• как устроен сервис, связывающий мир виртуальных сетей с классическими маршрутизаторами и сетевыми устройствами,
• как мы подружили Yandex Monitoring и Prometheus®,
• про компоненты для построения высоконагруженного и стабильного облачного DNS,
• о сервисе для проведения нагрузочного тестирования и анализа производительности,
• об устройстве сетевого блочного хранилища и типах дисков.
about:cloud – infrastructure – это возможность обменяться опытом с разработчиками, архитекторами, devops-специалистами, обсудить решение «нетривиальных» технических задач, получить ответы на самые «горячие» вопросы.
Присоединяйтесь
Метод Монте-Карло для прогнозирования сроков
За последний месяц мне нужно было построить сразу несколько финансовых моделей и моделей роста на основе довольно ограниченных объективных данных о размере рынка и конверсиях. Получить хоть какое-то представление о возможных разбросах значений очень помог метод Монте-Карло. И вот как раз наткнулся на статью, где подробно разбирается, как его использовать в Google Sheet, и применять для прогнозирования сроков выполнения задач и приоритизации бэклога.
Нам надо двигаться быстрее
Эту фразу можно услышать практически в каждой компании, кого из топ-менеджеров вы бы ни спросили. С вопросом "а куда именно нам надо двигаться", или, еще хуже, "а зачем нам двигаться быстро", так легко они уже не справляются.
Конечно, рыночек часто мотивирует компании ускоряться. При этом не стоит путать реальную нужду со следующими похожими на нее вещами:
👉Ностальгия. Когда-то компания была маленькой, двигалась и менялась быстро. Но рост всегда несет за собой сложность и неповоротливость, и вернуться в прошлое при всем желании не получится.
👉Хаотичность. Быстрая и интенсивная работа сама по себе не всегда несет за собой пользу для бизнеса.
👉Героические усилия. В компаниях, живущих от пожара до пожара, частым элементом культуры становится поощрение тех, кто, превозмогая все, решает очередную проблему. Это ведет не только к выгоранию, но и к тому, что компании разучиваются работать над долгосрочными проектами.
Когда от вас требуют двигаться быстрее, задайте следующие вопросы:
👉Зачем? Откуда вообще берется это требование, чем оно продиктовано, как согласовано со стратегией компании.
👉Какого типа скорость нужна? Идет ли речь о скорости поставки ценности или скорости адаптации к внешним изменениям на рынке?
👉В каких конкретно областях бизнеса надо двигаться быстро? Ускориться одновременно везде нельзя, да и не имеет смысла.
👉Что мы готовы заплатить за скорость? Ускорение не дается бесплатно, нужно чем-то пожертвовать. Например, качеством.
👉Какая поддержка будет оказана? Для того, чтобы команда работала быстрее, нужно, чтобы ее вход и выход были так же оптимизированы – грамотный менеджмент, понятные требования, налаженная автоматизация.
Как декомпозировать проекты
Уметь декомпозировать свою работу на маленькие составные кусочки – это навык, которому довольно сложно научить. На ум просится довольно пошлое сравнение с ездой на велосипеде. Если вы попробовали декомпозировать проект, сделали это фигово, настрадались от своего кривого подхода сами или заставили страдать других людей, то в следующий раз, скорее всего, получится лучше.
Автор статьи делает попытку алгоритмизировать свой опыт. Мне кажется, получилось довольно неплохо, и я сохранил себе статью, чтобы в будущем скидывать джунам. Алгоритм такой:
👉Перечислите все задачи, которые на ваш взгляд надо сделать, чтобы завершить проект.
👉Для каждой задачи выпишите последовательный список шагов, которые надо сделать, чтобы ее завершить.
👉Посмотрите на каждую задачу, и попробуйте понять, достаточно ли конкретно она определена. Понять это помогут несколько вопросов: "Понятно ли, какое изменение требуется сделать?", "Могу ли я понять, как должна выглядеть задача в состоянии сделано?", "Если я превращу список шагов в тудушки, достаточно ли сделать их все, чтобы выполнить задачу?", "Достаточно ли у меня информации, чтобы начать работать над задачей прямо сейчас?".
Про внедрение стандартов
Сталкивались ли вы когда-то с тем, что в разных местах продукта или кодовой базы для работы с одними и теми же концепциями используюся абсолютно разные подходы? Пример на скриншоте – различные форматы определения даты и времени, использующиеся в разных подсистемах. Помимо дат, такой зоопарк часто может коснуться способов ввода номера телефона, валют, локалей и языков. Чем больше в таких вещах хаоса, тем сложнее поддерживать систему, проще допустить баги на проде, а, значит, испортить пользовательский опыт.
Статья напоминает про то, что в решении таких проблем разумно обратиться к существующим стандартам и выбрать подходящий для вас. Например, ISO, IETF RFC, ICANN. Даже если внедрение стандарта потребует переписать какой-то существующий код и мигрировать данные, в долгую, скорее всего, это вложение окупится.
Несколько фактов про оценку сроков разработки
👉Задачи с маленьким сроком чаще всего недооцениваются, а с длительным – переоцениваются.
👉Конкретные разработчики имеют тенденцию либо постоянно недооценивать, либо постоянно переоценивать задачи. Причем, скорее всего, это связано с их индивидуальным риск-профилем.
👉Около 30% всех оценок оказываются точными, 68% – в пределах двух раз от изначальной оценки, 95% – в пределах четырех раз.
👉Точность оценки отдельных разработчиков не меняется с опытом и практикой.
Эти выводы основаны на доступных публично датасетах с прогнозами и реальными сроками выполнения задач, и на исследованиях Magne Jørgensen.
На каких трех вещах надо фокусироваться менеджеру
1️⃣Direction – делать так, чтобы каждый член команды четко понимал, что и когда от него ожидается
Это понимание важно сразу на нескольких уровнях, причем на каком конкретно из них фокусироваться зависит от конкретных людей:
👉Смысл – зачем вообще существует компания, разрабатываемый командой продукт, и сама команда
👉Вижн – долгосрочная картина того, куда конкретно вы должны прийти
👉Цели – понятные и измеримые ориентиры на ближайшее время
👉Приоритизация – очень четкие и понятные ответы на вопросы, важнее ли задача Х чем задача У.
2️⃣Coaching – коучить людей, помогая им понять, что им стоит продолжать делать, и как стать лучше
👉Работайте не только над исправлением недостатков, но и над прокачкой сильных сторон
👉Готовьте свою положительную обратную связь не менее внимательно, чем негативную
👉Давая обратную связь, будьте очень конкретными, и указывайте на детальные аспекты поведения
👉Подталкивайте людей к тому, чтобы они выдавали обратную связь вам
3️⃣Career – инвестировать в карьерное развитие своей команды, думая о нем за рамками следующего промо, и даже за рамками текущей компании
👉Постарайтесь понять, как каждый человек в вашей команде принимал карьерные решения до этого момента, что их драйвило
👉Попробуйте пофантазировать вместе про то, куда человек хотел бы прийти в самой идеальной картине мира, не учитывая ограничений вашей компании
👉С пониманием прошлой истории и идеального будущего составьте вместе план конкретных шагов, которые помогут человеку приблизиться к его мечте
СУБД от СберТеха прошла тест на совместимость с «1С:Предприятие»
Российский разработчик ПО СберТех и фирма «1С» успешно завершили тестовые испытания по взаимодействию своих флагманских продуктов Platform V Pangolin SE и платформы «1С:Предприятие».
Platform V Pangolin SE (начиная с версии 5.3.2) содержит расширения и доработки в ядре, которые учитывают специфику платформы «1С:Предприятие» (начиная с версии 8.3.23). Интеграция продуктов при создании ИТ-решений позволит компаниям поддерживать стабильную работу при построении и эксплуатации высоконагруженных информационных систем различного назначения.
Программный продукт компании «1С» предназначен для автоматизации любого бизнес-процесса предприятия. Platform V Pangolin SE —это система управления базами данных (СУБД), которая основана на хорошо зарекомендовавшей себя открытой СУБД PostgreSQL. Оба решения зарегистрированы в Реестре российского ПО и полностью подходят для задач импортозамещения, а также обеспечивают высокие показатели надёжности, безопасности, доступности и производительности.
Узнать больше о возможностях Platform V Pangolin SE можно здесь.
Ошибки во внедрении OKR
Несколько лет назад я писал статью про то, как мы в Авито работали с OKR. В частности, рассказывал про потенциальные проблемы, с которыми вы можете столкнуться. Сегодняшний материал из заголовка натолкнул меня на мысль о том, что многие из довольно очевидных проблем меня вообще обошли стороной благодаря тому, что у компании уже была очень сильная data-культура. Люди хотели и умели считать деньги и влияние на них продуктовых метрик.
Но если бы такой культуры и сильной аналитической системы на тот момент не было, скорее всего, OKR бы провалились. Вот какие фейлы выделяет автор статьи:
👉OKR навешиваются поверх delivery-first подходов с роадмапами и дедлайнами.
👉Команды не вовлечены в работу с данными, а просто получают какие-то сигналы от аналитиков, работающих как черные ящики.
👉Лидеры компании не готовы к неопределенности, поэтому пытаются сохранить контроль над сроками.
👉Больше времени тратится не на работу с данными, а на подбор подходящих key results.
👉OKR уровня компании и уровня команд не связаны друг с другом из-за того, что финансовые и продуктовые метники плохо провязаны.
👉OKR навешиваются на функциональные группы вместо кросс-функциональных команд, из-за чего постоянно происходят конфликты приоритетов.
👉OKR выставляются на год, но меняются каждые три месяца.
🚀 TradingView ищет iOS разработчика с опытом работы в платформенной команде.
Стек
Swift, Gitlab, Fastlane, Ruby, SPM, iOS 15+
Задачи
Архитектура, Инфраструктура, Модуляризация, CI/CD
Продукт
Более 10 миллионов пользователей по всему миру. Наши решения используют Тинькофф, Forbes, Revolut, Interactive Brokers, S&P Global.
Место работы
Офисы в Тбилиси, Санкт-Петербурге и Ростове-на-Дону, помощь с релокейтом
Как откликнуться? 🏃♂️
Если у тебя от 3+ лет опыта разработки, пиши @janemanolis
👉Подробнее в вакансии
Product Lab делится мини-курсом
по продакт-менеджменту бесплатно!
Мини-курс по собственной авторской методологии Product Focus поможет получить системные знания и навыки в продакт-менеджменте, а также понимание, что делать и в какой последовательности, чтобы успешно запустить и управлять продуктом.
🎤 Спикер курса — Андрей Бадин, CEO Product Lab, с опытом 20+ лет управления и запуска продуктов. Автор telegram-канала «Управляй иначе».
Что вас ждет в программе:
– мифы и проблемы продакт-менеджмента
– отличия проектного и продуктового управления
– методология Product Focus, которая помогает систематизировать знания и навыки
– этапы создания продукта и инструменты
– как не терять фокус с задач бизнеса
👉 Получить мини-курс
Реклама. ООО «Проектные сервисы». erid: 2VtzqxHBk3y
Как бизнесу выйти на новый уровень с помощью ИИ?
Приглашаем на конференцию Data Fusion 2024, которая пройдет в Москве 17-18 апреля.
На конференции вы сможете:
– Получить знания от экспертов в цифровой трансформации;
– Обсудить технологические тенденции, включая вопросы использования высоконагруженных платформ для обработки и хранения данных;
– Найти партнеров и расширить бизнес-контакты с профессионалами различных отраслей;
– Узнать о новейших разработках и технологиях в области ИИ, которые могут помочь вам в повышении эффективности вашего бизнеса или работы;
– Получить эксклюзивные знания по анализу данных для принятия обоснованных решений.
Не упустите шанс обогатить свой опыт и найти новые перспективы, регистрируйтесь на конференцию!
Хочешь перезагрузить карьеру в ИТ, но не знаешь, куда дальше развиваться?
На митапе «Управление в ИБ» расскажем, как и кому можно смело переходить в кибербез и почему это не страшно.
Поделимся, как быстро научиться разбираться в законодательстве ИБ, чем отличается специфика управления проектами и какие есть пути развития.
Когда: 22 апреля | 19:00
Где: Кибердом, Москва | онлайн
Кому будет интересно: менеджерам проектов
В программе 3 доклада и дискуссия, где развеем мифы о сложностях перехода в кибербез.
Необходимо зарегистрироваться.
Количество мест в офлайне ограничено❗️
Реклама АО «К2 Интеграция» ИНН 7701829110
Как пройти через массовое сокращение команды
Представьте – вы несколько лет строили замечательную команду, которая показывает отличные результаты. Однажды к вам приходит СЕО и говорит, что вам надо сократить 80% всех ее участников, причем на принятие и проведение решения выдается только один день.
В Reddit-треде куча советов про то, как менеджеру пройти через это. Вот некоторые из них:
👉Обновить собственное резюме, так как есть огромная вероятность, что на этом сокращения не остановятся. Особенно стоит подумать о том, остаетесь ди вы ценны, как менеджер, при значительно уменьшившемся размере команды.
👉Разобраться с зоной ответственности команды. Если ушла большая часть людей, их работу надо либо перестать делать, либо переложить на оставшихся. У менеджмента не должно быть ожиданий того, что оставшиеся 20% команды будут делать тот же объем работы.
👉Обязательно как можно раньше встретьтесь лично со всеми, кто остался в команде, обсудите происходящее и то, как поменяется их работа.
👉Изначально настройте себя на то, что сокращение – это не переговоры, а уже принятое бизнесовое решение. Лучший способ провести разговор с увольняемыми – придерживаться одного и того же сценария, оставаясь при этом человечным, и давая им возможность запроцессить информацию.
👉Постарайтесь сохранить личный контакт с увольняемыми. Вы можете помочь им с рекомендациями, отточкой навыков прохождения собеседования или написания резюме.
Определение ожиданий методом компаса или карты
Людям и командам разной зрелости нужен разный подход к определению ожиданий. Иногда полезно сравнивать их с определением направления движения с помощью компаса или с помощью карты.
🧭Компас – вы задаете только направление движения, но не даете никаких дополнительных ограничений, оставляя сотруднику максимум автономности для принятия собственных решений.
🗺️Карта – вы определяете не только направление, но и маршрут, причем в разной степени детализации. Можно задать только несколько ограничений, а можно описать весь маршрут с точностью до каждого поворота.
Может ли тимлид не быть программистом
Все похоливарили на прошлой неделе, давайте и мы не будем отрываться. На Хабре завирусилась статья, автор которой настаивает на том, что тимлиды, которые не пишут код, не обладают технической квалификацией и не могут справляться со своими задачами. Доводы такие:
👉Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
👉Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать.
👉Вы не можете оценить качество выполнения поставленной задачи, потому что вы не понимаете её суть.
👉Вы не можете оценить адекватность сроков выполнения задачи, так как не можете оценить её трудоёмкость.
👉Вы не можете выступать в роли арбитра в спорах между инженерами, так как не понимаете суть этих споров, и не обладаете авторитетом среди технарей.
👉Вы не можете обучать нанятых вами инженеров, так как вам нечем с ними поделиться.
👉Вы не можете выявлять технических лидеров в команде, чтобы делегировать им полномочия развития тех или иных направлений.
👉Вы не можете обеспечить "отказоустойчивость" вашей команды, так как не можете оценить реальный вклад в работу инженеров. Вы не понимаете, кого нужно удерживать, а с кем можно спокойно попрощаться. Вы не можете адекватно оценить риски ухода того или иного инженера. И, как следствие, вы не можете вовремя минимизировать эти риски.
На мой взгляд – полная ерунда. А вы что думаете?
Как быстрее выводить новые ИТ-продукты на рынок? Использовать облачные сервисы от VK Cloud!
VK Cloud — безопасная и технологичная платформа с широким набором облачных сервисов для разработки и работы с данными.
🔹 Все, что нужно для разработки: виртуальные машины, базы данных, GPU, Kubernetes, S3-хранилище, бэкапы, решения для машинного обучения и работы с Big Data.
🔹 Аудит, миграция, мониторинг и другие лучшие практики VK от команды опытных инженеров.
🔹 Комплексная защита веб-сервисов от атак и взломов.
Зарегистрируйтесь в VK Cloud и получите 3 000 ₽ для тестирования облачных сервисов в течение 60 дней!
Teamlead Crew стартует уже завтра
Если вы вдруг пропустили предыдущие анонсы – завтра стартует новый сезон онлайн конференции Podlodka Teamlead Crew, самого органичного способа быстро получить срез прикладного опыта по определенной теме, связанной с менеджментом команд. В этот раз вся конференция посвящена тому, как правильно внедрять, масштабировать и выкидывать на свалку истории процессные и инженерные метрики.
Так вот, абсолютно неожиданно для меня тема сезона про метрики взлетела, и мы идем на рекорд проданных билетов. И этот рекорд очень хочется побить, поэтому, если вы все еще сомневались, идти или нет, держите промокод для импульсивной покупки: tl_crew_12_9z2z7I
.
Чатик сезона уже стартовал, первые холивары зарождаются, так что готовьте свои кейсы, ставьте напоминания про утренние и вечерние сессии на каждый день и приходите к нам на конфу!
Microsoft и Amazon всё 😥
Если точнее, то облачные сервисы от Microsoft и Amazon закроют доступ для российских корпоративных клиентов до конца марта. А это Teams, SharePoint, Project, пакет Office 365 и многие другие популярные приложения.
Если вы в поиске замены для зарубежных программ, попробуйте сервис – Treerim.
Это продукт российского разработчика, который совмещает в себе функционал Jira, Confluence и Teams.
➤ В Treerim можно управлять проектами с канбан-досками, спринтами и всем, чем вы привыкли. Создавать базы знаний и формы, хранить данные о сотрудниках и автоматизировать любые процессы.
➤ Еще встроены видеочаты и аудиочаты. И, конечно, сервис для видеовстреч!
➤ А самое главное – ПО находится в России. Treerim можно развернуть на ваших мощностях без проблем с оплатами и блокировками. Также бесплатно и в короткие сроки специалисты Treerim помогут провести миграцию данных.
👉 Здесь можно записаться на демо и получить скидку 50% на годовую подписку.
Реклама. ООО "ОНЛИ". ИНН 7720823427, erid:2SDnjcg9ZNq
Привет, на связи Podlodka Teamlead Crew!
Пришли со свежими подробностями сезона.
Стартуем уже 1 апреля: научимся выбирать, внедрять, анализировать и масштабировать метрики.
Если вам кажется, что язык метрик сродни заклинаниям, которые знают лишь избранные, то вы попали по адресу. Мы пригласили крутых спикеров из известных компаний, которые обладают этим знанием и на метриках уже «собаку съели». Они научат правильно применять метрики, говорить с бизнесом и продактами на одном языке во благо разрабатываемому решению.
❓В каких сферах применимы метрики? Сергей Воробьёв объяснит как использовать популярные виды метрик и где брать для них данные.
❓Как принимать решения на основе метрик? Сергей Петрук из QIWI владеет этой магией: проведёт воркшоп по фреймворку принятия решений, разберёт реальные кейсы.
❓Как говорить с бизнесом на языке метрик? Серафима Чекулаева поделится священными тайнами продуктовых метрик и их потенциальной пользой.
Билеты уже на сайте, забирай свой!
https://podlodka.io/tlcrew
Осознанный подход к метрикам
Сегодня в 19 часов на канале Подлодки организуем доклад и Q&A секцию про то, какой вред плохо выбранные метрики могут нанести команде. Рассказывать про это будет Ярослав Астафьев, менеджер с очень большим опытом работы как в стартапах, так и в кровавом энтерпрайзе. В программе доклада обсуждение разных кейсов работы с метриками, рефлексия и выработка осознанного подхода к их применению.
Если что, то эту сессию проводим как разогрев перед полноценным сезоном Podlodka Teamlead Crew про метрики, который стартует на следующей неделе. Программа и спикеры уже на сайте, билеты распродаются как горячие пирожки, так что покупайте, пока не кончились (на самом деле это онлайн-конфа, поэтому билеты бесконечны!!111).
📆Дата: 26 марта, 19:00 по Москве
👉Ссылка на Youtube
Подробный гайд по поиску работы Engineering Manager'ом
Отличный документ, который покрывает все этапы поиска работы менеджером за пределами России. Я не буду его пересказывать, но дам небольшую выдержку интересных фактов:
👉Менеджеры, которые искали работу в 2023/2024 году, говорят про конверсию в примерно 1 оффер на 100 откликов. На скрине картинка от 2022 года.
👉Два списка компаний, которые платят много денег: раз и два.
👉Неплохой короткий шаблон для описания своих ачивок на каждом месте работы: {action verb} {deliverable/achievement} {impact (quantifiable if possible}} {tech used (if applicable)}
👉Автор пропагандирует немного спорный с моей точки зрения подход – вместо обычного резюме собирать сайт-визитку. Как по мне, пахнет какими-то 2010-ми.
👉Один из каналов поиска работы – вступить в несколько закрытых пулов клевых кандидатов, для доступа к которым рекрутеры платят деньги (раз, два, три, четыре).
👉Очевидное, но стоит повторить еще раз – если вы действительно хотите попасть в какую-то компанию, ищите внутреннего реферрала.
👉В терминах ROI полезнее всего вкладываться в подготовку к Behavioral Interview. Его результат чаще всего перевешивает технические секции. Вот тут есть разная инфа про подготовку.
Подкаст про то, как мы делаем Котлин
Я недавно сходил в гости в подкаст Кода Кода рассказать про то, чем занимаюсь на работе, и простыми словами объяснить, как и зачем создаются языки программирования. В частности, накидал историй про то, как специфика продукта влияет на процессы разработки:
👉Редкий релизный цикл, так как разработчики не скажут спасибо за обновления языка, прилетающие каждый день или неделю.
👉Практически невозможно собирать автономные команды, которые могут реализовывать значимые фичи от начала и до конца. Группировать команды приходится вокруг конкретных подсистем, и, как следствие, при планировании решать много задач по управлению зависимостями.
👉Очень сложно оценивать влияние изменений на пользовательские метрики. Во-первых, набор собираемых метрик очень ограничен. Во-вторых, никаких A/B тестов не покрутишь практически никогда. В-третьих, релизы состоят из большого количества изменений, отделить их влияние друг от друга не получается.
👉Большой упор на процессы обеспечения качества на всех этапах разработки. Из интересного – интенсивный догфудинг во внутренних проектах; большое количество quality gates, на которых изменения в компиляторе тестируются против пользовательских проектов; плотная работа с закрытой группой "early access champions", инженеров из бигтеха, которые накатывают пререлизные версии Котлина в своих продуктах и рассказывают про то, что сломалось; подробный RCA для любых регрессий, которые прошли через проверки качества.
В общем, если интересно – послушайте подкаст. А я когда-нибудь даже статью напишу про это.
И держите еще пару ссылок на выходные:
🔗Офигенный доклад про то, как монетизируются языки программирования
🔗Недавний подкаст со мной у "Мы обречены", но тут больше треп про жизнь