Попутный ветер

Хожу сейчас в три книжный клуба (один в Белграде, два онлайн, все разные) и думаю про то, насколько проще становится, когда ты попадаешь в тренды и тебя поддерживает среды. И это везде — от выбора одежды и внешнего вида до работы и досуга. Как будто можно плыть наконец, поддерживаемая течением, а не выгребая против него.

Первый раз я это явно почувствовала в период Work from Home в коронокризис. Это не твоя личная сложность и не твой личный процесс, а это проживают одновременно куча людей, делятся своими находками и опытом, рефлексируют и осмысляют. От эргономики и особенности среды до изменения коммуникаций.

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

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

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

Так наблюдаю сейчас разные лаборатории и обучение в сфере применения AI — от иностранных языков и преподавания вообще до работы с личной базой знаний и все это очень-очень любопытно.

Мое любимое место в таких вещах в теории инноваций Роджерса — раннее большинство.

#учить_и_учиться

Книжный обзор #5. Emily Nagoski. Come Together: The Science (and Art!) of Creating Lasting Sexual Connections. 18+

С трепетом пишу обзор на книгу про секс и наверное не решилась бы, если бы это не была книга Эмили Нагоски и там не было бы много про травмы, патриархат и социальные отношения. Ну и в конце концов здесь все взрослые люди (я на это надеюсь).

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

Я еле удержалась от того, чтобы не цитировать совсем уж всю книгу, но привожу достаточно много авторского текста и в канал это просто не влезло)

Поэтому читайте статью в телеграфе)

#книжный_обзор

Взгляд на работу через 5 лет

Переделывала резюме и заметила, как по-другому я вспоминаю о моих работах 5-10 лет назад. Раньше я концентрировалась на том, сколько всего я делала и вот это, и вон то, и еще крестиком вышивать умею. А сейчас детали изрядно забылись и остались только яркие события, что-то что я действительно сделала хорошо и что-то поменяла. А еще со временем поняла, что то, что было вроде «само», на самом деле результат моих прямых усилий. И если бы не было меня — так бы не было тоже. Возможно было бы по-другому, но не так.

Предлагаю практику для авторизации результата (и для резюме тоже)

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

#карьера_в_тестировании

Дайджест #22

Внезапно обнаружила себя в саббатикале с тремя проектами и двумя учебами, поэтому регулярно буду писать только рубрики) И сегодня снова #дайджест раз в две недели со всем, что показалось мне любопытным.

• Вероника отвечает, почему никто не верит, что мы молодцы, если говорить об этом раз в полгода. И это снова про видимость. Мало один раз показать что-то, надо и делать, и рассказывать вновь и вновь и разными способами. Не все придут на встречу, не все прочитают пост, а еще у людей свои дела)

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

• Про важность формулировок и то, что Agile Manifest никогда не отрицал документацию. В комментариях справедливо напоминают про время и контекст, когда создавался манифест и что тогда было comprehensive документацией.

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

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

Вспоминаю лекции Михаила Соколова про социальную мобильность и стратификацию. Среди прочего он рассказывал, что про уровень риска и инноваций в выборе тем для научных исследований. Люди, у которых больше поддержка семьи, могут себе позволить брать более рискованные темы и менять их, если что-то пошло не так, дольше писать PhD. Да и в целом более уверенно чувствовать себя в нестабильности западной академии, где добиться постоянной ставки очень сложно.

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

#дайджест

Как начать разбираться с метриками?

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

Кабина самолета. Тишина. Пилот штурману:

- Штурман, приборы!
- Сто.
Летят дальше.
- Что «сто»?!
- А что «приборы»?

Нередко в статья про метрики авторы сразу же пишут про какие-то популярные тестовые метрики или рассказывают про свой опыт.

Наташа же в течение нескольких месяцев писала цикл постов про то, какие метрики бывают, как подобрать нужные для себя и проблему баланса. Рекомендую начинать именно с них.

#менеджерское

об измерениях неизмеримого

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


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

метрики, как и всё в этой жизни, бывают разные: количественные и качественные, оценивающие процессы и оценивающие результат работы.

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

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

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

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

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

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

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

продолжим нашу нерегулярную рубрику про работу с метриками

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

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

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

вот несколько примеров, как это можно сделать:

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

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

3. скорость работы команды (например, lead time) + удовлетворённость команды
- скорость работы команды – важный показатель, но он мало значит, если команда при этом выгорает. если lead time хороший, но команда жалуется на перегрузку, это сигнал, что нужно пересмотреть процессы и распределение задач.

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

5. количество багов на модуль приложения умноженное на коэффициент важности этого модуля
- не все баги одинаково полезны. если баг найден в ключевом модуле, это может иметь более серьёзные последствия, чем аналогичный баг в менее критичном компоненте. умножив количество багов на коэффициент важности модуля, можно получить более точную оценку того, насколько серьёзна проблема и куда стоит направить ресурсы в первую очередь.

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

возвращаюсь с продолжением постов про метрики

баланс метрик: оцениваем процессы и результаты

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

почему это важно? давайте разбираться.

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

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

вот несколько примеров того, как можно сбалансировать процессные и результативные метрики, избегая фокуса только на количестве и времени:

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

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

3. процент выполнения спринта (процесс) + качество релиза (результат)
- завершить спринт на 100% – это, конечно, здорово, но если при этом качество релиза оставляет желать лучшего, то вся эта гонка теряет смысл. важно следить за тем, чтобы спринт завершался не только вовремя, но и с достойным результатом.

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

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

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

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

метрики качества для стартапов, продуктовых компаний и аутсорса

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

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

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

Количество багов с приоритетом Critical+ на проде (цель: тренд не должен расти)
важнейший показатель для стартапа – это отсутствие серьёзных сбоев в проде. критичные баги, влияющие на бизнес, – это красный флаг. важно следить за трендом: если он растёт, нужно принимать меры.

Test reliability: процент багов на демо/проде, некоррелирующих с проведёнными тестами (цель: тестировать то, что нужно)
эта метрика показывает, насколько тестирование отвечает реальным потребностям пользователей продукта. если баги на проде не связаны с тем, что тестировалось, значит, что-то идёт не так с процессами или тестовым покрытием.

Time to test (цель: тренд не растёт или падает)
время на тестирование должно либо оставаться стабильным, либо уменьшаться. для стартапа важно сохранять гибкость и не тратить слишком много времени на проверки, которые могут тормозить релизы. если время на тесты растёт, возможно, это сигнал к тому, чтобы оптимизировать процессы.

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

Test coverage + requirements traceability quality (цель: высокое покрытие требований + высокое качество покрытия относительно требований)
тестовое покрытие можно отслеживать по-разному: от процента фичей, протестированных до выхода в прод, до степени покрытия тестами различных уровней (юнит, интеграционные и т.д.). важно, чтобы команда чётко определила, что для них значит "протестировано", и следила за этим.

% of Declined issues (цель: невысокий, тренд не растёт)
важно не только находить баги, но и следить за тем, насколько они релевантны. declined баги (дубли или "работает как задумано") не должны превышать 10% от общего числа. если их больше, это может сигнализировать о проблемах с требованиями, их пониманием командой или коммуникацией внутри команды. или о том, что наш беклог не очень хорошо себя чувствует и в нём сложно что-то найти.

% of Requirements reviewed before development start (цель: стремиться к 100%)
ещё одна важная метрика – это то, как требования проходят ревью перед началом разработки. чем раньше выявляются проблемы, тем лучше.

Эффективность оценки трудозатрат (цель: растёт или не снижается тренд попадания в эстимейты по задачам тестирования)
оценка трудозатрат – важный элемент в долгосрочном планировании. если фактические затраты сильно отклоняются от планируемых, нужно пересматривать подход к оценке или декомпозиции задач.

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

продолжение ниже

начало ^

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

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

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

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

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

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

предыдущие посты про метрики
1, 2, 3

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

За что мы тебе платим?! (с)

Отвечаю на вопрос, чем клуб бережного развития ZenTest отличается от просто чата.

Кратко: постоянным сфокусированным вниманием основательниц к проекту. Темам, организации, атмосфере. И профилактикой нашего с Наташей выгорания)

Ок, все это хорошо, но что это даёт участницам?

• Стабильность и предсказуемость. У клуба есть свой ритм и рубрики выходят в свое время.

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

• Рефлексию и улучшения со стороны организаторок. Мы учимся комьюнити-менеджменту, смотрим на разные форматы, обсуждаем и пробуем новое.

• Материалы и мероприятия, которые мы готовим и организуем

• Внимательных и не выгоревших админок

Можно ли все это делать бесплатно, как волонтерский проект? Возможно, но я бы не взялась. Долгосрочно меня хватает только на этот канал.

Если вам кажется, что все выше стоит того – присоединяйтесь к нам в ноябре к теме про T-shape!

Формат клуба

• закрытый канал и чат
• только для женщин
• фокус на тестировщиц, для других специалисток обсуждаемо в индивидуальном порядке
• 1500 рублей / 15 евро в месяц или 3000 рублей / 30 евро с ноября по февраль
• начало 1 ноября
• оплатить можно до 5 ноября включительно
• запись и подробности в гугл-форме

#ZenTest

Гиг-экономика и прекариат

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

Сейчас мы с Леной готовим исследовательскую лабораторию про работу для нейроотличных людей. И я смотрю разное про то, как в целом может быть устроена работа, выходя за пределы с 9 до 18, 40 часов в неделю.

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

Например, что такое quasi-employment (ситуации, когда работник не оформляется в штат, но по сути является постоянным сотрудником, не имея льгот и защиты. В нашей реальности это например устройство по ГПХ, ИП или самозанятости) или kill fee (договоренность об оплате фрилансеру, если проект не доводится до конца по причинам, которые не зависят от фрилансера).

Авторы книги — contractor of record (еще один термин из книги), компания-посредник, которая обеспечивает менеджмент фрилансеров и временных работников. Поэтому многие термины описаны в позитивном ключе как гибкость, агентность и автономность. И это действительно может быть так!

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

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

Вся книга интересна, но отдельно порекомендую отрывок про тревогу прекариата.

#исследование_работы
#diversity
#менеджерское
#книги

Дайджест #23

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

Из казалось бы безобидного, но того, с чем я регулярно сталкивалась — когда женщин называют «девушками» или «девочками». Скажете мелочь? Но микроагрессия вся и состоит из таких мелочей.

• Не все исследования одинаково хороши, авторка пишет про организационную психологию, но подходы общие.

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

#дайджест
#diversity

Карты нарративной практики

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

Ушла я с книгой Майкла Уйта «Карты нарративной практики. Введение в нарративную терапию». И прочитала половину в самолете. Узнала как мы рассказываем и слушаем истории, как наша идентичность создается через эти истории и как на нас влияют идеи и смыслы.

Потом я пошла в терапию к нарративной практикессе и узнала, как это все работает на своем опыте. Ходила на групповые деконструкции и семинары. Перед самой эмиграцией три года назад прошла вводный курс «Мастерской нарративной практики» про философию и основные принципы подхода.

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

Сейчас закончила и праздную это!

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

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

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

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

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

#учить_и_учиться
#как_я
#книги
#narrative

Glue work vs T-shape

Разговаривала в понедельник в #ZenTest в прямом эфире с @PrinzAnna про T-shape. И не могу перестать думать про то, как же различить glue work (клеевую работу, которая нужна, чтобы проект двигался) и T-shape (развитие в разные стороны от основной экспертизы).

Со стороны эти штуки кажутся очень похожими и задачи могут быть одними и теми же, более того glue work часто продают сотрудницам как возможность T-shape. Перебирай крупу автотесты и прокачаешь свои технические навыки.

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

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

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

#ZenTest

Книжный обзор #6. Оливер Беркман. 4000 недель. Тайм-менеджмент для смертных

В книге мало практических советов и она не научит вас лучше управлять временем. Зато автор много размышляет о том, как мы воспринимаем время и наших ограничениях.

4000 недель складываются в 76 с хвостиком лет. Красивая цифра, хорошая жизнь.

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

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

Время

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

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

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

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

Ловушка эффективности

Чем быстрее мы делаем дела, тем больше у нас дел и сделанные дела часто генерируют новые дела. И мир все убыстряется, и дела валятся на нас, и мы стараемся сделать все больше.

«Заслужив репутацию человека, работающего с рекордной скоростью, вы начнете получать больше заданий. (Ваша начальница не дура: зачем давать дополнительную работу тому, кто работает медленнее?) Как только вы поймете, как делить время между детьми и офисом без чувства вины за то и другое, вас снова начнут дергать, требуя больше заниматься спортом или вступить в родительскую ассоциацию, — о, и не пора ли уже наконец научиться медитировать? Откроете свой бизнес, о котором мечтали многие годы, и, если дела пойдут успешно, вы оглянуться не успеете, как почувствуете недовольство из-за того, что он такой маленький.

Рут Шварц Коуэн в книге «Больше работы для матери» (More Work for Mother) рассказывает, что, когда домохозяйкам стала доступна трудосберегающая техника вроде стиральных машин и пылесосов, это никак не помогло им экономить время, потому что общепринятые стандарты чистоты возросли так, что свели на нет все старания инженеров. Теперь, когда стало возможно приводить рубашки мужа в безукоризненное состояние после каждой носки, вам начало казаться, что вы должны это делать, чтобы показать, как вы его любите. «Работа заполняет время, отпущенное на нее», — написал в 1955 году британский сатирик и историк Сирил Норткот Паркинсон, сформулировав таким образом знаменитый первый закон Паркинсона. Но это не просто шутка, и применим этот закон не только к работе, а ко всему, что необходимо сделать. На самом деле именно представление о том, что необходимо сделать, расширяется, заполняя все имеющееся у нас время».

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

Невозможность получить все и сразу

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

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

Эти мысли освобождают меня. Можно прекратить стараться, отгоревать то, чего не будет и жить.

#менеджерское
#книги
#книжный_обзор

Результаты в целом сопоставимые, но больше всего голосов за «Психологические проблемы тестирования». Четыре психологические и социальные проблемы — четыре поста, начнем 1 декабря.

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

Программу обновим попозже, но основные правила такие же, как всегда.

• закрытый канал и чат
• только для женщин
• фокус на тестировщиц, для других специалисток обсуждаемо в индивидуальном порядке
• 1500 рублей / 15 евро за декабрь-январь
• начало 1 декабря
• оплатить можно до 5 декабря включительно
• запись в гугл-форме

#ZenTest
#адвент