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

Во-первых, потому, что такие доклады шире — далеко не каждому придется переводить проект с webpack на vite или писать собственный s3-сервер. Зато каждый из нас сталкивался с необходимостью договариваться с теми, с кем не хочется договариваться; выстраивать собственную карьеру; разбираться что не так с идеей work-life balance. Во-вторых, потому, что эти навыки более долговечны. Технологии приходят и уходят, необходимость общаться с коллегами остается всегда.

Мой хороший друг, Андрей Смирнов, автор подкаста Frontend Weekend собрал клевых ребят, большинство из которых я знаю лично. И в эту субботу, 23 ноября, проведут конфу исключительно про софты: Soft Weekend. Обещали без рекламных стендов от компаний и агрессивного тыканья HR-брендами в лицо. Зато с 14ю полезными докладами и всякими нетворк-активностями.

Стоимость билета - 7к рублей за одного и 12к за двоих. На такую движуху вполне можно взять супруга/супругу и устроить семейный уикэнд. Для вас промокодик KODAKODA — скидка 10%. Купить можно здесь

Радио «Виктор»: Конфликт интересов

Бо́льшую часть своей жизни я думал, что конфликт интересов — это всегда связано с мошенничеством или грязными схемами. Или, по крайней мере, с сложным моральным выбором. Например, как тимлид, я хочу удержать сотрудника, а как друг — посоветовать ему двигаться дальше. Такие дилеммы я всегда решал одним способом: увеличением горизонта планирования. На длинной дистанции «морально правильное» почти всегда оказывается выгодным для всех сторон.

Например, если сотрудник «вырос» из своей позиции в команде, то всем лучше помочь ему найти место, где он сможет развиваться. Это полезно для него, для команды и для компании.

Но этот подход не всегда работает. Особенно когда на выбор влияет нерациональный актор. Это может быть не человек, а, например, формальные правила компании. Допустим, компании и тимлиду выгодно взяться за задачу прямо сейчас. Но скрам-процессы компании, моя лень или нежелание «прогибаться» заставляют отложить задачу на следующий спринт. Это тоже конфликт интересов. И здесь увеличение горизонта планирования не помогает: компаниям важно соблюдать процессы, но иногда команде выгоднее действовать быстрее.

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

Я не считаю, что «вторая работа» или сайд-проекты — это плохо. Напротив, это ценный опыт. Но они неизбежно вызывают конфликты интересов. Поэтому я считаю важным говорить о них открыто. Лучший способ — обсудить это лично, в доверительной атмосфере. Если же у вас нет доверия к своей компании или руководителю, то стоит ли тратить на них свои силы и время? Мой выбор — работать с теми, кому я доверяю, и заявлять о конфликте интересов.

Три года я вел подкаст «ТехноЛогично» от Газпромбанка. Это была важная часть моей жизни. В отличие от моего подкаста «Кода кода», я сразу получал обратную связь от независимых людей. Эта обратная связь, в том числе, выражалась в том, что мне продолжали платить как приглашенному ведущему. Я чувствовал поддержку и одобрение, а еще мне нравились гости и темы.

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

Больно, но свою позицию я не поменял. Буду рад, если вы в комментариях поделитесь своей.

Радио «Виктор»: Не думай за других людей

Эволюция научила Homo sapiens эмпатии. Мы стараемся понять чувства других, даже когда только готовимся к разговору. Дети копируют эмоции родителей, а затем учатся сопереживать. Эмпатия — это ключевой навык для жизни в обществе. Но она же — встроенный «бэкдор» для манипуляций.

Говорят, именно эмоциональный интеллект приводит нас к управленческим позициям. Он помогает понять других и предсказывать их реакции. Но иногда эти предположения заходят слишком далеко.

Мы начинаем предсказывать не только эмоции, но и мысли, а затем — решения других людей. Чем ближе мы знаем человека, тем чаще предположения верны. Но даже если вероятность точности 99%, каждая дополнительная ступень умозаключений снижает её. Это как в шахматах: хороший игрок видит 2–3 хода вперёд, гроссмейстер — 5–7, но никто не просчитывает всю партию.

Почему это важно в инженерной среде?
Инженеры часто опираются не на эмоции, а на опыт: что раньше подводило, что чаще ломалось, что приходилось срочно чинить. Однако у разных инженеров опыт сильно различается, что делает их подходы менее предсказуемыми.

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

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

Другой случай — инструмент для тестирования функциональности с использованием топиков кафки. Мы не учли, что за запись и чтение могут отвечать разные команды, и синхронизация между ними не всегда возможна. Пока мы поняли это, успели выслушать много критики. Коллеги обвиняли команду во всхе смертных грехах — и что пытаемся запретить кафку, что делаем все сложнее, что не даем использовать проверенный инструмент as-is. Требовали срочно запретить использовать этот инструмент. В итоге, были добавлены новые режимы работы и все стали счастливы.

Или история с интеграционными тестами. Коллеги неожиданно попросили срочно перейти на моки вместо тестов с их «ручками». Это вызвало конфликт и непонимание. Спор шел несколько дней вокруг того, как правильно строить тестирование. А причина оказалась простой: их система тратила огромные ресурсы на поддержание идемпотентности, которая была нужна только для этого кейса. В итоге, был найден способ, как не аффектить ее.

Выводы
Что объединяет эти истории? Это не инженерные проблемы, а проблемы коммуникации. Невозможно предусмотреть все сложности и обойти тысячу команд для обсуждения деталей. Вместо этого стоит создать понятный образ системы и объяснить, почему он сделан именно так.

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

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

Инженеру непонятно, почему ему запрещают использовать тригеры в СУБД, если это решает его задачу. Почему линтер блокирует пайплайн с устаревшей библиотекой, хотя новая версия ничем не лучше. Почему требуют использовать Kafka только как Pub/Sub, и не использовать как распределенный лог или буффер, хотя Kafka «вообще-то для этого и создавалась». Такие вопросы я слышу почти каждый день, и они всегда заставляют меня задуматься: действительно ли предлагаемое решение более эффективно? Не всегда. Но бывает, что это действительно так. А прав ли инженер, утверждая, что эффективность в конкретном кейсе оправдывает исключение? В большинстве случаев — нет.

Пример из управленческой плоскости: человек с зарплатой X увольняется из-за денег, а на его место после долгих поисков берут человека с зарплатой (X+20%) и меньшей квалификацией. Причины могут быть разными, но обычно они в плоскости того, что правила не позволяют повысить зарплату в этот период, для этого сотрудника, в этой стране (если компания международная) и так далее. Такие ситуации часто возникают, и на первый взгляд они кажутся нелогичными. Однако эти «неэффективности» тоже имеют своё объяснение.

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

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

Но без исключений нельзя
Хотим мы того или нет, но совсем без исключений тоже не получается. Иногда неэффективность становится настолько чудовищной, что важно сделать иначе, не смотря на риски. А еще есть легаси системы, есть внедренные «сбоку», есть переданные из других команд. И каждое из таких исключений висит, как Дамоклов меч. Или, если хотите, как Чеховское ружье.

Вот и получается, что есть три стула:
1. Дробить систему и изобретать велосипед в каждой части — это приведёт к потерям времени и ресурсов.
2. Загонять всех в рамки и заставлять всех работать по одному сценарию — это создаст внутренние конфликты и снизит гибкость.
3. Делать исключения и страдать от их последствий. Вас ждет неочевидное поведение и аварии.

Любая крупная компания выбирает сразу все три. Но разные компании, в разных пропорциях.

Радио «Виктор»: Делаю все, но ничего не работает
Я не раз был в ситуации, когда убеждал себя, что делаю все возможное, но результат просто сам берет и не достигается. Это когнитивная ловушка — на самом деле, конечно, так не бывает. Нам проще свалить все проблемы на людей вокруг, на отрасль, на то, что «время сейчас такое», чем признать, что что-то не так внутри нас.

Знания
Если в мире существует кто-то, кто уже справился с подобными проблемами, то от него мы можем получить знания — узнать, что еще не было испробовано.

В мою бытность CTO студии «Феникс» был момент, когда мы были в ужасной финансовой яме. Не просто не получали зарплату, но и вкладывали свои запасы на черный день, чтобы вовремя выплатить деньги сотрудникам. Тогда я впервые в жизни взял платную консультацию. Ожидал либо банальных советов, либо таких сложных, что их реализация займет годы. Но получил, кроме прочего, совет совершенно внезапный. Не вдаваясь в детали, он касался особенностей налогообложения. Один этот совет позволил нам резко выйти из глубокого минуса в ноль.

Знания можно получать не только от экспертов. Есть книги, видео, телеграм-каналы и записи докладов с конференций.

Умения
Возможно, вы формально все делаете правильно, но «дьявол кроется в деталях». Например, одно дело — проводить регулярные 1-to-1, другое — получать от них результат.

Недавно я разговаривал с другом, который жаловался, что вынужден микроменеджерить через уровень: решать некоторые задачи вместе с тимлидом и его сотрудником буквально втроем. Он и подчеркивал важность результата, и планы составлял, и показывал на примерах, как их добиваться. Использовал разные подходы, проводил ретро по аналогичным задачам. Но каждый раз все заканчивалось чем-то вроде «ну, будем внимательнее». Проблема была в том, что не хватало работы в режиме постмортем. Хочется сказать, что сразу все стало хорошо, но врать не буду — выводы делать еще рано.

Опыт
Бывают ситуации, когда для решения проблемы недостаточно знаний и умений. Тогда нужно искать опыт. Здесь уже не получится его заимствовать — нужен первоисточник.

Однажды мы не могли отладить плавающий баг с etcd. При определенном паттерне использования, спустя несколько суток единичные стримы из сотен тысяч «залипали»: соединение не обрывалось, но данные переставали поступать через watch. Проблема вроде была понятна, удавалось ее повторить, код всех компонентов был открытым — бери и решай. Но мы бились несколько недель. В итоге я решил привлечь опытного разработчика из соседней команды. Ему хватило трех дней, чтобы найти проблему. Причем именно там, где ее искали несколько человек, но упорно не видели.

Мудрость
Бывают ситуации, когда проблема не решается просто потому, что вы внутренне не хотите ее решать. Тогда нужно честно признаться в этом себе. А потом идти и договариваться с теми, кто ждет от вас решения. Возможно, все окажется не так страшно. Были и у меня решения, когда я уходил. Главное сделать это открыто и договорившись. Бежать от проблем «по-англиский» — точно не наш путь.

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

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

Радио «Виктор»: Как искать бездельников?
Инженерная профессия включает большую долю творчества. Разработка так и называется, потому что это про изобретение решений. В других IT-профессиях, например, в дизайне, эксплуатации, QA, тоже много изобретательства. А это значит, что:
- На производительность влияют не только навыки, инструменты и контроль, но и такие эфемерные вещи, как удобство, понимание цели и даже хорошее настроение.
- Нет полностью объективных критериев оценки навыков.
- Не существует эффективного способа контроля продуктивности.
- Один человек за час может сделать больше, чем десять за десять дней.

Это здорово, но делает отрасль уязвимой к абьюзу со стороны сотрудников. Дровишек в костер добавляют и «рынок кандидата» и удаленка. Все это дает возможность работать меньше за счет других коллег.

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

История Васи
Однажды я пришел руководить удаленной командой, которая делала проект по оптовой продаже цветов. Был разработчик, назовем его Вася, который несколько месяцев работал над проектом. Цветы закупались на голландских биржах. Где-то данные получали через API, а где-то приходилось парсить HTML/XML прайс-листы. Вася участвовал в обсуждениях, задавал вопросы, но его задачи постоянно сдвигались. Однажды он показал нам белую страницу, где «ну уже почти все готово, только багу поправить». В другой раз, показал по видео кусок кода, который вот уже почти работает, но к ревью еще не готов. В третий — показал, что в базе, которую он наполняет, вот уже что-то есть (правда оказалось, что данные только первого запроса в первый API метод).

Я пошел общаться с командой и разбираться почему так. Может, действительно, эта задача такая трудная, а я снаружи не вижу. И оказалось, что несколько предыдущих задач, которые «сдавал» Вася, на самом деле за него делали другие члены команды. К кому-то он приходил с просьбой помочь. С кем-то делали проект вдвоем, только вот «Вася приболел». А кто-то вообще половину работы сделал в рамках кодревью. И так ловко это было сделано, что никто в команде не считал Васю нахлебником. А проджект менеджер был Васей доволен. Результат моего исследования показал, что Вася не сделал ни одной задачи(!) за несколько месяцев — все делал кто-то другой. При этом, технически он был даже лучше подкован, чем коллеги.

С тех пор я встречал подобных «Васей». Они легко проходят собеседования, участвуют в обсуждениях, спорят о технических деталях, но не делают ничего полезного. Такое поведение первое время легко перепутать с «человек еще въезжает». Или с «ну наверное действительно сложная таска, нужно попробовать дать что-то другое».

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

Я верю, что рабочее время важно проживать с драйвом, интересом и в окружении людей, которые любят свое дело. Чтобы с радостью начинать понедельник в субботу.