О науке менеджмента

Слушал подкаст Глеба Соломина про нейробиологию и генетику https://www.youtube.com/watch?v=wuhxDAAvWRg. Тема в последнее время архипопулярная: модно стало если не всё, то многое в человеческом поведении определять через действие тех или иных генов. Крайние пропагандисты этой детерминистской теории вроде Сапольски так вообще отменили свободу воли.

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

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

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

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

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

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

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

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

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

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

На эту же цель ознакомления с профессией работает первая часть книги: автор рассказывает, как сейчас устроена разработка ПО, какие роли, этапы бывают. Также в книге очень много места уделено разным нотациям - UML, BPMN, eEPC и т.д. Она годится если не как справочник, то хотя бы как навигатор по этой теме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Людям из более "стабильных" областей это всё может показаться бредом, но мы в ИТ постоянно живём в таком режиме. И в продуктовых командах, и в заказной разработке.

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

Сегодня прочитал заметку Глеба Кузнецова https://news.1rj.ru/str/glebsmith77/358. Давно подписан на этого автора: он мыслит чётко, структурировано, даёт хороший анализ по различным темам.

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

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

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

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

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

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

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

Моя коллега, HRD компании Postgres Professional Ксения Замуховская написала для Хабра заметку про "токсичного гения" с говорящим названием "Харды не спасут: почему «человек-клей» выживет, а «токсичного гения» уволят (даже если он тащит прод)". Поскольку название было выбрано провокационное, материал собрал некоторое количество возмущённых откликов.

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

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

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

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

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

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

Однако: никакой больше крутой сисадмин или программист PHP не будет открывать дверь с ноги, потому что является носителем уникального знания.

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

В следующей части поясню на двух примерах, что значит думать о взаимодействии.

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

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

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

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

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

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

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

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

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

Программисты (из моей практики) часто бросают код на этапе реквеста: его одобрили, и они даже не мерджат. Впереди уже другая интересная головоломка. А зачем был написан код, как он попадёт в прод, какую проблему закроет? - Это уже неинтересно.

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

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

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

Современные банки по сути огромные ИТ-компании, в самых больших работают тысячи и тысячи аналитиков, программистов, тестировщиков. Больше, чем в любой другой "настоящей" ИТ-компании, разве что кроме Яндекса. Но у многих из них в карьере случается вот такой своеобразный vendor lock, только на работодателя: они успешно трудятся над узким кругом задач, используя ограниченный набор инструментов, иногда даже внутренней разработки.

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

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

Сегодня ровно год, как я веду этот канал.

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

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

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

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

О вопросах

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

Например:
- Васенька, когда будет закрыт мердж-реквест XXX?
- Максим, вчера я нашёл вот такой баг, а сегодня Луна в третьем доме, а послезавтра будет концерт в Лужниках...
- (вежливо, спокойно) Хорошо, и я повторю свой вопрос: когда будет закрыт мердж-реквест XXX?
- (очень злится)

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

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

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

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

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

Закончился мой испытательный срок в компании Postgres Professional. Прошёл его успешно, продолжаю дальше наносить непоправимую пользу внутренним проектам компании.

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

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

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

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

Но не всё так елейно, естественно. Были промахи, была даже пара немаленьких таких провалов. Мне позволяли ошибаться и исправлять свои ошибки самому, а значит, расти над собой. Позволяли заниматься управленческим творчеством, и это очень ценно.

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

Особенно это касается менеджеров, руководителей. Нам выпало быть инженерами по работе с людьми. Это и особенная ответственность, и особенный кайф от того, что получается сделать хорошо вместе с другими. Всем успехов в Новом 2026 году!