Презентация моего доклада - на моем сайте https://mtsepkov.org/SelfDetSQA23
👍5
#sqadays Иван Железков и Алексей Кожин из ПСБ. В стране невыученных уроков, или как создавалась школа тестирования ПСБ. Тотальный дефицит привел к тому, чтобы создать школу обучения новичков внутри. Потому что программы обучения на рынке очень слабо коррелируют с потребностями. Когда вы обучаете для себя - можно получить тех, кто нужен. И был короткий рассказ, как они это сделали.
1. Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.
2. Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов
3. Опишите роль - кто должен получиться.
4. Разработайте контент.
5. Запустите обучение.
Про 2 и 3 важно: обучение под себя, поэтому взяли внутренний фреймворк разработки банка и пометили артефакты, которые разрабатывают тестировщики. Это - основные темы, из них следуют знания и компетенции для них - получается контент. Он не висит в воздухе, он привязан к реальному процессу банка, и артефакты создаются не модельные, а реальные.
Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.
1. Первичная оценка и передача знаний
2. Создание рабочего артефакта
3. peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга
4. Оценка экспертами результата
Этап peer2peer оказался очень ценным, студенты снимают большое количество ошибок, и еще закрепляют знания, что сильно разгруает экспертов на следующем этапе.
По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.
Результаты:
* частичное решение проблемы подбора через обучения молодых - джун+, подтверждено
* снижение текучки - эксперты смогли проявить себя по-другому
* сокращение затрат на обучение за счет привлечения внутренних экспертов
В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.
1. Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.
2. Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов
3. Опишите роль - кто должен получиться.
4. Разработайте контент.
5. Запустите обучение.
Про 2 и 3 важно: обучение под себя, поэтому взяли внутренний фреймворк разработки банка и пометили артефакты, которые разрабатывают тестировщики. Это - основные темы, из них следуют знания и компетенции для них - получается контент. Он не висит в воздухе, он привязан к реальному процессу банка, и артефакты создаются не модельные, а реальные.
Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.
1. Первичная оценка и передача знаний
2. Создание рабочего артефакта
3. peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга
4. Оценка экспертами результата
Этап peer2peer оказался очень ценным, студенты снимают большое количество ошибок, и еще закрепляют знания, что сильно разгруает экспертов на следующем этапе.
По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.
Результаты:
* частичное решение проблемы подбора через обучения молодых - джун+, подтверждено
* снижение текучки - эксперты смогли проявить себя по-другому
* сокращение затрат на обучение за счет привлечения внутренних экспертов
В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.
#sqadays Анастасия Золотых из 2GIS. Тестирование на лету: новый подход к визуальному тестированию. Продукт Otello: web, мобилки, множество платформ, виджеты для встройки. Среднее время разработки и доставки фичи 5 дней, смесь ручного и автоматизированного тестирования, в автотестах - случайные разрешения для устройств и случайные данные с генерацией на лету. Их команда тестирует фронт, бэк и интеграция - через моки. Команда решала задачу расширить автотесты, добавив проверку по скриншотам, так как проверка на всех платформах и разрешениях - трудоемкая. Классический подход основан на том, что ты держишь эталонные скриншоты и сравниваешь с ними результаты, которые получил при прогоне теста. В их случае возникают сложности: эталонные скриншоты надо обновлять вручную, и не очевидно, что это даст меньше работы, чем ручное тестирование, к тому же на скриншоте - фиксированное разрешение и данные, нельзя использовать случайную генерацию.
Поэтому они реализовали комбинированную конструкцию: сделали повторяемую генерацию данных с использованием random seed, что позволяет прогнать один и тот же тест на проде и на тестовом стенде, и снять скриншоты, которые должны совпасть там, где функционал не менялся. Снятие скриншотов встроили в систему функциональных тестов, а вот их сравнение запускается отдельно, и не совпадение на останавливает конвейер поставки, а разбирается вручную. Со снятием скриншотов есть отдельные проблемы, когда есть анимация и дочитка блоков, их не разбирали, а дали ссылку на другой доклад. Сравнение идет по хэшу, так как основная масса совпадает и это - быстро, а если хэш не совпал - используют pixelmatch, и результат показывают три картинки: тестовую, эталонную и расхождения. Понятно, что есть фичи с редизайном интерфейса, когда скриншоты с прода и теста точно не совпадают, они помечены отдельно, с учетом номеров версий, и это оставлено на ручное тестирование - пока функционал не докатят до прода.
В целом - заработало, были оценки по ускорению тестирования. А еще такие тесты позволили поймать некоторые косвенные эффекты, когда в мобилки иногда просачиваются эффекты, которые должны работать только в web, или когда появляются дополнительные информационные блоки, которых не должно быть.
Поэтому они реализовали комбинированную конструкцию: сделали повторяемую генерацию данных с использованием random seed, что позволяет прогнать один и тот же тест на проде и на тестовом стенде, и снять скриншоты, которые должны совпасть там, где функционал не менялся. Снятие скриншотов встроили в систему функциональных тестов, а вот их сравнение запускается отдельно, и не совпадение на останавливает конвейер поставки, а разбирается вручную. Со снятием скриншотов есть отдельные проблемы, когда есть анимация и дочитка блоков, их не разбирали, а дали ссылку на другой доклад. Сравнение идет по хэшу, так как основная масса совпадает и это - быстро, а если хэш не совпал - используют pixelmatch, и результат показывают три картинки: тестовую, эталонную и расхождения. Понятно, что есть фичи с редизайном интерфейса, когда скриншоты с прода и теста точно не совпадают, они помечены отдельно, с учетом номеров версий, и это оставлено на ручное тестирование - пока функционал не докатят до прода.
В целом - заработало, были оценки по ускорению тестирования. А еще такие тесты позволили поймать некоторые косвенные эффекты, когда в мобилки иногда просачиваются эффекты, которые должны работать только в web, или когда появляются дополнительные информационные блоки, которых не должно быть.
🔥4
#sqadays Алексей Пименов. Я предлагаю - они отказываются! Как обычно превосходный доклад о психологических аспектах сопротивления изменениям и работе с ними. Социальные аспекты сопротивления доклад не затрагивал, в вопросах они проявились, Леша отвечал и сказал, что об этом у нее есть отдельный доклад.
Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.
Питер Сенге писал: "люди любят изменения, люди не любят меняться самим. И если понять как мыслят люди - можно увидеть природу сопротивления. Для этого Алексей опирается на модель Канемана Думай медленно, решай быстро, Канеман выделил в мозгу две системы: быстрых решений и реакций, которую навал Система-1 и медленных размышлений, которую навал Система-2.
Система-1 обучается многократным повторением, на личном опыте, поэтому обучается медленно, зато реагирует быстро и не энергозатратна. Система-1 работает при процессах, которые выполняются автоматически: при вождении автомобиля, у боксеров в бою, а достигается это повторением, но для мыслительных процессов эти механизмы тоже работают, мы можем отвечать или писать код тоже на автомате.
Система-2 - логическое мышление, обучается через теорию и чужой опыт, по сравнению с ситемой-1 - быстро, на хорошем тренинге можно получить информацию, эквивалентную 2-3 года личного опыта и начать ее опрокидывать в практику за счет упражнений, но реагирует эта система медленно - размышление требует времени, и крайне энергозатратна.
Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.
Если говорить в позитиве, то и модель Маклина - вполне рабочая модель, если рассматривать ее как выделение логических уровней, подобно к тому, как мы выделяем логические уровни приложения (фронт-бэк-БД), при этом каждый уровень не просто обрабатывает запросы другого, а имеет собственные активные процессы, обращающиеся к другим. Схемы работы мозга, которые получаются на их основы, вполне совместимы с современными моделями работы мозга. Если интересует - я готов обсуждать подробнее. И модель Канемана тоже рабочая, она - функциональная, описываемые ей эффекты есть, а уж как она локализована в мозгу - вопрос отдельный, не следует путать функциональное и модельное деление системы, они отличаются. Когда нейрофизиологи предложат иную локализацию систем Канемана и уточнят их - будем ей пользоваться.
Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.
Питер Сенге писал: "люди любят изменения, люди не любят меняться самим. И если понять как мыслят люди - можно увидеть природу сопротивления. Для этого Алексей опирается на модель Канемана Думай медленно, решай быстро, Канеман выделил в мозгу две системы: быстрых решений и реакций, которую навал Система-1 и медленных размышлений, которую навал Система-2.
Система-1 обучается многократным повторением, на личном опыте, поэтому обучается медленно, зато реагирует быстро и не энергозатратна. Система-1 работает при процессах, которые выполняются автоматически: при вождении автомобиля, у боксеров в бою, а достигается это повторением, но для мыслительных процессов эти механизмы тоже работают, мы можем отвечать или писать код тоже на автомате.
Система-2 - логическое мышление, обучается через теорию и чужой опыт, по сравнению с ситемой-1 - быстро, на хорошем тренинге можно получить информацию, эквивалентную 2-3 года личного опыта и начать ее опрокидывать в практику за счет упражнений, но реагирует эта система медленно - размышление требует времени, и крайне энергозатратна.
Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.
Если говорить в позитиве, то и модель Маклина - вполне рабочая модель, если рассматривать ее как выделение логических уровней, подобно к тому, как мы выделяем логические уровни приложения (фронт-бэк-БД), при этом каждый уровень не просто обрабатывает запросы другого, а имеет собственные активные процессы, обращающиеся к другим. Схемы работы мозга, которые получаются на их основы, вполне совместимы с современными моделями работы мозга. Если интересует - я готов обсуждать подробнее. И модель Канемана тоже рабочая, она - функциональная, описываемые ей эффекты есть, а уж как она локализована в мозгу - вопрос отдельный, не следует путать функциональное и модельное деление системы, они отличаются. Когда нейрофизиологи предложат иную локализацию систем Канемана и уточнят их - будем ей пользоваться.
👍6❤2
И отдельное замечание про энергозатратность. Нейрон - это клетка, и как клетка он обладает постоянным потреблением АТФ, описываемое циклом Кребса, вариации в пределах 5%, тепловые карты возбуждения мозга показывают именно такие вариации. Но вот для взаимодействия с другими нейронами, размышления ему нужен дофамин, ресурс которого ограничен и в лимбической системе есть регулятор, направляющий его в части, управляющие движением, если ситуация предполагает, что организму придется драться или убегать, то есть в стрессе, или в неокортекс для спокойных размышлений. А так мозг не устает. Разработчик "устал" писать код и пошле "отдыхать" в Warcraft - мыслительных ресурсов эта игра требует не меньше, а иногда - больше. Просто система подкрепления перестала воспринимать написание кода как полезную деятельность и выдавать дофамин под нее.
Последнее замечания как раз касается тезиса Алексея, что если человек - метеозависимый или мало спал, то для привычной механической работы, например, у токаря, проблем нет, только безопасность снижается, так как она требует включения Системы-2 для выработки реакции, а для разработчика или тестировщика это важно, он в результате просидел весь день и нифига не сделал. Связь более сложная, я лично писать и отлаживать код могу даже в уставшем состоянии, а вот сложные задачи проектирования или писать статьи надо на свежую голову.
Возвращаюсь к конспекту. Есть борьба двух систем за ресурсы. Вы системой-1 ведете автомобиль, а системой-2 обсуждаете ремонт в квартире, вдруг на дорогу выбегает собака, контраварийная езда требует всех ресурсов, и Система-2 отключилась. И наоборот, он этот тест часто проводит: ходит с человеком кругами по залу и человек складывает двухзначные цифры, ок, потом предлагает умножать, простой пример - не проблема, а сложный - человек может пойти в отказ, но если начинает считать - останавливается, потому что система-2 забрала все ресурсы, на прогулку не осталось. При этом в подавляющем числе случаев побеждает система-1.
Как это работает с изменениями? Вы приходите в команду, готовите логичные аргументы, рассчитываете на систему-2 - а они влетают в систему-1 и получаете фабрику гнилых отмазок. Почему? Любые новые роли атакуют идентичность человека. "Некогда объяснять, ты scrum-мастер" - а он PM, он знает кто оно такой, перспективы и так далее - много вопросов. Новая ответственность атакует чувство собственного достоинства и так далее. Люди чувствуют, что получат гораздо меньше, чем потеряют. Есть люди, которые за любой кипеж кроме голодовки - их 15-20% они всегда за. А остальные - видят проблемы и угрозы и консервативны.
Что мы можем с этим сделать? Поскольку сопротивление - эмоционально, то нам надо эмоцию остановить. При чем быстро. А то он успел возразить, вы вступили в спор, а дальше, даже если логика у оппонента проявилась - ему уже надо признать, что он не прав, а это - снова эмоции.
Принцип дзю-до: не спорим, а присоединяемся и ведем. "Так не работает, мы делали" - присоединяемся "да, не работает, я тоже пробовал, давай обсудим как у вас не работало и у меня, подумаем можно ли что сделать". Обсуждение переводит в логику, и потом уже выводим на конструктив. Когда проектируете изменения - попробуйте предсказать аргументы и понять, как будете присоединиться.
Другой инструмент - перебить эмоцию более сильной: "если это не сделать нас всех уволят". Но надо быть хорошим психологом, потому что перебить надо именно эмоцией, и есть риски: если вы неверно попали - эмоция развивает, или человек согласиться ии пойдет другим путем: обидеться, уволиться и настроить против, или устроить итальянскую забастовку. Он этот метод не любит и не применяет, но видел людей, у которых он хорошо работает.
Дальше - ответы на вопросы.
Последнее замечания как раз касается тезиса Алексея, что если человек - метеозависимый или мало спал, то для привычной механической работы, например, у токаря, проблем нет, только безопасность снижается, так как она требует включения Системы-2 для выработки реакции, а для разработчика или тестировщика это важно, он в результате просидел весь день и нифига не сделал. Связь более сложная, я лично писать и отлаживать код могу даже в уставшем состоянии, а вот сложные задачи проектирования или писать статьи надо на свежую голову.
Возвращаюсь к конспекту. Есть борьба двух систем за ресурсы. Вы системой-1 ведете автомобиль, а системой-2 обсуждаете ремонт в квартире, вдруг на дорогу выбегает собака, контраварийная езда требует всех ресурсов, и Система-2 отключилась. И наоборот, он этот тест часто проводит: ходит с человеком кругами по залу и человек складывает двухзначные цифры, ок, потом предлагает умножать, простой пример - не проблема, а сложный - человек может пойти в отказ, но если начинает считать - останавливается, потому что система-2 забрала все ресурсы, на прогулку не осталось. При этом в подавляющем числе случаев побеждает система-1.
Как это работает с изменениями? Вы приходите в команду, готовите логичные аргументы, рассчитываете на систему-2 - а они влетают в систему-1 и получаете фабрику гнилых отмазок. Почему? Любые новые роли атакуют идентичность человека. "Некогда объяснять, ты scrum-мастер" - а он PM, он знает кто оно такой, перспективы и так далее - много вопросов. Новая ответственность атакует чувство собственного достоинства и так далее. Люди чувствуют, что получат гораздо меньше, чем потеряют. Есть люди, которые за любой кипеж кроме голодовки - их 15-20% они всегда за. А остальные - видят проблемы и угрозы и консервативны.
Что мы можем с этим сделать? Поскольку сопротивление - эмоционально, то нам надо эмоцию остановить. При чем быстро. А то он успел возразить, вы вступили в спор, а дальше, даже если логика у оппонента проявилась - ему уже надо признать, что он не прав, а это - снова эмоции.
Принцип дзю-до: не спорим, а присоединяемся и ведем. "Так не работает, мы делали" - присоединяемся "да, не работает, я тоже пробовал, давай обсудим как у вас не работало и у меня, подумаем можно ли что сделать". Обсуждение переводит в логику, и потом уже выводим на конструктив. Когда проектируете изменения - попробуйте предсказать аргументы и понять, как будете присоединиться.
Другой инструмент - перебить эмоцию более сильной: "если это не сделать нас всех уволят". Но надо быть хорошим психологом, потому что перебить надо именно эмоцией, и есть риски: если вы неверно попали - эмоция развивает, или человек согласиться ии пойдет другим путем: обидеться, уволиться и настроить против, или устроить итальянскую забастовку. Он этот метод не любит и не применяет, но видел людей, у которых он хорошо работает.
Дальше - ответы на вопросы.
👍4
Вопрос. Если команда против и выходит в саботаж, что делать?
Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.
Что почитать? Есть хороший бизнес-роман Рей Иммельман "Босс бесподобный или бесполезный". Будете искать - есть еще книги с похожими названиями: "Хороший босс, плохой босс" и "Хороший плохой босс", они про другое, не путайте.
Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".
Вопрос. Есть предложения по изменениям, я их убедила, ввели изменения, а пошло не так и они оказались плохими. И тебе говорят "ты виновата". У него в голове ответ, что делать, чтобы не допустить: надо анонсировать изменения как гипотеза, и оформить "мы верим, что будем делать это и получим результат, поймем так-то, а если их не будем - будет откат". Сейчас, когда история уже произошла, надо самостоятельно повиниться: "да, облажались", а дальше: может, проблема, что только я обдумывала, надо месте и так далее, попробовать включить обвинителей в социальную группу.
Вопрос. Есть системные администраторы на площадках "я не буду делать - не знаю", хотя на собеседованиях показывали. А другие - сидят в кабинеты и не выходят в поле. Что делать? Ответ: дело в авторитете руководителя, как его поднимать, если технических скилов недостаточно. Лайфхак: собрать группу, и сказать "такая задача - ваши предложения". У него есть игра: 3 стикера, довольная, нейтральная, недовольная. Выигрышная стратегия: хорошие расхватали, потом даешь недовольную, не доволен - какие предложения, и так далее - требуешь договариваться. Чтобы не выходить впозицию "я начальник - ты дурак", а это - не перспективно.
Вопрос. При внедрении изменений сталкиваешься с манипуляторами, которые тоже давят на систему-1, эмоции. Как быть? Ответ: подумай, нужен ли такой вредитель в команде? А в моменте спроси при всех: "Какого результата ты хочешь добиться такими возражениями?" - это может рассыпать чистый деструктив, вывести в область конструктивных предложений.
Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.
Что почитать? Есть хороший бизнес-роман Рей Иммельман "Босс бесподобный или бесполезный". Будете искать - есть еще книги с похожими названиями: "Хороший босс, плохой босс" и "Хороший плохой босс", они про другое, не путайте.
Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".
Вопрос. Есть предложения по изменениям, я их убедила, ввели изменения, а пошло не так и они оказались плохими. И тебе говорят "ты виновата". У него в голове ответ, что делать, чтобы не допустить: надо анонсировать изменения как гипотеза, и оформить "мы верим, что будем делать это и получим результат, поймем так-то, а если их не будем - будет откат". Сейчас, когда история уже произошла, надо самостоятельно повиниться: "да, облажались", а дальше: может, проблема, что только я обдумывала, надо месте и так далее, попробовать включить обвинителей в социальную группу.
Вопрос. Есть системные администраторы на площадках "я не буду делать - не знаю", хотя на собеседованиях показывали. А другие - сидят в кабинеты и не выходят в поле. Что делать? Ответ: дело в авторитете руководителя, как его поднимать, если технических скилов недостаточно. Лайфхак: собрать группу, и сказать "такая задача - ваши предложения". У него есть игра: 3 стикера, довольная, нейтральная, недовольная. Выигрышная стратегия: хорошие расхватали, потом даешь недовольную, не доволен - какие предложения, и так далее - требуешь договариваться. Чтобы не выходить впозицию "я начальник - ты дурак", а это - не перспективно.
Вопрос. При внедрении изменений сталкиваешься с манипуляторами, которые тоже давят на систему-1, эмоции. Как быть? Ответ: подумай, нужен ли такой вредитель в команде? А в моменте спроси при всех: "Какого результата ты хочешь добиться такими возражениями?" - это может рассыпать чистый деструктив, вывести в область конструктивных предложений.
#sqadays Эмиль Барлыбаев из Doubletapp. На старт... Внимание... Нагружаем! Короткий рассказ про организацию нагрузочного тестирования. Потому что важно не просто дать нагрузку - надо дать разную нагрузку для определения разных характеристик. Для начала надо понять, какие запросы будут давать основную нагрузку, обычно они составляют малое количество функционала, и тестировать надо именно их, а не по площади. Далее даем нагрузку и делим три зоны: слабую, когда потребляемые ресурсы постоянны, а время отклика около нуля и не растет, основную, в которой ресурсы растут линейно и рост времени отклика примерно линеен по нагрузки, и стрессовую, когда мы постепенно приближаемся к максимуму нагрузки. В целом у нас - образная кривая, и эти зоны - ее деление. В примере пределом было 100 rps, слабая дона 0-40, рабочая 40-80 и стрессовая от 80. Дальше сравниваем вычисленную нагрузку с ожидаемой. Если ожидаемая ниже - то можно сокращать ресурсы. Если больше - нужно масштабирование, горизонтальное (больше нод) или вертикальная (мощность ноды). И делаем три вида тестов: под рабочей нагрузкой проверяем стабильность работы, стрессовое для проверки работоспособности под большой нагрузкой и долгое (8+ часов) тестирование под низкой нагрузкой, чтобы увидеть, что ресурсы сервиса не текут. Еще нужно тестирование всплеска, обычно есть события, когда ожидается всплеск нагрузки, вплоть до перегрузки, и надо проверить, что когда оно проходит, сервис возвращается к рабочим параметрам. Помимо этого нужно тестирование объема, что накопление данных не повышает время отклика. И в конце доклада - оформление отчета и рекомендации lzk начинающего, но это - стандартно.
#sqadays - публикую что не успел вчера Анфиса Лаврова. Проектирование процесса тестирования по проблемам. Любопытный доклад об успешном сокращении регресса от 6 недель до 2, а далее до одной, с уменьшением числа занятых тестировщиков с 5 до 3, то есть трудоемкость уменьшилась в 10 раз. Что важно - были разобраны неверные шаги, которые предприняли сначала. А также показано применение различных методов - организации процессов, анализ причин на простых примерах. Так что в целом - успех. А сами неверные шаги служат хорошей иллюстрацией того, как применение стереотипных ответов может оказаться неверным в конкретной ситуации.
Сначала была часть про процессы с простой схемой: процесс есть способ организации деятельности, с помощью которого в ответ на некоторую потребность гарантировано достигается результат с понятными ресурсами и способами управления: потребность -> (управление, ресурс) -> результат. Организация процесса оберегает от ошибок и сберегает ресурсы. Пример из жизни: у них не было процесса превращения запроса от клиента, которые поступал на общий почтовый ящик поддержки в тикет в таск-трекере: ящик смотрели все сотрудники, чтобы обеспечить более быструю реакцию, но кто берет задачу - определено не было, поэтому иногда создавали два тикета, а иногда - не одного. Решили, что будет один постоянный ответственный за разбор ящика. Понятно, что есть и другие варианты, например, регулятрное дежурство, или договоренность о пометке письму в ящике, если создан тикет и так далее.
Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.
Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Кога Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.
Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.
Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увелчилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.
Сначала была часть про процессы с простой схемой: процесс есть способ организации деятельности, с помощью которого в ответ на некоторую потребность гарантировано достигается результат с понятными ресурсами и способами управления: потребность -> (управление, ресурс) -> результат. Организация процесса оберегает от ошибок и сберегает ресурсы. Пример из жизни: у них не было процесса превращения запроса от клиента, которые поступал на общий почтовый ящик поддержки в тикет в таск-трекере: ящик смотрели все сотрудники, чтобы обеспечить более быструю реакцию, но кто берет задачу - определено не было, поэтому иногда создавали два тикета, а иногда - не одного. Решили, что будет один постоянный ответственный за разбор ящика. Понятно, что есть и другие варианты, например, регулятрное дежурство, или договоренность о пометке письму в ящике, если создан тикет и так далее.
Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.
Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Кога Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.
Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.
Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увелчилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.
🔥3🐳1🫡1
После этого решила, что нужен анализ. Есть два метода: дерево текущей реальности и 5 почему. Дерево попробовали - сложно, а 5 почему у них сработал. На слайдах и в рассказе было объяснение, что именно они увидели: они прогоняют все 5000 тестов для всех 3 баз платформ, в то время, как часть из тестов проверяют фронт, UI, который для всех платформ одинаков, а часть - проверяют еще и бизнес-логику, которая может различаться, так как для каждой платформы бэк имеет свою реализацию. Очевидно, что тесты, которые исключительно проверяют фронт достаточно прогнать один раз. И они разметеили тесты, скоратив время прогона.
Крмое того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.
Что интересно, мотивация сотрудников в результате тоже выросла. Долгий регресс с механическим повторением кейсов их сильно демотивировал. Так что заодно была решена вторая проблема.
Крмое того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.
Что интересно, мотивация сотрудников в результате тоже выросла. Долгий регресс с механическим повторением кейсов их сильно демотивировал. Так что заодно была решена вторая проблема.
🔥2🐳1
#sqadays Андрей Бровко из Авито. Оценка рисков в разрезе модели качества продукта. Интересный доклад с приземлением общей теории управления рисками к тестированию продукта. На хорошем уровне, со ссылками на стандарты, это было в презентации, но я записал не все. Но, к сожалению, в докладе не было приземления этой теории на практику в разных вариантах, и каких-то не очевидных примеров применения, тонкостей. Хотя некоторое количество примеров - было. Но такое представление все равно полезно - чтобы ничего не забыть, и чтобы показать соответствие стандартам, это может быть важно для проекта.
Риск-менеджмент работает с реализацией позитивных и негативных сценариев, но обычно рассматривают только негативные. Общая схема: (Оценка риска: идентификация, анализ, определение степени риска) -> Обработка риска, а снаружи - цикл: область применения -> коммуникация -> отчетность -> мониторинг.
Уровень риска: вероятность * влияние, оцениваем по трем градациям низкий-средний-высокий по каждой оси. Для программы надо описать требуемый профиль риска, стандартного нет, и это понятно: для медицинских программ одни требования, для информационных сайтов - другие, для систем, от которых зависит исполнение бизнес-процесса - третьи и так далее.
Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.
Виды риска:
* риск проекта: персонал, поставщики, организация, лицензии, техника
* Риск продукта - опыт пользователя: функциональность, ошибки и та далее.
Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.
Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.
Делаем чек-лист. На слайде был скриншот из системы работы с рисками, Слева - виды тестирования, справа - список рисков, их вероятность ивлияние.
Список рисков целесообразно вести не для каждого проекта, а общий, а для проекта из него делать выборку и описывать параметры. У них есть корпоративный список рисков и процесс ведения: изменения инициируют тестировщики, плюс ведется регулярный пересмотр актуальности и оценки рисков.
Риск-менеджмент работает с реализацией позитивных и негативных сценариев, но обычно рассматривают только негативные. Общая схема: (Оценка риска: идентификация, анализ, определение степени риска) -> Обработка риска, а снаружи - цикл: область применения -> коммуникация -> отчетность -> мониторинг.
Уровень риска: вероятность * влияние, оцениваем по трем градациям низкий-средний-высокий по каждой оси. Для программы надо описать требуемый профиль риска, стандартного нет, и это понятно: для медицинских программ одни требования, для информационных сайтов - другие, для систем, от которых зависит исполнение бизнес-процесса - третьи и так далее.
Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.
Виды риска:
* риск проекта: персонал, поставщики, организация, лицензии, техника
* Риск продукта - опыт пользователя: функциональность, ошибки и та далее.
Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.
Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.
Делаем чек-лист. На слайде был скриншот из системы работы с рисками, Слева - виды тестирования, справа - список рисков, их вероятность ивлияние.
Список рисков целесообразно вести не для каждого проекта, а общий, а для проекта из него делать выборку и описывать параметры. У них есть корпоративный список рисков и процесс ведения: изменения инициируют тестировщики, плюс ведется регулярный пересмотр актуальности и оценки рисков.
❤1
#sqadays Антон Семенченко. Чистая архитектура в контексте Автоматизации тестирования. Это был доклад о том, как архитектура влияет на качество продукта и тестирование. Антон ведет фундаментальную проработку темы и сейчас материала на 16 часов. Он обещал выложить его в понедельник, а сам доклад был обзорным рассказом без презентации. Но главная цель - не передать содержание, а показать тестировщикам, что им надо не дистанцироваться от архитектурной работы, не принимать разработанную архитектуру как данность, а активно участвовать в работе над архитектурой. Дальше - тезисы, записанные с голоса.
Смысл Архитектуры - снижение стоимости продукта на всех этапах, включая тестирование и эксплуатация.
Отделить архитектуру от дизайна невозможно ни в строительстве, ни в ИТ. Дверная ручка - - дизайн, фундамент здания - архитектура, а декоративные колонны - что? В ИТ тоже самое, есть design pattern и architecture pattern, но многое на стыке. К архитектуре точно относится принципы деления на компоненты и организации взаимодействия между ними, к дизайну - детали внутреннее устройство компонент, а вот выделение отдельных компонент или принципы проектирования компонент - на стыке.
Классическая архитектура включает три уровня: UI, бизнес-логика и БД. Но если у нас бизнес-логика является основой, есть сменная БД и интерфейс, управляемый бизнес-логикой, то фактически у нас при бизнес-логике есть два пугина: UI и БД. Но может быть и по-другому. SOA - лишь часть архитектуры, она говорит о способах пересечения границы компонента чтобы обеспечить взаимодействие.
Роберт Мартин. Clear Architecture. В одной из глав он приводит 4 варианта архитектуры: трехкомпонентрная, функционально-разделенная, сущность-плугины и еще один. При этом в коде - одинаковое количество классов и интерфейсов. Получается, что логически ошибки везде одинаковы - раз речь идет о коде. Но раз они одинаковы, то архитектура не влияет на тестируемость? Но опыт говорит о другом. Проверки в коде - разработчиками в unit-test, и если это делают - то ошибки должны быть найдены. Тогда где влияние архитектуры?
Юнит-тесты, code review и многие другие практики. И QA должны понимать эти аспекты и участвовать в проработке, вписывать их в свою стратегию тестирования. И дальше фокусироваться на пересечения границ.
Автотесты - куда встраивать: есть unit, api, есть функциональные. Куда ставить? Автотесты - тоже часть архитектуры системы в целом. Чтобы тестировать слои изолировано, полезно встраивать промежуточные слои: command-line, api для тестирования. Это позволяет статьи независимым от того, что тестируешь на этапе подготовки данных для конкретного теста, сделать тесты более изолированными. Если в приложении часто возникают проблемы безопасности - давайте вынесем их за скобки функциональных тестов и будем проверять их отдельно, а для этого сделаем способ работы, при котором "все позволено" - но отдельным модулем, который точно не выкатим на прод.
Design pattern humble object. Скромный объект. Разобьем сложный объект на два, разделим сложность. Так в свое время появился MVC: разделим на клиенте визуальное представление (View) и бизнес-логику (Controller). Потом еще был Module-View-Presenter, MVVM - они тоже делили сложность. Декомпозиция уменьшает сложность разработки, обеспечивает независимое тестирование и локализации ошибки. База данных. СУБД - plugin для приложения. ORM - плугин для плугина.
Разрабатывали монолит, стал монстром, решили декомпозировать - куча проблем с тестированием. Это проблема архитектуры, но в других терминах. Потому сделали два шага в одном: изменили архитектуру и поменяли реализацию. Если монолит внутри структурирован - разбит на компоненты, используется dependecy rules и разные методы пересечения границ - фабрики, IoC и другие то он потом хорошо развалится на микросервисы. А если микросервисы декомпозированы неверно, то ошибки и не кончатся.
Смысл Архитектуры - снижение стоимости продукта на всех этапах, включая тестирование и эксплуатация.
Отделить архитектуру от дизайна невозможно ни в строительстве, ни в ИТ. Дверная ручка - - дизайн, фундамент здания - архитектура, а декоративные колонны - что? В ИТ тоже самое, есть design pattern и architecture pattern, но многое на стыке. К архитектуре точно относится принципы деления на компоненты и организации взаимодействия между ними, к дизайну - детали внутреннее устройство компонент, а вот выделение отдельных компонент или принципы проектирования компонент - на стыке.
Классическая архитектура включает три уровня: UI, бизнес-логика и БД. Но если у нас бизнес-логика является основой, есть сменная БД и интерфейс, управляемый бизнес-логикой, то фактически у нас при бизнес-логике есть два пугина: UI и БД. Но может быть и по-другому. SOA - лишь часть архитектуры, она говорит о способах пересечения границы компонента чтобы обеспечить взаимодействие.
Роберт Мартин. Clear Architecture. В одной из глав он приводит 4 варианта архитектуры: трехкомпонентрная, функционально-разделенная, сущность-плугины и еще один. При этом в коде - одинаковое количество классов и интерфейсов. Получается, что логически ошибки везде одинаковы - раз речь идет о коде. Но раз они одинаковы, то архитектура не влияет на тестируемость? Но опыт говорит о другом. Проверки в коде - разработчиками в unit-test, и если это делают - то ошибки должны быть найдены. Тогда где влияние архитектуры?
Юнит-тесты, code review и многие другие практики. И QA должны понимать эти аспекты и участвовать в проработке, вписывать их в свою стратегию тестирования. И дальше фокусироваться на пересечения границ.
Автотесты - куда встраивать: есть unit, api, есть функциональные. Куда ставить? Автотесты - тоже часть архитектуры системы в целом. Чтобы тестировать слои изолировано, полезно встраивать промежуточные слои: command-line, api для тестирования. Это позволяет статьи независимым от того, что тестируешь на этапе подготовки данных для конкретного теста, сделать тесты более изолированными. Если в приложении часто возникают проблемы безопасности - давайте вынесем их за скобки функциональных тестов и будем проверять их отдельно, а для этого сделаем способ работы, при котором "все позволено" - но отдельным модулем, который точно не выкатим на прод.
Design pattern humble object. Скромный объект. Разобьем сложный объект на два, разделим сложность. Так в свое время появился MVC: разделим на клиенте визуальное представление (View) и бизнес-логику (Controller). Потом еще был Module-View-Presenter, MVVM - они тоже делили сложность. Декомпозиция уменьшает сложность разработки, обеспечивает независимое тестирование и локализации ошибки. База данных. СУБД - plugin для приложения. ORM - плугин для плугина.
Разрабатывали монолит, стал монстром, решили декомпозировать - куча проблем с тестированием. Это проблема архитектуры, но в других терминах. Потому сделали два шага в одном: изменили архитектуру и поменяли реализацию. Если монолит внутри структурирован - разбит на компоненты, используется dependecy rules и разные методы пересечения границ - фабрики, IoC и другие то он потом хорошо развалится на микросервисы. А если микросервисы декомпозированы неверно, то ошибки и не кончатся.
Надо понимать, что есть архитектура, принимать участие в архитектурных диспутах и ее построении - чтобы архитектура была удобной для целей тестирования. Принципы архитектуры похожи: они так или иначе определяют способы разделения на компоненты и способы взаимодействия между ними - границы и способы пересечения.
Сегодня в МШУ Сколково на #Highload - он сюда вернулся из Крокуса. Как обычно, много треков и много людей. На первый доклад хотел пойти на Точки отказа в хайлоад-системах от Константина Козловского, но там - жесткое переполнение зала. Поэтому пошел на Сергея Бережного, Эволюция сервисов и средств разработки и ностальгирую по прошлому - в докладе история технологий интернета примерно с 1997 года по площади - операционки, редакторы, базы данных, средства разработки и так далее. К сожалению, эволюции, то есть логики развития, а не просто истории фактов, в докладе нет, просто сборка логотипов. Это жаль, это - интересно. В вопросах было: почему Яндекс ушел с FreeBSD на Ubuntu? Ответ - эксплуатационные характеристики для управления большим количеством машин в кластере. А смысл доклада - вспомнить именно open source решений, и таким образом показать их вклад в развитие ИТ, общность разработчиков, которые не зависит от конкуренции между компании. И анонс инициативы Яндекса по грантам для Open Source разработки.
👍1
#highload Евгений Кульгин из CDEK: Mattermost на стероидах: как мы запустили и развиваем корпоративный мессенджер. Был телеграм, slack, skype для видео, проблемы что несколько мессенджеров и внешних, при этом slack - снаружи, нет контроля за работой сотрудников и помнит только 10к сообщений. Плюс важно держать мессенджер под контролем: он встравивается в бизнес-процессы, и отрубание их крэшит - поэтому решили развернуть локально mattermost. RocketChat тоже пробовали, но оказался нестабильным. И дальше был технический рассказ о проблемах, которые они решали: отказоустойчивость, хранение изображений, ограничение доступа к каналам, сервис, чтобы увидеть просмотр сообщения в виде привычных галочек и так далее. Они остаются на бесплатной версии и делают сервис подключаемыми плугинами, работают с подключением elastic search вместо собственного индексатора и своих уведомлений. Mattermost часть из этого дает в платной версии, но там, по отзывам, оно неудобно, например, для настройки доступа к каналам надо идти в консоль, для проверки что прочитали - жать кнопки, это не появляется как галочки и так далее. Поэтому все равно нужна собственная разработка. Делает все это один разработчик, который больше решает задачи devops. Если задумаетесь про mattermost - доклад точно полезен. Свои доработки они планируют публиковать без кодов (готовили к выступлению, не успели), а если будет интерес - подумают, как открыть доступ к кодам.
#highload Виктор Бурцев из Яндекс: Слишком… много… асинхронщины… На что обращать внимание при работе с фичей из десятка сервисов, обрабатывающих 15 000 асинхронных задач в секунду. Поверх основного функционала Яндекс-такси есть функционал live activity - обновление состояния на клиенте, включая активность разных плашек. Все это обеспечивается большим количеством сервисов асинхронной работы, которые, преимущественно, работают по таймеру, а не по событиям - чтобы сбалансировать нагрузку. И рассказ был о том, как перестраивать архитектуру, чтобы обеспечить нужную производительность. Например, запрос от задачи в core-сервис создает недопустимую нагрузку - поэтому делаем промежуточное redis-хранилище, в котором обновление по событиям, а уже к нему идет обращение за данными. В докладе был ряд конкретных кейсов, без обобщений и выделения шаблонов. Их интересно осмыслить, если вы решаете такие задачи, может, появятся идеи уже для ваших задач. И общие рекомендации, прежде всего логи и мониторинг, при чем не общий по hardware, а внутри конкретных задач. А по организации взаимодействия - понимайте, что возможны падения и самые разные ответы смежных сервисов, это надо обрабатывать и вести себя разумно, не создавая дополнительной нагрузки.
👍1🔥1
#highload Андрей Цветцих мз Тинькофф: Эволюция и мифы CQRS. Доклад на стыке концептов и практики. Концептуально CQRS был придуман, когда запросов чтения много больше, чем запросов изменения данных. В этом случае логично отделить чтение от изменения данных, чтобы по-разному их масштабировать. Но для этого надо разделить запросы на чтение - query и изменение - command. И при этом единый класс, который обрабатывает конкретную сущность, делится, как минимум, на два обработчика: для запросов и для команд, а в перспективе для каждой команды и запроса появляется свой обработчик.
Тут было интересное концептуальное утверждение, что такое разделение классов на множество отдельных обработчиков для каждой команды и запроса, упрощает код, делает компактные процедуры, вместо нескольких тысяч строк получаются сотни. Но при этом общее количество кода не меняется, он просто ложится в разные обработчики и файлы. Это интересно, потому что фактически получается откат с ООП-парадигмы на предыдущую, процедурную парадигму разработки. ООП, когда его придумывали, как раз говорил, что объединение всей логике, связанной с отдельным доменом или сущностью в один класс как раз облегчает понимание кода, обеспечивая инкапсуляцию и скрытие внутренней логики, позволяет менять реализацию, сохраняя интерфейс за счет инкапсуляции и так далее. Это интересно обдумать...
Дальше был рассказ о практической реализации, в том числе решении задач по выделению общих частей обработки команд, которые в классике реализуются за счет приватных методов. А в этом случае их делают как отдельные сервисы, но надо заблокировать обращение снаружи, в C# это internal. Первый этап - просто разделить методы в коде и работать на общей базе, и это можно делать постепенно. Когда методы разнесены. можно распилить один сервис на два: на чтение и запись, это Андрей сказал уже в ответах на вопросы. И тут не обязательно разделять код, можно начать со специализации экземпляров. Дальше можно разнести базы для чтения и запросов, настроив репликацию master-slave и по-разному масштабируя, но у этого есть понятная обратная сторона - появляется замедление обновления данных при чтении. В коде при этом возникают два соединения, в одном запрещено обновление. В коде важно для обновлений читать предыдущее состояние из write-базы, а не из read. А следующим шагом можно вместо master-slave делать разные структуры данных, оптимизированные на запись и на чтение, с трансформацией при передаче данных. Модель для чтения может обновляться синхронно, если она носит характер кэша, но, как правило, это делают асинхронно. Асинхронное обновление не дает задержки, но нарушается консистентность и повышается сложность, надо разбираться с нарушением порядка сообщений, и вообще с ошибками обновления, которые рассинхронизовывают write и read базы.
Следующая часть - мифы CQRS. Они реально мешают применению.
* Query не может менять состояние и даже писать логи. Это неверно, нельзя лишь меняем основную модель. А логе, метрики и кэши - меняем. И логи - это важно, потому что работу надо мониторить.
* Query может читать только read-модель. Это не так, если нет проблем с производительностью - читайте основную, так что в read-модель можно выгружать не все.
* Command не может читать read-модель. Это действительно так, потому что в ней не актуальные данные, и можно пропустить обновление.
* Command не может возвращать значение. Это не так. Если мы создаем сущность, можно вернуть ее ключ, если что-то обновляем, то можно вернуть данные. Однако, это требует синхронной обработки команды. Если вы захотите потому перейти на асинхронное взаимодействие, то это не получится. То есть формально можно будет новый асинхронный запрос обернуть таймером до обработки, но это может отменить эффект перехода на асинхронное взаимодействие. Хотя есть разные кейсы.
Тут было интересное концептуальное утверждение, что такое разделение классов на множество отдельных обработчиков для каждой команды и запроса, упрощает код, делает компактные процедуры, вместо нескольких тысяч строк получаются сотни. Но при этом общее количество кода не меняется, он просто ложится в разные обработчики и файлы. Это интересно, потому что фактически получается откат с ООП-парадигмы на предыдущую, процедурную парадигму разработки. ООП, когда его придумывали, как раз говорил, что объединение всей логике, связанной с отдельным доменом или сущностью в один класс как раз облегчает понимание кода, обеспечивая инкапсуляцию и скрытие внутренней логики, позволяет менять реализацию, сохраняя интерфейс за счет инкапсуляции и так далее. Это интересно обдумать...
Дальше был рассказ о практической реализации, в том числе решении задач по выделению общих частей обработки команд, которые в классике реализуются за счет приватных методов. А в этом случае их делают как отдельные сервисы, но надо заблокировать обращение снаружи, в C# это internal. Первый этап - просто разделить методы в коде и работать на общей базе, и это можно делать постепенно. Когда методы разнесены. можно распилить один сервис на два: на чтение и запись, это Андрей сказал уже в ответах на вопросы. И тут не обязательно разделять код, можно начать со специализации экземпляров. Дальше можно разнести базы для чтения и запросов, настроив репликацию master-slave и по-разному масштабируя, но у этого есть понятная обратная сторона - появляется замедление обновления данных при чтении. В коде при этом возникают два соединения, в одном запрещено обновление. В коде важно для обновлений читать предыдущее состояние из write-базы, а не из read. А следующим шагом можно вместо master-slave делать разные структуры данных, оптимизированные на запись и на чтение, с трансформацией при передаче данных. Модель для чтения может обновляться синхронно, если она носит характер кэша, но, как правило, это делают асинхронно. Асинхронное обновление не дает задержки, но нарушается консистентность и повышается сложность, надо разбираться с нарушением порядка сообщений, и вообще с ошибками обновления, которые рассинхронизовывают write и read базы.
Следующая часть - мифы CQRS. Они реально мешают применению.
* Query не может менять состояние и даже писать логи. Это неверно, нельзя лишь меняем основную модель. А логе, метрики и кэши - меняем. И логи - это важно, потому что работу надо мониторить.
* Query может читать только read-модель. Это не так, если нет проблем с производительностью - читайте основную, так что в read-модель можно выгружать не все.
* Command не может читать read-модель. Это действительно так, потому что в ней не актуальные данные, и можно пропустить обновление.
* Command не может возвращать значение. Это не так. Если мы создаем сущность, можно вернуть ее ключ, если что-то обновляем, то можно вернуть данные. Однако, это требует синхронной обработки команды. Если вы захотите потому перейти на асинхронное взаимодействие, то это не получится. То есть формально можно будет новый асинхронный запрос обернуть таймером до обработки, но это может отменить эффект перехода на асинхронное взаимодействие. Хотя есть разные кейсы.
Прошел #Highload. Я был только первый день, как обычно, публиковал заметки с докладов, но успел не все. Поэтому решил быстро собрать и опубликовать отчет https://mtsepkov.org/Highload-2023, читайте! В целом - было интересно, хотя и немного сумбурно: highload вернулся в Сколково, 11 треков и 3600+ офлайн участников. Но лично мне возвращение понравилось. И у меня получилось заглянуть в технологии, до этого для меня так работал только Питерский highload. Спасибо организаторам и до встречи на #Teamlead, где я буду не только слушателем - я буду рассказывать про инженерную модель личности человека, попытке воедино собрать модели нейрофизиологии и психологии в единую архитектуру.
👍7
#TeamleadConf Дарья Вьюнова. Паттерны проектирования общения: как сказать, что ты думаешь на самом деле, так, чтобы от тебя не разбежались. Дарья - тренер и архитектор обучения в онлайн-школе OTUS. Идея доклада в том, что есть много стереотипов коммуникации, многие из которых мы восприняли из детства, которые вызывают эмоциональную реакцию, обесценивают и демотивируют. И это часто не является целью коммуникации, ее цель - поиск конструктивного решения в ситуации в рациональном, а не эмоциональном обсуждении. А такие стереотипы могут цеплять эмоции и выводить из констркутива.
Такие стереотипы формируются в детстве, Дарья полагает, что они встроены в культуру^ russian feedback, красная ручка , много указаний на ошибок и мало похвалы в школе и так далее. Я думаю, что привязка к русской культуре неверна, судя по количеству западных книг, где объясняется примерно тоже самое, так что проблема общая, хотя культурный контекст, естественно, накладывает свои акценты. И такая привязка обесценивает культуру в целом. Тезисы из зала - что есть опыт западных компаний, где перегибы в другую сторону.
Но истоки - это вторично, потому что проблема объективно есть. И дальше были конкретные рекомендации по формулировкам, которые не дадут эмоциональной реакции. В виде практического упражнения, во взаимодействии с залом. И это - очень полезно, это приземляла теоретический материал доклада на практику. Потому что теорию знают многие. Что еще важно: эти фразы не должны быть формальной пудрой, это внутри должно быть так.
Ключом для изменения является вопрос: что я хочу достигнуть в коммуникации, и помогаю я этому своими формулировками или мешаю.
Общие рекомендации, чтобы убрать эмоциональную реакцию:
* Оценивать работу, а не личность
* Исключить личные местоимения
* Переключить смысл с прошлого на настоящее и будущее.
* Надо было -> Можно. Мы все что-то должны, это смягчает коммуникацию.
* Негатив предмет давть очень предметно.
* Заменять "но" на "и" и "лишь" и "только" - ценить усилия, а не обесценивать.
Дальше те формулировки, с которыми работали, и варианты изменений
* Вы допустили ошибку -> У нас проблема, Произошла нештатка, Ой как интересно получилось, Можем сделать по-другому. Переключить смысл с прошлого на будущее.
* Вы выбрали неудочное решение -> мы что-то не учли, есть вариант лучше, из каких вариантов мы выбирали, давайте еще подумаем
* Вы не выполнили -> Работа не доделана, Согласно требованиям, этого недостаточно..., Планируется что-то доделать? В работе отсутствует...
* Нужно было выбрать другое решение -> В следующий раз нужно; стоит пересмотреть; предлагаю попробовать
* Я сделал бы совсем по другому - это переход на личности, и из прошлого в будущее -> Как смотришь на то, чтобы сделать вот так, Рассмотрим альтернативы, А как можно еще это сделать? Можно сделать так...
* Ты работаешь как все; за воротами миллион - обесценивает.
* Вы конечно правы, но ... -> Я частично согласен... Есть другая точка зрения ... Я в работе сталкивался... Вы правы, и в то е время ...
* Позитив: Спасибо, сделано верно, и предлагаю сделать еще что-то...
В презентации был очень забавный слайд с переводом рекламы из будущего в прошлое - можно развлекаться в метро и на улицах, забавно.
Как общаешься сам с собой? Такими формулировками или нет? Ты даже не моешь встать рано замените на "предлагаю завтра встать пораньше".
Интересная формулировка от заказчика "Проделана большая работа ...". формально это - правильная оценивающая фраза, но для меня это канцеляризм, прикрывающий очень мало сделанного. И, судя по реакции зала - не только для меня.
Сообщение: Привет, что там с задачей? Паника и напряженка, излишний контроль. У нее пример: руководитель спрашивает "Мы за последние полгода nps считали ..." - эмоции. Потому справилась спросила - а что? - Инвестор запросил, если есть - отправим. Рабочая ситуация. Тут идея - до вопроса дать контекст. Я вспомнил, что тут была такая задача, что с ней происходит. Или что-то еще.
Такие стереотипы формируются в детстве, Дарья полагает, что они встроены в культуру^ russian feedback, красная ручка , много указаний на ошибок и мало похвалы в школе и так далее. Я думаю, что привязка к русской культуре неверна, судя по количеству западных книг, где объясняется примерно тоже самое, так что проблема общая, хотя культурный контекст, естественно, накладывает свои акценты. И такая привязка обесценивает культуру в целом. Тезисы из зала - что есть опыт западных компаний, где перегибы в другую сторону.
Но истоки - это вторично, потому что проблема объективно есть. И дальше были конкретные рекомендации по формулировкам, которые не дадут эмоциональной реакции. В виде практического упражнения, во взаимодействии с залом. И это - очень полезно, это приземляла теоретический материал доклада на практику. Потому что теорию знают многие. Что еще важно: эти фразы не должны быть формальной пудрой, это внутри должно быть так.
Ключом для изменения является вопрос: что я хочу достигнуть в коммуникации, и помогаю я этому своими формулировками или мешаю.
Общие рекомендации, чтобы убрать эмоциональную реакцию:
* Оценивать работу, а не личность
* Исключить личные местоимения
* Переключить смысл с прошлого на настоящее и будущее.
* Надо было -> Можно. Мы все что-то должны, это смягчает коммуникацию.
* Негатив предмет давть очень предметно.
* Заменять "но" на "и" и "лишь" и "только" - ценить усилия, а не обесценивать.
Дальше те формулировки, с которыми работали, и варианты изменений
* Вы допустили ошибку -> У нас проблема, Произошла нештатка, Ой как интересно получилось, Можем сделать по-другому. Переключить смысл с прошлого на будущее.
* Вы выбрали неудочное решение -> мы что-то не учли, есть вариант лучше, из каких вариантов мы выбирали, давайте еще подумаем
* Вы не выполнили -> Работа не доделана, Согласно требованиям, этого недостаточно..., Планируется что-то доделать? В работе отсутствует...
* Нужно было выбрать другое решение -> В следующий раз нужно; стоит пересмотреть; предлагаю попробовать
* Я сделал бы совсем по другому - это переход на личности, и из прошлого в будущее -> Как смотришь на то, чтобы сделать вот так, Рассмотрим альтернативы, А как можно еще это сделать? Можно сделать так...
* Ты работаешь как все; за воротами миллион - обесценивает.
* Вы конечно правы, но ... -> Я частично согласен... Есть другая точка зрения ... Я в работе сталкивался... Вы правы, и в то е время ...
* Позитив: Спасибо, сделано верно, и предлагаю сделать еще что-то...
В презентации был очень забавный слайд с переводом рекламы из будущего в прошлое - можно развлекаться в метро и на улицах, забавно.
Как общаешься сам с собой? Такими формулировками или нет? Ты даже не моешь встать рано замените на "предлагаю завтра встать пораньше".
Интересная формулировка от заказчика "Проделана большая работа ...". формально это - правильная оценивающая фраза, но для меня это канцеляризм, прикрывающий очень мало сделанного. И, судя по реакции зала - не только для меня.
Сообщение: Привет, что там с задачей? Паника и напряженка, излишний контроль. У нее пример: руководитель спрашивает "Мы за последние полгода nps считали ..." - эмоции. Потому справилась спросила - а что? - Инвестор запросил, если есть - отправим. Рабочая ситуация. Тут идея - до вопроса дать контекст. Я вспомнил, что тут была такая задача, что с ней происходит. Или что-то еще.
❤11
В конце был слайд, озаглавленный как Итоги. Хотя это - не итоги доклада, это способы мышления, которые призваны исключить негативную эмоциональную реакцию, которую тебе надо сдерживать в коммуникации, и тогда эти стереотипы, возможно, вообще не всплывут. А может, все равно всплывут, ведь ситуация, когда новичок предлагает решение и ошибается - вполне рабочая, и эту ошибку надо исправить конструктивно. Вот эти тезисы:
* Другой - поставщик полезного опыта.
* Разнообразие может создавать устойчивость команды.
* Со всеми ОК.
* Каждый всегда делает наилучший из возможных выборов.
Я бы в целом суммировал, что у каждого есть свои спусковые крючки эмоций, среди которых есть распространенные. Они выводят коммуникацию из конструктива, и их лучше не задевать случайно. При этом многое зависит от культуры компании и команды, вопрос "как задача" воспринимается как рабочий вопрос, а не скрытый упрек "почему не сделал" - то его нормально задать. Просто восприятие человека узнать непросто.
* Другой - поставщик полезного опыта.
* Разнообразие может создавать устойчивость команды.
* Со всеми ОК.
* Каждый всегда делает наилучший из возможных выборов.
Я бы в целом суммировал, что у каждого есть свои спусковые крючки эмоций, среди которых есть распространенные. Они выводят коммуникацию из конструктива, и их лучше не задевать случайно. При этом многое зависит от культуры компании и команды, вопрос "как задача" воспринимается как рабочий вопрос, а не скрытый упрек "почему не сделал" - то его нормально задать. Просто восприятие человека узнать непросто.
❤7
#Teamlead Яна Фёдорова. ИмаДЖУНариум — представление джунов о лидах. Яна пришла в тестирование из преподавания английского. Она умеет работать с обратной связью от учеников, и применила это для джунов. Реальное исследование, анонимный опрос 100 джунов и обработка результата, именно этим доклад интересен. Джуны - актуальная тема: 120 курсов по 100 джунов в месяц - 12к новичков на рунке. В курсах рассказывают, что с руководителем легко и можно классно пообщаться, и новички из ВУЗов приходят с этим ожиданиями. Если меняют специализацию, то легче, уже есть понимание, что происходит.
Чувство новичка - эмоциональные качели: страх, неуверенность, стресс, радость. И ожидают, что тимлид - придет и успокоит. А реально у тимлида - в календарях встречи, контроль выполнения задач, работа по проекты и так далее. Поэтому тимлид хочет опыта, джун получает очередной отказ, расстраивается, но, наконец, его берут - и тут у него ожидания, что все будут рады и будут помогать. У джуна нет опыта, есть богатое воображение и куча статей, которые о н прочитал о прекрасных тимлидах. А руководитель при этом думает, где взять столько времени, надо будет отвечать на вопросы, все проверять, а календарь и так полон. То есть ожидания различаются очень сильно.
В исследовании 100 джунов рассказали кейсы взаимодействия с руководителем в ответ на открытый вопрос.
* 17% - супер-тимлид
* 26% - не взаимодействую с тимлидом, созвоны раз в месяц
* 44% - работать невозможно, терплю ради стажа, избегаю взаимодействия
* 13% - прекратили сотрудничество, не сработались
Позитивный опыт: ожидания меньше или совпали с реальностью. Радость, восторг, счастье, вовлеченность. Из отзывов: собеседование - круто; спрашивает коротко и по делу; следит за всеми и может показать; познакомил с командой, ввел в курс дела, предупредил, что ошибки будут и это нормально.
Нейтральный опыт: как-то у нас без тимлида, может уволился, а я не знаю, работают и нем огут сказать - хорошо или нет. Мне кинули задачу, справился - работай. Нет лида - нет проблем, лид-невидимка, разработчик, не трогает QA. И одни говорят - хорошо, а другие - жаль. Эта категория появилась в процессе исследования.
Негативный: ожидания были выше реальности: обида, страх, разочарования., беспомощность. Лидам нет дела для подчиненных, хамство, убедилась, что хороших руководителей нет даже в ИТ. Руководители не боятся обидеть, нет дела до других чувств и это сильно ранит сотрудников. Увольнение без физбэка.
Есть кейсы "богатое воображение" - когда ожидания за гранью реальности. И тоже есть эмоции. Там примеры ожиданий: офис не такой, или я ничего не делаю, потому что мне ничего не сказали.
Как джуны оценивают лидов:
* Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.
* Душа компании. Весельчаки, заводные. Но если постоянно весело - пропадает серьезность, и подчиненные перестают всерьез работать, про задачи - отшучиваются
* Бабаушка. О тебе всегда заботятся, на 1:1 хочется закутаться в пледик
* Токсичный лид: токсик - современный мем. Считает, что делает одолжение, что ты работаешь, отпускает шутки. Много новеньких, потому что старенькие не задерживаются, новенькие тоже уходят, и потом читаем в интернете "ужасная компания", а не "ужасный Иван Иванович"
Руководители про джунов
* Ботаник. Читает пользовательское соглашение, читает все требования, работают тщательно, но очень долго
* Проактивный. Первые в очереди на выгорание, давайте все, готовы работать все время. За ними надо следить - могут сгореть.
* Виноват не я! Так сложилось. Стремятся переложить не только ответственность, но и задачи.
* Младенец. Хотят прямой ответ на вопрос, не любят исследовать, пояснения, наставления, все показать.
* Память золотой рыбки: пришел-спросил-забыл. Спросил кого спросить - не спросил, забыл. Что делал вчера - не помнит.
Каждый руководитель выбирает джунов под себя. Чтобы было комфортно всем. Когда команде не комфортно - снижается уровень мотивации, люди уходят. Не только джуны.
Чувство новичка - эмоциональные качели: страх, неуверенность, стресс, радость. И ожидают, что тимлид - придет и успокоит. А реально у тимлида - в календарях встречи, контроль выполнения задач, работа по проекты и так далее. Поэтому тимлид хочет опыта, джун получает очередной отказ, расстраивается, но, наконец, его берут - и тут у него ожидания, что все будут рады и будут помогать. У джуна нет опыта, есть богатое воображение и куча статей, которые о н прочитал о прекрасных тимлидах. А руководитель при этом думает, где взять столько времени, надо будет отвечать на вопросы, все проверять, а календарь и так полон. То есть ожидания различаются очень сильно.
В исследовании 100 джунов рассказали кейсы взаимодействия с руководителем в ответ на открытый вопрос.
* 17% - супер-тимлид
* 26% - не взаимодействую с тимлидом, созвоны раз в месяц
* 44% - работать невозможно, терплю ради стажа, избегаю взаимодействия
* 13% - прекратили сотрудничество, не сработались
Позитивный опыт: ожидания меньше или совпали с реальностью. Радость, восторг, счастье, вовлеченность. Из отзывов: собеседование - круто; спрашивает коротко и по делу; следит за всеми и может показать; познакомил с командой, ввел в курс дела, предупредил, что ошибки будут и это нормально.
Нейтральный опыт: как-то у нас без тимлида, может уволился, а я не знаю, работают и нем огут сказать - хорошо или нет. Мне кинули задачу, справился - работай. Нет лида - нет проблем, лид-невидимка, разработчик, не трогает QA. И одни говорят - хорошо, а другие - жаль. Эта категория появилась в процессе исследования.
Негативный: ожидания были выше реальности: обида, страх, разочарования., беспомощность. Лидам нет дела для подчиненных, хамство, убедилась, что хороших руководителей нет даже в ИТ. Руководители не боятся обидеть, нет дела до других чувств и это сильно ранит сотрудников. Увольнение без физбэка.
Есть кейсы "богатое воображение" - когда ожидания за гранью реальности. И тоже есть эмоции. Там примеры ожиданий: офис не такой, или я ничего не делаю, потому что мне ничего не сказали.
Как джуны оценивают лидов:
* Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.
* Душа компании. Весельчаки, заводные. Но если постоянно весело - пропадает серьезность, и подчиненные перестают всерьез работать, про задачи - отшучиваются
* Бабаушка. О тебе всегда заботятся, на 1:1 хочется закутаться в пледик
* Токсичный лид: токсик - современный мем. Считает, что делает одолжение, что ты работаешь, отпускает шутки. Много новеньких, потому что старенькие не задерживаются, новенькие тоже уходят, и потом читаем в интернете "ужасная компания", а не "ужасный Иван Иванович"
Руководители про джунов
* Ботаник. Читает пользовательское соглашение, читает все требования, работают тщательно, но очень долго
* Проактивный. Первые в очереди на выгорание, давайте все, готовы работать все время. За ними надо следить - могут сгореть.
* Виноват не я! Так сложилось. Стремятся переложить не только ответственность, но и задачи.
* Младенец. Хотят прямой ответ на вопрос, не любят исследовать, пояснения, наставления, все показать.
* Память золотой рыбки: пришел-спросил-забыл. Спросил кого спросить - не спросил, забыл. Что делал вчера - не помнит.
Каждый руководитель выбирает джунов под себя. Чтобы было комфортно всем. Когда команде не комфортно - снижается уровень мотивации, люди уходят. Не только джуны.
👍5❤3
Тимлид - как препод. Джуны - как студенты первого курса. Они обычно приходят с горящими глазами, и дальше зависит от того, как выстроен процесс.
Что делать? Общаться словами через рот. Коммуницируйте.
Что важно новеньким?
* Обратная связь: ты пришел новенький работаешь, и не понимаешь: то ли все так плохо, что завтра уволят, или наоборот все хорошо. Обратная связь - не только оценка, это проявление интереса как твои задачи, это создает интерес нужности.
* Обсуждение допущенных ошибок: ошибки допускают все. Очень часто джун воспринимает ошибку как последнюю, которую разрешено допустить, проговорите явно: что не уволят за любую ошибку, что надо быстро сказать.
* 1:1 - это не просто возможность услышать обратную связь, это возможность сказать в комфортной безопасной обстановке по рабочим делам.
Выводы.
* Работать с ожиданиями, чтобы не было кейсов переоценки, рассказывайте что вы ждете
* "Все хорошо" - не значит, что все хорошо, люди не всем делятся, особенно когда нет доверия и ощущения безопасности
* Коммуникация - ключевое слово в построении отношений
* Ваше общение влияет на карьеру. Руководитель накосячил - фидбэк на компанию. Не закапывайте человека и не убивайте самооценку, даже если не сложилось
* Мы все джуны, мы приходим в новые компании и команды.
* Тимлид - важный человек, от него многое зависит.
Что делать? Общаться словами через рот. Коммуницируйте.
Что важно новеньким?
* Обратная связь: ты пришел новенький работаешь, и не понимаешь: то ли все так плохо, что завтра уволят, или наоборот все хорошо. Обратная связь - не только оценка, это проявление интереса как твои задачи, это создает интерес нужности.
* Обсуждение допущенных ошибок: ошибки допускают все. Очень часто джун воспринимает ошибку как последнюю, которую разрешено допустить, проговорите явно: что не уволят за любую ошибку, что надо быстро сказать.
* 1:1 - это не просто возможность услышать обратную связь, это возможность сказать в комфортной безопасной обстановке по рабочим делам.
Выводы.
* Работать с ожиданиями, чтобы не было кейсов переоценки, рассказывайте что вы ждете
* "Все хорошо" - не значит, что все хорошо, люди не всем делятся, особенно когда нет доверия и ощущения безопасности
* Коммуникация - ключевое слово в построении отношений
* Ваше общение влияет на карьеру. Руководитель накосячил - фидбэк на компанию. Не закапывайте человека и не убивайте самооценку, даже если не сложилось
* Мы все джуны, мы приходим в новые компании и команды.
* Тимлид - важный человек, от него многое зависит.
❤3