Читаю сейчас книгу "Тайм-менеджмент для системных администраторов" Лимончелли, которую посоветовала моя тимлид.

Я читала много всякого по тайм-менеджменту и пробовала разные системы. В итоге собрала что-то своё, по большей части из идей Макса Дорофеева. И казалось мне, что нового может дать еще одна книга по тайм-менеджменту?

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

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

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

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

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

#менеджерское
#тлен_и_усталость

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

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

На одной из работ у нас была неделя открытых дверей в контакт-центре. И я отвечала на несколько звонков под присмотром оператора - был ценный опыт.

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

#заметки_с_полей

Когда стоит эскалировать

Дни постов про soft skills на Analysis Paradisis :)

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

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

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

Попробуйте сначала спросить:
- почему ваш коллега не успевает?
- как вы можете ему помочь?

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

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

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

Помните: в 99,9% случаев у ваших коллег есть адекватные причины не успеть или не сделать что-то: не успеть выкатить задачу к релизу, не успеть отправить документ. И работа в команде - это не про "наябедничать на соседа и испортить отношения", а про "помочь соседу, если ему нужна помощь".

Анна Обухова про то, как различия между официальными и неписанными правилами убивают продуктивность - https://www.facebook.com/story.php?story_fbid=2012517642133567&id=100001260518680

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

И продолжение от Анны Обуховой про инсайты - https://www.facebook.com/100001260518680/posts/2013641095354555/

Особенно интересно она пишет про людей с "рывковым типом производительности". Эти люди вообще все задачи решают через процесс похожий на инсайт.

Когда я решаю типичные и понятные задачи, я действую вполне линейно. Маленькие шаги, последовательность - вот это всё.

А со сложными задачами у меня работает - "загрузить проблему, расслабиться и ничего не делать". В моем случае гулять часами, иногда много дней подряд.

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

#тлен_и_усталость

И про рывковый тип производительности - https://www.facebook.com/story.php?story_fbid=2014961238555874&id=100001260518680

#тлен_и_усталость

Для меня тут самое ценное про то, что "если вы 2 часа бродили и 15 минут писали, то работа занимает 2.15, а то и 2.30, а не 15 минут как хочется думать".

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

#тлен_и_усталость

Издательский дом "Питер" перевели "Site Reliability Engineering" от гугла на русский (https://www.piter.com/product/site-reliability-engineering-nadezhnost-i-bezotkaznost-kak-v-google).

Определенно хочу до нее добраться.

#книги

Доклад бывшего коллеги на DevOpsDays Moscow про то, как эксплуатации жить с сервисами - https://www.youtube.com/watch?v=j9I4oeEXBO8

Все боли очень знакомые:

- нет документации ("Если документации нет - значит никто не скажет, что она плохая!"),

- сервис передали другой команде и теперь там никто не знает, что с ним делать,

- уволился менеджер, который знал как там все должно было работать,

- партизанская разработка ("мы тут быстренько что-то сделали и оно уже приносит деньги!")

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

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

Но вот в реальной жизни это все раз от раза не работает(

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

И в тему эксплуатации статья на хабре про то, из каких частей состоит инцидент и как сократить время восстановления - https://habr.com/company/okmeter/blog/422973/

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

Осваиваю теги: #размышления.

(старые записи закрыты для редактирования (что страшно неидеально — нельзя пойти и ИСПРАВИТЬ), однако новые-то в моих руках)

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

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

Недавно встретила во внутренних блогах знакомую фразу «if you're the smartest person in the room, find another room» (если ты самый умный человек в комнате, пора искать другую комнату).

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

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

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

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

Вчера говорила терапевтке, что чтение старых текстов вызывает у меня две реакции:
1) вот отстой, сейчас я бы написала об этом гораздо лучше
2) как хорошо написано! Как будто и не я писала. Я бы сейчас не смогла повторить это, а значит — лавры не мои, а меня-прошлой, которой уже нет.

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

А ещё это значит, что я ценю себя (и хвалю, и поощряю, и довольна собой) только в прыжке. В действии. В исполнительстве. В изобретении. В занятости. В полезности.

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

Ведь если сейчас я делаю что-то на 15% лучше прошлогоднего, то это не только радость от прогресса, но и ужас от того, что к следующему году нужно смочь как минимум на 16% лучше сегодняшнего. Иначе какой это прогресс. Прогресс — прошлый день! Сейчас важен и прогресс прогресса, рост год к году роста год к году.

Короче, можно себя использовать и выпотрошить очень эффективно таким неврозом.

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

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

Татьяна Никонова рассказала про кампанию, где професиии, описываются через стереотипы о женщинах - https://www.instagram.com/p/BoEUTO3i3sS/

Тестировщиц там еще не было. Я бы предложила "Она перепроверяет всё, что ты делаешь. Потому, что она тестировщица".

#diversity
#women_in_tech

Хотя нет, вот такое было - https://www.instagram.com/p/BoKT1J0jAUi/

#diversity
#women_in_tech

Подборка материалов про исследовательское тестирование - http://www.software-testing.ru/library/testing/other-testing/2890-pathway-exploratory-testing

#записная_книжка

Когда я пришла на первую работу тестировщиком мой начальник как раз увольнялся. Мне дали редмайн, задачи и сказали тестировать)

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

Еще на одной работе я на второй день уже участвовала в регрессионном тестировании и начала делать задачи. За три недели я более-менее освоилась и... поменяла команду. И сразу получила крупную задачу на несколько дней.

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

На этой неделе я закончила первый большой проект, который я тестировала больше четырех недель. И очень собой горда.

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

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

С нежностью вспоминаю, как я писала курсовые и дипломы в LaTeX. Про систему контроля версий я тогда правда ещё не знала)

Всё началось с этой статьи - http://mydebianblog.blogspot.com/2006/10/blog-post_30.html?m=1

Меня тогда поразила идея, что можно разделять текст и его оформление. И заняться оформлением отдельно. В Word тоже можно настроить стили, но я тогда это не умела и не подозревала, что так можно)

И формулы, конечно же. В LaTeX я набирала сложные формулы гораздо быстрее и проще, чем в Word.

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

#письмо

Диплом как код

На Хабре вышла статья «Как я диплом в LaTeX писал с GitHub, Docker и TravisCI»

https://habr.com/post/424805/

Начала читать перевод SRE book. И впечатления у меня очень неоднозначные.

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

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

#книги

В SRE book авторы пишут любопытное про суммарный уровень ошибок.

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

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

В Google под суммарным уровнем ошибок (или бюджетом) понимают процент неуспешных запросов за квартал. И это хорошая точка, где сходятся интересы всех сторон.

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

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

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

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