Shoo and Endless Agony

QA Maturity Models are broken by design В реакциях к прошлому посту произошел взрыв лайков, оказалось всем интересно послушать про QA maturity. Долго думал в каком формате это всё делать, что бы это было информативно и полезно. В результате собрал царь-лонгрид, не просто с моими мыслями на этот счёт, но и с возможностью самому немного покрутить типовые maturity models, посмотреть что это из себя представляет и как работает. TL;DR: Проблемы с QA Maturity Models начинаются с самого термина maturity. "Зрелость процессов" воспринимается командами и менеджментом как что-то безусловно классное. Все хотят себе зрелые QA процессы, а зрелые QA процессы определенно работают лучше, чем незрелые. На практике под maturity подразумевается стандартизация, формализация и условный adoption стандартных практик, инструментов и артефактов. Даже если это идёт в ущерб интересам команды или задачам бизнеса. Большинство матюрити моделей создавались под вполне конкретный контекст, специфику и задачи. И никакой другой контекст там не учитывается и, будем честны, довольно слабо вписывается в эти модели. Существует какое-то количество адаптаций maturity моделей под аджайл, скрам, лин и прочее, но в большинстве случаев это про замену одних названий практик на другие, а не структурные изменения. Матюрити модели очень сильно смещают фокус внимания. Здорово, когда этот сдвиг происходит в нужную вам сейчас сторону, не здорово - когда наоборот, вещи которые важны выпадают из поля зрения, потому что "более зрелые процессы этого не требуют". И, наверное, самая большая проблема: в рамках моделей внедрение инструментов, создание артефактов и использование тех или иных практик - это самоцель. Не способ улучшить качество. Не способ закрыть боли и запросы команды. Это что-то ценное само по себе. Есть тест план - хорошо, нет тест плана - плохо. Даже если ни тебе, ни команде, ни бизнесу этот тест план не нужен. Список, на самом деле, получился довольно большой. Вариантов того, что с этим можно делать - тоже, от "использовать как есть" до "просто отказаться от попыток строить зрелые процессы и сфокусироваться на том, что действительно важно". Думаю вы прекрасно знаете, какой вариант поддерживаю лично я. :) Полный текст почитать можно тут. Мысли, комментарии и холивары - пожалуйста в комменты, буду рад. А ещё не забываем ставить лайки тут и в линкедине.

Не случившийся паблик толк, анонс следующего поста и call to action. Давным давно уже собираюсь выйти за пределы чатиков и повыступать где-нибудь ещё, но всё как-то не складывается. То времени капитальнейше нету, то вроде кажется что и рассказать особо-то нечего. На днях вдруг смотрю на грядущий сезон Podlodka Crew и думаю "пора" (да, как тот самый кот в меме). Грядущая куашная секция целиком посвящается QA Maturity ака "зрелости QA процессов". Тема, надо сказать, произвела на меня впечатление - мозг мгновенно проснулся, откликнулся и принялся генерировать черновик доклада, призванный устроить полнейшую анархию и дизрапт. Потому что, конечно, вся эта история со шкалами maturity - целиком и полностью сломана. Она не просто не работает, она скорее вредна. Доклада моего, к сожалению, не случится - может быть как-нибудь в следующий раз. :) (значит все таки не "пора", говорит мне вселенная) Но раз уж жернова ненависти уже раскрутились, а черновик текста уже набросан - значит быть посту (или нескольким) на эту тему. Так что накидывайте лайков, если вам оно нужно интересно. И пишите в комментах, а как у вас там с maturity в командах и что вы думаете по этому поводу?

Под недавним постом про таких разных QA лидов был вопрос как выживать в режиме "нужно заниматься всем и сразу". Обещал пост, сделал пост. Дисклеймер: Это очень сжатая версия - в материалах курса про это текста на несколько модулей и н страниц, так что многое осталось за кадром. И так, что делать-то? Прежде всего, помнить: Больше зон ответственности и направлений работы != больше капасити. Скорее наоборот, переключение между контекстами и задачами может отжирать кучу времени и размывать фокус. Что тут можно делать, что бы меньше страдать? Жестко ограничивать число параллельных треков работы. Не пытаться делать миллион дел одновременно, а четко расставлять приоритеты и держать фокус на малом количестве вещей. Закрываешь один кусочек работы, переключаешься на следующий. Это про многообразие задач в твоём to do листе, а не про количество задач в in progress. Избавляться от лишних зависимостей. Типовая ошибка здесь: придти в команду, набрать себе зон ответственности и точек принятия решений, а потом умирать под их грузом. Если команда может сама принять решение и двигаться дальше, значит тебе не надо подключаться. Если твоё участие в созвоне нужно потому что "было бы полезно послушать", то лучше потратить время на те вещи, где ты сейчас действительно нужен. Нужно учиться делегировать. Без гиперконтроля, без "я бы сделал по другому", без аппрувов на каждом шагу. Нужно строить процессы так, что бы они не блокировались на тебе. Да, ревью тестов может помочь поймать корнер кейсы, но оно не должно блокировать работу по фиче. Потом докинешь фидбэк. Да, развитие автотестов - твоя зона ответственности, но команда должна иметь возможность быстро оценить результаты и что-то поправить по мелочи, пока ты переключился на другие задачи. Это не про то, что бы переложить всю работу на других и чиллить попивая латте на банановом. Это про то, что бы тратить ресурсы на то, где нужна именно твоя экспертиза. Выстраивать строгую приоритезацию задач. Чем больше твой to-do лист, тем важнее правильно выбирать то, на что ты тратишь время. Да, все задачи срочные, важные и нужные, и было бы хорошо сделать сразу всё. Но это так не работает. Здесь помогает оценка через "что произойдет, если не взять это в работу прямо сейчас?". Жёстко контролировать скоуп. Здесь про строжайший фича кат и отказ от "идеальных решений" в пользу того, что необходимо и принесет максимум пользы в обозримой перспективе. Да, иногда это не применимо и быстрые решения неоправданы, но это должно быть осознанным решением, а не просто "хочется что бы красиво было" Не менее важно декомпозировать задачи, которые берешь в работу. Чем больше треков работы требуют твоего внимания - тем важнее двигаться короткими итерациями. Уйти на месяц пилить один кусок, пока всё остальное пылает - непозволительная роскошь. Переключаться между контекстами на середине задачи - потеря времени и лютая боль. Поэтому выстраиваем работу так, что бы двигаться маленькими атомарными шагами и актуализировать приоритеты по мере движения. Прозрачно транслировать и договариваться о приоритетах и точках фокуса. Доносить до бизнеса и команды чем именно ты планируешь заниматься, в каком порядке и что идёт под нож как "можно отложить". Проговаривать на что хватает твоего капасити, на что не хватает, почему приоритеты именно такие, что попало под тот самый фича-кат. Это не только управление ожиданиями (хотя управлять ими это мастхэв), но и способ получить себе ещё ресурсов, договориться с оунерами задачи на другое (более простое) решение и в целом избавляет от проблем. Иногда кажется, что "очевидно что всё и сразу сделать не получится". Но нет, не очевидно. Явно проговаривать такие штуки - ещё один важный скилл. Всё это не убирает "хаос" и большое количество стримов работы. Это помогает плюс-минус управлять хаосом, минимизировать количество боли и использовать те преимущества, которые он даёт, на пользу себе и команде. Ну и традиционно: если хочется покопаться в этом всём глубже, лучше понимать как это всё работает и научиться превращать бардак во что-то работающее - ты знаешь что делать.

Status update Давно не писал, поделюсь апдейтами. Последние полгода были, мягко говоря, насыщенными. Немного внепланово оказался в новой локации, а там как водится - походы по инстанциям за документами, адаптация к новому месту и культурному контексту, попытки понять что тут вообще происходит и миллионы вопросов в духе "где тут раздобыть нормальный кофе, где жить и что есть". Куча мелких бытовых штук которые вроде бы каждая по отдельности ерунда, но когда их много и все надо решать одновременно - мозг начинает немного закипать, а время уходит вникуда. Параллельно с этим неожиданно схлопнулся проект, который вроде бы только набирал обороты. Такой себе подарок на новый год. Всё это одновременно, конечно, идеальный рецепт чтобы немного поехать крышей. Почти так и произошло, но в целом живой. Тем временем, продолжаю развивать историю с курсом. Сейчас грядет большо апдейт платформы: добавляю peer-to-peer ревью между участниками, накидываю логики уведомлений, потихоньку двигаюсь в сторону более динамичного контента. Коробочное решение в духе "нужно чтобы было где постить контент" становится всё теснее, так что впереди миграция на более кастомное. Просто потому, что продукт начинает требовать штук, которые в предыдущую "коробку" уже не влезают. Отдельно радует, что коммьюнити вокруг курса продолжает расти, люди присоединяются и всё это дает много фидбэка и идей куда это развивать. Тоже присоединяйтесь, тут классно. ;) Консалтинг и менторшип тоже живёт. Засетапил ребятам нагрузочное тестирование с нуля, в кои-то веки пришлось поковыряться не только в локусте, но и в инфраструктуре. Параллельно, конечно, с кучей ресерча на тему подходов, репортов и метрик которые нужны под конкретную задачу. Но, отдельно классно что заработало. Другую команду продолжаю менторить в автоматизации - как это всё строить, как развивать, какой код писать. Ну и получилось немного запрыгнуть на хайп-трейн и поэкспериментировать с агентами для сбора метрик качества. Спойлер: ИИ никого не заменил, но жить команде стало сильно приятнее. Поэтому если вам на проекте нужно что-то похожее - пишите, обсудим, как минимум поделюсь опытом или договоримся о сотрудничестве. Ну и давайте пробовать силу нетворкинга. Если у вас есть классный продукт и команда, в которой нужно строить процессы, писать код, лидить инженеров и в целом делать так, чтобы разработка меньше страдала, бизнес чаще получал то, что ожидает получить, а пользователи реже штурмовали саппорт, в общем всяческий QA, DevEx и Engineering Management в разных пропорциях - то давайте общаться. Вдруг дримтим и я неожиданно найдем друг друга благодаря силе коммьюнити. :) В общем, такие дела. Следущий пост по плану - на днях - продолжение последнего поста про куа лидов и "как не умереть в многообразии задач". Кажется, уже могу с чистой совестью делиться лайфхаками на этот счёт.

Такие разные QA лиды Сегодня ещё кусочек рефлексии из последних нескольких месяцев. Если раньше ко мне регулярно приходили с вопросами "что нужно, что б стать джуном" (как некоторые из вас помнят, с этих вопросов и начался этот канал), то теперь чаще приходят с вопросом "что нужно, что б стать куа лидом?". Иногда это выливается в запись на участие в курсе, иногда в менторинг и мок-собеседования, иногда просто в простыню текста в качестве ответа. Самая большая сложность здесь в том, что сам тайтл куа лида - довольно абстрактный. В разных компаниях и в разных контекста он будет включать в себя очень разные штуки. Соответственно и ожидания от кандидатов будут тоже сильно разниться. В аттаче - схемка, которую набросал, когда в очередной раз пытался ответить на этот вопрос. Она упрощенная и "обрезанная", но всё равно неплохо иллюстрируют общую сложность и вариативность. Дальше, думаю, комбинаторику из всех возможных сочетаний уже можно прикинуть. Ответа на вопрос "и что тогда делать?" там нет. Возможно, в каком-то из следующих постов. :)

Немножко про опыт жизни в self-employment режиме Разбавлю около-образовательный контент личным опытом. Вот уже несколько месяцев прошли в режиме работы "на себя" - вышел из найма, сфокусировался на своих проектах и фигачил. Само решение было не самым простым. Да, были идеи и проекты, которыми хотелось заняться всерьез, а не "на выходных и по ночам". Но всё равно было ощущение шага в пустоту. Совершенно непонятно как это всё будет работать и будет ли вообще работать, а синдром самозванца настойчиво твердит мол "ты, дружок, себя переоцениваешь". Но в итоге решил, что надо просто брать и делать. Получился неистовый стресс, ещё немножко бед с башкой и куча всего интересного. В первую очередь это, конечно, про опыт и понимание того, как работать работу, когда у тебя нет стейкхолдеров, которые приходят с запросами и хотелками, а вся твоя команда это ты сам и, если очень повезёт, те люди которых каким-то чудом удалось заинтересовать и привлечь к участию. Во вторую, про полное отсутствие определённости. Причём речь даже не про отсутствие знания что раз в N тебе на карту будет падать зарплатка (хотя и про это тоже, конечно). Речь про то, что у тебя есть почти бесконечных размеров бэклог задач (половину из которых ты, если честно, вообще понятия не имеешь как делать), и примерно ноль понимания, какие из твоих усилий и действий принесут хоть какие-то результаты, а какие окажутся просто потраченными впустую ресурсами. На этом фоне начинаешь намного лучше понимать всех этих фаундеров стартапов которые нон-стопом бегают и орут, регулярно меняют продуктовые гипотезы и вообще какие-то все нервные. Ага, теперь понятно почему так. При всём этом, опыт получился странным, но классным. Удалось много всего интересного сделать, многие штуки продолжают делаться. Больше всего времени и усилий, конечно, ушло на курс и всё что вокруг него. Помимо контента (которого оказалось изрядно больше, чем планировалось), это про создание продукта как такового. Пришлось поломать голову над learning experience - как выстраивать коммуникацию, как сделать что бы обучение работало, как сделать домашки полезными, и т.д. Покопаться с технической частью - от лэндинга и всяких must-have штук до внутреннего подобия LMS. С периодическими хотфиксами и дебагом в ночи, когда ничего не работает. Штука, которая запускалась с мыслями "а это точно кому-то интересно?" превратилась в проект, который стабильно приносит классный фидбэк и оказывается полезен не только куакам, но и людям из смежных доменов. И который продолжает работать, расти и генерировать задачи в бэклог. Помимо этого был менторинг для нескольких будущих и действующих лидов. От планов обучения и мок-интервью до совместных брейнштормов как можно решать те или иные проблемы на новом проекте. Мок-интервью вообще штука которую я раньше особо не практиковал - тоже пришлось подумать как это всё выстраивать и посомневаться "а то ли я вообще делаю?", прежде чем получить обратную связь и с облегчением выдохнуть. Плюс сработал нетворкинг и пришёл запрос на консалтинг и обучение автоматизации для внешней команды. Никогда не считал себя экспертом именно в автоматизации, но пообщались с ребятами, обсудили детали, и выяснилось что тут есть мэтч и наши представления о "как надо \ чего хочется" довольно похожи. И вот уже собираю для ребят план и материалы для обучения, набрасываю полезных задачек для практики и готовлюсь к следующим шагам, как будем двигать это всё в продакшен. В общем, набор из разных форматов и контекстов в которых нужно ресерчить и разбираться на ходу, между которыми нужно переключаться и принимать решения, в правильности которых не уверен. И, конечно, попытки не потонуть во всей этой многозадачности (не всегда успешные). Всё это заставило хорошенечко покопаться в голове и разобраться с тем что мотивирует, что имеет важность, что хочется создавать и в каком формате. Самый тревожный вывод из всего этого - что мне определённо понравилось. Рекомендовать, конечно, никому в здравом уме не буду. Но и отговаривать не стану.

Как формируется видение QA домена Сегодня, как и обещал в предыдущем посте, принёс вам один из набросков того, как формируется видение QA домена и представление того, что вообще нужно построить. Большое количество деталей осталось за кадром - от разбора что кроется за каждым из шагов, почему это важно и как с этим работать, до всяких менее очевидных историй про то, как разные квадратики на этой схеме взаимодействуют между собой. На миро доске осталось, наверное, штук пятьдесят попыток правильно визуализировать основные концепции. А соответствующие куски контента для курса пришлось переписать с десяток раз. Но зато результат каеф. Собрал положительный фидбэк, отлично размял мозги пытаясь свести кучу аспектов в единый воркфлоу и заодно структурировал в своей голове всё это.

Про объяснение интуитивно понятных штук В процессе работы над курсом возникает необходимость объяснять и формализовывать концепции, которые вроде бы понятны, но на самом деле не очень. Процесс сильно похож на любимые мною холивары в QA сообществах и даже написание постов в этот канал. С поправкой на то, что масштаб контента и скорость обратной связи совсем другая. Это один аспектов, который мне действительно нравится - заставляет хорошенько размять мозги. Да и в целом кажется мне исключительно полезным занятием. Одной из таких штук, над которыми пришлось поломать голову, стало описание того, что из себя представляет видение (vision) QA домена и как его формировать. Если очень упрощенно - то этот самый вижн или видение, это то, на основе чего мы строим QA домен. Приходим в новую команду, анализируем происходящее и в нашей голове возникает картинка того, как это должно работать, что нужно поменять, как должна выглядеть архитектура домена. Тут возникает два разных варианта. 1. Мы берем архитектуру QA домена по условному "учебнику" и просто строим вот так. Этот подход хреново работает, ведь он не учитывает всю специфику контекста. Представляет собой то самое "универсальное решение", вокруг отказа от которых построен весь курс и половина этого канала. Но зато абсолютно понятно что делать. 2. Мы это видение формулируем и синтезируем на основе того контекста, который собрали. Это как раз про ту довольно объемную майнд-мэпу в одном из предыдущих постов и ещё кучу всего. Но проблема в том, что это довольно субъективный и местами творческий процесс. Там где опытные лиды, у которых уже есть опыт и большая насмотренность "как бывает" быстро собирают в своей голове паззл, вместе с аргументацией "почему так" - начинающие QA лиды теряются в многообразии контекста, возможных способов решения и непонимания за что вообще хвататься. К этому добавляется и ещё куча всего: - Cоблазн применять "знакомые" и "комфортные" инструменты и решения там, где они объективно не слишком подходят: "на предыдущем проекте использовали X - классно работало, давайте и тут использовать". - Перфекционизм и тяга выстроить "идеальные" (что бы это не значило) процессы там, где идеально не нужно. - Желание внедрить штуки, про которые "слышал и интересно попробовать" просто потому, что хочется. В итоге, если всё сводится к простому "давайте представим, что тут нужно построить" - результат получается довольно далеким от того, что реально нужно. Это приводит к необходимости превратить этот субъективный и творческий процесс формирования "видения" во что-то хоть сколько нибудь прозрачное - с ключевыми точками интереса, раздельными шагами и промежуточными целями и т.д. В ближайшие дни будет небольшой спойлер той схемы, которая из всего этого получилась. А пока просто хороший повод подумать, порефексировать и пообсуждать (при желании - велкам в комменты) как вы над этим процессом работаете и работаете ли вообще, или картинка как-то сама складывается, интуитивно? Ну и традиционная напоминалка: Почитать про курс и записаться можно тут, задонатить на развитие канала тут, а реквестировать пост на интересную вам тему - в личку.

Про "туннельное зрение" и том, почему чинить очевидные проблемы - не всегда хорошо. Одна из классных особенностей курса, который я тут пилю - это домашки, которые не про тесты "выбери правильный ответ" или задачи из цикла "напиши тест-план". Это про мысленные эксперименты и обсуждение того, как и почему можно действовать в тех или иных ситуациях. Я немного подробнее рассказывал про это в более ранних постах. Помимо того, что это в целом даёт пространство для мыслей "как можно" и "почему так", это ещё и подсвечивает разные интересные штуки, которые потом классно разбирать вместе с участниками. Про одну из таких штук и поговорим сегодня. Когда мы приходим на новый проект, вокруг нас обычно целое многообразие странных решений, проблем и всевозможного бардака. В ситуации, когда перед нами возникает очевидная проблема, у многих куа инженеров и лидов включается "туннельное зрение" - увидел проблему, сфокусировался на решении, не увидел всё остальное. Команда релизится без регрессионных и смоук-тестов. Вместо хоть сколько-то формализованных критериев качества - субьективные ощущения "вот сейчас кайф". Роли и зоны ответственности размазаны и вообще не понятно как применяются, и т.д. и т.п. Но что вообще плохого в том, что бы решать проблему, которую видишь (и в большом количестве случаев даже знаешь как решить)? Проблема в том, что здесь легко упустить ряд деталей. 1. Базовая база: а точно ли это вообще проблема? Возможно, дело не в том, что тот или иной подход плох, не работает и являет собой проблему, а в том что мы привыкли работать по другому, в то время как бизнес и команду это все полностью устраивает? Это не столько про мантру "работает - не трогай", сколько про то, что процессы могут быть разными, далеко не все что мы видим как "проблему" действительно является таковой. 2. А почему это работает именно так? Зачастую мы - далеко не первые в компании, кто увидел эту проблему и пытался её решить. Существующий процесс это не просто какой-то бардак, который никто раньше не замечал, а результат Н-ного количества попыток решения проблемы (или других проблем). Возможно, у команды просто не было кого-то, кто точно знал как решить проблему (а мы то точно знаем). Или мы упускаем какие-то детали контекста и происходящего, которые мешают сделать лучше. 3. А точно ли эту проблему нужно решать? Существующие решения создают риски и ограничения - это плохо масштабируется, это даёт слабую прогнозируемость результатов и т.д Вместе с этим они могут нести и бенефиты, ценные для компании и команды. Моментальные деплои без каких-либо регрессионных проверок могут уронить продакшен, но дают возможность быстро проверять гипотезы и собирать фидбэк на реальных данных. Неформализованные критерии качества делают процесс непрозрачным и сложно масштабируемым, но дают возможность опираться на "видение" и экспертизу участников, которые могут быть конкурентным преимуществом. Профит от "кривых" процессов может легко перевешивать все минусы и риски, которые они несут. Решение, которое будет срезать и то, и другое - нанесёт больше вреда, чем пользы. 4. Нужно ли эту проблему решать сейчас? Есть ли менее очевидные, но более болезненные точки процессов, заслуживающие больше внимания? Имеет ли это значение сейчас или будет актуально через два года, а сейчас и так нормально? Готова ли команда менять этот кусок процессов и в том масштабе, в котором это кажется нужным? Как это мэтчится с тем, что от нас ждёт команда и бизнес? Любая лидершип роль - это не только про способность "придумать", спроектировать и внедрить решения. Но и про умение действовать в условиях существующих ограничений, расставлять приоритеты и грамотно их обосновывать. Поэтому "действительно ли нужно это делать сейчас" - не менее важный вопрос, чем "как эту проблему решать". Всё это не значит что решать очевидные проблемы - плохая практика и лучше поискать что-то менее "бросающееся в глаза". Часто эти проблемы - хорошая отправная точка для дальнейших изменений. Но здесь важно видеть общую картину, учитывать контекст и принимать взвешенные решения.

Субботний микро-пост из серии про многообразие качества - о том, откуда всю эту информацию собирать. Все многообразие качества, о котором мы говорили - это ещё и многообразие источников данных, с которыми мы можем работать и из которых можем собирать данные. Из этих источников мы собираем контекст о качестве на текущий момент и о том, каким мы хотим видеть его в будущем. Собственно выше - примерная схема того, как это выглядит. Для каждого из блоков есть N способов и подходов к сбору и анализу данных, но здесь я оставил это за скобками. Ну, а для тех, кто хочет от начала и до конца разобраться с тем, как все эти данные собирать, анализировать, превращать в понятные треки работ и инициативы, внедрять и развивать и, что главное, делать все это так что бы это работало для вашей команды - вы знаете, что делать. ;)

На небесах только и разговоров что о качестве: часть 3 Пришло время продолжить серию постов про качество, его многообразие и многообразие определений оного. Как и обещал, в этом посте поговорим про насущный вопрос «а зачем это все?!», иными словами почему так сложно и что бы что? Зачем во всём этом копаться и какой профит это дает? Здесь есть несколько моментов. 1. Само по себе понимание этого многообразия полезно. И вам, и команде. Оно наглядно демонстрирует разные аспекты проблем, разные пласты работы над качеством и то, какую ценность каждый из них формирует для разных участников. Через это же понимание можно увидеть какие из аспектов качества выпадают из фокуса команды, над чем предстоит работать, да и вообще увидеть (и донести до других) всю объемность куа домена. 2. То, как воспринимается качество в рамках команды и в головах отдельно взятых людей формирует ожидания, с которыми мы работаем. Когда стейкхолдеры сходятся на том, что нам нужен более качественный продукт - это здорово. Но это не говорит о том, что их ожидания от нашей работы сходятся между собой. Просто потому, что под "качественным продуктом" каждый подразумевает что-то своё, и эти представления могут довольно сильно конфликтовать. А в нашем субьективном восприятии качество может вообще значить что-то третье. В итоге мы строим что-то совсем не то, что от нас ждали, хотя по факту делаем всё тот же "более качественный продукт". 3. Это позволяет синхронизировать команду. Прямое следствие двух предыдущих пунктов - возможность говорить на одном языке. Когда мы понимаем всё многообразние качества и разницу восприятий между участниками, мы можем договориться об общем понимании и представлении. Где ключевые точки интереса, что важно каждому из участников, как одно влияет на другое и пр. В итоге субьективное "продукт соответствует ожиданиям по уровню качества" становится чуть менее субьективным и все плюс-минус понимают, какой набор характеристик под этим кроется. 4. Сводит множество разных аспектов в единую картинку. Там где до этого бизнес заботился только о бизнесовом качестве, а разработчики о качестве кода - мы можем выстраивать цельную картину. Доносить до всех участников когда (и почему) важно пожертвовать одним в пользу другого, как одно аффектит другое и почему просто забить на один из кусочков не получится. Для работы над QA доменом это означает, что мы сможем осознанно (и прозрачно для остальных участников) балансировать между интересами и проблемами разных групп. Выстраивать работу над качеством так, что бы обеспечение планки качества в одном аспекте не рушило другие, потому что это неприменно приведет к обратному эффекту - лишь вопрос времени. Начинать выстраивать качество с того, что бы разобраться что именно от нас всё таки хотят, почему именно так и к какому результату каждый из участников хочет придти - казалось бы, довольно очевидная история. Тем не менее, стоит только начать в этом копаться, как всплывает огромное количество сложностей и нюансов. В канале это переросло в целую серию очень упрощенных постов, в рамках курса - в три полноценных модуля. Просто что бы понять "а что вообще за качество нам нужно строить?". Такие дела.

Пока следующий пост относительно про качество готовится к публикации, добавлю очередную ссылку на Федю Борщева. Часто на него ссылаюсь, потому что несмотря на довольно большое количество точек, по которым наше видение очень разнится - многие его посты перекликаются с моим представлением о правильном и прекрасном. Этот пост как раз про одну из таких вещей. Публикую с сокращениями, за полной версией - по ссылке выше. В «Коммуникации Систем» мы говорим о понятиях system form и system function. Форма — это как система выглядит: на какие модули разбита, с какими данными работает. Функция — то, что система делает: как реагирует на ввод, что отдаёт на вывод. Для меня форма и функция выходят далеко за рамки айтишечки и даже проектирования систем. Это, скорее, про красоту. Вещи, в которых форма подчинена функции — красивы. Вещи, в которых функция размыта, а форма сложна — некрасивы и неприятны. ... Глядя на форму, можно определить функцию, которую туда закладывает автор. Так, по названию хорошего класса в коде понятно, что он делает, а по первому экрану приложения видно, чего от него хотели авторы. ... Форма эволюционирует вместе с функцией. К примеру Медиум когда-то был отличным средством для публикации лонгридов, а в процессе эволюции превратился в пейвольную помойку — очевидно, новая форма стала более выгодна владельцам. Или взять любой продукт Яндекса — почти везде его функция со временем перестаёт интересовать владельцев. Так навигатор превратился в тормозные «карты», а сервисы доставки еды и такси превратились непонятно во что: «экосистема» это что-то на шейрхолдерском, а не на пользовательском. Когда проектируете что угодно — архитектуру системы, пользовательский опыт, пост в тг-канал — сначала подчиняйте форму функции, а потом уже думайте об украшениях. Идеи, которые Федя с командой рассматривает на своем курсе про дизайн систем, я по сути протащил через весь свой курс по построению QA процессов: - Сначала определяемся с функцией, затем создаём форму которая будет ей служить. - Избавляемся от любой сложности в форме, не способствующей (и уж тем более мешающей) работе функции. - Осознаем не только тесную взаимосвязь, но и изменчивость этих воплощений в процессах, инструментах и всём домене. Собственно, мысли о том, что дизайн процессов слабо отличается от систем-дизайна не новы. Но это, кажется, про то, как работает дизайн в целом.

На небесах только и разговоров что о качестве: часть 2 В продолжение предыдущего поста, как и обещано, делюсь своим мнением на этот счёт. Прежде всего - почему всё так сложно-то? Всё сложно по ряду причин: 1. Понятие качества довольно многогранное. Пользователи, бизнес-стейкхолдеры, разработчики - все видят продукт через свою призму восприятия, свои цели и то как они взаимодействуют с продуктом. Тут можно дробить "качество" на составляющие - "внешнее и внутреннее качество" или "качество продукта, качество кода, качество пользовательского опыта". Вариантов довольно много. 2. Каждая из этих "грайней" и форм восприятия тоже сложная. В комментариях к предыдущему посту упоминали качество по Гарвину. В домашках ребята упомянали и Модель Кано, и модель качества по Макфолу, и даже пришедший из маркетинга EDT. Таких классификаций достаточно много и они, в целом, продолжают появляться. Короче, количество факторов формирующих собой итоговое "качество" довольно большое. 3. Качество воспринимается субьективно. Кому-то важно, что бы всё выглядело pixel perfect, а кому-то важнее избежать лишнего клика в регулярно используемых сценариях. Кто-то отдает предпочтение стабильности работы и отсутствию ошибок, а кому-то важнее что в продукте быстрее появляются новые фичи, пусть иногда и в сыром виде. И т.д. 4. Качество относительно и зависит от контекста. Восприятие качества базируется на сравнении с конкурирующими продуктами, с тем к чему человек привык и теми ожиданиями, которые у него есть относительно продукта. Всё это про "качество" как сравнительную характеристику. Более того, эти ожидания и точки сравнения меняются с течением времени и исходя из контекста. 5. Все эти аспекты качества не изолированы друг от друга. Они довольно тесно (и местами совсем не очевидно) переплетаются, создавая цепочки влияния друг на друга. Качество кода может аффектить пользовательских опыт, восприятие бизнеса будет влиять на те рамки, в которых создается техническая реализация и т.д. Важно отметить: высокая планка качества может вредить так же, как и низкая. Вся эта сложность приводит к тому, что нет бинарной величины "продукт качественный". Попытки превратить это всё в какой-то универсальный score типа "уровень качества 9/10" почти обречены на провал. И даже схема с quality gate'ами на отдельные характеристики качества вызывает вопросы, т.к. плохо адаптируется к тому, что приоритеты тех или иных аспектов качества могут очень сильно меняться. В следующем посте про "а зачем это всё вообще?".

На небесах только и разговоров что о качестве... Факт, который кажется мне довольно забавным: курс про то, как строить QA, рассчитаный на действующих и будущих куа лидов, а так же всех кто так или иначе вовлечен в работу над качеством, стартовал с блока посвященного тому, а что вообще такое это ваше качество. Вопрос, которым издавна мучают джунов на их первых собеседованиях, и на который раз за разом получают один и тот же ответ: качество - это соответствие фактического состояния продукта ожидаемому. Казалось бы, что тут ещё обсуждать. Но как и большинство штук "по учебнику" - это определение слабо мэтчится на реальную жизнь, со всеми её оговорками, сложностями, многообразием проектов, продуктов и команд. При этом я вижу, что не проходит и недели, что бы в каком-то из около-рабочих сообществ, закулисных холиваров на митапах или просто где-нибудь в комментах не всплывал вопрос "а что вообще такое это ваше качество и в чём его измерять?" Ещё драматичнее тот факт, что по субьективным ощущениям почти никогда эти дискуссии не заканчиваются каким-то консенсусом. Независимо от того, холиварят между собой куа инженеры, руководители команд или люди, занимающие около с-левел тайтлы. Не реже возникают ситуации, когда команды пытаются "что-то делать с качеством", при этом даже не обсудив между собой что это вообще такое. И тут тоже не совсем понятно, как надеяться на успех этой миссии. Так появился первый модуль курса, в котором почти в течении часа мы разбираемся с тем, что же такое качество, что оно может из себя представлять и из чего формироваться в разных контекстах. И то, это только начало - все эти идеи будут раскручиваться и дополняться по ходу движения потока от модуля к модулю. Так появился набор домашек, где ребята делились своими мыслями и идеями на примере "выдуманных" (но очень похожих на правду) контекстов. И самое прекрасное здесь, что даже на основе одних и тех же кейсов - ответы оказались очень разными. Каждый подмечает важные для себя штуки, трансформирует свой опыт и набитые шишки в видение, гипотезы и интерпретацию событий. Это классно работает, особенно когда потом можно обсудить всю разницу решений и посмотреть, как ответы на те же самые вопросы видят другие люди. Ну и, конечно, модерировать всё это - чертовски интересное занятие. И за счёт перекресного опыления опытом и идеями, и за счёт комментариев "у меня тут мозг закипел в попытках" от участников. А у вас как? Приходилось ли вообще задаваться этим вопросом? Есть ли ощущение, что все в команде точно понимают, что такое это ваше качество? Или всё это ненужно, лучше побольше тестов успеть написать? Всем кто набросит в комментах - лайк и плюс в карму, а я своим мнением поделюсь чуть позже.

Про 20.06 🍾 Ну что ж, друзья. Новая версия курса сегодня запустилась, первый кусочек контента получил своих зрителей. Продолжаю немножко гореть и ловить периодические ошибки, всё таки это тоже своего рода релиз. Но это нормально. Что ещё интереснее: 8 лет назад был сделан первый пост на извечную тему "што ж нужно знать джуниорам". От этой цифры начинают скрипеть олдскулы, но что есть то есть, это был долгий путь. :) Спасибо всем, кто читает. Тем, кто насыпает фидбэка, делится впечатлениями и помогает делать канал лучше - вдвойне спасибо. Такие дела. 🎉️️️️️️

Курс стартует уже в эту пятницу, а значит ... Самое время было собрать лэндинг про курс с удобной формочкой для сайнапа, вместо старого грустного описания в Outline. Впереди ещё куча работы на навести красоты и добавить порядка. Позади дебаггинг-сессия достойная очень длинного пост-мортема. Но зато теперь все, кто ещё не успел записаться могут откликнуться на last call и запрыгнуть в вот-вот стартующий поток. Такие дела.

Тим-дизайн, часть вторая В прошлом посте немного поговорили про то, как QA функция может вписываться в общую структуру команд и какими вообще эти команды бывают. Сегодня немного поговорим про то, как вообще понять какая команда нужна вам, из каких факторов эта картинка складывается и что со всем этим делать. 1. Традиционная точка старта здесь - выясняем запросы бизнеса и команды. Иными словами разбираемся с тем, что от вас хотят: какие цели стоят перед QA функцией, какие зоны ответственности надо захватить и какие проблемы предстоит решать. Это одновременно позволяет понять и масштабы работы, и основные домены в которых эта работа будет вестись. Если ваша задача на обозримое будущее - поддерживать ультра-быстрые поставки фичей, гарантируя работу ключевых бизнес-сценариев, то это один пул задач и работы. Если вам нужно максимально нарастить тестовое покрытие и выдавать 99% покрытие функциональных требований тестами, то это совсем другой пул работы и другие ресурсы. 2. Изучаем контекст, имеющиеся ограничения и факторы влияющие на работу. Наличие регуляторных ограничений, уровень рисков связанных с качеством, текущее состояние продуктового качества и кодовой базы, уровень инженерной культуры, релизные циклы, продуктовые и технические планы. Здесь мы, по сути, дополняем результаты предыдущего шага более подробным контекстом. Если команда и так неплохо справляется с обеспечением необходимого уровня качества, но хотят видеть отдельного юнита в качестве драйвера этого процесса - тогда возможно вам нужен минимум дополнительных ресурсов. Если команда утопает в багах, сборки постоянно красные, а для стаблизации релиз кандидата нужно три месяца по кругу переписывать один и тот же код - вероятно, вас ждёт много работы и это потребует ощутимо больше ресурсов. Если цена ошибки в продакшене минимальная и главное быстро поправить - это один флоу, если критический баг в продакшене может привести к катастрофическим последствиям - это другой флоу. И всё в этом духе. 3. Маппим получившийся список целей и активностей на необходимые экспертизы. Если мы видим запрос от команды на автоматизацию (или это единственный вариант обеспечить нужную частотность и объем прогоняемых тестов) - то нам нужна экспертиза в автоматизации. Нужна ли нам нагрузка, внутренние пентесты, экспертиза в UX или внимание к мельчайшим деталям для создания "вылизанного" юая. На выходе у нас получается что-то похожее на матрицу компетенций - области экспертизы, которые нам нужны и их маппинг на команды/домены/блоки работы. 4. Дополняем получившуюся матрицу деталями. Здесь мы грубо оцениваем объемы работы и её срочность, уровень нужной нам глубины экспертизы в зависимости от ожиданий, степень автономности в зависимости от уровня неопределенности по задачам и необходимости самостоятельно формулировать, выбирать и принимать решения. Здесь же мы накладываем получившиеся блоки работ на рабочие процессы в командах и смотрим, где могут быть боттлнеки, скачки нагрузки и/или где нам гарантированно нужно делать поправку на бас-фактор. И ещё раз возвращаемся к п.2 с имеющимися у нас ограничениями, в т.ч. по бюджету, возможности увеличивать хэдкаунт, срочности закрытия тех или иных пробелов в экспертизе. В результате у нас получается что-то похожее на приблизительный состав команды и профили кандидатов. 5. Расставляем приоритеты, дополняем это планами развития исходя из того горизонта планирования, который у нас есть, а так же дополняем эту картину общекомандными требованиями - здесь появляется культурный- и командный-фит и прочие штуки, которые компания ожидает условно от всех. То, что получится в результате уже можно нести согласовывать, продавать и запускать в работу, в случае успеха. Это, конечно, весьма упрощенное описание процесса. Полный текст вышел примерно на 5 тысяч слов длиннее. Ну, а что делать, что б его почитать - вы знаете. P.S. Если вы вдруг уже заполняли формочку про курс, а я до сих пор с вами не связался - значит сабмит куда-то затерялся, обязательно пните меня в личку.

То, как мы говорим про качество определяет культуру работы над оным. Почти уникальная для этого канала рубрика - редко рекомендую кому-то книги, касающиеся тестирования или QA. Но тут одна из удивительно приятных находок для меня - Leading Quality by Ronald Cummings - John & Owais Peer Короткая, на ~150 страниц, книга посвященная тому, как выстраивать работу над качеством, почему это важно и как это всё работает. Многие тезисы очень перекликаются с тем, что вот уже на протяжении N лет я рассказываю в этом канале и в русскоязычном сообществе, в то время как другие хорошо дополняют эту парадигму. Объем сохраненных на потом цитат и фрагментов перевалил, кажется, все разумные пределы. Один из таких концептов сегодня принес вам, что бы поделиться. Он сводится к тому, что бы описать работу над построением качества через нарративы, которыми мы говорим про качество. В книге приводится три ключевых нарратива в QA домене: 1. The Ownership Narrative Разговоры о том, кто является ответственным за качество. Причем здесь важно отметить, что это не только теоретическое "качество это ответственность всей команды", но и то как мы говорим об этом в разных контекстах - например, когда продакшен упал. 2. The “How to Test” Narrative Разговоры о том, как тестировать и обеспечивать качество вот этой фигни. Это касается выбора конкретных подходов и практик, выбора инструментов, скоупа тестирования или обсуждения тестируемости приложения. Это касается и продукта в целом, и отдельных его фичей. 3. The Value Narrative Разговоры о ценности работы над качеством в целом и отдельных инициатив, о том, когда и почему в это качество нужно инвестировать, про return of investments и то, сколько ещё нам нужно вложить сил и ресурсов в работу над качеством и что мы хотим получить взамен. Через призму этих трех нарративов мы можем описать культуру качества в компании целиком с одной стороны, а с другой стороны понять каким образом и в каком направлении мы хотим её менять. Через то, что мы говорим в рамках каждого из этих нарративов и сколько внимания уделяем каждому из них, можно увидеть те проблемы, которые мешают нам создавать более качественный продукт. Например, многие технические специалисты сфокусированы исключительно на втором - на том "как мы можем это тестировать", но при этом полностью игнорируют даже попытки разговоров о value всех этих инициатив, инструментов и процессов. И далее по списку. В финале хочется добавить ещё одну цитату-цитаты, которая помогла мне ответить на вопрос почему мой курс про построение QA процессов так похож на курс по problem-solving: In Your Strategy Needs a Strategy: How to Choose and Execute the Right Approach, author Martin Reeves hits the nail on the head when he says: “Strategy is, in essence, problem solving, and the best approach depends upon the specific problem at hand. Your environment dictates your approach to strategy.” Так что помимо того, что бы записаться на курс, горячо всем рекомендую ещё и классную книжку.

На что это всё влияет? Прежде всего это влияет на рабочие воркфлоу, точки внешних и внутренних зависимостей. Это определяет и то, как будет происходить внутри- и кросс-командная коммуникация, как будет планироваться работа, возможные точки блокирования или отказа в рабочих процессах. Вторым важным фактором здесь является разделение и изолирование контекстов. Любой участник находящийся за пределами команды, работающей над фичей, так или иначе теряет часть рабочего контекста по задаче. Если человек выполняет роль X-as-a-Service для N разных команд, то его погружение в проблематику и контекст отдельно взятой команды ожидаемо меньше, чем если фокус человека сосредоточен на том, над чем работает одна конкретная команда - неважно, проектная она или продуктовая. На этом этапе мы определяемся с тем, как наша QA команда вписывается в общую оргструктуру и взаимодействует с другими ролями. Следующим шагом становится то, как выглядит сама команда, как происходят все коммуникации внутри и во вне, существует ли деление на отдельные роли|функции внутри команды, как выстроена иерархия. В общем, это только начало. :)