(часть 1)

Как увеличить свои шансы на прохождение собеседования

Кроме общих слов о том, почему вообще надо спрашивать про место, где вам предстоит проводить треть из ваших 24 часов много-много дней и месяцев подряд, напишу, почему это так важно для руководителя:

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

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

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

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

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

(часть 3)

(часть 2)

Как увеличить свои шансы на прохождение собеседования

Кстати, о культуре компании

Слово "культура" произошло от латинского cultura — «возделываю, обрабатываю землю» (ниже курсивом - по статье из русскоязычной Википедии).

В латинских источниках впервые слово встречается в трактате о земледелии Марка Порция Катона Старшего (234—148 годы до н. э.) De Agri Cultura (около 160 года до н. э.) — самом раннем памятнике латинской прозы.

Этот трактат посвящён не просто обработке земли, а уходу за полем, что предполагает не только возделывание земли, но и особое душевное отношение к ней. Например, Катон даёт такой совет по приобретению земельного участка: нужно не лениться и обойти покупаемый участок земли несколько раз; если участок хорош, чем чаще его осматривать, тем больше он будет нравиться. Вот это самое «нравиться» должно быть непременно. Если его не будет, то не будет и хорошего ухода, то есть, не будет культуры.

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

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

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

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

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

P.P.S. Кстати, мне в команду нужно 4 специалиста разного уровня. Хорошая известная российская компания. Приходите!

В субботу 24 января в очередной раз посетил митап кружка Петра Жаркова https://t.me/morkovka_speredi_morkovka_szadi/371. Было заявлено три темы, успели разобрать только две. Как всегда, было очень весело и интересно, поскольку проводится в интерактивной манере: разбиваемся на команды, играем и выигрываем.

Первая игра была близкой к моему опыту работы в реальном мире. Вводные: фирма хочет делать х2 продаж, у маркетинга есть план. CEO не понимает, что делает ИТ: оно проедает большой бюджет, сроки постоянно срываются, CIO невнятно оправдывается. Мы - представители консалтинговой фирмы. Нам надо разработать план и презентовать его CEO, чтобы заключили контракт именно с нами (в игре участвует три команды). На всё про всё 45 минут, команда из 8 или 9 человек, никто друг друга не знает либо видит буквально второй раз в жизни. Вперёд!

Этот этап моя команда выиграла. Я ещё раз убедился в своих специфичных навыках: в ситуации неопределённости быстро беру на себя ответственность по организации людей и выдерживаю тайминг. Капитанов команд никто не назначал, я с первой секунды самоназначился. Сначала
правила работы, потом назначение ролей, потом сама работа. В первые минут 15-20 модерировал обсуждение, чтобы оно было более конструктивным. В один момент чуть отодвинул товарища, который очень долго и ветвисто любит рассуждать куда-то в бок (надеюсь, он не в обиде).

Итог - мы выиграли. Всего лишь игра, а приятно. Для меня ещё важно, что единственные из трёх точно вписались в отведённое время (моя суперсила).

Вторая игра следующая. Делимся на 5 команд, от каждой надо выбрать и рассказать интересную поучительную историю про делегирование.

К своему удивлению, от моей новой команды (мы пересобрались после первого задания) вышел я со своей историей. Почему удивлению? - Я вообще не рассказчик, артистические навыки ниже среднего, особо не умею держать зал и всё такое. Однако ребята проголосовали за мою историю. Её, кстати, напишу чуть позже: она на самом деле поучительная. А коллеги по обсуждению своими тезисами ещё добавили глубины.

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

А вот та самая история про делегирование, которую я анонсировал в прошлом сообщении https://t.me/playingjazz/87.

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

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

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

...Шли дни моего счастливого отпуска. Мы с семьёй купаемся, загораем, едим арбузы. Короче, отдыхаем! Вдруг! - в пятницу на второй неделе, то есть в последний рабочий день Васи в качестве моего зама раздаётся звонок. От него!
- Да, Вася?
- Максим, тут такое, тут такое!.. Я не знаю, как мне быть, извини, что врываюсь в отпуск, но я правда не знаю, памаги-спаси!

Начинаем разбираться. Прод упал и лежит? - Нет, прод работает, клиенты идут. Кто-то умер и не оставил завещания, как мерджить задачу? - Нет, все живы. И так по самым главным пунктам. В итоге доходим до того, что релиз не выпустили в срок, а так в целом все молодцы.

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

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

На дискуссии в группе коллега рассказывал: у него тоже был опыт передачи дел своему заму. И он, руководитель, просто в первые дни приходил к заму и говорил: всё ок, всё ок, всё ок. Человек успокаивался, он понимал, что немного "под присмотром". И в какой-то момент окончательно успокоился, костыли были убраны.

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

Короче, делегирование не заканчивается на формальном рукопожатии при передаче задачи. Иногда оно имеет продлённый эффект, и на это тоже надо закладываться.

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

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

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

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

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

Что тут может и должен сделать РП?

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

Во-вторых, у РП тут открывается продуктовая перспектива. Часто "быстро-срочно" требуют не со зла, а потому что наличный продукт в каких-то важных для заказчика местах отличается от идеальной картины. Может быть, вот этой зелёной кнопочки нет в вашем годовом плане, но у него болит, и всю остальную работу, которую вы делали 2000 человеко-часов, он считает напрасной. На самом деле, далеко не все люди мыслят категориями проектов (и это нормально!), но искренне хотят сделать продукт лучше. РП начинает не только видеть "план-факт-ресурсы", но и что он вообще делает, и как это помогает пользователю.

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

Продолжаю рассуждать про разницу в работе между руководителем проектов и тимлидом. Она в том числе вытекает из простого факта, что РП ближе к бизнесу.

Тут важно небольшое пояснение. Везде, где мы говорим о ролях РП, тимлида, иногда архитектора в компаниях в сфере ИТ, мы заранее понимаем, что в каждой компании своё представление о роли. Вот где-то даже СТО обязан писать код. А где-то (мои личные знакомые) тимлид вообще не прикасается к коду, а занимается только people-management и немного project-management.

Итак, руководитель проектов. Проект в нашем случае реализуется посредством ИТ-решений и силами ИТ-команды. Но главная цель такой реализации - обеспечить конкретную потребность бизнеса. Поэтому если тимлид сфокусирован больше на грамотном использовании ресурса ИТ-команды, то РП - на результате и пользе для компании.

Да, я считаю, что РП должен уметь думать про пользу. Где-то есть чёткое разделение: руководитель продукта про сам продукт и пользу, которую он приносит юзерам, акционерам и всем-всем-всем, а руководитель проектов только про исполнение задумок.

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

И всё же, где экспертиза со стороны РП по поводу пользы? - Всё просто. Работая в inhouse-командах, я всегда удивлялся, что почти всегда у нас, а также по многочисленным свидетельствам из других компаний, бизнес очень редко считает непосредственную эффективность доработок или устранения неисправностей.

Бывает, забегают в пятницу вечером: всё, капут, выводи всех своих завтра на overtime, даже заплатим по ТК РФ, нужно срочно добавить вон ту плашку на сайт! Аккуратно интересуешься, а зачем, а сколько народу ей будет пользоваться, а что это за категория посетителей, а какой средний чек она обеспечивает, а есть ли репутационные потери? Всем вдруг становится очевидно, что overtime стоимостью условно 100 тысяч рублей принесёт компании условные 5 тысяч, и то с вероятностью 0,7.

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

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

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

Попался на глаза короткий, но очень эмоциональный разбор одной небольшой джазовой пьесы Jumpin' At The Woodside в исполнении двух гениев джаза - Каунта Бейси и Оскара Питерсона. Автор наглядно разбирает, в чём именно состоит гениальность и за что нам стоит любить мастерство обоих пианистов: https://www.youtube.com/watch?v=PkMFLD4KtJg

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

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

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

И вообще оба играючи выбиваются из ритма, давая понять, что даже presto им не помеха намеренно отставать на 1/8-1/16-е ради того, чтобы поиграться друг с другом и со слушателем. Азартная игра со временем внутри азартной и быстрой пьесы!

Очень, очень классно! Имею возможность прослушивать Jumpin' At The Woodside на хороших Bang & Olufsen, получаю настоящий восторг от этой игры двух джазменов. Ты как-будто сам становишься умнее и тоньше, когда тебе предлагают настолько изысканное блюдо. Возвышает и окрыляет!

#джаз

Пет-проекты

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

В скобках замечу, что подход так себе. Трудоголизм вещь вообще не очень. Многие просто устраиваются на интересную работу и там делают своё дело хорошо, а вечерами уделяют внимание семье, хобби или лежанию на диване. Да, на собеседовании мало чего можно показать из прошлого кода, потому что у всех вокруг NDA (если только вы не ИИ-шки, которым доверяют все NDA-секреты без остатка). Но по мне так человек ведёт более сбалансированную и осмысленную жизнь, чем тогда, который после работы приходит на вторую работу.

Однако я вот о чём подумал. С разработчиками более-менее понятно. Что же спрашивать на собеседованиях у менеджеров в качестве пет-проекта?

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

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

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

Так что, выходит, будущим менеджерам вопросы про пет-проекты даже логичнее задавать? Что думаете, друзья?

Если вы руководите чем-то, проявляете себя вне работы? Или просто забываете обо всех связанных с этим стрессах и наслаждаетесь нормальной жизнью?

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

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

Во-вторых, я попросил рассказать, что изображено на рисунке. Там достаточно простая sequence-диаграмма, фронт запрашивает бэк, бэк идёт в базу, достаёт JSON и прокидывает обратно клиенту. Обычно все начинают рассуждать сразу вслух. Этот претендент завис секунд на 15 (думаю, скармливал картинку ИИ), потом начал говорить и выдал какой-то совершенно невообразимый канцелярский речекряк типа "на данной схеме мы наблюдаем последовательность осуществления роутинга запроса в реальном времени, направленную на поддержание процесса чего-то там". Я аж в голос засмеялся и попросил кандидата рассказать ещё раз своими словами, что происходит.

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

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

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

Во первых и главных: вообще есть мало фильмов про управленческие факапы. Если мы берём голливудское кино, которое можно отнести к производственным драмам, то оно всё так или иначе про истории успеха: от "Соцсети" про Цукерберга до "Основателя" про Рея Крока. Советские фильмы 60-80-х годов, вопреки устоявшемуся мнению о всесильной цензуре, часто весьма жёстко критикуют некоторые практики того времени. Вроде бы страна продолжает развиваться быстрыми темпами - рост производства очень впечатляет - а кинодеятели бичуют отдельные пороки только в путь!

Во вторых, советские фильмы сняты про обычных пиджаков, бюрократов, партийцев, то есть менеджеров. Иногда прямо про обычные рабочие бригады (как "Премия"), иногда про молодого главу горкома партии, как "Обратная связь". Но в любом случае, таких людей много. Можно представить себя на их месте. В то время как Голливуд снимает про выдающиеся величины: в фокусе находится личность, которая меняет целый мир. Интересно, но не про нас с вами.

Фильм на себе, конечно, вывозят великие актёры: Янковский, Ульянов, Лавров. Заняты также Гурченко, Гундарева. Ничего себе обычная производственная драма!

Сюжет строится вокруг того, что в горком приходит новый глава, а в городе сдаётся могучий комбинат всесоюзного значения. Фильм начинается со сцены: тётя меняет огромные цифры на конструкции комбината - "До пуска осталось N дней". Короче, дедлайн.

Дальше спойлер. Молодой управленец Янковский вдруг узнаёт, что definition of done по ходу строительства комбината подменил авантюристичный строитель Ульянов. В итоге отрасль и государство получат серьёзный убыток при формально успешно выполненной работе. Много кто понимает, что это плохо, но все приняли идею, что по-другому уже не получится. У Янковского хватает пороха докрутить ситуацию до конца. Конечно, у всех сторон есть своя правда, и в итоге то решение, которое было принято самым большим московским начальством, не сказать чтобы обрадовало хоть кого-то. Типичный компромисс.

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

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

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

Читаю "Впереди перемен" Джона Коттера. Наткнулся вот на такое интересное рассуждение:

"Работая отдельно, сотрудники движутся вверх по служебной лестнице, а в составе команды этого не происходит. Для успешной карьеры необходим солидный послужной список. Если же в нем будет записано, что «такой-то состоял членом команды, осуществлявшей что-либо», то в большинстве современных организаций этот аргумент воспримут как недостаточно веский для дальнейшего продвижения."

По-моему, очень интересный вопрос ставит автор ещё в 2012 году, и пока удовлетворительного ответа нет.

Даже у нас в ИТ уже некоторое время назад стало принято думать, что время гениев-одиночек прошло (я писал об этом ранее). Программисты, в одиночку пишущие за одну ночь гениальный код, который потом приносит миллиарды вашей фирме, - такое в прошлом. И программистов стало сильно больше, чем 30-40 лет назад, и код пишут не только люди, и конкуренция гораздо жёстче. Короче, новое качество способны давать команды, коллективы, группы, причём умело составленные.

Но вопрос в том, как мы умеем нанимать людей, раскрывающих свой потенциал именно в команде? - Если честно, в среднем по отрасли не очень.

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

Часть времени собеседований направлена на выяснение софт-скиллов, и среди этих софтов, вероятно, какой-то процент отводится навыкам коллективных действий. Но акцент пока что делается не на этом.

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

У меня нет красивого ответа. Вопрос в том числе и мне. Лично я не собеседованиях всегда думаю о человеке именно в рамках команды, куда его нанимаю. Но говорить о целенаправленных метриках, надёжных подходах к прояснению этого вопроса на собеседованиях пока рано. Скорее полагаешься на собственную интуицию и общее умение оценить человека.

Так что с одной стороны, да, "участвовал в успешной команде" выглядит блекло. И поэтому карьерные консультанты под копирку советуют писать в своих резюме эти уже до крови из глаз надоевшие "внедрил фреймворк Х, чем поднял производительность сервиса на 12,5%". А с другой - умеем ли мы, нанимающая сторона, среди тысячи других разглядеть того единственного человека, которого не достаёт именно нашей команде?..

О тестировании

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

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

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

Теперь же настала пора более вдумчиво работать над продуктом. Уровень качества, который вы при этом обеспечиваете, является одной из ключевых метрик. Выпустить вообще сырой продукт, который пользователи пусть и тестируют? - Ну если вы всем известные монополии и олигополии (не будем показывать пальцем), то наверное можно. Я лично наблюдаю в некоторых очень крупных сервисах явные баги, которые не закрываются 10 лет.

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

И через это тестирование становится не просто очередной группой в вашем отделе или департаменте, на которую надо выделять ФОТ, потому что надо. А начинает быть инструментом влияния на прибыль, который приносит продукт. Вы контролируете глубину тестирования - вы играете с балансом стоимость разработки / скорость / качество. Вы проводите глубокое пользовательское тестирование - вы возвращаете себе упущенную прибыль, которую вы не сможете посчитать ни одним анализом простоев в ваших Zabbix и Grafana. Вы настроили разумные нагрузочные и E2E - вы заставляете разработчиков лучше думать об архитектуре и вкладываться в надёжность, а не только в скорость доставки до прода.

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

Возвращение

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

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

Я уже ранее писал про своё отношение к отпуску руководителя: https://t.me/playingjazz/45 . Пересказывать лонгрид не буду даже кратко, повторю оттуда только один тезис: "Мы будем считать отпуском то состояние человека, когда он не работает свою работу ни в каком виде".

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

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

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

Я даже поймал себя на мысли, что сегодня в течение рабочего дня мне становится немного скучновато. Они все работают без меня, и у них всё хорошо! Просто стой и наблюдай рядом! Шероховатости есть везде, но в главном, считаю, у меня получилось. Еду домой окрылённый...

В поисках информации об управлении изменениями прочитал две книги Джона Коттера: "Впереди перемен" и "Наш айсберг тает". Автор - известный авторитет в области лидерства, профессор Гарварда и так далее.

Коттер пропагандирует свою собственную 8-шаговую модель управления изменениями:

1) Внушение людям ощущения необходимости перемен
2) Создание команды реформаторов
3) Видение перспектив и определение стратегии
4) Пропаганда нового видения
5) Создание условий для широкого участия сотрудников в преобразованиях
6) Получение скорых результатов
7) Закрепление достигнутых успехов и углубление перемен
8) Укоренение изменений в корпоративной культуре

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

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

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

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

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

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

(продолжение тут)

(начало тут)

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

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

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

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

Я смело могу рекомендовать обе книги к прочтению, особенно тем руководителям, кто не хочет сидеть на одном месте. Как пророчит сам автор, в XXI организации будут подвержены всё более частым изменениям, в частности, из-за обостряющейся международной конкуренции. Мы из 2026 видим, что в целом он был прав, только двигателем конкуренции бывает не только глобализация, но и другие внезапные события. Так или иначе, а меняться приходиться, и всё быстрее.

ps. Потихоньку начинаю пользоваться Obsidian в качестве собственной базы знаний. Давно хотел начать, и вот случилось. В частности, по книгам теперь делаю конспект, что позволяет быстро возобновить память о прочитанном. Пока очень нравится! По мере получения опыта расскажу более подробно.

Про то, как ИИ всех уволит

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

Команда действительно была выделена. Приступили. Но хорошо бы узнать подробности, ограничения и т.д. Создали чат. Биг босс немного побыл там аналитиком. На первоначальный сбор требований тоже ушло время, стало не 2 недели, а месяц с небольшим. В итоге на второй месяц MVP увидело свет.

И тут заказчик говорит: "Кстати, вот мы ещё работаем с такими клиентами..." И безопасники подоспели: "А помните про разделение персданных на разные контуры? И сколько типов операций, столько разных инстансов и согласий?" Короче, MVP как бы есть, но его точно никому нельзя показывать. Биг босс пишет: мол, сорян, но срок вправо на месяц.

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

Но когда многие рассуждают про внедрение ИИ в производство ИТ-продуктов, то почему-то максимально фокусируются на труде программиста. ИИшка весь код напишет за час, за второй час покроет всё автотестами, - всем добро пожаловать на рынок труда!

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

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

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

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

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

В компании Postgress Professional, где я работаю, с подачи основателя принято заниматься бегом. Конечно, необязательно, но получилось так, что я тоже начал втягиваться.

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

Самое удивительное, что это мой 17-й забег вообще. Конечно, раньше иногда бегал по стадиону, 2-3 раза в год, то 5, то 8 км. А с января 2026 начал целенаправленно бегать по дорожке в зале. И вот на 17-й раз уже полумарафон.

Когда один мой коллега по другой компании тоже начал бегать и где-то через полгода пробежал столько же, то я сильно удивлялся: мол, у тебя талант!

На самом деле, нужна только умеренная регулярность, и тогда любой заметный результат будет достижим. Наверное, это и есть мораль сей заметки.