Мощный лонгрид про то, как замапить то, для чего нужен продукт на то, как его будут делать
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

Вчера обещал про календарь разработчика.
Спойлер: тут без чудес, рекомендации те же, что и менеджерам.

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

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

Что туда может входить?
- всеми любимые Scrum-активности (независимо от реальности, все свои процессы в 99% называют Scrum, так принято, не будем нарушать традицию) по некоторым оценкам могут занимать суммарно от 2х дней в 2 недели
- встречи для обсуждения технических моментов со смежными командами (тут частота зависит от степени желания что-то обсуждать, некоторым "проще" потом переделывать)
- собесы (кому не везет у тех по 3-4 собеса в неделю, по 1-1.5ч каждый)
- если повезет, то будут 1:1 с лидом/менеджером (если совсем повезет, то раз в 2 недели)
- партия в кикер или плойка
В итоге, иногда, на собственно работу (написание/ревью кода, прогон тест-кейсов и тд) может оставаться по 3-4 часа в день.

Много это или мало? Тут как посмотреть: иногда качественно проведенная встреча с другой командой может привести к тому, что вам и кодить/тестить ничего не придется.
Scrum-активности тоже могут занимать немного времени, если просто начать там делать ровно то, ради чего они придуманы. К примеру Daily Scrum (как правильно называется то, что часто называют standup) может заканчиваться за 5 мин, если фокус не на перечислении каждой задачи, а на обсуждении проблем достижения цели спринта. Ну и тд.

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

The Architect’s Blueprint: Understanding Software Styles and Patterns with Cheatsheet
https://medium.com/bytebytego-system-design-alliance/the-architects-blueprint-understanding-software-styles-and-patterns-with-cheatsheet-5c1f5fd55bbd
#tech_read

И еще немного про встречи из анналов истории :)
#it_memes

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

Хорошо, если будет обозначен процесс изменений, для того, чтобы втащить что-то новое, нужно предварительно подготовиться: формулирование проблемы, проработка вариантов решения, плюсы/минусы альтернатив, критерии успешности эксперимента (если предполагается эксперимент), "план Б", документирование решения и обучение команды/команд (если втащили что-то мало ей известное). Может звучать "бюрократично", но это направляет креатив в конструктивное русло и является одним из инструментов влияния на цену ошибки.

Что убивает инициативу?
- ответы в стиле "это не ваша забота, вы код пишите лучше"
- строгое разделение зон ответственности: разрабы пишут код, тестировщики проверяют результаты, девопсы это разворачивают. И никто никого не пускает в свои "владения"

#ваши_вопросы #management
Интересующие вас вопросы можно задать в комментах под сообщениями или в личку. "Редакция" всегда рада поделиться опытом или поразмышлять над возможными ответами, если такого опыта еще не было :)

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

Интересный вопрос (часто возникает в той или иной формулировке):
"Качество ПО - это ответственность команды". Но почему-то разработчики не хотят тестировать продукт (когда надо)? И писать автотесты (когда надо)?

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

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

Что происходит в реальной жизни?
Разработчиков не учат тестированию. Более того, популярно мнение, что это вредно. Я однажды уже комментировал это . (Уже стесняюсь писать про то, сколько лет назад это было, но мало что менялось с тех пор).

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

Можно долго мусолить тему "разрабов в тестировании", но реальность такова, что только руководитель разрабов определяет, участвуют они в тестировании или нет, а если участвуют, то как именно.
Поэтому если вы, как тестировщик, имеете вопрос "почему разрабы не тестируют", то задайте его их руководителю. Что делать, если этот вопрос возникает у руководителя, мы обсудим позже, хотя кажется, что ответ очевиден.
#testing #holywar

Софт-скилы под давлением временем только твердеют и замещают собой старые хард-скилы, которые превращаются в песок - путь менеджера
#мысли_вслух

Мне очень нравятся DORA метрики. Это хороший инструмент для оценки качества DevOps-процессов. И хотя изначально (в лоб) он больше подходит для тех проектов, которые можно обозначить, как "self-coded + self-hosted", все метрики можно замапить на любые типы проектов и типы релизов. Вот пример того, как это можно сделать для мобилок.
PS грустный факт: я нечасто участвовал в собеседованиях DevOps-ов, но за все время не могу вспомнить, чтобы кто-то из них знал эти 4 буквы DORA.
#metrics