В канале "Тимлид очевидность" нашёл ссылку на интересную запись разговора: сам автор канала со своим коллегой беседуют с организационным психологом на тему групп и команд https://t.iss.one/general_it_talks/758

У Дмитрия Болдырева https://t.iss.one/dmiboldyrev достаточно радикальный взгляд. То, что обычно принято называть командой в IT, в его понимании полноценной командой не является. Основной признак команды - это то, что она сама внутри себя делит "добычу". К командам в таком понимании можно называть бригаду строителей, артель старателей на добыче золота или взвод спецназа на задании. А то, что обычно называется "IT-командой", является рабочей группой: мы можем работать вместе, но цели у каждого по сути персональные. Да, не секрет, что одна из самых больших коммерческих тайн, которую берегут практически во всех компаниях, является ведомость зарплат сотрудников: коллеги не должны догадываться, кому сколько достаётся.

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

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

Вообще, современные корпоративные практики, скорее, не дают развиваться настоящим командам: матричная структура, перетасовывание людей между проектами, задействование параллельно в нескольких проектах и так далее. Здесь для бизнеса есть свои плюсы: рабочая сила более ликвидна, КПД её применения выше. Также люди на фоне устойчивых связей не устроят вредный профсоюз и прочие забастовки. Не уйдут все разом, оставив пустым отдел. Но с другой стороны, команды эффективнее, люди в них работаю дольше, работа более качественная. Когда нужно решать сложные вопросы либо перформить за себя и за Сашку, команда может справиться с этим. Группа скорее всего нет.

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

ЦЕЛИ НА ГОД

Когда же говорить о годовых целях, как не 1 января! Сразу: я не буду вдаваться в конкретику по поводу личных целей, а порассуждаю о методе.

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

Получилось конкретных 11 пунктов. Сначала 1-2 слова - название цели, потом немного подробнее, как это должно в итоге выглядеть и, где это уместно, 1-2-3 шага, как я к этому приду. Не стал делать талмуд с подробным описанием каждого чиха, но и не ограничился запиской "хочу, чтобы было хорошо". К записям возвращался в течение года несколько раз, но не часто. Так или иначе, желания были в моей памяти, тем более что я осознанно их сформулировал в начале года.

Что имеем спустя год. Прямо сказать, в некоторых аспектах вышла настоящая магия. Заключается она в том, что те вещи, которые были написаны ручкой, случились буквально. Причём иногда не в том контексте, который подразумевался при написании. Условно, я сначала видел, что будет A, потом B и как результат C. А получилось A, потом D и F, а потом вдруг неожиданно C. Делаю вывод, что подсознание так или иначе приведёт тебя к тому, куда ты хотел прийти, найдёт пути. Главное захотеть что-то конкретное.

Ещё вывод. Почти всё сбылось полностью. Ну точнее как сбылось, я это захотел и в итоге исполнил. А даже то, что не было достигнуто полностью, было попробовано и исполнено хотя бы наполовину. При этом я не горел весь год желанием во что бы то ни стало обязательно выполнить все пункты, относился к этому достаточно ровно. В итоге среди 366 дней этого високосного года нашлось достаточно времени для каждой из 11 целей.

Хочу ли я повторить опыт в этом году? - Безусловно хочу! Считаю его мега-успешным. Мне понравилась очень простая мысль, которую я как-то нашёл в статье на Хабре. Мол, мы, работники IT, используем в бизнесе столько средств для планирования, успешного выполнения заданий. Так почему бы эти инструменты не попробовать для нашей собственной жизни! Да, почему? - Попробовал, убедился, что работает!

Как говорили древние, medice, cura te ipsum! А главный инструмент по преобразованию окружающего мира - это я сам!

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

Прослушал выпуск подкаста Кода-Кода про инцидент-менеджмент https://t.iss.one/kodakodacast/373 . Гостем был Андрей Чупейкин, CTO блока платформы в Ozon. Есть много интересных вещей, которые можно было бы приложить к работе в компании, где я сейчас тружусь. Но одно сильно бросилось в глаза, об этом хотел чуть порассуждать.

Андрей говорит там, что лично участвует в разборе всех инцидентов. Приводит несколько примеров, когда ночью на личный телефон звонит робот, CTO встаёт и бежит читать логи вместе с разработчиками. Уже в другом интервью с Андреем, которое я посмотрел после, он говорит примерно то же самое: и он, и его ключевые руководители сами буквально смотрят логи, когда что-то случается.

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

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

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

Хотя Андрей очень здраво говорит о необходимости элементарной координации. Я сам с этим сталкивался не раз и не два в своей работе: вот есть 2-3-4 взрослых человека, хороших профессионала, которые точно могли бы без меня разобраться и быстро починить прод. Но нужен именно какой-то дядя, который скажет элементарные вещи: Васенька, делай хорошо, а нехорошо не делай. И - о чудо! - буквально за 15 минут всё починили. Надо легонько подтолкнуть, но без этого легонько всё лежит очень долго. Я уже даже не переживаю по этому поводу - иногда странной безынициативности коллег - а просто принимаю как должное.

А отсюда второе. Точно ли надо СТО крупной технологической компании влезать в каждый лог? Я вот недавно давал ссылку на Сертакова, который пишет про хронический перегруз топ-менеджеров, и кажется, это прям классический случай. Фасилитация, грамотное эскалирование, поиск ресурсов - думаю, со всем этим справился бы зам. Или зам зама. Или дежурный менеджер, отвечающий за прод.

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

А вы даёте своим сотрудниками право ошибиться? Я даю, не часто, но заставляю себя убирать руки от штурвала. Конечно, понимая пределы.

Нашёл отличный канал с подкастами - "Бреслав и Ложечкин". Два спикера очень интересно и глубоко раскрывают темы, о которых рассуждают. И не в последнюю очередь потому, что есть реальный опыт работы в крупных компаниях: один из них создавал язык Kotlin, руководил командами в JetBrains, второй долго работал в Microsoft и Amazon, а теперь CIO в банке.

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

Понравилось наблюдение авторов насчёт социальной защищённости сотрудников. С одной стороны, для всех нас, работников по найму, социальная защищённость - гарантии от внезапного увольнения, выплаты при сокращении и т.п. - это однозначное благо. За улучшение условий труда и найма боролись наши предки, которым когда-то приходилось работать 6 дней в неделю по 12 часов и безо всяких гарантий.

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

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

Ложечкин рассказывает реальный случай, когда в немецком подразделении Microsoft увольняли сотрудника то ли год, то ли два. Наконец добились увольнения, а он пошёл в суд и вернулся на работу, где продолжал бездельничать (со слов его руководителя). Теперь мне стало более понятно, зачем крупные корпорации выстраивают такое длинное сито отбора, и весь процесс затягивается на месяца. В другом выпуске подкаста, кстати, рассказывают, что в Amazon найм - это всего лишь 15% (!) проверка hard- и soft-скиллов, а 85% - проверка жизненных установок и соответствия культуре компании.

Подкасты Бреслава и Ложечкина однозначно рекомендую, каждый выпуск очень богат на оригинальные мысли. Кроме того, работа больших компаний начинает выглядеть более логичной, когда о ней говорят не только программисты, которых задалбывают 5-7-этапными интервью на входе, но и менеджеры, которые долго проработали в системе.

https://t.iss.one/breslavandlozhechkin/13

Прочитал сегодня "Чёрную книгу менеджера". Кто-то из авторов каналов, на которые я подписан, рекомендовал её как "книгу, перевернувшую жизнь".

Мягко говоря, не впечатлён. Вообще не люблю хамского стиля и топорных истин. Наверное, лет до 25 такое заходило, потом перестало.

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

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

Так что мораль книженции можно сократить буквально до пары слов: работайте правильно, а неправильно не работайте. Ну или, в качестве рекомендации руководителям руководителей, звучит так: нанимайте вменяемых адекватных менеджеров, а глупых и неадекватных не нанимайте. Если у человека нет базовых понятий об окружающем мире, не работайте с ним.

https://stratoplan-school.com/Storage/books/pdf/stratoplan_black_book.pdf

Сегодня у меня первый день участия в Марафоне от Стратоплана. Бесплатное мероприятие, 10 дней, из которых 5 дней - потреблять статьи, 5 дней - семинары в Zoom. И вот на какой мысли себя поймал.

Чтобы систематизировать прочитанное и услышанное, сделал файлик, куда записываю краткие выводы из пройденного за день. Такой конспект, глядя на который, потом легко вспомнить, о чём была речь. Так то информации очень много, если не проработал её (особенно если не написал заметку в свой авторский Телеграм-канал), то забудется очень быстро. Ведь ещё на работе 100500 дел каждый день, и вокруг вон что происходит!

И понимаю, что я делаю именно то, что сейчас люди активно передают помощникам вроде ChatGPT. Мол, составь мне конспект, перескажи краткое содержание того-то, сделай выжимку. ИИ мгновенно это делает и достаточно красиво упаковывает.

Проблема только в том, что получает от этого человек? Вот если я сам лично ещё раз не окину взглядом статью, не посижу 10 минут не подумаю, что является самым ценным для меня, а поручу это всё ChatGPT, что останется в моей голове? Есть лёгкое подозрение, что меньше, чем после самостоятельной интеллектуальной работы. Как там в советском мультике про двоих из ларца, "Вы и есть за меня будете? - Ага!"

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

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

Занялись поиском разработчика в свою команду. Сделали резюме, воронку подбора, с HR отработали взаимодействие. Пошёл поток кандидатов. Назначаем интервью.

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

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

Очень дорогая оценка, надо сказать.

Интересные тесты для поступления на юридический, три примера https://t.iss.one/avvablog/2584

Но я хотел бы сфокусироваться не на самих примерах, а на мета-примере: самом посте и комментариях под ним. К IT это применимо совершенно точно.

У нас в отрасли по объективным причинам скапливаются люди двух типов: 1) С IQ заметно выше среднего 2) С некоторыми проблемами в коммуникации, то, что принято называть интровертным типом личности. Люди первого типа легче и быстрее справляются о огромным количеством абстрактной информации при разработке ПО, их высокий IQ - их конкурентное преимущество. Люди второго типа, как правило, более усидчивы, а как нам говорит известная максима, хороший программист - это тот, у кого железная задница. Мало обладать хорошим умом, надо ещё и уметь долго ковырять задачи. Часто носителями и первого, и второго типа являются одни и те же люди.

Ну так вот. Проблемы могут возникать в коммуникации между ними и всеми остальными. Умный человек может написать тезис, подобный одному из приведённых выше примеров, и для него будет "всё очевидно". В то время как другие люди не поймут сложную причинно-следственную связь между элементами сообщения, либо будут долго её распутывать. С другой стороны, интровертность, то есть сфокусированность на себе и своих ощущениях, мешает более умным людям почувствовать, с какими проблемами могут столкнуться остальные. Интроверту может показаться, что если ему всё очевидно, то и другим тоже всё очевидно: "А что, бывает по-другому?"

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

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

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

Уходя - уходи правильно

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

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

Думаю, это проигрышный подход. Учёные говорят, наша память работает так, что мы по сути перепроживаем то, что пытаемся вспомнить. Поэтому иногда так разнятся показания живых свидетелей: люди не врут, они на ходу додумывают. Это просто физиология.

Так и с рабочим коллективом. Конечно, есть фактическая основа, по которой у коллег складывается вывод: кто-то классный, кто-то много пашет, кто-то лодырь, кто-то умный и т.д. Однако, в силах самого индивида проговорить свой опыт так, чтобы люди вспомнили лучшее, и не вспомнили худшее, либо эти воспоминания получили новый ракурс. И это последний шанс уходящего сотрудника повлиять на коллективные воспоминания о нём, дальше он не властен над умами людей, которых покидает.

Тут, наверное, возникает следующий вопрос: а зачем делать так, чтобы меня помнили с хорошей стороны? Но ответ на него скорее зависит от возраста: молодые, юные личности склонны впадать в нигилизм: "А мне пофиг!". Чем более зрел человек, тем больше он убеждается, что социальность для людей на первом месте.

Если не хватает уверенности в собственной фантазии насчёт сценария прощания, лучше положиться на кондовые примеры культуры: написать или проговорить 2-3 обязательных в таких случаях предложения, поблагодарить хотя бы "хором" всех, кому адресовано прощание. Ещё лучше - высказать своё отношение по поводу самого ухода из компании: мол, тут хорошо, но хочу расти дальше по карьере/материальной составляющей. Или пытался, но не справился. Это прекратит кривотолки и слухи.

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

Поколение Z, оно же "жертвы ЕГЭ"

Про поколения хочу немного добавить к написанному в другом канале.

В работе сталкиваюсь с тем, что молодое поколение (до 25-27) немного другое, чем мы (мне 42). У нас общепринято воспроизводить риторику дедовщины: мол, молодые не умеют работать, не знают цену деньгам, "инфантилы", "эгоисты" и так далее. Но я в целом другого мнения о молодёжи.

Например, провожу встречи 1:1. Обычная управленческая практика, когда говорим с подчинённым о его личных вопросах, а не о задачах в рамках должности. Так вот, практически все молодые сотрудники отличаются высокой степенью саморефлексии: они могут поддерживать разговор, говоря о своих целях, своих чувствах, диссонансах, которые испытывают на работе. Короче, умеют абстрагироваться от себя как от рабочей единицы и заявлять о проблемах личности, которая воспроизводит эту рабочую единицу. Это очень интересно, каждый раз поддерживать такой разговор, но и очень волнительно, т.к. я в этот момент должен быть и хорошим психологом.

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

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

https://t.iss.one/call_botya/1663

Сегодня побывал на чудесном мероприятии: Пётр Жарков @Peterzh1 решил сделать оффлайн-встречу для читателей и комментаторов своего Телеграм-канала "Морковка спереди, морковка сзади" https://t.iss.one/morkovka_speredi_morkovka_szadi. Тематика канала управленческая, соответственно, и на встречу собрались люди, которым эта тема интересна.

Пётр со своей помощницей Юлей провели 3 игры: одна вступительная, 2 на управленческие навыки.

Однозначно много пользы и достаточно много открытий для меня лично. Дело в том, что вообще мы, работники IT, в игры не играем. Те активности, которые приняты в отрасли - это в-основном большие конференции (человек выступает, потом 2-3 вопроса из зала) или хакатоны (все кодят на время, иногда защищают идеи). В плане развития и рефлексии на тему управленческих навыков обычно что-то делается внутри компаний, и не всегда делается хорошо. Покопался в своей памяти: подобные интересные и продуктивные игры у меня были в первой крупной компании, в которой я работал, и было это уже 19 лет назад.

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

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

Ещё через игру, через наблюдение за другими убедился, как важно в некоторые момент быть гибким. В нашей культуре часто "гибкий" ставят рядом со "слабый", но это совершенно не так! Гибкий не теряет цели, но оперативно меняет подходы, чтобы достичь того, чего он действительно хочет. А вот твёрдый, упрямый зацикливается на одном методе, в итоге теряя фокус.

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

Пока всё, может быть, что-то ещё напишу позже. Петру огромное спасибо за идею, смелость и организацию! Прекрасный субботний день в интересной компании!

Общеизвестно, что...

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

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

В этом разборе https://habr.com/ru/companies/nexign/articles/301802/ речь ведётся о восприимчивости других людей к получению знаний: мол, прочитанное запоминается хуже, чем прослушанное, а то в свою очередь хуже, чем сделанное. Оказывается, надёжного источника "исследования" на эту тему нет. Другими словами, это чистая спекуляция, чья-то выдумка.

Но что на самом деле? - Как говорят психологи (в частности, школа НЛП), у разных людей разные ведущие системы восприятия: визуальная, аудиальная, кинестетическая, дигитальная. Некоторым людям надо показать что-либо для лучшего усвоения, другими рассказать, с третьими закрепить в навыке, буквально водя вместе курсором, четвёртым лучше построить абстрактную схему и дать понятные символы. Говорят, думают и даже выглядят люди с разными типами ведущей системы по-разному. Кстати, в ИТ в основном визуалы и дигиталы.

Много и других таких "законов", которые, возможно, когда-то были высказаны в шутку либо в каком-то контексте, а потом разрослись до размера Галактики. По моим смутным ощущениям, сюда можно записать другое излюбленное - "правило Парето", говорящее про то, что якобы 20% усилий дают 80% результата. Сам Парето был экономистом, и изучал распределение доходов семей в Италии: 20% семей получали 80% дохода. Если уж опираться на подобные наблюдения, то сейчас, в эпоху сильного расслоения, в некоторых странах 5% усилий давало бы 95% результата. Не вздумайте только с этой мыслью подходить к своему руководителю при планировании спринта!

Здравое зерно, конечно, есть: некоторые вещи, такие, как конструирование архитектуры, взаимоотношений систем, действительно в-основном определяют успешное будущее всей вашей работы. Однако, ИТ - одна из тех отраслей, где результат в итоге добывается "железной задницей", усидчивостью и объёмом работы. Любой хороший программист знает это.

А какие у вас открытия в этой области? Есть ли вещи, которые "всем понятны", а для вас звучит сомнительно?

Мифический человеко-месяц

Наконец-таки прочитал знаменитый бестселлер Фредерика Брукса-младшего. Книга, которую вы встретите в огромном количестве рекомендаций для саморазвития в ИТ. Первое издание вышло аж в 1975 году, следующее в 1995.

Честно скажу, особых откровений в книге не нашёл. Возможно, это потому, что идеи давно разлиты в многочисленных материалах, статьях по нашей тематике, в самом дискурсе. Многое из того, что там написано, является теперь само собой разумеющимся. Взять ту же идею "человеко-месяца": понятно, что ликвидность труда в ИТ-проектах весьма относительна. Если вы на горящем проекте в завершающей его стадии добавляете ещё людей, то это будет означать скорее не ускорение работ, а их замедление.

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

Но что ещё лично мне приглянулось. Как же американцы любят обобщать опыт! Вообще, США - страна феноменально развитой экономической статистики. Вот и в "Мифическом человеко-месяце" мы видим, как уже в 70-е делали заключения по поводу той или иной организации труда по созданию ИТ-продукта. Казалось бы, какая отрасль в те годы, всё только начиналось! К большому сожалению, у нас и в 3-ем десятилетии XXI века редко где увидишь подобную информацию. Много говорим про конкретные технологии, в последнее время стали наконец говорить про человека в отрасли и его проблемы, но по-прежнему мало об организации, стандартизации, доказанных способах увеличения эффективности. Хотя ИТ давно уже не кружок для гиков, а огромная отрасль с миллиардными оборотами.

Чем вообще занимается тимлид?

Вчера мой руководитель спросил меня между делом: мол, а ты сколько времени на написание кода тратишь? Я подумал, ответил: "Процентов 15, плюс реквесты, плюс архитектурные дела по фронт-енду, но это не так много".

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

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

А вот чтобы костюмчик хорошо сидел, нужно сводить всё это вместе, особенно учитывая 4-е измерение - время. Тимлид выступает в команде и как режиссёр, и как продюсер. Я в детстве недоумевал: зачем в кино режиссёры, если сценарист и так написал, что делать? - Открывай, читай, играй по написанному, в чём сложность!?.. С годами понял, что в отношениях между людьми миллион сложностей, которые нельзя уладить раз и навсегда. Даже некоторым единицам нужен персональный ангел: например, часто за выдающимся артистом стоит очень трудоспособный продюсер, режиссёр и даже психотерапевт или команда из всех вышеперечисленных.

То есть тимлид решает много разнообразных задач, суть которых - сделать так, чтобы его подчинённые поменьше отвлекались от дела своей специализации. Это раз. А два - заранее продумывает, как должно быть устроено пространство этой совместной работы, чтобы подчинённые давали больше эффекта и меньше сил и времени тратили на неизбежные потери.

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

Я думаю, конечно нет. Всё очень просто: создать сплочённый самоуправляемый коллектив гораздо сложнее и дороже, чем просто выделить руководителя. Например, качественное, а не для галочки, горизонтальное взаимодействие начинается с очень тщательного подбора кадров. Так, экипажи самолётов и тем более комических кораблей подбирают с учётом психоэмоциональных особенностей каждого участника. Для этого нужно проводить глубокое тестирование, а также иметь широкую базу для отбора. Претендентов в космонавты вы наберёте легко, а претендентов на должность мидлла, чтобы перекладывать JSON'ы туда-сюда?

Лидерская схема управления, где один берёт на себя работу по сглаживанию углов и наведению порядка, гораздо менее сложна и затратна. Она естественна для выполнения огромного количества типовых работ, таких, как написание коммерческого кода, например. Она и складывается сама собой в самых различных ситуациях в жизни. Вы застряли с соседями в лифте - даже там кто-то возьмёт на себя работу успокаивать других и думать, как поскорее выбраться, пока остальные паникуют.

Так что тимлид - это такой маленький пехотинец в войне с хаосом, энтропией. А поскольку, как известно из II закона термодинамики, энтропия лишь возрастает, работы у такого пехотинца будет всегда с головой.

Написал в шутейном тоне статейку про "токсичные собеседования". Это тема давно уже оккупировала все полки на Хабре. Можно взглянуть на вопрос немного под другим углом
https://habr.com/ru/articles/886070/

Встречи 1:1

Немного поговорим о том, что такое встречи one-to-one, зачем их проводить и как это делать лучше.

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

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

Теперь перейдём к преимуществам. Что же дают one-to-one, и как их лучше использовать к удовольствию всех сторон?

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

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

Второе. Нужно вести разговор так, чтобы подчинённый говорил больше вас. В разных методичках даются разные цифры: например, в одной компании методологи пишут, что 80% времени говорит сотрудник. Я ориентируюсь на собственные ощущения: я должен чётко понимать, что говорю меньше своего собеседника. Это достаточно тяжело, особенно поначалу: у руководителей, как правило, более прокачанный разговорный навык, в то время как у программиста обычно более интровертный психотип. Но в этом и заключается одна из основных целей встречи: раскрыть вашего подчинённого.

Третье. Зачем, собственно, раскрывать. Встречи one-to-one должны стать очень ценным источником знаний для самого руководителя в первую очередь. Люди - главный его инструмент для выполнения своей функции. Логично, что чем лучше он знает своих людей, тем более виртуозно он может использовать его для выполнения задач подразделения. В качественном диалоге люди очень часто сообщают о себе гораздо больше, чем собираются сами: тут вырвалось необычное слово, тут вдруг стал прятать глаза, тут волнуется, а тут весь блестит от счастья. Иногда бывает и так, что вырулили на тему, о которой даже не думали вначале, но она сидела где-то в подсознании и требовала обсуждения.

Безусловно, далеко не каждая встреча для вас будет открытием, особенно если вы работаете с человеком давно. Однако будьте начеку: может подвернуться шанс, чтобы глубже понять человека. У меня были случаи, когда узнавал о людях что-то совсем новое. Не буду раскрывать подробности ввиду личного характера общения, но общий настрой человека становился более понятен, а планы на него иногда менялись. Классическое: это не он такой злой и неконтактный, это просто у него ребёнка в больницу положили. Ему не взбучка нужна, а отгул или отпуск.

(продолжение https://t.iss.one/playingjazz/31)

(начало https://t.iss.one/playingjazz/30)

Четвёртое. Кроме момента понимания сотрудников, one-to-one - отличный инструмент для качественного воздействия на них. Тут нужно быть аккуратным, деликатным: не делать глубокое бурение, чтобы заложить свои - естественно, очень ценные! - но всё же свои мысли. Нужно побыть немного коучем: больше задавать правильные вопросы. Очень часто бывает, что человек не совсем понимает свою силу, свой потенциал или даже не видит размера лужи, в которой начал тонуть. Когда установился доверительный диалог, вы можете потихоньку вести его, чтобы этот потенциал раскрыть. И ему лучше от этого, и у вас в команде человек стал работать качественнее!

Пятое. Но вообще, встречи 1:1 - это ещё и место для обязательной обратной связи от вас. Я железно придерживаюсь этого правила: даю краткую справку, как оцениваю труд моего сотрудника за период, пока мы не встречались, даже если он специально не спрашивал об этом. Среди ваших подчинённых вряд ли найдётся больше одного человека, которому действительно не важно, что руководитель думает о качестве его работы. Даже более вероятно, что вы вообще не встретите такого человека в своих рядах: почти всем важно, что думают о их работе, особенно что думает человек, от которого зависит зарплата, карьерный рост или увольнение. Не будьте "холодной матерью", обратную связь от которой нужно заслужить какими-то специальными танцами или другими фокусами! - Человека со спокойной психикой это будет раздражать, человека более тревожного просто сводить с ума.

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

Шестое. Встречи нужно готовить. У меня есть специальный файлик, куда я записываю основные моменты встреч, повестку, запросы моего визави и наши с ними договорённости. Я всегда понимаю, что по результатам прошлых договорённостей человек захочет спросить меня: как продвигается то или иное? чем закончилось? что порешали? Конечно, некоторые вопросы решаем и между встречами. Но summary всегда нужно иметь под рукой.

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

(окончание https://t.iss.one/playingjazz/32)

(предыдущая часть тут https://t.iss.one/playingjazz/31)

И седьмое. Собственно, как проводить встречи, какие паттерны использовать? - Мой ответ банальный: это относится к области искусства. Есть общая рамка: дать обратную связь, дать выговориться, спросить 3-4 обязательных пункта. Но даже порядок этих вопросов может варьироваться буквально в зависимости от текущего настроения коллеги. Тем более, нельзя заранее предугадать вопросы и ответы, которые будут идти дальше. Если у вас отличные отношения с подчинённым, можете попробовать сократический диалог (см. здесь, например: https://www.youtube.com/watch?v=QuwtUsYcYC0). Но делать это надо, понимая все возможные последствия, как положительные, так и отрицательные.

У меня был случай на одной из прошлых работ, ещё до ИТ-шных: я уже несколько месяцев работал в компании, был относительно успешен. Нас направили на внутреннее обучение в компании, которое вела хороший психолог. И она так удачно подбирала вопросы на одной из сессий тренинга, что вывела меня на осознание: я вообще не тем занимаюсь в своей жизни, это просто не моя работа! Очень скоро я ушёл оттуда, а ей до сих пор благодарен (но не знаю, благодарен ли был тогда директор департамента, где я работал)

Так что уважаемые коллеги-руководители, используйте этот прекрасный ритуал на все 100%! Вы вряд ли что-то испортите, регулярно делая беседы со своими подчинёнными. Зато можете приобрести много чего полезного, о чём эта небольшая статья.

ps. Кстати, бонус: поскольку вы прокачиваете умение вести диалог и слушать вашего собеседника, будет ещё одна дополнительная польза - ваши более уверенные навыки в проведении собеседований, в наборе команды.

Очередная статья про вред переключения контекста в труде программиста https://habr.com/ru/companies/netologyru/articles/890474/. Поскольку говорят и пишут об этом постоянно, выскажу своё особо ценное мнение.

Дело в том, что я вообще не считаю это большой проблемой. Нет, конечно лучше, когда программист спокойно трудится над одной задачей в удобном ему темпе. Но меня откровенно удивляют и даже немного шокируют заявления, которые есть в этой статье, например, навроде "Каждое короткое сообщение, которое вы отправляете коллеге в Slack, отнимает у него (разработчика) 23 минуты продуктивной работы." Это прямо противоречит всему тому, что я наблюдаю вокруг себя.

Я в IT уже 15 лет. До 2020 мы работали в офисах. Почти всегда это были openspace. Да, openspace - откровенно плохой способ организации рабочего пространства. Тем не менее, люди неплохо работали. Они точно работали хуже, чем если бы находились в идеальных условиях, но они работали на достаточно приличном уровне, имея не "одно сообщение в 23 минуты", а постоянные отвлекающие факторы.

Вообще, лучшие программисты, лиды, с которыми я имел дело, каждый день переключаются между многими задачами, иногда десятками. Это не мешает им быть лучшими. Скорее, даже есть обратная зависимость: лучших можно отвлекать 50 раз на день, и они всё равно остаются лучшими, в то время как новичок или просто человек, которого случайно занесло в IT, потом долго восстанавливает контекст.

Ну ладно, в массовой разработке, в индустрии нельзя ориентироваться на лучших, надо на средних. Но вот здесь и вмешивается то важное, о чём обычно не упоминают в подобных статьях про "идеальную работу программиста в вакууме" - это баланс. С одной стороны на чаше весов - суперидеальные условия, в которых программист выдаёт 100% своей продуктивности. На другой - объём подготовительной и организационной работы, которую нужно провести, чтобы программист всегда находился в идеальных условиях, когда всё всегда понятно, никаких коммуникаций в течение дня не требуется, прод не ложится, экспертное мнение не нужно и т.д. и т.п. За "неидеальность" программист платит примерно 20% своей эффективности, но кто сказал, что это больше, чем все вышеназванные затраты?

Возьмите любую деятельность человека, которая занимает большие ресурсы мозга. Например, оживлённая беседа, спор на профессиональные темы. Вот вы ведёте монолог, и вдруг ваш визави задаёт вам один вопрос вне контекста, что-то о погоде. Вы что, правда выпадете на 23 минуты из беседы, пытаясь в голове восстановить цепочку аргументов? - Нет же, вы сделаете это за считанные секунды. Ладно, с поправкой на объём кода в IDE, может быть 2-3 минуты. Но не больше. Я сейчас руковожу командой, у меня как у лида огромное количество отвлекающих факторов в течение дня, однако я ещё пишу код, и кажется, не сильно отстают от себя самого, когда я был просто сеньор-разработчиком, ни по скорости выполнения задач, ни по качеству.

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