В IT чудес не бывает

Ну что?
Каникулы продолжившие отпуск закончились, традиционная пора вспоминания рабочих паролей (хотя бы для менеджера паролей), рабочих задач и тдтп
Всех с началом нового рабочего года 🖖
#it_memes

Всех с наступающим! 🎉 🎄🎅🏻
Больше желаний и настроения их достигать 🙂
Хорошего всем года!

Разработчик, помни! Тестировщик чувствует твой страх. Малейшее колебание при ответе на вопрос "ты проверял?" будет воспринято как слабость!

чужие #мысли_вслух из древних интернетов

How Hard Should Your Employer Work To Retain You?

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

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

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

А статья хорошая, почитайте, кто еще не сталкивался с этим вопросом. Немеджеров тоже касается.

#management

Что на самом деле стоит за "оцените тестирование":

Сколько времени нам нужно, чтобы узнать все, что нам нужно знать о чем-то, о чем мы пока мало что знаем?

#testing чужие #мысли_вслух и #классика из древних интернетов

Немного 10-летней классики на тему "зачем нам тестировщики, если разрабы сами тестируют свой код"

• Нужны ли тестировщики, если разработчики пишут тесты?
• Thinking about No Testers
• When Programmers (and Testers) Do Their Jobs

Самое интересное, все заметки вышли +/- в одно время (но я был первый 😃), видимо ретроградный Меркурий 🥸.

PS забавно, что мой коммент к моему посту с указанием заметки с "About 98 Percent Done" (2я ссылка выше) привел к сессии тестирования Disqus, который, похоже, на тот момент времени не имел тестировщиков. Получилось весело 🤭

#классика #testing

Сегодня без комментариев в традиционно-пятничных #it_memes

7 uncommon opinions after 10 years of product management
• “Product” isn’t a role
• The worst thing a PM can be is intelligent
• Stay out of the spotlight
• I still don’t know what epics and stories are
• Metrics suck
• There’s no “way to do product”
• Don’t read blog posts — write them instead

Я не PM/PO, но очень давно с ними работаю. И комфортнее с теми, кто следует хотя бы части этих принципов 🙂

#развитие

Ну вот только вчера философская мысля...
А тут вотъ: Using fake deadlines without driving your engineers crazy

... Putting challenging timeboxes on projects in a healthy environment can lead to serious innovation and creativity.
...
5 mistakes to avoid
1. Not communicating to the team what will happen after the deadline
2. Not consulting with your team about what’s feasible
3. Pushing your team too hard to meet it
4. Not pushing your team to meet it
5. Being rigid about the deadline

#процессы

Если предположить, что
1) закон Паркинсона работает (а эмпирика показывает, что так и есть)
2) у задачи нет сроков выполнения*

-> получается, что задача никогда не будет сделана, а значит, никому ненужная.

*Если сроки выполнения задачи перенесли 3 раза** - она тоже бессрочная.
** число получено эмпирическим путем

#мысли_вслух #it_философия

Tying Engineering Metrics to Business Metrics

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

#metrics

Среднестатистический middle manager в пятничных #it_memes
ох уж этот #management ...

How to grow as an Engineering Manager

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

Наткнулся тут на статью "When engineers become managers: How to be a great technical leader".
Прочитал пару раз, гоняя в голове стада радужных единорожек.
В целом умного-нового-ничего, скорее спорил с самим собой по некоторым моментам.

Но пост не про это :)

С радостью и интересом наткнулся на фразу в конце "Now, it is important to draw a distinction between optimism and Pollyannaism."

Господь, полез гуглить "поллианизм". Оказалось, если совсем просто, это умение находить пользу/радость даже в самой большой куче 💩
Шикарно, теперь знаю новое слово и я - поллианист, нашел пользу в банальной статье 😃

PS кстати, список литературы там посмотрите, действительно хорош.

#management

"Решаем проблему, а не человека".

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

И вот именно это и есть настоящая проблема.

Вот такая вот смысловая загогулина.

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

Когда вы работаете над MVP старайтесь больше думать над "ценным", а не фокусироваться на "минимальном".

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

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

не совсем #it_memes но #байки и #ваши_вопросы

Понимаю, что далеко не весь контент в канале прям всем полезен и сходу применим (вопросов нет только к #it_memes). Много философии и древних баек.
Но кто вам это еще расскажет...

Че-то недавно вспомнилась тут давнишняя мысль:
"Если вам больше 38 и вы работаете в найме не совсем топом, то в ближайшие годы у вас случится босс много младше вас".

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

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

Помню лишь, что "много младше" в какой-то момент "стабилизируется" и дальше младше не становится :)

В общем это не страшно.

Но если че, то подумайте, может пора шевелить извилинами и/или локтями активнее.

#it_философия #байки

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

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

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

... my testing expertise became less valuable at the end of the cycle and much more valuable at the start.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.
...
I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer.
A software developer needs to be able build a product with confidence that it does what it’s expected to do.
Knowing how to do that at a basic level should be critical to the role of a good software developer.
For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Forget developers in test, we need testers in development (2013)

#testing #quality