Читаю сейчас "Переходный возраст" Лоуренса Стейнберга. Автор рассказывает про подростковый период, опираясь на нейробиологию.

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

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

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

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

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

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

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

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

И основной вопрос - зачем идти в корпорацию и строить карьеру там. Что это дает и чего это стоит.

https://www.facebook.com/story.php?story_fbid=10157676824028032&id=703368031

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

Кого мы из женщин мы знаем в математике и computer science? Я сходу могу вспомнить только Аду Лавлейс, Грейс Хоппер и Софью Ковалевскую.

Вчера я смотрела, что рекомендуют по системному администрированию. И много кто говорил о книге Немета про администирование Unix. Только это книга Немет, Эви Немет. Она была ведущим автором этих книг.

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

#women_in_tech
#diversity

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

«Расскажите ребенку, что учеба — это движение из точки, где ты вообще-вообще-совсем ничего не умеешь, в точку, где худо-бедно умеешь, но еще не блестяще. На этом пути в каждом шаге ошибаться не стыдно, а естественно. И ошибаться нужно будет много раз. И пробовать, и еще пробовать, и с каждой попыткой будет получаться немножечко лучше. А иногда будет казаться, что все замерло, и никакого “лучше” не происходит. А иногда будет даже немного хуже, чем в прошлый раз. И да, это неприятно, но вот так, мать ее, выглядит учеба.

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

К сожалению, прежде, чем объяснить это ребенку, иногда приходится повторить себе. И не раз».

Про общение с заказчиками и партнерами

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

Например, часто случаются такие диалоги:

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

А теперь сравните его с таким диалогом:

- Коллеги, добрый день. Подскажите, почему на этот запрос мы получаем ошибку такую-то? (пример запроса)
- Добрый день! Вы забыли передать параметр userId. Вот пример правильного запроса (пример запроса)

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

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

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

3. Не приводите отсылок к началу переписок: вместо того, чтобы написать "посмотрите документацию, которую мы вам отправили полгода назад" или "см. сообщение от 14 авг. 2000 года", отправьте эту документацию еще раз или продублируйте сообщение.

4. Пробуйте не просто отвечать "да/нет" на вопросы, а понимать, почему вас об этом спрашивают. Попробуйте отвечать на вопросы чуть шире, чем вас попросили: вместо "да, этот параметр нужен" написать "да, этот параметр нужен, потому что бывают такие случаи, что…" - очень часто в таких объяснениях можно заранее выявить нестандартные случаи.

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

К проблеме, о которой писала выше - про общение с заказчиками и партнерами:

Недавно на вопрос "По какой логике вы определяете, использовать этот параметр или вот тот?" мне просто скинули кусок php-шного кода со словами "Вот так. Остались вопросы?".
Это пример, как делать не надо никогда. Надеюсь, что очевидно, почему, но все же:

Во-первых, ваш собеседник может не уметь читать код (внезапно), особенно если вы не знаете точно, кто он по должности на стороне партнера.

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

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

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

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

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

#письмо

Интересное о женщинах в IT, diversity и гендерных квотах - https://medium.com/russian/%D0%BE-%D0%B6%D0%B5%D0%BD%D1%89%D0%B8%D0%BD%D0%B0%D1%85-32c1e98de161

Я не согласна с тем, как автор выводит из эволюционной теории пола гендерные роли. А вот его опыт с гендерными квотами - действительно любопытен.

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

Я бы хотела, чтобы хотя бы первоначальный отбор шел по резюме без личных данных - ни имени, ни возраста, ни пола.

#diversity
#women_in_tech

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дни постов про 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» (если ты самый умный человек в комнате, пора искать другую комнату).

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

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

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

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