#DevOpsConf Сергей Реусин из СберМаркет. Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения. Это был доклад первого дня, на который я забыл опубликовать конспект. Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering, основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report. Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.

Это - интересный взгляд. Потому что в погоне за высокой доступностью часто применяют сложные и дорогие технические решения, и несут неоправданные затраты. В то время как альтернативные способы могут быть гораздо легче. Я тут поделюсь своим опытом. В свое время мы проектировали систему розничного магазина для Спортмастера, и спросили их - а могут же быть разные проблемы с работой системы: электричество, сеть и так далее. А они рассказали, что на этот случай есть план-Б: автономный сканер ШК (ТСД), в который загружен каталог с актуальными ценами, и который умеет фиксировать продажи, сканируя ШК, и простая дешевая касса, на которой можно пробивать чеки в автономном режиме и которая работает от обычного бесперебойника, и в результате при любых проблемах магазин 6 часов способен вести продажи. Что позволяет не слишком заморачиваться с доступностью именно информационной системы. И аналогичный подход у них дальше применялся при переходе на централизованную систему лояльности: при сбоях интернета владельцам карт предоставлялась специальная скидка, размер которой их обычно удовлетворял, так что проблемы не вызывали негатива. И как побочный эффект такое решение снижало требования к доступности централизованной системы лояльности - план-Б со специальной скидкой работал и в этом случае.

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

Узнал тут, что Школа Сколково проводит исследование по практикам проектного управления. Как пишут на сайте, задача — собрать комплексное представление о применяемых практиках, найти новые успешные, которые сложились в ответ на современные вызовы, а также проблемные точки для того, чтобы дальше совершенствовать обучение управлению проектами.

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

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

В начале марта был на конференции #DevOpsConf. Полторы тысячи офлайн-участников, Сколково, много информации и общения. Я, как обычно, вел публиковал заметки с докладов, и сейчас собираю их в отчет https://mtsepkov.org/DevOpsConf-2024 Наиболее интересен для меня был доклад Игоря Курочкина про NextOps - то, что придет следом за DevOps. В нем была концепция Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их.

Сегодня на #Agiledays - смотрю, что происходит с современным менеджментом. Первый доклад Mirko Kleiner. Scaling Agile Across Companies. Речь шла про принципиальное изменение парадигмы взаимоотношений с поставщиками, переходе от закупок по спецификации к партнерству в условиях непрерывных изменений - Lean-Agile Procurement. В докладе было не систематичное изложение подхода, а набор кейсов, которые иллюстрируют изменение, отличие от традиционного.

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

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

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

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

Дальше кейс выбора поставщика ERP. Был сделан за два дня, обычно - год. Но до этого был первый такт, когда выбрали решение, а тут выбирали поставщика решения. Команда - бизнес, финансы, закупки, ИТ, HR. Команда сделала short list из трех поставщиков - и их всех пригласили на 2 дня поработать в одной комнате, совместно спроектировать контракт, а если получится - попробовать сделать прототип. Три конкурента в одной комнате. Индивидуальные разговоры по контрактам тоже были - но ограничено, и итоги их влияли на проект. В результате был выбран один из вендоров, и еще конкретный человек от другого вендора. В результате выбрали вендора А + конкретного человека из вендора Б. Аналогичный кейс делали для Roche, и там был онлайн. Общая сессия и отдельные, и в жюри люди из разных компаний. Работает не только с ИТ, но и с поставками оборудования, такие кейсы тоже есть. Важно что вы переходите с людьми в режим совместного создания проекта и оцениваете их с этой точки зрения.

Аналогично можно делать программы улучшений - был кейс AGCO - производители сельхозтехники. Разобрали трактор на части, позвали маркетинг, конвейер, поставщиков и спросили: что можно улучшить? Совместное творчество. И с разработкой вакцин против ковида - Pfiser и Biontech. Согласовали правила управления, разделения затрат и прибыли, запустили работу. По результатам спросили себя: почему раньше не делали таким образом?

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

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

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

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

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

В пятницу был на конференции #Agiledays. Как всегда, интересное содержание и много нетворкинга, так что в ходе конференции получилось опубликовать заметку только по одному выступлению. Поэтому оперативно собрал и публикую отчет https://mtsepkov.org/AgileDays-2024 На конференции появилось ощущение, что происходит некоторый поворот, смена парадигмы, может быть, не меньший, чем в начале 2010-х, когда agile лишь завоевывал позиции. Он требует осмысления, и в отчете я это попробую сделать. А если говорить о докладах, то мой выбор - выступление Анны Обуховой про сверхцели, Мирко Кляйнера про переход с поставщиками в партнерскую позицию и Алексея Вебера про счастливое лидерство и Дмитрия Годунова про мегапроекты. И еще был круглый стол по самоуправлению, который шел параллельно с Обуховой, поэтому я на него не попал, так что рассказываю кратко по презентации и обсуждению в кулуарах.

Десятая статья про модели личности 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 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.

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

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

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