7324
правки
Изменения
Новая страница: «Прошла '''[https://sqadays.com/ru/program/117475 35-я SQAdays]''', на которой был ряд интересных докладов и много н…»
Прошла '''[https://sqadays.com/ru/program/117475 35-я SQAdays]''', на которой был ряд интересных докладов и много нетворкинга. Это — ожидаемо, конференция уже много лет стабильно показывает такое качество и атмосферу. Я выступал со своим докладом, слушал, общался, публиковал заметки с докладов, а сейчас собираю их в отчет. Помимо своего доклада я хочу отметить доклад '''Алексея Пименова''', а также '''совершенно замечательный доклад Александр Ткачева''', сделанный в стихах в форме сказки про Федота-стрельца. А доклады '''Лидии Роговой''' и '''Ирины Баржак''' вызвали у меня много размышлений, за что я им благодарен. В заметках доклады собраны в два раздела: про тестирование и про менеджмент и soft skill, а свой доклад я нескромно вынес в начало. В моих заметках докладов про тестирование и про все остальное примерно поровну, но это просто личный отбор докладов: я не тестировщик. На конференции докладов по тестированию, естественно, было больше.
= Максим Цепков. Системное мышление: что это и зачем нужно тестировщику? =
Мой доклад [[Системное мышление: что это и зачем нужно тестировщику? (SQAdays-2024)|'''Системное мышление: что это и зачем нужно тестировщику?''']] продолжал тему, которую я начал на AnalystDays: зачем ИТ-шнику нужно системное мышление, почему ему недостаточно специализированных моделей, таких как с4-model или описания бизнес-процессов. В этом докладе приземление было на задачи тестировщика. При этом я рассказывал реальные кейсы, в которых отдельно выделял — в чем именно здесь проявляется системное мышление. Сложность в том, что дать системное представление о системном мышлении в рамках доклада — невозможно. Мойе задачей было показать метод и побудить к его дальнейшему изучению.
= Про тестирование =
== Александр Ткачев из ГНИВЦ. Сказ об автотестах Windows-приложения ==
Потрясающая форма доклада — сказание в стихах в стиле сказки про Федота-стрельца. И это надо слушать и получать удовольствие. При этом содержательно в докладе — подробный рассказ о создании автотестов под Windows с вставками в прозе, в которых разбираются технические подобности:
1. Создание автотестов — техстек, особенности настройки драйвера, которому правильно передавать root, а не окно приложения чтобы иметь доступ к всяким нотификациям и служебным окнам windows, используемым, например, при сохранении. Они использовали python + behave (bdd на gherkin) + appium + allure report. gherkin выбран потоvу, что можно писать русские аннотации, а это позволило использовать готовые тест-кейсы. Для поиска элементов приложения по свойствам используется inspect, тут у windows свои особенности, с которыми надо разбираться, набор свойств? который разработчик видит в ide не слишком соответствует тому, что показывает inspect, так что даже там, где разработчики могут что-то добавить, получается не так просто. ActionChains аналогичны web и мобилкам, можно несколько объединять в одно действие, но нет простого скроллинга, можно скролить до элемента, что неудобно или pgup-pgdn.
2. Запуск автотестов на виртуалке — есть особенности, в том числе, чтобы автотесты продолжали выполняться, когда ты от виртуалки отключился, чтобы это не требовало физической работы твоей машины, которая держит сеанс. Там магия, в презентации она раскрыта. Если нужно использовать разные учетки — то с помощью psexec запускаешь драйвер автотестов под нужной учеткой, он запустит все остальное.
3. Как работать с элементами, если они не парсятся, например в кастомной форме. Координатный метод — ищем кусочек изображения, распознаем текст. Не слишком стабильные методы, коминируем, чтобы было стабильно. Есть скрины, есть вариант, что надо в заголовке окна проверить переменный текст, например ИНН — распознаем текст. Бывает ищем кнопку, потом считываем текст, проверяя, что нужная кнопка. Если цветовое выделение — ищем элемент, берем писксел, сравниваем цвет. Это кроссплатформенно, не зависит от технологий реализации, быстрое распознавание — часто быстрее, чем find element.
4. Встройка в CI/CD и процесс в целом. И тут помогает как раз то, что BDD фреймворк, использовали тест кейсы, которые уже есть, ручные тестировщики продолжили их писать, просто шаги — из меню вариантов, а не произвольные, и эти тест-кейсы есть в jira. А дальше автоматизаторы делают из этого автотесты. И это включается в общий цикл. По результатам тестов — рассылка в почте и отчет в allure.
== Владимир Техтилов из BelkaCar. Self-healing скриншот-тесты: тесты для ленивых ==
Идея — с помощью скриншот тестов можно достаточно просто автоматически проверять, что поведение UI не изменилось: берем сохраняем экраны и потом сравниваем. И они сделали первую версию тестов на python + playwrite + pixel match. Попробовали с ней жить — и выяснили, что есть проблема с обновлением эталонных экранов. Они меняются в ходе разработки, а для воспроизведения ты должен снять скриншот ровно в том же окружении, что будет при выполнении теста — разрешение экрана, модель браузера и так далее. Обновление оказалось трудоемким, и через некоторое время вернулись к функциональным тестам. Но через некоторое время проект обрел второе дыхание — сделали скрипт, который позволял одной кнопкой порождать весь набор скриншотов за счет запуска тестов в специальном режиме, когда изображения не сравниваются, а создаются новые. Это сделано на основе CI/CD, у них gitlab, но есть аналоги для других. Скриншоты красиво раскладываются по папкам, в зависимости от места в тесте, и дальше создается merge request на обновление тестов. В таком виде оно взлетело и летит.
В целом — понятно. Про аналогичную задачу был доклад год назад на SQAdays от 2GIS, где была задача получить скрины под все разрешения и версии браузеров, чтобы проверять работоспособность UI ([[SQAdays-2023b|мой конспект]]). А еще весной 2012 я слушал доклад, где тоже разбирали тестирование по изображениям. Там проблема была иной: desktop приложение запускалось через citrix, поэтому вместо элементов экрана, на которых опираются при тестировании, у тебя просто картинка. С этого доклада у меня тоже есть [[SQAdays-2012ab|конспект]]. И можно сравнить — что поменялось в подходах за столько лет.
== Александр Кидяев и Дмитрий Сорокин из ГНИВЦ. ЕГР ЗАГС. Трансформация стратегии тестирования во время перехода системы с монолита на микросервисы ==
ЕГР ЗАГС — монолитная система, обеспечивающая работу ЗАГС о всей стране. внедренная вместо разрозненной автоматизации на местах. Развитие столкнулось с ограничениями и было решено сделать вторую версию на микросервисах. Но при этом обеспечить мягкий переход с параллельной эксплуатацией обоих систем. Разработку новой системы ведут несколько команд, у каждой — свой пул микросервисов. а команда тестирования — общая, и в ее ответственности и старая и новая системы. Рассказ был про изменение подходов, которое было призвано обеспечить качество. Вот новые практики.
* Встреча 5 амиго для обсуждения новых фич: разработчик, QA, аналитик, архитектор, заказчик. Из этих встреч — поток информации о том. что будет сделано.
* Тестирование требований, которые ведут в confluence
* Центр компетенций тестирования: поиск решений и лучших практик
* Сразу закладывают нагрузочное тестирование, в старой версии были только отчеты. И автоматизация тестирования.
* DoD и DoR для задач со стороны тестирования. Утверждены как регламенты, и это выручает по срокам — неподготовленные задачи не идут.
* Попарное тестирование — оно работает хорошо
* Начали смотреть изменения в законах. В одном проекте Минюста увидели изменения, которые сильно конфликтуют в текущим функционалом системы, дали обратную связь — и Минюст поменял проект.
* Участие в ПСИ и демо приносит практическую пользу
Про боли.
* Не стоит писать кейсы до реализации нового функционала. Потому что его выкатили, через неделю изменился, через неделю еще изменился, и ты несколько раз актуализируешь тесты.
* Пиковые нагрузки. Команды работают независимо, релиз ЗАГС-1 вышибает команду на неделю, и если в это время кончается спринт у ЗАГС-2 получается перенапряжение, это надо разруливать.
== Андрей Романюк из Okko. Релиз без сюрпризов: как мы уменьшили количество багов в проде ==
Основная идея доклада — переход от субъективно выставляемого приоритета бага к count — объективной оценке его влияния, которая получается как произведение охвата пользователей на барьерность бага и на 10000, чтобы получить целое число (охват и критичность считают в процентах). Охват зависит от сценария, в котором проявляется баг, для каждого из сценариев известна частота их использования пользователями: главную страницу открывает 90 %, а авторизацию всего 11 %, потому что авторизовались — и она запомнена. Охват обновляют раз в месяц. А барьерность варьируется от 1 %, например, для всплывающего окна, которое повисит и исчезнет через 3 секунды, до 100 % если блокируется запуск фильма, и еще один коэффициент — доля устройств, на которых баг проявляется, одни баги проявляются во всех версиях, а другие могут быть, например, только на телевизорах. Сount дает объективное влияние бага.
Они считают Count для текущего состояния прода, а также для новых фич, в которых часто баги исправлены не полностью. И договорились, что Count > 100 — ситуация, которой допускать не хотят. Поэтому если появляется сырой релиз, то выходят предрелизные фичи-предупреждения. Продукт все равно может взять на себя ответственность за выпуск такого релиза, но обычно релиз задерживают. Раньше тоже были ситуации сырого релиза, но поскольку объективного показания влияния бага на пользователей не было, то продукты чаще всего принимали решение релиз выкатывать. В результате на проде багов с count > 100 практически нет. Статистика в целом улучшилась, но не сильно, так как баги с меньшим count пропускают.
Был интересный вопрос: зачем вы берете на себя доказательство, что релиз не надо катить? Ответ: продукты не понимают влияние бага, им кажется, что это фигня. А любой баг на проде воспринимают как ошибку тестирования. Предрелизы — подсвечивают и показывают чья ответственность, и каков размер проблемы.
== Павел Владимиров. Meta-Prompting и агенты: выжимаем максимум из ChatGPT ==
Для начала было немного базовой терминологии, и тут для меня было интересен параметр вероятности, определяющий как GPT ищет ответ: перебором до достижения требуемой вероятности, или просто на заданную глубину. И параметр температуры, который задает креативность ответа, сводящуюся к тому, что для ответа выбирается не самый вероятный из вариантов продолжения разговора, а другой.
А дальше был рассказ про промпты, начиная с простых, когда в запросе дают один или несколько примеров ответа (one shot или few shots) к более сложным. В chain-of-thought ты просишь дать цепочку рассуждений, тем самым GPT разлагает сложную задачу на несоклько простых, ответ для которых находит с большей вероятностью. Contextual prompting задает контекст, который надо учитывать для ответа. Ask before answer явно просит задать дополнительные вопросы для уточнения ответа, в этом случае GPT сначала вытянет контекст у пользователя.
Еще GPT умеет собирать команду агентов, которые коллективно решают задачу, находясь в разных позициях. Но при этом есть ограничения, связанные с тем, что такой подход очень быстро накапливает контекст, и может выйти за ограничения, прервав формирование ответа. И есть схема метапромптинг, когда есть оркестратор, который накапливает контекст, и спрашивает экспертов, которые контекста не запоминают, это экономит ресурсы.
Отмечу, что на конференции было много докладов про Это один из рассказов про работу GPT, но я был только на одном из них.
== Лариса Ковалевская из Авито. Как мы меняли процессы с помощью Team Maturity Model, чтобы максимально качать качество ==
Любопытный доклад. Рассказ был про команду Авито-путешествия, которая переходила из режима стартап-разработки, в котором критерием качества является совесть разработчиков, метрики не используются, а баги правятся на личном взаимодействии службы сопровождения и разработки, к регулярному процессу с мониторингом через метрики, разбором накопленных багов, покрытием тестами и другими регулярными практиками.
В чем особенность этого кейса? В авито есть модель зрелости команд, Team Maturity Model, определяемая через опросник, по которой каждый квартал команда проходит аудит. Там есть блок качества, и на входе показатели были 29 % при baseline 80 %, и было много других наблюдаемых проблем, например, накопившийся бэклог багов. Команда начала работу над качеством, не разбираясь детально с моделью зрелости, а, так сказать, из общих соображений. Внедрили практику оценки задач 3 амиго (обсуждение на входе аналитиком, разработчиком, тестировщиком), ручные и приемочные тесты, тест-дизайн и продакт-приемка, внедрение SLA по общению с пользователями и ревью бэклога багов. Ситуация улучшилась. Но TMM получился всего 60 % вместо ожидаемых 80. И тогда команда пошла разбираться в структуре блока QA в TMM. И обнаружила там те практики, с которыми у них плохо: отсутствие DoD и DoR, низкое тестовое покрытие, неактуальная тестовая модель, отсутствие работы с рисками и другие. И поставила квартальные цели по обеспечению этих показателей — писать DoD и DoR в задачах, написать тестовое покрытие — оно было декомпозировано до конкретных задач по покрытию сценариев, и так далее. И выполнило задачи, получив TMM 80 %.
TMM авито опубликован, в докладе была ссылка, а я нашел статью здесь (https://habr.com/ru/companies/avito/articles/578342/).
Но вот вопрос, дало ли это что-то реально, пользователям продукта и компании — не раскрыт. Почему TMM по качеству именно такая, в чем ценность именно этих таких показателей? Об этом в докладе не было, TMM представлялся как абсолютный идеал. И вот у меня такой рассказ вызвал воспоминание о сборах в армии, когда наряду с полезными знаниями нас учили красиво и быстро заправлять кровати, а также готовили к маршу в ногу и с песней. И эта составляющая была не менее важная, чем содержательная подготовка. В армии это имеет давнюю традицию с Павла I, который это копировал у Фридриха Великого. При этом у Фридриха была содержательная цель, он использовал как часть боевой подготовки, а Павел — лишь для парадов. Чем достижение TMM в 80 % отличается от требований идеально маршировать на параде? И ясно ли это команде, или они видят тут некоторый ритуал — непонятно. Из доклада это неясно.
= Про менеджмент и soft skill =
== Лидия Рогова. Конфликты восприятия или ТОП-5 инструментов для налаживания коммуникации ==
Доклад вызвал размышления: те техники, которые Лидия давала — просты, и кажется, что это — базовый уровень, ими должен владеть каждый. Но они востребованы, люди до этого базового уровня не дотягивают, и возникает вопрос — почему? Еще отмечу, что, на мой взгляд, часть материала была слишком упрощена, все-таки реальный процесс — сложнее. А какие-то вещи, представляя собой распространенные практические приемы, опираются на ложные основания, и вот стоит ли их давать, не задумываясь об этих основаниях — вопрос для меня открытый.
А теперь, после такой преамбулы — краткое содержание доклада с моими комментариями. Замечательно, что доклад начался с фокусировки слушателей: личная цель мероприятия, почему важно для меня лично, что хочу получить как результат; как в конце пойму, что получил. На это была дана пара минут, я, я думаю, что для слушателей была польза от такой фокусировки на всю конференцию. Потому как далеко не всегда об этом думают. А в конце доклада был такт — подумать и оценить — продвинулись или нет.
Дальше — цитата из Галилея: человека нельзя научить, можно помочь найти это в себе. Позиция известна, на ней основаны многие техники коучей. Только надо понимать, что это — идеалистический взгляд, основанный на том, что у человека есть нематериальная душа или аналогичная субстанция, которая при рождении получила хостинг в нашем теле на время жизни, и которая уже содержит все наши знания. Или, в другой парадигме — есть генетический код, в нем все записано. А реально природа для млекопитающих перешла от программирования в генетическом коде к обучению личным опытом. Которое человек дополнил обучением через теоретическое знание, через книги. А про душу — достоверная информация о знаниях, в нее заложены — отсутствуют. В докладе тема дальше не развивалась.
Коммуникация:
* вербальная: устная и письменная;
* невербальная — мимика и жесты;
* паравербальная — тон, интонации, темп, паузы, смех
Коммуникация важна, ее хотят перевести в хард-скиллы, включить в образование. Я тут замечу, что в Древнем Риме так уже было — риторика входила в базовое образование, а с тех пор куда-то потерялось.
Проблемы коммуникация связаны с тем, что одни и те же слова могут быть по-разному интерпретированы, и потому понимают вовсе не то, что имел ввиду говорящий. А дальше возникают обиды. Например, эффективно работать может означать, что надо больше заработать для компании, а не сделать больше задач. Или человек старался сделать красиво, породил 5 вариантов, все не понравились. Или сказали сделать срочно, он не спал всю ночь, а утром сказали «посмотрим позднее» — наверное, срочность была не столь велика. В общем, кейсы — понятные, но я бы не сказал, что все они связаны именно с интерпретацией слов. Часть ситуаций связаны с неверными ожиданиями, которые вовсе не обязательно обусловлены словами в коммуникации, они связаны с различными представлениями о жизни, разным домысливанием ситуации. С той же красотой — проблема могла быть не в оформлении, а в смысловом содержании, например.
Вообще домысливание за другого, при которой ты принимаешь что-то на свой счет — распространенная ошибка. Например, руководитель утром не спросил про котика, хотя обычно это делает, и ты думаешь, что он тобой недоволен. А реально у него могут быть совсем другие проблемы дома или озабоченность рабочей встречей или что-то еще. Или наоборот, со стороны руководителя недовольство командой. потому что они плохо работают, хотя это он ставит нереалистичные задачи и так далее.
Все это конфликты восприятия. И тут важно не обижаться, замыкаясь в себе, и не обсуждать кто круче, а выходить в коммуникацию, уточняя ситуацию, и мысля конструктивно. Доносить объективность ситуации, рассказывать, про свою работу, если с ней есть проблемы. Подходить к ситуации разумно: если руководитель пришел с вопросом, а ответ требует обдумывания и работы с материалами — то сказать об этом, а не стараться как-нибудь ответить немедленно.
Я тут хочу дополнить: при разборе таких конфликтов важно держать фокус целей работы, при этом уточнять интерпретацию этих целей, потому что она может различаться. При этом на путь к целям могут быть разные точки зрения, это нормально, и разделение ответственности может быть различным, но объединяющие цели при этом позволяют искать варианты, идти в конструктивное обсуждение.
Инструменты по коммуникации.
* Активное слушание. Заинтересованно слушаем собеседника, не решаем собственные задачи. Кивать, угукать, агакать.
* Фактичность. Мыслить фактами, а не эмоциями и субъективными оценками. Коучи любят вопрос «а что ты сейчас чувствуешь?» Очень важно разделять.
* Я-позиция. Не быть токсиком, не говорить что кто-то сделал неправильно, а передавать позицию из своего опыта: «Я закрываю таски за день, потому что если их закрывать дольше, это может сказаться на отношении заказчика, не стоит так делать» вместо «вы долго закрываете таски, надо быстрее». Высказывая мнение, не задевать чувства другого человека. Уметь воспринимать себя и свое мнение, при этом слышать других и понимать, что оно другое, а не неверное.
* Делегирование. Это проблема всех руководителей, а не только начинающих. Усталость «почему я за них всегда все делаю» — типичное.
* Групповые встречи и навыки фасилитации. Это — важно. Обозначить повестку, модерировать. Форматы — разные (master mind, обмен опытом, one2one в том числе групповой). Командная встреча — ведет к цели команды. Групповая встреча — общая тематика и личные цели.
По инструментам в ходе рассказа были приемчики.
Фактичность. С вами поругались, обесценили ваши задачи. Вы приходите, сели в уголок, и представли себя мухой на стекле. Муха не знает, что такое чувство, она мыслит фактами. Муха видит, что мужчина машет руками. Муха не может понять поняла, что женщина расстроилось, а мужчина зол. Она может слышать, что женщина стала говорить громче. Если так разобрать ситуацию, что про многие конфликты можно увидеть, что они несерьезны, тут домыслы.
Делегирование. Признаки проблемы: постоянная текучка в команде, все приходится делать, неясно кто за что отвечает. А на уровне самооценки — убеждение «я всегда сделаю быстрее», или «подчиненные сделают хуже, руководитель будет недоволен», и с такие убеждения надо менять. В докладе не было — как менять, так что поделюсь своим: работает трезвая оценка результативности команды, потому что руководитель, который все делает сам, является ограничением для команды. Понятно, что может быть стратегия героя пожарника-поджигателя: сам поджег, сам потушил — герой. Но если посмотреть рационально, то команда может сделать больше, чем один, и этот результат стоит того, чтобы научиться делегировать.
Делегирование — процесс передачи ответственности (не функций), с постановкой целей для достижения.
Как добиться делегирования?
* ставить цели, а не задачи, и определять результат
* анализировать полученные результаты и обсуждать выводы
* тратить время на верхнеуровневую коммуникацию
* мотивировать свою команду
* цели должны соответствовать уровню исполнителя и соразмерны уровню ответственности
Я тут хочу дополнить. Про делегирование есть модель ситуационного лидерства (надо смотреть первую версию модели, вторая — о другом). Если у вас команда джунов, которые пока не могут сделать самостоятельно, то по пути к делегированию надо пройти от режима поручений directing к режиму coaching, в котором ты учишь человека вырабатывать план действий и далее в режим supporting, когда ты учишь во-время звать на помощь при проблемах. А надежда, что делая задачу за задачей по поручениям сотрудник сам научится делать, конечно, имеет основания, но опыт средневекового обучения мастерству говорит, что на это нужно примерно 7-10 лет.
Про встречи. В рассказе была такая забавная конструкция, как групповой one2one. Оказывается, мода на one2one привела к тому, что обычные статусы, да еще в формате отчета руководителю, начали называть групповым one2one, чтобы быть в тренде.
Фасилитация:
* структурируем процесс и равномерно распределяем время на каждого
* следим за соблюдением правил и атмосферой партнерства
* управляем динамикой группы и вовлекаtм в обсуждение
* активно слушаем, резюмируем, подводим итоги.
Я тут хочу сказать, что вовлечение в обсуждение, создание атмосферы партнерства и равномерное распределение времени имеет свою ценность и свою цену. Рабочие встречи имеют цель, и задача фасилитации — обеспечить эффективное продвижение к этой цели в краткие сроки. А атмосфера — это вторично. Да, есть понятные риски, например, что мы можем не услышать чье-то ценное мнение, потому что более активные участники просто не дадут слово, и задача фасилитатора подобные риски снять. В целях встречи может быть не просто выработать решение, но и вовлечь участников встречи в дальнейшую работу по его выполнению, и тогда надо следить за принятием решения участниками, снимать проблемы отстранения. И конфликты надо переводить в конструктив, это тоже понятно. Но цель — надо держать в фокусе.
== Алсу Шайдуллина. Путеводитель по менторству в ИТ: роль, сценарии и вызовы ==
Общая часть доклада понятна. Менторы — помогают человеку идти своим путем, частое применение — на онбординге в компанию. Ментор отличается от коуча работой по предметным знаниям, а не только с мотивацией, а от наставника тем, что наставник ведет по пути, не адаптируя его. Мотивация самого ментора тоже понятна — обучая других — обучаешься сам, качаешь софтскиллы и так далее. Но вот дальше были интересные модели для разных форматов встреч. Ценность моделей в том, что они структурируют встречу, задают набор вопросов, ко которых надо подумать. Главное — относиться к ним не как к догме, которую надо соблюдать буквально, а как к рабочему инструменту. Дальше будут названия модели, содержание — гуглите, краткое можно будет посмотреть в презентации.
* Менторство начинается с первичной встречи и для нее подходит модель GROW. От себя отмечу, что модель — любопытное преломление коучами работы по целям, интересно сопоставить ее, например, с OKR и с конструкции SMART-целей.
* Для регулярных встреч есть модель OSCAR.
* В случае ситуативной встречи полезно попросить менти подготовиться по модели STAR, а ситуацию разбирать по модели SBI.
Если менторство не ограничивается испытательным сроком, то важно ставить цели и выделять этапы, а не просто рассматривать его как постоянный процесс.
Как в любой деятельности, бывают проблемы.
* Поставили цель — не подготовил. Варианты: слишком сложно, не мотивирует, устал — мы смотрим проблемы
* Менти не выполняет задания, игнорирует. Варианты: сменились приоритеты, сменились его цели, ему непонятно, а он стесняется. Проговариваем причины, корректируем работу.
* Сам ментор может быть не вовлечен по разным причинам — стоит сделать перерыв.
* Разногласия ментора и менти по подходам, особенно если у менти был негативный опыт. Это надо проговорить и адаптировать план.
* Менти пассивно ждет решение. Надо поставить время, чтобы самостоятельно.
В любом случае, важно не винить себя, если что-то пошло не так. Ошибки — случаются. Сделал паузу, проанализировал, пошел дальше. И надо помнить, что менти сам идет по пути, это — его ответственность, мы его не ведем.
== Boris Moshnin из SM Lab. Долгосрочная стабильность vs. карьерная мобильность: что лучше для профессионального развития? ==
Понятно, что однозначного ответа в докладе не было, но там был неплохой сравнительный анализ, плюсы и минусы каждой стратегии. Долгосрочная — ты погружаешься в технологию или продукт, который нравится, и стабильно работаешь с ним. Это уверенность в завтрашнем дне и много другого профита. Правда, в случае форс-мажоров можно оказаться на рынке труда с не нужными навыками. Потому что технологии стареют и могут умереть. А еще потенциально ограничение роста и возможности перемещения: ты занимаешь ценную нишу, из которой тебя не отпустят. Стратегия частых перемещений имеет свои плюcы — широкий кругозор, знакомство с новыми технологиями, наработку навыка быстрого погружения в проект, большое количество завершенных проектов, если для тебя это важно и ты выбираешь короткие проекты. Я тут хочу заметить, что деление на долгосрочную и мобильную стратегии похоже на деление дайверов и сканеров в модели Барбары Шер. Но это — типовые случаи, а жизнь разнообразнее, например, бывают стабильные стартап-команды, которые долго работают. Он сам собирался поступать на химфак, не получилось, пошел временно работать в ИТ и задержался на 8 лет, потом выучился на художника, но потом снова пошел в ИТ.
== Алексей Пименов. Как на самом деле работает механизм эволюционных изменений ==
Основной посыл доклада — что эволюция — это вовсе не медленные пошаговые изменения, которые происходят за миллионы лет, да еще сами по себе. Но для начала — проблема. Любая трансформация имеет образ светлого будущего, в котором производительность производительность возросла или качество улучшилось или еще какие-то показатели изменились. Но по пути к этому светлому будущему у нас проблемы, просадка этого показателя, когда мы разрушили старую структуру, и строим новую, а потом налаживаем ее работу. В психологии это описывается моделью Виржинии Сатир, а в командообразовании кривой Такмана, Алексей упоминал обоих. Часто терпения построить и запустить новое — не хватает, заказчик или топ прерывает процесс и ищет следующего агента изменений.
Дальше тезис: каждая такая трансформация — революция. И правильно поменять подход, вместо революционных трансформаций проводить эволюцию. Как реально устроена эволюция? В 1972 Нильс Элридж и Стивен Джей Гуд предложили теорию прерывистого равновесия, в которой резко происходят скачкообразные мутации в определенных состояниях. Пример — кембрийский взрыв, накопление кислорода в атмосфере, который сильно повернул эволюцию. Но есть вулканы, пересыхание рек, падение метеоритов — в эти периоды эволюция идет очень быстро, а потом все застывает в новом статическом состоянии. В жизни человека такие моменты — свадьбы, разводы, рождение детей, переезды, смена места работы. У компаний — смена топов, ipo, слияние и поглощение. Для государства — кризисы, войны, эпидемии — очень быстрое внедрение, в 2020 все корпорации быстро перешли на удаленку. В такие периоды идет быстрая адаптация. При этом периоды равновесия — вовсе не зона комфорта, это мы сидим голым задом на муравейнике, терпим и не уходим потому как вдруг там в другом месте будет хуже.
Эволюционный менеджмент — о том, как делать управляемую эволюцию в компании. Три такта: стрессор, рефлексия и лидерство.
Стрессор — показывает людям, что их картина мира вовсе не такая хорошая, как они думают. Например, они не считали TTM или не видели финансовую ведомость или не знали, что происходит у топов. Теперь узнали — и жизнь не будет прежней. Стрессоры бывают разные. И важно, чтобы этот стрессор реально напряг людей.
Алексей привел историю Тэтчер: у нее заканчивался первый срок, ничего особого не сделано, перспектив переизбрания — нет. Тут возникла проблема в Фолклендами, которая возникла регулярно, но решалась профилактической посылкой британского флота. А Тэтчер задерживала посылку, пока конфликт не перешел в горячую фазу, а потом выиграла войну, получив титул железной леди и переизбрания надолго. И это — провокация.
И тут есть две опасности: пережать со стрессором, так что сотрудники или заказчики побегут. А вторая — наоборот, что все посмотрят на стрессор и не испугаются.
Дальше — рефлексия. Любой стрессор имеет сроки, вы нарисовали кошмар, и он действует 3 дня, потом пойдут мысли «раньше жили так — и дальше будем». Поэтмоу важно в этот моент провести рефлексию. Собрать собрание и обсудить, что делать. И в этот момент решение можно ненавязчиво предлагать — потому что они готовы к переменам. И они будут считать, что практику они выработали сами, будут нести ответственность. При грамотной фасилитации на собрании должен родиться план.
А дальше план есть — его должен кто-то делать. Нужно лидерство, его можно взять самому или поддержать того, кто взялся.
Эволюцию по такому сценарию можно предсказать и спланировать: есть равновесие, статус-кво — проектируем стрессор, думаем про новую практику и путь к новому равновесия. Канвас Зигзаг. Самое интересное — развороты, на них проявляются риски: потери людей, верха шумят низы молчат, итальянская забастовка ненавязчиво мешать; партизанская герилья против изменений. Их надо выявлять и планировать. Индивидуально работать с людьми. У Алексея были доклады на предыдущих SQA про зигзаги, психологию и социальные методы работы с изменениями.
Техника манипулятивная, об этом был явный вопрос, и Алексей не отрицает. Потому что разъяснять — бесполезно, у людей будет все хорошо, или объяснения что новые практики не работают вплоть до реального кризиса, а тут мы проектируем заранее.
В целом конструкция понятная. Я только хочу сказать, что кривая производительности или других метрик будет та же самая, с провалом. Принципиальное отличие тут — что изменения проводит не внешний агент, который грудью на амбразуру, агент лишь указывает проблемы, а дальше сама команда придумывает и осуществляет изменения. А что идея была фасилитирована — не проявляется.
== Ирина Баржак. Менеджмент конфликтов ==
Доклад учит тому, как не принимать чужую ругань и агрессию на свой счет, как не терять спокойствие, а работать с ситуацией конструктивно. Для этого надо держать такую позицию: агрессия другого человека — всегда проявление его собственных проблем и конфликтов, а ты просто подвернулся ему, чтобы этот негатив вылить. И ничего личного в этом нет. Говорить ему об этом — точно нельзя, конфликт становится нерешаемым. А надо, исходя из этого, не обижаться, не плакать и не идти на встречную агрессию, а действовать по такому алгоритму:
1. Сохранить спокойствие
2. Записывать ключевые слова — он говорит о своей внутренней боли, и ключевые слова это выдают. Если заказчик говорит, что вы не умеет управлять проектами, то ты записываешь: проверить, кто с их стороны управляет проектами и насколько он это умеет.
3. Использовать эти слова в своих интересах.
4. Задавать вопросы. Почему, на каком основании вы решили, что помешало сделать выбор и так далее. Вместо сопротивления — разбираешься. Не молчишь принимая вину.
5. Использовать технику трех да. Не говорить «это невозможно, так никто не делает». Они считают, что вы некомпетентны, найдут других. Потому что «невозможно» — это лишение выбора, и это лишает выбора. И реально в большинство идей — возможно, только дорого, долго, надо искать человека. И надо говорить «это возможно, но потребует этого или этого» — у человека появляется выбор, и он конструктивно мыслит над задачей.
Позиция конфликтолога: переделать других людей не получится. Надо работать с собой. Первое чему учишься — молчать и использовать чужие проблемы в своих целях. Отмечу, что это — чисто манипулятивная техника получается. Понятно, откуда она возникла у конфликтологов: в традиционных корпорациях с политическими играми иначе просто нельзя. И в семьях из слабой позиции тоже не очень перспективно, а люди с сильной позицией к конфликтологам не часто ходят, они сами справляются. Но насколько правильно ее применять повсеместно для меня вопрос открытый.
И помнить, что в обратную сторону это тоже работает. Если вы на кого-то кричите — это проекция вашего внутреннего конфликта. Если говорите спокойно — ОК. А если кричите — это ваш внутренний конфликт и вам его решать.
Конкретно про обесценивание, которое часто проявляется в коммуникации. Это функция психики, которая позволяет справиться с фрустацией, когда произошел резкий отказ. Еще у детей: когда отвергли, старшие не взяли в игру и так далее. И утт идея «не больно то и хотелось и игра у вас дурацкая». Секунду назад хотелось, а теперь — вот так, психика сработала и сняла боль. А потом с каждым отказом это фиксируется, и не доходит до сознания, идет на автомате, видишь что-то — и сразу обесцениваешь.
В целом у меня сложное отношение к этому докладу. Он точно актуален для достаточно большого количества людей, которые сталкиваются с агрессией и обесцениванием разного вида и не умеют этому противостоять. Хотя в ИТ на нынешнем дефицитном рынке персонала это, наверное, не так часто встречается, но все равно актуально. Но, с другой стороны такой подход потенциально закрывает человека для любой обратной связи, даже конструктивной. Потому что распространенное искажение восприятия — когда человеку говорят о проблемах, то он думает «это на меня наезжают, просто делают это вежливо, чтобы не было претензий». Фактически, такой подход пестует основную ошибку атрибуции, в просторечии «все уроды, а я Дартаньян», а зачем слушать обратную связь от уродов, пытаться их понять. А люди, которые уже мыслят «есть моя точка зрения и неправильная» тоже встречаются достаточно часто, может быть не реже, чем те, кто терпит чужую агрессию. А их доклад будет укреплять в выбранной позиции. Так что, на мой взгляд, тут не хватает баланса.
= Максим Цепков. Системное мышление: что это и зачем нужно тестировщику? =
Мой доклад [[Системное мышление: что это и зачем нужно тестировщику? (SQAdays-2024)|'''Системное мышление: что это и зачем нужно тестировщику?''']] продолжал тему, которую я начал на AnalystDays: зачем ИТ-шнику нужно системное мышление, почему ему недостаточно специализированных моделей, таких как с4-model или описания бизнес-процессов. В этом докладе приземление было на задачи тестировщика. При этом я рассказывал реальные кейсы, в которых отдельно выделял — в чем именно здесь проявляется системное мышление. Сложность в том, что дать системное представление о системном мышлении в рамках доклада — невозможно. Мойе задачей было показать метод и побудить к его дальнейшему изучению.
= Про тестирование =
== Александр Ткачев из ГНИВЦ. Сказ об автотестах Windows-приложения ==
Потрясающая форма доклада — сказание в стихах в стиле сказки про Федота-стрельца. И это надо слушать и получать удовольствие. При этом содержательно в докладе — подробный рассказ о создании автотестов под Windows с вставками в прозе, в которых разбираются технические подобности:
1. Создание автотестов — техстек, особенности настройки драйвера, которому правильно передавать root, а не окно приложения чтобы иметь доступ к всяким нотификациям и служебным окнам windows, используемым, например, при сохранении. Они использовали python + behave (bdd на gherkin) + appium + allure report. gherkin выбран потоvу, что можно писать русские аннотации, а это позволило использовать готовые тест-кейсы. Для поиска элементов приложения по свойствам используется inspect, тут у windows свои особенности, с которыми надо разбираться, набор свойств? который разработчик видит в ide не слишком соответствует тому, что показывает inspect, так что даже там, где разработчики могут что-то добавить, получается не так просто. ActionChains аналогичны web и мобилкам, можно несколько объединять в одно действие, но нет простого скроллинга, можно скролить до элемента, что неудобно или pgup-pgdn.
2. Запуск автотестов на виртуалке — есть особенности, в том числе, чтобы автотесты продолжали выполняться, когда ты от виртуалки отключился, чтобы это не требовало физической работы твоей машины, которая держит сеанс. Там магия, в презентации она раскрыта. Если нужно использовать разные учетки — то с помощью psexec запускаешь драйвер автотестов под нужной учеткой, он запустит все остальное.
3. Как работать с элементами, если они не парсятся, например в кастомной форме. Координатный метод — ищем кусочек изображения, распознаем текст. Не слишком стабильные методы, коминируем, чтобы было стабильно. Есть скрины, есть вариант, что надо в заголовке окна проверить переменный текст, например ИНН — распознаем текст. Бывает ищем кнопку, потом считываем текст, проверяя, что нужная кнопка. Если цветовое выделение — ищем элемент, берем писксел, сравниваем цвет. Это кроссплатформенно, не зависит от технологий реализации, быстрое распознавание — часто быстрее, чем find element.
4. Встройка в CI/CD и процесс в целом. И тут помогает как раз то, что BDD фреймворк, использовали тест кейсы, которые уже есть, ручные тестировщики продолжили их писать, просто шаги — из меню вариантов, а не произвольные, и эти тест-кейсы есть в jira. А дальше автоматизаторы делают из этого автотесты. И это включается в общий цикл. По результатам тестов — рассылка в почте и отчет в allure.
== Владимир Техтилов из BelkaCar. Self-healing скриншот-тесты: тесты для ленивых ==
Идея — с помощью скриншот тестов можно достаточно просто автоматически проверять, что поведение UI не изменилось: берем сохраняем экраны и потом сравниваем. И они сделали первую версию тестов на python + playwrite + pixel match. Попробовали с ней жить — и выяснили, что есть проблема с обновлением эталонных экранов. Они меняются в ходе разработки, а для воспроизведения ты должен снять скриншот ровно в том же окружении, что будет при выполнении теста — разрешение экрана, модель браузера и так далее. Обновление оказалось трудоемким, и через некоторое время вернулись к функциональным тестам. Но через некоторое время проект обрел второе дыхание — сделали скрипт, который позволял одной кнопкой порождать весь набор скриншотов за счет запуска тестов в специальном режиме, когда изображения не сравниваются, а создаются новые. Это сделано на основе CI/CD, у них gitlab, но есть аналоги для других. Скриншоты красиво раскладываются по папкам, в зависимости от места в тесте, и дальше создается merge request на обновление тестов. В таком виде оно взлетело и летит.
В целом — понятно. Про аналогичную задачу был доклад год назад на SQAdays от 2GIS, где была задача получить скрины под все разрешения и версии браузеров, чтобы проверять работоспособность UI ([[SQAdays-2023b|мой конспект]]). А еще весной 2012 я слушал доклад, где тоже разбирали тестирование по изображениям. Там проблема была иной: desktop приложение запускалось через citrix, поэтому вместо элементов экрана, на которых опираются при тестировании, у тебя просто картинка. С этого доклада у меня тоже есть [[SQAdays-2012ab|конспект]]. И можно сравнить — что поменялось в подходах за столько лет.
== Александр Кидяев и Дмитрий Сорокин из ГНИВЦ. ЕГР ЗАГС. Трансформация стратегии тестирования во время перехода системы с монолита на микросервисы ==
ЕГР ЗАГС — монолитная система, обеспечивающая работу ЗАГС о всей стране. внедренная вместо разрозненной автоматизации на местах. Развитие столкнулось с ограничениями и было решено сделать вторую версию на микросервисах. Но при этом обеспечить мягкий переход с параллельной эксплуатацией обоих систем. Разработку новой системы ведут несколько команд, у каждой — свой пул микросервисов. а команда тестирования — общая, и в ее ответственности и старая и новая системы. Рассказ был про изменение подходов, которое было призвано обеспечить качество. Вот новые практики.
* Встреча 5 амиго для обсуждения новых фич: разработчик, QA, аналитик, архитектор, заказчик. Из этих встреч — поток информации о том. что будет сделано.
* Тестирование требований, которые ведут в confluence
* Центр компетенций тестирования: поиск решений и лучших практик
* Сразу закладывают нагрузочное тестирование, в старой версии были только отчеты. И автоматизация тестирования.
* DoD и DoR для задач со стороны тестирования. Утверждены как регламенты, и это выручает по срокам — неподготовленные задачи не идут.
* Попарное тестирование — оно работает хорошо
* Начали смотреть изменения в законах. В одном проекте Минюста увидели изменения, которые сильно конфликтуют в текущим функционалом системы, дали обратную связь — и Минюст поменял проект.
* Участие в ПСИ и демо приносит практическую пользу
Про боли.
* Не стоит писать кейсы до реализации нового функционала. Потому что его выкатили, через неделю изменился, через неделю еще изменился, и ты несколько раз актуализируешь тесты.
* Пиковые нагрузки. Команды работают независимо, релиз ЗАГС-1 вышибает команду на неделю, и если в это время кончается спринт у ЗАГС-2 получается перенапряжение, это надо разруливать.
== Андрей Романюк из Okko. Релиз без сюрпризов: как мы уменьшили количество багов в проде ==
Основная идея доклада — переход от субъективно выставляемого приоритета бага к count — объективной оценке его влияния, которая получается как произведение охвата пользователей на барьерность бага и на 10000, чтобы получить целое число (охват и критичность считают в процентах). Охват зависит от сценария, в котором проявляется баг, для каждого из сценариев известна частота их использования пользователями: главную страницу открывает 90 %, а авторизацию всего 11 %, потому что авторизовались — и она запомнена. Охват обновляют раз в месяц. А барьерность варьируется от 1 %, например, для всплывающего окна, которое повисит и исчезнет через 3 секунды, до 100 % если блокируется запуск фильма, и еще один коэффициент — доля устройств, на которых баг проявляется, одни баги проявляются во всех версиях, а другие могут быть, например, только на телевизорах. Сount дает объективное влияние бага.
Они считают Count для текущего состояния прода, а также для новых фич, в которых часто баги исправлены не полностью. И договорились, что Count > 100 — ситуация, которой допускать не хотят. Поэтому если появляется сырой релиз, то выходят предрелизные фичи-предупреждения. Продукт все равно может взять на себя ответственность за выпуск такого релиза, но обычно релиз задерживают. Раньше тоже были ситуации сырого релиза, но поскольку объективного показания влияния бага на пользователей не было, то продукты чаще всего принимали решение релиз выкатывать. В результате на проде багов с count > 100 практически нет. Статистика в целом улучшилась, но не сильно, так как баги с меньшим count пропускают.
Был интересный вопрос: зачем вы берете на себя доказательство, что релиз не надо катить? Ответ: продукты не понимают влияние бага, им кажется, что это фигня. А любой баг на проде воспринимают как ошибку тестирования. Предрелизы — подсвечивают и показывают чья ответственность, и каков размер проблемы.
== Павел Владимиров. Meta-Prompting и агенты: выжимаем максимум из ChatGPT ==
Для начала было немного базовой терминологии, и тут для меня было интересен параметр вероятности, определяющий как GPT ищет ответ: перебором до достижения требуемой вероятности, или просто на заданную глубину. И параметр температуры, который задает креативность ответа, сводящуюся к тому, что для ответа выбирается не самый вероятный из вариантов продолжения разговора, а другой.
А дальше был рассказ про промпты, начиная с простых, когда в запросе дают один или несколько примеров ответа (one shot или few shots) к более сложным. В chain-of-thought ты просишь дать цепочку рассуждений, тем самым GPT разлагает сложную задачу на несоклько простых, ответ для которых находит с большей вероятностью. Contextual prompting задает контекст, который надо учитывать для ответа. Ask before answer явно просит задать дополнительные вопросы для уточнения ответа, в этом случае GPT сначала вытянет контекст у пользователя.
Еще GPT умеет собирать команду агентов, которые коллективно решают задачу, находясь в разных позициях. Но при этом есть ограничения, связанные с тем, что такой подход очень быстро накапливает контекст, и может выйти за ограничения, прервав формирование ответа. И есть схема метапромптинг, когда есть оркестратор, который накапливает контекст, и спрашивает экспертов, которые контекста не запоминают, это экономит ресурсы.
Отмечу, что на конференции было много докладов про Это один из рассказов про работу GPT, но я был только на одном из них.
== Лариса Ковалевская из Авито. Как мы меняли процессы с помощью Team Maturity Model, чтобы максимально качать качество ==
Любопытный доклад. Рассказ был про команду Авито-путешествия, которая переходила из режима стартап-разработки, в котором критерием качества является совесть разработчиков, метрики не используются, а баги правятся на личном взаимодействии службы сопровождения и разработки, к регулярному процессу с мониторингом через метрики, разбором накопленных багов, покрытием тестами и другими регулярными практиками.
В чем особенность этого кейса? В авито есть модель зрелости команд, Team Maturity Model, определяемая через опросник, по которой каждый квартал команда проходит аудит. Там есть блок качества, и на входе показатели были 29 % при baseline 80 %, и было много других наблюдаемых проблем, например, накопившийся бэклог багов. Команда начала работу над качеством, не разбираясь детально с моделью зрелости, а, так сказать, из общих соображений. Внедрили практику оценки задач 3 амиго (обсуждение на входе аналитиком, разработчиком, тестировщиком), ручные и приемочные тесты, тест-дизайн и продакт-приемка, внедрение SLA по общению с пользователями и ревью бэклога багов. Ситуация улучшилась. Но TMM получился всего 60 % вместо ожидаемых 80. И тогда команда пошла разбираться в структуре блока QA в TMM. И обнаружила там те практики, с которыми у них плохо: отсутствие DoD и DoR, низкое тестовое покрытие, неактуальная тестовая модель, отсутствие работы с рисками и другие. И поставила квартальные цели по обеспечению этих показателей — писать DoD и DoR в задачах, написать тестовое покрытие — оно было декомпозировано до конкретных задач по покрытию сценариев, и так далее. И выполнило задачи, получив TMM 80 %.
TMM авито опубликован, в докладе была ссылка, а я нашел статью здесь (https://habr.com/ru/companies/avito/articles/578342/).
Но вот вопрос, дало ли это что-то реально, пользователям продукта и компании — не раскрыт. Почему TMM по качеству именно такая, в чем ценность именно этих таких показателей? Об этом в докладе не было, TMM представлялся как абсолютный идеал. И вот у меня такой рассказ вызвал воспоминание о сборах в армии, когда наряду с полезными знаниями нас учили красиво и быстро заправлять кровати, а также готовили к маршу в ногу и с песней. И эта составляющая была не менее важная, чем содержательная подготовка. В армии это имеет давнюю традицию с Павла I, который это копировал у Фридриха Великого. При этом у Фридриха была содержательная цель, он использовал как часть боевой подготовки, а Павел — лишь для парадов. Чем достижение TMM в 80 % отличается от требований идеально маршировать на параде? И ясно ли это команде, или они видят тут некоторый ритуал — непонятно. Из доклада это неясно.
= Про менеджмент и soft skill =
== Лидия Рогова. Конфликты восприятия или ТОП-5 инструментов для налаживания коммуникации ==
Доклад вызвал размышления: те техники, которые Лидия давала — просты, и кажется, что это — базовый уровень, ими должен владеть каждый. Но они востребованы, люди до этого базового уровня не дотягивают, и возникает вопрос — почему? Еще отмечу, что, на мой взгляд, часть материала была слишком упрощена, все-таки реальный процесс — сложнее. А какие-то вещи, представляя собой распространенные практические приемы, опираются на ложные основания, и вот стоит ли их давать, не задумываясь об этих основаниях — вопрос для меня открытый.
А теперь, после такой преамбулы — краткое содержание доклада с моими комментариями. Замечательно, что доклад начался с фокусировки слушателей: личная цель мероприятия, почему важно для меня лично, что хочу получить как результат; как в конце пойму, что получил. На это была дана пара минут, я, я думаю, что для слушателей была польза от такой фокусировки на всю конференцию. Потому как далеко не всегда об этом думают. А в конце доклада был такт — подумать и оценить — продвинулись или нет.
Дальше — цитата из Галилея: человека нельзя научить, можно помочь найти это в себе. Позиция известна, на ней основаны многие техники коучей. Только надо понимать, что это — идеалистический взгляд, основанный на том, что у человека есть нематериальная душа или аналогичная субстанция, которая при рождении получила хостинг в нашем теле на время жизни, и которая уже содержит все наши знания. Или, в другой парадигме — есть генетический код, в нем все записано. А реально природа для млекопитающих перешла от программирования в генетическом коде к обучению личным опытом. Которое человек дополнил обучением через теоретическое знание, через книги. А про душу — достоверная информация о знаниях, в нее заложены — отсутствуют. В докладе тема дальше не развивалась.
Коммуникация:
* вербальная: устная и письменная;
* невербальная — мимика и жесты;
* паравербальная — тон, интонации, темп, паузы, смех
Коммуникация важна, ее хотят перевести в хард-скиллы, включить в образование. Я тут замечу, что в Древнем Риме так уже было — риторика входила в базовое образование, а с тех пор куда-то потерялось.
Проблемы коммуникация связаны с тем, что одни и те же слова могут быть по-разному интерпретированы, и потому понимают вовсе не то, что имел ввиду говорящий. А дальше возникают обиды. Например, эффективно работать может означать, что надо больше заработать для компании, а не сделать больше задач. Или человек старался сделать красиво, породил 5 вариантов, все не понравились. Или сказали сделать срочно, он не спал всю ночь, а утром сказали «посмотрим позднее» — наверное, срочность была не столь велика. В общем, кейсы — понятные, но я бы не сказал, что все они связаны именно с интерпретацией слов. Часть ситуаций связаны с неверными ожиданиями, которые вовсе не обязательно обусловлены словами в коммуникации, они связаны с различными представлениями о жизни, разным домысливанием ситуации. С той же красотой — проблема могла быть не в оформлении, а в смысловом содержании, например.
Вообще домысливание за другого, при которой ты принимаешь что-то на свой счет — распространенная ошибка. Например, руководитель утром не спросил про котика, хотя обычно это делает, и ты думаешь, что он тобой недоволен. А реально у него могут быть совсем другие проблемы дома или озабоченность рабочей встречей или что-то еще. Или наоборот, со стороны руководителя недовольство командой. потому что они плохо работают, хотя это он ставит нереалистичные задачи и так далее.
Все это конфликты восприятия. И тут важно не обижаться, замыкаясь в себе, и не обсуждать кто круче, а выходить в коммуникацию, уточняя ситуацию, и мысля конструктивно. Доносить объективность ситуации, рассказывать, про свою работу, если с ней есть проблемы. Подходить к ситуации разумно: если руководитель пришел с вопросом, а ответ требует обдумывания и работы с материалами — то сказать об этом, а не стараться как-нибудь ответить немедленно.
Я тут хочу дополнить: при разборе таких конфликтов важно держать фокус целей работы, при этом уточнять интерпретацию этих целей, потому что она может различаться. При этом на путь к целям могут быть разные точки зрения, это нормально, и разделение ответственности может быть различным, но объединяющие цели при этом позволяют искать варианты, идти в конструктивное обсуждение.
Инструменты по коммуникации.
* Активное слушание. Заинтересованно слушаем собеседника, не решаем собственные задачи. Кивать, угукать, агакать.
* Фактичность. Мыслить фактами, а не эмоциями и субъективными оценками. Коучи любят вопрос «а что ты сейчас чувствуешь?» Очень важно разделять.
* Я-позиция. Не быть токсиком, не говорить что кто-то сделал неправильно, а передавать позицию из своего опыта: «Я закрываю таски за день, потому что если их закрывать дольше, это может сказаться на отношении заказчика, не стоит так делать» вместо «вы долго закрываете таски, надо быстрее». Высказывая мнение, не задевать чувства другого человека. Уметь воспринимать себя и свое мнение, при этом слышать других и понимать, что оно другое, а не неверное.
* Делегирование. Это проблема всех руководителей, а не только начинающих. Усталость «почему я за них всегда все делаю» — типичное.
* Групповые встречи и навыки фасилитации. Это — важно. Обозначить повестку, модерировать. Форматы — разные (master mind, обмен опытом, one2one в том числе групповой). Командная встреча — ведет к цели команды. Групповая встреча — общая тематика и личные цели.
По инструментам в ходе рассказа были приемчики.
Фактичность. С вами поругались, обесценили ваши задачи. Вы приходите, сели в уголок, и представли себя мухой на стекле. Муха не знает, что такое чувство, она мыслит фактами. Муха видит, что мужчина машет руками. Муха не может понять поняла, что женщина расстроилось, а мужчина зол. Она может слышать, что женщина стала говорить громче. Если так разобрать ситуацию, что про многие конфликты можно увидеть, что они несерьезны, тут домыслы.
Делегирование. Признаки проблемы: постоянная текучка в команде, все приходится делать, неясно кто за что отвечает. А на уровне самооценки — убеждение «я всегда сделаю быстрее», или «подчиненные сделают хуже, руководитель будет недоволен», и с такие убеждения надо менять. В докладе не было — как менять, так что поделюсь своим: работает трезвая оценка результативности команды, потому что руководитель, который все делает сам, является ограничением для команды. Понятно, что может быть стратегия героя пожарника-поджигателя: сам поджег, сам потушил — герой. Но если посмотреть рационально, то команда может сделать больше, чем один, и этот результат стоит того, чтобы научиться делегировать.
Делегирование — процесс передачи ответственности (не функций), с постановкой целей для достижения.
Как добиться делегирования?
* ставить цели, а не задачи, и определять результат
* анализировать полученные результаты и обсуждать выводы
* тратить время на верхнеуровневую коммуникацию
* мотивировать свою команду
* цели должны соответствовать уровню исполнителя и соразмерны уровню ответственности
Я тут хочу дополнить. Про делегирование есть модель ситуационного лидерства (надо смотреть первую версию модели, вторая — о другом). Если у вас команда джунов, которые пока не могут сделать самостоятельно, то по пути к делегированию надо пройти от режима поручений directing к режиму coaching, в котором ты учишь человека вырабатывать план действий и далее в режим supporting, когда ты учишь во-время звать на помощь при проблемах. А надежда, что делая задачу за задачей по поручениям сотрудник сам научится делать, конечно, имеет основания, но опыт средневекового обучения мастерству говорит, что на это нужно примерно 7-10 лет.
Про встречи. В рассказе была такая забавная конструкция, как групповой one2one. Оказывается, мода на one2one привела к тому, что обычные статусы, да еще в формате отчета руководителю, начали называть групповым one2one, чтобы быть в тренде.
Фасилитация:
* структурируем процесс и равномерно распределяем время на каждого
* следим за соблюдением правил и атмосферой партнерства
* управляем динамикой группы и вовлекаtм в обсуждение
* активно слушаем, резюмируем, подводим итоги.
Я тут хочу сказать, что вовлечение в обсуждение, создание атмосферы партнерства и равномерное распределение времени имеет свою ценность и свою цену. Рабочие встречи имеют цель, и задача фасилитации — обеспечить эффективное продвижение к этой цели в краткие сроки. А атмосфера — это вторично. Да, есть понятные риски, например, что мы можем не услышать чье-то ценное мнение, потому что более активные участники просто не дадут слово, и задача фасилитатора подобные риски снять. В целях встречи может быть не просто выработать решение, но и вовлечь участников встречи в дальнейшую работу по его выполнению, и тогда надо следить за принятием решения участниками, снимать проблемы отстранения. И конфликты надо переводить в конструктив, это тоже понятно. Но цель — надо держать в фокусе.
== Алсу Шайдуллина. Путеводитель по менторству в ИТ: роль, сценарии и вызовы ==
Общая часть доклада понятна. Менторы — помогают человеку идти своим путем, частое применение — на онбординге в компанию. Ментор отличается от коуча работой по предметным знаниям, а не только с мотивацией, а от наставника тем, что наставник ведет по пути, не адаптируя его. Мотивация самого ментора тоже понятна — обучая других — обучаешься сам, качаешь софтскиллы и так далее. Но вот дальше были интересные модели для разных форматов встреч. Ценность моделей в том, что они структурируют встречу, задают набор вопросов, ко которых надо подумать. Главное — относиться к ним не как к догме, которую надо соблюдать буквально, а как к рабочему инструменту. Дальше будут названия модели, содержание — гуглите, краткое можно будет посмотреть в презентации.
* Менторство начинается с первичной встречи и для нее подходит модель GROW. От себя отмечу, что модель — любопытное преломление коучами работы по целям, интересно сопоставить ее, например, с OKR и с конструкции SMART-целей.
* Для регулярных встреч есть модель OSCAR.
* В случае ситуативной встречи полезно попросить менти подготовиться по модели STAR, а ситуацию разбирать по модели SBI.
Если менторство не ограничивается испытательным сроком, то важно ставить цели и выделять этапы, а не просто рассматривать его как постоянный процесс.
Как в любой деятельности, бывают проблемы.
* Поставили цель — не подготовил. Варианты: слишком сложно, не мотивирует, устал — мы смотрим проблемы
* Менти не выполняет задания, игнорирует. Варианты: сменились приоритеты, сменились его цели, ему непонятно, а он стесняется. Проговариваем причины, корректируем работу.
* Сам ментор может быть не вовлечен по разным причинам — стоит сделать перерыв.
* Разногласия ментора и менти по подходам, особенно если у менти был негативный опыт. Это надо проговорить и адаптировать план.
* Менти пассивно ждет решение. Надо поставить время, чтобы самостоятельно.
В любом случае, важно не винить себя, если что-то пошло не так. Ошибки — случаются. Сделал паузу, проанализировал, пошел дальше. И надо помнить, что менти сам идет по пути, это — его ответственность, мы его не ведем.
== Boris Moshnin из SM Lab. Долгосрочная стабильность vs. карьерная мобильность: что лучше для профессионального развития? ==
Понятно, что однозначного ответа в докладе не было, но там был неплохой сравнительный анализ, плюсы и минусы каждой стратегии. Долгосрочная — ты погружаешься в технологию или продукт, который нравится, и стабильно работаешь с ним. Это уверенность в завтрашнем дне и много другого профита. Правда, в случае форс-мажоров можно оказаться на рынке труда с не нужными навыками. Потому что технологии стареют и могут умереть. А еще потенциально ограничение роста и возможности перемещения: ты занимаешь ценную нишу, из которой тебя не отпустят. Стратегия частых перемещений имеет свои плюcы — широкий кругозор, знакомство с новыми технологиями, наработку навыка быстрого погружения в проект, большое количество завершенных проектов, если для тебя это важно и ты выбираешь короткие проекты. Я тут хочу заметить, что деление на долгосрочную и мобильную стратегии похоже на деление дайверов и сканеров в модели Барбары Шер. Но это — типовые случаи, а жизнь разнообразнее, например, бывают стабильные стартап-команды, которые долго работают. Он сам собирался поступать на химфак, не получилось, пошел временно работать в ИТ и задержался на 8 лет, потом выучился на художника, но потом снова пошел в ИТ.
== Алексей Пименов. Как на самом деле работает механизм эволюционных изменений ==
Основной посыл доклада — что эволюция — это вовсе не медленные пошаговые изменения, которые происходят за миллионы лет, да еще сами по себе. Но для начала — проблема. Любая трансформация имеет образ светлого будущего, в котором производительность производительность возросла или качество улучшилось или еще какие-то показатели изменились. Но по пути к этому светлому будущему у нас проблемы, просадка этого показателя, когда мы разрушили старую структуру, и строим новую, а потом налаживаем ее работу. В психологии это описывается моделью Виржинии Сатир, а в командообразовании кривой Такмана, Алексей упоминал обоих. Часто терпения построить и запустить новое — не хватает, заказчик или топ прерывает процесс и ищет следующего агента изменений.
Дальше тезис: каждая такая трансформация — революция. И правильно поменять подход, вместо революционных трансформаций проводить эволюцию. Как реально устроена эволюция? В 1972 Нильс Элридж и Стивен Джей Гуд предложили теорию прерывистого равновесия, в которой резко происходят скачкообразные мутации в определенных состояниях. Пример — кембрийский взрыв, накопление кислорода в атмосфере, который сильно повернул эволюцию. Но есть вулканы, пересыхание рек, падение метеоритов — в эти периоды эволюция идет очень быстро, а потом все застывает в новом статическом состоянии. В жизни человека такие моменты — свадьбы, разводы, рождение детей, переезды, смена места работы. У компаний — смена топов, ipo, слияние и поглощение. Для государства — кризисы, войны, эпидемии — очень быстрое внедрение, в 2020 все корпорации быстро перешли на удаленку. В такие периоды идет быстрая адаптация. При этом периоды равновесия — вовсе не зона комфорта, это мы сидим голым задом на муравейнике, терпим и не уходим потому как вдруг там в другом месте будет хуже.
Эволюционный менеджмент — о том, как делать управляемую эволюцию в компании. Три такта: стрессор, рефлексия и лидерство.
Стрессор — показывает людям, что их картина мира вовсе не такая хорошая, как они думают. Например, они не считали TTM или не видели финансовую ведомость или не знали, что происходит у топов. Теперь узнали — и жизнь не будет прежней. Стрессоры бывают разные. И важно, чтобы этот стрессор реально напряг людей.
Алексей привел историю Тэтчер: у нее заканчивался первый срок, ничего особого не сделано, перспектив переизбрания — нет. Тут возникла проблема в Фолклендами, которая возникла регулярно, но решалась профилактической посылкой британского флота. А Тэтчер задерживала посылку, пока конфликт не перешел в горячую фазу, а потом выиграла войну, получив титул железной леди и переизбрания надолго. И это — провокация.
И тут есть две опасности: пережать со стрессором, так что сотрудники или заказчики побегут. А вторая — наоборот, что все посмотрят на стрессор и не испугаются.
Дальше — рефлексия. Любой стрессор имеет сроки, вы нарисовали кошмар, и он действует 3 дня, потом пойдут мысли «раньше жили так — и дальше будем». Поэтмоу важно в этот моент провести рефлексию. Собрать собрание и обсудить, что делать. И в этот момент решение можно ненавязчиво предлагать — потому что они готовы к переменам. И они будут считать, что практику они выработали сами, будут нести ответственность. При грамотной фасилитации на собрании должен родиться план.
А дальше план есть — его должен кто-то делать. Нужно лидерство, его можно взять самому или поддержать того, кто взялся.
Эволюцию по такому сценарию можно предсказать и спланировать: есть равновесие, статус-кво — проектируем стрессор, думаем про новую практику и путь к новому равновесия. Канвас Зигзаг. Самое интересное — развороты, на них проявляются риски: потери людей, верха шумят низы молчат, итальянская забастовка ненавязчиво мешать; партизанская герилья против изменений. Их надо выявлять и планировать. Индивидуально работать с людьми. У Алексея были доклады на предыдущих SQA про зигзаги, психологию и социальные методы работы с изменениями.
Техника манипулятивная, об этом был явный вопрос, и Алексей не отрицает. Потому что разъяснять — бесполезно, у людей будет все хорошо, или объяснения что новые практики не работают вплоть до реального кризиса, а тут мы проектируем заранее.
В целом конструкция понятная. Я только хочу сказать, что кривая производительности или других метрик будет та же самая, с провалом. Принципиальное отличие тут — что изменения проводит не внешний агент, который грудью на амбразуру, агент лишь указывает проблемы, а дальше сама команда придумывает и осуществляет изменения. А что идея была фасилитирована — не проявляется.
== Ирина Баржак. Менеджмент конфликтов ==
Доклад учит тому, как не принимать чужую ругань и агрессию на свой счет, как не терять спокойствие, а работать с ситуацией конструктивно. Для этого надо держать такую позицию: агрессия другого человека — всегда проявление его собственных проблем и конфликтов, а ты просто подвернулся ему, чтобы этот негатив вылить. И ничего личного в этом нет. Говорить ему об этом — точно нельзя, конфликт становится нерешаемым. А надо, исходя из этого, не обижаться, не плакать и не идти на встречную агрессию, а действовать по такому алгоритму:
1. Сохранить спокойствие
2. Записывать ключевые слова — он говорит о своей внутренней боли, и ключевые слова это выдают. Если заказчик говорит, что вы не умеет управлять проектами, то ты записываешь: проверить, кто с их стороны управляет проектами и насколько он это умеет.
3. Использовать эти слова в своих интересах.
4. Задавать вопросы. Почему, на каком основании вы решили, что помешало сделать выбор и так далее. Вместо сопротивления — разбираешься. Не молчишь принимая вину.
5. Использовать технику трех да. Не говорить «это невозможно, так никто не делает». Они считают, что вы некомпетентны, найдут других. Потому что «невозможно» — это лишение выбора, и это лишает выбора. И реально в большинство идей — возможно, только дорого, долго, надо искать человека. И надо говорить «это возможно, но потребует этого или этого» — у человека появляется выбор, и он конструктивно мыслит над задачей.
Позиция конфликтолога: переделать других людей не получится. Надо работать с собой. Первое чему учишься — молчать и использовать чужие проблемы в своих целях. Отмечу, что это — чисто манипулятивная техника получается. Понятно, откуда она возникла у конфликтологов: в традиционных корпорациях с политическими играми иначе просто нельзя. И в семьях из слабой позиции тоже не очень перспективно, а люди с сильной позицией к конфликтологам не часто ходят, они сами справляются. Но насколько правильно ее применять повсеместно для меня вопрос открытый.
И помнить, что в обратную сторону это тоже работает. Если вы на кого-то кричите — это проекция вашего внутреннего конфликта. Если говорите спокойно — ОК. А если кричите — это ваш внутренний конфликт и вам его решать.
Конкретно про обесценивание, которое часто проявляется в коммуникации. Это функция психики, которая позволяет справиться с фрустацией, когда произошел резкий отказ. Еще у детей: когда отвергли, старшие не взяли в игру и так далее. И утт идея «не больно то и хотелось и игра у вас дурацкая». Секунду назад хотелось, а теперь — вот так, психика сработала и сняла боль. А потом с каждым отказом это фиксируется, и не доходит до сознания, идет на автомате, видишь что-то — и сразу обесцениваешь.
В целом у меня сложное отношение к этому докладу. Он точно актуален для достаточно большого количества людей, которые сталкиваются с агрессией и обесцениванием разного вида и не умеют этому противостоять. Хотя в ИТ на нынешнем дефицитном рынке персонала это, наверное, не так часто встречается, но все равно актуально. Но, с другой стороны такой подход потенциально закрывает человека для любой обратной связи, даже конструктивной. Потому что распространенное искажение восприятия — когда человеку говорят о проблемах, то он думает «это на меня наезжают, просто делают это вежливо, чтобы не было претензий». Фактически, такой подход пестует основную ошибку атрибуции, в просторечии «все уроды, а я Дартаньян», а зачем слушать обратную связь от уродов, пытаться их понять. А люди, которые уже мыслят «есть моя точка зрения и неправильная» тоже встречаются достаточно часто, может быть не реже, чем те, кто терпит чужую агрессию. А их доклад будет укреплять в выбранной позиции. Так что, на мой взгляд, тут не хватает баланса.
