А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

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

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы

А давайте еще про "законы/закономерности/принципы" в IT.

Самый популярный - это закон Конвея (Conway's law):

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

Иногда звучит в такой интерпретации:

"Don’t ship the org chart!"

Похоже на то, что у вас?

Подробнее по теме:
• The Most Powerful Law in Software
• Conway’s Law in Team Topolgies: Did you really get it? (кстати, там упоминается прикольный "лайфхак": "we should design our teams (not the software yet) to “match” the required software architecture. That means reconfiguring the team intercommunications before the software is finished.")

#it_философия

Продолжая тему "менеджер и техника".

Еще несколько советов оставаться в технике будучи менеджером: Should you Stay Technical as an Engineering Manager?

PS жаль, что мои самые любимые - самые неэффективные 😒
PS2 кстати, вопросы поддержания необходимого тонуса в технике касаются не только менеджеров 😉

#management #развитие

IT Global Meetup #16
23 марта в Питере. Молодцы, оживили.
Даже интересно, сколько участников будет.
PS я тот еще социофобушек теперь, но все может быть...

Философское пятничное #it_memes ное от Макса Дорофеева

#it_философия

Пересмотрел еще раз спустя 9 лет.
Он все так же хорош. Но тогда был прямо в ❤️
Очень рекомендую.

Вадим Макишвили, доклад "36"

Следующий его доклад ("42") мне не так хорошо зашел, но думаю и он нашел свою аудиторию.

#it_философия

Лидерство - это искусство разочаровывать людей с такой скоростью, которую они могут выдержать.

(с) "кому только не приписывают"

#мысли_вслух #management

И еще один доклад Вадима "55", для руководителей.

Почему-то вспомнил про эту книгу "Общаться с ребенком. Как?"
Мысли пересекаются.

Но задумался про казус: иногда возникают ситуации, когда хочется, чтобы сотрудники "стали" наконец взрослыми, а не "инфантилили"/не вели себя, как дети.
При этом же часто менеджерам рекомендуют книги про воспитание детей...
Что это? Намек на то, что такие люди разработчики не взрослеют?

#management

What's a distributed system?
It's not microservices exchanging messages and storing data in a DB.

Небольшая шпаргалка-затравка по теме распределенных систем. Скорее просто для того, чтобы оценить масштаб бедствия в голове по этой теме перед столь любимыми многими компаниями собесом по System Design.
#tech_read

Девиз "успешных" людей в пятничных #it_memes

ЗЫ тут должен был быть другой мем, но я вовремя заметил, что у меня стало много "жоп" по пятницам.

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

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

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

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

Потом та же история повторилась с DevOps (которые сначала просто админы с большими ЗП, а потом СИАЙ-админы и админа в КУБЕ). И снова раскрутка через вакансии и отражение в резюме.

Теперь вот та же фигня с цифрами по результатам в резюме, которая 100% пришла из резюме сейлзов/маркетологов и прочих продаванов.
Все рекрутеры теперь их ждут в резюме инженеров (и уж тем более инженерных менеджеров) и предлагают всем это использовать.
И все будут писать вот такую фигню, типа "разработал и успешно внедрил новую систему рекомендаций для e-commerce проекта, используя Python (Scikit-learn, NumPy, SciPy, PyTorch, Surprise), PostgreSQL, что позволило увеличить продажи на 15% за первые три месяца после запуска".

Что не так с такими циферками в резюме?
Есть риск попасть в анекдот "Это ребята курили. Я просто рядом стоял"
1. Если вы не знаете, как именно ваша работа повлияла на эти циферки - не надо это писать
2. Если вы не знаете, как эти циферки меряются - не надо это писать
3. Если вы не можете рассказать, сколько времени занял рост до этих циферок, сколько людей и как в этом участвовало - не надо это писать

И чем больше была команда - тем меньше вероятность, что это надо писать...

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

Примеры:
- обучил 100500 падаванов
- проработал изменение архитектуры, которое привело к ускорению (циферка), повышению RPS, повышение производительности и тдтп
- затащил новый подход к написанию тестов и скорость написания тестов увеличилась с X до Y
- ускорение выполнения тестов с N до M
- протащил проект изменений через X команд
- провел X собесов из них Y прошли испытательный срок (или заонбордил 100 чуваков)
- запустил 300 новых команд

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

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

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

Для тех, у кого могут быть вопросы, зачем такое в резюме в принципе.
Числа про деньги интересны с точки зрения:
1) косвенно показывают, что инженер знает про то, как меняются бизнес-метрики его продукта
2) можно предположить, что насколько человек вовлечен в культуру product engineering

#собеседования #про_резюме

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

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

"Roast Beef and Legos" by Alan Page

#it_философия

Лет 5 назад подсмотрел у Киры Кузьменко 2 лайфхака на тот случай, когда "текст никак не пишется” (она в свою очередь тоже откуда-то взяла, но те ссылки уже "мертвые"):

1. "...если не пишется и страх чистого листа. С 2008 года практикую: надо просто начать с "ну бля, короче..." — и дальше текст сам выстраивается без воды и вот этого всего."
2. Тексты не пишутся по вдохновению, да и дождаться его иногда месяцами невозможно. (...) Трудно, как говорят редакторы, только первые двадцать минут. Правда, эти двадцать минут приходится переживать несколько раз в день.

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

В статье Алана есть интересная аббревиатура: TTWWADI.
А явной расшифровки нет, пришлось гуглить.
That’s the way we’ve always done it - вот что это значит.
И понятно, что это проблема не только IT.

#it_философия

"20% теории управления достаточно для 80% результатов. Если конечно принцип Парето работает" Ryan Lilly

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

#мысли_вслух #management

Есть ложь, наглая ложь и "тут всего пара строчек, оценю задачу в половину сторипоинта" (байки из интернетов)

#metrics #байки

Результат #codereview на 50 строк vs 100500 строк

Сделал дело и идешь смотреть пятничные #it_memes

В четверг в комментах обещал побухтеть про оценку.
Мое определение оценки:
“Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.”

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

Тут будут просто советы, а завтра про собственно процесс, как я его вижу.

1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда )
2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:
• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее
• процесс информирования о возникающих из-за этого рисках (не тянем до последнего)
3. При запуске/перестройке процесса оценки очень помогают эталонные (референтные) задачи, сравнивая с которыми мы пытаемся оценить наши текущие задачи
4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5.
Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?
5. Не бывает “копеечных” задач. Вообще не используйте это обозначение. Оно мешает запускать в голове комплексный процесс оценки задачи, зато помогает забыть про важные вещи.
6. БОльшая декомпозиция помогает точности оценки
7. Постепенный уход в сторону простого кол-ва задач, тогда можно просто считать кол-во задач и меньше думать про их оценивание.

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

И еще тут у меня было про этой теме.

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

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

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

Работу над оценкой задач на следующий спринт начинаем в текущем спринте.
Встреча 1 (30-45 мин):
• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)
• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)
• у каждой такой задачи появляется ответственный, который до проведения следующей встречи собирает нужную для оценки информацию (корректность проработки, место(-а) в коде, которые надо изменить/дописать, синхронизация со смежной командой и тд) и делает на базе этого предварительную оценку* (см дальше пояснения)

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

Встреча планирования спринта (15 мин**):
• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов
• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.

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

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

Почему такой процесс редко можно встретить в реале? :)
Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.

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

Если в компании есть инженерные отделы, основной задачей которых является “как бы” помощь продуктовым командам делать/выпускать их продукт(ы), обеспечение процесса разработки и тп, а эти команды не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемам, то рано или поздно (скорее рано) все они превращаются в “вахтеров” со своими правилами, регламентами, "best practices" и системой разрешений.
Работа продуктовых команд при этом превращается в увлекательное преодоление множества препятствий к релизу…

Что это могут быть за команды? Те самые “общие” devops, отдельные внешние команды тестирования, безопасники, разработчики типа “общих” компонентов.
И в итоге у каждого есть понимание смысла своего существования, целей и пользы, но на выходе сплошной output вместо outcome и, эммм, напряженные отношения….

Варианты "че с этим делать"

#байки #мысли_вслух #holywar

Понятно, что надо плясать вокруг "не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемами".
1. Работающий вариант распространения контекста (в обе стороны, кстати говоря) - это "командировки" инженеров в продуктовые команды и наоборот.
2. Донесение мысли о том, что все они тут нужны не для того, чтобы свои задачи работать, а чтобы продукты деньги зарабатывали, кажется очевидным, но почему-то обычно самым сложным :)
3. Повышение прозрачности работы "общих" команд для всех остальных. Бывает такое, что они реально дело делают, а со стороны выглядит как... "херней страдают".
4. Распространение знаний/экспертизы в продуктовые команды

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