🟣Как помочь новичку быстрее адаптироваться в команде?
🔊 Обсудят 7 июня в 20:00 мск на онлайн-митапе с Андреем Волковым, тимлидом, который уже 18 лет в IT и ему есть чем поделиться.
В рамках встречи вы узнаете, как оценить состояние и уровень стресса нового сотрудника, используя шаблоны и чек-листы, как составить индивидуальный план онбординга и как выстраивать доверительные отношения с новым сотрудником.
Акцент будет сделан на инструментах и методиках, которые работают на практике и дают результат.
👉 Для участия зарегистрируйтесь: https://otus.pw/CZlc/
Нативная интеграция. Информация о продукте www.otus.ru
В рамках встречи вы узнаете, как оценить состояние и уровень стресса нового сотрудника, используя шаблоны и чек-листы, как составить индивидуальный план онбординга и как выстраивать доверительные отношения с новым сотрудником.
Акцент будет сделан на инструментах и методиках, которые работают на практике и дают результат.
Нативная интеграция. Информация о продукте www.otus.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
D&D как инструмент тимлида
Удаленка – круто, но она влияет на наше восприятие людей. Оно становится однобоким, мы не видим, как люди действуют в различных жизненных ситуациях, и гораздо хуже представляем себе их ограничения и возможности.
Виктор Корейша предлагает довольно необычный способ того, как посмотреть на свою команду в необычных срежессированных обстоятельствах – вовлечь их в разговорную ролевую игру. Идея, на самом деле, очень крутая:
🎲Позволяет быстро понять культуру общения и взаимодействия в команде.
🎲Помогает внедрять в команду новичков и давать им почувствовать чувство локтя.
🎲Можно увидеть скрытые конфликты между людьми, которые не видны в рабочей обстановке.
🎲Позволяет выделить неформальных лидеров.
В статье глубоко разбирается несколько примеров из практики Виктора, и объясняется, как самому провести такую игру в своей команде.
Удаленка – круто, но она влияет на наше восприятие людей. Оно становится однобоким, мы не видим, как люди действуют в различных жизненных ситуациях, и гораздо хуже представляем себе их ограничения и возможности.
Виктор Корейша предлагает довольно необычный способ того, как посмотреть на свою команду в необычных срежессированных обстоятельствах – вовлечь их в разговорную ролевую игру. Идея, на самом деле, очень крутая:
🎲Позволяет быстро понять культуру общения и взаимодействия в команде.
🎲Помогает внедрять в команду новичков и давать им почувствовать чувство локтя.
🎲Можно увидеть скрытые конфликты между людьми, которые не видны в рабочей обстановке.
🎲Позволяет выделить неформальных лидеров.
В статье глубоко разбирается несколько примеров из практики Виктора, и объясняется, как самому провести такую игру в своей команде.
Архитектурные принципы
Пару месяцев назад я выкладывал холиварную статью о том, что архитекторы не нужны. Но в любой системе, над которой работает больше одной команды, в конце концов появляется необходимость в согласованности решений по проектированию и выбору технологий. Один из вариантов ее решения – совместно выбрать набор декларативных архитектурных принципов.
Несколько примеров из статьи:
📝Use cloud services if being lock-in to a particular provider is acceptable.
📝Prefer standard data formats over third-party and custom formats.
Главное при составлении таких принципов – не делать их слишком общими, одновременно обо всем и ни о чем.
Пару месяцев назад я выкладывал холиварную статью о том, что архитекторы не нужны. Но в любой системе, над которой работает больше одной команды, в конце концов появляется необходимость в согласованности решений по проектированию и выбору технологий. Один из вариантов ее решения – совместно выбрать набор декларативных архитектурных принципов.
Несколько примеров из статьи:
📝Use cloud services if being lock-in to a particular provider is acceptable.
📝Prefer standard data formats over third-party and custom formats.
Главное при составлении таких принципов – не делать их слишком общими, одновременно обо всем и ни о чем.
workingsoftware.dev
Architecture Principles: An approach to effective decision making in software architecture
Are you a software architect and often find it difficult to make architecture decisions in your team? This article shows you how to use architecture principles to make effective decisions in your team.
Любой код когда-нибудь станет техдолгом
Держите статью-напоминание о том, что даже если вы пишете идеальный код на самом современном стеке, спустя несколько лет он устареет только из-за постоянного цикла смены технологий.
👴🏻Flash, Silverlight и Java апплеты умерли, как и код, написанный для них.
👴🏻Большая часть Objective-C кода с появлением и развитием Swift стала легаси.
👴🏻Стандарт OpenTelemetry сделал написанные ранее инхаусные библиотеки для трассировки неактуальными.
Все со временем превращается в технический долг. Об этом важно помнить, чтобы не ударяться в чрезмерную оптимизацию существующих проектов.
Держите статью-напоминание о том, что даже если вы пишете идеальный код на самом современном стеке, спустя несколько лет он устареет только из-за постоянного цикла смены технологий.
👴🏻Flash, Silverlight и Java апплеты умерли, как и код, написанный для них.
👴🏻Большая часть Objective-C кода с появлением и развитием Swift стала легаси.
👴🏻Стандарт OpenTelemetry сделал написанные ранее инхаусные библиотеки для трассировки неактуальными.
Все со временем превращается в технический долг. Об этом важно помнить, чтобы не ударяться в чрезмерную оптимизацию существующих проектов.
Хабр
Итоги двадцати лет работы — технический долг и неподдерживаемый код
Технический долг — один из самых популярных сегодня терминов. Люди говорят: «Мы быстро развиваем свой MVP, минимизируя технический долг!» Они говорят о техническом долге, чтобы звучать круто или...
Российский скрам
Отличный блогпост активного участника нашего чата про его опыт с управленческими методологиями: самозародившийся скрам на стройке коровника на Камчатке, управленческий консалтинг в девяностые, появление менеджмента проектов и первое столкновение со скрамом.
Кроме рефлексии про полученный опыт, автор выделяет четыре особенности скрама, которые мешают ему прижиться в России в своей оригинальной форме:
1️⃣Отсутствие роли руководителя
2️⃣Слишком сильная ритуальность
3️⃣Неопределенность роли скрам-мастера
4️⃣Скрам – слишком потогонная система
Отличный блогпост активного участника нашего чата про его опыт с управленческими методологиями: самозародившийся скрам на стройке коровника на Камчатке, управленческий консалтинг в девяностые, появление менеджмента проектов и первое столкновение со скрамом.
Кроме рефлексии про полученный опыт, автор выделяет четыре особенности скрама, которые мешают ему прижиться в России в своей оригинальной форме:
1️⃣Отсутствие роли руководителя
2️⃣Слишком сильная ритуальность
3️⃣Неопределенность роли скрам-мастера
4️⃣Скрам – слишком потогонная система
Telegraph
Скрам глазами постороннего
Я работаю в сфере, скажем так, HR (подробнее здесь, и ниже в тексте) и к разработке имею весьма опосредованное отношение. Тем не менее, у меня есть определённый опыт взаимодействия со скрамом, как управленческой методикой, и связанные с этим впечатления.…
Отличный пример лендинга для найма от Авито
Сразу предупреждаю – это не реклама, постить лендинг меня не просили, и тут он исключительно потому, что очень сильно мне понравился!
Вообще, нанимательные лендинги – классный инструмент, чтобы рассказать кандидату про вакансию, выделив самые важные идеи и предоставив все необходимые доказательства. И все это – без полотна безликого текста и с нормальными визуальными акцентами.
Так вот, Авито сделали шаг вперед. Вместо рассказа о вакансиях, стеке технологий или крутости команды в вакууме, они объединили в е это в крутой нарратив, рассказав, какие этапы проходит объявление при публикации, и какую роль в этом играет каждая команда. Сразу становится понятнее, зачем нужна огромная платформенная команда, с какими задачами предстоит столкнуться в работе над модерацией или опытом продавцов, и зачем используются конкретные технологии.
Ну и все это – понятным языком, с ярким визуалом и небольшими интерактивными вставками. Посмотрите, вдохновитесь, и соберите похожий сайт про вашу команду!
Сразу предупреждаю – это не реклама, постить лендинг меня не просили, и тут он исключительно потому, что очень сильно мне понравился!
Вообще, нанимательные лендинги – классный инструмент, чтобы рассказать кандидату про вакансию, выделив самые важные идеи и предоставив все необходимые доказательства. И все это – без полотна безликого текста и с нормальными визуальными акцентами.
Так вот, Авито сделали шаг вперед. Вместо рассказа о вакансиях, стеке технологий или крутости команды в вакууме, они объединили в е это в крутой нарратив, рассказав, какие этапы проходит объявление при публикации, и какую роль в этом играет каждая команда. Сразу становится понятнее, зачем нужна огромная платформенная команда, с какими задачами предстоит столкнуться в работе над модерацией или опытом продавцов, и зачем используются конкретные технологии.
Ну и все это – понятным языком, с ярким визуалом и небольшими интерактивными вставками. Посмотрите, вдохновитесь, и соберите похожий сайт про вашу команду!
Итак, ты стал(а) тимлидом. Что было дальше?
14 июня в 19:00 ребята из СберМаркета приглашают всех тимлидов и тех, кто хочет ими стать, на митап в Москве. Расскажут про тимлидские боли и поделятся историями о развитии карьеры.
Что будет на митапе?
📝 «Как тимлиду стать Engineering manager’ом» от Сергея Яныкина, engineering manager в CберМаркете.
📝 «Деление клеток, или Как плавно делить команду и не убить её при этом» от Алексея Партилова, тимлида в СберМаркете.
📝 Public talk «Как сделать твою команду эффективной» c Engineering manager’ами СберМаркета и ведущими подкаста «Для tech и этих».
Регистрация по ссылке, количество мест в офлайне ограничено.
14 июня в 19:00 ребята из СберМаркета приглашают всех тимлидов и тех, кто хочет ими стать, на митап в Москве. Расскажут про тимлидские боли и поделятся историями о развитии карьеры.
Что будет на митапе?
📝 «Как тимлиду стать Engineering manager’ом» от Сергея Яныкина, engineering manager в CберМаркете.
📝 «Деление клеток, или Как плавно делить команду и не убить её при этом» от Алексея Партилова, тимлида в СберМаркете.
📝 Public talk «Как сделать твою команду эффективной» c Engineering manager’ами СберМаркета и ведущими подкаста «Для tech и этих».
Регистрация по ссылке, количество мест в офлайне ограничено.
Эволюция управления процессом разработки во Фланте
Флант – компания, которая продает клиентам услуги продуктовой разработки и обслуживания инфраструктуры. На Хабре они поделились историей развития своей системы управления бэклогом, оценки и распределения задач между инженерами. Отличный пример эволюции, продиктованной возникающими проблемами, вместо слепых попыток внедрить очередную модную методологию.
Вот основные идеи, к которым пришла команда:
👉WIP-лимиты и вытягивающая модель, благодаря которым у инженеров не появляется демотивирующей стены нерешенных задач.
👉Регулярный груминг заблокированных задач, благодаря чему они не теряются.
👉Использование «слота WIP», равного двум часам работы опытного инженера, как универсальной единицы приносимой ценности.
Флант – компания, которая продает клиентам услуги продуктовой разработки и обслуживания инфраструктуры. На Хабре они поделились историей развития своей системы управления бэклогом, оценки и распределения задач между инженерами. Отличный пример эволюции, продиктованной возникающими проблемами, вместо слепых попыток внедрить очередную модную методологию.
Вот основные идеи, к которым пришла команда:
👉WIP-лимиты и вытягивающая модель, благодаря которым у инженеров не появляется демотивирующей стены нерешенных задач.
👉Регулярный груминг заблокированных задач, благодаря чему они не теряются.
👉Использование «слота WIP», равного двум часам работы опытного инженера, как универсальной единицы приносимой ценности.
Интервью по System Design — это обязательный этап собеседований в большие технологические компании уровня FAANG, по результатам которого принимается финальное решение о найме.
Но на русском языке почти нет материалов для комплексной подготовки!
Поэтому Валерий Бабушкин, Vice President, Data Science в Blockchainꓸcom, и Евгений Нижибицкий, Lead Machine Learning Engineer в AliExpress, создали свой авторский курс, где вы научитесь выстраивать сложные и масштабируемые архитектуры программных систем.
За 4 недели вы научитесь:
- собирать требования и оценивать нагрузку
- применять высокоуровневые схемы и модульный дизайн
- масштабировать и повышать отзывчивость систем
- создавать подсистемы для хранения данных, поиска и аналитики
На курсе System Design вы получите готовый план идеального ответа на собеседовании, а также знания о системах, которые помогут выделиться среди других кандидатов.
Записывайтесь на курс по ссылке до 19 июня! Ждём вас!
Но на русском языке почти нет материалов для комплексной подготовки!
Поэтому Валерий Бабушкин, Vice President, Data Science в Blockchainꓸcom, и Евгений Нижибицкий, Lead Machine Learning Engineer в AliExpress, создали свой авторский курс, где вы научитесь выстраивать сложные и масштабируемые архитектуры программных систем.
За 4 недели вы научитесь:
- собирать требования и оценивать нагрузку
- применять высокоуровневые схемы и модульный дизайн
- масштабировать и повышать отзывчивость систем
- создавать подсистемы для хранения данных, поиска и аналитики
На курсе System Design вы получите готовый план идеального ответа на собеседовании, а также знания о системах, которые помогут выделиться среди других кандидатов.
Записывайтесь на курс по ссылке до 19 июня! Ждём вас!
Техника обучения Фейнмана
Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:
1️⃣Запишите все, что вы знаете о теме, как будто вы объясняете ее кому-то.
2️⃣Отметьте все пробелы в рассуждениях, и вернитесь к изучению темы, пока не закроете их.
3️⃣Переписывайте свое объяснение, заменяя сложные идеи более простыми, пока оно не станет очевидным.
А вообще, если вы не читали «Вы, конечно, шутите, мистер Фейнман», закрывайте Телегу, покупайте книгу, и, я гарантирую, это будет лучшее вложение вашего времени.
Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:
1️⃣Запишите все, что вы знаете о теме, как будто вы объясняете ее кому-то.
2️⃣Отметьте все пробелы в рассуждениях, и вернитесь к изучению темы, пока не закроете их.
3️⃣Переписывайте свое объяснение, заменяя сложные идеи более простыми, пока оно не станет очевидным.
А вообще, если вы не читали «Вы, конечно, шутите, мистер Фейнман», закрывайте Телегу, покупайте книгу, и, я гарантирую, это будет лучшее вложение вашего времени.
Вебинар про карьерный рост продактов
Если есть профессия с еще более беспорядочным набором ожиданий и отличием роли от компании к компании, чем тимлид, так это продакт. Где-то от тебя требуется быть мини-СЕО (материальная компенсация при этом забывает про «СЕО», но не забывает про «мини»). Где-то – ты слепо перемалываешь поставленные кем-то задачи в разработческий бэклог. А где-то – исследуешь, как принести ценность пользователям и бизнесу. Короче, разные ожидания, разные навыки, и совсем разные карьерные пути.
Если вы хотите разобраться в том, как выглядит карьерный путь продакт-менеджера, получить рекомендации для себя, или идеи для развития продактов в вашей команде, приходите на вебинар от Edutoria.
Мне нравится, что все спикеры – СРО, а, значит, успели и за свою карьеру повидать всякое, и других продактов вырастить:
— Сергей Ершов, CPO СберОбразования.
— Максим Гришак, CPO Домклик от Сбера, лидер направления небанковских сервисов в недвижимости.
— Женя Агеев, CPO в стриме «Государственные услуги» в ВТБ
— Игорь Мелех, Head of Рroduct в Ozon, Автор телеграм-канала «MVP из палок».
📆Дата: 13 июня, 19:00
👉Регистрация
Если есть профессия с еще более беспорядочным набором ожиданий и отличием роли от компании к компании, чем тимлид, так это продакт. Где-то от тебя требуется быть мини-СЕО (материальная компенсация при этом забывает про «СЕО», но не забывает про «мини»). Где-то – ты слепо перемалываешь поставленные кем-то задачи в разработческий бэклог. А где-то – исследуешь, как принести ценность пользователям и бизнесу. Короче, разные ожидания, разные навыки, и совсем разные карьерные пути.
Если вы хотите разобраться в том, как выглядит карьерный путь продакт-менеджера, получить рекомендации для себя, или идеи для развития продактов в вашей команде, приходите на вебинар от Edutoria.
Мне нравится, что все спикеры – СРО, а, значит, успели и за свою карьеру повидать всякое, и других продактов вырастить:
— Сергей Ершов, CPO СберОбразования.
— Максим Гришак, CPO Домклик от Сбера, лидер направления небанковских сервисов в недвижимости.
— Женя Агеев, CPO в стриме «Государственные услуги» в ВТБ
— Игорь Мелех, Head of Рroduct в Ozon, Автор телеграм-канала «MVP из палок».
📆Дата: 13 июня, 19:00
👉Регистрация
Как использовать Definition of Ready
Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.
Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.
Такие правила могут быть полезными. Благодаря им можно на раннем этапе отловить задачу, которая зависит от других команд, и может заблокировать вам работу, или поймать другие похожие случаи.
Но проблем от использования DoR в таком формате больше, чем пользы. Вместо итеративной разработки фичи с быстрым фидбэком DoR провоцируют появление этапов работы. Условно говоря, вместо совместной работы разработчика и дизайнера над фичой, у нас появляется два этапа – дизайн и имплементация, между которыми появляется дополнительный гейт в виде ревью макетов. Если макеты не соответствуют DoR, работа над фичей не начинается, пока дизайнер не внесет все правки. А это, конечно, сильно увеличивает среднее время разработки.
Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:
- Не включайте в список критериев требования по 100% готовности чего-то до старта работы.
- Трактуйте DoR как набор рекомендаций, а не обязательных правил.
Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.
Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.
Такие правила могут быть полезными. Благодаря им можно на раннем этапе отловить задачу, которая зависит от других команд, и может заблокировать вам работу, или поймать другие похожие случаи.
Но проблем от использования DoR в таком формате больше, чем пользы. Вместо итеративной разработки фичи с быстрым фидбэком DoR провоцируют появление этапов работы. Условно говоря, вместо совместной работы разработчика и дизайнера над фичой, у нас появляется два этапа – дизайн и имплементация, между которыми появляется дополнительный гейт в виде ревью макетов. Если макеты не соответствуют DoR, работа над фичей не начинается, пока дизайнер не внесет все правки. А это, конечно, сильно увеличивает среднее время разработки.
Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:
- Не включайте в список критериев требования по 100% готовности чего-то до старта работы.
- Трактуйте DoR как набор рекомендаций, а не обязательных правил.
Mountain Goat Software
The Definition of Ready and Its Dangers
Although not as popular as a Definition of Done, some Scrum teams use a Definition of Ready to control what product backlog items can enter an iteration.
Лайв-разбор инцидентов
Инцидент-менеджмент, написание постмортемов и устранение корневых проблем – отличный способ для команды учиться на своих ошибках и постоянно улучшать код, инфраструктуру и процессы.
Ребята из Otus проводят встречу с анализом реальных кейсов, на которой будет разбираться, как не превратить разбор инцидентов в сессию взаимных упреков, вести полезные постмортемы, и подходить к выявлению руткозов. А всем, кто зарегистрируется, бонусом отправят бесплатную подборку эфиров по управлению командой и решению кризисных ситуаций.
📆Дата: 15 июня, 19:00
👉Регистрация
Инцидент-менеджмент, написание постмортемов и устранение корневых проблем – отличный способ для команды учиться на своих ошибках и постоянно улучшать код, инфраструктуру и процессы.
Ребята из Otus проводят встречу с анализом реальных кейсов, на которой будет разбираться, как не превратить разбор инцидентов в сессию взаимных упреков, вести полезные постмортемы, и подходить к выявлению руткозов. А всем, кто зарегистрируется, бонусом отправят бесплатную подборку эфиров по управлению командой и решению кризисных ситуаций.
📆Дата: 15 июня, 19:00
👉Регистрация
Причины плохого перфоманса
1️⃣Сотрудник плохо перформит, потому что вы поставили его на неподходящую ему роль.
2️⃣Сотрудник только вышел на новую роль, на него свалилось много всего неизвестного, и он не справляется из-за переизбытка информации.
3️⃣Причины кроются где-то в личных или семейных событиях.
4️⃣У вас есть неявные ожидания от роли сотрудника, а он привык работать по-другому.
5️⃣Люди меняются, и роли, которые им подходили раньше, могут переставать подходить со временем.
1️⃣Сотрудник плохо перформит, потому что вы поставили его на неподходящую ему роль.
2️⃣Сотрудник только вышел на новую роль, на него свалилось много всего неизвестного, и он не справляется из-за переизбытка информации.
3️⃣Причины кроются где-то в личных или семейных событиях.
4️⃣У вас есть неявные ожидания от роли сотрудника, а он привык работать по-другому.
5️⃣Люди меняются, и роли, которые им подходили раньше, могут переставать подходить со временем.
Radical Candor
5 Reasons Your Top Employees Are Underperforming | Radical Candor
One management dilemma is when a high-performance person who ought to be getting better every day is underperforming. Underperforming employees happen for 5 reasons.
“Анти-требования” для модели данных
Самый очевидный способ подойти к проработке модели данных – смотреть на ее сущности как на объекты реального мира, добавляя им атрибуты, которые имеют очевидный смысл. Например, “товар” в корзине интернет-магазина, состоит из названия, его описания, цены, количества приобретенных единиц и других похожих свойств. Недостаток такого подхода в том, что модели такого рода могут очень сильно разрастаться, их состояние зависит от кучи различных условий, и для корректного их обновления придется писать сложную логику.
Распилить модель правильным образом могут помочь “анти-требования”. Идея такая – вы формулируете фейковое бизнес-требование, влияюбщее на отношения атрибутов, и оцениваете его адекватность. Например, “Когда описание товара длиннее 5000 символов, его цена должна измениться на 20%”. Если требование звучит неадекватно – нет никакой необходимости держать эти атрибуты в рамках одной сущности. Если звучит адекватно – связь есть, нужно выделять в отдельную сущность.
Самый очевидный способ подойти к проработке модели данных – смотреть на ее сущности как на объекты реального мира, добавляя им атрибуты, которые имеют очевидный смысл. Например, “товар” в корзине интернет-магазина, состоит из названия, его описания, цены, количества приобретенных единиц и других похожих свойств. Недостаток такого подхода в том, что модели такого рода могут очень сильно разрастаться, их состояние зависит от кучи различных условий, и для корректного их обновления придется писать сложную логику.
Распилить модель правильным образом могут помочь “анти-требования”. Идея такая – вы формулируете фейковое бизнес-требование, влияюбщее на отношения атрибутов, и оцениваете его адекватность. Например, “Когда описание товара длиннее 5000 символов, его цена должна измениться на 20%”. Если требование звучит неадекватно – нет никакой необходимости держать эти атрибуты в рамках одной сущности. Если звучит адекватно – связь есть, нужно выделять в отдельную сущность.
Как убеждать людей, когда у вас нет административных рычагов
👉Повышайте уровень своей репутации в компании. На него влияют две вещи: насколько хорошие решения вы принимаете, и насколько вы проявляете здравый смысл.
👉До того, как предлагать изменения, разберитесь, почему вещи работают именно так, как работают сейчас. А еще, поработайте с ними самостоятельно, чтобы не опираться только на чужие суждения.
👉Когда вы только начинаете изменения, беритесь за самые низковисящие фрукты. Быстрые победы помогут заслужить доверия для более серьезных изменений.
👉Продавайте любое изменение, как эксперимент: заранее определите критерии успешности и ограничьте время его проведения.
👉Перед тем, как презентовать идею группе людей, продайте ее каждому из группы лично, и отработайте все возможные возражения.
👉Повышайте уровень своей репутации в компании. На него влияют две вещи: насколько хорошие решения вы принимаете, и насколько вы проявляете здравый смысл.
👉До того, как предлагать изменения, разберитесь, почему вещи работают именно так, как работают сейчас. А еще, поработайте с ними самостоятельно, чтобы не опираться только на чужие суждения.
👉Когда вы только начинаете изменения, беритесь за самые низковисящие фрукты. Быстрые победы помогут заслужить доверия для более серьезных изменений.
👉Продавайте любое изменение, как эксперимент: заранее определите критерии успешности и ограничьте время его проведения.
👉Перед тем, как презентовать идею группе людей, продайте ее каждому из группы лично, и отработайте все возможные возражения.
Challenges -> Concerns -> Problems -> Barriers
Интересная модель того, как риски со временем превращаются в барьеры, которые мешают вашей команде двигаться дальше. Основная мысль – нельзя фокусироваться только на тушении пожаров и устранении барьеров, которые мешают вот прямо сейчас. Если хотите долгосрочного успеха – постоянно трекайте потенциальные риски на периферии, и занимайтесь ими, пока их важность не выросла.
Интересная модель того, как риски со временем превращаются в барьеры, которые мешают вашей команде двигаться дальше. Основная мысль – нельзя фокусироваться только на тушении пожаров и устранении барьеров, которые мешают вот прямо сейчас. Если хотите долгосрочного успеха – постоянно трекайте потенциальные риски на периферии, и занимайтесь ими, пока их важность не выросла.
Ищут Тимлида в Облако Selectel.
Тимлид в Selectel это
▪️Про техническое лидерство, архитектуру и готовность залезть в код
▪️Про мотивацию и развитие своей команды
▪️Про общение и кооперацию со смежными командами и создание ценности для клиента общими силами
Откликнуться можно тут
По вопросам можно писать сюда
Тимлид в Selectel это
▪️Про техническое лидерство, архитектуру и готовность залезть в код
▪️Про мотивацию и развитие своей команды
▪️Про общение и кооперацию со смежными командами и создание ценности для клиента общими силами
Откликнуться можно тут
По вопросам можно писать сюда
Подробный обзор системы грейдов в Shopify
Shopify зарефакторили свою систему грейдов. Основные идеи следующие:
- Всего у инженеров восемь грейдов, от стажера до fellow.
- Каждый грейд разделен на пять сегментов по “mastery”. Mastery – это технические навыки и доменные знания, получаемые сотрудником по мере приобретения опыта.
- Mastery отдельно оценивается по пяти характеристикам: технические знания, решение задач, принятие решений, лидерство.
- Переход между уровнями не завязан на mastery. Это просто еще одна проекция, в рамках которой можно расти в зарплате, не беря на себя новую ответственность.
Shopify зарефакторили свою систему грейдов. Основные идеи следующие:
- Всего у инженеров восемь грейдов, от стажера до fellow.
- Каждый грейд разделен на пять сегментов по “mastery”. Mastery – это технические навыки и доменные знания, получаемые сотрудником по мере приобретения опыта.
- Mastery отдельно оценивается по пяти характеристикам: технические знания, решение задач, принятие решений, лидерство.
- Переход между уровнями не завязан на mastery. Это просто еще одна проекция, в рамках которой можно расти в зарплате, не беря на себя новую ответственность.
Вебинар от Otus про использование метрик для управления командой
Ребята из Otus проводят вебинар про то, как выстроить систему метрик для оценки эффективности работы разного типа команд. Обещают разобрать следующие темы:
- Почему в управлении командой важны цифры
- Какие метрики применимы в тех или иных ситуациях
- Кейсы из реальной практики работы поддержки, продуктовых команд
- Рекомендации по внедрению метрик
Гусары и гусарыни, придержите ваши кнопки дизлайков! Мы эту тему много раз обсуждали в канале и в чате, и мнение большинства склоняется к тому, что любое управление по метрикам чаще приносит вред, чем пользу. Но даже если вы, как и я, сильно держитесь за эту позицию – послушать аргументы другой стороны и подискутировать про них всегда полезно. Поэтому подключайтесь на стрим и готовьте ваши вопросы!
📆Дата: 28 июня в 19:00 по Москве
👉Регистрация
Нативная интеграция информация о продукте www.otus.ru
Ребята из Otus проводят вебинар про то, как выстроить систему метрик для оценки эффективности работы разного типа команд. Обещают разобрать следующие темы:
- Почему в управлении командой важны цифры
- Какие метрики применимы в тех или иных ситуациях
- Кейсы из реальной практики работы поддержки, продуктовых команд
- Рекомендации по внедрению метрик
Гусары и гусарыни, придержите ваши кнопки дизлайков! Мы эту тему много раз обсуждали в канале и в чате, и мнение большинства склоняется к тому, что любое управление по метрикам чаще приносит вред, чем пользу. Но даже если вы, как и я, сильно держитесь за эту позицию – послушать аргументы другой стороны и подискутировать про них всегда полезно. Поэтому подключайтесь на стрим и готовьте ваши вопросы!
📆Дата: 28 июня в 19:00 по Москве
👉Регистрация
Нативная интеграция информация о продукте www.otus.ru