Подкаст «Кода кода»

Радио «Виктор»: Общая картина и детали Давно мечтал начать красить миниатюры. И вот, наконец, добрался попробовать. Открытием для меня стал ключевой принцип: гиперболизированно выделяй некоторые детали, потому что с «высоты» их только так и будет видно. Похожим образом гримируются актёры для большой сцены. Помните персонажа Пьеро из «Золотого ключика» — у него было белое лицо и одна большая слезинка. Вблизи это смотрелось смешно и нелепо, но на сцене, благодаря этому, его персонаж был понятен зрителю. При этом желание выделить все детали обречено на провал. Видели когда-нибудь китайские сайты 2010-х, где в каждом пикселе экрана мигает какой-то баннер? Всего настолько много, что ты не можешь сфокусироваться на чём-то одном. В детстве я так наряжал ёлку — пытался поместить на ней все-все игрушки, гирлянды, мишуру. Вблизи можно было рассмотреть каждую, и это было даже любопытно: от прабабушкиной Снегурочки до вчера подаренного шарика с переливающимися гранями. Но уже с расстояния в метр всё превращалось в кашу. Когда выделено всё — не выделено ничего. А что в работе? Ровно так же и в рабочих переговорах. Если вы обсуждаете крупный проект в широком составе, то плохо говорить о нём общими словами. Но так же плохо пытаться проговорить все детали. Правильный подход: выбрать заранее несколько важных ключевых деталей и их подсветить, оконтурить, выделить. А другие места обозначить и скрыть за общим фасадом. Таким образом, вы, с одной стороны, обозначите глубину проекта, подсветите какой-то ключевой риск или момент, который требует координации с рядом команд. С другой — не перегрузите собеседника подробностями. Выбор конкретных деталей сильно зависит от ситуации. Тем же принципом я руководствуюсь, когда хочу объяснить вклад человека в процессе перформанс-ревью. Некоторые мои коллеги пытаются рассказать максимум деталей: и о проектах, и об архитектуре, и о проблемах, которые были в реализации, и даже обосновать по дороге, зачем мы этим занимались. Это всегда выходит плохо — никто со стороны не готов воспринять такой объём информации по каждому коллеге. С другой стороны, слишком общие слова: «Вася — супер молодец» — тоже не дают достаточно, чтобы можно было принимать коллегиальные решения. А вот подход подчёркивания нескольких отдельных деталей позволяет обсудить и широту сделанного, и глубину.

Радио «Виктор»: Никаких неожиданностей Наверняка вы замечали, что новая полюбившаяся песня с каждым новым прослушиванием нравится нам всё больше и больше. Наш мозг обожает предсказывать и попадать в реальность. На этом принципе построена вся музыкальная гармония: как правило, нам подсовывают именно то, чего мы и так ждём. Но не в точности, иначе никакого предсказания бы не было. Это как теле-викторина — ее интересно смотреть, если ты можешь ответить на часть вопросов, но не на все. Идти по знакомой дороге быстрее и легче. Приятно читать книгу или смотреть фильм, построенный по знакомым канонам, но поданный по-новому. Если вам интересно разобраться в этих канонах, рекомендую книгу «Тысячеликий герой» Кэмпбелла и учебник гармонии Дубовского. Аналогичные принципы можно найти и в живописи, и, например, в кулинарии. Пробуя новое блюдо, вы опираетесь на весь свой предыдущий опыт и хотите, чтобы в нём было что-то знакомое. Но при этом и что-то новое тоже. UX и DX В UX работает точно так же. Мы знаем множество примеров, когда широкая аудитория не смогла принять слишком революционный продукт. Но зато легко влилась в него, когда была готова. Например, Яндексу пришлось даже откатить новый дизайн Кинопоиска под напором пользователей, хотя дизайн был крут и, в итоге, выкатился по частям. Отсюда, кстати, и ощущение в массовом сознании, что «раньше было лучше», ведь «разработчики всё время всё портят». Интереснее обстоит дело с DX (Developer Experience). С одной стороны, разработчики любят что-то новенькое. Ведь именно драйв от того, что ты в чём-то разобрался, — это то качество, которое многих привело в профессию. С другой стороны, многие новые вещи приходят не в дополнение к старому, а как его замена. И тут подключается боль от того, что старым, удобным, привычным и таким знакомым пользоваться больше нельзя. Или ещё хуже — нужно вложить кучу работы в обновление. И вся эта работа не принесёт нового драйва от запуска. При этом отсутствие изменений — тоже не знак качества. Даже лучшая компьютерная игра всех времен и народов «Герои меча и магии III» живет во многом благодаря команде энтузиастов, которые кое-что дорабатывают. Менеджмент Я очень стараюсь, чтобы на любой рабочей встрече была минимальная доля неожиданностей. Не стоит «держать что-то у себя», чтобы рассказать только в нужный момент. Встреча, на которой никто, кроме тебя, не знает, что произойдёт, точно окажется непродуктивной. Ещё хуже — пытаться сделать «приятный сюрприз для заказчика» или «придержать нашу главную фишку на потом». Это почти никогда не работает. Лучше с самого начала договариваться максимально подробно, а потом обсуждать необходимые изменения и дополнения так часто, как это возможно. Я представляю это как принцип часов: скорость стрелки всегда направлена по касательной, но движется она по дуге, потому что на неё действует ускорение. Оно действует постоянно и понемногу. Так, что стрелка, уверен, этого даже не замечает. Когда я был начинающим тимлидом, я нанял в команду разработчика, которым не был доволен с самого начала. У меня было к нему много претензий, но я всё думал про себя: «Вот-вот он войдёт в процесс, вот-вот станет попадать в сроки, вот-вот научится понимать, что я от него хочу». Стоит ли говорить, что когда я, наконец, выложил ему всё своё негодование, он был просто в шоке. Тогда вопрос: «А почему, Витя, ты мне раньше не говорил?» — поставил меня в тупик. Теперь я понимаю: нужно было давать обратную связь так часто, как я бы мог это сделать. И тогда, как и стрелки часов, мы вполне могли бы указывать вместе на нужную цифру в нужное время.

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

Давайте станем ближе? Поделитесь, какую позицию вы занимаете и какой у вас уровень IT-шности. От вас — участие в опросе, от нас — полезный и захватывающий контент 🤝

Заглянем в бар? Вы помните, как мы, ваши бесценные ведущие Витя Корейша и Женя Антонов, пригласили Настю Абрашитову в бар? 🍸 Из экспериментального выпуска на ваших глазах вырос отдельный самостоятельный подкаст, в котором мы делимся управленческим опытом. Рассказываем истории, иногда спорим о том, как правильно поступить, иногда соглашаемся, но всегда учимся друг у друга и получаем удовольствие. В выпусках обсуждаем проблемы и вопросы, с которыми можно столкнуться на разных управленческих позициях в IT в разные периоды своей карьеры. Пока мы готовим новый сезон в «Кода кода», предлагаем послушать самый мёд из подкаста «Три тимлида заходят в бар». 1️⃣ Неприятные разговоры с сотрудниками — как проводить, чтобы не навредить? Про кондиционерные войны, гигиену, зависимости, громкие звуки, ссоры Ивана Ивановича и Ивана Никифоровича, противогаз, Чебурашку и многое другое. 2️⃣ Бесконечные встречи в календаре. Как не сойти с ума и успеть пообедать? База выживания в диких условиях — подготовка к встречам, модерация, фокус внимания, 2-3 встречи в один слот и то, как кукушечку держать при себе. 3️⃣ Тайм-менеджмент — как успевать срочное и не терять важное О борьбе с прокрастинацией, лайфхаках успеть всё (и не успеть тоже), навыке вести заметки во время встречи, дедлайнах своих и чужих. 4️⃣ Перфоманс ревью — объективная оценка или способ выжимания соков и формализм ради формализма? Субъективные оценки vs Объективные показатели, Польза vs Вред, Манипуляции vs Помощь своей команде. 5️⃣ Как тимлиду поменять работу и не сойти с ума Экзистенциальные вопросы — нужен ли ты кому-то, нужно ли делать карьерный шаг назад, что будет и как быть, если … Это не наш субъективный выбор, а аналитика и фидбэк слушателей. Наслаждайтесь и следите за новыми выпусками в телеграм-канале подкаста 👀

Радио «Виктор»: Собеседование — не допрос Договорённости о работе всегда предшествуют переговоры, и часть этих переговоров называется собеседованием. Наверняка вы видели мок-собеседования на YouTube, скорее всего, участвовали в найме со стороны собеседующей стороны и, конечно, проходили собеседования сами. И, вероятно, наблюдали или даже участвовали в таких собеседованиях, где одна сторона задаёт вопрос, получает на него ответ и... просто переходит к следующему вопросу. А потом мы читаем тысячи жалоб на то, что «спрашивали алгоритмы, а кому они нужны» или «меня полтора часа мучали кейсами, и я не знаю, хорошо ли я справился». При этом ничто не мешает собеседующему объяснить, почему он задаёт именно этот вопрос. Как ответ на него повлияет на работу в команде? Как кандидат относится к такому формату работы? Часто это может дать гораздо больше информации. А ведь в этом и цель — узнать максимум. К тому же, вы попутно выполните и вторую цель диалога — на конкретных примерах покажете, чем вы тут вообще занимаетесь. Техническое собеседование Часто, особенно в крупных компаниях, выделяют отдельную техническую секцию. Иногда даже не одну, а, например, делят на «секцию по алгоритмам» и «секцию дизайна систем». А ещё, чтобы каждый раз не изобретать велосипед, обычно существует фиксированный список или база вопросов. В помощь собеседующему там уже написан эталонный ответ или критерии, которым он должен соответствовать. Но это совершенно не значит, что эти вопросы существуют в вакууме и никак не относятся к конкретной позиции. Допустим, вы решаете спросить: «В чём отличие горутины от потока?» Обсудив ответ и углубившись в детали, вернитесь к вашей позиции. Почему для вас это важно? - Может быть, у вас был баг, который приводил к резкому росту числа горутин, и вы упирались в планировщик. - Может, у вас CPU-интенсивные приложения, и вам важно следить за утилизацией ядер. - Может, вы переносите бизнес-логику с Java на Go и стремитесь сохранить параллелизм. - Может, сочетание лимитов в кубере и установленных GOMAXPROCS ваших приложений уже приводило к троттлингу и падению бизнес-метрик, и вам важно, чтобы каждый член команды хорошо понимал, как и что стоит настраивать. А если вы сами не понимаете, зачем задаёте этот вопрос, то, может, он и не нужен? Soft skills интервью или менеджерская секция Вы просите человека рассказать про свой провальный проект. Обсуждаете это с ним, делаете выводы. Но почему бы не объяснить, что именно вам тут было важно? И почему бы не поделиться в ответ своим провальным проектом? Если моя цель не только понять, насколько кандидат соответствует нужной позиции по навыкам, но и определить его майндсет, то я ещё больше стараюсь превратить такой разговор в диалог. Мне ведь важно не только как кандидат поступал в прошлом или поступил бы в теоретических условиях, но и то, как он отреагирует на мои решения. Ему же не в вакууме управлять командой, а в моём направлении. А значит, обсуждать сложные кейсы со мной, в том числе. И так во всём В первом сезоне подкаста «Кода кода» меня почти не слышно. Я не только не озвучивал своего мнения, но даже вырезал свои вопросы там, где контекст склеивался. Позже мы с Женей стали активно делиться и своим мнением. А в последних сезонах — дополнять гостей и даже спорить с ними. Я уверен, что такой подход гораздо лучше раскрывает и тему, и гостя. Потому что в реальной жизни мы очень редко попадаем в изолированный контекст. А значит, и пользы от такой изоляции немного. Если вы заметили эти изменения в подкасте и вам это нравится — ставьте молнию.

Пока в нашем подкасте перерыв, решил предложить вам послушать и посмотреть интервью, которое я брал у коллег. Это была разовая акция, в рамках нашей (Озоновской) конференции E-code. В организации и проведении которой я активно участвовал в начале осени. Говорили о том, как написанный код превращается во что-то реальное и осезаемое. Гостями были два CTO: 🧑 Леонид Налчаджи, технический директор по продукту и технологиям логистики; 🧑 Иван Лазарев, технический директор по продукту и технологиям товарных операций. В этой беседе: 🔉 обсудили, зачем инженеры Ozon Tech ездят работать на склады и в курьерскую службу; 🔉 вспомнили ошибки разработки и их последствия; 🔉 рассказали про преимущества — почему мы так любим работу в IT, которая влияет на миллионы пользователей. ➡ Смотреть и комментировать.

Радио «Виктор»: инструменты управления иллюзорны, но такова жизнь До того, как я стал тимлидом, я думал, что мне отсыплют немного «власти». И внешне так оно и выглядит — ты теперь маленький, но босс, вот тебе люди, управляй. А потом оказывается, что никакого волшебного интерфейса, как в игре Sims, не появляется. Более того, ни «кнут», ни «пряник» тоже не оказываются под твоим полным контролем, да и не всегда понятно, что именно ими может быть. Плюшки Тимлид может раздавать «интересные» задачи как награду или закрывать глаза на отступления от корпоративных правил для поощрения. И наоборот — забирать это в качестве наказания. Вот только границы таких методов очень узкие. Потому что если использовать их «на всю катушку», быстро столкнешься с последствиями. Например, увеличишь bus factor, потому что только один человек в команде «трогал» эту новую крутую технологию. Деньги Трудоустройство — это понятная договоренность: работодатель платит деньги, а сотрудник выполняет работу. Вот только для инженерных профессий это работает плохо (подозреваю, что и для многих других тоже). Проблемы начинаются уже на старте, в момент договоренности. Вы когда-нибудь видели служебную инструкцию, которая объясняла бы, что от вас ожидается? Ради интереса попробуйте составить такую сами про себя, а потом проверьте, насколько реальность совпадает с написанным. Будет ли разработчик контрибьютить в два раза больше кода в продакшен, если начать платить ему в два раза больше? Думаю, ответ очевиден. Но еще хуже то, что тимлид, как правило, не оказывает прямого влияния на зарплаты. Он не может просто взять и заплатить Васе больше, а Маше — меньше. В крупных компаниях для этого есть сложные процессы вроде performance review. В стартапах можно попробовать выбить повышение через цепочку руководителей. Когда-то мне казалось, что это просто бюрократия. Но даже у собственника бизнеса руки связаны. С одной стороны, «вилку» ограничивают рыночные условия и невозможность понизить кому-то оклад. С другой — экономика бизнеса и необходимость единой политики для одной должности. Увольнения и наказания Есть миф, что уволить человека очень сложно из-за трудового законодательства. На практике любая компания увольняет сотрудников и справляется с этим. Но может ли тимлид уволить любого члена своей команды в любой момент? Конечно, нет. Минимум, ему придется аргументировать это перед HR, руководством, бизнесом. То есть окончательное решение принимает не он. И это только верхушка айсберга. Чтобы иметь реальную власть в вопросах увольнения, нужно еще управлять наймом. А найм — это дорогой и сложный процесс. Это не значит, что нужно держаться за каждого, даже самого токсичного и бесполезного сотрудника. Но назвать увольнение эффективным инструментом управления тоже сложно. Что же остается? Все вышеперечисленное. И еще множество других методов. Цель этого поста — показать, что никакого волшебного «пульта управления» нет. Ни у тимлида, ни у мидл-менеджмента, ни у топов, ни у собственников. Его просто не существует. Люди слишком сложные.

Радио «Виктор»: вина и ответственность Многие путают эти два понятия. Кто-то считает, что «взять на себя ответственность» — то же самое, что «признать себя виноватым». Другие говорят о том, что можно «назначить виноватого», и это то же самое, что «переложить на него ответственность». Между тем именно наше отношение к ответственности определяет профессиональный рост в здоровой культуре. Вина Вина сосредоточена на прошлом и может быть вменена кому-то от кого-то на основании объективных фактов или субъективных суждений. Субъект обвиняет объект в чем-то и может применить к нему насилие: наказание, порицание, отсутствие поощрения. Например, тимлид A считает разработчика B виноватым в том, что тот не сделал задачу в обозначенный срок, и наказывает его тем, что не продвигает его на грейд-ап. Вина не всегда имеет последствия, но, так как эти последствия связаны с насилием, она вызывает страх. Вина может быть снята или передана «по-настоящему виновному». Признание вины — это готовность понести наказание. А еще, в переговорах, это снятие этой вины с других присутствующих, что уменьшает их страх. Ответственность Ответственность же нельзя передать насильно. Ее можно только принять, взять. Ответственность — это готовность справляться с последствиями. Она может быть выражена явно, например: «Задача провалена, но теперь я готов сделать то-то и то-то, чтобы не завалить весь проект». Или может быть «по умолчанию», в виде «за такой-то домен отвечает вот этот человек». Но это не будет работать, если ответственное лицо не готово что-то делать. У ответственности много интересных свойств. Например, ответственность нельзя делегировать. Я отвечаю за проект, в рамках проекта есть задача, которую я попросил сделать своего репорта. Теперь и я несу ответственность за проект, и он несет ответственность за задачу, если мы оба на это согласились. Отсюда следует, что если я взял за что-то ответственность, то это не значит, что я должен лично совершить все действия. Проблемы Огромное количество рабочих конфликтов возникает из-за того, что люди не понимают этой разницы. Или не убеждаются в том, что кто-то взял на себя ответственность. Или берут, а потом сбрасывают с себя. Иногда еще и обвиняя всех вокруг. Не делайте так. А еще огромное количество ответственных людей загоняет себя в ловушку. Им дают новые зоны ответственности, они берут, при этом не взвесив собственный ресурс. А как отказаться — не понимают. И привет «выгорание». Если хотите пост про то, в чем разница между «сбросить с себя ответственность» и «отказаться от нее», то вы знаете, что ставить в реакциях. P.S. Обычно в постах я пытаюсь привести примеры из своей практики. Но тут они могут быть слишком чувствительными для участников тех или иных событий.

Радио «Виктор»: Как искать бездельников? Инженерная профессия включает большую долю творчества. Разработка так и называется, потому что это про изобретение решений. В других IT-профессиях, например, в дизайне, эксплуатации, QA, тоже много изобретательства. А это значит, что: - На производительность влияют не только навыки, инструменты и контроль, но и такие эфемерные вещи, как удобство, понимание цели и даже хорошее настроение. - Нет полностью объективных критериев оценки навыков. - Не существует эффективного способа контроля продуктивности. - Один человек за час может сделать больше, чем десять за десять дней. Это здорово, но делает отрасль уязвимой к абьюзу со стороны сотрудников. Дровишек в костер добавляют и «рынок кандидата» и удаленка. Все это дает возможность работать меньше за счет других коллег. Дисклеймер: я не утверждаю, что работодатели святы или что удаленка — плохо. Я за то, чтобы работать меньше и зарабатывать больше, если это честно. Речь о том, что некоторые люди осознанно или нет используют уязвимость системы, чтобы участвовать в разделении благ, но не делить обязанности. И ответственность. История Васи Однажды я пришел руководить удаленной командой, которая делала проект по оптовой продаже цветов. Был разработчик, назовем его Вася, который несколько месяцев работал над проектом. Цветы закупались на голландских биржах. Где-то данные получали через API, а где-то приходилось парсить HTML/XML прайс-листы. Вася участвовал в обсуждениях, задавал вопросы, но его задачи постоянно сдвигались. Однажды он показал нам белую страницу, где «ну уже почти все готово, только багу поправить». В другой раз, показал по видео кусок кода, который вот уже почти работает, но к ревью еще не готов. В третий — показал, что в базе, которую он наполняет, вот уже что-то есть (правда оказалось, что данные только первого запроса в первый API метод). Я пошел общаться с командой и разбираться почему так. Может, действительно, эта задача такая трудная, а я снаружи не вижу. И оказалось, что несколько предыдущих задач, которые «сдавал» Вася, на самом деле за него делали другие члены команды. К кому-то он приходил с просьбой помочь. С кем-то делали проект вдвоем, только вот «Вася приболел». А кто-то вообще половину работы сделал в рамках кодревью. И так ловко это было сделано, что никто в команде не считал Васю нахлебником. А проджект менеджер был Васей доволен. Результат моего исследования показал, что Вася не сделал ни одной задачи(!) за несколько месяцев — все делал кто-то другой. При этом, технически он был даже лучше подкован, чем коллеги. С тех пор я встречал подобных «Васей». Они легко проходят собеседования, участвуют в обсуждениях, спорят о технических деталях, но не делают ничего полезного. Такое поведение первое время легко перепутать с «человек еще въезжает». Или с «ну наверное действительно сложная таска, нужно попробовать дать что-то другое». Выводы Таких людей нужно увольнять как можно быстрее. И не бояться ошибиться, уволив не того. Причина не только в чувстве справедливости. Подобное поведение отравляет команду, вызывает сомнения в себе, руководителе и ценности работы. Я верю, что рабочее время важно проживать с драйвом, интересом и в окружении людей, которые любят свое дело. Чтобы с радостью начинать понедельник в субботу.

Радио «Виктор»: Делаю все, но ничего не работает Я не раз был в ситуации, когда убеждал себя, что делаю все возможное, но результат просто сам берет и не достигается. Это когнитивная ловушка — на самом деле, конечно, так не бывает. Нам проще свалить все проблемы на людей вокруг, на отрасль, на то, что «время сейчас такое», чем признать, что что-то не так внутри нас. Знания Если в мире существует кто-то, кто уже справился с подобными проблемами, то от него мы можем получить знания — узнать, что еще не было испробовано. В мою бытность CTO студии «Феникс» был момент, когда мы были в ужасной финансовой яме. Не просто не получали зарплату, но и вкладывали свои запасы на черный день, чтобы вовремя выплатить деньги сотрудникам. Тогда я впервые в жизни взял платную консультацию. Ожидал либо банальных советов, либо таких сложных, что их реализация займет годы. Но получил, кроме прочего, совет совершенно внезапный. Не вдаваясь в детали, он касался особенностей налогообложения. Один этот совет позволил нам резко выйти из глубокого минуса в ноль. Знания можно получать не только от экспертов. Есть книги, видео, телеграм-каналы и записи докладов с конференций. Умения Возможно, вы формально все делаете правильно, но «дьявол кроется в деталях». Например, одно дело — проводить регулярные 1-to-1, другое — получать от них результат. Недавно я разговаривал с другом, который жаловался, что вынужден микроменеджерить через уровень: решать некоторые задачи вместе с тимлидом и его сотрудником буквально втроем. Он и подчеркивал важность результата, и планы составлял, и показывал на примерах, как их добиваться. Использовал разные подходы, проводил ретро по аналогичным задачам. Но каждый раз все заканчивалось чем-то вроде «ну, будем внимательнее». Проблема была в том, что не хватало работы в режиме постмортем. Хочется сказать, что сразу все стало хорошо, но врать не буду — выводы делать еще рано. Опыт Бывают ситуации, когда для решения проблемы недостаточно знаний и умений. Тогда нужно искать опыт. Здесь уже не получится его заимствовать — нужен первоисточник. Однажды мы не могли отладить плавающий баг с etcd. При определенном паттерне использования, спустя несколько суток единичные стримы из сотен тысяч «залипали»: соединение не обрывалось, но данные переставали поступать через watch. Проблема вроде была понятна, удавалось ее повторить, код всех компонентов был открытым — бери и решай. Но мы бились несколько недель. В итоге я решил привлечь опытного разработчика из соседней команды. Ему хватило трех дней, чтобы найти проблему. Причем именно там, где ее искали несколько человек, но упорно не видели. Мудрость Бывают ситуации, когда проблема не решается просто потому, что вы внутренне не хотите ее решать. Тогда нужно честно признаться в этом себе. А потом идти и договариваться с теми, кто ждет от вас решения. Возможно, все окажется не так страшно. Были и у меня решения, когда я уходил. Главное сделать это открыто и договорившись. Бежать от проблем «по-англиский» — точно не наш путь. Итог Первые три пункта я вспоминаю каждый раз, когда кажется, что проблема неразрешима. Это работает и на коротком горизонте — например, во время инцидентов, когда все очевидные варианты уже исчерпаны, а руки опускаются. Тогда я собираю и формулирую все, что известно на текущий момент, чтобы понять, чего не хватает: знаний, умений или опыта. А в больших жизненных вопросах иногда приходится доходить и до четвертого пункта. Это больно. Но точно лучше, чем обманывать себя и окружающих.

Радио «Виктор»: Почему компании тупят? Чем больше компания или даже конкретная команда, тем больше возникает регламентов и «глупых» правил. А в инженерной части все больше «квадратно-гнездового» и меньше ситуативно-эффективного. Инженеру непонятно, почему ему запрещают использовать тригеры в СУБД, если это решает его задачу. Почему линтер блокирует пайплайн с устаревшей библиотекой, хотя новая версия ничем не лучше. Почему требуют использовать Kafka только как Pub/Sub, и не использовать как распределенный лог или буффер, хотя Kafka «вообще-то для этого и создавалась». Такие вопросы я слышу почти каждый день, и они всегда заставляют меня задуматься: действительно ли предлагаемое решение более эффективно? Не всегда. Но бывает, что это действительно так. А прав ли инженер, утверждая, что эффективность в конкретном кейсе оправдывает исключение? В большинстве случаев — нет. Пример из управленческой плоскости: человек с зарплатой X увольняется из-за денег, а на его место после долгих поисков берут человека с зарплатой (X+20%) и меньшей квалификацией. Причины могут быть разными, но обычно они в плоскости того, что правила не позволяют повысить зарплату в этот период, для этого сотрудника, в этой стране (если компания международная) и так далее. Такие ситуации часто возникают, и на первый взгляд они кажутся нелогичными. Однако эти «неэффективности» тоже имеют своё объяснение. В обеих ситуациях, мы действуем не эффективно. Но почему? А все из-за того, что почти невозможно управлять крупной командой, регулировать крупную систему ситуационно. От случая к случаю. Вместо этого, есть два пути: дробить систему на более мелкие или придумывать общие правила, которые работают хорошо в большинстве случаев, но часто оказываются неэффективными в исключительных ситуациях. Каждое исключение из правил — это всегда риск. А риски на бесконечном горизонте «стреляют» всегда. Например, все микросервисы компании выкатываются в кубер единым пайплайном с общими правилами масштабирования и распределения по неймспейсам и зонам доступности. Мы делаем исключение для одного сервиса — полностью кастомный пайплайн, выкатывающий его в три разных неймспейса по одному на каждую зону доступности. Сначала все будет хорошо. Но через год или два мы захотим, чтобы доступ к секретам определялся неймспейсом. Вспомним ли мы, в этот момент, об исключении? Протестируем ли для него? Верно ли напишем логику исключения в новом коде? Ну, думаю, вы поняли, чем такое кончается... Но без исключений нельзя Хотим мы того или нет, но совсем без исключений тоже не получается. Иногда неэффективность становится настолько чудовищной, что важно сделать иначе, не смотря на риски. А еще есть легаси системы, есть внедренные «сбоку», есть переданные из других команд. И каждое из таких исключений висит, как Дамоклов меч. Или, если хотите, как Чеховское ружье. Вот и получается, что есть три стула: 1. Дробить систему и изобретать велосипед в каждой части — это приведёт к потерям времени и ресурсов. 2. Загонять всех в рамки и заставлять всех работать по одному сценарию — это создаст внутренние конфликты и снизит гибкость. 3. Делать исключения и страдать от их последствий. Вас ждет неочевидное поведение и аварии. Любая крупная компания выбирает сразу все три. Но разные компании, в разных пропорциях.