Хорошее дополнение к этим пунктам:
"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

"...давать ошибаться..."
Кстати, про ошибки.
Все делают ошибки. Ошибка - это нормально, это в целом даже ожидаемо. Ненормально ничего не делать после того, как ошибка произошла, считая что "ошибка - это нормально".
И под “делать” я тут понимаю не “кару небесную”, а нормальную работу над ошибками: понять причину, неочевидные следствия и шаги по их устранению, а также нужные исправления для того, чтобы уменьшить шанс на повторение ошибки и/или снизить ее цену.
#мысли_вслух

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

А если мы говорим о менти, который хочет получить совет, то лучшее по этой теме было тут "Instead of looking for a mentor, just find somebody who can answer some questions you have. Then, if you think they can answer some more, ask them again. In reality, a mentor is mostly just somebody that answers questions more than once."

Ну а я постоянно следую этому совету
"If you want a mentee - get good at something and make yourself available to answer questions about it"

PS хотя было уже несколько моментов, когда встречи для обсуждения вопросов-ответов так и не состоялись по разным причинам, иногда от нехватки моих сил на это, иногда вопрошающий исчезал вместе со своими вопросами. Может проблема решалась другим способом или просто теряла актуальность. Допускаю, что оплачиваемая история не позволяет относится к ней так неорганизованно. Но это неточно 🙂

#развитие

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

Как я для себя формулирую ожидания от Team Lead / Tech Lead:

Team Lead:
• фокусировать
• вдохновлять
• растить
• коммуницировать
• воспитывать
• поддерживать
• оценивать производительность команды
• выявлять внутренние проблемы в команде на ранних стадиях
• решать конфликтные ситуации
• контролировать внутренние процессы разработки
• организация ретроспективы

+ добавляется то, что обычно делает или Tech lead, или эти активности размазываются по другим людям в команде:
• разработка (программирование или тестирование)
• соблюдение регламентов
• декомпозиция задач
• code review
• техническое воспитание новичков
• принятие решений в рамках тех технологических решений и стандартов, что есть в компании
• участие в архитектурной(-ых) группе(-ах)
• контролировать технический долг
• участвовать в отборе кандидатов, включая собеседование
• изучение индустрии

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

Чем Team Lead в этом случае отличается от Engineering Manager?
Распоряжением бюджета (планирование/расход).

Чем Team Lead отличается от Scrum Master (правда ведь весьма похоже по ожиданиям?). У SM фокус на скраме, поддержанием его культуры, ценностей и тп. Но, если коротко, далеко не везде у нас есть скрам, уволить сотрудника скрам-мастер не может (хотя тимлид тоже не всегда 😉) и за работу команды в итоге отвечает Team Lead.

Вообще вопрос не нов. И у меня тоже есть немного букв про эту таинственную роль с полезными ссылками по теме внутри.
#процессы #management

Один из самых неожиданных вопросов, который пришлось услышать на проходивших у меня в прошлом году собесах: "как вы будете мотивировать людей, которые не хотят работать? Они приходят только деньги получать".
Но самое грустное, что это не тренировочный кейс, это то, с чем пришлось бы столкнуться (по словам собеседующих), “потому что, давайте будем честными, хотя вы и можете обеспечить вовлеченность сотрудников, вы не можете замотивировать их. Это происходит изнутри.” (Do Managers Really Have Power Over Employee Motivation?)
А в целом, не демотивируйте, чтобы потом не мотивировать - это самое простое обычно. Это то, с чего стоит начать. Частично, то что может демотировать, мы уже обсуждали.

#байки #management

Сегодня же пятница. Хватит серьезного контента на неделю.
Обещал вчера ролик про то, как это "просто" - научиться писать автотесты.
PS простите, тут все взрослые, а детям закройте глаза на последнем кадре.
#it_memes #тестирование

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

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