Немного прагматизма.
Менять людей сложно, иногда проще их поменять, как бы это странно и цинично не звучало. Но если не улучшать процесс собеса и онбординга, то ничего хорошего не получится.
Собеседование - один из важных инструментов взращивания нужной вам инженерной культуры и экспертизы в команде: вы не должны забывать оценивать на собесе то, что вам ценно/важно. И это скорее всего не только харды.
Немного моего творчества про собесы:
• Нетехническое собеседование - зачем, полезные вопросы
• Немного про наём, собеседование и испытательный срок от вашего КО
• "Вкусняшка" для менеджера программистов или лучший момент в работе менеджера
• Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

#management #процессы #собеседования

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

Тема оценки предстоящих работ постоянно в топе инфоленты, потому что все стараются, но мало кто попадает: потому что это сложно или долго.
Estimation Isn’t for Everyone одна из свежих статей на эту тему. Забавно, что там 1:1 повторяются мои мысли про усреднение оценки на периоде времени, что дает возможность перейти просто к количеству выполняемых задач для измерения скорости команды.
А время по оценке каждой задачи в отдельности правильнее тратить на то, чтобы понять, что именно нужно сделать и эксперименты. Поэтому что именно это уменьшает неопределенность и снижает риски.

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

#процессы #management #оценка

Давайте сегодня сдуем пыль со старой статьи-перевода (я начинал вести свой блог делая переводы интересных статей, добавляя свои мысли по ходу).
Кто такой хороший тестировщик?
Статья была какое-то время очень популярна (по статистике). Что изменилось с тех пор? Имхо - ничего. Классика.
ЗЫ Только ссылку на оригинал пришлось поправить, потому что старая умерла.
#testing #классика #развитие

Рубрика "Вопросы из зала"
Как руководителю обучать руководителей?
Disclaimer: реального официального опыта быть менеджером менеджеров у меня нет, дальше просто мои мысли и идеи, подтвержденные лишь по касательной. Короче, как бы делал я. В подписчиках есть большие руководители, надеюсь они дополнят, поправят. И конечно, речь ниже про IT менеджеров.

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

Итак, как обучать руководителей? Хмм, да кажется проще, чем инженеров, потому что нужно научить тому, что, по идее, уже знаешь и делаешь сам. А если не знаешь - научиться вместе 🙂

Регулярные задачи и активности у подчиненного руководителя сильно пересекаются с твоими текущими или ты ими занимался недавно.
Проведение собесов/отбор, 1:1, формирование команд, планирование и работа с рисками, бюджетирование (😭).
Ты же сам все это уже умеешь? Делись опытом, спрашивай, слушай (больше, чем говоришь сам), направляй в нужную тебе сторону, поддерживай правильные действия.
Если есть сомнения в своих педагогических навыках, организуй обучение на специализированных курсах, посещение конференций. Только важно потом обсуждать увиденное/услышанное/изученное.

Самое сложное, пожалуй, это оценить, как это все применяется твоим сотрудником на практике.
Но это уже тема отдельного разговора.

#ваши_вопросы #management

Традиционный пятничный мем.
Картинка 10+ летней давности. Тогда прямо в тему. Сейчас, хочется уже верить, не совсем. Но все равно, улыбает.
PS или все так же? 🫠
#it_memes #тестирование

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

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

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

PS как-нибудь напишу про пирамиды тестирования и то, что про них думаю.
#testing #мысли_вслух

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

#management

Очень интересно сейчас выглядит продуктовая разработка в какой-то части отечественных продуктовых компаний: нужно сделать продукт, который повторяет некоторый многим привычный, но иноземный, совокупного возраста лет 10-25. И нужно не просто частями наращивать, а чтобы сразу и полностью копия.
Все вот эти вопросы “а какую проблему решаем?” в традиционной продуктовой (да любой) разработке втыкаются в “вот оно вчера так все работало, и мы хотим, чтобы все так же работало, но с вами”. Огромное поле задач для людей, которые умеют в приоритизацию и переговоры, пока разрабы судорожно повторяют фичи возраста 10+ лет, потому что пользователю нужно именно это. Вот такая вот вроде продуктовая, а как бы и нет, разработка. Некоторые бэклоги забиты на годы вперед. Порешает ли пользователь свои проблемы без новых продуктов? Я думаю, что, в какой-то степени, да (просто пример одного из вариантов решения). Понадобятся ли эти забитые бэклоги после этого, хороший вопрос…
Но это шансы и их надо использовать. И в этой ситуации важны качественные принятые решения со стороны разработки, как на, условно, тактическом, так и стратегическом уровне, позволяющие закрыть вопросы того, что нужно было "вчера" и того, что понадобиться "послезавтра". А это не всегда совпадающие истории...
#байки

Вчера были мысли написать сегодня что-то умное про бюджетирование, но во-первых, где я и где "умное бюджетирование", а во-вторых сегодня же пятница.
Давайте лучше порефлексируем о результатах недели.
Кто-то отправил файлы с бюджетами на рассмотрение, кто-то добавил очередной if-чик в надежде, что плохо воспроизводимый баг уйдет, а у кого-то наконец-то перестали "моргать" тесты (но это неточно).
#it_memes #байки

Молодые родители отмечают каждый новый месяц ребенка в течение года. У владельцев собак то же самое со щенками. Я уже немолодой родитель, да и собаки у меня уже взрослые.
Но вот каналу - 1 месяц 🎉
Спасибо, что подписались и, если верить статистике, даже его читаете (знаю-знаю, не все). С одной стороны, хочется у вас попросить обратной связи: чего добавить, чего убрать (больше/меньше баек, больше просто ссылок без моих комментов, долой засилье мемов). А с другой 🫣, лично меня текущий формат пока устраивает. Но с удовольствием подумаю над вашими предложениями, если кому-то захочется поделиться своими мыслями/вопросами/идеями.
Из удивившего в телеге: в тлг-канале не видно, кто именно ставит реакции под сообщениями (в комментариях видно, а в основных постах - нет). Поэтому не стесняйтесь ставить свои 💩 и ❤️- я все равно не вижу кто именно отреагировал, но зато вашу реакцию на пост можно оценить.
Очень признателен тем, что находит время комментировать, спасибо вам большое, вы помогаете.
Задающие вопросы - для вас в моем ❤️ отдельный уголок.
Погнали дальше…
#байки

Все хэштеги и группа для обсуждения
#байки - истории из жизни
#it_memes - веселые картинки по теме канала
#quality
#testing
#test_automation
#unit_testing
#management
#процессы
#tech_read - полезные статьи
#ваши_вопросы - ответы на ваши вопросы, можно задавать любым удобным вам способом
#holywar - посты, которые могут вызывать горение
#мысли_вслух - короткие, но умные мысли, чаще мои :)
#metrics - про метрики (технические, процессные)
#развитие - посты про развитие, свое и команды
#it_философия - посты-наблюдения про отрасль
#codereview
#observability
#собеседования
#вопросы_с_собесов
#про_резюме
#оценка
#тесты_в_проде
#стратегия чтобы это не значило

Все кому заходит контент, но телега мешает его обсуждать, велком в группу https://t.me/+eVSMX4QvqvxlNjcy

Карьерные лестницы 1.
Так или иначе вопросы развития мозга, в идеале, одновременно с ЗП встают перед каждым из нас.
Многие при этом надеются на то, что этот план развития им предоставит их менеджер. Я бы даже сказал "уверены, что только менеджер может их составить".
И хотя в задачи менеджера или лида действительно может входить “развитие сотрудников”, мой опыт показывает, что лучше получается, когда менеджер дает направления, текущие места приложения возможных усилий, а непосредственно план развития самостоятельно составляется сотрудником. И уже потом этот план совместно обсуждается, полируется и берется в работу.
Понятно, что условный джун не составит себе хорошего плана и тут требуется больше участия лида или опытного сеньора. Но даже в этом случае самостоятельной работы не нужно исключать.
Наличие в компании инженерных “лестниц” серьезно помогает и в составлении планов индивидуального развития, и в обсуждениях пересмотров ЗП*, и в формированиях ожиданий от кандидатов и списков вопроса на собесах.
*Тема увязки уровней компетенций лестницы с уровнем ЗП кажется ожидаемой, понятной и логичной, но не все так просто обычно. Поговорим про это попозже.

Немного полезных ссылок с описаниями возможных уровней лестниц:
1. Карты развития, в целом без привязки к лестницам, но много интересного по разным ролям/языкам и тп. Что важно, упор сделан именно про технику, потому что обычно сами лестницы очень абстрактные. Подобные ресурсы с последующим наложением на потребности команды, как раз и помогают в самостоятельном составлении плана.
2. Один из возможных вариантов лестницы.
3. Ну и еще одна, в качестве примера
4. Инструмент для составления своей лестницы
#развитие #процессы #holywar

Годовые планы и бюджеты
Каждый год, уже много лет, убеждаюсь, что годовые планирования - это что-то такое... необычное.
Это как раз то, что доказывает, что в планировании важен сам процесс познания и осознания желаний, а не конечные артефакты.
Потому что каждый раз, очередное планирование года тонко (а иногда и толсто) показывает, что в этом году все делали не то, что планировали. То черные лебеди прилетят, то сами, что чаще, накосячим, то “опять власть видение меняется”, а то выстреливает то, что делали не планируя.
И хотя порефлексировать о причинах конечно стоит: возможно что-то все же стоит менять, но относитесь к этому действу проще и гибче, без надрыва.

#байки

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

Сегодня философский #it_memes

Забавный инсайт после просмотра доклада: наверное в каждой компании есть команда Core (самые важные и самые озвиздюленные ребята обычно).
Сейчас правда появилось более стильное название: Platform team (степень важности и озвиздюливания сохраняется, местами даже увеличивается)
#процессы #quality

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

Лирическое отступление: где-то одновременно с этим, тестеров переименовали в QA (не поменяв сути их деятельности и не поняв, что же значат эти 2 буквы), спустя какое-то время админов переименовали в DevOps (хороший получился трик с повышением ЗП, хотя и задачи чуток поменялись, да).

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

На чем же виток спирали “замкнулся”?
Специализация.
Продукты стали еще сложнее, инструментов стало больше, впихнуть все потребности в одну (даже самую умную) голову стало сложнее, а в команде типа не может быть опсов больше, чем девов.
Появились отделы и даже департаменты девопсов (господи, кто ж уже теперь помнит, что вообще значит слово DevOps), специализированные команды по нагрузочному тестированию, начали много говорить про, а где-то уже и появились, платформенные команды.
Пошли на очередной виток. Хорошо это или плохо?
Нет, это просто спираль, ну или мое преломление реальности. Наблюдаем дальше. Опять же, есть ощущение, что спираль восходящая.

ЗЫ кстати, в архитектурных решениях свои спирали (а может “маятники”), типа “монолит -> микросервисы -> монолит”
#байки #процессы #quality

Postmortem за $135млн
"Наиболее вероятной причиной аварии "Луны-25" стало нештатное функционирование бортового комплекса управления, связанное с невключением блока акселерометров в приборе БИУС-Л (блок измерения угловых скоростей) из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором", - говорится в сообщении.
Отмечается, что распределение команд в таких массивах данных имеет случайный, то есть вероятностный характер.
"В связи с этим в бортовой комплекс управления приходили нулевые сигналы с акселерометров прибора БИУС-Л. Это не позволило при выдаче корректирующего импульса зафиксировать момент набора требуемой скорости и произвести своевременное выключение двигательной установки космического аппарата, в результате чего ее отключение произошло по временной установке".

Рубрика "Вопросы из зала"
"Кто должен заниматься покрытием автотестами?
И как объяснить, что с текущей помойкой в проекте, которая будет переписываться глобально в течение следующих трех месяцев после релиза последних бизнес фич в этом году, это совсем не актуально?

Начнем с самого простого:
Кто должен писать автотесты - кто-то из команды, зависит от того, кто (специалисты с какой квалификацией) у нее есть сейчас и того, что мы понимаем под "автотестами".
Я знаю разработчиков, которые автотестами называют все тесты, которые у них пишут автоматизаторы (а то, что пишут разработчики это или модульные, или интеграционные). Вот такая вот “логичная” классификация🙂

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

Тогда какие тесты?
Если ожидается переписывание кода бека, когда мы меняем реализацию полезной бизнес-логики без изменения API (клиент остается тем же), то перед началом работ важно зафиксировать текущее поведение функциональными тестами на API + контрактными тестами (детальная серия статей про их теорию и практику). Это могут сделать или разрабы, или автоматизаторы (если они знают что-то, кроме написания e2e тестов через UI). Можно и через UI конечно, но я не сторонник такого подхода (такие тесты медленно работают, подвержены влиянию вспышек на солнце и в принципе случайно успешные).
Короче, в этом случае, тесты вам только в помощь и стоит не кого-то переубеждать, а выделить время на их написание.
Можно чуток схалявить и зафиксировать API вызовы с клиента и их результаты через какой-нибудь инструмент записи запросов во время ручного тестирования клиента. Удобного и правильного примера инструмента не подскажу, давно не лазил в эту сторону, но такое точно есть (вангую, что тот же Postman подойдет).
Если планируем менять и клиентскую часть, и API, или у вас моно-приложение типа десктопа или мобилки, то я бы сказал, что написание любых автотестов перед тем, как все будет переписываться, бесполезно. Время будет потрачено впустую и все тесты потом придется выкинуть. Проще их уже делать одновременно с написанием нового кода.

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

Но и это еще не все...
Есть другой аспект этой истории, уже не совсем про автотесты. Он кроется в самой постановке вопроса. Завтра продолжим.

#testing #ваши_вопросы