Гой еси, добры читатели.
Решил завести телегу: twitter стал неудобен, в блог коротко писать лень. Пусть все, что нахожу интересного в сети по теме менеджмента, качества и процессов в IT будет тут, заодно сдобрю своими мыслями и разбавлю ссылками на старые статьи из блога.
В тви что-то останется, но буду потихоньку переезжать сюда.

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

Мощный лонгрид про то, как замапить то, для чего нужен продукт на то, как его будут делать
Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies
Вообще тема с Team Topologies у меня зашла не сразу, постепенно.
Но сейчас она у меня хорошо отражается на опыт (прошлый и текущий)
#процессы

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

Я думаю, что у многих людей моего поколения ответ будет похожим: "в школе занятия были", если со школой повезло.
У меня это тоже было в школе, где-то в 1989 году (+/- , так далеко я уже не все помню 😂).
Потом был УПК* (учебно-производственный комбинат), где была написана первая "полноценная" программа на бейсике (но это неточно) - лабораторная работа по оптике, работа линз, "графика", лучики, преломление, черно/белая красота.
*Для тех кто не в курсе: УПК это тема, когда ты еще учась в школе, обучался какой-то профессии. У меня за 2 года была слесарка (слесарь механосборочных работ) и вот "оператор ПЭВМ".

После школы у меня был некоторый перерыв: вуз и специальность у меня, эмм, военная, связь и все вокруг нее. По АСУ занятия были, но глядя на нынешние программы обучения по IT, можно сказать, что ничего и не было. Хотя программы немного писал и даже диплом был с программой (Turbo Pascal).
Фан-факт: после увольнения со службы я долго не мог найти работу и я даже ходил на собес в Максидом продавцом (магазин товаров для строительства, ремонта и тп), но не прошел 😂
Но потом, по знакомству, попал к своему однокашнику писать Delphi-компоненты на заказ.
И-и-и понеслось. На календаре был конец 2000 года.
#байки

Про QualityGate здорового человека
https://medium.com/thefork/the-need-of-a-quality-gate-at-thefork-8adf913adc6c
#quality

#рефлексия_без_гуглежа
Я часто наступаю на одну и ту же граблю: уравниваю менеджмент и лидерство. В целом они часто пересекаются по жизни и соблазн их уравнять велик. Является ли лидерство частью или одним из инструментов менеджмента, или это параллельно существующие явления? Конечно параллельно: можно быть менеджером без лидерства, а можно быть лидером и не быть при этом менеджером.
Когда-то давно я вывел для себя 7 важных умений менеджера:
1. Найти правильных людей
2. Дать им цель
3. Не мешать или не допекать излишним вниманием
4. Уметь и иметь желание играть в игру "одна голова хорошо, а две лучше" - по запросу от команды
5. Уметь слушать
6. Обучать команду и себя
7. Получать удовольствие от работы и от команды

Можно их использовать без лидерства? Наверное можно. Но с ним это получается, говоря программерским языком, нативным образом. А может часть из них и есть лидерство?
Короче, надо освежить эту тему в своей голове.

PS кстати, про навыки менеджера, у Google их 10 и они частично пересекаются с моими.
#management

Неплохая подборка
A compilation of outstanding testing articles (with JavaScript)
https://practica.dev/blog/a-compilation-of-outstanding-testing-articles-with-javaScript/
#testing

Не все best practices одинаково полезны 🫣
Всем хороших выходных.
#it_memes

Хорошее дополнение к этим пунктам:
"I don’t know when I fell into this stupid habit, but time and time again, I’ve found that the best way for me to grow my team (as well as my own career) is a path where my leadership job ends up being obsolete."

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

#management

Так получилось, что за свои 20+ лет опыта, я постоянно бывал в ситуациях, когда продукт (или его большой функциональный кусок), который начинала разрабатывать моя команда, спустя какое-то время умирал. Иногда еще до того, как я уходил из компании, иногда уже после, но "умирал". Я бы даже сказал жестче: вообще все, что стартовало в моей команде или с моим участием не летело дольше 3-5 лет.

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

Ну и обращая внимание на частоту "круговорота" IT-шников между компаниями, можно наблюдать, что некоторые просто не дорабатывают до того момента, когда их проект закрывают.
Поэтому я решил (уже давно), что не стоит выдавать себе "черную метку".
А просто нужно быть готовым к тому, что твое "детище" закроют. ☠️

И хотя это были не "классические" стартапы с нуля, а новые проекты/продукты внутри больших компаний (а это 2 большие разницы с точки зрения срока "дожития"), я попробовал ответить на вопрос, с которым ко мне пришел бывший коллега несколько лет назад:
"Я собираю негативный опыт (ошибки) - интересно было бы услышать твой top советов - как развалить IT проект/компанию?"
Что у меня получилось:
- неправильные люди (для каждой стадии жизни проекта/продукта важны разные умения и психотипы)
- неправильный выбор технологий (скорость реализации нового и изменений, скорость найма)
- сделали прототип и потом не выкинули его на помойку, а начали на нем продукт писать
- неподходящие процессы разработки или несоответствие их текущему статусу проекта
- отсутствие инженерной культуры и забивание на правильные инженерные практики
- мало слушаем своего пользователя
- сильно случаем своего пользователя :)
- недостаточный маркетинг
- неумение/нежелание продавать (или продавать новое, если есть понятное старое)
Остальное, кажется, следствие или комбинация выше перечисленного.

Ответил и забыл 🙂 А месяц назад Антон мне про этот вопрос и мои ответы напомнил. Забавно, но я с удовлетворением обнаружил, что за прошедшие годы ничего не поменялось: добавить/удалить оттуда нечего.
Хотя, вру, сейчас я бы добавил "недостаток целеустремленности".
#байки #процессы

Для тех, кто хочет потестировать поле ввода возраста самостоятельно и с помощью ChatGPT
https://jarbon.medium.com/testing-bolt-on-ai-dcf85d26a87d

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

При этом:
- часто календарь забит регулярными встречами, которые потом отменяют за 5 мин до их начала, а не отменяют вообще, потому что "потом не будет возможности накинуть встречу, все слоты займут" 🤡
- эти же люди часто не смотрят до встречи в предлагаемую повестку и не читают приложенные документы/ссылки 😡
- из-за этого встреча затягивается и автоматом двигает остальные встречи, которые в календаре идут сплошняком.
Сплошное бинго🤪

Впрочем, раньше я был более категоричен:
"Как понять,что ты плохой менеджер?
Просто посмотри в свой календарь,если он забит под завязку и туда не впихнуть встречу раньше, чем через 2 недели,то тебе есть над чем поработать.
А если речь про встречу,которую ты сам и предложил накинуть,то совсем жопа."

Что делать, если ваш календарь такой, но где-то в глубине души вы понимаете, что это плохо.

Про календарь разработчика завтра.
#management #процессы

Серия статей про полезные практики и подходы в тестировании микросервисов https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/
#testing #tech_read