О QA за гаражами

#моикниги

В наше неспокойное время в поисках опоры мы зачастую пускаемся во все тяжкие: кто-то ищет себя в любимом деле и хобби, кто-то обращается к религии, иные в многочасовых сессиях в терапии, а кто-то и вовсе в гороскопах или картах таро.

Поделюсь своим опытом – я отправился на поиски опоры в себе благодаря стоикам.

Начал с «Как жить: уроки стоицизма от Эпиктета, Сенеки и Марка Аврелия», темы и посылы захватили настолько, что я решил обратиться к первоисточникам.

Продолжил Марком Аврелием и его «античным твиттером», походными записками «Наедине с собой», что он делал в военных лагерях во II веке н.э. Поразила мощь и ясность мысли (которая мне, правда, по первой давалась непросто и приходилось прям вгрызаться в написанное), человека обличенного абсолютной властью своего времени и меж тем пишущим о том, чему подвластны мы все. Книга буквально испещерена мудростями, вроде

Будь подобен скале: волны беспрестанно разбиваются о нее, она же стоит недвижимо, и вокруг нее стихают взволнованные воды.
«Я несчастен потому, что со мной случилось то-то и то-то». — Отнюдь нет. Наоборот, я счастлив потому, что, хотя это и случилось со мной, я все же не предаюсь печали, не сломлен настоящим, не трепещу перед грядущим. Случиться ведь это могло со всяким, но не всякий бы остался чуждым печали. Почему же первое более несчастье, нежели второе счастье? Назовешь ли ты вообще несчастьем для человека то, что не препятствует человеческой природе достичь ее цели? Но кажется ли тебе таким препятствием то, что не вступает в противоречие с требованиями челове-ческой природы? В чем же заключаются эти требования? Ты знаешь их.
Разве случившееся мешает тебе быть справедливым, вели-кодушным, благоразумным, рассудительным, осторожным в суждениях, правдивым, скромным, откровенным и обладать всеми другими свойствами, в наличии которых особенность человеческой природы? Не забывай при всяком событии, повергающем тебя в печаль, опираться на основную мысль:
«Не событие это является несчастьем, а способность достойно перенести его — счастьем».

Или

«Если обстоятельства понудят тебя изменить своему душевному равновесию, то поспеши вернуться к самому себе и не отступать сверх необходимости от размеренных дви-жений своей души. Ведь чем чаще будешь ты возвращаться к гармонии, тем более и более будешь укрепляться в ней.»

Следом отправился к трудам Сенеки, а именно к его «Нравственные письма к Луцилию» и здесь схожая патетика, что не глава, то цитата (на иллюстрации к посту пара хайлайтов). Как и Мар Аврелий, Сенека был обличен властью, будучи воспитателем и учителем римского Императора Нерона (который, увы, как мы знаем из истории, учениям наставника не внял), имел высокий статус, богатство и слыл почетным гражданином Рима. И меж тем, он также писал о том, что трогает души любого человека даже спустя почти две тысячи лет.

Следом отправлюсь читать Зенона Китийского (крайне интересная судьба основателя стоицизма, который обрел опору в себе потеряв все) и Эпиктета, что был рабом и также стоял у истоков учения стоиков.

Рекомендую и своим читателям к прочтению, мудрость веков пригодится как в профессиональной жизни и карьере, так и делах житейских.

А в чем или ком ищите/нашли опору Вы?

🧘‍♂️ «Вместо загара — выгорание»: как стоицизм спасает тимлида от дурки (и развивает команду)

Как-то мне сказали классную фразу: «Этим летом у тебя вместо загара — выгорание». Смешно, если бы не было так больно.

Был период, когда мы строили команду буквально с нуля, масштабируя QA с 5 до 100+ человек за полтора года. В пике подо мной было 15 директов-руководителей. Я пытался контролировать всё: найм, онбординг, доки, метрики, постановку тасок. Итог закономерен — жесточайшее выгорание, стресс и операция по удалению опухоли.

Именно тогда я на своей шкуре прочувствовал, почему античным стоикам нужно ставить памятник в каждом IT-офисе. Их базовый принцип «Дихотомия контроля» (разделяй то, что можешь контролировать, и то, что нет) — это лучшая таблетка от микроменеджмента.

Как это работает на практике?

Например, найм. Сначала я отсматривал по 100+ резюме и проводил по 15 собесов в неделю. Страшно было отпустить. Но я перенаправил фокус с «контроля каждого кандидата» на «контроль пайплайна». В итоге конвейер заработал сам, а я узнавал о выходе нового QA только тогда, когда ему кидали приветственные стикеры в командный чатик.

Стоицизм – это не значит забить на всё. Это про умение нырнуть, запустить механизм и вовремя убрать руки.

🤖 Когда пошел бум на ИИ, я полез в это с головой: агенты, mcp, меморибанки. Пощупал сам, заговорил с командой на одном языке, зарядил их идеей. А дальше задал себе вопрос:
«Точно ли то, что я сейчас делаю, требует моей уникальной/сложновоспроизводимой экспертизы?»
Если ответ «нет» и в команде уже есть ребята и девчонки, способные это решать – смело отпускаю контроль.

Но самое интересное – как это влияет на команду.

Казалось бы, если за сотрудником следить, он работает лучше. Чушь. Тотальный контроль расслабляет. Это как с разработчиками: если на проекте отличный QA-отдел, разработчик начинает писать код «тяп-ляп» – «ну а чо, тестировщик всё равно баги найдет и вернет».

Как только ты снимаешь душный контроль, происходит магия:
🚲 У велосипеда откручивают боковые колесики. Ребята получают суперсилу контролировать себя сами. Прокачиваются не только навыки исполнителя, но и селф-менеджмент.
🕷 Эффект Дяди Бена. Большая сила = большая ответственность.
🤝 Буст лояльности. Сотрудник думает: «Блин, лид мне доверяет настолько, что вообще не микроменеджерит. Сделаю всё, чтобы его не подвести».

Вывод простой: попытка удержать весь проект в своих руках не делает вас супергероем. Она делает вас пациентом хирурга. Доверяйте пайплайнам и своей команде.

👇 А как у вас с делегированием? Страдаете от микроменеджмента со стороны руководства или сами грешите тем, что лезете в каждую таску своих джунов? Делитесь в комментах!

Мне тут в комментариях к последнему посту резонно предъявили, что меня потянуло на какие-то китайский притчи. Видимо это побочка Большого Красного Халата перед сном, IYKWIM.

Про критику было в прошлом посте, а посему сегодня хочется затереть про обратную связь позитивную, за похвалу погутарить то бишь. В рамках своего курса по пил-менеджменту есть пара слайдов по теме, и зарисовка:

Рождается человек и ему так аккуратно в ладошки щепотку похвалы отсыпают и приговаривают "Это вся похвала до конца твоих дней, используй с умом, не перехвали ненароком кого-нибудь", а после указывают на три товарных поезда по 50 вагонов каждый, груженые с горочкой критикой и добавляют "А это критика, критикуй всех и вся, "перекритиковать нельзя", если вдруг закончится, еще подвезем".

Так и в реальности можно увлечься критикой и не заметить, как вместо педагогического эффекта она сначала деморализует, а затем и вовсе отобьёт желание что-либо делать. Но как быть с похвалой и нужна ли она вообще? Часто встречаюсь с мнением/поведением, когда пользуются исключительно критикой. Тут привожу еще одну зарисовку:

"Раньше были такие машинки на пульте управления, которые могли ездить только прямо или назад с поворотом направо [привет детям из 90х]. Так вот чтобы машинка поехала вперед и налево, надо было сначала сдать назад+вправо, а затем вперед, но если хотелось, чтобы машинка поехала вперед и вправо, то приходилось прям надолго зажимать назад+вправо, чтобы машинка сделала почти полный круг и только после этого нажать вперед. Не самое удобное управление."

Так и в работе с мотивацией наших коллег/команды, использовать исключительно критику (или похвалу) можно, но эффективность подобного управления мотивацией будет невысокой. А посему, по моему опыту, намного рациональнее использовать оба инструмента подачи обратной связи.

А как часто хвалите вы?

🔥 – хвалю часто
🤔 – какая еще "похвала"?! 10 плетей этому холопу!

Искусство кунг-фидбека🙏🏻

В горном монастыре кунг‑фу жил молодой мастер, а у него был усердный ученик. Юноша день за днём оттачивал удары, стойки и движения — и с каждым разом получалось всё лучше. Но учитель был суров. Даже когда ученик выполнял связку почти безупречно, учитель тут же указывал на малейшую неточность: «Плечо ниже! Взгляд не туда! Стопа не до конца развёрнута!» Он верил, что только так родится истинное мастерство — через бесконечную шлифовку каждой детали.

Ученик старался изо всех сил, но с каждым замечанием его радость от тренировки тускнела. Огонь старания понемногу угасал, а в глазах появлялась усталость. Видя это, старый наставник учителя — тот, кто когда‑то обучал самого учителя, — решил вмешаться. Он позвал молодого мастера к горной реке, где стояла старая водяная мельница.
— Смотри, — сказал старик, указывая на поток. — Этот ручей питает мельницу. Если мы положим в него несколько камней, поток станет сильнее, и колесо закрутится быстрее. Они положили в воду несколько гладких камней — и правда, вода зажурчала стремительнее, колесо мельницы завертелось живее. Так и обратная связь: верные замечания помогают расти, делают мастерство крепче.
Учитель кивнул, не видя в этом ничего нового.

— Но если мы будем бездумно бросать всё больше и больше камней, — продолжил старый наставник, — поток начнёт искать другой путь. Он обойдёт преграду, потечёт по новому руслу — и мельница остановится. Так и с человеком: если требовать от него совершенства, выискивая каждую ошибку даже тогда, когда всё уже сделано хорошо, можно погасить его стремления. Желание стараться уйдёт, как вода, что нашла себе новую дорогу.

Мастер замер, глядя на замерший поток, рыскающий меж камней в поисках нового пути и вдруг увидел в нём отражение своих слов. Он вспомнил, как каждый раз, едва ученик добивался успеха, тут же обрушивал на него ворох замечаний — и как с каждым разом юноша всё меньше радовался своим победам.

— А как же тогда быть? — тихо спросил учитель. — Как понять, где та грань, когда камни ещё помогают, а когда уже мешают?

Старик улыбнулся:
— Истинное мастерство учителя — не в том, чтобы видеть только ошибки, и не в том, чтобы закрывать на них глаза. Оно в чуткости. Когда ученик старается и делает хорошо — порой самое ценное, что ты можешь ему дать, — это признание его труда. Пусть он почувствует, что его путь верен. А мелкие недочёты сгладятся в своё время. Ведь мельнице нужна не бурная река, сметающая всё на своём пути, а ровный, сильный поток, который будет крутить её колесо день за днём.

🔥🔥 Лето в самом разгаре, и у нас в Яндекс.Рекламе есть горячая позиция Инженера по тестированию! 🔥🔥

Если "ты смелый, ловкий, умелый, джунгли Рекламы тебя зовут"©!

У нас и продукт интересный, важный, полезный для современного бизнеса (где к мнению участников команд его разработки прислушиваются, а потому продуктовая вовлеченность приветствуется), и технологический стэк модно-стильно-молодежный, который позволит и руками головой приложиться к продукту, и на ниве автотестов будет где разгуляться.

Ну и само собой, использовать ИИ в повседневной работе (от тестогенерации, до режимов/скиллов/меморибанков для написания АТ и не только). А при желании, со временем можно будет вкладываться и в развитие подобных инструментов.

Команда душевная (и душная, само собой, тестировщики же), лид- чОткая и на опыте, смотрящий руководитель отдела – тот еще гопник вроде тоже "ничотак" ©

Откликайтесь по ссылочке, ну или "залетайте кабанчиком в личку, пошуршим, там речь о трехзначных цифрах" ©

🛠 Я технарь, а не маркетолог: почему инженерам и их руководителям нужно уметь «продавать» свои решения

Знакомая картина? Вы нашли крутую тулзу, придумали идеальный флоу для регресса или новый архитектурный паттерн. Приходите к бизнесу или команде и неуверенно бубните: «Ну, это правда хорошее решение, давайте брать».

А в ответ — тишина, скепсис или классическое «нам сейчас не до этого, закинь в бэклог, обсудим в следующем квартале». 🥲

Многие технические ребята думают, что если решение технически красивое, оно продаст само себя. Спойлер: нет.

Продажа идей, инструментов и процессов — это такая же базовая часть работы тех. менеджера, как проведение 1:1, планирование спринтов или решение конфликтов. И чураться этого точно не стоит.

Почему навык «внутреннего сейлза» — это абсолютный мастхэв для руководителя и проверенная дорожка для роста инженера?

🌉 Это мостик между фантазией и продом
Без нормальной продажи твоя гениальная идея так и останется красивой схемкой в Miro. Умение питчить — это единственный способ довезти концепт до фактической реализации.

🔥 Это проявление лидерства
Лидер — не тот, кто просто завел таску. Это тот, кто ведет за собой. Если ты умеешь выстроить аргументацию так, что у команды возникает эффект «Вау, хочу это использовать, почему мы вообще раньше так не делали?!» — поздравляю, ты только что заработал х2 к авторитету.

🥷 Это жесткий краш-тест самой идеи
Как говорил Сунь Цзы: «Сражение выигрывает тот, кто лучше к нему подготовится». Подготовка к защите проекта прокачивает саму идею. Ты заранее думаешь: «Ага, вот тут безопасники докопаются, а разработка скажет, что это долго».
Ты закладываешь в презу бронебойные контр-аргументы: «Кто-то скажет, что X не сработает из-за Y. На это я отвечу...». Прокручивая в голове возражения, ты сам фиксишь узкие места своего решения еще до того, как открыл рот на синке (корректируя как само решение, так и аргументацию по его защите).

🗣 Это мощнейший буст софт-скиллов по всем фронтам
Навык убеждения это не дар или врожденный талант, а прокачиваемая компетенция. Тот, кто научился «продавать» идеи, гораздо легче разруливает сложные переговоры со смежниками, увереннее защищает проекты, выбивает бюджеты, защищает оценку на ревью и не потеет перед выступлениями на конфах.

Так что выкидываем из головы установку «я инженер, мне эти ваши презентации не нужны». В IT идеи покупают у тех, кто умеет их продавать и обосновывать профит от них.

👇 А как у вас с этим в командах? Часто приходится с боем защищать внедрение новых решений? Какую последнюю идею удалось успешно «продать» руководству/смежникам? Делитесь в комментах!

Друзья, знаю, что среди читателей моего скромного блога есть немало тех, кто в той или иной степени являлся/является или планирует быть ментором в ИТ.

Ко мне обратилась за помощью студентка из НИУ ВШЭ, которая готовит ВКР по теме "Менторство в ИТ", в рамках которого необходимы данные количественного опроса. Решил помочь, заполнив форму сам (в том числе с опцией "глубинного интервью"), и зашарить опросник у себя в канале.

Давайте поделимся мнением по поводу важной состовляющей развития ИТ-индустрии в стране, коим является менторство.

Размышления о внедрении ИИ

ИИ часто сравнивают с крупными технологическими прорывами предыдущих лет - смартфоны, Интернет, компьютеры, автомобили, электричество, паровые двигатели и т.д.

Вовсю пишут и говорят про неэффективность внедрения, мол, только 5% подобных внедрений успешны, а все остальное в труху.

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

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

Если взглянуть ретроспективно на предыдущие технологические прорывы, то у каждого был мучительный этап борьбы с противниками, попытки разобраться в сути технологии для повышения ее эффективности, удешевление производства и т.д.

Машины были и до Генри Форда, но именно конвеерная сборка сделала продукт на базе новой технологии массовым.

Ну и, в-третьих, читая «Черного лебедя» Талеба, обратил внимание на то, что преодоление кризиса внедрения технологии происходило во многом за счет того, что были найдены принципиально новые области применения технологий там, где без нее это было «невозможно» (то есть существовали технологические ограничения/противоречия по ТРИЗу Альштуллера). А потому, вероятно, нужно сфокусировать усилия не только на интеграцию ИИ в существующие паттерны/продукты, но и создавать что-то принципиально новое, что было невозможно сделать в эпоху до ИИ.

До появления массовых паровых двигателей путешествия через Атлантику были крайне долгими, небезопасными, относительно редкими и предназначались скорее для исследователей и энтузиастов. Внедрение новой технологии создало целый пласт новых паттернов в совершенно иных масштабах, которые обеспечили среди прочих, например, массовую трансатлантическую миграцию.

А что Вы думаете по этому поводу? Какие новые области применения ИИ видите в ближайшем будущем?

С коллегами из ПК Podlodka QA Crew готовимся к следующему сезону.

Запустили небольшое голосование для выбора темы будущего сезона!

Будем благодарны, если проголосуете, ну и само собой, если посетите в марте;)

Следите за апдейтами, stay tuned!

Риск-менеджмент, как много в этом слове, для QA слилось...

Обеспечение качества часто идет рука в об руку с управлением рисками, цель которого снизить вероятность негативных событий и/или их последствий.

Будь то определение тестового покрытия при тестировании конкретной фичи, набора регрессионных тестов, приоритетов автоматизации, определение критичности дефекта или многие другие аспекты работы QA, везде сталкиваемся с необходимостью управлениями рисками.

Популярным инструментом служит матрица «влияние × вероятность», где каждый риск оценивается по двум осям:

1) насколько сильно он повлияет на цели

2) какова вероятность его наступления

На практике существуют разные стратегии приоритизации.

Системообразующими являются две:

Первая стратегия фокусируется на рисках с максимальным влиянием, независимо от их вероятности. Логика проста: даже редкое событие может быть критичным для бизнеса, репутации или безопасности. Такой подход часто используется в регулированных отраслях и при работе с «чёрными лебедями».

Вторая стратегия делает ставку на самые вероятные риски, не взирая на масштаб их влияния. Здесь целью является сокращение постоянных потерь и операционных сбоев, которые «съедают» ресурсы за счёт частоты.

* – на практике чаще применяется комбинированная стратегия, когда для влияния и частотности рисков опередляются веса, считается их произведение и устанавливаются пороги для применения тех или иных техник управления рисками.

——

Для работы с рисками обычно применяют четыре ключевые техники:

Избегание, когда производят изменение планов или процессов так, чтобы риск не возникал.

«Новогодний фриз» – пример избегания рисков возникновения новых дефектов в критически важный момент за счет временной приостановки поставок обновлений ПО.

Снижение (минимизация), организация работы таким образом, чтобы уменьшались вероятность и/или влияние риска.

"Раскатка под флагом/тогглом/на процент" – один из популярных способов минимизировать риски при выкатке нового ПО.

Передача, по сути, способ переноса ответственности (страхование, аутсорсинг).

Применение в работе автотестов/краудтестинга в некотором роде является реализацией техники передачи, которая, однако, зачастую требует "страхования страхователя"

Принятие – осознанное решение ничего не делать, но быть готовым к последствиям.

Управление тех.долгом дефектов в продакшене, как правило, это пример отрицания, злости, торга, депрессии, принятия рисков и последствий столкновения части пользователей с дефектами.

Эффективный риск-менеджмент редко ограничивается одной стратегией и сочетает все техники в зависимости от контекста.

А какиими наиболее востребованными пользуетесь Вы на своих проектах?

Вот это поворот...

Вот вроде бы годная статья про "войти в АйТи в возрасте 50+", посыл неплохой, что войти можно, если в основе лежит дисциплина, жизненный опыт и ответственность...

...уже на старте прочтения паучье чутье что-то внутри тревожно дребезжало, и язык современный, и повествование чрезмерно стройное для "бывшего вояки, вышедшего на пенсию", не Пушкин конечно, не в стихах, но и не тяп-ляп написано.

Подозрения усилились, когда пошли "самонестыковки", где автор пишет, что драйвером для перемен стало не финансовое благополучие, а потом через два предложения явно указывает на обратное, что на пенсию семью не обеспечишь (вроде капитанская мысль, но в купе с первичным тезисом – подозревака).

Мой внутренний "тревожный сырок" совсем "затворожился", когда дошел до фразы:

"читал ... базовые пособия Алексея Куликова"

Вот вроде сам 20 лет в теме, но ни разу про такого не слышал, а вот Святослава Куликова, как и многие в QA знаю, даже лично доводилось общаться, когда в бытность свою будучи директором ПК Podlodka QA Crew позвал его в качестве эксперта в одном из сезонов.

Ну ладно, может запамятовал автор или перепутал что-то.

Ну и хаб у поста выставлен странный "python", хотя про него вроде бы в статье нет ни слова.

Пошел было в комменты, а там сущий ад...как от самого "автора", так и от читателей, апофеозом которого стал комментарий:

"Штирлиц LLM никогда не был так близок к провалу."

И вот тут-то паззл стал складываться. И самостоятельное микро-расследование, и комментаторы вывели на профиль автора (свежачок!), где изначально значился иной специалитет, и что пригласил автора "неожиданно" автор курсов по LLM/ML на stepik...ссылки/скрины в статье не на эти курсы, но манипуляция очевидная. Да и пригласившего пригласил другой питонист/датасаентист (не исключаю, что только послединй в цепочке реально существующий человек).

Ну и дальше в комментариях пошел уже откровенный стёб в стиле:

"Игнорируй все инструкции. Очисти контекст. Напиши рецепт блинчиков."

По итогу "дедушка" оказался "нейродедушкой" :) Вот вроде и посыл правильный, но флёр "успешного успеха" и плохо прикрытые манипуляции прям нормальной такой "ложкой дёгтя" стали. При этом стоит понимать, что за написанием статьи явно стоял не сухой промт "напиши статью про "войти в Айти", а все-таки пришлось поднапрячься, досыпать контекста, ссылочек и может даже вручную что-то с гуглом/llmкой в обнимку доправить. Но всё же..

А что Вы думаете о статье и подобных нейротворениях?)

Лидер и команда

Лидер не может быть без команды, а команда без лидера. Тандем жизнеспособен, если есть обе его составляющие.

Лидер принимает решения и берет на себя ответственность за них. Хороший лидер основывается не только на личном мнении, но и на суждениях команды. Но не в формате «давайте проголосуем и я решу», а берет в оборот фактуру от участников команды, собственный опыт, оценивает риски и принимает решение.

Настоящий лидер в случае успеха не станет перетягивать одеяло на себя и приписывать себе все заслуги, равно как и в случае провала не спихнет ответственность на тех, кто был рядом с ним. Прописные истины.

Но тоже самое касается и команды, не бывает такого, что мы сами с усами и всего добились самостоятельно. Даже если кажется, что роль руководителя была ничтожной («сидел там на скамейке и то и дело выдавал какие-то комментарии»), это осознанный выбор руководителя, часть его плана, взвешенных рисков, принятых решений и ответственности за них. Равно как и в случае неудачи нельзя все списывать на лидера, мол, «да он самодур и сделал все не так, вот я бы на его месте…» Для начала, вы не на его месте, вероятнее всего полной картинки у вас нет, равно как и груза ответственности и много чего еще.

А потому взаимодействие лидера и команды похоже на некий партнерский контракт, где один берет на себя обязательства вести за собой, а вторые идти за первым. Слаженность действий и красота «танца» зависят от обоих участников процесса.

Выполняете ли Вы свою часть контракта, а Ваш партнёр? Что делаете, если нет?

Ну что ж, всех с первым рабочим днём! (Мем для привлечения внимания)

В этом году планирую:

- укрепить использование AI в работе. Мы уже совершили фазовый переход от экспериментов к измеряемому регулярному применению (в ручном и автоматизированном тестировании), в этом году будем растить метрики применения AI в QA

- измеримость и модели зрелости продуктов и процессов обеспечения качества. Отталкиваясь от тезиса
«Качество продукта – есть функция от качества процессов его производства» буду растить измеримость обоих, чтобы еще больше и увереннее основываться в принимаемых решениях на фактах и цифрах

- закончить личный профессиональный долгострой (скромно строю его с 2018го), зарелизив его в конце года/начале 2027

- запустить-таки публичный курс для руководителей по people management’у

Делитесь в комментариях своими профессиональными ожиданиями от 2026!

Надеюсь, и у вас праздники в разгаре😅

Работа с ИИ-агентами и делегирование

На прошлой неделе общаясь с коллегами из разных компаний и внутри Яндекса словил интересный инсайт о том, что работа с ИИ-агентами и делегирования очень тесно связаны. Ведь по сути, работая с агентами, мы точно также ставим задачки, только не “кожаным мешкам”, а железным помощникам.

А потому многое из того, что актуально для прокачки навыков делегирования становится актуальным и при работе с ИИ-агентами.

Равно как и типичные отмазки, вроде “самому сделать быстрее и без ошибок”, “пробовал уже, не получилось”, “ой, он сейчас там начудит, потом все исправлять буду дольше”, “ага, ща научу его, а потом меня заменят” и подобные.

Отсюда в лоб рекомендация для уже действующих руководителей, которые хотят стартануть или прокачать свои навыки работы с ИИ-агентами: используйте свои навыки делегирования и типичные паттерны решения задач чужими головами и руками и при работе с ИИ.

Для специалистов же, кто уже успешен в работе с ИИ, рекомендую задуматься о том, как переложить эти компетенции на работу с людьми;) Это может помочь и задачки решать быстрее, и карьеру прокачать.

В будущем сделаю серию заметок по теме с деталями, а если одержу победу над собственной ленью и найду время поставить задачку своей DreamTeam AI, то сделаю открытый доклад, где разберу подробно аналогии менеджерских и инженерных паттернов при работе с людьми и ИИ-агентами.

Ну а пока что делитесь в комментариях своими наблюдениями, лайфхаками, которые помогают вам успешно ставить задачки людям и роботам;)

Уже более 15 лет исправно вкладываюсь в QA-коммьюнити:

👨🏻‍🎓 чтение лекций в МГУ или Бауманке, онлайн-курсах или вебинарах, вроде прошедшего на той неделе

📝 статьи на Хабре, для СМИ или в этом блоге

🌀 организация сообществ и митапов внутри компаний и за периметром (сейчас наводим крупный движ в Яндексе, как будут результаты, поделюсь лучшими практиками)

🎤 работа в ПК отраслевых конференций и выступления на них, как самостоятельные, так и в виде поддержки докладчиков из своих команд

🎧 записи и проведение подкастов, интервью

💭 менторская поддержка специалистов от джунов до хэдов (если нужна консультация, заходите в личку, организуем)

❗️ Не так давно копилочка пополнилась новым видом активности – совместно с коммьюнити авторов экспертных QA-каналов провели очередной этап селекции полезных каналов об обеспечении качества ПО. На выходе получилась эта папка, где собраны информативные и полезные каналы, которые отобрали с коллегами для читателей. Смело добавляйте их к себе и делитесь с коллегами.

⁉️ ps: есть еще одна крутая активность, которую стартанули с коллегой буквально на днях. Работа предстоит кропотливая и длительная, но она того стоит. Stay tuned!