Десятая статья про модели личности https://vc.ru/hr/1093766 «Спиральная динамика, Big Five и другие модели ценностей» посвящена ценностным моделям. Как я отмечал в статье «Внутренняя сцена и объективная реальность», именно ценности и убеждения определяют спектакль на нашей внутренней сцене, они оценивают наши поступки, окрашивают происходящее в сияние света или покрывают тьмой. Это касается как конструирования будущего, так и оценки произошедшего. И для понимания других нужно уметь понять, как они оценивают происходящее, в какой цвет окрашены события в их спектакле. И, хотя каждый человек уникален, оказывается, что есть модели, которые хорошо позволяют в этом разобраться. Самая известная ценностная модель – спиральная динамика, но есть и другие: Герчикова, Громовой-Терентьевой, Алексея Кулакова и другие. И, что интересно, в числе ценностных моделей – распространенная модель Big Five, которая тоже по факту описывает ценности человека, и через них – его психологию и поведение. Полное оглавление серии https://mtsepkov.org/Self-Det

Одиннадцатая статья про модели личности https://vc.ru/hr/1117480 «Адизес, Белбин и другие модели команды и руководства» показывает, как эти модели встраиваются в комплексную модель личности. Часть моделей были затронуты в предыдущей статье, посвященной ценностным моделям, а также статье по MBTI. Подробного рассказа про сами модели в статье нет. Однако, при подготовке я вспомнил, что четыре года назад писал обзор истории развития моделей руководства https://vc.ru/hr/145616 «Руководство и лидерство — спектр представлений». Думаю, эта статья завершает серию. Полное оглавление – на моем сайте https://mtsepkov.org/Self-Det. В планах – опубликовать книгу на основе этой серии статей, доработав материал на основе тех обсуждений, которые были в ходе публикации.

Сегодня и завтра в Иннополисе на #mergeconf Интересно, 11 треков. Нестабильной инет не даёт публиковать впечатления онлайн, ждите отчёта. Мой доклад - про самоопределение, презентация выложена у меня на сайте https://mtsepkov.org/SelfDet-Merge там же ссылка на предыдущий доклад по теме с видео

В выходные впервые был на MergeConf в Иннополисе. Живая конференция, хорошие доклады, оперативно публикую отчет https://mtsepkov.org/MergeConf-2024

#sqadays Ольга Ерина из red_mad_robot. Техника SEMAT в управлении качеством ПО. У меня очень интересное впечатления от доклада. С одной стороны, было впечатление поверхностного изложения. Но в конце как раз получается, что SEMAT был использован именно так, как сейчас позиционируют авторы: как легкая система поверх существующих процессов, которая наводит фокус на продвижение по проекту. При том, что применять можно поверх любой методологии, и не только в профессиональной работе, но и для личных проектов.

Да, для тех, кто не в курсе, SEMAT - это назваание рабочей группы во главе с Иваром Якобсоном, которая начала делать эту конструкцию, а позднее они пришли под крышу OMG (Object Management Group), и более известен как OMG Essence или полностью The Essence of software engineering, есть книга Ивара, стандарт OMG и большая библиотека практик на сайте Ивара, достпная при регистрации.

В рассказе Ольга пробежалась по конструкции SEMAT - 7 альф, параллельное движение их по состояниям в ходе проекта, и интегральное измерение продвижения проекта в целом, исходя из каждой альфы. На слайдах были конкретные таблицы workflow, при чем не для програмной системы целиком, а отдельно для тестировщиков, когда есть отдельная команда тестирования, которая, получается, делает автономный проект, включенный в более крупный, при том что спринты у них общие. Конструкцию с автономным тестированием рассматривают редко. И там отдельно был фокус на альфу технологий, которую разбирают редко.

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

Что я бы полагал важным. Ольга советовала не рассматривать альфы, на которые нет вдияния. Я бы полагал, что их тоже имеет смысл включать в рассмотрения. Дело в том, что исследования SEMAT выделили этот набор альф по принципу минимальной необходимости: провал по одной из них приводит к провалу проекта. И даже если у вас нет прямого влияния, вы будете видеть, где именно проект поджидают нежданчики. И, по принципу системного подхода, стоит смотреть альфы для системы и для ее надсистемы, в данном случае - для проекта в целом и для тестирвоания в проекте. А для жизни - смотреть на конкретный проект и на его включения в жизнь в целом. Что было, но явно не акцентировано и без показа связи.

Еще интересно, что хотя OMG Essence появился давно, и Ивар дважды приезжал на SECR в Россию, рассказывал про конструкцию, тема для участников - новая, и из зала было много вопросов. Я надеюсь, что это может привести к новой волне интереса. Я сам использовал ее с в докладах примерно с 2015 года, можно посмотреть доклад https://mtsepkov.org/BigPicture-PM-IT, статью https://vc.ru/hr/103212 и другие материалы на моем сайте., включая конспекты докладов Ивара.

#sqadays Андрей Мясников. Я люблю свою работу, я приду туда в субботу! Доклад про то, как не выгореть, заметив симптомы на ранних стадиях. Как всегда от Андрея - хороший и живой. В начале предупреждение: если у вас уже все серьезно, обратитесь к специалисту, в докладе - про профилактику.

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

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

У Андрея есть своя классификация, он рассказывал на SQAdays-13 (я нашел по конспекту https://mtsepkov.org/SQAdays-2013a):
* одноразовые: прогнал ПМИ, посетил конфу.
* итеративные, регулярные - чистить зубы,
* внезапные - прилетают вдруг.
* волшебные - они любимые.
Выяснилось, что сотрудник работал только на одноразовых и итеративных. И ему скучно. Ему стали давать внезапные - стало лучше, человек раскрылся, она потом стало пускать на тушение пожаров - и ему нравится. Вывод: определитесь, какой тип задач нравится больше всего, и следите, чтобы было.

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

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

Рефлексия проблем. Он это не сделал сразу и потерял несколько дней и душевное спокойствие. 5 почему и другие техники. Почему вчера было хорошо, а сегодня - не очень? Что изменилось? Как прошел денек? Если остался осадок - то от чего?

Выгулять лень. Останьтесь дома и не делайте вообще ничего, не тратьте мыслетопливо. В идеале - не готовьте. Побежите как угорелый. А если нет - полежите еще.

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

Съешь лягушку. Сделайте самое плохое дело первым. Если вы пробежали несколько километров, хуже не будет.

Отдых - часть работы. Восстановление. 8-часовой рабочий день не просто так придуман. Если у вас выходной и вы вызываетесь помочь - не надо. Если инструмент затупился - его выбрасывают. Точите себя как инструмент, отдых - это такое время.

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

Презентация моего доклада на моем сайте https://mtsepkov.org/SoftSkillSQA Там же ссылки на предыдущие доклады по теме.

#sqadays Екатерина Глушанина из 2ГИС. Как внутренние активности помогают расти и поддерживать бодрость духа. С моей точки зрения, этот доклад - очень хорошая иллюстрация того, как одни и те же события приводят к совершенно разным последствиям. У всех был ковид и переход на удаленку. У очень многих при этом появилось больше чатов, например, общий чат в дополнение к командным. Но вот то, что из общего чата, на основе анализа общения там, проросло много различных активностей: литклуб, докладо-клуб, митапы, мастер-классы - это исключение. Хотя, казалось бы: если люди задают вопросы, то обобщить и попробовать эти проблемы порешать - вполне понятная штука. Рассказ был как раз о том, как прорастали разные активности. Литклуб - из обсуждений книг, которые были на слуху, он хорошо стартовал, а потом общие книги кончились. Доклад-клуб - из обсуждения докладов на конференциях, они не кончаются. Типовые проблемы команд породили митапы по обмену опытом их решения. Мастер-классы - из проблем, по которым есть эксперты являются узким горлом. Пошло очень хорошо, и даже календарь оказался перенапряжен - они сделали опрос от чего отказаться, общее мнение было, что встречи полезны, но как урок - они начали делать регулярный дайджест, выявлять проблемные точки, и делать мероприятия только по реальным причинам. В целом - хорошо.

#sqadays Дмитрий Щербаков из BelkaCar. За кулисами каршеринга: тестирование автомобилей. В докладе был рассказ, как устроено тестирование управлением автомобиля в каршеринге. Я лично услышал из доклада, что тестирование автомобиля ничем принципиально не отличается от тестирования другой работы с интеграции с оборудованием, которое, в свою очередь, близко к тестированию интеграции. Может, это субъективно. Тестирование работы с оборудованием я представляю, мы делали работу с оборудованием для розничным магазинов, там на кассе до пяти разных внешних устройств, с разными протоколами, а важно, чтобы все работало. А интеграция тоже похожа, особенно когда там внешняя система, которую иногда сложнее подключить в тестовом контуре, чем внешнее оборудование. И да, используем эмуляторы, иногда с обеих сторон.

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

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

#sqadays Наталья Савостюк. Как экологично влиять на изменение своего оклада? Доклад был вчера, но я не успел опубликовать. У Натальи 90 человек в отделе, и большой опыт разбора ситуаций с окладами. На основе опыта - пять обобщенных персонажей, типичных представителей у которых есть проблемы с окладами. И особенности ситуаций с каждым.

1. Недооцененный Мидл+, хорошо работает для своих задач. Не имеет целей развития, когда говорит - потому что так принято, плана развития нет, либо по нему не идет. Закрыт эмоционально, на разговорах 1:1 - все хорошо. А потом уходит, а в кулуарах оказывается, что он считает, что он недооценен, успехи не замечают. А вопрос: как замечать, если ты об этом не говорит.

У нее психологическое образование, она может раскрутить, но это много сил и она спец, у других - такого нет. Если руководитель через кулуарные разговоры узнает проблемы, зовет поговорить про план развития - а тот говорит "на работе времени нет, а потом - домашние дела." План развития договоренность, если сотрудник нарушает - почему руководитель должен стараться? Тут надо отметить, что обычно те, кто хотят развиваться - находят время. Мидл+ с высокой вероятностью сам достаточно свободен в распределении своего времени. Он его не выделяет, и обижается на компанию, что времени не дают.

Так как задачи выполняют хорошо, руководитель сам ищет повышение. Спрашивает "а сколько" - ответ - "я не знаю, сами оцените". Вопрос ожиданий тут важен, потому что на небольшую индексацию руководители часто готовы, а с большой им часто непонятно. А, с другой стороны, если у него ожидания большого повышения, то озвучив небольшое можно получить обиду. Вообще люди из этой группы ожидают повышения 10-15% "на инфляцию", даже в долларах или евро :) Индексировать по инфляции - право компании, но обычно не предмет договоренностей, не автомат. Правда, замечу, что если на рынке - рост, даже независимо от инфляции, то без такой индексации люди будут уходить.

2. Амбициозный. Junior+ поработал год-полтора, был интенсивный рост и оно породил завышенные ожидания. На собеседовании просит оклад в 1.5-2 раза текущего, и хочет повышение на 20-30% каждые полгода. Через 2-3 года человек приходит к тупику - такого темпа роста точно не будет. Тут контрольные вопросы: а что ты сделал за последнее время, что нового принес - если ответа нет - то какие основания? Часто ответы: "я ответственный, внимательный, развивающийся", но это же характеристика любого хорошего сотрудника, почему это стоит +20-30% в полгода? Амбициозный персонаж часто берется за много дел, но вот доводит до конца - мало.

3. Рисковый. Он сходил и принес офер, говорит что хочет остаться. Делают контрофер. Но дальше будет релиз - и его уволят. В процессе релиза бизнесу надо закрыть задачи. И работают на удержание. А вот после релиза есть фаза маркетинга, и раскрутки. Бизнес начинает экономить - и увольняет таких дорогих.

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

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

5. Матерый. Группа проектов или ресурс-менеджер. Сам может выстроить путь развития, найти пространство работы. Цели ставить не нужно. Но он тоже может столкнуться с проблемами по зарплате, и она связана с тем, что руководитель может просто выпустить закрытый им сектор из поля зрения, полагая что там стабильная регулярная работа, в то время как у сотрудника там реальный рост сложности решаемых задач и достижения. И тут ему надо уметь показывать свои достижения, и рост ценности для компании.

Подводя итоги, как действовать.
1. Сформулируйте ожидания: какой доклад хочу, когда я его хочу? Какой разрыв? Что я готов сделать ради этого?
2. Подумайте, насколько реалистична такая разница в заданный срок с учетом обстановки в стране, ИТ, вашей отрасли, вашей компании - может, надо менять? При этом у любой компании есть периоды сложностей и хорошие. Осознали - скорректируйте ожидания.
3. Сходите к руководителю и озвучьте спокойным текстом все, что обдумали. И обсудите - может что еще надо.

И замечания по проблемным кейсам.
* Надо понимать, что если был план, вы его игнорили, а в конце года начали делать - будут вопросы. Оклад - за изменения в работе, а вы просто доделали план, изменений не было. Разовая работа, например, конфа - премия. Чтобы оклад - можно стать амбассадором. Изменение - на постоянной основе. Не один онбординг, а обязанность.
* Есть кейс, когда тебя взяли на оклад с ожиданиями, ты не умел, наконец обучился - это не повод повышать, ты просто наконец-то делать то, для чего брали.
* Изучил новое, но ненужное для проекту - неясно, профита-то нет.

Подводя итоги: говорите о своих изменениях через ценности для бизнеса. Вы сами управляете жизнью. Нет правильных и неправильных цифр. Управляйте своим путем. И будьте довольны окладами.

В ответах на вопросы был разбор кейса, когда приходят дяденьки из бизнеса с якобы разовой задачей. А потом оно прилипает, ты не разговаривал, потому как разовое. Ответ Натальи: хотел бы такой оклад, за последний год стал делать вот это и получил ценность для бизнеса. Не копить обиду, а поговорить. И принять ответственность за то, что на входе не договаривался. Тут могут быть сложные переговоры, их надо уметь вести.

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

#sqadays Олег Королев и Анастасия Радужная из Ростелеком. Влияние QA сообществ на развитие ценностей в компании. Рассказ - success-story о запуске сообщества тестировщиков. Это - не первая попытка, но 1.5 года назад сообщество запустилось, и за это время были успешные проекты:
* единая методология
* единый базовый онбординг
* школа тестеров - для внешних, рост джунов и 3 месяца стажировки, ребята сами вызвались быть менторами: 280 заявок, 35 взяли, 22 дошли до финала, 10 человек на стажировки и их берут работать
* экспертная группа, готовая выступать на конференциях
* внутренние продукты - разработка в рамках импортозамещения инструментов для тестирования, сообщество дает фидбэк

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

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

QA - первое сообщество компании. Они катализировали появление сообществ - архитекторы, СУБД, Devops. Я тут хочу отметить, что в рамках компании воспроизводится ситуация с отрасли: сообщество тестировщиков было 10 лет назад одним из первых организовавшихся и самым активным, я это помню по истории конференции SQAdays.

#sqadays Нэлля Сердюк и Алексей Алешин из Ростелеком ИТ. Продукт, который можно "пить". Название - из метафоры очистки воды. А проект - про тестирование порталов видеонаблюдения за ЕГЭ и выборами. Но в рассказе специфики проекта не было, был рассказ про реорганизацию процесса и используемые практики. И я из их числа хочу отметить не очевидную реорганизацию: они откладывают описание тест-кейса до стабилизации задачи, а до этого работают по чек-листам. Это дает относительную легкость изменений и убирает фактор сроков - тест-кейс можно описать и после выкатки срочного функционала в прод, в режиме устранения тех.долга. При тестировании новой фичи чек-листа хватает, так как тестировщики в контексте: команда знакомится с задачей на груминге, и ее помнят, а вот при регрессе проверяют сделанное давно, и важно хорошее описание, чтобы регресс мог провести любой из тестировщиков. Это описание собирают на основе чек-листов и финальных комментариев тестировщика по каждому тестированию, которые тоже является обязательным для каждого такта тестирования и должен описывать - что было проверено с техникой. Груминг для знакомства с задачей был новой практикой, казалось бы. он дает накладные расходы, но реально он сокращает количество возвратов задач, когда ТЗ поняли неверно и делали не то. Я тут хочу заметить, что ненадежность передачи через артефакты из-за того, что тексты трактуют по-разному была осознана уже больше 20 лет назад, это - одна из предпосылок agile-методов, но те, кто создают процессы почему-то по-прежнему верят текстовым описаниям, практики коммуникации типа груминга появляются позднее и далеко не везде...

#sqadays Алексей Петров, Одноклассники. Индивидуальные планы развития на базе матрицы компетенций. Цели индивидуального развития: рост знаний и компетенций, карьерный рост, рост финансового вознаграждения, увеличение вариативности развития. Но! куда расти?
Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много.

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

В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя.

Калибрация самооценки. Руководителем, наставником или кем-то еще. Помните про эффект Данинга-Крюгера: компетентные недооценивают, а некомпетентные переоценивают. При калибровке - не устраивайте экзамен. Вы - наставник, ментор, а не судья.

Дальше выберите области улучшений. Сотрудник - сам выбирает, не руководитель. И не обязательно от слабых областей, можно от сильных. Не выбирайте все, 3-6 на полгода - достаточно. А вот дальше руководитель сопоставляет выбранное с потребностями бизнеса - и тут обсуждаем.

Дальше был проект прокачки с конкретным примером. Формат:
* прокачиваемые компетенции,
* описание проекта,
* пользовательские сценарии,
* бизнес-ценность
* точки поэтапного контроля (вехи)
* DoD
* артефакт
* в какую цель бьет
Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль.

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

Делаем 2-3 проекта, чтобы была вариативность, и по внешним связям, и по своему драйву.

Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.

Профит:
* сотрудник понимает кто он и куда идет
* руководитель тоже понимает это про сотрудника
* есть цели на год и квартал - можно сопоставлять с ИПР
* обоснование роста зарплаты - связь косвенная, но она есть, нужно и сотруднику и руководителю. Но проекты - они разовые, поэтому рост зп - не автоматический

Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее.

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

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

Вопрос. Есть тестировщик, который не хочет расти, ему нормально. Он написал ИПР, чтобы быть "как все". Поставил в пару, один зажигает, другой нет. Тут помогут ОКР: тебе может норм, бизнесу - нет. Можно сделать портрет идеального тестировщика вашего подразделения.

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

Связь с грейдами. Если вы самооценку связываете с грейдами - выше риск, что вы в самооценке обманываете себя. И там будет экзамен, контроль. Так что прямая завязка усложняет конструкцию.

#sqadays Вадим Лунин и Вадим Зубович, Альфа-Банк (Беларусь). ИИ в тестировании: помощник, или угроза. ИИ уверенно переходит из фазы "посмотрим, что он может" в фазу "сделаем помощника и будем использовать". На Merge я неделю назад Газпромнефть рассказывал, как собрал ИИ-помощника для работы с вакансиями и подбор персонала, закрывающего полный цикл. А тут был рассказ об использовании ИИ для тестирования.

Для начала - история. ИИ начал входить в тестирование для частных задач.
* Автомат результата автотестов - Report portal - анализировал причины падений
* Self healing automation - чтобы тестовые скрипты проходили. Helenium и еще несколько
* Автоматические анализаторы performance. Yslow, PageSpeed - рекомендации по ускорению
* Обнаружение визуальной регрессии - наложение текста и картинок.
Каждый из инструментов - узкий и изолированный, он не встраивается. Подход - от инструмента. Приходит идея - и делаем нейросеть.

Дальше все гиганты начали делать комплексные решения. Отдали спеку - она все сделает. Поскольку заменяем отдел тестировщиков, лицензия стоит как отдел - а результат сомнителен.

Но появились большие языковые модели - универсальные инструменты. И тут получается история, аналогичная тому, что было 7 лет назад: был комплексный TestComplete для корпоратов за большие деньги, появился Selenium и сообщество быстро сделало инструменты. Так будет и здесь.

По направлениям - есть еще IDE-ассистенты - автокомплит на стероидах, работает неплохо. Тут он бы выделил Tabnine: начинаешь писать название метода - он выдает реализацию. И работает без VPN.

У банка ограничения - надо уметь развернуть локально. Они выбрали Llama, Mistral, Zephir. И еще Вихрь - русифицированный Mistral.

Направления
* генерация тестовой документации
* ревью кода автотестов (и вообще всех кодов)
* фазз-тестирование

Идея - порождать тесткейсы по спекам. Для начала ui-тест, по flow для мобилки. Ни одна из моделей результата не дала. Порождали обобщенные сценарии, не понимали язык. Но появилась saiga - русифицированная Llama-3, ей скормили спеку, где картинки описали текстом - и получили приемлемый результат. Еще UI запилили, куда кидаем спеку, из нее промпт идет

Бэкэнд-тесты - они проще UI, картинок нет.
* Llame-2 что-то сгенерировала, но по-английски, и там не тестовый сценарий, а какой-то ответ. И не учтен весь пользовательский путь.
* Zephir - получилось получше, похоже на описание шагов, по английски. И дописал сценарии, которые в спеке нет
* Mistral - лучше всех, по-русски, опознал полный путь. Но с промптами пришлось поиграться серьезно.
* Развернули Вихрь - тоже хорошо.

Планы: проработать спеки для UI, и еще чтобы alure, API - проработать интеграцию с инструментами типа swagger

Код-ревью. Просто попробовали отдать поруцию кода и pull request. Появился проект Alt-man review. дает pull request, пишет ответ комментарием в git. Но не взлетело - галлюцинации, неверный язык программирования

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

Фаззинг - шумовые данные, бомбардировка приложения чтобы найти утечки данных и крэши. Вышел OSS-fuzz от google - заточен на это, по задумке он сам все сделает. По факту - сам не может, тесты надо написать самим. oss-fuzz-gen - сморит коды и порождает, только для с++ - поэтмоу они пока не копали. И им им еще надо развернуть свой кластер, и обучить работать с их моделями GPT, а не с google. Это - в планах.

По горячим следам публикую отчет с #sqadays https://mtsepkov.org/SQAdays-2024a Кроме постов, которые я публиковал в ходе конференции, там пара докладов, которые были в конце и общие впечатления с конференции. Наиболее интересное для меня связано с использованием ИИ, которое перекликается с услышанным на MergeConf неделю назад: пока теоретики спорят, о том, что он может, а что не может, практики - используют.

В Питере возобновился IT Global Meetup. Для тех, кто не знает - это замечательное мероприятие, объединяющее IT-шников и организует его сообщество сообществ Piter-United.ru Один день, 15 сообществ, 50+ спикеров, 1000+ участников. Я был на нем в субботу и публикую отчет https://mtsepkov.org/ITGM-16_2024-05 Все выступления, на которых я был - интересные и очень разные. И много знакомых. Я унес с митапа интересный формат интерактива с залом, который был у Юрия Санникова и метод волшебных друидов для работы с ограничениями в TOC. А обсуждения нужны ли HR и нужны ли менеджеры дали фокусировку собственного понимания темы.

#AnalystDays Алексей Пименов. Социология на службе аналитика. В докладе - социологическая модель племени. Есть такое направление современной социологии - корпоративная антропология, которое говорит, что "на самом деле" современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.

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

Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.

Для начала: Мы с тобой одной крови. Идентичность. Американский психопат - визитки, меряются друг с другом. Одинаковые очки и костюмы - но они видят разницу и могут понять иерархию. Человек - которого они не пускают. Слова, одежда, жесты, рестораны. Не приходить во фраке к неформалом и наоборот.

Концепция V'ger - это из первого фильма star track. В любой компании есть история, связанная с технологией или чем-то ядерным - и нельзя нарушать. Microsoft - Basic, он во всех продуктах. Для компании - доменного регистратора все строится вокруг домена, хостинг и другие услуги пришли как развитие. И сейчас у них проблема с продуктами в телеграм, которые строятся без домена - как так, vger отсутствует. Узнайте, что является vger компании или команды, с которой взаимодействуете. Следующий шаг - понять дает ли это ограничение, или объединяет и что с этим делать.

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

Язык племени. Вам придется учить множество языков, это нормально. Где нам искать вещи с языком? Есть два места: столовка и курилка. Надо ходить и прислушиваться. Например, есть компании с фокусом на личной идентичности, а есть - на командной. И это очень четко проявляется. При этом в командной идентичности - часто проблемы с межкомандным взаимодействием. Команды доказывают свою правоту, конкурируют или борются.

Социальная сплоченность: в племени думаем одинаково. Спектр от хаоса до тоталитарной секты. Социальные инновации: способность группы выдать идею. Может ли сплоченная группа выдать идею? Хуже. Команду сначала сплачивают, а потом говорят - придумывайте. Они не могут. Со сплоченностью надо остановиться как только поняли общую цель, не идти до полного единомыслия. А если вы сотрудник, то оценив сплоченность вы можете понять, как предлагать инициативу. В одних командах - можно принести самому публично, в других - привлекать сторонников по-одному, в третьих - через руководителя. А когда принесли - можно практику сделать vger чтобы она сохранилась.

Про общего врага. Это не должен быть человек или другая команда, не играйте в игру против команды PVP, играйте PVE - против внешней среды, против рынка и так далее.

Ритуалы. Как искать общее в новой команде? Первое - отношения с каждым. Выявляем соуиальные группы - ВУЗ, хобби, проживание. Дальше - разматываем, создаем личный контакт. Когда с каждым личный выстроен - объединяем. Если общее. И против проблемы. И сам: можем побороться - поддержите. С удаленщиками искать общее на порядок сложнее. Возможно, игры, стриминг, телеграм-чатики.

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

Как узнать компанию? Познакомьтесь на конференции, пообщайтесь, посмотрите доклады - там язык проявляется. Подпишись если блоги.

Я в заключении хочу отметить, что методы корпоративной антропологии. с одной стороны, дают рабочую модель, но, с другой - искажают восприятие. В основе лежит убеждение, что человек живет в придуманной парадигме первобытного племени, живущего в PVP с другими племенами, с этим смириться и хитрыми приемами направить эту глубинную психологию в конструктив, например, превратив PVP в PVE. Штука в том, что это - в основе - та модель псевдопервобытного племени, которую придумали, когда обосновывали колониальной экспансии белых людей. Сейчас в антропологии идет отдельная история, когда исследователи сопоставляют эти модели с реальной практикой, но это - сложно. потому что племен не так много сохранилось, а при исследованиях всегда идет интерференция понятий. Опасностей для практике несколько: мы приписываем всем людям то, что свойственно лишь части; мы видим в реальности то, чего в ней нет, потому что наша призма восприятия так настроена. Это касается всех социальных моделей.

Слайды моего доклада - на моем сайте https://mtsepkov.org/SysThink-AD24