Искусственные впрыски дофамина, метод «камеди бадди» и деление слона на части: Петр Туголуков – о работе менеджера

На IT-конференции DUMP-2024 команда Doubletapp записала серию подкастов с ее топовыми спикерами. Мы говорили с ними о Канбан Методе, о пользе контролируемых конфликтов внутри компании, о том, как выстроить эффективную команду продаж и можно ли продавать на IT-конференциях.

Одним из героев серии подкастов «Что-то на программистском» стал Петр Туголуков. Свой путь в IT он начинал больше десяти лет назад как разработчик C++, а затем ушел в менеджмент и сейчас руководит архитектурой в Xsolla, занимается консультациями и аудитом.

Искусственные впрыски дофамина, метод «камеди бадди» и деление слона на части: Петр Туголуков – о работе менеджера

В разговоре с CEO Doubletapp Сергеем Анчутиным Петр рассказал о дофамине менеджеров, критериях успешности IT-специалиста, правилах составления идеального резюме и минусах удаленки. А еще дал советы по управлению временем и поделился, как прием из стендапа помогает в его работе.

Как и почему ты из разработчика стал менеджером?

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

Насколько сильно отличается работа обычного тимлида от менеджмента уже нескольких команд и менеджмента менеджеров?

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

Для всех ли подходит такой карьерный путь — из разработчика становиться лидером?

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

А как выделять вот это желание быть лидером и выявлять таких людей?

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

Можно ли на этапе джунов и стажеров выявлять таких лидеров?

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

У тебя нет фантомных болей и желания попрограммировать после того, как ты стал большим менеджером?

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

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

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

А считаешь ли ты успехом, когда ты вырастил человека до руководителя, он классно перформил, а потом берет и переходит в какую-то компанию, которую считают выше левелом, в условный Google?

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

Ты не чувствуешь грусть, обиду от того, что ты их вырастил, а они уходят дальше?

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

Искусственные впрыски дофамина, метод «камеди бадди» и деление слона на части: Петр Туголуков – о работе менеджера

А какой путь вообще человек должен пройти в IT, чтобы считать, что его карьера стала успешной, что он достиг какой-то хорошей ачивки и может считать себя состоявшимся специалистом?

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

А самого тебя известность, публичность и деньги драйвят?

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

А людей на менторство ты берешь за деньги или бесплатно?

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

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

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

Какие ты минусы видишь в распределенной работе?

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

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

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

Твоя цитата: «Занимался дизайном департаментов, перекраивал команды согласно Team Topologies». Можешь подробнее рассказать, что это – дизайн департаментов и Team Topology?

«Team Topologies» – известная книга. Насколько я знаю, она еще не переведена на русский, была только на английском выпущена. Она про то, какие виды команд существуют, как они друг с другом коммуницируют, кто какие задачи выполняет и как с помощью всего этого достичь максимума пользы в процессе разработки. И именно это мы использовали, когда меняли структуру одного из доменов, одного из департаментов. У нас было несколько практически независимых команд, которые были сосредоточены и на достижении бизнес-результата, и на достижении технического результата, то есть поддержания SwA, технического долга на нужном уровне и стабильности, в частности. Мы разделили таким образом, что часть команд стала ориентироваться только на бизнес-показатели, такие как ретеншн, количество апсейлов, входная конверсия и так далее. Часть команд стали, грубо говоря, платформой, которые только за технику, только за SwA, а бизнес-ориентированные команды стали их потребителями. Мы разделили фокус. Суммарно если смотреть, мы его, я бы сказал, увеличили, он стал менее размытым.

Пять советов по управлению своим временем?

Самое важное – голова не для того, чтобы помнить, голова для того, чтобы думать. Используйте календари. Вторая составляющая очень важная – ориентируйтесь на регулярность. Если мы возьмем, например, полчаса каждый день по работе над каким-то проектом, через неделю мы получим 3,5 часа – достаточно много. Поэтому соблюдайте регулярность, выбивайте время, его достаточно просто найти.

Ставьте цели. Даже если времени много, его можно потратить на то, что не нужно. Очень важно делать то, что вам действительно приносит ценность какую-то. Это третье.

Наверное, четвертое… Топ-5 не смогу сказать, вот четыре – да. Четвертое – это декомпозиция. Не ешьте слона целиком, ешьте слона по частям. И уже его в эти маленькие слоты вы можете засунуть и сделать, выполнить. И так можно выполнить в одного человека достаточно большой проект.

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

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

Ты практикуешь Канбан Подход, выстраиваешь работу команд, но при этом используешь физическую доску, а не просто доску в трекере. Зачем это физически визуализировать?

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

А почему ты вообще выбрал Канбан Подход и считаешь его лучше всех остальных и самым подходящим?

Канбан не является лучше всех остальных, Scrum не является лучше всех остальных, никто не является лучше всех остальных. Они как инструменты строительные и любые другие – под определенную задачу. В текущий момент мы сконцентрированы на том, чтобы регулярно доставлять ценность и уменьшать время, за которое мы это делаем. Мы немного отошли от итеративности в пользу регулярности, поэтому нам тут помогает Канбан.

Подробнее о Канбан Методе можно узнать из нашего подкаста с преподавателем и консультантом по современным методам менеджмента Алексеем Пименовым.

Цитата: «Я много занимался инженерной культурой в компании, внедрял инженерные практики». А какие именно это были практики и почему и к чему привели? Какие метрики улучшились?

Самый-самый яркий пример – это тестирование производительности. Когда я стал архитектором, не было в порядке вещей проверять, насколько система выдерживала тот или иной трафик. И несколько лет я делал так, чтобы люди знали об этом, знали, почему это действительно ценно. Где-то в кулуарах буквально несколько часов назад я рассказывал о том, как это сделать. Мы либо повторяем, повторяем, пока нам это не надоест, и только в этот момент это начнет работать, либо [используем] так называемый инцидент-baste подход, когда мы получаем инцидент либо какое-то неприятное последствие из-за того, что мы это не делаем. И люди сразу резко начинают понимать. Это своего рода принцип кнута, только пряника нет.

Искусственные впрыски дофамина, метод «камеди бадди» и деление слона на части: Петр Туголуков – о работе менеджера

Как составить идеальное резюме?

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

Но когда ты выкладываешь резюме, ты же выкладываешь его одно, то есть оно должно быть какое-то универсальное…

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

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

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

Если мы сравниваем двух людей, казалось бы, с нулевым опытом: один учился четыре года в универе на компьютерной специальности, до этого в школе участвовал в олимпиадах по программированию, второй прошел курсы «Скиллбокса». Они выходят, и у каждого ноль лет коммерческого опыта. Но мы понимаем, что между ними просто пропасть – а резюме их выглядят одинаково, кроме строчки «образование».

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

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

Да, мы сталкивались с этим. Можно сделать онлайн-анкету, я бы сказал даже не анкету, а квиз на понимание базовых концепций или опыта, который нужен именно вам, допустим, работа с докером, CI/CD и так далее. И так можно очень много процентов отсеять и оставить тех, которые релевантны вам.

Ты несколько раз во время нашего разговора упомянул свою книгу, расскажи про нее подробнее…

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

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

В книге я освещаю именно инженерные практики, которые, на мой взгляд, не покрыты на современных ресурсах типа Medium, Хабра и так далее. Мы все знаем книги, связанные с паттернами разработки – «Банда четырех», «Head first» и так далее. Но для инженерных паттернов, инженерных практик, которые связаны не только с архитектурой, но и с процессами, например, с тем же QA, нет единого ресурса, где их можно найти. Я считаю, что эти все вещи я собирал по крупицам, в том числе наступая на грабли не единожды, набивая не одну шишку, причем не только я, а и моя команда. Я считаю важно, чтобы этот весь опыт люди увидели и смогли воспользоваться им. И, судя по тому, какой фидбэк я получил, опубликовав первую главу, людям нравится. Это то, что может им помочь. Поэтому я с большим задором двигаюсь дальше.

А почему не публиковать просто постепенно, в телеграм-канале или на Хабре? Одна глава, вторая, третья…

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

Выпуск подкаста «Что‑то на программистском» с Петром Туголуковым смотрите на YouTube‑канале Doubletapp, аудиоверсию слушайте на удобной площадке.

У нас уже вышли подкасты с ML-разработчиком из Сбера Кириллом Овчинниковым, экспертом по Канбан Методу Алексеем Пименовым, ведущим подкаста о Python, нейрофизиологом-любителем и Head of Developer Relations в Evrone Григорием Петровым, а также другими спикерами.

Подписывайтесь на канал и смотрите свежие выпуски.

11
2 комментария

Прочитав все это стоит задуматься

Ответить

думать вообще следует регулярно

Ответить