Мир глазами другого человека

Поболтали с Андреем Смирновым за мой путь в айти и в целом за жизнь. Получилось легко и достаточно откровенно в некоторых местах.

Нельзя прочитать этикетку изнутри банки (#менеджмент) Метафора "нельзя прочитать этикетку изнутри банки" прекрасно иллюстрирует одну из задач руководителя: увидеть общую картину/ситуацию/расклад сил и т.д. за желанием забуриться в детали. Решение сложных задач требует выхода за рамки собственной точки зрения. Без взгляда "снаружи" есть риск оказаться в ситуации, когда твоя точка зрения покрывает лишь часть возможных вариантов решений или развития событий, что паровозиком тащит за собой риск принятия ошибочного или неоптимального решения. Наверняка видели, как работают художники - рисуют кусочек картины и отходят на несколько шагов, чтобы увидеть, как последние штрихи повлияли на картину в целом. Вот это оно. Причем они это делают даже в случае небольших полотен - меняется освещение, угол зрения, фокус и т.д. Для руководителя сделать это не так просто в силу понятных причин. Система управления - это вообще не картина, а целая галерея. Да еще и с необходимостью принимать решения в условиях дефицита информации и неопределенности. С этим надо жить и работать. Большим подспорьем будет расширение управленческого и не только кругозора, системность в подходах и критическое мышление. На ближайшем TeamLead Conf теме принятия решений в условиях неопределенности будет посвящено прилично докладов. В качестве иллюстрации. Ставлю пиво, что в первые дни после назначения или на старте новой задачи у большинства из нас возникает дикое желание действовать. Нам же уже рассказали про тонны проблем, которые требуют сиюминутного решения. Рукава засучены, кофе налит, погнали. И пофигу, что система до нас уже как-то работала, и вообще не так, как нам рассказали за полчаса. Но у нас есть успешный прошлый опыт, который гарантированно нанесет непоправимую пользу всем и резко улучшит расклады. Если же потратить немного времени на исследование и анализ, подняться над суетой для оценки и поиска истинных причин поведения системы в данный момент, провести пяток интервью с ключевыми сотрудника

Куда пропал? В последнее время энергия писателя уходит в подготовку новых лекций и нескольких выступлений на TeamLead Conf (программа), поэтому пишу мало. Ограничения мозга в части созидания имеют очень четкие границы. При этом читать получается, чем я и занимаюсь вместо писанины. Что запомнилось. Вернулся к технической литературе, почти осилил (и даже программировал немного с ИИ в напарниках) "Apache Kafka" от Орейли, потому что кругом внезапно случилась кафка головного мозга. В целом откуда растут ноги - понятно - удобный инструмент, хорошая надежность, хорошая масштабируемость, позволяет замещать огромную кучу косяков в разработке других узлов. Но в моем случае - это вариант нездорового применения инструмента. Не можешь сделать надежную и доступную систему - воткни кафку, не можешь добиться хорошей производительности на многопоточных запросах - воткни кафку, и т.д. При этом решение принимается мгновенно и без попыток исправить что-то и обойтись без лишнего узла. Книжка норм, кто кафку гоняет - обязательно почитайте, ключевые идеи и возможности описаны хорошо, хотя по традиции воды тоже хватает. Свои инструменты надо знать очень хорошо. "Фундаментальный подход к программной архитектуре" от того же Орейли. Интерес вызвала примерно по той же самой причине - я давно в ойти и систем видел немало, но вдруг что-то пропустил. Более того, стали делать много новых конструкций с ранее не применявшимися бизнес-процессами. Архитектор во мне давненько не брал шашки в руки, поэтому решил себе напомнить про паттерны, свойства, подходы и пр, чтобы не развивать ту самую кафку головного мозга. Особый интерес в этом труде вызвала Часть третья, которая посвящена совсем не типичной информацией для архитекторов - софтскилам. Неплохо описана значимость умения создавать презентации и демонстрировать свои решения команде. А дальше "Эффективная команда" - глава про личные качества, про влияние на команду, про различные варианты контроля, "Навыки лидерства и ведение переговоров" - гла

Про подготовку к выступлениям Буквально через месяц встретимся в Питере на Saint TeamLead Conf 2025. Команда и спикеры усердно готовятся, кстати, я в этот раз и команда и спикер, но неполноценный:) Скорее ведущий в расширенными полномочиями. Опыт выступающих совершенно разный, тематика выступления и состав аудитории тоже. А вот ошибки одинаковые. Дальше будет несколько ключевых на мой взгляд советов из моего опыта спикера и организатора конференций по подготовке к выступлениям и их проведению. 1️⃣ Очень важно понимать цель своего выступления: что слушатель услышит, какую пользу вы ему нанесете, будет ли это решение конкретной проблемы или приглашение к дискуссии, что он сможет забрать с собой после вашего доклада? Ответы на эти вопросы помогут правильно расставить акценты. Крайне странно звучат рассказы, в которых упор делается куда-то сильно в сторону. 2️⃣ Неплохо бы знать свою аудиторию. Первый путь: спросить у организаторов - они обычно знаю, кто будет в зале с точностью до прошлогодней статистики. Второй: задать вопрос перед основной частью выступления. Знание аудитории позволит раскрывать наименее очевидные вещи в процессе рассказа и использовать более понятный язык, или делать больший акцент на чем-то. С первым вариантом понятно, а вот со вторым могут быть нюансы. Когда спрашиваете слушателей, а некоторые спикеры задают несколько вопросов, вполне закономерно, что публика ждет, что что-то получит за свою активность, например, что-то в вашей истории изменится в зависимости от ответов. Если это произойдет, то круто бы это обыграть "среди нас много инженеров, так давайте блаблабла" или "коллеги, технические писатели, а нас сегодня много в зале, часто ли вы сталкивались блаблабла". Это точно добавит очков. А вот если окажется, что в зале нет и десятой части специалистов по физике твердого тела (ФТТ), а вы яростно сыпете терминами и формулами со словами "очевидно из рисунка", готовьтесь к ворчанию в отзывах. 3️⃣ В тему ФТТ - изобилие сленга в выступлении даже

Про подготовку и выступление Продолжение поста про подготовку к выступлениям. 1️⃣ Обязательно репетируйте. И желательно не в одиночестве. Я выступаю с 2008ого на широкую аудиторию, но никогда не отказываюсь от прогонов с организаторами. Многие используют коллег, семейство, подойдет любая публика, которая будет а) строга и лояльна одновременно, б) открыто скажет, что нравится или не нравится, в) сможет поддержать дискуссию о содержании и подаче. Онтико многие годы при организации конференций приглашает профессиональных тренеров спикеров: Алексея (@obrovets), Романа (@p0b0rchy). А на Тимлидконф я уже несколько лет приглашаю Марину, она профессиональная телеведущая и тренер по речи. Это огромное подспорье для подготовки, особенно малоопытным спикерам. Даже если у организаторов нет такой штуки - рекомендую поискать кого-то, если опыта мало или реально сложное выступление. Это справедливо не только для конференций. Важные выступления на работе или по жизни тоже стоит репетировать. А еще мы устраиваем "очные прогоны", приезжаем всем программным комитетом за день до конфы и вместе с стройкой смотрим и слушаем доклады. 2️⃣ Не пейте кофе перед выступлением!!! а) оно очень быстро просится назад, б) оно пожирает воду. В итоге дискомфорт и сухой рот со всеми вытекающими. Загасить кофе водой на сцене не выйдет, устанете пить, а к выходу попросится еще больше жидкости. 3️⃣ Подготовьте голос. Я обычно не использую всякие хитрые техники кривляний и дыханий, а просто ловлю кого-то и болтаю минут 15-20, чтобы прогреть связки и запустить легкие. Кроме того, это субъективно добавляет уверенности, потому что как минимум один человек вас только что внимательно слушал. Техник прогрева в интернете полно, попробуйте, они почти все безопасны. 4️⃣ Даже когда вас представил ведущий - не поленитесь еще раз рассказать, кто вы и что будет происходить дальше. Это а) привлекает внимание аудитории (ведущего они уже видели раз пять), б) запускает ваш контакт с ней, в) позволяет "вкатиться"

Размышления о самовосприятии и влиянии оного на изменение себя (#философское) Злой текст на подумать. Навеяло чтением надменных постов в одной из запрещенных соцсетей про успешный успех и не только. Все мы на рабочих местах так или иначе заблуждаемся в следующем: 1️⃣ Часто, и иногда неприлично заблуждаемся в масштабах нашего вклада в общее дело. Я не отрицаю, что иногда есть место геройскому подвигу, но в среднем мы работаем в команде и напрягаются так или иначе все. 2️⃣ Регулярно в разных пропорциях приписываем себе заслуги других. Достаточно взглянуть в резюме и перед нами человек-оркестр с пачкой достижений, достойных как минимум медали. Кстати, эти самые медали и премии часто играют злую шутку с самомнением. 3️⃣ Преувеличиваем наши профессиональные умения и положение среди коллег. Ну правда, если бы мы все были такими экспертами и профессионалами, неужели бы мы были там, где сейчас? 4️⃣ Легко закрываем глаза на дорогостоящие ошибки и созданные нами тупиковые ситуации, приводящими к самым разным негативным последствиям. И, что характерно, всегда есть кто-то, кто виноват в этом, но точно не мы. 5️⃣ Преувеличиваем нашу роль в создании успеха, игнорируя связанные с этим явные и скрытые затраты (успех - мое, а затраты - не моя проблема). 6️⃣ Иногда просто галлюцинируем и видим что-то, чего на самом деле нет. Секс в том, что все эти искажения - прямой результат успеха. Прошлые успехи двигают нас вперед, придают эмоциональных сил, но награждают искажением «Если в прошлом все было так круто, то в будущем все будет еще круче!». Есть однозначный плюс - такое состояние наполняет нас решимостью, позволяет без страха двигаться вперед на встречу неизведанному, забивать на угрозы риски и потенциальные проблемы. Если бы мы воспринимали реальность ровно так, как она есть на самом деле, то наверняка сидели бы под одеялом. Поговаривают, что реалисты почти всегда владельцы депресняка. В целом ничего страшного, ну разве что команда и другие участники процесса нав

Про хороших слушателей конференций Традиционно принято рассуждать о том, как быть/стать крутым спикером. Но на конференции кроме спикеров есть и слушатели. Что такое "быть хорошим слушателем"? Я много выступал перед разными аудиториями (разок меня слушало двое). И много слушал. Слушать доклады - это труд, местами более тяжелый. Именно слушать, а не тусануть в зале, когда на сцене кто-то что-то рассказывает и в какой-то степени развлекает вас. По сути каждый раз при выборе - слушать тот или иной спич или нет - нужно делать выбор - я иду слушать или "ну пойду послушаю". От ответа на этот вопрос зависит очень многое. Немного советов о том, как быть хорошим слушателем: 1️⃣ Вы не обязаны уделять спикеру своё время, но постарайтесь проявить уважение. В конце концов спикер готовился, тратил силы, и продолжает их тратить на сцене. Даже очень опытные спикеры эмоционально и физически очень вкладываются в выступление. Если вам неинтересно выступление, или оно не соответствует вашим ожиданиям, или если у вас есть другие дела или неотложные вопросы, покиньте зал. Аккуратно встаньте, тихонько подойдите к двери, осторожно откройте её и уходите. Выбирайте место в зале исходя из выбора. Особенно, если вы "ну пойду послушаю". Нет ничего зазорного, если вы уйдете с первого ряда, просто чуть больше людей обратит на это внимание, ну и спикер вас запомнит:) 2️⃣ Раз уж вы решили остаться, будьте внимательны. Отключите телефон, желательно и жужжалку тоже. Некоторые аппараты жужжат так, что слышно:) Кнопки ноутбука тоже щелкают:) Ферму можно строить в метро. Обидно видеть со сцены макушки, а не глаза:) Современниками полчаса без телефона тяжело, но обычно оно того стоит. 3️⃣ Когда вы слышите что-то, с чем согласны или поняли суть - стоит кивнуть или улыбнуться, особенно, если вы сидите на первых рядах. Эта обратная связь даёт спикеру сигнал, что он достучался до вас, вы его слушаете. Спикеры очень часто опираются именно на реакцию публики в своих рассказах. Огромное облегчени

Хороший человек просит помочь, не проходите мимо: Привет, меня зовут Григорий (про себя написал ниже, мой контакт - @GNKogan). У меня запрос на пообщаться с умными людьми. (Кто не дочитал до конца — тот ... не ЦА 🙂 ). Я сейчас занимаюсь трансформацией ИТ-направления в частном образовательном холдинге - несколько колледжей и вузов в 4 городах с оффлайн- и дистанционным обучением. Но цель у меня более амбициозная — вместо поиска линии водораздела между индустрией и образованием создать систему нового типа, в которой производство и обучение будут неразрывно переплетены, как косичка. В общем, не пытаться сдружить ежа с ужом, не встраивать одно внутрь другого (как каждая первая IT-компания сейчас делает), а сделать producation-систему, в которой обе функции будут равноважными. Внутри процесс выстроен так, что одновременно решаются обе задачи — баланс достигается за счёт подхода на основе управления знаниями. Наружу же смотрит двуглавый (или даже большеглавый) орёл — каждой целевой аудитории предлагает свои услуги. Кому и зачем это нужно? Да, я из замкадья, поэтому речь идёт о решении проблем не десятка вузов первого эшелона и не двадцатки компаний бигтеха. То есть более 80% IT-отрасли и почти 100% бизнес-заказчиков (кто же не жаловался на сроки/качество/овербюджет IT-проектов и на подрядчиков? — корни проблемы в том же). Хотя, думаю, бигтеху тоже будет интересно. В общем, такая задумка — мы наш, мы новый мир построим. Но ведь любая революция лучше, если она начинается с хорошего касдева. Кое-какие гипотезы на базе своей компании я уже проверил, теперь зашёл в образовательную систему. И хочу поговорить уже исходя из роли внутри образовалки. Я не буду просить: а) дать преподавателей, б) взять студентов на практику, в) заплатить за базовую кафедру. 🙂 Если вы готовы поговорить — напишите мне, пожаааалста. Особенно если вы: - принимали на работу и воспитывали ИТ-джунов, - преподавали на ИТ-специальностях или [будущим] ИТ-специалистам, - прошли через несколько разных ф

Немного про подведение итогов (#философское) Традиционно мы куда-то ломимся. Ставим недостижимые и несбыточные амбициозные цели, планируем стратегии (потом их перепланируем), мотивируем сотрудников (пофигу, что не работает), запускаем новые проекты (и не гасим ненужные старые). Мы смотрим вперёд - и это правильно. Но есть всем известная практика, которая на самом деле является сумасшедшим по силе инструментом - подведение итогов. Но это не просто сухой отчёт о проделанной работе. Это осознанный процесс рефлексии, анализа и извлечения уроков. Это момент, когда команда останавливается, оглядывается назад и задаёт себе ключевой вопрос: чо это с нами такое было? Именно в глубине кроется огромная сила. Именно в этот момент можно осознать, что ломились не туда, делали не то, достигли вообще не тех целей, и теперь все надо по-другому. И чем раньше поймешь - тем дешевле исправлять. Мы же (не все) традиционно механизируем это все и превращаем в формальность, укладывая очередную граблю на пути. Подведение итогов - это не выгрузить тикеты и порадовать себя и окружающих прогрессом (классика джира-менеджмента). Люди склонны двигаться от одной задачи к другой, не задерживаясь на результатах. Нам так проще. Быстрый эндорфин. Итогом снижение числа тикетов становится самоцелью. Мы гордимся выполнением, но редко анализируем, как мы это сделали, что получили, что нам это стоило. Обычно так: конец итерации, что-то зафиксировали, причем далеко не всегда даже по классике (что у нас получилось, что не получилось, что будем делать иначе и пр), "неделя прошла, чет поделали, не все получилось, мы молодцы, вот отчет". И погнали дальше. Итогом имеем бесконечную карусель тикетов в джире и прыжки по граблям. К тому же часто итоги подводит руководитель, остальные раз за разом прокручивают мысль "ну да, ну не прям так конечно". Команде нужен диалог. В безопасной среде. Когда каждый член команды может высказаться. Если люди боятся говорить о проблемах, потому что боятся последствий, итог

По синтез итогов (#философское) «Сделали 15 тикетов. Не доделали 3. Были задержки. В целом все ок». Это не итог. И не все ок. В прошлый раз я писал о том, как мы, ломясь вперёд, забываем о силе подведения итогов. Я предложил смотреть на процесс подведения итогов, как на диалог равных в безопасных условиях, с понятными зафиксированными тезисами. Возникает вопрос: как уйти от стандартного подхода, когда просто перечисляют «что сделали», в сторону полезных записей? Синтез информации - объединяем существующие данные с целью получения новой, более полной версии. Как это ? 1️⃣ Активное слушание - не просто говорим о проблемах и успехах по очереди. Мнение по задаче - дополнительный кусочек контекста. Технарь легко увидит проблему в процессе, которую менеджер даже не подозревал или заведомо игнорировал. Важно не просто слышать, а включаться и задавать вопросы, уточнять, вытягивать скрытое. Это исследовательский диалог. 2️⃣ Подтверждающее резюме - как ты это понял. Классика жанра: "Погоди, давай я повторю, что услышал, а ты подтвердишь, что я тебя правильно понял". Это не формальность, важно, чтобы все еще раз смогли услышать информацию в другой оболочке и еще раз осмыслисть, все ли поняли одинаково, всё ли обсудили. Киллер-фича такого диалога, которая убивает пассивное согласие и возвращает людей на второй круг осмысления. Иначе все покивают и поймут каждый по-своему. 3️⃣ Непосредственно синтез. Это не просто про сложить всё услышанное вместе. Это про построение смыслов. 1. Что на входе: факты (что делали); эмоции (там где не получилось или было слишком тяжело/легко);гипотезы (почему так вышло, как мы до этого докатились); перечень успехов и провалов. 2. Что внутри и на выходе: последовательности (что повлекло за собой что? что упустили/пропустили); контекст (что знали до сегодня, что узнали сейчас, куда применим и как); историческая справка (что делали раньше иначе, что круто взлетало и приносило успехи, а теперь неожиданно успехов не принесло, хотя схе

Сила не только в людях. Сила - в связях. (#пролюдей) По итогам приличного количества услышанных историй про трансформацию команд, сложности и последствия, вот вам моя точка зрения, почему стабильные IT-команды работают лучше, и почему им иногда не нужно мешать. В айтишечке, где технологии меняются быстрее, чем листья календаря, забывается одна простая истина: самое ценное в продукте — не код или эксплуатация систем, а команда, которая его пишет и поддерживает. Имеем парадокс: команды из сильных инженеров, архитекторов и продактов не могут выйти на стабильный ритм и давать прогресс, в то же время другие команды без «звезд» стабильно выпускают качественные фичи, быстро реагируют на инциденты и даже радуются новым вызовам. В чём разница? Не в технологическом стеке и не в уровне скиллов (хотя и в них конечно же тоже). Разница в качестве взаимодействия внутри команды. И это далеко не всегда про качественный менеджмент. Тезис 1: Психологическая безопасность — основа высокой эффективности. Создать ее по распоряжению нельзя. Google проектом Aristotle показал: ключевой фактор успеха IT-команд - психологическая безопасность. То есть среда, в которой разработчик может сказать: «Я не понял архитектуру», SRE - признать, что инцидент вызван его правкой, или продакт предложить откат фичи без риска быть низложенным. Такая культура не создаётся за один ретро-дейли-груминг. Она выстраивается месяцами через доверие, открытость и тысячи незаметных сигналов: кто-то кому-то помог, где-то поддержал, где-то признал свою неправоту. Такие штуки формируют в некотором смысле социальный капитал команды, и его нельзя измерить или посчитать, но это ахрененно важный актив. Тезис 2: Команды в IT не собираются. Они созревают. И делают это не со скоростью сахарной браги. Г-н Койл в своем «Кульурном коде» выдал, что эффективные команды - это не временные проектные группы, а устойчивые социальные системы. В IT это особенно заметно: лучшие результаты показывают долгоживущие и стабильные

Кризисы и InBetween 1.0 (#филофофское) Я занимаюсь конференциями в разных ролях примерно с 2012ого. А выступил первый раз на широкую публику аж в 2008ом. Этот рынок - очень непростой, и очень чутко реагирующий на состояние окружающей среды. В разные времена были и взлеты и падения. Появлялись звездочки и загибались гиганты. Сейчас уже мало кто вспомнит РИТ (Российские интернет-технологии) или Whale Rider от Онтико, мощь и академичность CEE SECR (в 2008ом меня не взяли в программу:)), почили в Бозе куча вендорских тусовок (сейчас, кстати, их ренессанс, PT, Я, Т, Авито, Озон, Мтс и пр стараются), ушли интересные площадки вроде Software People, серия Labs-конф от Люксофта, 404-фест в том виде, в котором он был. При этом есть ветераны, которые стабильно собирают площадки: Highload++, Codefest, JPoint, AgileDays, Стачка, отдельно отмечу г-на Орликова и его SQA Days (я сбился со счета, сколько Влад и его команда сделала за прошедшие лет 15). TeamLead Conf родился сравнительно недавно, осенью 2018ого. Но уже надвигается неумолимо 20ый выпуск, пусть и через пару лет. Я помню первое «дырявое» расписание, пара потоков чисто на знакомых и энтузиастах. Сейчас это крупнейшая софт-скил (не вендорская) тусовка из мне известных. Это мы придумали тимлидов:) Тысячи единомышленников и ценителей чужого опыта этой осенью забьют в Сколково 10!! залов с разнообразным контентом. Спустя 7 лет - минимум х5 посетителей и точно х5 потоков:) Кажется, что это достойный результат для «стартапа».  Но на его пути тоже были ямы и канавы. Например, осенью 2022 в Питере мы потеряли почти треть спикеров. Но справились, и вышло очень недурно.  Историй по жизни хватает, в далеком 1998 в небезызвестный кризис юный я стоял на платформе Домодедово и выбирал между билетом на электричку и пачкой сигарет (понятно, кто победил:), но уже тогда было понятно, что кризис - это про выбор и принятие сложных решений. В 2008ом многие заказчики моего на тот момент работодателя решили прекратить сотрудничество.

Талант vs Упорство (#пролюдей) Мы часто с восхищением наблюдаем за людьми, достигшими вершин в спорте, искусстве или бизнесе, и воспринимаем их как настоящих супер-героев. Их мастерство кажется нам чем-то магическим - будто оно возникло из ниоткуда, без усилий и долгих часов работы. Мы наслаждаемся бомбическим результатом, но редко задумываемся о процессе, который к нему привёл. Почему нам удобнее верить, что великие люди просто «родились такими», а не пришли к успеху через упорный труд? Возможно, потому что признание их усилий заставило бы нас задуматься о собственных возможностях и, возможно, о собственной лени, неуверенности и пр. Что по сути своей такое себе ощущение:) Если гений — это дар свыше, то с ним не нужно соревноваться. Но если успех - результат ежедневной работы, то и мы могли бы достичь многого (пусть и не таких высот, но тем не менее)… если бы захотели. Сегодня эта иллюзия развивается в виде тренда, который можно назвать «успешный успех». В соцсетях, на курсах и в мотивационных роликах нам обещают: «За 30 дней стань миллионером», «Освой профессию мечты за неделю», «Достигай целей без стресса и жертв». Всё это создаёт впечатление, что большие результаты можно получить почти без усилий - достаточно просто купить правильный продукт, подписаться на нужного наставника или «включить режим успеха». Но за этим фасадом скрывается опасное заблуждение. Такой подход не только искажает реальность, но и подрывает веру в собственные силы. Когда человек следует этим рецептам и не видит мгновенного результата, он начинает думать, что с ним что-то не так - будто он «не избранный», «не талантливый», «не создан для успеха». На самом деле проблема не в нём, а в ложной посылке: настоящие достижения почти никогда не приходят быстро и легко. Даже для тех, кто обладает талантом, они требуют времени, терпения, повторных попыток и, главное, готовности работать даже тогда, когда никто не хлопает в ладоши. А иногда кидает помидоры. Я и сам такой. Нет-нет, да залезает

Про задние мысли (#пролюдей) Подведению итогов года посвящается. Каждый год в декабре принято подводить определенные итоги прошедшего года. До итогов я еще не добрался, как и до конца года, зато очередная книжка напомнила мне про одно чудесное когниивное искажение. Ставлю пиво, что вы когда-нибудь слышали от коллеги: "Ну, это было очевидно!" или "Я же говорил, что так и будет!" Наверняка вы столкнулись с эффектом знания "задним числом" (или "hindsight bias"). Это когнитивное искажение, которое заставляет нас воспринимать события прошлого как более предсказуемые, чем они были на самом деле. Причем до события никто даже не догадывался, что так будет. Например, вы выпускаете обновление, и оно ломает к такой-то матери прод внезапным образом. Вдруг кто-то из команды заявляет: "Ну, это было предсказуемо! Я знал, что так и случится". Хотя до релиза этот человек активно поддерживал идею и не высказывал никаких сомнений. Вроде бы безобидная штука из серии "я же говорил", но в реальности она может серьезно вредить. Или другой пример: вы запускаете новый проект, и он проваливается. Вдруг все вокруг начинают говорить: "Ну, это было очевидно, что идея не взлетит". Хотя до этого все радостно кивали и говорили, что это гениальная задумка. Знакомо? Вот это оно. Известны три явных формы тяжести этого искажения: 1️⃣ "Я знал, что так и будет" Самая легкая форма. Например, вы внедряете новую систему мониторинга, и она оказывается неудобной для команды. После этого кто-то из разработчиков заявляет: "Я сразу понял, что это не сработает". Хотя до этого он активно участвовал в обсуждениях и даже предлагал свои идеи по настройке системы. 2️⃣ "Это было неизбежно" Здесь эффект становится сильнее. Мы начинаем воспринимать событие как нечто, что просто должно было случиться. Например, вы запускаете новую фичу, и она вызывает нагрузку на серверы. Коллеги начинают говорить: "Ну конечно, это было неизбежно, ведь мы не доделали нагрузочное тестирование". Хотя до этого никто не поднимал

Про страх публичных выступлений (#пролюдей) Страх перед выступлением - это нормально. Даже у бывалых. Многие думают, что хороший спикер - это тот, кто не волнуется. На самом деле, хороший спикер не боится своего волнения. Он им пользуется. Волнуются все. Страх перед трибуной или камерой вообще не признак слабости. Это реакция на ситуацию, где ты выходишь из зоны комфорта и делаешь что-то важное. Если бы тебе было всё равно - ты бы не волновался. А раз волнуешься, значит, тема тебе небезразлична. Это жирный плюс. Я выступаю уже без малого 20 лет, и каждый раз чувствую волнение, даже перед узким кругом слушателей. Чуть выше я рассказывал, что читаю небольшие лекции для сотрудников своего подразделения. Каждый раз это волнует и заставляет прикладывать усилия. Проблема возникает, когда мы начинаем контролировать себя до паралича: - «А вдруг запнулся?» - «А если спросят то, чего я не знаю?» - «Выгляжу ли я достаточно уверенно?» - «Мама не положила платок» В этот момент внимание уходит от аудитории и темы и сосредотачивается на себе. И вместо того чтобы говорить с людьми, мы начинаем играть какую-то хренороль и теряем естественность. Что реально помогает (и как это работает на практике) 1️⃣ Не стоит бороться со страхом, надо с ним работать. Волнение - это энергия. Она не исчезнет, но её можно направить. Перед выступлением я нахожу собеседника и просто болтаю с ним ан любые темы. Это убирает часть волнения. А за 2 минуты до начала выступления я втыкаю приложеньку от часов и дышу по таймеру минуту. Это не «медитация», а просто перезагрузка нервной системы. Сердцебиение снижается, руки перестают потеть. Главное - не пить много кофе:) А разговор прогревает связки и напоминает организму, что у него есть руки, которыми можно махать:) 2️⃣ Стоит говорить не «про», а «для». Если ты сам понимаешь, зачем это рассказываешь, то аудитория это почувствует. Иначе - шляпа. На одном из митапов я слушал про реорганизацию процессов эксплуатации. Вместо того чтобы начинать с

Некоторые вещи просто требуют времени #философское #поворчать Если кто-то 50 лет назад посадил дуб на вашем участке, вы получаете то, что нельзя было купить готовым, ускорить или "оптимизировать". Если вы хотите получить все и сразу с чистого листа в чистом поле - вам это не удастся. Только ждать. И помогать расти. Потому что некоторые вещи просто требуют времени. Сейчас мы живём в эпоху "мгновенного" результата. И это проникает в то, как мы пилим софт и развиваем компании. Да, генерация кода ускоряется, но настоящий фундамент успешного продукта - это не скорость, а упорство на грани упрямства, способность годами держать фокус, выстраивать отношения, проходить через кризисы. Это - не спринты, это - годы, а иногда десятилетия. Современники одержимы скоростью (и я местами). Быстрые итерации, деплой за деплоем, "fail fast". Для многого - это ок. Можно бежать, оставлять качество «на потом» и учиться по ходу. Но есть зоны, где скорость вредит. Где существует трение и не случайно. Комплаенс, например, или безопасность, или надежность. А еще сильнее трутся люди и процессы. Адептам скорости нередко кажется, что всё, что создаёт трение, надо убрать. Заменить людей на ИИ, процессы скриптами. Но ведь именно трение, именно то, что «просто требует времени», часто и есть суть. Не зря же существуют «периоды охлаждения» для важных решений. Есть понимание: человеку нужно время подумать. ИИ сносно и быстро пишет код. На дистанции правда пока не проверяли. Время не прошло. Интереснее то, что хуманы несут эту логику дальше: хотят деплоить ещё быстрее, запускать больше экспериментов, и возникает новый запрос - убрать всё, что тормозит пайплайн: ревью, дизайн, инфраструктуру. Если машины такие крутые - зачем чек-листы и согласования? Натыкал промт - получил результат. И психологически становится легче и проще. Проще - дешевле. А где дешевле, там проще бросить. Потому что даже с лучшими намерениями сложно делать качественно, когда софт стремительно становится товаром массового прои

Про смену еще одной парадигмы (#менеджмент) Вопрос в зал: у кого есть должностные инструкции? - лес рук. Не буду спрашивать, что в них, все-равно их видели ровно один раз при приеме на работу, ну может два, если что-то поменялось. При этом чем занят человек на самом деле? Хорошо если чем-то похожим, что было в описании вакансии:) Но часто (в ИТ по крайней мере) и вакансия слабо отражает суть того, что будет, а уж должностная инструкция подавно. Особенно, если расстарались и добавили нужный уровень абстракции, чтобы потом не пришлось отмазываться на вопрос "ну вы же другое предлагали". А давайте еще добавим к этому всему штатное расписание. Которое, о, чудо, снова не отвечает на вопрос - а кто вообще чем сейчас занят и что делает:) Все эти штуки в современном мире становятся опасными. Статичные, написанные добрым канцеляритом, идеальные носители иллюзии контроля и порядка. Конторы натурально не знают, кто у них есть и чем заняты, но делают вид, что знают. При этом по данным прошлогоднего Всемирного экономического форума, к 2030 году почти 40% используемых сегодня навыков устареют и изменятся, а срок годности многих технических скиллов — меньше двух с половиной лет. Это так то очень быстро. Скорости бешеные. А теперь вопрос, они же не в 2030 разом изменятся - сколько вы не обновляли жоб дескрипшен или матрицу компетенций? Почитайте страничку по ссылке - крайне интересно. Тем временем, всякие разные компании продвигают идею skill-based orgaization - т.е. организация, построенная на навыках. Не фиксируем должность, а фиксируем человека по состоянию здесь и сейчас. Не «эта роль должна уметь вот это», а «этот конкретный человек сейчас умеет вот это, вот на этом уровне, вот с таким опытом». Это собирают в карту скилов, которую постоянно обновляют и следят за актуальностью. Что-то типа матрицы компетенций с указанием скилов. И эта штука живет во времени и постоянно апдейтится. Научился - изменили, достиг новых высот - изменили. Поверх такой карты предлагается стро

Про смену еще одной парадигмы #2 (#менеджмент) Немного проясню, что я имел ввиду в прошлом посте и отвечу на вопросы читателей. Система, которую я не то, чтобы предлагаю, скорее пытаюсь осмыслить и прикинуть, можно ли ее как-то прислонить к реальности, не является в чистом виде замещающей для текущей конфигурации "Должностная инструкция"->"Описание вакансии"->"Матрица компетенций"->Человек. Идея в следующем. Пока только идея. По сути это надстройка над классическим убером задач типа Юду. Есть задачи или класс задач, которые можно решить, обладая некоторым набором компетенций. Как этот набор получить? Опытным путем и экспертной оценкой. Это непросто, потому что всегда возникает вопрос - если человек обладает контекстными знаниями на уровень ниже тех, которые нужны для решения задачи, но при этом демонстрирует высокие результаты в обучении - считать его подходящим? Мое мнение - да, хоть и немного зависит от контекста ситуации. И вот здесь на сцену выходят современные инструменты (ИИ, например), которые могут облегчить тиндеру выбирать подходящие критерии, анализировать результаты, калибровать требования и пр. Представим, что у нас есть система, которая гибко расширяется в полуавтоматическом режиме и наращивает карту "Задача-компетенции". ИИ легко справится с этим, если ему немного помочь. В обратную сторону - это тоже справедливо, строить звездные карты по анализу классов решенных задач конкретным сотрудником. Тоже выглядит решаемой задачей. Условно, если у тебя сисадмин был замечен 10 раз в тикете "выдать доступ" без возврата на доработку и с приемлемым сроком - можно с высокой долей вероятности рисовать ачивку - "умеет в доступы на 5 из 5". Начнет лажать - скорректировать на 4 из 5 и понизить "рейтинг" в тиндере. Со стороны "маркеткплейса задач", глядя на все эти показатели, робот строит матрицу "что надо | кто может". Задачи "что надо" поступают от человеков. При этом опять же может проводиться калибровка с точки зрения срочности, детализации описания

Про менеджеров-носорогов #пролюдей У нас есть мероприятие для вновь присоединившихся - что-то типа групповой онординг-сессии. Приходят коллеги и рассказывают про контору, про ее историю, отвечают на вопросы. Крайне полезное мероприятие. На последней встрече был разогревочный слайд - кто ты сегодня? Ну и там котики, ежики, совы и прочая милота. А мне вспомнился носорог. Редкое, мощное животное, НО, почти ничего не видит дальше пары десятков метров, но прёт по саванне так, будто видит всё на свете. Ставлю пиво, что хоть раз на вашем пути попадались такие руководители. Да что уж там, я сам был таким. 1️⃣ Плохое зрение и хороший слух У носорога очень хреновое зрение . Дальше пары десятков метров видят нормально только отдельные особи, у большинства все, что дальше, расплывается в кашу, зато нюх и слух что надо. Ничего не напоминает? Что там будет впереди или за пределами команды - пофигу, зато все "знает", все "слышал", везде чует подвох. Кстати, у носорога в жизни есть еще одни косяк - он почти не видит, что творится у него под ногами, особенно, когда куда-то ломится. 2️⃣ Большой и неповоротливый Вторая фишка - масса и инерция. Носорог физически не умеет резко тормозить или делать резкие повороты на бегу. При этом топит на секундочку до 50км/ч по пересеченке. Если ломится - то будет бежать до упора, курс уже не поменять. У менеджеров это выражается так - решение принято - поезд ушёл. И не потому, что что решение было семь раз обдумано, а просто потому что развернуться на ходу ему не позволяют установки. Остановиться и сказать «пацаны, чет мы лажанули, давайте подумаем, куда дальше" недостижимо. Команда ещё на середине, а иногда и в начале работ, видит, что путь явно выбран был не тот, на горизонте уже видны проблемы, аккуратно сигналит об этом, а иногда орет, а поезд мчит вперёд на всех парах. 3️⃣ Не его проблемы Самое смешное и самое грустное свойство одновременно. Носорог сносит всё, что попадается по пути - кусты, молодые деревья, каких-то незадачли

В этом году исполнилось 25 лет, как я ковыряюсь в ИТ, из них лет 15 я занимаю позиции уровня +- СТО. Когда я был юным техдиром, хватание за все подряд и вписывание себя во все задачи не казалось какой-то проблемой, энергии хватало на все. Потом я подрос, и с некоторым удивлением обнаружил, что вписывание себя в задачи стало более осознанным, но "за все подряд" осталось, просто слегка видоизменилось. Периодически на просторах интернетов появляются дискуссии - должен ли тимлид программировать или технический директор разбираться в бизнесе, результатом всегда плотный срач без победителей. Де-факто, короткого и однозначного ответа на то, кто такой СТО нет. Более того, спросите пять разных CEO и получите пять разных ответов. Для одного это техлид, который «разберётся с серверами и вот этим непонятным софтом для бухгалтерии за кучу денег». Для другого - правая рука, способная закрыть все технические вопросы для него и всей лавки. Для третьего - «тот парень из ИТ», который должен сделать быстро, дёшево и вчера, но делает долго, дорого и вообще не вчера:). Стандарта просто нет. Итогом СТО - это конкретная не роль. Это конструктор, который бизнес собирает под себя, особо не задумываясь о нюансах. Техлид и всякоразноопс. Менеджер проекта. Менеджер продукта. Нанимающий менеджер. Ментор. HR. Спикер и лицо компании на конференциях. А еще иногда шкаф может подвинуть или дверь починить в раздевалке. Куча профессий в одном человеке, и ни от одной по-хорошему не откажешься. Уберёшь найм - получишь так себе команду. Забьёшь на менторство - потеряешь ключевых людей через полгода. Выкинешь продуктовое мышление, и вот ты уже пилишь какие-то очень нужные никому фичи. В итоге под воздействием бизнеса получается оч часто не СТО, а тимлид тимлидов, который лично лезет во всё, потому что «ну а кто, если не я». И лезут паровозиком проблемы. Вкладываться особо не хотят, хотят фичи и выполненные планы, и меняться тоже не очень хочется. Почему-то нет места ни техническому долгу, ни архи