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

Честно, не знаю, кто сейчас читает и будет ли читать подобные книги-справочники. Но хорошая, подтянутая под современные реалии, замена Савину с его 20-летним доткомом.
Для освежения мыслей перед собесами (всем больше собесов!) - отлично. Тем более, знаю, что часто всю теорию активно продолжают спрашивать.

«Качество решает ВСЁ: Полное руководство по тестированию ПО»

Автору за упорство - респект 👏

#quality

The Manager’s Path in the Age of AI
Очень хорошая статья от Camille Fournier (автора "The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change", рекомендую книгу начинающим менеджерам)

Начало вообще "вдохновляющее" 🙂

“There is no need for a permanent middle management layer.” — Jack Dorsey
“I don’t think people managers will have any value in the future.” — Brian Cheskey
“No pure managers: Every leader at Coinbase must also be a strong and active individual contributor.” — Brian Armstrong

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

We should be spending some of our productivity gains on things that seem like slowing down: meetings, design reviews, conversations. These ways of maintaining alignment, sharing knowledge, and creating human connections are, in my opinion, more important than ever to creating good outcomes at scale.

—
Снова менеджеров убирают. Спиралька пошла на новый виток, как в гугле в свое время:

Проект Oxygen (Google) или как Гугль от менеджеров пытался отказаться

Ага, знаем, плавали. Команды без лидов... До сих пор удивляю интервьюеров на собесах, кто-то даже слово "бирюза" вспоминает. Теперь вот мидл-менеджмент убрать и все прям точно полетит, ага.

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

#management

Вчера в комментах в линкеде, кроме приятностей (всем поучаствовавшим - огромное спасибо), был и интересный вопрос:

Поделитесь, как вы относитесь к моментам, когда руководитель отдела/подразделения погружается на более низкий уровень и применяет свою экспертизу разработчика для решения конкретных технических задач? Был ли у вас такой опыт?

Конечно такое было.
Такое было со мной, когда я только стал руководителем. Такое наблюдал и у других руководителей.

В этом месте стоит зафиксировать один момент: "погружение"="понимание происходящего" - это ок, "погружение" = "я вместо разработчика пишу код" - тут "256 оттенков серого".

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

"для многих именно возможность “писать код” и является самым важным, а может и единственным критерием “ты можешь быть техническим менеджером”" похожее рассуждение было тут

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

Я тоже прошел этот путь и перестал влезать в код только, когда у меня появилось 8 команд с разным стеком разработки отличающимся от моего прошлого опыта. Единственные кто продолжал от меня "страдать" - это тестировщики 😃

В более общем смысле, чем выше поднимаешься, тем меньше "участия в коде" должно быть. "Должно ли это совсем пропасть?" - холиварная тема 😃, вон в недавней беседе CTO Озон рассказывал про "папа еще может".

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

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

"Будь готов к тому, что теперь твоя работа - это делать работу мозгами и руками других людей без наблюдения ощутимого результата своего труда в моменте здесь и сейчас" - совет №1 новоиспеченному менеджеру

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

#management

Это лучше из того, что я посмотрел по разработке с ИИ, а точнее про подход и организацию процесса, за последнее время.
Паша, ты красавчик. Я оценил и проникся. Особенно на моментах с ревью проработки задачи и про стоимость задач. Готов часть (но только часть 😂) своих бубубу за недавним пивом забрать обратно.

Запускай бест-практис у себя в канале, хотя бы по одному примеру, совету в неделю.

PS Кириллу Улитину спасибо за организацию FWR Club.

#развитие

А как все более активное внедрении ИИ в разработку меняет, если конечно меняет, подход "не мешайте кодеру кодить"?

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

Насколько теперь человек нежелающий вникать в суть проблемы и ждущий ТЗ на входе сейчас полезен? Меняется что-то?

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

"Let coders code" fallacy

#it_философия

Выпуск - машина времени... Прям ностальгия.
25 лет за без малого 2 часа. Прикольно.
• Почему полетел Agile?
• Почему Scrum победил XP и (частично) Канбан?
• И куда это все исчезло (исчезло?) сейчас? 🙂
• Ну и да, куда же без ИИ-шки и то, как она может (но не факт, ибо люди все те же) что-то поменять?

 #процессы #байки #классика

Вспомнил, что я когда-то тоже делал список эффекто-законо-принципов, но больше в сторону психологии.
Оказалось ему уже почти 10 лет 😲
Задача не стояла в объяснении каждого термина, а просто в том, чтобы все было собрано в одном месте. Ниже самые интересные 🙃

Если вы знаете, еще какие-нибудь интересные штуки, пишете в комментариях.

Эффект Даннинга — Крюгера
Определение в вики слишком затянутое. Я его понимаю так: глупые не понимают, что они глупые, потому что они глупые. Но при этом уверены, что они круты. А умные "знают, что ничего не знают" и думают, что все остальные о них того же мнения.

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

Закон Паркинсона (на самом деле их три, но чаще вспоминают первый и мы именно его недавно вспоминали. А между тем 3й вариант такой прикольный 😜)
1. "Работа заполняет время, отпущенное на неё"
2. "Расходы растут с доходами"
3. "Рост приводит к усложнённости, а усложнённость — это конец пути"

Эффект Рингельмана (или эффект социальной лени)
"Индивидуальный вклад участника группы уменьшается по мере того, как размер группы растет"

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

Теория разбитых окон
В качестве примера, "если в здании разбито одно стекло, и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна".
В IT эта теория хорошо ложится на понятие технического долга.

Теория мотивации Герцберга
Двухфакторная теория мотивации, которая опирается на то, что удовлетворённость от работы зависит от её внутренних и содержательных характеристик, а неудовлетворённость зависит от внешних характеристик работы и её контекста. Эти характеристики делятся на две группы: гигиенические факторы, недостаток в которых приводит к неудовлетворенности, и мотивирующие факторы приводящие к удовлетворению работой.
Обстановка на работе и условия труда + мотивирующие факторы = состояние удовлетворённости
Обстановка на работе и условия труда – мотивирующие факторы = нулевой эффект
ЗЫ кстати, зарплата не входит в число мотивирующих факторов. Классическая гигиена.

Модель Такмана (командная динамика)
Стадии развития команды: Формирование, Шторм, Нормализация, Работа, иногда добавлют Закрытие. Любые изменения в количественном составе (приход-уход), скорее всего переведет команду на начальную или просто более раннюю стадию.

#it_философия