Процесс найма — несправедливый, как ни старайся
Читаю «Work Rules!» от бывшего главы HR Google.
Корпорация добра проводит A/B тесты во внутренних процессах, в том числе в найме. Вот как разные методы отбора кандидатов влияют на будущую успешность сотрудника:
• Отсев по количеству лет опыта — 3%
• Сбор фидбеков с прошлых мест — 7%
• Неструктурированные интервью — 14%
• Структурированные интервью — 26%
• Тест на общие когнитивные способности (внезапно) — 26%
• Практическое задание — 29%
Разные компании комбинируют эти методы, но ни один из них по отдельности не гарантирует более 30% успеха!
———
Когда после 5 лет работы в QIWI решил «пособеситься ради интереса», оказалось что это целый новый мир, не похожий на то, что я делал в каждодневной работе.
У людей, кто работает на одном месте несколько лет и не смотрит на рынок, могут возникнуть трудности:
— Как оценить свой опыт,
— Как проходить собеседования,
— Какая зарплата считается рыночной.
Было бы здорово мне тогда сходить на консультацию к кому-то, кто в этой теме работает постоянно. Это помогло бы сэкономить время и силы, и меньше стрессовать.
Этот пост — реклама Карьерного Цеха. Ребята предлагают бесплатную консультацию для тех, кто подумывает искать работу.
На консультации помогут сориентироваться в рынке, составить резюме, оценить навыки. Расскажут, как правильно готовиться и проходить собеседования. А еще ребята организуют тусовку, где можно найти нетворк для поиска работы.
Записывайтесь на бесплатную консультацию и получите индивидуальный план поиска работы, который приведет вас к офферу.
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Читаю «Work Rules!» от бывшего главы HR Google.
Корпорация добра проводит A/B тесты во внутренних процессах, в том числе в найме. Вот как разные методы отбора кандидатов влияют на будущую успешность сотрудника:
• Отсев по количеству лет опыта — 3%
• Сбор фидбеков с прошлых мест — 7%
• Неструктурированные интервью — 14%
• Структурированные интервью — 26%
• Тест на общие когнитивные способности (внезапно) — 26%
• Практическое задание — 29%
Разные компании комбинируют эти методы, но ни один из них по отдельности не гарантирует более 30% успеха!
———
Когда после 5 лет работы в QIWI решил «пособеситься ради интереса», оказалось что это целый новый мир, не похожий на то, что я делал в каждодневной работе.
У людей, кто работает на одном месте несколько лет и не смотрит на рынок, могут возникнуть трудности:
— Как оценить свой опыт,
— Как проходить собеседования,
— Какая зарплата считается рыночной.
Было бы здорово мне тогда сходить на консультацию к кому-то, кто в этой теме работает постоянно. Это помогло бы сэкономить время и силы, и меньше стрессовать.
Этот пост — реклама Карьерного Цеха. Ребята предлагают бесплатную консультацию для тех, кто подумывает искать работу.
На консультации помогут сориентироваться в рынке, составить резюме, оценить навыки. Расскажут, как правильно готовиться и проходить собеседования. А еще ребята организуют тусовку, где можно найти нетворк для поиска работы.
Записывайтесь на бесплатную консультацию и получите индивидуальный план поиска работы, который приведет вас к офферу.
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Low-context vs High-context коммуникация
Читаю The Culture Map — книгу про культурные различия. Заходит настолько, что буду приносить сюда кое-какие концепты.
Страны с богатой историей и традициями выражают больше смыслов меньшим количеством слов, что экономит время и помогает сохранить отношения. Это называется high-context коммуникацией.
У нас принято «читать между строк». Аналогично в Испании, Турции и многих других странах.
В Японии и Китае это же называется «слушать воздух».
High-context пример: На дейли тимлид говорит «надо подумать, как оптимизировать запрос». В нашей культуре это может означать просьбу к конкретному разработчику заняться оптимизацией, но напрямую это не озвучено.
Могут возникнуть недопонимания:
🤏 конкретный разработчик может не понять, что эта просьба — к нему, и продолжить работать по своей задаче. А когда неоптимальный запрос станет проблемой — это будет его проблема, потому что у тимлида были ожидания.
🤏 сразу несколько ребят бросят свои задачи и, не синхронизируясь, займутся оптимизацией. Другая работа не будет сделана, а потом еще и спорить будут, чья оптимизация круче 🙂
==========
Напротив, молодые «экспатские» страны, вроде Австралии, не имели возможности развить high-context культуру. Чтобы выходцы из разных стран могли сосуществовать, они стараются не закладывать доп смыслов в свои сообщения и выражаются прямо и детализированно.
В следующем посте расскажу про Low-context коммуникацию, почему она лучше подходит для рабочих отношений.
Как вы думаете, где больше пространства для недопониманий?
1️⃣ — Между двумя представителями разных Low-context стран, например Австралия и Канада
2️⃣ — Между Low-context из США и High-context из Китая
3️⃣ — Между High-context из России и High-context из Индии
Буду рад обсудить в комментах 🙂
Читаю The Culture Map — книгу про культурные различия. Заходит настолько, что буду приносить сюда кое-какие концепты.
Страны с богатой историей и традициями выражают больше смыслов меньшим количеством слов, что экономит время и помогает сохранить отношения. Это называется high-context коммуникацией.
У нас принято «читать между строк». Аналогично в Испании, Турции и многих других странах.
В Японии и Китае это же называется «слушать воздух».
High-context пример: На дейли тимлид говорит «надо подумать, как оптимизировать запрос». В нашей культуре это может означать просьбу к конкретному разработчику заняться оптимизацией, но напрямую это не озвучено.
Могут возникнуть недопонимания:
🤏 конкретный разработчик может не понять, что эта просьба — к нему, и продолжить работать по своей задаче. А когда неоптимальный запрос станет проблемой — это будет его проблема, потому что у тимлида были ожидания.
🤏 сразу несколько ребят бросят свои задачи и, не синхронизируясь, займутся оптимизацией. Другая работа не будет сделана, а потом еще и спорить будут, чья оптимизация круче 🙂
==========
Напротив, молодые «экспатские» страны, вроде Австралии, не имели возможности развить high-context культуру. Чтобы выходцы из разных стран могли сосуществовать, они стараются не закладывать доп смыслов в свои сообщения и выражаются прямо и детализированно.
В следующем посте расскажу про Low-context коммуникацию, почему она лучше подходит для рабочих отношений.
Как вы думаете, где больше пространства для недопониманий?
1️⃣ — Между двумя представителями разных Low-context стран, например Австралия и Канада
2️⃣ — Между Low-context из США и High-context из Китая
3️⃣ — Между High-context из России и High-context из Индии
Буду рад обсудить в комментах 🙂
Yet Another Level: TeamLead — Митап для тимлидов от Яндекса.
25 июля. Бесплатно.
Митап из серии мероприятий про жизнь в IT-индустрии. В этот раз о тимлидах, их софт скилах и карьерных треках.
Будут выступать уважаемые господа:
📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure.
«Играющий тренер: выиграет или проиграет?» — Поговорим о том, как начинающие тимлиды 80% пишут код и 80% занимаются менеджментом.
📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке.
«Жока и Бока: две очень разные судьбы тимлидов». Ожидаю классный сторителлинг, где каждый сможет узнать себя.
📌 Руслан Остропольский, CPO в Test IT.
«Как завоевать доверие тимлиду» Разберёмся, что такое доверие, как оно формируется и как его не потерять. А ещё обсудим, есть ли разница между доверием и авторитетом.
Митап пройдёт 25 июля онлайн и офлайн в Москве — участие бесплатное, но нужно зарегистрироваться
Присоединяйтесь к чату сообщества в tg https://www.tg-me.com/Yet_Another_Level
25 июля. Бесплатно.
Митап из серии мероприятий про жизнь в IT-индустрии. В этот раз о тимлидах, их софт скилах и карьерных треках.
Будут выступать уважаемые господа:
📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure.
«Играющий тренер: выиграет или проиграет?» — Поговорим о том, как начинающие тимлиды 80% пишут код и 80% занимаются менеджментом.
📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке.
«Жока и Бока: две очень разные судьбы тимлидов». Ожидаю классный сторителлинг, где каждый сможет узнать себя.
📌 Руслан Остропольский, CPO в Test IT.
«Как завоевать доверие тимлиду» Разберёмся, что такое доверие, как оно формируется и как его не потерять. А ещё обсудим, есть ли разница между доверием и авторитетом.
Митап пройдёт 25 июля онлайн и офлайн в Москве — участие бесплатное, но нужно зарегистрироваться
Присоединяйтесь к чату сообщества в tg https://www.tg-me.com/Yet_Another_Level
Low-context коммуникация и обратная связь
Правильный ответ на вопрос из прошлого поста — 3️⃣
C большей вероятностью представители двух разных High-context культур могут неправильно считывать «между строк» сообщения друг друга. Потому что их культура формировалась независимо в разном историческом контексте. Даже внутри одной страны есть риск неправильного считывания «между строк». Сейчас в распределенных командах работают ребята из разных регионов, и у каждого свой high-context.
Поэтому простое правило — в рабочей коммуникации использовать Low-context.
Самому выражаться максимально четко и детализированно и переспрашивать у собеседника, если начинаешь додумывать.
Давать максимум контекста: над чем работаешь и детали для правильного понимания ситуации. Объяснять, почему задаешь тот или иной вопрос. Да, иногда придется повторяться. Но лучше повторить, чем быть неправильно понятым.
А еще — не закладывать намёков и смыслов «между строк» в своей коммуникации и не пытаться найти их в словах собеседника.
Но из любого правила есть исключения.
Самое важное исключение — обратная связь.
Удивительно, но многие Low-context страны имеют культуру смягчения корректирующей обратной связи. Например, в Америке, UK и Канаде принято давать фидбек в формате «сендвича»: «несколько положительных аспектов, затем мягко упомянуть о том, что можно улучшить, и снова похвалить».
Раньше я давал фидбек именно так, считая это правильным. Но один разработчик назвал это «буллшит-бургером», и я понял, что такой подход может восприниматься как неискренний: положительная часть обесценивается, а корректирующая не воспринимается должным образом.
Теперь я стараюсь использовать Low-context коммуникацию, сохраняя при этом прямой стиль обратной связи.
На картинке — позиционирование стран в координатах «Коммуникация / Обратная связь».
Мы с вами находимся в квадранте «High-context / Direct negative feedback». Из этого делаем вывод, что в общем случае мы можем общаться намёками и рассчитывать, что собеседник поймёт наш посыл «между строк». Но при этом если код — 💩, то так и будет сказано.
Намёк может быть понят неправильно, поэтому стоит помнить об этой склонности и возвращаться к Low-context.
Однако не стоит ориентироваться на Америку в части обратной связи. Конечно, не стоит говорить «твой код — говно». Но и формат «ты, конечно, молодец, но код — говно. Но ты, конечно, молодец» — не поможет.
И да, «хвали публично / ругай лично» 🙂
Правильный ответ на вопрос из прошлого поста — 3️⃣
C большей вероятностью представители двух разных High-context культур могут неправильно считывать «между строк» сообщения друг друга. Потому что их культура формировалась независимо в разном историческом контексте. Даже внутри одной страны есть риск неправильного считывания «между строк». Сейчас в распределенных командах работают ребята из разных регионов, и у каждого свой high-context.
Поэтому простое правило — в рабочей коммуникации использовать Low-context.
Самому выражаться максимально четко и детализированно и переспрашивать у собеседника, если начинаешь додумывать.
Давать максимум контекста: над чем работаешь и детали для правильного понимания ситуации. Объяснять, почему задаешь тот или иной вопрос. Да, иногда придется повторяться. Но лучше повторить, чем быть неправильно понятым.
А еще — не закладывать намёков и смыслов «между строк» в своей коммуникации и не пытаться найти их в словах собеседника.
Но из любого правила есть исключения.
Самое важное исключение — обратная связь.
Удивительно, но многие Low-context страны имеют культуру смягчения корректирующей обратной связи. Например, в Америке, UK и Канаде принято давать фидбек в формате «сендвича»: «несколько положительных аспектов, затем мягко упомянуть о том, что можно улучшить, и снова похвалить».
Раньше я давал фидбек именно так, считая это правильным. Но один разработчик назвал это «буллшит-бургером», и я понял, что такой подход может восприниматься как неискренний: положительная часть обесценивается, а корректирующая не воспринимается должным образом.
Теперь я стараюсь использовать Low-context коммуникацию, сохраняя при этом прямой стиль обратной связи.
На картинке — позиционирование стран в координатах «Коммуникация / Обратная связь».
Мы с вами находимся в квадранте «High-context / Direct negative feedback». Из этого делаем вывод, что в общем случае мы можем общаться намёками и рассчитывать, что собеседник поймёт наш посыл «между строк». Но при этом если код — 💩, то так и будет сказано.
Намёк может быть понят неправильно, поэтому стоит помнить об этой склонности и возвращаться к Low-context.
Однако не стоит ориентироваться на Америку в части обратной связи. Конечно, не стоит говорить «твой код — говно». Но и формат «ты, конечно, молодец, но код — говно. Но ты, конечно, молодец» — не поможет.
И да, «хвали публично / ругай лично» 🙂
Исследование тимлидов
В 23 году прошел большой опрос тимлидов от DevCrowd. Поделюсь интересностями оттуда.
Этот пост — призыв пройти опрос текущего года. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел.
Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики.
В прошлом опросе приняло участие 570 человек, из которых:
- 68% – тимлиды
- 22% – менеджеры менеджеров
- 9% – директора
📌 90% перешли в менеджмент в той же компании, где работали инженерами.
📌 Топ-3 обязанности руководителей любого уровня:
1️⃣ Собеседования,
2️⃣ Развитие людей в команде
3️⃣ Оценка их перфоманса.
📌 — 80% тимлидов считают себя сильнее большинства инженеров в своей команде.
📌— Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени.
📌 — Активно ищет работу только каждый десятый тимлид.
Подробнее, с инфографикой и даже видосом от Егора Толстого — Ссылка на результаты 2023.
———
P.S. там есть вопрос про медиа, которые вы читаете. Среди вариантов нет Product Developer, но есть поле «другое». Ну вы знаете, что туда написать 🙂
Пройти опрос.
В 23 году прошел большой опрос тимлидов от DevCrowd. Поделюсь интересностями оттуда.
Этот пост — призыв пройти опрос текущего года. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел.
Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики.
В прошлом опросе приняло участие 570 человек, из которых:
- 68% – тимлиды
- 22% – менеджеры менеджеров
- 9% – директора
📌 90% перешли в менеджмент в той же компании, где работали инженерами.
📌 Топ-3 обязанности руководителей любого уровня:
1️⃣ Собеседования,
2️⃣ Развитие людей в команде
3️⃣ Оценка их перфоманса.
📌 — 80% тимлидов считают себя сильнее большинства инженеров в своей команде.
📌— Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени.
📌 — Активно ищет работу только каждый десятый тимлид.
Подробнее, с инфографикой и даже видосом от Егора Толстого — Ссылка на результаты 2023.
———
P.S. там есть вопрос про медиа, которые вы читаете. Среди вариантов нет Product Developer, но есть поле «другое». Ну вы знаете, что туда написать 🙂
Пройти опрос.
Почему я продолжаю работать в Авито из Испании
Прошел год с написания поста Digital Nomad в Испании, а я всё еще работаю в Авито. Кстати, советую прочитать тот байопик нашего переезда :)
Раньше идея релокации для меня была сопряжена со сменой работы. До ковида и всеобщей удалёнки других вариантов и не было. Да и зарплата в рублях была маленькой для Европы. К тому же при релокации работодатель помогал с документами, билетами и арендой на первое время.
Но вот в прошлом году я релоцировался, сохранив работу. Почему?
0️⃣ Появилась такая возможность. Удалёнка стала нормой, а загнивающая Европа привлекает к себе молодых и талантливых с помощью новых типов внж.
1️⃣ Уровень зарплат выровнялся. Серьезно, посмотрите levels.fyi. Возьмем за пример немецкий Тинькофф — необанк N26. Медианная gross зп сеньора в Германии — €87K/год. Это ~€4.5k в месяц на руки после налогов. Сеньор-помидоры в РФ просят столько же. C тимлидскими позициями ситуация даже хуже.
2️⃣ Мне интересно в Авито. Потихоньку приближаюсь к ощущению, что работаю здесь уже достаточное время, чтобы что-то понимать и наносить пользу. И очень здорово, что есть островок стабильности в виде работы, который помогает заземлиться во время переезда и рождения ребенка.
3️⃣ В России рынок кандидата. Компании конкурируют за толковых ребят, процесс найма относительно лайтовый (да, даже если это несколько секций включая алгосы). В Европе — рынок работодателя. Кандидатов много больше, чем вакансий. Тестовое задание на день-два работы — норма. Трудоустроиться в европейскую компанию — не так-то просто.
4️⃣ Сейчас мой тип ВНЖ не привязан к работодателю. Если переходить работать на местную компанию — нужно менять тип ВНЖ и стану привязан. В случае увольнения будет всего месяц на поиски.
5️⃣ Работать в русскоязычной компании — понятнее. И дело даже не в твоём плохом английском, а в менталитете и плохом английском всей команды. Серьёзно, я знаю истории, когда ребята на созвоне не могли договориться, потому что не понимали речь друг друга, и уходили в текстовое обсуждение.
Чтоб жизнь малиной не казалась — расскажу про риски и минусы:
0️⃣ Собирать доки и подаваться на ВНЖ нужно самому, есть риск отказа. Мы приехали на машине с беременной женой и собакой по шенгену. Виза закончилась во время рассмотрения ВНЖ. Отказ был бы очень некстати в такой ситуации.
1️⃣ Курсы валют. Если рубль просядет к евро — мой доход снизится. Честно говоря, укрепления рубля я не жду. А вот зарплаты в рублях растут. Главное — иметь подушку безопасности и план.
2️⃣ Высокая цена «подписки на страну». Сюда я включаю прогрессивную ставку налога, цены на аренду жилья и на услуги. Стоит ли оно того — каждый решает сам.
3️⃣ Повидаться с роднёй или приехать на общекомандный сбор стало сильно дороже и сложнее, нужно закладывать два дня на дорогу.
Не зарекаюсь от переезда или перехода в другую компанию в будущем, но сейчас не собираюсь.
Наконец-то можно планировать жизнь на несколько лет вперед.
Прошел год с написания поста Digital Nomad в Испании, а я всё еще работаю в Авито. Кстати, советую прочитать тот байопик нашего переезда :)
Раньше идея релокации для меня была сопряжена со сменой работы. До ковида и всеобщей удалёнки других вариантов и не было. Да и зарплата в рублях была маленькой для Европы. К тому же при релокации работодатель помогал с документами, билетами и арендой на первое время.
Но вот в прошлом году я релоцировался, сохранив работу. Почему?
0️⃣ Появилась такая возможность. Удалёнка стала нормой, а загнивающая Европа привлекает к себе молодых и талантливых с помощью новых типов внж.
1️⃣ Уровень зарплат выровнялся. Серьезно, посмотрите levels.fyi. Возьмем за пример немецкий Тинькофф — необанк N26. Медианная gross зп сеньора в Германии — €87K/год. Это ~€4.5k в месяц на руки после налогов. Сеньор-помидоры в РФ просят столько же. C тимлидскими позициями ситуация даже хуже.
2️⃣ Мне интересно в Авито. Потихоньку приближаюсь к ощущению, что работаю здесь уже достаточное время, чтобы что-то понимать и наносить пользу. И очень здорово, что есть островок стабильности в виде работы, который помогает заземлиться во время переезда и рождения ребенка.
3️⃣ В России рынок кандидата. Компании конкурируют за толковых ребят, процесс найма относительно лайтовый (да, даже если это несколько секций включая алгосы). В Европе — рынок работодателя. Кандидатов много больше, чем вакансий. Тестовое задание на день-два работы — норма. Трудоустроиться в европейскую компанию — не так-то просто.
4️⃣ Сейчас мой тип ВНЖ не привязан к работодателю. Если переходить работать на местную компанию — нужно менять тип ВНЖ и стану привязан. В случае увольнения будет всего месяц на поиски.
5️⃣ Работать в русскоязычной компании — понятнее. И дело даже не в твоём плохом английском, а в менталитете и плохом английском всей команды. Серьёзно, я знаю истории, когда ребята на созвоне не могли договориться, потому что не понимали речь друг друга, и уходили в текстовое обсуждение.
Чтоб жизнь малиной не казалась — расскажу про риски и минусы:
0️⃣ Собирать доки и подаваться на ВНЖ нужно самому, есть риск отказа. Мы приехали на машине с беременной женой и собакой по шенгену. Виза закончилась во время рассмотрения ВНЖ. Отказ был бы очень некстати в такой ситуации.
1️⃣ Курсы валют. Если рубль просядет к евро — мой доход снизится. Честно говоря, укрепления рубля я не жду. А вот зарплаты в рублях растут. Главное — иметь подушку безопасности и план.
2️⃣ Высокая цена «подписки на страну». Сюда я включаю прогрессивную ставку налога, цены на аренду жилья и на услуги. Стоит ли оно того — каждый решает сам.
3️⃣ Повидаться с роднёй или приехать на общекомандный сбор стало сильно дороже и сложнее, нужно закладывать два дня на дорогу.
Не зарекаюсь от переезда или перехода в другую компанию в будущем, но сейчас не собираюсь.
Наконец-то можно планировать жизнь на несколько лет вперед.
Technical Design Review (TDR)
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть один большой минус: код уже написан. Когда появляются критичные комменты по архитектуре и нужно всё переписывать — очень демотивирует и может возникнуть конфликт.
Эту проблему решает TDR — Technical Design Review.
Это как кодревью, но про архитектуру и заранее: инженер описывает в Confluence предлагаемое решение и собирает обратную связь с команды и внешних ребят.
Как и в кодревью, есть плюсы, минусы и подводные камни.
Плюсы:
1️⃣ Более проработанное решение будет быстрее разработано и с меньшими проблемами.
Серьёзная проработка архитектуры до старта разработки даёт возможность полноценно попроектировать и учесть обратную связь.
2️⃣ Обмен знаниями и гарантия документирования.
Есть возможность научиться проектировать архитектуру у более опытных ребят. Проектировать может один, а разрабатывать — другой. Полноценная дока появляется еще до старта разработки.
3️⃣ Осведомленность команды и соседей.
При разработке будет меньше вопросов. Не будет проблем с интеграцией и вопросов «а что это вы тут делаете?». Не возникнет блокирующих рисков.
Минусы:
1️⃣ Увеличивает Time2market
Это компенсируется временем, сэкономленным на поддержке и рефакторингах. TDR = контроль за техдолгом.
Но есть подводные камни. TDR может «застрять на ревью» как задача на кодревью.
Причины могут быть разные, но результат — задержка реализации.
Способы решения этой проблемы — аналогичные для долгих кодревью:
— Договориться о сроках с ревьюерами.
— Определить в команде приоритет. В идеале, ревью кода и ревью TDR — приоритетнее, чем написание нового кода по своим задачам.
«Сел утром за работу — посмотри пулл реквесты и TDR».
— Заранее предупреждать о предстоящем ревью в следующем спринте. Просить запланировать ревью.
— Иметь четкую систему оценок и критичности комментов: что обязательно к исправлению, а что опционально.
— Иметь гайдлайны о том, что должно быть в TDR: компонентные и sequence-диаграммы, оценки объема данных и нагрузки, оценки рисков, план миграции, план отката. Это снимет часть вопросов, возникающих на большинстве TDR.
2️⃣ Иногда TDR делают там, где он не нужен, замедляя разработку. А иногда не делают там, где нужен, порождают риски.
Проблема в отсутствии договоренностей, какие изменения должны проходить через TDR.
Есть общие рекомендации по уровню влияния. Например, если есть выход за рамки команды — желателен TDR.
Впрочем, никто не настучит по голове, если TDR не будет. В итоге каждая команда сама решает, что выносить, а что — нет.
Поэтому нужно выписать четкие критерии для проведения TDR.
Например:
— Создание нового микросервиса
— Выбор базы данных
— Интеграция с внешней системой
Итог
Мы провели около 10 TDR за полгода.
Иногда это было больно: долгое ревью, сложно достучаться до внешних ребят, руки чешутся разрабатывать, но вынуждены уйти на доработку из-за критичных комментов.
Но в целом польза от TDR точно перевешивает.
Советую ли я читателю TDR?
— Однозначно, стоит попробовать!
Если у вас есть похожий опыт — делитесь в комментариях.
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть один большой минус: код уже написан. Когда появляются критичные комменты по архитектуре и нужно всё переписывать — очень демотивирует и может возникнуть конфликт.
Эту проблему решает TDR — Technical Design Review.
Это как кодревью, но про архитектуру и заранее: инженер описывает в Confluence предлагаемое решение и собирает обратную связь с команды и внешних ребят.
Как и в кодревью, есть плюсы, минусы и подводные камни.
Плюсы:
1️⃣ Более проработанное решение будет быстрее разработано и с меньшими проблемами.
Серьёзная проработка архитектуры до старта разработки даёт возможность полноценно попроектировать и учесть обратную связь.
2️⃣ Обмен знаниями и гарантия документирования.
Есть возможность научиться проектировать архитектуру у более опытных ребят. Проектировать может один, а разрабатывать — другой. Полноценная дока появляется еще до старта разработки.
3️⃣ Осведомленность команды и соседей.
При разработке будет меньше вопросов. Не будет проблем с интеграцией и вопросов «а что это вы тут делаете?». Не возникнет блокирующих рисков.
Минусы:
1️⃣ Увеличивает Time2market
Это компенсируется временем, сэкономленным на поддержке и рефакторингах. TDR = контроль за техдолгом.
Но есть подводные камни. TDR может «застрять на ревью» как задача на кодревью.
Причины могут быть разные, но результат — задержка реализации.
Способы решения этой проблемы — аналогичные для долгих кодревью:
— Договориться о сроках с ревьюерами.
— Определить в команде приоритет. В идеале, ревью кода и ревью TDR — приоритетнее, чем написание нового кода по своим задачам.
«Сел утром за работу — посмотри пулл реквесты и TDR».
— Заранее предупреждать о предстоящем ревью в следующем спринте. Просить запланировать ревью.
— Иметь четкую систему оценок и критичности комментов: что обязательно к исправлению, а что опционально.
— Иметь гайдлайны о том, что должно быть в TDR: компонентные и sequence-диаграммы, оценки объема данных и нагрузки, оценки рисков, план миграции, план отката. Это снимет часть вопросов, возникающих на большинстве TDR.
2️⃣ Иногда TDR делают там, где он не нужен, замедляя разработку. А иногда не делают там, где нужен, порождают риски.
Проблема в отсутствии договоренностей, какие изменения должны проходить через TDR.
Есть общие рекомендации по уровню влияния. Например, если есть выход за рамки команды — желателен TDR.
Впрочем, никто не настучит по голове, если TDR не будет. В итоге каждая команда сама решает, что выносить, а что — нет.
Поэтому нужно выписать четкие критерии для проведения TDR.
Например:
— Создание нового микросервиса
— Выбор базы данных
— Интеграция с внешней системой
Итог
Мы провели около 10 TDR за полгода.
Иногда это было больно: долгое ревью, сложно достучаться до внешних ребят, руки чешутся разрабатывать, но вынуждены уйти на доработку из-за критичных комментов.
Но в целом польза от TDR точно перевешивает.
Советую ли я читателю TDR?
— Однозначно, стоит попробовать!
Если у вас есть похожий опыт — делитесь в комментариях.
ProductSense
Прежде чем писать этот пост, я спросил у нашего продакта: Илья, это ценная конфа?
«Обычно да, так как довольно требовательно отбирают спикеров и темы. Я был один раз, но остались очень крутые впечатления от воркшопов»
Поэтому я согласился порекламировать в обмен на билет.
И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂
5-6 сентября, оффлайн в Москве или онлайн
Конфа для продактов и не только: есть доклады и про управление командой и проектом, а еще про взаимодействие Discovery <-> Delivery.
Спикеры и темы в расписании
Я бы сходил послушать Александра Вазюкова из Т-Банка с докладом “Приключение на 20 минут, или прогнозирование сроков проекта” (спойлер: прогнозирование не ради самого прогноза, а ради рефлексии)
А еще Александру Клименко из Soft Skills Lab — с докладом “Продакту не нужны софт скиллы?”. Кстати, еще у них будет воркшоп про переговоры.
В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн.
17 августа подняли цены на билеты, но у меня есть промокод для билетов Digital Pass и Professional, который возвращает цену к прошлой. Промокод действует три дня, пишите мне в личку @engineering_memeger.
Вот ссылка на лендос конференции
Прежде чем писать этот пост, я спросил у нашего продакта: Илья, это ценная конфа?
«Обычно да, так как довольно требовательно отбирают спикеров и темы. Я был один раз, но остались очень крутые впечатления от воркшопов»
Поэтому я согласился порекламировать в обмен на билет.
И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂
5-6 сентября, оффлайн в Москве или онлайн
Конфа для продактов и не только: есть доклады и про управление командой и проектом, а еще про взаимодействие Discovery <-> Delivery.
Спикеры и темы в расписании
Я бы сходил послушать Александра Вазюкова из Т-Банка с докладом “Приключение на 20 минут, или прогнозирование сроков проекта” (спойлер: прогнозирование не ради самого прогноза, а ради рефлексии)
А еще Александру Клименко из Soft Skills Lab — с докладом “Продакту не нужны софт скиллы?”. Кстати, еще у них будет воркшоп про переговоры.
В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн.
17 августа подняли цены на билеты, но у меня есть промокод для билетов Digital Pass и Professional, который возвращает цену к прошлой. Промокод действует три дня, пишите мне в личку @engineering_memeger.
Вот ссылка на лендос конференции
Культура код-ревью: приоритеты и скорость
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
DevOps в продуктовой разработке: outsource vs in-house
Этот пост — реклама Selectel. Мы давние друзья, делали коллабы для подлодки, а я сам их клиент для личных целей.
В тему верю, поэтому согласился разместить.
Продуктовая разработка и аутсорс DevOps могут показаться несовместимыми. На первый взгляд, это даже антонимы 🙂
Ведь DevOps — это не профессия, а культура совместной работы разработки и эксплуатации.
Однако давайте взглянем на это с другой стороны.
В Авито, например, есть внутренняя PaaS (Platform as a Service). Она позволяет разработчикам сосредоточиться на бизнес-логике, абстрагируясь от нюансов инфраструктуры в большинстве случаев.
И вот — новый микросервис в 3 кластерах с настроенным CI/CD, логами, метриками и трассировкой.
Готово — PgSQL развернут, секреты в Vault, подключения настроены.
Это экономит кучу времени и ускоряет разработку. Но не отменяет DevOps культуру. Доступ ко всем конфигам кубера в наличии, а с постгресом можно работать в режиме full access, если очень нужно.
Во всех предыдущих компаниях, где я работал — в оценки по задачам мы закладывали разворачивание и настройку инфры — кубера, баз данных, систем для трассировки, …
И это было существенное время.
В том, чтобы отдать инфру на аутсорс, есть куча плюсов:
1. Фокус разработчиков на продукте: Разработчики сосредоточены на продуктовом коде, не отвлекаясь на инфраструктурные задачи.
2. Как следствие — ускорение запуска фичей. Чем быстрее фичи доходят до пользователей, тем быстрее растет продукт и его аудитория.
3. Экономия ресурсов: Не нужно содержать штат инженеров инфраструктуры. Аутсорсер заботится о найме, мотивации, обучении, отпусках, рабочем ноутбуке и пенсионных отчислениях.
4. Финансовая ответственность за SLA: при проседании ниже 99.95% аутсорсер выплачивает компенсацию.
Оптимальное решение часто находится посередине. Базовую инфраструктуру можно отдать на аутсорс, сохранив при этом in-house команду для критичных компонентов и поддержания DevOps-культуры.
Важно помнить: DevOps — это про людей и процессы, а не только про инструменты.
Подробнее — на лендосе DevOps-as-a-Service.
Поделитесь в комментах — насколько вы погружены в инфру? Сколько % времени разработки занимает DevOps?
———
Реклама АО «Селектел». ИНН: 7810962785 Erid:2VtzqvYLck5
Этот пост — реклама Selectel. Мы давние друзья, делали коллабы для подлодки, а я сам их клиент для личных целей.
В тему верю, поэтому согласился разместить.
Продуктовая разработка и аутсорс DevOps могут показаться несовместимыми. На первый взгляд, это даже антонимы 🙂
Ведь DevOps — это не профессия, а культура совместной работы разработки и эксплуатации.
Однако давайте взглянем на это с другой стороны.
В Авито, например, есть внутренняя PaaS (Platform as a Service). Она позволяет разработчикам сосредоточиться на бизнес-логике, абстрагируясь от нюансов инфраструктуры в большинстве случаев.
$ avito service createИ вот — новый микросервис в 3 кластерах с настроенным CI/CD, логами, метриками и трассировкой.
$ avito service add postgresql Готово — PgSQL развернут, секреты в Vault, подключения настроены.
Это экономит кучу времени и ускоряет разработку. Но не отменяет DevOps культуру. Доступ ко всем конфигам кубера в наличии, а с постгресом можно работать в режиме full access, если очень нужно.
Во всех предыдущих компаниях, где я работал — в оценки по задачам мы закладывали разворачивание и настройку инфры — кубера, баз данных, систем для трассировки, …
И это было существенное время.
В том, чтобы отдать инфру на аутсорс, есть куча плюсов:
1. Фокус разработчиков на продукте: Разработчики сосредоточены на продуктовом коде, не отвлекаясь на инфраструктурные задачи.
2. Как следствие — ускорение запуска фичей. Чем быстрее фичи доходят до пользователей, тем быстрее растет продукт и его аудитория.
3. Экономия ресурсов: Не нужно содержать штат инженеров инфраструктуры. Аутсорсер заботится о найме, мотивации, обучении, отпусках, рабочем ноутбуке и пенсионных отчислениях.
4. Финансовая ответственность за SLA: при проседании ниже 99.95% аутсорсер выплачивает компенсацию.
Оптимальное решение часто находится посередине. Базовую инфраструктуру можно отдать на аутсорс, сохранив при этом in-house команду для критичных компонентов и поддержания DevOps-культуры.
Важно помнить: DevOps — это про людей и процессы, а не только про инструменты.
Подробнее — на лендосе DevOps-as-a-Service.
Поделитесь в комментах — насколько вы погружены в инфру? Сколько % времени разработки занимает DevOps?
———
Реклама АО «Селектел». ИНН: 7810962785 Erid:2VtzqvYLck5
promo.selectel.ru
DevOps-as-a-Service
Сократите time-to-market вашего продукта и создайте комфортную среду разработки, делегируя нам ответственность за управление и поддержку DevOps-практик.
Как подготовиться к собесу на тимлида?
… в продолжение к предыдущему посту.
Читать каналы из тимлидской папки, конечно же!
☀️Мой любимый Роадмап тимлида в канале Teamlead Good Reads — огромная база знаний по разным аспектам работы тимлида. Это очень толковый инструмент для собственного развития. А для собеса Роадмап поможет структурировать рассказ о себе.
☀️ Тимлид Очевидность — кладезь опыта. Ведет мой товарищ — Евгений Антонов. С удовольствием читаю сам и 100% могу рекомендовать.
— Как тимлиду собеседовать работодателя
— Подготовка к собеседованию по STAR
— Как оценить результат работы тимлида — эпизод подкаста, который поможетосознать свои заслуги и толково о них рассказать.
☀️ Ув. тов. Шароватов. — Вопросы работодателю на собесе. Невероятно харизматичный тимлид и просто аутентичный человек, с которым приятно общаться и перенимать опыт.
☀️TeamLead. С места в career. — Собеседование руководителей. К Ольге я приходил за советом еще когда стартовал свой канал 🙂 Точно рекомендую.
В папке 19 каналов. Верю, что каждый сможет найти для себя интересное.
Подписывайтесь: https://www.tg-me.com/addlist/CidpeALk4WJiODJi
… в продолжение к предыдущему посту.
Читать каналы из тимлидской папки, конечно же!
☀️Мой любимый Роадмап тимлида в канале Teamlead Good Reads — огромная база знаний по разным аспектам работы тимлида. Это очень толковый инструмент для собственного развития. А для собеса Роадмап поможет структурировать рассказ о себе.
☀️ Тимлид Очевидность — кладезь опыта. Ведет мой товарищ — Евгений Антонов. С удовольствием читаю сам и 100% могу рекомендовать.
— Как тимлиду собеседовать работодателя
— Подготовка к собеседованию по STAR
— Как оценить результат работы тимлида — эпизод подкаста, который поможетосознать свои заслуги и толково о них рассказать.
☀️ Ув. тов. Шароватов. — Вопросы работодателю на собесе. Невероятно харизматичный тимлид и просто аутентичный человек, с которым приятно общаться и перенимать опыт.
☀️TeamLead. С места в career. — Собеседование руководителей. К Ольге я приходил за советом еще когда стартовал свой канал 🙂 Точно рекомендую.
В папке 19 каналов. Верю, что каждый сможет найти для себя интересное.
Подписывайтесь: https://www.tg-me.com/addlist/CidpeALk4WJiODJi
Telegram
Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки
«Роадмап тимлида» получил собственный сайт, и теперь работать с ним стало проще! Пользуйтесь и не забывайте оставлять 🌟 на GitHub!
https://tlroadmap.io
https://tlroadmap.io
Podlodka Podcast: Авторизация
Вышел эпизод подлодки со мной!
Позвали рассказать про Авторизацию, а говорили 90% времени про Аутентификацию.
Про то, насколько всё проклято, и какое нас ждёт светлое будущее без паролей.
Ну и немного про авторизацию. И совсем чуть про технику.
С Podlodka Crew мы дружим давно: в составе программного комитета я делал конференции HR Crew и несколько сезонов Teamlead Crew.
А вот до подкаста дорос только сейчас. Все-таки Podlodka — это подкаст №1 в русскоязычном айти. Высший пилотаж, так сказать.
Спасибо Егору и Жене, что позвали. Приятно поговорить с умными людьми 🙂
🎧 Послушать
👀 Посмотреть на ютубе
Вышел эпизод подлодки со мной!
Позвали рассказать про Авторизацию, а говорили 90% времени про Аутентификацию.
Про то, насколько всё проклято, и какое нас ждёт светлое будущее без паролей.
Ну и немного про авторизацию. И совсем чуть про технику.
С Podlodka Crew мы дружим давно: в составе программного комитета я делал конференции HR Crew и несколько сезонов Teamlead Crew.
А вот до подкаста дорос только сейчас. Все-таки Podlodka — это подкаст №1 в русскоязычном айти. Высший пилотаж, так сказать.
Спасибо Егору и Жене, что позвали. Приятно поговорить с умными людьми 🙂
🎧 Послушать
👀 Посмотреть на ютубе
Yandex Scale — бесплатная конференция по облачным технологиям
25 сентября в Москве пройдет конференция, где будут выступать не только сотрудники Яндекса, но и спикеры из Райфа, Lamoda, Mindbox и других компаний.
Конференция организована по всем канонам: целый день, 5 параллельных треков, перерывы для нетворкинга и афтерпати в завершение.
Среди докладов меня заинтересовали:
— Новые возможности PostgreSQL 17
— Сломать, чтобы починить: парадокс хаос-инжиниринга в действии
— Новые горизонты платформы YDB: DWH, оптимизации, варианты поставки
— Ускоряем построение высоконагруженных решений на базе serverless YDB
Участие в конференции бесплатное, но требуется предварительная регистрация.
Лично я планирую смотреть онлайн. А вы присоединитесь?
25 сентября в Москве пройдет конференция, где будут выступать не только сотрудники Яндекса, но и спикеры из Райфа, Lamoda, Mindbox и других компаний.
Конференция организована по всем канонам: целый день, 5 параллельных треков, перерывы для нетворкинга и афтерпати в завершение.
Среди докладов меня заинтересовали:
— Новые возможности PostgreSQL 17
— Сломать, чтобы починить: парадокс хаос-инжиниринга в действии
— Новые горизонты платформы YDB: DWH, оптимизации, варианты поставки
— Ускоряем построение высоконагруженных решений на базе serverless YDB
Участие в конференции бесплатное, но требуется предварительная регистрация.
Лично я планирую смотреть онлайн. А вы присоединитесь?
Пять пороков команды
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на две части: здесь обзор и примеры, а в следующем — о методах «лечения».
Дисфункции идут по пирамиде — одна вытекает из другой, создавая систему взаимозависимых проблем. Я сталкивался с ними в больших командах, когда личный вклад размывается, и можно «затеряться».
Итак, вот они,слева-направо, люблю их снизу-вверх:
1️⃣ Отсутствие доверия — члены команды боятся ошибиться, т.к. предполагают, что за ошибку их сначала публично отчитают, а потом и вовсе уволят (и из-за этого они умрут от голода).
Например, разработчик неделю не признается в проблемах по задаче, боясь показаться некомпетентным. В результате цель спринта провалена, а осознание этого приходит в последний день, когда уже ничего нельзя сделать.
Это базовая дисфункция, лежащая в корне всех остальных проблем. Поэтому «лечение» команды нужно начинать именно с неё.
2️⃣ Боязнь конфликтов — команда избегает конструктивных споров: либо поверхностно соглашается с решением, либо быстро идет на компромисс, который в итоге никому не выгоден. Лишь бы не вступать в конфликт
Правильно — незачем раскачивать лодку. Сиди тихо и не высовывайся, всем лучше будет.
Например, при проработке нового сервиса разработчик предлагает новую технологию и никто не высказывает альтернативное мнение, хотя у многих есть сомнения. Потом приходится переделывать большие куски кода.
3️⃣ Отсутствие обязательств — команда не берет на себя ответственность за решения и договоренности.
Кто не принимает решений, тот не ошибается — Удобно.
Например, когда на ретроспективе возникает экшен-айтем, никто не вызывается взять его на себя. А командные соглашения забываются сразу после выходных.
Или другой пример — при выборе архитектуры разработчики не могут принять ответственность за решение и всегда привлекают тимлида.
4️⃣ Уклонение от ответственности — члены команды не призывают друг друга к ответу за действия и результаты.
Пока сидишь тихо и не привлекаешь внимание — всё хорошо. А если начнешь от кого-то чего-то требовать, то и от тебя начнут требовать. А оно тебе надо?
Например, никто не обращает внимания на то, что коллега постоянно нарушает код-стайл, аргументируя это спешкой. Техдолг растет, но все молчат.
Другой пример — один из разработчиков слишком часто берет дейоффы и «болеет». При этом никто из команды этого не замечает.
5️⃣ Невнимание к результатам — личные цели ставятся выше командных.
Какая нафиг цель спринта? Какие такие продуктовые метрики? Вот если я в резюме напишу, что работал с CockroachDB — вот это да, это понятно зачем нужно.
…
В итоге, это всё про страх потерять работу. Сиди на попе ровно, получай зарплату, не делай много / не высовывайся, не требуй много с других / не докапывайся.
И всё будет хорошо.
Нет, не будет.
В такой атмосфере нет ни удовольствия от работы, ни роста и развития. Люди увольняются, а проект загнивает.
Поэтому с дисфункциями нужно бороться.
Ключевое отличие команды от рабочей группы — наличие общей цели и взаимной поддержки. Но не достаточно просто формально обозначить «цель спринта». Нужно выстраивать доверительные отношения и атмосферу взаимопомощи.
Друзья, для следующего поста мне нужна ваша помощь: поделитесь в комментариях, с какими из этих дисфункций вы сталкивались? Как боролись? Как поняли, что ситуация улучшилась?
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на две части: здесь обзор и примеры, а в следующем — о методах «лечения».
Дисфункции идут по пирамиде — одна вытекает из другой, создавая систему взаимозависимых проблем. Я сталкивался с ними в больших командах, когда личный вклад размывается, и можно «затеряться».
Итак, вот они,
1️⃣ Отсутствие доверия — члены команды боятся ошибиться, т.к. предполагают, что за ошибку их сначала публично отчитают, а потом и вовсе уволят (и из-за этого они умрут от голода).
Например, разработчик неделю не признается в проблемах по задаче, боясь показаться некомпетентным. В результате цель спринта провалена, а осознание этого приходит в последний день, когда уже ничего нельзя сделать.
Это базовая дисфункция, лежащая в корне всех остальных проблем. Поэтому «лечение» команды нужно начинать именно с неё.
2️⃣ Боязнь конфликтов — команда избегает конструктивных споров: либо поверхностно соглашается с решением, либо быстро идет на компромисс, который в итоге никому не выгоден. Лишь бы не вступать в конфликт
Правильно — незачем раскачивать лодку. Сиди тихо и не высовывайся, всем лучше будет.
Например, при проработке нового сервиса разработчик предлагает новую технологию и никто не высказывает альтернативное мнение, хотя у многих есть сомнения. Потом приходится переделывать большие куски кода.
3️⃣ Отсутствие обязательств — команда не берет на себя ответственность за решения и договоренности.
Кто не принимает решений, тот не ошибается — Удобно.
Например, когда на ретроспективе возникает экшен-айтем, никто не вызывается взять его на себя. А командные соглашения забываются сразу после выходных.
Или другой пример — при выборе архитектуры разработчики не могут принять ответственность за решение и всегда привлекают тимлида.
4️⃣ Уклонение от ответственности — члены команды не призывают друг друга к ответу за действия и результаты.
Пока сидишь тихо и не привлекаешь внимание — всё хорошо. А если начнешь от кого-то чего-то требовать, то и от тебя начнут требовать. А оно тебе надо?
Например, никто не обращает внимания на то, что коллега постоянно нарушает код-стайл, аргументируя это спешкой. Техдолг растет, но все молчат.
Другой пример — один из разработчиков слишком часто берет дейоффы и «болеет». При этом никто из команды этого не замечает.
5️⃣ Невнимание к результатам — личные цели ставятся выше командных.
Какая нафиг цель спринта? Какие такие продуктовые метрики? Вот если я в резюме напишу, что работал с CockroachDB — вот это да, это понятно зачем нужно.
…
В итоге, это всё про страх потерять работу. Сиди на попе ровно, получай зарплату, не делай много / не высовывайся, не требуй много с других / не докапывайся.
И всё будет хорошо.
Нет, не будет.
В такой атмосфере нет ни удовольствия от работы, ни роста и развития. Люди увольняются, а проект загнивает.
Поэтому с дисфункциями нужно бороться.
Ключевое отличие команды от рабочей группы — наличие общей цели и взаимной поддержки. Но не достаточно просто формально обозначить «цель спринта». Нужно выстраивать доверительные отношения и атмосферу взаимопомощи.
Друзья, для следующего поста мне нужна ваша помощь: поделитесь в комментариях, с какими из этих дисфункций вы сталкивались? Как боролись? Как поняли, что ситуация улучшилась?
Product Developer
Пять пороков команды — это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция». Пост получился объёмным, поэтому я его разделил на две…
Как лечить пять дисфункций команды: практические шаги
В прошлом посте я описал пять дисфункций команды по Патрику Ленсиони, а теперь поговорим о том, как их "лечить". Часть идей из книги, часть из личного опыта, часть — из ваших комментариев. Список не полный, так что делитесь своими мыслями, буду рад обсудить.
1️⃣ Отсутствие доверия
Лечение:
— Поощряйте открытое признание ошибок. Начните с себя, покажите свою ошибку. Призывайте ошибаться и учиться на ошибках. А в следующий раз, когда разработчик заранее скажет о проблеме по цели спринта, — поблагодарите и объясните, как это помогло команде достичь цели
— Тимбилдинги, как бы банально ни звучало. Нужно дать возможность команде узнать друг друга вне рабочего контекста. Можно провести даже онлайн. Мы делали встречу под названием «барушник» в пятницу вечером — созванивались по зуму, чтобы поиграть в клавогонки или просто поболтать на разные темы
— Командные тренинги. Есть разные упражнения, но по сути важно просто собрать всех вместе и дать пространство рассказать друг другу о взаимных ожиданиях. Есть тренинг «пять пороков команды», я его проходил лет пять назад. Он тогда стал хорошей стартовой точкой для налаживания отношений в команде
Признаки улучшения: ребята чаще обращаются за помощью к команде, открыто обсуждают свои трудности и ошибки, воспринимая их как возможность для роста.
2️⃣ Боязнь конфликтов
Лечение:
— Попробуйте практику «адвокат дьявола». Один из участников обсуждения намеренно надевает шляпу адвоката дьявола и оспаривает предложенные идеи. Важно заранее проговорить это и оспаривать именно идею, а не накидывать на её автора. Нужен модератор
— Перед важными решениями можно проводить анонимные опросы, чтобы выявить сомнения
— Обучайте команду конструктивной обратной связи. Тут советую всем Методичку по ненасильственному общению и Фреймворки обратной связи
Признаки улучшения: Обсуждения становятся более оживленными, решения принимаются после рассмотрения альтернатив, с учетом плюсов, минусов и рисков.
3️⃣ Отсутствие обязательств
Лечение:
— Попробуйте технику «молчаливого голосования», где каждый анонимно оценивает свою поддержку решения. Если команда не поддержит решение — то не будет и обязательств по его соблюдению
— Записывайте все договоренности в конце обсуждений и назначайте ответственного, который будет при случае возвращать команду к принятым решениям и договоренностям
— Для экшн-айтемов четко прописывайте: кто, что и до какого момента должен сделать
Признаки улучшения: Решения принимаются быстрее, команда более последовательна в их выполнении. Экшн-айтемы с ретроспектив не накапливаются, а своевременно выполняются.
4️⃣ Уклонение от ответственности
Лечение:
— Проводите регулярные сессии обратной связи в формате 360
— Поощряйте культуру "вызова", где каждый член команды может задать вопрос о действиях коллеги. Тут важно не переборщить 🙂
— При возникновении ситуаций как в прошлом посте, например один разработчик слишком часто берет дейоффы, спрашивайте у ребят на 1-1 — что мешает им высказаться
Признаки улучшения: Члены команды регулярно обмениваются конструктивной обратной связью, что приводит к повышению общего качества работы и укреплению командного духа
5️⃣ Невнимание к результатам
Лечение:
— Визуализируйте общие цели команды и регулярно обсуждайте прогресс
— Обсудите с командой, как личные цели каждого участника могут способствовать достижению общих целей проекта
— Празднуйте общие успехи команды, а не только индивидуальные достижения
Признаки улучшения: Сотрудники чаще обсуждают общие цели, готовы жертвовать личными интересами ради общего результата.
———
Важно помнить, что "лечение" этих дисфункций — это непрерывный процесс. При чем во многом это процесс перевоспитания взрослых людей, а это на грани возможного.
Начните с построения доверия и постепенно двигайтесь вверх по пирамиде.
Возможно, в процессе прочтения, у вас где-то бомбануло, или вы вспомнили свой способ «лечения». Как сказал в начале, список не полный, поэтому буду рад обсудить в комментариях.
В прошлом посте я описал пять дисфункций команды по Патрику Ленсиони, а теперь поговорим о том, как их "лечить". Часть идей из книги, часть из личного опыта, часть — из ваших комментариев. Список не полный, так что делитесь своими мыслями, буду рад обсудить.
1️⃣ Отсутствие доверия
Лечение:
— Поощряйте открытое признание ошибок. Начните с себя, покажите свою ошибку. Призывайте ошибаться и учиться на ошибках. А в следующий раз, когда разработчик заранее скажет о проблеме по цели спринта, — поблагодарите и объясните, как это помогло команде достичь цели
— Тимбилдинги, как бы банально ни звучало. Нужно дать возможность команде узнать друг друга вне рабочего контекста. Можно провести даже онлайн. Мы делали встречу под названием «барушник» в пятницу вечером — созванивались по зуму, чтобы поиграть в клавогонки или просто поболтать на разные темы
— Командные тренинги. Есть разные упражнения, но по сути важно просто собрать всех вместе и дать пространство рассказать друг другу о взаимных ожиданиях. Есть тренинг «пять пороков команды», я его проходил лет пять назад. Он тогда стал хорошей стартовой точкой для налаживания отношений в команде
Признаки улучшения: ребята чаще обращаются за помощью к команде, открыто обсуждают свои трудности и ошибки, воспринимая их как возможность для роста.
2️⃣ Боязнь конфликтов
Лечение:
— Попробуйте практику «адвокат дьявола». Один из участников обсуждения намеренно надевает шляпу адвоката дьявола и оспаривает предложенные идеи. Важно заранее проговорить это и оспаривать именно идею, а не накидывать на её автора. Нужен модератор
— Перед важными решениями можно проводить анонимные опросы, чтобы выявить сомнения
— Обучайте команду конструктивной обратной связи. Тут советую всем Методичку по ненасильственному общению и Фреймворки обратной связи
Признаки улучшения: Обсуждения становятся более оживленными, решения принимаются после рассмотрения альтернатив, с учетом плюсов, минусов и рисков.
3️⃣ Отсутствие обязательств
Лечение:
— Попробуйте технику «молчаливого голосования», где каждый анонимно оценивает свою поддержку решения. Если команда не поддержит решение — то не будет и обязательств по его соблюдению
— Записывайте все договоренности в конце обсуждений и назначайте ответственного, который будет при случае возвращать команду к принятым решениям и договоренностям
— Для экшн-айтемов четко прописывайте: кто, что и до какого момента должен сделать
Признаки улучшения: Решения принимаются быстрее, команда более последовательна в их выполнении. Экшн-айтемы с ретроспектив не накапливаются, а своевременно выполняются.
4️⃣ Уклонение от ответственности
Лечение:
— Проводите регулярные сессии обратной связи в формате 360
— Поощряйте культуру "вызова", где каждый член команды может задать вопрос о действиях коллеги. Тут важно не переборщить 🙂
— При возникновении ситуаций как в прошлом посте, например один разработчик слишком часто берет дейоффы, спрашивайте у ребят на 1-1 — что мешает им высказаться
Признаки улучшения: Члены команды регулярно обмениваются конструктивной обратной связью, что приводит к повышению общего качества работы и укреплению командного духа
5️⃣ Невнимание к результатам
Лечение:
— Визуализируйте общие цели команды и регулярно обсуждайте прогресс
— Обсудите с командой, как личные цели каждого участника могут способствовать достижению общих целей проекта
— Празднуйте общие успехи команды, а не только индивидуальные достижения
Признаки улучшения: Сотрудники чаще обсуждают общие цели, готовы жертвовать личными интересами ради общего результата.
———
Важно помнить, что "лечение" этих дисфункций — это непрерывный процесс. При чем во многом это процесс перевоспитания взрослых людей, а это на грани возможного.
Начните с построения доверия и постепенно двигайтесь вверх по пирамиде.
Возможно, в процессе прочтения, у вас где-то бомбануло, или вы вспомнили свой способ «лечения». Как сказал в начале, список не полный, поэтому буду рад обсудить в комментариях.
E-CODE by Ozon Tech | 28 и 29 сентября
Больше бесплатных оффлайн конференций от бигтехов!
2 дня, 4 параллельных трека, 50 выступлений.
Москва, 28-29 сентября.
Онлайн трансляция, конечно же, будет.
28 сентября — Менеджмент, Бэкенд, Инфра, Наука и жизнь.
Точно буду смотреть:
1️⃣ — Алексей Пименов / Neogenda —Трехуровневая система управления
Алексея всегда интересно послушать, хожу на его доклады на всех конференциях 🙂
2️⃣ — Александр Бирюков / Т-Банк — SageDB: зачем мы пишем свою базу данных
Меня привлекает тема баз данных, а когда кто-то из игроков рынка пишет свою — это значит, что по каким-то причинам не подошли существующие, и это вдвойне интересно.
3️⃣ — ClickHouse как пример DBaaS во внутреннем облаке / Евгений Сударчиков / Ozon
В Авито у нас есть ClickHouse в DBaaS, хочу сравнить реализацию и возможности для разработчиков.
4️⃣ — Квантовые вычисления: основные идеи и современное состояние технологии / Станислав Страупе / Сбер/МГУ/РКЦ
На доклад про квантовый компьютер я ходил на HighLoad++ в 2020 году. Было очень познавательно, и сейчас для меня это шанс быстро освежить тему и узнать прогресс за прошедшее время.
29 сентября — QA, Mobile, ML&DS, Наука и жизнь.
Меня заинтересовали:
1️⃣ — Нагрузочное тестирование в Ozon: прошлое, настоящее и будущее / Иван Приходько / Ozon
Все готовят нагрузочное тестирование по-разному. Буду набираться насмотренности.
2️⃣ — Figma Mockup to Server-Driven UI / Владислав Чешенко / Альфа-Банк.
Знаю, что в Альфе Server-Driven UI начали делать еще до санкций, и очень интересно посмотреть на их опыт.
3️⃣ — История развития архитектуры системы рекомендаций Ozon / Алексей Гурьянов / Ozon
В Авито рекомендации — очень интересная и сложная область разработки. Хочу посмотреть, как её готовят в других компаниях.
Москва. 28 и 29 сентября. Оффлайн и онлайн.
Зарегистрироваться
Больше бесплатных оффлайн конференций от бигтехов!
2 дня, 4 параллельных трека, 50 выступлений.
Москва, 28-29 сентября.
Онлайн трансляция, конечно же, будет.
28 сентября — Менеджмент, Бэкенд, Инфра, Наука и жизнь.
Точно буду смотреть:
1️⃣ — Алексей Пименов / Neogenda —Трехуровневая система управления
Алексея всегда интересно послушать, хожу на его доклады на всех конференциях 🙂
2️⃣ — Александр Бирюков / Т-Банк — SageDB: зачем мы пишем свою базу данных
Меня привлекает тема баз данных, а когда кто-то из игроков рынка пишет свою — это значит, что по каким-то причинам не подошли существующие, и это вдвойне интересно.
3️⃣ — ClickHouse как пример DBaaS во внутреннем облаке / Евгений Сударчиков / Ozon
В Авито у нас есть ClickHouse в DBaaS, хочу сравнить реализацию и возможности для разработчиков.
4️⃣ — Квантовые вычисления: основные идеи и современное состояние технологии / Станислав Страупе / Сбер/МГУ/РКЦ
На доклад про квантовый компьютер я ходил на HighLoad++ в 2020 году. Было очень познавательно, и сейчас для меня это шанс быстро освежить тему и узнать прогресс за прошедшее время.
29 сентября — QA, Mobile, ML&DS, Наука и жизнь.
Меня заинтересовали:
1️⃣ — Нагрузочное тестирование в Ozon: прошлое, настоящее и будущее / Иван Приходько / Ozon
Все готовят нагрузочное тестирование по-разному. Буду набираться насмотренности.
2️⃣ — Figma Mockup to Server-Driven UI / Владислав Чешенко / Альфа-Банк.
Знаю, что в Альфе Server-Driven UI начали делать еще до санкций, и очень интересно посмотреть на их опыт.
3️⃣ — История развития архитектуры системы рекомендаций Ozon / Алексей Гурьянов / Ozon
В Авито рекомендации — очень интересная и сложная область разработки. Хочу посмотреть, как её готовят в других компаниях.
Москва. 28 и 29 сентября. Оффлайн и онлайн.
Зарегистрироваться
Как составить индивидуальный план развития
Один товарищ спросил, как самому составить себе ИПР. Я пытался найти и скинуть ему какую-нибудь годную статью, но не смог.
Поэтому пишу пост и выкладываю шаблон ИПР, который мне дали в QIWI 4 года назад — он всё еще лучший ♥️
Вот простой фреймворк из 3 шагов:
1️⃣ — Точка А — Где мы сейчас
Самодиагностика, собес или сессия с ментором помогут определить текущий уровень.
Для самодиагностики можно примерить на себя матрицы компетенций из Avito Playbook:
— Разработчики (Там есть даже шаблон Windrose, добавленный мною)
— Аналитики данных
— Продакты
— Дизайнеры
— Тимлиды и инжиниринг менеджеры
— Data-Science инженеры
2️⃣ — Точка Б — Куда хотим попасть
— Если хотите помочь команде — можно составить StarMap, чтобы найти недостающие в команде компетенции и качать именно их.
Более простой вариант — спросить у продакта или тимлида, каких компетенций им хотелось бы добавить команде.
— Если хотите пользу для себя — можно попросить подробный фидбек на собеседовании, либо пройти сессию с ментором. Можно сходить на конференцию, посмотреть что сейчас в тренде. Можно подумать, каких навыков не хватало на прошлых задачах.
Важно понимать цель, сроки и ожидаемый результат:
1. Какой эффект даст прокачка навыка?
2. Когда хотите увидеть результат?
3. В чем польза?
Например, Вася хочет:
— качать алгосы, чтобы лучше проходить собесы
— качать базы данных, чтобы оптимизировать медленные запросы и улучшить продукт.
Эффектом может быть либо прокачка в решении интересной рабочей задачи, либо смена работы. Выбор за Васей.
3️⃣ — Строим маршрут А -> Б
Если хотите прокачаться именно в рабочих задачах, то можно пойти по модели Дженнингса:
— 10% теория. Это могут быть статьи, поход на конференцию, просмотр записей докладов, ну или курс.
— 20% наблюдение за другими. Найдите коллегу, который хорошо делает то, чему хотите научиться.
— 70% практика с обратной связью от ментора. Ну тут всё просто. Берешь и делаешь 🙂. Потом собираешь обратную связь и переделываешь.
Пропишите конкретные шаги, установите дедлайны и оцените риски. Если нужна помощь — договоритесь с людьми заранее. Главное — критерии успеха: как вы поймёте, что навык прокачан? Возможно, это будет успешное завершение рабочей задачи.
———
Если вы всё хотели составить себе ИПР, но никак не добирались до этого и ждали знака — вот он. Составьте себе ИПР 🙃
Шаблон ИПР поможет побороть проблему белого листа.
Один товарищ спросил, как самому составить себе ИПР. Я пытался найти и скинуть ему какую-нибудь годную статью, но не смог.
Поэтому пишу пост и выкладываю шаблон ИПР, который мне дали в QIWI 4 года назад — он всё еще лучший ♥️
Вот простой фреймворк из 3 шагов:
1️⃣ — Точка А — Где мы сейчас
Самодиагностика, собес или сессия с ментором помогут определить текущий уровень.
Для самодиагностики можно примерить на себя матрицы компетенций из Avito Playbook:
— Разработчики (Там есть даже шаблон Windrose, добавленный мною)
— Аналитики данных
— Продакты
— Дизайнеры
— Тимлиды и инжиниринг менеджеры
— Data-Science инженеры
2️⃣ — Точка Б — Куда хотим попасть
— Если хотите помочь команде — можно составить StarMap, чтобы найти недостающие в команде компетенции и качать именно их.
Более простой вариант — спросить у продакта или тимлида, каких компетенций им хотелось бы добавить команде.
— Если хотите пользу для себя — можно попросить подробный фидбек на собеседовании, либо пройти сессию с ментором. Можно сходить на конференцию, посмотреть что сейчас в тренде. Можно подумать, каких навыков не хватало на прошлых задачах.
Важно понимать цель, сроки и ожидаемый результат:
1. Какой эффект даст прокачка навыка?
2. Когда хотите увидеть результат?
3. В чем польза?
Например, Вася хочет:
— качать алгосы, чтобы лучше проходить собесы
— качать базы данных, чтобы оптимизировать медленные запросы и улучшить продукт.
Эффектом может быть либо прокачка в решении интересной рабочей задачи, либо смена работы. Выбор за Васей.
3️⃣ — Строим маршрут А -> Б
Если хотите прокачаться именно в рабочих задачах, то можно пойти по модели Дженнингса:
— 10% теория. Это могут быть статьи, поход на конференцию, просмотр записей докладов, ну или курс.
— 20% наблюдение за другими. Найдите коллегу, который хорошо делает то, чему хотите научиться.
— 70% практика с обратной связью от ментора. Ну тут всё просто. Берешь и делаешь 🙂. Потом собираешь обратную связь и переделываешь.
Пропишите конкретные шаги, установите дедлайны и оцените риски. Если нужна помощь — договоритесь с людьми заранее. Главное — критерии успеха: как вы поймёте, что навык прокачан? Возможно, это будет успешное завершение рабочей задачи.
———
Если вы всё хотели составить себе ИПР, но никак не добирались до этого и ждали знака — вот он. Составьте себе ИПР 🙃
Шаблон ИПР поможет побороть проблему белого листа.
SMART для ИПР и не только — фреймворк для постановки целей
Это пост-дополнение к посту с шаблоном ИПР. По нему возникли вопросы — «что за заголовки Конкретные, Измеримые,… Что туда писать»?
В мире красивых аббревиатур много булшита, но эти 5 букв считаю достаточно ценными, чтобы о них рассказать.
Если просто записать в ИПР «Прокачаться в базах данных» — это будет достаточно абстрактно и породит кучу вопросов:
— Зачем?
— Как поймешь, что прокачался?
— А когда?
Вот SMART — как раз чтобы ответить на эти вопросы при постановке цели.
1️⃣ Specific (конкретная) — Цель должна быть понятной и чёткой
Пример, вместо «Прокачаться в базах данных» — «Научиться оптимизировать SQL запросы».
Чем более детализирована цель, тем легче к ней идти.
2️⃣ Measurable (измеримая) — Цель должна иметь чёткие показатели успеха.
Пример: «Уменьшить время выполнения SQL-запросов в синхронных пользовательских сценариях до 500 миллисекунд максимум при нагрузке в 1М пользователей».
Чем больше конкретных цифр получится дать — тем лучше.
Если получится выполнить цель в изначальной постановке — круто! Но это редкость.
Не беда, если в процессе придет понимание, что в текущем виде цель не получается выполнить.
Расценивайте это как вектор. Направление, куда двигаться. И да, с появлением новых вводных вектор может меняться.
Лучше двигаться с вектором, чем по кругу или по траектории как на картинке к посту.
3️⃣ Achievable (достижимая) — Реалистична ли цель в текущих условиях?
Есть ли обучающие материалы, эксперты за которыми можно наблюдать, и задачи, на которых применить новые знания?
Пример: «Пройти курс по оптимизации SQL-запросов и внедрить улучшения в течение двух спринтов, привлекать эксперта Васю для ревью»
Важно не перегружать себя и оценивать реальные возможности.
4️⃣ Relevant (релевантная/согласованная) — Цель должна быть важной для ваших текущих задач и карьеры.
Пример: «Запросы нужно оптимизировать для того, чтобы сервис держал нагрузку на 1 миллионе пользователей — с текущим ростом это будет через полгода»
Важно, чтобы цель приносила пользу лично вам и вашей команде.
5️⃣ Time-bound (ограниченная по времени) — Определите дедлайн.
Пример: "Закончить курс по SQL за 2 недели и оптимизировать запросы до конца месяца".
Причем план может быть отложенным — здесь не сказано, что это должно происходить в следующие два спринта. Это может быть план развития на полугодие, где конкретно эта цель стартует в следующем квартале.
Сроки мотивируют и помогают не откладывать выполнение задач.
———
SMART пригождается не только в ИПР, но и в постановке целей на квартал для команды или личных целей.
Важная ремарка: бывают цели, к которым очень сложно приложить линеечку.
У нас был рефакторинг, эффект от которого мы не смогли оцифровать. Но! сама попытка дала важные мысли о том, как скорректировать план рефакторинга.
Когда будете ставить цели в следующий раз — попробуйте описать их по этим 5 буквам.
Даже если финальая формулировка не будет описана по SMART, это упражнение будет полезным и поможет доуточнить цель и путь достижения.
Это пост-дополнение к посту с шаблоном ИПР. По нему возникли вопросы — «что за заголовки Конкретные, Измеримые,… Что туда писать»?
В мире красивых аббревиатур много булшита, но эти 5 букв считаю достаточно ценными, чтобы о них рассказать.
Если просто записать в ИПР «Прокачаться в базах данных» — это будет достаточно абстрактно и породит кучу вопросов:
— Зачем?
— Как поймешь, что прокачался?
— А когда?
Вот SMART — как раз чтобы ответить на эти вопросы при постановке цели.
1️⃣ Specific (конкретная) — Цель должна быть понятной и чёткой
Пример, вместо «Прокачаться в базах данных» — «Научиться оптимизировать SQL запросы».
Чем более детализирована цель, тем легче к ней идти.
2️⃣ Measurable (измеримая) — Цель должна иметь чёткие показатели успеха.
Пример: «Уменьшить время выполнения SQL-запросов в синхронных пользовательских сценариях до 500 миллисекунд максимум при нагрузке в 1М пользователей».
Чем больше конкретных цифр получится дать — тем лучше.
Если получится выполнить цель в изначальной постановке — круто! Но это редкость.
Не беда, если в процессе придет понимание, что в текущем виде цель не получается выполнить.
Расценивайте это как вектор. Направление, куда двигаться. И да, с появлением новых вводных вектор может меняться.
Лучше двигаться с вектором, чем по кругу или по траектории как на картинке к посту.
3️⃣ Achievable (достижимая) — Реалистична ли цель в текущих условиях?
Есть ли обучающие материалы, эксперты за которыми можно наблюдать, и задачи, на которых применить новые знания?
Пример: «Пройти курс по оптимизации SQL-запросов и внедрить улучшения в течение двух спринтов, привлекать эксперта Васю для ревью»
Важно не перегружать себя и оценивать реальные возможности.
4️⃣ Relevant (релевантная/согласованная) — Цель должна быть важной для ваших текущих задач и карьеры.
Пример: «Запросы нужно оптимизировать для того, чтобы сервис держал нагрузку на 1 миллионе пользователей — с текущим ростом это будет через полгода»
Важно, чтобы цель приносила пользу лично вам и вашей команде.
5️⃣ Time-bound (ограниченная по времени) — Определите дедлайн.
Пример: "Закончить курс по SQL за 2 недели и оптимизировать запросы до конца месяца".
Причем план может быть отложенным — здесь не сказано, что это должно происходить в следующие два спринта. Это может быть план развития на полугодие, где конкретно эта цель стартует в следующем квартале.
Сроки мотивируют и помогают не откладывать выполнение задач.
———
SMART пригождается не только в ИПР, но и в постановке целей на квартал для команды или личных целей.
Важная ремарка: бывают цели, к которым очень сложно приложить линеечку.
У нас был рефакторинг, эффект от которого мы не смогли оцифровать. Но! сама попытка дала важные мысли о том, как скорректировать план рефакторинга.
Когда будете ставить цели в следующий раз — попробуйте описать их по этим 5 буквам.
Даже если финальая формулировка не будет описана по SMART, это упражнение будет полезным и поможет доуточнить цель и путь достижения.
Servant leadership vs Управляемость команды
Disclaimer: это реклама бесплатного вебинара от Soft Skills Lab. Ребят уважаю, тема откликается, сам пойду.
Концепция «Лидер-слуга» — стиль управления через предоставление свободы сотрудникам и помощь в устранении препятствий. Команда вовлечена в принятие всех решений, с их мнением считаются, и они вольны делать что захотят и как захотят.
Google был одной из первых компаний, кто популяризировал эту концепцию. В книге Work Rules автор утверждает, что свобода сотрудников — ключ к продуктивности. И что единственный способ обеспечить свободу — это отнять власть у менеджеров. Например, менеджер не может самостоятельно решить вопрос о найме, увольнении или оценке на перформанс ревью.
Даже без таких радикальных мер я знаю много тимлидов, которые стараются работать в стиле servant leadership. И я сам поддерживаю вовлечение инженеров и чувствую, что ребята тоже проявляют инициативу.
Этот подход может сплотить команду, поднять мотивацию и привести к росту перформанса и скорости достижения результатов.
Но…
Есть некая грань, после которой команда садится на шею и становится неуправляемой:
▫️ исключения из правил становятся нормой — опоздать, забыть, не прийти
▫️ требования к тимлиду/продакту/… растут, а эффективность команды падает
▫️ отговорок больше, чем сделанных задач
Если узнали свою команду хотя бы в одном пункте, это опасный звоночек. Потеря управляемости — процесс постепенный и незаметный, поэтому важно вовремя его отловить и остановить.
3 октября в 20:00 по мск Саша Клименко, основательница Soft Skills Lab, проведет открытый воркшоп «Как не потерять управляемость команды? 5 ошибок в коммуникации и как их исправлять».
Это будет бесплатное занятие в Zoom с практикой на реальных кейсах и общением голосом (приносите свои ситуации и вопросы!)
За 1,5 часа вы узнаете:
▫️ Какие ошибки в коммуникации не дают наладить контакт с командой?
▫️ Как отследить потерю управляемости и не допустить ее?
▫️ Что делать, если вы уже чувствуете, что сотрудники сели на шею?
Ссылку на встречу отправят в бота. Зарегистрироваться.
Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqx6CbxM
Disclaimer: это реклама бесплатного вебинара от Soft Skills Lab. Ребят уважаю, тема откликается, сам пойду.
Концепция «Лидер-слуга» — стиль управления через предоставление свободы сотрудникам и помощь в устранении препятствий. Команда вовлечена в принятие всех решений, с их мнением считаются, и они вольны делать что захотят и как захотят.
Google был одной из первых компаний, кто популяризировал эту концепцию. В книге Work Rules автор утверждает, что свобода сотрудников — ключ к продуктивности. И что единственный способ обеспечить свободу — это отнять власть у менеджеров. Например, менеджер не может самостоятельно решить вопрос о найме, увольнении или оценке на перформанс ревью.
Даже без таких радикальных мер я знаю много тимлидов, которые стараются работать в стиле servant leadership. И я сам поддерживаю вовлечение инженеров и чувствую, что ребята тоже проявляют инициативу.
Этот подход может сплотить команду, поднять мотивацию и привести к росту перформанса и скорости достижения результатов.
Но…
Есть некая грань, после которой команда садится на шею и становится неуправляемой:
▫️ исключения из правил становятся нормой — опоздать, забыть, не прийти
▫️ требования к тимлиду/продакту/… растут, а эффективность команды падает
▫️ отговорок больше, чем сделанных задач
Если узнали свою команду хотя бы в одном пункте, это опасный звоночек. Потеря управляемости — процесс постепенный и незаметный, поэтому важно вовремя его отловить и остановить.
3 октября в 20:00 по мск Саша Клименко, основательница Soft Skills Lab, проведет открытый воркшоп «Как не потерять управляемость команды? 5 ошибок в коммуникации и как их исправлять».
Это будет бесплатное занятие в Zoom с практикой на реальных кейсах и общением голосом (приносите свои ситуации и вопросы!)
За 1,5 часа вы узнаете:
▫️ Какие ошибки в коммуникации не дают наладить контакт с командой?
▫️ Как отследить потерю управляемости и не допустить ее?
▫️ Что делать, если вы уже чувствуете, что сотрудники сели на шею?
Ссылку на встречу отправят в бота. Зарегистрироваться.
Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqx6CbxM
Telegram
Soft Skills Lab bot
Бот для организации мероприятий школы коммуникации Soft Skills Lab
OAuth 2.0 в картинках
Иногда бывает сложно объяснить, как работает OAuth. Инфы в интернете много, но она вся мудрёная и порой противоречивая. Кажется, что некоторые авторы специально усложняют тему, чтобы выглядеть умнее.
А тема-то не такая сложная — успешный сценарий можно объяснить за один пост в телеге с одной sequence-диаграммой.
Участники:
👤 Пользователь — владеет ресурсами и авторизует ваше приложение на доступ к ним. Например, ему нужно разместить объявление, но вместо регистрации с логином и паролем он хочет «войти через Google».
💻 Ваше клиент-серверное приложение — например, доска объявлений, где вы хотите разрешить вход через Google.
🔐 OAuth провайдер — предоставляет сервер для авторизации и сервер для доступа к ресурсу. Например, Google предоставляет доступ к имени, email и ID пользователя.
🛠️ 5 шагов, чтобы реализовать «вход через Google»:
1️⃣ — Получить конфигурацию OAuth
Провайдеры предоставляют discovery-endpoint, который вернет актуальные url для OAuth протокола.
Рекомендуется запрашивать конфигурацию вместо хардкода или сохранения в конфиге.
Проверьте сами: https://accounts.google.com/.well-known/openid-configuration
2️⃣ — Отправить запрос на авторизацию
После нажатия на кнопку «Войти через Google» ваше клиентское приложение выполняет запрос в ваш бэкенд.
Ваш бэкенд перенаправляет клиента на URL, составленный с помощью authorization_endpoint из 1️⃣ и стандартных oauth-параметров:
1. response_type=(code|token) — Определяет flow: Auth Code или Implicit. Используйте code, т.к. иначе токен передается на клиент в query string, оставаясь в логах веб-серверов, и может быть украден с клиента
2. client_id — Публичный идентификатор вашего приложения, который вы получили через веб-интерфейс OAuth провайдера для разработчиков.
3. state Уникальный случайный код, который генерирует ваш бэкенд. Нужен, чтобы предотвратить CSRF атаки. В конце флоу помогает убедиться, что изначальный запрос был инициирован вашим приложением.
4. scope — Список типов ресурсов, к которым приложение запрашивает доступ. openid — для доступа к userinfo_endpoint из 1️⃣. calendar_read — чтение календаря.
3️⃣ — Пользователь взаимодействует с OAuth провайдером.
Обычно здесь пользователь вводит логин-пароль, проходит 2fa через sms, и т.д. Если пользователь уже залогинен на этом устройстве, то увидит просто кнопку "Предоставить доступ YourApp к информации о вас".
Этот процесс непрозрачен для вашего приложения, т.к. пользователь взаимодействует с OAuth провайдером через браузер без вашего участия.
4️⃣ — Получение токена
OAuth провайдер перенаправляет браузер обратно к вашему сервису, используя redirect_uri, который передал ваш бэкенд на шаге 2️⃣.
Параметры redirect_uri:
1. state — Должен соответствовать тому, который передал ваш бэкенд на шаге 2️⃣. Если не совпадает, — значит пользователь подвергся CSRF атаке.
2. code — Одноразовый код, сгенерированный oauth провайдером.
Ваш бэкенд делает запрос в OAuth Auth server для получения access_token и других.
После получения access_token ваш бэкенд использует его для запросов к ресурсам.
Auth Code flow безопаснее, чем implicit flow, потому что добавляется шаг взаимодействия вашего сервиса и OAuth провайдера для получения токена. Таким образом на клиенте не светятся никакие секреты, и вероятность их компрометации снижается.
5️⃣ — Получение ресурсов
Когда ваш сервис получает access_token, он может быть использован для вызова API сервера ресурсов сразу или в будущем.
access_token имеет ограниченный срок действия и его нужно регулярно обновлять с помощью refresh_token.
Доказательством аутентификации служит id_token. ID пользователя можно достать из поля sub (subject), раскодировав base64 JWT id_token.
Или обратиться к userinfo_uri, используя access_token.
Вот собственно и всё.
OAuth — это просто.
Распространите.
——
Специально для поста я перевел инфографику из статьи ув. тов. Phil Boutros.
На картинке к посту — превью. Сам pdf файл — чуть ниже.
Для закрепления материала можно поиграться в официальной OAuth 2.0 Playground
Иногда бывает сложно объяснить, как работает OAuth. Инфы в интернете много, но она вся мудрёная и порой противоречивая. Кажется, что некоторые авторы специально усложняют тему, чтобы выглядеть умнее.
А тема-то не такая сложная — успешный сценарий можно объяснить за один пост в телеге с одной sequence-диаграммой.
Участники:
👤 Пользователь — владеет ресурсами и авторизует ваше приложение на доступ к ним. Например, ему нужно разместить объявление, но вместо регистрации с логином и паролем он хочет «войти через Google».
💻 Ваше клиент-серверное приложение — например, доска объявлений, где вы хотите разрешить вход через Google.
🔐 OAuth провайдер — предоставляет сервер для авторизации и сервер для доступа к ресурсу. Например, Google предоставляет доступ к имени, email и ID пользователя.
🛠️ 5 шагов, чтобы реализовать «вход через Google»:
1️⃣ — Получить конфигурацию OAuth
Провайдеры предоставляют discovery-endpoint, который вернет актуальные url для OAuth протокола.
Рекомендуется запрашивать конфигурацию вместо хардкода или сохранения в конфиге.
Проверьте сами: https://accounts.google.com/.well-known/openid-configuration
2️⃣ — Отправить запрос на авторизацию
После нажатия на кнопку «Войти через Google» ваше клиентское приложение выполняет запрос в ваш бэкенд.
Ваш бэкенд перенаправляет клиента на URL, составленный с помощью authorization_endpoint из 1️⃣ и стандартных oauth-параметров:
1. response_type=(code|token) — Определяет flow: Auth Code или Implicit. Используйте code, т.к. иначе токен передается на клиент в query string, оставаясь в логах веб-серверов, и может быть украден с клиента
2. client_id — Публичный идентификатор вашего приложения, который вы получили через веб-интерфейс OAuth провайдера для разработчиков.
3. state Уникальный случайный код, который генерирует ваш бэкенд. Нужен, чтобы предотвратить CSRF атаки. В конце флоу помогает убедиться, что изначальный запрос был инициирован вашим приложением.
4. scope — Список типов ресурсов, к которым приложение запрашивает доступ. openid — для доступа к userinfo_endpoint из 1️⃣. calendar_read — чтение календаря.
3️⃣ — Пользователь взаимодействует с OAuth провайдером.
Обычно здесь пользователь вводит логин-пароль, проходит 2fa через sms, и т.д. Если пользователь уже залогинен на этом устройстве, то увидит просто кнопку "Предоставить доступ YourApp к информации о вас".
Этот процесс непрозрачен для вашего приложения, т.к. пользователь взаимодействует с OAuth провайдером через браузер без вашего участия.
4️⃣ — Получение токена
OAuth провайдер перенаправляет браузер обратно к вашему сервису, используя redirect_uri, который передал ваш бэкенд на шаге 2️⃣.
Параметры redirect_uri:
1. state — Должен соответствовать тому, который передал ваш бэкенд на шаге 2️⃣. Если не совпадает, — значит пользователь подвергся CSRF атаке.
2. code — Одноразовый код, сгенерированный oauth провайдером.
Ваш бэкенд делает запрос в OAuth Auth server для получения access_token и других.
После получения access_token ваш бэкенд использует его для запросов к ресурсам.
Auth Code flow безопаснее, чем implicit flow, потому что добавляется шаг взаимодействия вашего сервиса и OAuth провайдера для получения токена. Таким образом на клиенте не светятся никакие секреты, и вероятность их компрометации снижается.
5️⃣ — Получение ресурсов
Когда ваш сервис получает access_token, он может быть использован для вызова API сервера ресурсов сразу или в будущем.
access_token имеет ограниченный срок действия и его нужно регулярно обновлять с помощью refresh_token.
Доказательством аутентификации служит id_token. ID пользователя можно достать из поля sub (subject), раскодировав base64 JWT id_token.
Или обратиться к userinfo_uri, используя access_token.
Вот собственно и всё.
OAuth — это просто.
Распространите.
——
Специально для поста я перевел инфографику из статьи ув. тов. Phil Boutros.
На картинке к посту — превью. Сам pdf файл — чуть ниже.
Для закрепления материала можно поиграться в официальной OAuth 2.0 Playground
