Девятая статья про модель личности https://vc.ru/hr/1068280 «MBTI: представляем мышление непохожего» посвящена типологии Майерс-Бриггс, которая, на мой взгляд, является лу4чшей моделью, позволяющей понять мышление другого, не похожего на тебя человека, представить спектакль жизни на его внутренней сцене. А это – совершенно необходимо для эффективной коммуникации и взаимодействия в команде различающихся людей, которые, по исследованиям Белбина, сильнее однородных команд. Этой статьей я начинаю разбор психологических моделей, сопоставления их с базовым уровнем моделей личности. Полное оглавление серии https://mtsepkov.org/Self-Det
vc.ru
MBTI: представляем мышление непохожего — Карьера на vc.ru
Как было показано в статье «Внутренняя сцена и объективная реальность», наше поведение определяется не столько объективной реальностью, сколько спектаклем, разыгрывающимся на нашей внутренней сцене: оценка происходящего и планирование будущего происходит…
👍3❤1
Узнал тут, что Школа Сколково проводит исследование по практикам проектного управления. Как пишут на сайте, задача — собрать комплексное представление о применяемых практиках, найти новые успешные, которые сложились в ответ на современные вызовы, а также проблемные точки для того, чтобы дальше совершенствовать обучение управлению проектами.
Ведет исследование Павел Алферов, которого я много лет знаю как одного из ведущих российских специалистов по управлению. История очень полезная для индустрии: результаты будут обработаны и опубликованы, так что ваше участие — для общего блага.
Поделитесь, как вы вели проекты за последние пару лет, пройдя опрос по ссылке Негативный опыт тоже приветствуется.
Ведет исследование Павел Алферов, которого я много лет знаю как одного из ведущих российских специалистов по управлению. История очень полезная для индустрии: результаты будут обработаны и опубликованы, так что ваше участие — для общего блага.
Поделитесь, как вы вели проекты за последние пару лет, пройдя опрос по ссылке Негативный опыт тоже приветствуется.
Бизнес-школа СКОЛКОВО - бизнес-образование, бизнес-обучение в Москве
Исследование «Современные практики управления проектами 2022-2024»
👍3❤1
В начале марта был на конференции #DevOpsConf. Полторы тысячи офлайн-участников, Сколково, много информации и общения. Я, как обычно, вел публиковал заметки с докладов, и сейчас собираю их в отчет https://mtsepkov.org/DevOpsConf-2024 Наиболее интересен для меня был доклад Игоря Курочкина про NextOps - то, что придет следом за DevOps. В нем была концепция Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их.
🔥7
Сегодня на #Agiledays - смотрю, что происходит с современным менеджментом. Первый доклад Mirko Kleiner. Scaling Agile Across Companies. Речь шла про принципиальное изменение парадигмы взаимоотношений с поставщиками, переходе от закупок по спецификации к партнерству в условиях непрерывных изменений - Lean-Agile Procurement. В докладе было не систематичное изложение подхода, а набор кейсов, которые иллюстрируют изменение, отличие от традиционного.
Рассказ начался с кейса из автопрома. Автопроизводители прогнозировали падение спроса, сократили производство и покупку комплектующих. И компании, производящие чипы, переориентировались на другую продукцию, другие чипы. И когда спрос начал восстанавливаться, то оказалось, что разместить заказ на чипы невозможно, и это была реальная проблема, у некоторых компаний пришлось до 300к автомобилей поставить на стоянки в ожидании поставок. Тесле было легче. Она - вертикально интегрированная, и в этих условиях легче маневрировать, и она меньше сократила производство. Но чипы она все равно заказывает - и тут она решила проблему за счет внутренней гибкости, она не придерживалась стратегии единого поставщика, а искала варианты с разными чипами, даже если под них приходилось адаптировать и переписывать софт.
Кстати, хочу заметить, что такая разница между Теслой и всеми остальными автопроизводителями понятна: Тесла делает инновационный продукт, и у них - другие требования, которые обычные поставщики обеспечить не могут. Также было у Форда, когда он делал свой конвейер: он был вынужден включить в группу производство стали и резины для шин и других деталей, потому что требования к количеству и качеству принципиально отличались.
Следующий кейс - Haier. Компания, которая была обычным производителем бытовой техники, а потом - принципиально изменила свою структуру. В ней десятки тысяч сотрудников. И она состоит из набора команд, каждая из которых действует как микропредприятие со своей экономикой, связанная горизонтальными связями и мини-контрактами с другими. И это синхронизируется каждый месяц, поэтому очень подвижно. Два года назад компания открыла свою экосистему наружу, разрешив командам заключать контракты с внешними поставщиками, а также открыв возможность внешним участникам приносить свои идеи. А трансформацию вроде делала Сазерленд.
Компания LightYear - около 1000 сотрудников, создание автомобиля на солнечной энергии. Обычный цикл разработки автомобиля - классический водопад. Проектирование, потом заказ разным поставщикам комплектующих и оборудования для сборки. И это - длинные циклы. Например, корпус - заказ станка, который штампует корпус - около 2 лет, и он будет штамповать тот корпус, под который спроектирован. Им это - долго. И когда проект будет - неясно. Они собрали команду, и еще позвали туда поставщиков - можно ли с этим что-то сделать. Ответ был - можно, есть оборудование для создания прототипов, а не промышленного производства. Оно много дешевле. Но оно - недолговечное, если ставить на линию - то максимум месяц. И они решили, что это им и нужно, можно часто пробовать новые варианты. Но это решение - результат совместной работы, решение было найдено коллективно командой, которая взяла ответственность за весь продукт. Взаимодействие при этом строится по партнерской схеме совместной деятельности, а не классической цепочки поставки. Границы компаний размылись, контрактование пришлось сильно переработать, но это возможно.
Рассказ начался с кейса из автопрома. Автопроизводители прогнозировали падение спроса, сократили производство и покупку комплектующих. И компании, производящие чипы, переориентировались на другую продукцию, другие чипы. И когда спрос начал восстанавливаться, то оказалось, что разместить заказ на чипы невозможно, и это была реальная проблема, у некоторых компаний пришлось до 300к автомобилей поставить на стоянки в ожидании поставок. Тесле было легче. Она - вертикально интегрированная, и в этих условиях легче маневрировать, и она меньше сократила производство. Но чипы она все равно заказывает - и тут она решила проблему за счет внутренней гибкости, она не придерживалась стратегии единого поставщика, а искала варианты с разными чипами, даже если под них приходилось адаптировать и переписывать софт.
Кстати, хочу заметить, что такая разница между Теслой и всеми остальными автопроизводителями понятна: Тесла делает инновационный продукт, и у них - другие требования, которые обычные поставщики обеспечить не могут. Также было у Форда, когда он делал свой конвейер: он был вынужден включить в группу производство стали и резины для шин и других деталей, потому что требования к количеству и качеству принципиально отличались.
Следующий кейс - Haier. Компания, которая была обычным производителем бытовой техники, а потом - принципиально изменила свою структуру. В ней десятки тысяч сотрудников. И она состоит из набора команд, каждая из которых действует как микропредприятие со своей экономикой, связанная горизонтальными связями и мини-контрактами с другими. И это синхронизируется каждый месяц, поэтому очень подвижно. Два года назад компания открыла свою экосистему наружу, разрешив командам заключать контракты с внешними поставщиками, а также открыв возможность внешним участникам приносить свои идеи. А трансформацию вроде делала Сазерленд.
Компания LightYear - около 1000 сотрудников, создание автомобиля на солнечной энергии. Обычный цикл разработки автомобиля - классический водопад. Проектирование, потом заказ разным поставщикам комплектующих и оборудования для сборки. И это - длинные циклы. Например, корпус - заказ станка, который штампует корпус - около 2 лет, и он будет штамповать тот корпус, под который спроектирован. Им это - долго. И когда проект будет - неясно. Они собрали команду, и еще позвали туда поставщиков - можно ли с этим что-то сделать. Ответ был - можно, есть оборудование для создания прототипов, а не промышленного производства. Оно много дешевле. Но оно - недолговечное, если ставить на линию - то максимум месяц. И они решили, что это им и нужно, можно часто пробовать новые варианты. Но это решение - результат совместной работы, решение было найдено коллективно командой, которая взяла ответственность за весь продукт. Взаимодействие при этом строится по партнерской схеме совместной деятельности, а не классической цепочки поставки. Границы компаний размылись, контрактование пришлось сильно переработать, но это возможно.
👍5🔥1
Дальше кейс выбора поставщика ERP. Был сделан за два дня, обычно - год. Но до этого был первый такт, когда выбрали решение, а тут выбирали поставщика решения. Команда - бизнес, финансы, закупки, ИТ, HR. Команда сделала short list из трех поставщиков - и их всех пригласили на 2 дня поработать в одной комнате, совместно спроектировать контракт, а если получится - попробовать сделать прототип. Три конкурента в одной комнате. Индивидуальные разговоры по контрактам тоже были - но ограничено, и итоги их влияли на проект. В результате был выбран один из вендоров, и еще конкретный человек от другого вендора. В результате выбрали вендора А + конкретного человека из вендора Б. Аналогичный кейс делали для Roche, и там был онлайн. Общая сессия и отдельные, и в жюри люди из разных компаний. Работает не только с ИТ, но и с поставками оборудования, такие кейсы тоже есть. Важно что вы переходите с людьми в режим совместного создания проекта и оцениваете их с этой точки зрения.
Аналогично можно делать программы улучшений - был кейс AGCO - производители сельхозтехники. Разобрали трактор на части, позвали маркетинг, конвейер, поставщиков и спросили: что можно улучшить? Совместное творчество. И с разработкой вакцин против ковида - Pfiser и Biontech. Согласовали правила управления, разделения затрат и прибыли, запустили работу. По результатам спросили себя: почему раньше не делали таким образом?
Если резюмировать, то для запуска партнерства нужно MVP правил управления, деньги на стол, и посмотреть, что можно сделать за 2 недели для развития партнерства, запустить его? Правила доопределяются в ходе работы, в какой-то момент появится соглашение о разделении успеха, и это тоже важно сделать своевременно.
По сравнению с классическими контрактами на поставку такое партнерство дает многократное ускорение процесса. И совершенствование самого продукта, потому что поставщики, с их знаниями возможностей вовлекаются в проектирование, предлагают лучшие варианты.
Обычная конструкция: контракт на поставку. При чем - парные, с каждым. А предлагается - совместный контракт с совместными целями.
Я хочу сказать, что это - очередной этап развития горизонтальных связей по сетевой структуре. В принципе, о вовлечении говорили давно, правда раньше фокус был на вовлечение в проектирование клиентов, а сейчас еще и в другую сторону по цепочке пошли. Еще отдельный вопрос - в каких случаях такая кооперация возможна, а в каких - нет. Не очевидно, что она интересна компаниям и их поставщикам в любых случаях. Впрочем, это относится к любым формам взаимодействия.
Еще надо заметить, что все-таки ответа на кейс про производство чипов, с которого начался доклад, не было. Неясно, насколько по-другому развивалась ситуация, если бы у автопроизводителей с поставщиками чипов были такие партнерские отношения: ведь сокращение производства автомобилей было объективно.
Аналогично можно делать программы улучшений - был кейс AGCO - производители сельхозтехники. Разобрали трактор на части, позвали маркетинг, конвейер, поставщиков и спросили: что можно улучшить? Совместное творчество. И с разработкой вакцин против ковида - Pfiser и Biontech. Согласовали правила управления, разделения затрат и прибыли, запустили работу. По результатам спросили себя: почему раньше не делали таким образом?
Если резюмировать, то для запуска партнерства нужно MVP правил управления, деньги на стол, и посмотреть, что можно сделать за 2 недели для развития партнерства, запустить его? Правила доопределяются в ходе работы, в какой-то момент появится соглашение о разделении успеха, и это тоже важно сделать своевременно.
По сравнению с классическими контрактами на поставку такое партнерство дает многократное ускорение процесса. И совершенствование самого продукта, потому что поставщики, с их знаниями возможностей вовлекаются в проектирование, предлагают лучшие варианты.
Обычная конструкция: контракт на поставку. При чем - парные, с каждым. А предлагается - совместный контракт с совместными целями.
Я хочу сказать, что это - очередной этап развития горизонтальных связей по сетевой структуре. В принципе, о вовлечении говорили давно, правда раньше фокус был на вовлечение в проектирование клиентов, а сейчас еще и в другую сторону по цепочке пошли. Еще отдельный вопрос - в каких случаях такая кооперация возможна, а в каких - нет. Не очевидно, что она интересна компаниям и их поставщикам в любых случаях. Впрочем, это относится к любым формам взаимодействия.
Еще надо заметить, что все-таки ответа на кейс про производство чипов, с которого начался доклад, не было. Неясно, насколько по-другому развивалась ситуация, если бы у автопроизводителей с поставщиками чипов были такие партнерские отношения: ведь сокращение производства автомобилей было объективно.
👍3
В пятницу был на конференции #Agiledays. Как всегда, интересное содержание и много нетворкинга, так что в ходе конференции получилось опубликовать заметку только по одному выступлению. Поэтому оперативно собрал и публикую отчет https://mtsepkov.org/AgileDays-2024 На конференции появилось ощущение, что происходит некоторый поворот, смена парадигмы, может быть, не меньший, чем в начале 2010-х, когда agile лишь завоевывал позиции. Он требует осмысления, и в отчете я это попробую сделать. А если говорить о докладах, то мой выбор - выступление Анны Обуховой про сверхцели, Мирко Кляйнера про переход с поставщиками в партнерскую позицию и Алексея Вебера про счастливое лидерство и Дмитрия Годунова про мегапроекты. И еще был круглый стол по самоуправлению, который шел параллельно с Обуховой, поэтому я на него не попал, так что рассказываю кратко по презентации и обсуждению в кулуарах.
👍19🤯1
Десятая статья про модели личности https://vc.ru/hr/1093766 «Спиральная динамика, Big Five и другие модели ценностей» посвящена ценностным моделям. Как я отмечал в статье «Внутренняя сцена и объективная реальность», именно ценности и убеждения определяют спектакль на нашей внутренней сцене, они оценивают наши поступки, окрашивают происходящее в сияние света или покрывают тьмой. Это касается как конструирования будущего, так и оценки произошедшего. И для понимания других нужно уметь понять, как они оценивают происходящее, в какой цвет окрашены события в их спектакле. И, хотя каждый человек уникален, оказывается, что есть модели, которые хорошо позволяют в этом разобраться. Самая известная ценностная модель – спиральная динамика, но есть и другие: Герчикова, Громовой-Терентьевой, Алексея Кулакова и другие. И, что интересно, в числе ценностных моделей – распространенная модель Big Five, которая тоже по факту описывает ценности человека, и через них – его психологию и поведение. Полное оглавление серии https://mtsepkov.org/Self-Det
vc.ru
Спиральная динамика, Big Five и другие модели ценностей — Карьера на vc.ru
В очередной статье серии, посвященной модели личности (оглавление), я буду рассматривать модели, связанные с ценностями человека. Ведь, как я отмечал в статье «Внутренняя сцена и объективная реальность», именно ценности и убеждения во многом определяют спектакль…
👍4
Одиннадцатая статья про модели личности https://vc.ru/hr/1117480 «Адизес, Белбин и другие модели команды и руководства» показывает, как эти модели встраиваются в комплексную модель личности. Часть моделей были затронуты в предыдущей статье, посвященной ценностным моделям, а также статье по MBTI. Подробного рассказа про сами модели в статье нет. Однако, при подготовке я вспомнил, что четыре года назад писал обзор истории развития моделей руководства https://vc.ru/hr/145616 «Руководство и лидерство — спектр представлений». Думаю, эта статья завершает серию. Полное оглавление – на моем сайте https://mtsepkov.org/Self-Det. В планах – опубликовать книгу на основе этой серии статей, доработав материал на основе тех обсуждений, которые были в ходе публикации.
vc.ru
Адизес, Белбин и другие модели команды и руководства — Карьера на vc.ru
Очередная статья про модель личности (оглавление серии) будет посвящена моделям руководства и организации команд. Отчасти я затрагивал эту тему в прошлой статье «Спиральная динамика, Big Five и другие модели ценностей». Так, модель DISC неявно включает вопросы…
🔥7
Сегодня и завтра в Иннополисе на #mergeconf Интересно, 11 треков. Нестабильной инет не даёт публиковать впечатления онлайн, ждите отчёта. Мой доклад - про самоопределение, презентация выложена у меня на сайте https://mtsepkov.org/SelfDet-Merge там же ссылка на предыдущий доклад по теме с видео
🔥7👍4
В выходные впервые был на MergeConf в Иннополисе. Живая конференция, хорошие доклады, оперативно публикую отчет https://mtsepkov.org/MergeConf-2024
🔥9👍3
#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 и другие материалы на моем сайте., включая конспекты докладов Ивара.
Да, для тех, кто не в курсе, 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 и другие материалы на моем сайте., включая конспекты докладов Ивара.
vc.ru
OMG Essence и OKR – многофокусное ведение проектов и бизнеса в целом — Карьера на vc.ru
В прошлой статье «Public web — следуем за потребителем» мы говорили о практиках и технологиях public web следования за потребителем при высоком темпе изменений. А в этой, 25 статье серии «Менеджмент цифрового мира» (оглавление) мы поговорим о тех изменениях…
🔥7
#sqadays Андрей Мясников. Я люблю свою работу, я приду туда в субботу! Доклад про то, как не выгореть, заметив симптомы на ранних стадиях. Как всегда от Андрея - хороший и живой. В начале предупреждение: если у вас уже все серьезно, обратитесь к специалисту, в докладе - про профилактику.
Начался с личной истории. Однажды проснулся и понял, что не хочет на работу. Позвонил начальнику, он разрешил не выходить. И еще день. Не на помогло. И начальник сказал: или выходишь на работу, или отпуск за свой счет. И он вышел и провел анализ ощущений: его удобный бардак на столе уборщица трансформирует в удобный ей, солнце отсвечивает в монитор после обеда, оттягиваешь взять задачу в работе. На следующий день вышел борячком, потому что увидел - это все мелочи, а значит их можно побороть: энергия приходит во время работы, поэтому просто действуй. И дальше - разные техники.
Типы задач. Тоже история от знакомого лида, пришел - говорит: сотрудник увядает, вроде все хорошо, но положил заявление со словами "все достало". А там классный лид, менеджер-зонтик: прикрывает команду, гнев начальства не долетает. Андрей спрашивает: а какой тип задач сотруднику нравится? Пришлось рассказать, что это.
У Андрея есть своя классификация, он рассказывал на SQAdays-13 (я нашел по конспекту https://mtsepkov.org/SQAdays-2013a):
* одноразовые: прогнал ПМИ, посетил конфу.
* итеративные, регулярные - чистить зубы,
* внезапные - прилетают вдруг.
* волшебные - они любимые.
Выяснилось, что сотрудник работал только на одноразовых и итеративных. И ему скучно. Ему стали давать внезапные - стало лучше, человек раскрылся, она потом стало пускать на тушение пожаров - и ему нравится. Вывод: определитесь, какой тип задач нравится больше всего, и следите, чтобы было.
Добавьте элемент игры. Переходящий вантуз - на столе у того, кто нафакапил до тех пор, пока следующий не облажается. Нашел крупный баг, затащил релиз - вознаграждение, тортик или вино, или что вам нравится.
Идеальной работы не существует. Но! вы можете назначить любую работу любимой. Не значит, что смириться. Выписываете: близко от дома, хороший проект, но плохие процессы - попробуйте изменить.
Рефлексия проблем. Он это не сделал сразу и потерял несколько дней и душевное спокойствие. 5 почему и другие техники. Почему вчера было хорошо, а сегодня - не очень? Что изменилось? Как прошел денек? Если остался осадок - то от чего?
Выгулять лень. Останьтесь дома и не делайте вообще ничего, не тратьте мыслетопливо. В идеале - не готовьте. Побежите как угорелый. А если нет - полежите еще.
Найдите общее хобби с коллегами. Была коллега, с которой тяжело общаться, а потом узнал, что общая онлайн-игра. С ПМ - играть в шашки, и рабочие вопросы пошли лучше
Съешь лягушку. Сделайте самое плохое дело первым. Если вы пробежали несколько километров, хуже не будет.
Отдых - часть работы. Восстановление. 8-часовой рабочий день не просто так придуман. Если у вас выходной и вы вызываетесь помочь - не надо. Если инструмент затупился - его выбрасывают. Точите себя как инструмент, отдых - это такое время.
Если проблемы - рефлексируй. Ты или выгораешь, или угораешь, для чего меняешь жизнь.
Начался с личной истории. Однажды проснулся и понял, что не хочет на работу. Позвонил начальнику, он разрешил не выходить. И еще день. Не на помогло. И начальник сказал: или выходишь на работу, или отпуск за свой счет. И он вышел и провел анализ ощущений: его удобный бардак на столе уборщица трансформирует в удобный ей, солнце отсвечивает в монитор после обеда, оттягиваешь взять задачу в работе. На следующий день вышел борячком, потому что увидел - это все мелочи, а значит их можно побороть: энергия приходит во время работы, поэтому просто действуй. И дальше - разные техники.
Типы задач. Тоже история от знакомого лида, пришел - говорит: сотрудник увядает, вроде все хорошо, но положил заявление со словами "все достало". А там классный лид, менеджер-зонтик: прикрывает команду, гнев начальства не долетает. Андрей спрашивает: а какой тип задач сотруднику нравится? Пришлось рассказать, что это.
У Андрея есть своя классификация, он рассказывал на SQAdays-13 (я нашел по конспекту https://mtsepkov.org/SQAdays-2013a):
* одноразовые: прогнал ПМИ, посетил конфу.
* итеративные, регулярные - чистить зубы,
* внезапные - прилетают вдруг.
* волшебные - они любимые.
Выяснилось, что сотрудник работал только на одноразовых и итеративных. И ему скучно. Ему стали давать внезапные - стало лучше, человек раскрылся, она потом стало пускать на тушение пожаров - и ему нравится. Вывод: определитесь, какой тип задач нравится больше всего, и следите, чтобы было.
Добавьте элемент игры. Переходящий вантуз - на столе у того, кто нафакапил до тех пор, пока следующий не облажается. Нашел крупный баг, затащил релиз - вознаграждение, тортик или вино, или что вам нравится.
Идеальной работы не существует. Но! вы можете назначить любую работу любимой. Не значит, что смириться. Выписываете: близко от дома, хороший проект, но плохие процессы - попробуйте изменить.
Рефлексия проблем. Он это не сделал сразу и потерял несколько дней и душевное спокойствие. 5 почему и другие техники. Почему вчера было хорошо, а сегодня - не очень? Что изменилось? Как прошел денек? Если остался осадок - то от чего?
Выгулять лень. Останьтесь дома и не делайте вообще ничего, не тратьте мыслетопливо. В идеале - не готовьте. Побежите как угорелый. А если нет - полежите еще.
Найдите общее хобби с коллегами. Была коллега, с которой тяжело общаться, а потом узнал, что общая онлайн-игра. С ПМ - играть в шашки, и рабочие вопросы пошли лучше
Съешь лягушку. Сделайте самое плохое дело первым. Если вы пробежали несколько километров, хуже не будет.
Отдых - часть работы. Восстановление. 8-часовой рабочий день не просто так придуман. Если у вас выходной и вы вызываетесь помочь - не надо. Если инструмент затупился - его выбрасывают. Точите себя как инструмент, отдых - это такое время.
Если проблемы - рефлексируй. Ты или выгораешь, или угораешь, для чего меняешь жизнь.
👍12🔥4👏2
Презентация моего доклада на моем сайте https://mtsepkov.org/SoftSkillSQA Там же ссылки на предыдущие доклады по теме.
🔥4
#sqadays Екатерина Глушанина из 2ГИС. Как внутренние активности помогают расти и поддерживать бодрость духа. С моей точки зрения, этот доклад - очень хорошая иллюстрация того, как одни и те же события приводят к совершенно разным последствиям. У всех был ковид и переход на удаленку. У очень многих при этом появилось больше чатов, например, общий чат в дополнение к командным. Но вот то, что из общего чата, на основе анализа общения там, проросло много различных активностей: литклуб, докладо-клуб, митапы, мастер-классы - это исключение. Хотя, казалось бы: если люди задают вопросы, то обобщить и попробовать эти проблемы порешать - вполне понятная штука. Рассказ был как раз о том, как прорастали разные активности. Литклуб - из обсуждений книг, которые были на слуху, он хорошо стартовал, а потом общие книги кончились. Доклад-клуб - из обсуждения докладов на конференциях, они не кончаются. Типовые проблемы команд породили митапы по обмену опытом их решения. Мастер-классы - из проблем, по которым есть эксперты являются узким горлом. Пошло очень хорошо, и даже календарь оказался перенапряжен - они сделали опрос от чего отказаться, общее мнение было, что встречи полезны, но как урок - они начали делать регулярный дайджест, выявлять проблемные точки, и делать мероприятия только по реальным причинам. В целом - хорошо.
❤5
#sqadays Дмитрий Щербаков из BelkaCar. За кулисами каршеринга: тестирование автомобилей. В докладе был рассказ, как устроено тестирование управлением автомобиля в каршеринге. Я лично услышал из доклада, что тестирование автомобиля ничем принципиально не отличается от тестирования другой работы с интеграции с оборудованием, которое, в свою очередь, близко к тестированию интеграции. Может, это субъективно. Тестирование работы с оборудованием я представляю, мы делали работу с оборудованием для розничным магазинов, там на кассе до пяти разных внешних устройств, с разными протоколами, а важно, чтобы все работало. А интеграция тоже похожа, особенно когда там внешняя система, которую иногда сложнее подключить в тестовом контуре, чем внешнее оборудование. И да, используем эмуляторы, иногда с обеих сторон.
А в целом в докладе - интересный рассказ, с интересными историями разборки с разными моделями автомобилей, или с внезапной массовыми GPS-помехами, которые сбили определение положения автомобиля, и они сейчас периодически шлют бригады людей на самокатах для поиска. Предмет оптимизации для них - количество разнообразных прошивок, которое достигается через конфигурацию. Тестировать это все надо на любой новой партии автомобилей, и желательно на нескольких автомобилях из партии, потому что могут быть изменения. А при осваивании новой модели автомобиля нужен еще реверс-инжиниринг внутреннего устройства его системы управления, чтобы туда грамотно встроится.
Тестирование прошивки на машине занимает примерно день, за которые проходит около 300 проверок. При этом иногда проверяют несколько: один рулит, второй с ноута следит на автомобилем, а третий - за сервером. Это - особенность реального времени, но все эти части и для интеграции надо проходить. И оптимизация тестирования с эмуляторами автомобиля или ноутом вместо реального сервера эту финальный тест не отменяет, хотя и позволяет уменьшить их количество. Что интересно, они практически не обновляют прошивки в автомобилях. Потому что срок службы автомобиля относительно невелик, и целесообразно держать обратную совместимость со старыми версиями прошивок, а не обновлять с тестированием.
А в целом в докладе - интересный рассказ, с интересными историями разборки с разными моделями автомобилей, или с внезапной массовыми GPS-помехами, которые сбили определение положения автомобиля, и они сейчас периодически шлют бригады людей на самокатах для поиска. Предмет оптимизации для них - количество разнообразных прошивок, которое достигается через конфигурацию. Тестировать это все надо на любой новой партии автомобилей, и желательно на нескольких автомобилях из партии, потому что могут быть изменения. А при осваивании новой модели автомобиля нужен еще реверс-инжиниринг внутреннего устройства его системы управления, чтобы туда грамотно встроится.
Тестирование прошивки на машине занимает примерно день, за которые проходит около 300 проверок. При этом иногда проверяют несколько: один рулит, второй с ноута следит на автомобилем, а третий - за сервером. Это - особенность реального времени, но все эти части и для интеграции надо проходить. И оптимизация тестирования с эмуляторами автомобиля или ноутом вместо реального сервера эту финальный тест не отменяет, хотя и позволяет уменьшить их количество. Что интересно, они практически не обновляют прошивки в автомобилях. Потому что срок службы автомобиля относительно невелик, и целесообразно держать обратную совместимость со старыми версиями прошивок, а не обновлять с тестированием.
🔥4❤2
#sqadays Наталья Савостюк. Как экологично влиять на изменение своего оклада? Доклад был вчера, но я не успел опубликовать. У Натальи 90 человек в отделе, и большой опыт разбора ситуаций с окладами. На основе опыта - пять обобщенных персонажей, типичных представителей у которых есть проблемы с окладами. И особенности ситуаций с каждым.
1. Недооцененный Мидл+, хорошо работает для своих задач. Не имеет целей развития, когда говорит - потому что так принято, плана развития нет, либо по нему не идет. Закрыт эмоционально, на разговорах 1:1 - все хорошо. А потом уходит, а в кулуарах оказывается, что он считает, что он недооценен, успехи не замечают. А вопрос: как замечать, если ты об этом не говорит.
У нее психологическое образование, она может раскрутить, но это много сил и она спец, у других - такого нет. Если руководитель через кулуарные разговоры узнает проблемы, зовет поговорить про план развития - а тот говорит "на работе времени нет, а потом - домашние дела." План развития договоренность, если сотрудник нарушает - почему руководитель должен стараться? Тут надо отметить, что обычно те, кто хотят развиваться - находят время. Мидл+ с высокой вероятностью сам достаточно свободен в распределении своего времени. Он его не выделяет, и обижается на компанию, что времени не дают.
Так как задачи выполняют хорошо, руководитель сам ищет повышение. Спрашивает "а сколько" - ответ - "я не знаю, сами оцените". Вопрос ожиданий тут важен, потому что на небольшую индексацию руководители часто готовы, а с большой им часто непонятно. А, с другой стороны, если у него ожидания большого повышения, то озвучив небольшое можно получить обиду. Вообще люди из этой группы ожидают повышения 10-15% "на инфляцию", даже в долларах или евро :) Индексировать по инфляции - право компании, но обычно не предмет договоренностей, не автомат. Правда, замечу, что если на рынке - рост, даже независимо от инфляции, то без такой индексации люди будут уходить.
2. Амбициозный. Junior+ поработал год-полтора, был интенсивный рост и оно породил завышенные ожидания. На собеседовании просит оклад в 1.5-2 раза текущего, и хочет повышение на 20-30% каждые полгода. Через 2-3 года человек приходит к тупику - такого темпа роста точно не будет. Тут контрольные вопросы: а что ты сделал за последнее время, что нового принес - если ответа нет - то какие основания? Часто ответы: "я ответственный, внимательный, развивающийся", но это же характеристика любого хорошего сотрудника, почему это стоит +20-30% в полгода? Амбициозный персонаж часто берется за много дел, но вот доводит до конца - мало.
3. Рисковый. Он сходил и принес офер, говорит что хочет остаться. Делают контрофер. Но дальше будет релиз - и его уволят. В процессе релиза бизнесу надо закрыть задачи. И работают на удержание. А вот после релиза есть фаза маркетинга, и раскрутки. Бизнес начинает экономить - и увольняет таких дорогих.
Я тут хочу отметить, что контрофер в некоторых компаниях сейчас стал штатным способом для повышения зарплат сотрудникам. Это может быть связано с тем, что внутри считают, что не могут адекватно оценить сотрудника и полагаются на внешнюю оценку его роста. Или с бюджетными соображниями, сотруднику прямо объясняют, что в бюджет заложен рост фонда зарплат по инфляции, а еще - отдельные деньги на удержание через контрофер, и руководитель сам предлагает такой механизм.
4. Сеньор. Ответственный, у него большой и относительно круг обязанностей, которые он хорошо выполняет. И тут могут быть сложности, если он хочет роста оклада и готов расширить круг ответственности: чем именно расширить, и получится ли это не в ущерб тому, что он выполняет, а если он одно возьмет, а другое перестанет делать - то не очень понятно, почему взятое должно больше стоить. Это предмет переговоров. В любом случае, новые обязанности надо брать на регулярной основе, расширяя круг ответственности, например, если онбординг - то не разово, а как зону ответственности, а если выступление, то опять-таки не разово, а стать регулярным спикером.
1. Недооцененный Мидл+, хорошо работает для своих задач. Не имеет целей развития, когда говорит - потому что так принято, плана развития нет, либо по нему не идет. Закрыт эмоционально, на разговорах 1:1 - все хорошо. А потом уходит, а в кулуарах оказывается, что он считает, что он недооценен, успехи не замечают. А вопрос: как замечать, если ты об этом не говорит.
У нее психологическое образование, она может раскрутить, но это много сил и она спец, у других - такого нет. Если руководитель через кулуарные разговоры узнает проблемы, зовет поговорить про план развития - а тот говорит "на работе времени нет, а потом - домашние дела." План развития договоренность, если сотрудник нарушает - почему руководитель должен стараться? Тут надо отметить, что обычно те, кто хотят развиваться - находят время. Мидл+ с высокой вероятностью сам достаточно свободен в распределении своего времени. Он его не выделяет, и обижается на компанию, что времени не дают.
Так как задачи выполняют хорошо, руководитель сам ищет повышение. Спрашивает "а сколько" - ответ - "я не знаю, сами оцените". Вопрос ожиданий тут важен, потому что на небольшую индексацию руководители часто готовы, а с большой им часто непонятно. А, с другой стороны, если у него ожидания большого повышения, то озвучив небольшое можно получить обиду. Вообще люди из этой группы ожидают повышения 10-15% "на инфляцию", даже в долларах или евро :) Индексировать по инфляции - право компании, но обычно не предмет договоренностей, не автомат. Правда, замечу, что если на рынке - рост, даже независимо от инфляции, то без такой индексации люди будут уходить.
2. Амбициозный. Junior+ поработал год-полтора, был интенсивный рост и оно породил завышенные ожидания. На собеседовании просит оклад в 1.5-2 раза текущего, и хочет повышение на 20-30% каждые полгода. Через 2-3 года человек приходит к тупику - такого темпа роста точно не будет. Тут контрольные вопросы: а что ты сделал за последнее время, что нового принес - если ответа нет - то какие основания? Часто ответы: "я ответственный, внимательный, развивающийся", но это же характеристика любого хорошего сотрудника, почему это стоит +20-30% в полгода? Амбициозный персонаж часто берется за много дел, но вот доводит до конца - мало.
3. Рисковый. Он сходил и принес офер, говорит что хочет остаться. Делают контрофер. Но дальше будет релиз - и его уволят. В процессе релиза бизнесу надо закрыть задачи. И работают на удержание. А вот после релиза есть фаза маркетинга, и раскрутки. Бизнес начинает экономить - и увольняет таких дорогих.
Я тут хочу отметить, что контрофер в некоторых компаниях сейчас стал штатным способом для повышения зарплат сотрудникам. Это может быть связано с тем, что внутри считают, что не могут адекватно оценить сотрудника и полагаются на внешнюю оценку его роста. Или с бюджетными соображниями, сотруднику прямо объясняют, что в бюджет заложен рост фонда зарплат по инфляции, а еще - отдельные деньги на удержание через контрофер, и руководитель сам предлагает такой механизм.
4. Сеньор. Ответственный, у него большой и относительно круг обязанностей, которые он хорошо выполняет. И тут могут быть сложности, если он хочет роста оклада и готов расширить круг ответственности: чем именно расширить, и получится ли это не в ущерб тому, что он выполняет, а если он одно возьмет, а другое перестанет делать - то не очень понятно, почему взятое должно больше стоить. Это предмет переговоров. В любом случае, новые обязанности надо брать на регулярной основе, расширяя круг ответственности, например, если онбординг - то не разово, а как зону ответственности, а если выступление, то опять-таки не разово, а стать регулярным спикером.
🔥4
5. Матерый. Группа проектов или ресурс-менеджер. Сам может выстроить путь развития, найти пространство работы. Цели ставить не нужно. Но он тоже может столкнуться с проблемами по зарплате, и она связана с тем, что руководитель может просто выпустить закрытый им сектор из поля зрения, полагая что там стабильная регулярная работа, в то время как у сотрудника там реальный рост сложности решаемых задач и достижения. И тут ему надо уметь показывать свои достижения, и рост ценности для компании.
Подводя итоги, как действовать.
1. Сформулируйте ожидания: какой доклад хочу, когда я его хочу? Какой разрыв? Что я готов сделать ради этого?
2. Подумайте, насколько реалистична такая разница в заданный срок с учетом обстановки в стране, ИТ, вашей отрасли, вашей компании - может, надо менять? При этом у любой компании есть периоды сложностей и хорошие. Осознали - скорректируйте ожидания.
3. Сходите к руководителю и озвучьте спокойным текстом все, что обдумали. И обсудите - может что еще надо.
И замечания по проблемным кейсам.
* Надо понимать, что если был план, вы его игнорили, а в конце года начали делать - будут вопросы. Оклад - за изменения в работе, а вы просто доделали план, изменений не было. Разовая работа, например, конфа - премия. Чтобы оклад - можно стать амбассадором. Изменение - на постоянной основе. Не один онбординг, а обязанность.
* Есть кейс, когда тебя взяли на оклад с ожиданиями, ты не умел, наконец обучился - это не повод повышать, ты просто наконец-то делать то, для чего брали.
* Изучил новое, но ненужное для проекту - неясно, профита-то нет.
Подводя итоги: говорите о своих изменениях через ценности для бизнеса. Вы сами управляете жизнью. Нет правильных и неправильных цифр. Управляйте своим путем. И будьте довольны окладами.
В ответах на вопросы был разбор кейса, когда приходят дяденьки из бизнеса с якобы разовой задачей. А потом оно прилипает, ты не разговаривал, потому как разовое. Ответ Натальи: хотел бы такой оклад, за последний год стал делать вот это и получил ценность для бизнеса. Не копить обиду, а поговорить. И принять ответственность за то, что на входе не договаривался. Тут могут быть сложные переговоры, их надо уметь вести.
Еще вопрос: стоит ли удерживать? Ответ: есть много разных факторов, были преображения для любого персонажа. Для руководителя идеальная ситуация, когда сотрудники сами приходят и обсуждают. Но практически руководителю часто приходится брать обсуждение на себя. У нее в практике были кейсы, когда по результатам обсуждений остаются, в том числе на меньшие оклады, чем был офер.
Подводя итоги, как действовать.
1. Сформулируйте ожидания: какой доклад хочу, когда я его хочу? Какой разрыв? Что я готов сделать ради этого?
2. Подумайте, насколько реалистична такая разница в заданный срок с учетом обстановки в стране, ИТ, вашей отрасли, вашей компании - может, надо менять? При этом у любой компании есть периоды сложностей и хорошие. Осознали - скорректируйте ожидания.
3. Сходите к руководителю и озвучьте спокойным текстом все, что обдумали. И обсудите - может что еще надо.
И замечания по проблемным кейсам.
* Надо понимать, что если был план, вы его игнорили, а в конце года начали делать - будут вопросы. Оклад - за изменения в работе, а вы просто доделали план, изменений не было. Разовая работа, например, конфа - премия. Чтобы оклад - можно стать амбассадором. Изменение - на постоянной основе. Не один онбординг, а обязанность.
* Есть кейс, когда тебя взяли на оклад с ожиданиями, ты не умел, наконец обучился - это не повод повышать, ты просто наконец-то делать то, для чего брали.
* Изучил новое, но ненужное для проекту - неясно, профита-то нет.
Подводя итоги: говорите о своих изменениях через ценности для бизнеса. Вы сами управляете жизнью. Нет правильных и неправильных цифр. Управляйте своим путем. И будьте довольны окладами.
В ответах на вопросы был разбор кейса, когда приходят дяденьки из бизнеса с якобы разовой задачей. А потом оно прилипает, ты не разговаривал, потому как разовое. Ответ Натальи: хотел бы такой оклад, за последний год стал делать вот это и получил ценность для бизнеса. Не копить обиду, а поговорить. И принять ответственность за то, что на входе не договаривался. Тут могут быть сложные переговоры, их надо уметь вести.
Еще вопрос: стоит ли удерживать? Ответ: есть много разных факторов, были преображения для любого персонажа. Для руководителя идеальная ситуация, когда сотрудники сами приходят и обсуждают. Но практически руководителю часто приходится брать обсуждение на себя. У нее в практике были кейсы, когда по результатам обсуждений остаются, в том числе на меньшие оклады, чем был офер.
🔥3👍2
#sqadays Олег Королев и Анастасия Радужная из Ростелеком. Влияние QA сообществ на развитие ценностей в компании. Рассказ - success-story о запуске сообщества тестировщиков. Это - не первая попытка, но 1.5 года назад сообщество запустилось, и за это время были успешные проекты:
* единая методология
* единый базовый онбординг
* школа тестеров - для внешних, рост джунов и 3 месяца стажировки, ребята сами вызвались быть менторами: 280 заявок, 35 взяли, 22 дошли до финала, 10 человек на стажировки и их берут работать
* экспертная группа, готовая выступать на конференциях
* внутренние продукты - разработка в рамках импортозамещения инструментов для тестирования, сообщество дает фидбэк
К сожалению, в докладе не было анализа - почему сообщества не получалось раньше. Потому что рассказывали, в общем-то очевидные вещи: для сообщества нужны разные люди, которые готовы работать как двигатели при том, что формальных обязательств перед сообществом у них нет. Говорили, что если пробуешь сообщество ввести в формальные рамки, то воспринимается это как еще один кусок работы и отторгается. И тут возникает впечатление, что это - просто ламповый островок человеческих взаимоотношений в корпорации. Но вот истории говорят, что сообщество решает вполне рабочие задачи, и в рабочее время. Которые, наверное, почему-то не получалось в рамках рабочего процесса. Может быть, из-за его слишком большой организованности и формализованности, которая не дает пространства для инициативы. И тогда сообщество получается средством разморозки излишне жесткой корпоративной культуры. В общем, тут были бы интересен анализ.
В рассказе были понятные организационные моменты: надо формировать повестку встреч, фасилитировать их и делать резюме по итогам встречи. Но, что тут интересно, резюме выполняют роль информации о том, что происходит в сообществе и привлечения интересующихся. Вообще сообщество - двухуровневое, есть широкий круг, который участвует в общем чате и есть ядро, которое участвует во встречах, делает задачи.
QA - первое сообщество компании. Они катализировали появление сообществ - архитекторы, СУБД, Devops. Я тут хочу отметить, что в рамках компании воспроизводится ситуация с отрасли: сообщество тестировщиков было 10 лет назад одним из первых организовавшихся и самым активным, я это помню по истории конференции SQAdays.
* единая методология
* единый базовый онбординг
* школа тестеров - для внешних, рост джунов и 3 месяца стажировки, ребята сами вызвались быть менторами: 280 заявок, 35 взяли, 22 дошли до финала, 10 человек на стажировки и их берут работать
* экспертная группа, готовая выступать на конференциях
* внутренние продукты - разработка в рамках импортозамещения инструментов для тестирования, сообщество дает фидбэк
К сожалению, в докладе не было анализа - почему сообщества не получалось раньше. Потому что рассказывали, в общем-то очевидные вещи: для сообщества нужны разные люди, которые готовы работать как двигатели при том, что формальных обязательств перед сообществом у них нет. Говорили, что если пробуешь сообщество ввести в формальные рамки, то воспринимается это как еще один кусок работы и отторгается. И тут возникает впечатление, что это - просто ламповый островок человеческих взаимоотношений в корпорации. Но вот истории говорят, что сообщество решает вполне рабочие задачи, и в рабочее время. Которые, наверное, почему-то не получалось в рамках рабочего процесса. Может быть, из-за его слишком большой организованности и формализованности, которая не дает пространства для инициативы. И тогда сообщество получается средством разморозки излишне жесткой корпоративной культуры. В общем, тут были бы интересен анализ.
В рассказе были понятные организационные моменты: надо формировать повестку встреч, фасилитировать их и делать резюме по итогам встречи. Но, что тут интересно, резюме выполняют роль информации о том, что происходит в сообществе и привлечения интересующихся. Вообще сообщество - двухуровневое, есть широкий круг, который участвует в общем чате и есть ядро, которое участвует во встречах, делает задачи.
QA - первое сообщество компании. Они катализировали появление сообществ - архитекторы, СУБД, Devops. Я тут хочу отметить, что в рамках компании воспроизводится ситуация с отрасли: сообщество тестировщиков было 10 лет назад одним из первых организовавшихся и самым активным, я это помню по истории конференции SQAdays.
👍5
#sqadays Нэлля Сердюк и Алексей Алешин из Ростелеком ИТ. Продукт, который можно "пить". Название - из метафоры очистки воды. А проект - про тестирование порталов видеонаблюдения за ЕГЭ и выборами. Но в рассказе специфики проекта не было, был рассказ про реорганизацию процесса и используемые практики. И я из их числа хочу отметить не очевидную реорганизацию: они откладывают описание тест-кейса до стабилизации задачи, а до этого работают по чек-листам. Это дает относительную легкость изменений и убирает фактор сроков - тест-кейс можно описать и после выкатки срочного функционала в прод, в режиме устранения тех.долга. При тестировании новой фичи чек-листа хватает, так как тестировщики в контексте: команда знакомится с задачей на груминге, и ее помнят, а вот при регрессе проверяют сделанное давно, и важно хорошее описание, чтобы регресс мог провести любой из тестировщиков. Это описание собирают на основе чек-листов и финальных комментариев тестировщика по каждому тестированию, которые тоже является обязательным для каждого такта тестирования и должен описывать - что было проверено с техникой. Груминг для знакомства с задачей был новой практикой, казалось бы. он дает накладные расходы, но реально он сокращает количество возвратов задач, когда ТЗ поняли неверно и делали не то. Я тут хочу заметить, что ненадежность передачи через артефакты из-за того, что тексты трактуют по-разному была осознана уже больше 20 лет назад, это - одна из предпосылок agile-методов, но те, кто создают процессы почему-то по-прежнему верят текстовым описаниям, практики коммуникации типа груминга появляются позднее и далеко не везде...
👍3❤1
#sqadays Алексей Петров, Одноклассники. Индивидуальные планы развития на базе матрицы компетенций. Цели индивидуального развития: рост знаний и компетенций, карьерный рост, рост финансового вознаграждения, увеличение вариативности развития. Но! куда расти?
Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много.
Средство для вариации - матрица компетенций. У Алексея есть заготовка ее можно дополнять, и точно надо добавить знание компонентов вашего продукта.
В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя.
Калибрация самооценки. Руководителем, наставником или кем-то еще. Помните про эффект Данинга-Крюгера: компетентные недооценивают, а некомпетентные переоценивают. При калибровке - не устраивайте экзамен. Вы - наставник, ментор, а не судья.
Дальше выберите области улучшений. Сотрудник - сам выбирает, не руководитель. И не обязательно от слабых областей, можно от сильных. Не выбирайте все, 3-6 на полгода - достаточно. А вот дальше руководитель сопоставляет выбранное с потребностями бизнеса - и тут обсуждаем.
Дальше был проект прокачки с конкретным примером. Формат:
* прокачиваемые компетенции,
* описание проекта,
* пользовательские сценарии,
* бизнес-ценность
* точки поэтапного контроля (вехи)
* DoD
* артефакт
* в какую цель бьет
Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль.
В примере были цели - тест-дизайн, TMS, продуктовую компоненту, и проект включал разработку тест-кейсов для этой компоненты с использованием TMS. Реализуя проект мы приносим ценность для бизнеса - получаем больше тест-кейсов, и развиваем сотрудника.
Делаем 2-3 проекта, чтобы была вариативность, и по внешним связям, и по своему драйву.
Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.
Профит:
* сотрудник понимает кто он и куда идет
* руководитель тоже понимает это про сотрудника
* есть цели на год и квартал - можно сопоставлять с ИПР
* обоснование роста зарплаты - связь косвенная, но она есть, нужно и сотруднику и руководителю. Но проекты - они разовые, поэтому рост зп - не автоматический
Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее.
ИПР сотрудников можно объединять, чтобы была взаимная зависимость и перекрестный контроль. Например, один хочет расширить написание тест-кейсов, а второй - навыки руководства, и тогда второму ставим задачу обеспечить работу первого.
Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много.
Средство для вариации - матрица компетенций. У Алексея есть заготовка ее можно дополнять, и точно надо добавить знание компонентов вашего продукта.
В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя.
Калибрация самооценки. Руководителем, наставником или кем-то еще. Помните про эффект Данинга-Крюгера: компетентные недооценивают, а некомпетентные переоценивают. При калибровке - не устраивайте экзамен. Вы - наставник, ментор, а не судья.
Дальше выберите области улучшений. Сотрудник - сам выбирает, не руководитель. И не обязательно от слабых областей, можно от сильных. Не выбирайте все, 3-6 на полгода - достаточно. А вот дальше руководитель сопоставляет выбранное с потребностями бизнеса - и тут обсуждаем.
Дальше был проект прокачки с конкретным примером. Формат:
* прокачиваемые компетенции,
* описание проекта,
* пользовательские сценарии,
* бизнес-ценность
* точки поэтапного контроля (вехи)
* DoD
* артефакт
* в какую цель бьет
Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль.
В примере были цели - тест-дизайн, TMS, продуктовую компоненту, и проект включал разработку тест-кейсов для этой компоненты с использованием TMS. Реализуя проект мы приносим ценность для бизнеса - получаем больше тест-кейсов, и развиваем сотрудника.
Делаем 2-3 проекта, чтобы была вариативность, и по внешним связям, и по своему драйву.
Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.
Профит:
* сотрудник понимает кто он и куда идет
* руководитель тоже понимает это про сотрудника
* есть цели на год и квартал - можно сопоставлять с ИПР
* обоснование роста зарплаты - связь косвенная, но она есть, нужно и сотруднику и руководителю. Но проекты - они разовые, поэтому рост зп - не автоматический
Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее.
ИПР сотрудников можно объединять, чтобы была взаимная зависимость и перекрестный контроль. Например, один хочет расширить написание тест-кейсов, а второй - навыки руководства, и тогда второму ставим задачу обеспечить работу первого.
🔥5