StarMap — Карта компетенций команды
Когда работали в офисе, многие вопросы решались через тупо поговорить с людьми рядом. В любой момент можно было обсудить любой вопрос:
— Как понять, что в команде достаточно компетенций для решения любой задачи из бэклога?
— Если есть ощущение, что для некоторых задач из бэклога нужно наращивать компетенции, то как понять, какие?
— Если какие-то компетенции надо наращивать, то как понять, кому?
— Или как разработчику при составлении плана развития понять, что будет полезно команде?
— Как новичку разобраться, к кому идти за советом по какому-то вопросу?
На удаленке больше асинхронного взаимодействия, а визуализация вышла на первый план. StarMap — визуальный инструмент для ответа на эти вопросы. Это таблица, где строки — компетенции, а столбцы — участники. Ну или наоборот, как удобно.
Он нужен в первую очередь команде. Поэтому его составляет и актуализирует сама команда. При составлении списка компетенций команда учитывает бэклог продукта и стратегию разработки. Компетенции должны быть конкретными, но достаточно верхнеуровневыми, чтобы на их изучение до самостоятельной работы ушло несколько месяцев. Список должен быть обозримым за одну встречу, рекомендую около 50 строк.
Дальше каждый участник заполняет свою ячейку соответствующей компетенции. Он вписывает туда один из возможных вариантов степени компетентности. В самом простом варианте это может быть «—», ✔︎ и ★. Думаю, тут обозначения очевидны.
После заполнения StarMap команда может составить план по развитию, чтобы закрыть критичные компетенции.
Мы решили учесть обучение компетенции в своем наборе отметок:
«➖» — отсутствие компетенции и нежелание развиваться в этой области
«➕» — наличие знаний и умений, достаточных для самостоятельной работы в данной области
«❗️» — Эксперт, высокий уровень знаний и умений, способность решать сложные задачи, готов обучать других (если не готов, то «+» )
«❓» — отсутствие или низкий уровень компетенции, но готов изучать
После заполнения StarMap показывает, где в команде есть бас-фактор, нехватка компетенций или обучающих. Например, что в команде низкий уровень компетенции QA по составлению сценариев тестирования, и некому обучать. А еще Вася — единственный, кто может исследовать проблему на проде. Скорее всего, Васю будут дёргать из отпуска, если прод упадёт.
На составление StarMap ушло около 3-4 часов, но оно того стоило. Процесс развития команды стал более прозрачным, и мы точно знаем что это развитие полезно для продукта и интересно участникам. Сейчас на поддержку мы тратим час в месяц.
В следующем посте расскажу о том, как можно организовать встречу для составления StarMap и подробнее о критериях для списка компетенций.
Когда работали в офисе, многие вопросы решались через тупо поговорить с людьми рядом. В любой момент можно было обсудить любой вопрос:
— Как понять, что в команде достаточно компетенций для решения любой задачи из бэклога?
— Если есть ощущение, что для некоторых задач из бэклога нужно наращивать компетенции, то как понять, какие?
— Если какие-то компетенции надо наращивать, то как понять, кому?
— Или как разработчику при составлении плана развития понять, что будет полезно команде?
— Как новичку разобраться, к кому идти за советом по какому-то вопросу?
На удаленке больше асинхронного взаимодействия, а визуализация вышла на первый план. StarMap — визуальный инструмент для ответа на эти вопросы. Это таблица, где строки — компетенции, а столбцы — участники. Ну или наоборот, как удобно.
Он нужен в первую очередь команде. Поэтому его составляет и актуализирует сама команда. При составлении списка компетенций команда учитывает бэклог продукта и стратегию разработки. Компетенции должны быть конкретными, но достаточно верхнеуровневыми, чтобы на их изучение до самостоятельной работы ушло несколько месяцев. Список должен быть обозримым за одну встречу, рекомендую около 50 строк.
Дальше каждый участник заполняет свою ячейку соответствующей компетенции. Он вписывает туда один из возможных вариантов степени компетентности. В самом простом варианте это может быть «—», ✔︎ и ★. Думаю, тут обозначения очевидны.
После заполнения StarMap команда может составить план по развитию, чтобы закрыть критичные компетенции.
Мы решили учесть обучение компетенции в своем наборе отметок:
«➖» — отсутствие компетенции и нежелание развиваться в этой области
«➕» — наличие знаний и умений, достаточных для самостоятельной работы в данной области
«❗️» — Эксперт, высокий уровень знаний и умений, способность решать сложные задачи, готов обучать других (если не готов, то «+» )
«❓» — отсутствие или низкий уровень компетенции, но готов изучать
После заполнения StarMap показывает, где в команде есть бас-фактор, нехватка компетенций или обучающих. Например, что в команде низкий уровень компетенции QA по составлению сценариев тестирования, и некому обучать. А еще Вася — единственный, кто может исследовать проблему на проде. Скорее всего, Васю будут дёргать из отпуска, если прод упадёт.
На составление StarMap ушло около 3-4 часов, но оно того стоило. Процесс развития команды стал более прозрачным, и мы точно знаем что это развитие полезно для продукта и интересно участникам. Сейчас на поддержку мы тратим час в месяц.
В следующем посте расскажу о том, как можно организовать встречу для составления StarMap и подробнее о критериях для списка компетенций.
❤5🔥2👍1
Как мы составляли список компетенций StarMap (а еще DoR, DoD и еще несколько списков)
Для начала отвечу на разумный вопрос: в чем сложность составить список? Взял и составил, и не нужен целый пост.
Не всё так просто. Давайте возьмем команду из 9 человек и скажем «сделайте себе список». В лучшем случае, два самых активных набросают что-то по своему усмотрению. Скорее всего, такой артефакт отомрёт очень скоро. Во-первых, эти двое могут что-то упустить. Во-вторых, всем остальным будет скучно, они будут чувствовать себя ненужными на этой встрече, и им будет пофиг на этот список.
Чтобы команда использовала инструмент, каждый должен в него вложиться. Тогда это будет его артефакт, он будет чувствовать вовлеченность и принадлежность.
Для первичного составления StarMap мы использовали 1-2-4-All
1️⃣ — 10 минут — Сначала каждый участник индивидуально составляет список
Он может исходить из собственных компетенций и наблюдаемых проявлений сокомандников.
2️⃣ — 10 минут — Затем случайным образом объединяются в пары и объединяют свои списки в один
Элементы можно доуточнять, переформулировать, находить похожие, объединять в группы. На этом этапе список может вырасти в два раза.
3️⃣ — 20 минут — Пары объединяются в четверки и объединяют два списка в один
Пары внутри уже договорились, поэтому группе из четырех будет несложно повторить слияние. Точно легче, чем если сразу начать составлять список четверым.
4️⃣ — 10 минут — Перерыв
Каждый 40 минут выкладывался по полной и все устали. А впереди самое мясо =) Стоит буквально вырубить камеры, микрофоны и отойти от компухтера на 10 минут. Не просто так академический час длится 45 минут.
5️⃣ — 40 минут — Вся команда в сборе объединяет два списка
Как в случае с четверками, договариваются не 8 человек, а две мини-группы, которые внутри уже пришли к согласию. Цель — составить первую версию списка и потом итеративно его дополнять.
В конце остается минут 10, чтобы индивидуально каждый сам за себя заполнил матрицу.
Если повезет, то еще минут 10 пробежаться по матрице в поисках проблемных компетенций, где нет экспертов или низкий бас-фактор.
По нашему опыту, сложнее всего было оформить финальный список большой группой. Нам даже пришлось сделать дополнительную встречу для этого. Сейчас, оборачиваясь назад, я понимаю, что лучше итерационный подход.
Если по какому-то элементу идут жаркие споры и не получается придти к согласию, лучше не тратить на него время и отложить. Если он реально нужен для текущих задач из бэклога и по этой компетенции есть просадка, — всплывёт в ближайшее время на ретроспективе. И на ретроспективе можно либо дополнить список, либо запланировать провести внеочередной StarMap Sync.
P.S. По статистике телеги пост про StarMap стал самым полезным (по репостам) в канале. Это мотивирует меня писать еще об инструментах и практиках 🙂 Напишите в комментах, если я не раскрыл какой-то интересующий аспект StarMap, или в целом что было бы интересно почитать.
Для начала отвечу на разумный вопрос: в чем сложность составить список? Взял и составил, и не нужен целый пост.
Не всё так просто. Давайте возьмем команду из 9 человек и скажем «сделайте себе список». В лучшем случае, два самых активных набросают что-то по своему усмотрению. Скорее всего, такой артефакт отомрёт очень скоро. Во-первых, эти двое могут что-то упустить. Во-вторых, всем остальным будет скучно, они будут чувствовать себя ненужными на этой встрече, и им будет пофиг на этот список.
Чтобы команда использовала инструмент, каждый должен в него вложиться. Тогда это будет его артефакт, он будет чувствовать вовлеченность и принадлежность.
Для первичного составления StarMap мы использовали 1-2-4-All
1️⃣ — 10 минут — Сначала каждый участник индивидуально составляет список
Он может исходить из собственных компетенций и наблюдаемых проявлений сокомандников.
2️⃣ — 10 минут — Затем случайным образом объединяются в пары и объединяют свои списки в один
Элементы можно доуточнять, переформулировать, находить похожие, объединять в группы. На этом этапе список может вырасти в два раза.
3️⃣ — 20 минут — Пары объединяются в четверки и объединяют два списка в один
Пары внутри уже договорились, поэтому группе из четырех будет несложно повторить слияние. Точно легче, чем если сразу начать составлять список четверым.
4️⃣ — 10 минут — Перерыв
Каждый 40 минут выкладывался по полной и все устали. А впереди самое мясо =) Стоит буквально вырубить камеры, микрофоны и отойти от компухтера на 10 минут. Не просто так академический час длится 45 минут.
5️⃣ — 40 минут — Вся команда в сборе объединяет два списка
Как в случае с четверками, договариваются не 8 человек, а две мини-группы, которые внутри уже пришли к согласию. Цель — составить первую версию списка и потом итеративно его дополнять.
В конце остается минут 10, чтобы индивидуально каждый сам за себя заполнил матрицу.
Если повезет, то еще минут 10 пробежаться по матрице в поисках проблемных компетенций, где нет экспертов или низкий бас-фактор.
По нашему опыту, сложнее всего было оформить финальный список большой группой. Нам даже пришлось сделать дополнительную встречу для этого. Сейчас, оборачиваясь назад, я понимаю, что лучше итерационный подход.
Если по какому-то элементу идут жаркие споры и не получается придти к согласию, лучше не тратить на него время и отложить. Если он реально нужен для текущих задач из бэклога и по этой компетенции есть просадка, — всплывёт в ближайшее время на ретроспективе. И на ретроспективе можно либо дополнить список, либо запланировать провести внеочередной StarMap Sync.
P.S. По статистике телеги пост про StarMap стал самым полезным (по репостам) в канале. Это мотивирует меня писать еще об инструментах и практиках 🙂 Напишите в комментах, если я не раскрыл какой-то интересующий аспект StarMap, или в целом что было бы интересно почитать.
🔥3
Lagom T-Shape
На днях говорил с коллегой, он поделился своим затруднением:
«Вот я изучаю какую-то технологию, но мне всё кажется что недостаточно глубоко, и не могу остановиться. А еще репетитор по джаве говорил мне, что Т-Shape — фигня, а фуллстек разрабы — шарлатаны, и надо глубоко копать в джаву, чтобы быть крутым»
После этого разговора я решился написать этот пост, хотя раньше думал, что тема уже себя изжила.
Есть 2 крайности:
1) Узкопрофильный специалист
2) Универсал поверхностных знаний
Почему-то принято надсмехаться над вторым. Типа, такой персонаж нихрена толком не может сделать. То ли дело крутой джава-программист, у которого имя любого класса состоит минимум из 10 слов. Вот профессионал!
Никто не задумывается о том, что такому профессионалу нужна весьма специфичная среда. Представим его как черный ящик.
На вход ему нужен стабильный поток технически грамотно поставленных задач, которые нужно:
— придумать
— собрать требования
— декомпозировать, описать технически
На выходе из этого черного ящика будет код. Нужно:
— проверить, что этот код решает именно ту проблему, которую надо
— проверить соблюдение всех требований
— проверить внешнее качество
— доставить код до пользователя
— обеспечить долгосрочную работоспособность фичи в продакшене
— собрать обратную связь о фиче
Смотрите, этот узкоспециализированный крутой профессионал не видит источник задачи и не видит пользу для бизнеса от своей работы. Из-за этого он склонен к оверинжинирингу. Для того, чтобы его работа принесла пользу, нужен еще «обслуживающий персонал». Почему тогда никто не надсмехается над такими профессионалами?
В общем, мне кажется что прямой пользы для бизнеса нет ни от узкопрофильного специалиста, ни от поверхностного универсала.
Истина где-то посередине. Человек не может быть супер-крутым профессионалом во всех сферах. И охватить вообще все сферы тоже не может.
Как понять, насколько широко и до какой глубины прокачиваться? У шведов есть понятие Lagom. Целесообразная достаточность. Это вообще очень важный для них основополагающий жизненный принцип. Весьма обеспеченные люди живут достаточно просто. Достаточно для получения удовольствия от жизни. Предлагаю отталкиваться от этого понятия. Универсального рецепта нет, это внутреннее чувство, которое нужно нарабатывать на практике.
Куда развиваться вширь:
Когда разработчик делает задачу, он может сам прикинуть, в чем он мог бы быть полезен. Там где «мог бы» != «может», как раз вектор для прокачки. StarMap в помощь 🙂 Таких векторов множество, и можно выбрать тот, что больше по душе. Главное, не хвататься сразу за всё, а качать что-то конкретное. Со временем доберешься и до остального.
До какой глубины копать:
Lagom.
До достаточной, но не избыточной =) Сорян, нет универсального ответа. Должно быть понимание особенностей используемой технологии. Но не обязательно знать всю подкапотку. Мы не можем вместить все знания всего что мы используем. Подумайте: вы пользуетесь смартфоном, знаете как это делать удобно и эффективно. Для этого не нужно знать всё железо и весь софт. Максимум — вы знаете характеристики, типа объем оперативки. И знаете, на что эта характеристика влияет. Так вы можете выбрать инструмент.
Этот пост зрел у меня давно. И тут на днях Александр Кузовлев предложил написать совместный пост на эту тему. Он ведет канал о продуктовой разработке с точки зрения PM, при этом говорит о своем видении техдолга и других важных для разработчиков вещах. Его версия поста «T-Shape для продуктовых команд»: https://www.tg-me.com/aheadofthepack/72 Как всегда, я его еще не видел. Пойду читать)
На днях говорил с коллегой, он поделился своим затруднением:
«Вот я изучаю какую-то технологию, но мне всё кажется что недостаточно глубоко, и не могу остановиться. А еще репетитор по джаве говорил мне, что Т-Shape — фигня, а фуллстек разрабы — шарлатаны, и надо глубоко копать в джаву, чтобы быть крутым»
После этого разговора я решился написать этот пост, хотя раньше думал, что тема уже себя изжила.
Есть 2 крайности:
1) Узкопрофильный специалист
2) Универсал поверхностных знаний
Почему-то принято надсмехаться над вторым. Типа, такой персонаж нихрена толком не может сделать. То ли дело крутой джава-программист, у которого имя любого класса состоит минимум из 10 слов. Вот профессионал!
Никто не задумывается о том, что такому профессионалу нужна весьма специфичная среда. Представим его как черный ящик.
На вход ему нужен стабильный поток технически грамотно поставленных задач, которые нужно:
— придумать
— собрать требования
— декомпозировать, описать технически
На выходе из этого черного ящика будет код. Нужно:
— проверить, что этот код решает именно ту проблему, которую надо
— проверить соблюдение всех требований
— проверить внешнее качество
— доставить код до пользователя
— обеспечить долгосрочную работоспособность фичи в продакшене
— собрать обратную связь о фиче
Смотрите, этот узкоспециализированный крутой профессионал не видит источник задачи и не видит пользу для бизнеса от своей работы. Из-за этого он склонен к оверинжинирингу. Для того, чтобы его работа принесла пользу, нужен еще «обслуживающий персонал». Почему тогда никто не надсмехается над такими профессионалами?
В общем, мне кажется что прямой пользы для бизнеса нет ни от узкопрофильного специалиста, ни от поверхностного универсала.
Истина где-то посередине. Человек не может быть супер-крутым профессионалом во всех сферах. И охватить вообще все сферы тоже не может.
Как понять, насколько широко и до какой глубины прокачиваться? У шведов есть понятие Lagom. Целесообразная достаточность. Это вообще очень важный для них основополагающий жизненный принцип. Весьма обеспеченные люди живут достаточно просто. Достаточно для получения удовольствия от жизни. Предлагаю отталкиваться от этого понятия. Универсального рецепта нет, это внутреннее чувство, которое нужно нарабатывать на практике.
Куда развиваться вширь:
Когда разработчик делает задачу, он может сам прикинуть, в чем он мог бы быть полезен. Там где «мог бы» != «может», как раз вектор для прокачки. StarMap в помощь 🙂 Таких векторов множество, и можно выбрать тот, что больше по душе. Главное, не хвататься сразу за всё, а качать что-то конкретное. Со временем доберешься и до остального.
До какой глубины копать:
Lagom.
До достаточной, но не избыточной =) Сорян, нет универсального ответа. Должно быть понимание особенностей используемой технологии. Но не обязательно знать всю подкапотку. Мы не можем вместить все знания всего что мы используем. Подумайте: вы пользуетесь смартфоном, знаете как это делать удобно и эффективно. Для этого не нужно знать всё железо и весь софт. Максимум — вы знаете характеристики, типа объем оперативки. И знаете, на что эта характеристика влияет. Так вы можете выбрать инструмент.
Этот пост зрел у меня давно. И тут на днях Александр Кузовлев предложил написать совместный пост на эту тему. Он ведет канал о продуктовой разработке с точки зрения PM, при этом говорит о своем видении техдолга и других важных для разработчиков вещах. Его версия поста «T-Shape для продуктовых команд»: https://www.tg-me.com/aheadofthepack/72 Как всегда, я его еще не видел. Пойду читать)
❤1
Пост — рубеж
Обычно я пишу познавательные лонгриды. Формат не совсем стандартный для телеги, но заходит, судя по репостам.
Этот пост — короткий и личный. Понимаю что рискую, отходя от формата. Но очень хочу поделиться.
Сегодня мой последний день в QIWI. 13 июля исполнилось 5 лет, как я пришел в компанию.
Оба моих деда работали 60+ лет на одном предприятии, а для нашего поколения 5 лет это серьезно.
Что я приобрел за эти 5 лет:
— Познакомился с тысячей отличных людей, и частичка каждого теперь есть во мне. Благодарю вас за опыт, уроки и возможность работать рядом.
— Запрогал пару мелких проектов в одиночку в начале пути. Часть из них все еще живы и приносят пользу.
— Узнал тысячу всяких штук в разработке. Вылез из стартаперского мира Node.js +PgSQL в энтерпрайзный JVM + OracleDb.
— Привнес инженерные практики в разработку БД, проводил воркшопы и вебинары.
— Был ментором 10 классных ребят в разное время. Очень рад, что был рядом в начале пути, и вижу как много они добились и еще добьются. Они наступают на пятки и мотивируют меня развиваться 🙂
— Сделал вместе с командой штук 10 крупных продуктов или крупных фич. Эти фичи точно окупили для продукта меня и команду.
— Начал писать статьи, выступать на конфах. Стартовал этот канал.
Недавно я писал про продуктовый подход к найму. Когда я выходил посмотреть, как собеседуют другие, я не собирался увольняться.
А потом появилась она. Возможность сделать большой шаг вперед, оставаясь при этом продуктовым разработчиком. Возможность хорошенько перетряхнуть привычный ритм. Эту возможность я не могу упустить.
С сегодняшнего дня и до понедельника Добби — свободный эльф 🙂
А в понедельник начинается новая жизнь.
Верю, что она принесет много новых тем для постов.
Вот первая тема: в следующем посте расскажу, где теперь и что буду дальше делать.
Stay Tuned.
Обычно я пишу познавательные лонгриды. Формат не совсем стандартный для телеги, но заходит, судя по репостам.
Этот пост — короткий и личный. Понимаю что рискую, отходя от формата. Но очень хочу поделиться.
Сегодня мой последний день в QIWI. 13 июля исполнилось 5 лет, как я пришел в компанию.
Оба моих деда работали 60+ лет на одном предприятии, а для нашего поколения 5 лет это серьезно.
Что я приобрел за эти 5 лет:
— Познакомился с тысячей отличных людей, и частичка каждого теперь есть во мне. Благодарю вас за опыт, уроки и возможность работать рядом.
— Запрогал пару мелких проектов в одиночку в начале пути. Часть из них все еще живы и приносят пользу.
— Узнал тысячу всяких штук в разработке. Вылез из стартаперского мира Node.js +PgSQL в энтерпрайзный JVM + OracleDb.
— Привнес инженерные практики в разработку БД, проводил воркшопы и вебинары.
— Был ментором 10 классных ребят в разное время. Очень рад, что был рядом в начале пути, и вижу как много они добились и еще добьются. Они наступают на пятки и мотивируют меня развиваться 🙂
— Сделал вместе с командой штук 10 крупных продуктов или крупных фич. Эти фичи точно окупили для продукта меня и команду.
— Начал писать статьи, выступать на конфах. Стартовал этот канал.
Недавно я писал про продуктовый подход к найму. Когда я выходил посмотреть, как собеседуют другие, я не собирался увольняться.
А потом появилась она. Возможность сделать большой шаг вперед, оставаясь при этом продуктовым разработчиком. Возможность хорошенько перетряхнуть привычный ритм. Эту возможность я не могу упустить.
С сегодняшнего дня и до понедельника Добби — свободный эльф 🙂
А в понедельник начинается новая жизнь.
Верю, что она принесет много новых тем для постов.
Вот первая тема: в следующем посте расскажу, где теперь и что буду дальше делать.
Stay Tuned.
Тут Вообще всё по-другому
Когда вы в последний раз выходили на новую работу? Помните это ощущение: вокруг все такие умные, разговаривают на каком-то своем эльфийском языке и щелкают задачки как будто всю жизнь здесь.
Вообще у меня в жизни это тоже было. Сейчас воспоминания поугасли, но образы иногда всплывают в пямяти. Тогда я был программистом. Онбординг был попроще. Выдали ноут, посадили кодить. Страшные слова объясняли по мере поступления. В итоге через какое-то время въехал.
Теперь я техлид. По трудовой — мемеджер. Никто не собирается сюсюкаться и подавать знания на ложечке. Надо выкручивать проактивность на максимум, охватить максимально ширину продукта и процессов. И строить план погружения в глубину.
Видели когда-нибудь техлида, который нихрена не понимает, что происходит на дэйли? Это я. И это нормально, по мнению команды. Шокирующий контент. На самом деле, если бы не трансляция "это нормально" со всех сторон, меня бы сожрал синдром самозванца.
Обратная связь от новых коллег очень помогает даже в самом начале пути. Цените обратную связь, спрашивайте обратную связь, давайте обратную связь :)
Что дальше?
Буду погружаться в новый продукт и процессы.
Буду продолжать находить в повседневной работе интересные и полезные темы.
Буду продолжать вести канал, делясь этими темами с вами.
Буду вписываться в движухи Райфа.
Буду продолжать совместные движухи с ребятами из QIWI. Например, сегодня опубликовали пост на хабре по мотивам выступления на QSP 6.0:
https://habr.com/ru/company/qiwi/blog/569136/
Когда вы в последний раз выходили на новую работу? Помните это ощущение: вокруг все такие умные, разговаривают на каком-то своем эльфийском языке и щелкают задачки как будто всю жизнь здесь.
Вообще у меня в жизни это тоже было. Сейчас воспоминания поугасли, но образы иногда всплывают в пямяти. Тогда я был программистом. Онбординг был попроще. Выдали ноут, посадили кодить. Страшные слова объясняли по мере поступления. В итоге через какое-то время въехал.
Теперь я техлид. По трудовой — мемеджер. Никто не собирается сюсюкаться и подавать знания на ложечке. Надо выкручивать проактивность на максимум, охватить максимально ширину продукта и процессов. И строить план погружения в глубину.
Видели когда-нибудь техлида, который нихрена не понимает, что происходит на дэйли? Это я. И это нормально, по мнению команды. Шокирующий контент. На самом деле, если бы не трансляция "это нормально" со всех сторон, меня бы сожрал синдром самозванца.
Обратная связь от новых коллег очень помогает даже в самом начале пути. Цените обратную связь, спрашивайте обратную связь, давайте обратную связь :)
Что дальше?
Буду погружаться в новый продукт и процессы.
Буду продолжать находить в повседневной работе интересные и полезные темы.
Буду продолжать вести канал, делясь этими темами с вами.
Буду вписываться в движухи Райфа.
Буду продолжать совместные движухи с ребятами из QIWI. Например, сегодня опубликовали пост на хабре по мотивам выступления на QSP 6.0:
https://habr.com/ru/company/qiwi/blog/569136/
Признаний пост
Настоящая продуктовая разработка — как стратегия в перспективе нескольких лет. Это вектор для развития. Текущий процесс может быть далеко не идеальным. И если текущий процесс приносит бизнесу ценность, нам не стоит его ломать и строить с нуля. Сломать будет легко, но не факт что получится построить.
Мы в силах менять процесс постепенно. Делать шаги в сторону стратегического идеала. И мы всю жизнь будем находиться в этом состоянии движения от проблемного прошлого к светлому будущему через "промежуточное" настоящее. Надо видеть в этом настоящем хорошее, радоваться позитивным изменениям и принимать недостижимость идеала.
Из коммента к статье на хабре:
Как донести эту мысль до остальных членов команды? Последнее время много об этом думаю и делаю какие-то шаги в этом направлении, но, кажется, натыкаюсь на стену непонимания.
Изменить внутреннее восприятие в человеке очень трудно, и для этого он должен сам захотеть. Для этого ему нужна подходящая среда, инфополе. Трансляция ценностей со всех сторон: сверху, сбоку, от коллег. Этот канал — один из источников, формирующих инфополе, способствующее изменениям процессов изнутри. Я говорю о том, через что мы с командой прошли сами. О том, в чем увидел пользу и позитивные изменения. Но я никогда не был в идеальной в вакууме продуктовой разработке. Это всегда был путь к светлому будущему. И мне с этим ок 😉
- У вас настоящая продуктовая разроботка?
- Нет, только в канале рассказываю
- Кросивое...
Простите, раз уж я теперь мемеджер, позволил себе поучаствовать в трендах 😃Настоящая продуктовая разработка — как стратегия в перспективе нескольких лет. Это вектор для развития. Текущий процесс может быть далеко не идеальным. И если текущий процесс приносит бизнесу ценность, нам не стоит его ломать и строить с нуля. Сломать будет легко, но не факт что получится построить.
Мы в силах менять процесс постепенно. Делать шаги в сторону стратегического идеала. И мы всю жизнь будем находиться в этом состоянии движения от проблемного прошлого к светлому будущему через "промежуточное" настоящее. Надо видеть в этом настоящем хорошее, радоваться позитивным изменениям и принимать недостижимость идеала.
Из коммента к статье на хабре:
Как донести эту мысль до остальных членов команды? Последнее время много об этом думаю и делаю какие-то шаги в этом направлении, но, кажется, натыкаюсь на стену непонимания.
Изменить внутреннее восприятие в человеке очень трудно, и для этого он должен сам захотеть. Для этого ему нужна подходящая среда, инфополе. Трансляция ценностей со всех сторон: сверху, сбоку, от коллег. Этот канал — один из источников, формирующих инфополе, способствующее изменениям процессов изнутри. Я говорю о том, через что мы с командой прошли сами. О том, в чем увидел пользу и позитивные изменения. Но я никогда не был в идеальной в вакууме продуктовой разработке. Это всегда был путь к светлому будущему. И мне с этим ок 😉
Выключил уведомления и жизнь наладилась
Прошло 2 недели на новом месте. Входящие сообщения бесконечным потоком в почте и нескольких мессенджерах. Количество коммуникаций на пределе моих возможностей. Встречи одна за одной, так что приходится бронировать в календаре время на обед и на оффлайновые активности типа чтения документации.
В первые несколько дней понял: если буду действовать реактивно, каждый раз переключаясь на очередное входящее сообщение, то не вывезу. Не смогу построить план и следовать ему. Если мгновенно переключаться, то это не я формирую план погружения в продукт, а он меня засасывает. А я хочу действовать осознанно и непредвзято.
Еще несколько лет назад, после прочтения Джедайских Техник Дорофеева, я захотел попробовать отключить уведомления. И вот пришел тот самый момент.
Отключил все уведомления на телефоне и рабочем ноуте и сейчас понимаю, что это реально помогает. Дает возможность заниматься тем, чем планировал. Мой внутренний невротик заставляет меня проверять почту и мессенджеры примерно раз в час. При этом входящие меня дожидаются. Ничего не ломается за тот час, пока я не отвечаю на сообщение. Хотя бывает, что за час уже и вопрос становится неактуальным: сами разобрались. Тем лучше 🙂
Поменялось и мое отношение к коммуникации с коллегами: не отвечаю мгновенно сам и не требую этого от других. Понимаю, что в моменте человек скорее всего занят чем-то важным. А еще формулирую запрос максимально четко, чтобы не нужны были уточнения, когда коллега дойдет до ответа на мой вопрос.
Режим, когда мы сразу получаем ответ на запрос, можно назвать синхронным. В офисе мы дёргали друг друга вживую и получали мгновенную реакцию. При кажущихся плюсах такого подхода, это все равно вырывает человека из контекста, и это было проблемой даже в офисе. Но в офисе у нас хотя бы была возможность понять, насколько человек занят, прежде чем мы его отвлечем.
На удаленке модель взаимодействия меняется. Те добрые люди, которые раньше оценивали степень занятости и не дергали лишний раз, сейчас просто пишут сообщения. Каждое уведомление нас отвлекает. И после этого вернуться в контекст очень сложно. Отключение уведомлений — одно из действий, помогающих поддерживать концентрацию в работе.
Если мы сами просматриваем входящие сообщения, когда нам это удобно, то такой режим можно назвать асинхронным. Закинул запрос — получил ответ, когда отвечающему удобно. Но это требует внутренней самоорганизации и умения строить планы дальше чем на 5 минут вперед.
Идеи, как на удаленке управлять хаосом, я черпаю у Дорофеева. Если вы знакомы с его творчеством (Поднимите руку 🙋🏽♀️🙋🏽♂️) и тоже подумывали отключить уведомления, то вот вам знак. Попробуйте 😉. Устройте небольшой эксперимент, хотя бы на день-два. Побудьте исследователями. Если хотите поделиться результатами, welcome в комменты. Мне интересно почитать и буду рад поотвечать.
Если вы не знаете, кто такой Дорофеев, то советую начать знакомство с 10 минут его выступления на JPoint. Ссылка на конкретный момент выступления, который может вас зацепить: https://youtu.be/DukfcM24tgk?t=1226
Прошло 2 недели на новом месте. Входящие сообщения бесконечным потоком в почте и нескольких мессенджерах. Количество коммуникаций на пределе моих возможностей. Встречи одна за одной, так что приходится бронировать в календаре время на обед и на оффлайновые активности типа чтения документации.
В первые несколько дней понял: если буду действовать реактивно, каждый раз переключаясь на очередное входящее сообщение, то не вывезу. Не смогу построить план и следовать ему. Если мгновенно переключаться, то это не я формирую план погружения в продукт, а он меня засасывает. А я хочу действовать осознанно и непредвзято.
Еще несколько лет назад, после прочтения Джедайских Техник Дорофеева, я захотел попробовать отключить уведомления. И вот пришел тот самый момент.
Отключил все уведомления на телефоне и рабочем ноуте и сейчас понимаю, что это реально помогает. Дает возможность заниматься тем, чем планировал. Мой внутренний невротик заставляет меня проверять почту и мессенджеры примерно раз в час. При этом входящие меня дожидаются. Ничего не ломается за тот час, пока я не отвечаю на сообщение. Хотя бывает, что за час уже и вопрос становится неактуальным: сами разобрались. Тем лучше 🙂
Поменялось и мое отношение к коммуникации с коллегами: не отвечаю мгновенно сам и не требую этого от других. Понимаю, что в моменте человек скорее всего занят чем-то важным. А еще формулирую запрос максимально четко, чтобы не нужны были уточнения, когда коллега дойдет до ответа на мой вопрос.
Режим, когда мы сразу получаем ответ на запрос, можно назвать синхронным. В офисе мы дёргали друг друга вживую и получали мгновенную реакцию. При кажущихся плюсах такого подхода, это все равно вырывает человека из контекста, и это было проблемой даже в офисе. Но в офисе у нас хотя бы была возможность понять, насколько человек занят, прежде чем мы его отвлечем.
На удаленке модель взаимодействия меняется. Те добрые люди, которые раньше оценивали степень занятости и не дергали лишний раз, сейчас просто пишут сообщения. Каждое уведомление нас отвлекает. И после этого вернуться в контекст очень сложно. Отключение уведомлений — одно из действий, помогающих поддерживать концентрацию в работе.
Если мы сами просматриваем входящие сообщения, когда нам это удобно, то такой режим можно назвать асинхронным. Закинул запрос — получил ответ, когда отвечающему удобно. Но это требует внутренней самоорганизации и умения строить планы дальше чем на 5 минут вперед.
Идеи, как на удаленке управлять хаосом, я черпаю у Дорофеева. Если вы знакомы с его творчеством (Поднимите руку 🙋🏽♀️🙋🏽♂️) и тоже подумывали отключить уведомления, то вот вам знак. Попробуйте 😉. Устройте небольшой эксперимент, хотя бы на день-два. Побудьте исследователями. Если хотите поделиться результатами, welcome в комменты. Мне интересно почитать и буду рад поотвечать.
Если вы не знаете, кто такой Дорофеев, то советую начать знакомство с 10 минут его выступления на JPoint. Ссылка на конкретный момент выступления, который может вас зацепить: https://youtu.be/DukfcM24tgk?t=1226
YouTube
Максим Дорофеев — Воспитай свою обезьяну
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Максим Дорофеев, mnogosdelal.ru — Воспитай свою обезьяну
Международная Java-конференция JPoint 2016
Москва, 22-23 апреля 2016
Рассказ…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Максим Дорофеев, mnogosdelal.ru — Воспитай свою обезьяну
Международная Java-конференция JPoint 2016
Москва, 22-23 апреля 2016
Рассказ…
Мы попали в шторминг
Каждая команда через какое-то время после формирования начинает штормить. Это нормально, и в этом никто не виноват. Просто человеки так работают.
Когда команда только собирается, участники выстраивают социальные связи. Все друг к другу присматриваются и хотят понравиться, стараются быть профессионалами и работать работу. Команда при этом еще не очень слаженная, продуктивность такой команды на этапе формирования средняя. Обратную связь толком никто никому не дает, ”чтобы не обидеть”.
Со временем между участниками накапливается недопонимание, недоговоренности и мелкие обидки. Из-за отсутствия обратной связи, мозг каждого начинает додумывать. А додумывание ни к чему хорошему не приводит. В какой-то момент вы можете заметить обострившиеся конфликты и недовольство. Еще очень яркий индикатор — вместо "мы" в команде звучит "я" vs "они". Если заметили — поздравляю, вы попали в шторминг. Мы с командой сейчас как раз тут.
Из шторминга есть 2 выхода:
Первый — просто остановить конфликты. Изолировать участников, переформировать команду, отделить кого-то куда-то. Этот путь самый простой и напрашивающийся самим участникам конфликта. Но этот путь приведет всех в этап формирования. А следом за ним опять будет шторминг. Попадая в бесконечный цикл форминг->шторминг, человек теряет веру в командную работу. Когда-то мне помогли не попасть в этот цикл. Поэтому я верю в командную работу и пишу этот пост.
Второй выход — разрешить конфликты и пройти через шторминг. Для этого нужно в первую очередь опрозрачить, что происходит шторминг. Что это нормальный человеческий процесс, никто не виноват, и что мы не токсичная команда. Что все люди разные, но каждый полезен. Что нужно учиться слушать и слышать друг друга. Учиться понимать мотивацию каждого. Учиться объяснять свою мотивацию. На этапе шторминга очень важно общаться ненасильственно.
Те счастливчики, которые прошли через шторминг, попадают в норминг. Это как штиль после бури. Появляется внутреннее спокойствие. Но чтобы плыть быстро, нужен ветер. На этапе норминга не хватает драйва, потому что всё еще есть опасение давать обратную связь.
Постепенно это опасение сходит на нет, а команда становится слаженной и делает восхитительные вещи. Я был частью такой команды, знаю как это круто, и это знание мотивирует меня помочь команде пройти через шторминг.
Если вы тоже повидали шторминг, прошли через него, и вынесли что-то для себя — помогите пройти через это другим. Поделитесь в комментах. Возможно, ваш совет поможет нам :)
Каждая команда через какое-то время после формирования начинает штормить. Это нормально, и в этом никто не виноват. Просто человеки так работают.
Когда команда только собирается, участники выстраивают социальные связи. Все друг к другу присматриваются и хотят понравиться, стараются быть профессионалами и работать работу. Команда при этом еще не очень слаженная, продуктивность такой команды на этапе формирования средняя. Обратную связь толком никто никому не дает, ”чтобы не обидеть”.
Со временем между участниками накапливается недопонимание, недоговоренности и мелкие обидки. Из-за отсутствия обратной связи, мозг каждого начинает додумывать. А додумывание ни к чему хорошему не приводит. В какой-то момент вы можете заметить обострившиеся конфликты и недовольство. Еще очень яркий индикатор — вместо "мы" в команде звучит "я" vs "они". Если заметили — поздравляю, вы попали в шторминг. Мы с командой сейчас как раз тут.
Из шторминга есть 2 выхода:
Первый — просто остановить конфликты. Изолировать участников, переформировать команду, отделить кого-то куда-то. Этот путь самый простой и напрашивающийся самим участникам конфликта. Но этот путь приведет всех в этап формирования. А следом за ним опять будет шторминг. Попадая в бесконечный цикл форминг->шторминг, человек теряет веру в командную работу. Когда-то мне помогли не попасть в этот цикл. Поэтому я верю в командную работу и пишу этот пост.
Второй выход — разрешить конфликты и пройти через шторминг. Для этого нужно в первую очередь опрозрачить, что происходит шторминг. Что это нормальный человеческий процесс, никто не виноват, и что мы не токсичная команда. Что все люди разные, но каждый полезен. Что нужно учиться слушать и слышать друг друга. Учиться понимать мотивацию каждого. Учиться объяснять свою мотивацию. На этапе шторминга очень важно общаться ненасильственно.
Те счастливчики, которые прошли через шторминг, попадают в норминг. Это как штиль после бури. Появляется внутреннее спокойствие. Но чтобы плыть быстро, нужен ветер. На этапе норминга не хватает драйва, потому что всё еще есть опасение давать обратную связь.
Постепенно это опасение сходит на нет, а команда становится слаженной и делает восхитительные вещи. Я был частью такой команды, знаю как это круто, и это знание мотивирует меня помочь команде пройти через шторминг.
Если вы тоже повидали шторминг, прошли через него, и вынесли что-то для себя — помогите пройти через это другим. Поделитесь в комментах. Возможно, ваш совет поможет нам :)
Medium
Forming, Storming, Norming, and Performing
Much like individuals grow and develop over time, so does a team. In a 1965 article in the Psychological Bulletin, Bruce Tuckman introduced a team and group development model that maps a team’s…
Чем команда отличается от рабочей группы
Не всякая команда — на самом деле команда. Вот есть абстрактная группа людей, которые друг друга знают, работают с одним стеком, на одном продукте. Иногда советуются, как лучше сделать. Иногда сталкиваются с общими проблемами.
Чем не команда? Да тем, что у каждого сугубо индивидуальные задачи. И в спринте они почти не пересекаются. Иногда столько мелких параллельных задачек, что глаза на лоб лезут. Поэтому на дейли никому не интересно, что говорят другие. Ведь это не относится к его работе. Своих задачек и так выше крыши. С другой стороны, иметь индивидуальные задачи удобно. Рассчитываешь только на себя. Отвечаешь только за свой кусок работы.
Это рабочая группа. Она может быть дружной, атмосфера в коллективе может быть няшной. В целом, это нормальная, эффективная структура. До тех пор, пока не нужно сделать что-то по настоящему большое. Что-то, что не под силу индивидуалу. Что-то, что требует объединить усилия и из рабочей группы превратиться в команду.
Команда - рабочая группа, объединённая общей целью. Стратегической целью продукта и локальной целью спринта. На планирование спринта попадает большая задача. Очевидно, что её можно сделать только распараллелив работу на всех. А потом эту работу нужно интегрировать и проверять, как результат работы каждого члена команды взаимодействует с результатом других. Для этого нужно сфокусироваться и держать в голове глобальную картинку спринта.
Если кто-то кого-то недопонял, это может привести к тому что распараллеленная работа не интегрируется друг с другом. Обычно это становится понятно только в конце спринта. Времени на фиксы остаётся мало. Недопонимание, из-за которого возникли проблемы с интеграцией, кто-то может трактовать как тупизм или саботаж. Тут-то и начинается шторминг)
Чтобы работать как команда и делать прекрасные вещи, которые не под силу одиночке, нужно взаимопонимание и доверие. А оно рождается из открытости и обратной связи.
Выход из шторминга - стараться понимать друг друга. Помнить, что у каждого благие намерения. Просто разный язык и способ мышления.
Да, поначалу на гарантию взаимопонимания придется тратить много времени. Проговаривать все самые очевидные вещи. (Которые оказываются неочевидными другим). Не оставлять пространства для додумывания. Переспрашивать если начинаешь додумывать сам.
Из-за этого встречи будут затягиваться. Но это единственный путь научиться понимать друг друга, стать командой и сфокусироваться на большой общей цели.
Мне повезло быть частью команды, и теперь я хочу чтобы другие почувствовали то же, что и я.
Если у вас есть возможность взять амбициозную общую цель, — попробуйте. Если такой возможности нет, попробуйте найти. Дальше будет долгий путь — научиться работать над общей целью. В какой-то момент вы почувствуете, что обрели вторую семью.
Не всякая команда — на самом деле команда. Вот есть абстрактная группа людей, которые друг друга знают, работают с одним стеком, на одном продукте. Иногда советуются, как лучше сделать. Иногда сталкиваются с общими проблемами.
Чем не команда? Да тем, что у каждого сугубо индивидуальные задачи. И в спринте они почти не пересекаются. Иногда столько мелких параллельных задачек, что глаза на лоб лезут. Поэтому на дейли никому не интересно, что говорят другие. Ведь это не относится к его работе. Своих задачек и так выше крыши. С другой стороны, иметь индивидуальные задачи удобно. Рассчитываешь только на себя. Отвечаешь только за свой кусок работы.
Это рабочая группа. Она может быть дружной, атмосфера в коллективе может быть няшной. В целом, это нормальная, эффективная структура. До тех пор, пока не нужно сделать что-то по настоящему большое. Что-то, что не под силу индивидуалу. Что-то, что требует объединить усилия и из рабочей группы превратиться в команду.
Команда - рабочая группа, объединённая общей целью. Стратегической целью продукта и локальной целью спринта. На планирование спринта попадает большая задача. Очевидно, что её можно сделать только распараллелив работу на всех. А потом эту работу нужно интегрировать и проверять, как результат работы каждого члена команды взаимодействует с результатом других. Для этого нужно сфокусироваться и держать в голове глобальную картинку спринта.
Если кто-то кого-то недопонял, это может привести к тому что распараллеленная работа не интегрируется друг с другом. Обычно это становится понятно только в конце спринта. Времени на фиксы остаётся мало. Недопонимание, из-за которого возникли проблемы с интеграцией, кто-то может трактовать как тупизм или саботаж. Тут-то и начинается шторминг)
Чтобы работать как команда и делать прекрасные вещи, которые не под силу одиночке, нужно взаимопонимание и доверие. А оно рождается из открытости и обратной связи.
Выход из шторминга - стараться понимать друг друга. Помнить, что у каждого благие намерения. Просто разный язык и способ мышления.
Да, поначалу на гарантию взаимопонимания придется тратить много времени. Проговаривать все самые очевидные вещи. (Которые оказываются неочевидными другим). Не оставлять пространства для додумывания. Переспрашивать если начинаешь додумывать сам.
Из-за этого встречи будут затягиваться. Но это единственный путь научиться понимать друг друга, стать командой и сфокусироваться на большой общей цели.
Мне повезло быть частью команды, и теперь я хочу чтобы другие почувствовали то же, что и я.
Если у вас есть возможность взять амбициозную общую цель, — попробуйте. Если такой возможности нет, попробуйте найти. Дальше будет долгий путь — научиться работать над общей целью. В какой-то момент вы почувствуете, что обрели вторую семью.
Стоит ли разработчику заниматься предварительной проработкой задачи
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.
Miro
Где-то весной я решил попробовать продуктовый подход к найму. Чтобы лучше проводить интервью кандидатов в QIWI, я решил сам пойти попробоваться в роли кандидата. Пошел в компании, у которых есть чему поучиться. Одной из компаний была Miro. Тогда для меня стало откровением, что компания родом из Перми ищет разработчиков и тимлидов в свой Берлинский хаб.
Стал узнавать про них больше. Пришло осознание, что ковид и удаленка стали мощнейшим бустом для этой компании. Обнаружил крутой канал @miroengineering и движуху типа статей на хабре и медиуме, митапы и всякое такое. Мне захотелось прикоснуться к прекрасному, поэтому нашел интересную вакансию и вошел в процесс. Поговорил с HR и настолько она меня вдохновила, что пошел изучать продукт и сценарии использования. Даже нашел потенциальную уязвимость типа Secrets Exposure. С радостью понёс эту находку на интервью и...
Быстро вошел, — быстро вышел, приключение на полчаса :) Короче, я завалил первый же собес, где нужно было лайвкодить алгоритмы и говорить на английском. К такому меня жизнь не готовила) Впрочем, этот фейл меня раззадорил и я пошел дальше. Прошел собесы в разные компании и понял, что очень многое зависит от интервьюеров. Компания в лице интервьюеров может так относиться к кандидатам, что даже отвергнутый всё равно будет рекомендовать её.
Этот пост — рекомендация митапа для разработчиков и тимлидов от Miro. Ко мне в ЛС пришли организаторы из JUG Ru Group с просьбой попромить его. Мне, как человеку, который не стал тимлидом в Miro, офигенно интересно, как ребята справляются с быстрым ростом распределенных команд. И вообще как оно там, внутри.
В эту среду, 8 сентября, в 18:00. Онлайн. Бесплатно.
Нужна только регистрация.
Где-то весной я решил попробовать продуктовый подход к найму. Чтобы лучше проводить интервью кандидатов в QIWI, я решил сам пойти попробоваться в роли кандидата. Пошел в компании, у которых есть чему поучиться. Одной из компаний была Miro. Тогда для меня стало откровением, что компания родом из Перми ищет разработчиков и тимлидов в свой Берлинский хаб.
Стал узнавать про них больше. Пришло осознание, что ковид и удаленка стали мощнейшим бустом для этой компании. Обнаружил крутой канал @miroengineering и движуху типа статей на хабре и медиуме, митапы и всякое такое. Мне захотелось прикоснуться к прекрасному, поэтому нашел интересную вакансию и вошел в процесс. Поговорил с HR и настолько она меня вдохновила, что пошел изучать продукт и сценарии использования. Даже нашел потенциальную уязвимость типа Secrets Exposure. С радостью понёс эту находку на интервью и...
Быстро вошел, — быстро вышел, приключение на полчаса :) Короче, я завалил первый же собес, где нужно было лайвкодить алгоритмы и говорить на английском. К такому меня жизнь не готовила) Впрочем, этот фейл меня раззадорил и я пошел дальше. Прошел собесы в разные компании и понял, что очень многое зависит от интервьюеров. Компания в лице интервьюеров может так относиться к кандидатам, что даже отвергнутый всё равно будет рекомендовать её.
Этот пост — рекомендация митапа для разработчиков и тимлидов от Miro. Ко мне в ЛС пришли организаторы из JUG Ru Group с просьбой попромить его. Мне, как человеку, который не стал тимлидом в Miro, офигенно интересно, как ребята справляются с быстрым ростом распределенных команд. И вообще как оно там, внутри.
В эту среду, 8 сентября, в 18:00. Онлайн. Бесплатно.
Нужна только регистрация.
miro.jugru.org
Miro: онбординг инженеров, рост команды и Fluent setter’ы
Участие команды в принятии решений
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂
Привет!
Я тут вписался в программный комитет Podlodka HR Crew, которая пройдет 18-29 октября🔥
Мы два месяца готовили эту конфу, и я буду ведущим четырех сессий.
Да, это первое промо платной конфы. Но это реально труд и мы старались сделать качественный продукт.
И за промо мне никто не платил, просто я верю в это мероприятие.
Раньше я покупал билетики на Teamlead и Backend Crew не задумываясь, потому что казалось недорого.
Сейчас я побывал в шкуре ПКшника и убежден, что мероприятие стоит своих денег.
Podlodka Crew — это двухнедельные конференции с сессиями в 10:00 и в 19:00.
Конкретно эта HR Crew — для рекрутеров, тимлидов, собеседующих сеньоров, нанимающих менеджеров, деврелов и всех сочувствующих.
Во время первой недели разбираем Поиск и привлечение:
— Узнаете способы привлечения: от реферальных программ до митапов и обучающих курсов
— Научитесь смотреть на процесс глазами нанимающего менеджера
— Поймете, как эффективно описывать вакансии
На второй неделе погружаемся в Собеседования кандидатов:
— Разберетесь, сколько нужно собеседований и каких
— Поймете, как дать обратную связь кандидату и не облажаться
— Узнаете, как изнутри устроено интервью разработчика
— Послушаете про опыт One-Day-Offer от топовых компаний
А еще разберем вакансии и покекаем вместе над факапами с собеседований, которыми поделятся участники конфы.
Подарю проходку тому, кто принесет в комменты к этому посту самый забавный факап с собеседования :)
Полное расписание и билетики тут
Я тут вписался в программный комитет Podlodka HR Crew, которая пройдет 18-29 октября🔥
Мы два месяца готовили эту конфу, и я буду ведущим четырех сессий.
Да, это первое промо платной конфы. Но это реально труд и мы старались сделать качественный продукт.
И за промо мне никто не платил, просто я верю в это мероприятие.
Раньше я покупал билетики на Teamlead и Backend Crew не задумываясь, потому что казалось недорого.
Сейчас я побывал в шкуре ПКшника и убежден, что мероприятие стоит своих денег.
Podlodka Crew — это двухнедельные конференции с сессиями в 10:00 и в 19:00.
Конкретно эта HR Crew — для рекрутеров, тимлидов, собеседующих сеньоров, нанимающих менеджеров, деврелов и всех сочувствующих.
Во время первой недели разбираем Поиск и привлечение:
— Узнаете способы привлечения: от реферальных программ до митапов и обучающих курсов
— Научитесь смотреть на процесс глазами нанимающего менеджера
— Поймете, как эффективно описывать вакансии
На второй неделе погружаемся в Собеседования кандидатов:
— Разберетесь, сколько нужно собеседований и каких
— Поймете, как дать обратную связь кандидату и не облажаться
— Узнаете, как изнутри устроено интервью разработчика
— Послушаете про опыт One-Day-Offer от топовых компаний
А еще разберем вакансии и покекаем вместе над факапами с собеседований, которыми поделятся участники конфы.
Подарю проходку тому, кто принесет в комменты к этому посту самый забавный факап с собеседования :)
Полное расписание и билетики тут
podlodka.io
Онлайн-конференция Podlodka HR Crew #2
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам HR, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Привет! В прошлом посте я предложил написать трешовую историю с собеса в комменты и получить проходку на HR Crew. Признаю ошибку, это был слишком сложный призыв к действию :)
Предлагаю вариант попроще. Завтра, в субботу 16 окт, в 10:00 один из жмякнувших на кнопку ниже получит проходку 😉
Имя победителя появится в этом посте.
*****
Победители: Эмилька
Предлагаю вариант попроще. Завтра, в субботу 16 окт, в 10:00 один из жмякнувших на кнопку ниже получит проходку 😉
Имя победителя появится в этом посте.
*****
Победители: Эмилька
Говорить словами через рот
Раньше я писал про ретроспективы на разных этапах становления команды по Брюсу Такмену.
Хочу поговорить про выход из шторминга, улучшение взаимодействия и повышение продуктивности команды.
Всё это счастье достигается одним простым инструментом — говорить словами через рот.
Переход на следующий этап и рост продуктивности команды связаны с обратной связью. А конкретно, с количеством и качеством обратной связи. А еще с балансом корректирующей и подкрепляющей.
Я намеренно сказал корректирующая, а не негативная. Разница в конструктивности. Корректирующая — о том, что нужно поменять и как именно поменять в работе. Негативная — неконструктивная ОС о том, что плохо в работе. В худшем случае, это ОС о том, что плохо в человеке. Очень часто вместо корректирующей люди дают негативную. В шторминге обратная связь обычно либо никакая, либо негативная. А негативная и неконструктивная обратная связь — хуже, чем никакая.
При этом продуктивное поведение часто остается незамеченным, потому что "ну наконец-то нормально сделал. так и должно быть, че тут говорить то". Если давать только корректирующую обратную связь, пусть даже максимально честную и справедливую, то окружающие не поймут, ценишь ли ты хоть что-то в их работе. Если в команде никто не дает подкрепляющую ОС, а все только негативят, то может показаться, что все плохо, и что все только и делают, что ошибаются.
Получается такой самоподдерживающийся шторминг. Есть способ остановить круг негативной обратной связи.
Способ очень простой: увидеть что-то хорошее в работе коллег и подкрепить это позитивной ОС. Если делать это от души, это не будет наигранно и искусственно. Важно создать прецедент. Рассказать всем, почему это важно. Если замечать позитивные изменения, их станет больше.
Когда окружающие замечают в твоей в работе много хорошего, корректирующая обратная связь воспринимается проще.
Поэтому, если хочешь что-то менять с помощью корректирующей обратной связи, — научись сначала подкреплять позитивной 😉
Раньше я писал про ретроспективы на разных этапах становления команды по Брюсу Такмену.
Хочу поговорить про выход из шторминга, улучшение взаимодействия и повышение продуктивности команды.
Всё это счастье достигается одним простым инструментом — говорить словами через рот.
Переход на следующий этап и рост продуктивности команды связаны с обратной связью. А конкретно, с количеством и качеством обратной связи. А еще с балансом корректирующей и подкрепляющей.
Я намеренно сказал корректирующая, а не негативная. Разница в конструктивности. Корректирующая — о том, что нужно поменять и как именно поменять в работе. Негативная — неконструктивная ОС о том, что плохо в работе. В худшем случае, это ОС о том, что плохо в человеке. Очень часто вместо корректирующей люди дают негативную. В шторминге обратная связь обычно либо никакая, либо негативная. А негативная и неконструктивная обратная связь — хуже, чем никакая.
При этом продуктивное поведение часто остается незамеченным, потому что "ну наконец-то нормально сделал. так и должно быть, че тут говорить то". Если давать только корректирующую обратную связь, пусть даже максимально честную и справедливую, то окружающие не поймут, ценишь ли ты хоть что-то в их работе. Если в команде никто не дает подкрепляющую ОС, а все только негативят, то может показаться, что все плохо, и что все только и делают, что ошибаются.
Получается такой самоподдерживающийся шторминг. Есть способ остановить круг негативной обратной связи.
Способ очень простой: увидеть что-то хорошее в работе коллег и подкрепить это позитивной ОС. Если делать это от души, это не будет наигранно и искусственно. Важно создать прецедент. Рассказать всем, почему это важно. Если замечать позитивные изменения, их станет больше.
Когда окружающие замечают в твоей в работе много хорошего, корректирующая обратная связь воспринимается проще.
Поэтому, если хочешь что-то менять с помощью корректирующей обратной связи, — научись сначала подкреплять позитивной 😉
В последнее время мало пишу, но больше говорю головой.
Сегодня заканчивается Podlodka HR Crew, где я побывал в шляпах программного комитетчика, ведущего и спикера. Было круто!
По праву спикера, выкладываю в паблик запись одной из сессий :)
Треш-истории с собесов, уникальный закрытый контент!
Доступ по ссылке без регистрации и смс:
https://youtu.be/jMsII2cZwxg
Сегодня заканчивается Podlodka HR Crew, где я побывал в шляпах программного комитетчика, ведущего и спикера. Было круто!
По праву спикера, выкладываю в паблик запись одной из сессий :)
Треш-истории с собесов, уникальный закрытый контент!
Доступ по ссылке без регистрации и смс:
https://youtu.be/jMsII2cZwxg
YouTube
Разбор факапов с собеседований / Никита Хромушкин, Инесса Васильева, Александр Андронов
Мы попросили участников конференции рассказать о самых отборных их и коллег факапах на интервью. Не важно, собеседовал или собеседовался. Зашел не в ту переговорку и начал собеседовать на джависта растерявшегося дизайнера? Забыл название своего текущего места…
Привет!
В этом канале до сих пор я писал про всякие софтовые штуки. А ведь мне есть чем поделиться и по хардам.
Поэтому прямо сейчас готовлю вебинар для бесплатного курса от Слёрма и Райфа. Стартует в понедельник, 8 ноября.
https://slurm.io/from-middle-to-senior
Открываю курс темой "Работаем с базами данных PostgreSQL".
Спешу успеть, потому что Podlodka HR Crew только-только отпустила, и на всю подготовку у меня была неделя.
Признаюсь честно, очково :)
Задача амбициозная — упаковать в полтора часа весь цикл разработки БД для бэкендера.
Презентация уже на 130 слайдов, материала еще примерно на 30. Уже сомневаюсь, что влезу в полтора часа.
Прикинул тут, а ведь с PostgreSQL я уже 9 лет. И есть столько всяких приколюх, которыми хочу поделиться.
Когда-то я прочитал, что делиться знаниями, — как отдавать частичку себя другим. Это как бы горизонтальный перенос генов. Читай, размножение. Поэтому это поведение самоподкрепляется организмом.
Поэтому я чувствую мотивацию провести офигенный вебинар.
Записывайтесь. Бешплатно :)
В этом канале до сих пор я писал про всякие софтовые штуки. А ведь мне есть чем поделиться и по хардам.
Поэтому прямо сейчас готовлю вебинар для бесплатного курса от Слёрма и Райфа. Стартует в понедельник, 8 ноября.
https://slurm.io/from-middle-to-senior
Открываю курс темой "Работаем с базами данных PostgreSQL".
Спешу успеть, потому что Podlodka HR Crew только-только отпустила, и на всю подготовку у меня была неделя.
Признаюсь честно, очково :)
Задача амбициозная — упаковать в полтора часа весь цикл разработки БД для бэкендера.
Презентация уже на 130 слайдов, материала еще примерно на 30. Уже сомневаюсь, что влезу в полтора часа.
Прикинул тут, а ведь с PostgreSQL я уже 9 лет. И есть столько всяких приколюх, которыми хочу поделиться.
Когда-то я прочитал, что делиться знаниями, — как отдавать частичку себя другим. Это как бы горизонтальный перенос генов. Читай, размножение. Поэтому это поведение самоподкрепляется организмом.
Поэтому я чувствую мотивацию провести офигенный вебинар.
Записывайтесь. Бешплатно :)
Продуктовые метрики по вчерашнему вебинару
Привет. Канал то про продуктовую разработку. А продуктовая разработка — это в том числе про обратную связь. Вчерашний вебинар можно расценивать как фичу в продукте "Курс: Разработчик, или от Мидла до Сеньора." О метриках продукта пока рано говорить, а вот промежуточные метрики фичи уже есть, и я несу их вам :)
Когда создавал этот канал, для себя видел мотивацию в том, чтобы помогать людям, которым небезразлична их работа, находить что-то новое и полезное для себя. Радовался как ребенок, когда 40 человек задумались об использовании Definition of Ready и Definition of Done. Подводя промежуточные итоги вчерашнего вебинара, могу сказать, что я удивлен, ошеломлен и счастлив.
1️⃣ — В пике было 876 зрителей онлайн-трансляции. Это очень-очень много и очень-очень волнительно для меня.
2️⃣ — Сейчас ютуб пишет 6803 просмотров. Это вообще охренеть)
3️⃣ — Очень хороший график числа зрителей, отток маленький. На перерыве мы почти никого не потеряли, хотя кураторы от Слёрма меня пугали потерей 30% аудитории.
4️⃣ В канал пришло 200+ подписчиков. Привет! :)
5️⃣ 227 человек оставили подробную обратную связь через гуглоформу. Особенно радует, что каждая из затронутых тем нашла своего зрителя. Ну и конечно есть негатив от тех, кто меня раскусил и сразу понял, что я — самозванец =)
Делюсь с вами сводной таблицей ответов на гуглоформу: https://docs.google.com/spreadsheets/d/1rVp48sYBPR-52NaVO8kWUAF1czori1UPS2Qdu5MP3xM
6️⃣ Сейчас гитхаб пишет, что 248 раз склонирован репозиторий с домашкой. Надеюсь, в ней есть практическая польза. Хочу собрать обратную связь по домашке, чтобы в будущем учесть и сделать лучше и полезнее.
Поэтому просьба: пройдите анонимный трёхминутный опрос в гуглоформе: https://forms.gle/3eCNJm5pGxzbsa2FA
В комментах к этому посту обязательно поделюсь сводной таблицей и графиками ответов на эту форму.
Спасибо!☺️
Привет. Канал то про продуктовую разработку. А продуктовая разработка — это в том числе про обратную связь. Вчерашний вебинар можно расценивать как фичу в продукте "Курс: Разработчик, или от Мидла до Сеньора." О метриках продукта пока рано говорить, а вот промежуточные метрики фичи уже есть, и я несу их вам :)
Когда создавал этот канал, для себя видел мотивацию в том, чтобы помогать людям, которым небезразлична их работа, находить что-то новое и полезное для себя. Радовался как ребенок, когда 40 человек задумались об использовании Definition of Ready и Definition of Done. Подводя промежуточные итоги вчерашнего вебинара, могу сказать, что я удивлен, ошеломлен и счастлив.
1️⃣ — В пике было 876 зрителей онлайн-трансляции. Это очень-очень много и очень-очень волнительно для меня.
2️⃣ — Сейчас ютуб пишет 6803 просмотров. Это вообще охренеть)
3️⃣ — Очень хороший график числа зрителей, отток маленький. На перерыве мы почти никого не потеряли, хотя кураторы от Слёрма меня пугали потерей 30% аудитории.
4️⃣ В канал пришло 200+ подписчиков. Привет! :)
5️⃣ 227 человек оставили подробную обратную связь через гуглоформу. Особенно радует, что каждая из затронутых тем нашла своего зрителя. Ну и конечно есть негатив от тех, кто меня раскусил и сразу понял, что я — самозванец =)
Делюсь с вами сводной таблицей ответов на гуглоформу: https://docs.google.com/spreadsheets/d/1rVp48sYBPR-52NaVO8kWUAF1czori1UPS2Qdu5MP3xM
6️⃣ Сейчас гитхаб пишет, что 248 раз склонирован репозиторий с домашкой. Надеюсь, в ней есть практическая польза. Хочу собрать обратную связь по домашке, чтобы в будущем учесть и сделать лучше и полезнее.
Поэтому просьба: пройдите анонимный трёхминутный опрос в гуглоформе: https://forms.gle/3eCNJm5pGxzbsa2FA
В комментах к этому посту обязательно поделюсь сводной таблицей и графиками ответов на эту форму.
Спасибо!☺️
Есть ли смысл в индексе, если выгребаем треть таблицы?
После вебинара мне и организаторам писали, что я не прав: индекс по валюте используется даже если в запросе выгребается треть таблицы при равномерном распределении трёх валют по таблице счетов. Причем аргументировали: заполнили таблицу равномерно, сняли планы запросов, приложили скрины.
Очень круто, что вскопали так глубоко! Напомню, вопрос был: имеет ли смысл индекс по currency? Прежде, чем я признаюсь, что меня раскусили, предлагаю посмотреть план запроса. Вникать в план — как раз то, что двигает мидла в сеньора :)
Давайте посмотрим, что мы могли бы увидеть в плане.
1️⃣ Index Only Scan — Cамый производительный вариант. Это когда все нужные для запроса данные находятся в индексе (индекс по нескольким колонкам) или покрыты индексом (covering index).
2️⃣ Index Scan — Классический вариант. Поиск по индексу + доступ к таблице. Тут останавливаться не будем.
3️⃣ Sequence scan. Ну тут всё понятно, перебираем данные в таблице
4️⃣ Bitmap Index Scan + Bitmap Heap Scan. Как раз наш третий вариант. Он возможен благодаря тому что данные хранятся в куче (heap).
Если в двух словах, то это значит, что по индексу БД составит битовую карту блоков, отметит блоки содержащие нужные данные и затем просканирует эти блоки в таблице. В некоторых случаях это более эффективно, чем sequence scan. А еще это позволяет использовать несколько индексов при поиске. Короче, механика крутая.
Казалось бы, обмазаться индексами и будет Bitmap Scan с использованием всех возможных индексов на таблице) Но напомню про оверхед на обслуживание индекса, и то что Bitmap scan всё еще "чуть лучше" чем Sequence scan. Посмотрите на cost: для sequence scan он 0..56, а для bitmap heap scan 14..51.
Вот вам еще один аспект в трейд-оффе для принятия решения об использовании индекса. Решать, как всегда, вам :)
Вот статья из цикла про EXPLAIN: https://habr.com/ru/post/276973/ В ней более детально описана механика Bitmap Heap Scan с примерами.
После вебинара мне и организаторам писали, что я не прав: индекс по валюте используется даже если в запросе выгребается треть таблицы при равномерном распределении трёх валют по таблице счетов. Причем аргументировали: заполнили таблицу равномерно, сняли планы запросов, приложили скрины.
Очень круто, что вскопали так глубоко! Напомню, вопрос был: имеет ли смысл индекс по currency? Прежде, чем я признаюсь, что меня раскусили, предлагаю посмотреть план запроса. Вникать в план — как раз то, что двигает мидла в сеньора :)
Давайте посмотрим, что мы могли бы увидеть в плане.
1️⃣ Index Only Scan — Cамый производительный вариант. Это когда все нужные для запроса данные находятся в индексе (индекс по нескольким колонкам) или покрыты индексом (covering index).
2️⃣ Index Scan — Классический вариант. Поиск по индексу + доступ к таблице. Тут останавливаться не будем.
3️⃣ Sequence scan. Ну тут всё понятно, перебираем данные в таблице
4️⃣ Bitmap Index Scan + Bitmap Heap Scan. Как раз наш третий вариант. Он возможен благодаря тому что данные хранятся в куче (heap).
Если в двух словах, то это значит, что по индексу БД составит битовую карту блоков, отметит блоки содержащие нужные данные и затем просканирует эти блоки в таблице. В некоторых случаях это более эффективно, чем sequence scan. А еще это позволяет использовать несколько индексов при поиске. Короче, механика крутая.
Казалось бы, обмазаться индексами и будет Bitmap Scan с использованием всех возможных индексов на таблице) Но напомню про оверхед на обслуживание индекса, и то что Bitmap scan всё еще "чуть лучше" чем Sequence scan. Посмотрите на cost: для sequence scan он 0..56, а для bitmap heap scan 14..51.
Вот вам еще один аспект в трейд-оффе для принятия решения об использовании индекса. Решать, как всегда, вам :)
Вот статья из цикла про EXPLAIN: https://habr.com/ru/post/276973/ В ней более детально описана механика Bitmap Heap Scan с примерами.
Какая часть знаний RDBMS независима от конкретной СУБД?
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.
Telegram
Oracle Developer👨🏻💻
🔝 канал о разработке в СУБД Oracle:
SQL, PL/SQL, оптимизация, архитектура и многое другое...
Backend-pro.ru - обучение по различным программам, связанных с backend-разработкой для ФЛ и ЮЛ.
Отец-основатель: @denis_dbd Кивилёв Денис
SQL, PL/SQL, оптимизация, архитектура и многое другое...
Backend-pro.ru - обучение по различным программам, связанных с backend-разработкой для ФЛ и ЮЛ.
Отец-основатель: @denis_dbd Кивилёв Денис