Как не оказаться «Барби»/«Кеном» в комнате с «Опенгеймерами»?
Привет, Хабр! Меня зовут Антон Смирнов, я веду телеграм канал Аналитика сегодня, вот уже более 8 лет руковожу различными командами разработки и я тот самый человек, который приходит к разработчику с задачей «ну ты там сам посмотри, как лучше сделать». Эта статья выросла из моего доклада для закрытого комьюнити Skillbox IT Experts, где мы обсуждаем, как делать крутые продукты, несмотря на разный профессиональный бэкграунд.⠀
Если вы когда-либо пытались объяснить фронтендеру, зачем «нужна ещё одна итерация ради пользовательского счастья», или слышали в ответ «это не баг, а фича», — значит, вы поймёте меня без слов. В этой статье — проверенные советы, как наладить контакт с технарями, не чувствуя себя героем комикса «Гуманитарий против Машины».
У меня гуманитарное образование (международные экономические отношения) и для большинства разработчиков я мыслю скорее как гуманитарий. При этом я руковожу продуктовой командой из 28 человек и в работе некоторых из них понимаю меньше 50%. Иногда это мешает, а иногда помогает: чтобы наладить диалог с технарями, совсем не обязательно самому быть инженером. Нужно просто понимать, как они думают, и уметь переводить «между мирами» бизнеса и разработки — об этом и будет статья.
Об извечном конфликте
Откуда вообще взялась идея рассказать про диалог гуманитариев и технарей?
На самом деле, вдохновил меня мем. Тот самый — про «Опенгеймера» и «Барби», когда вся лента делилась на тех, кто за продакт-менеджеров в архитектурных дискуссиях, и тех, кто за разработчиков с огнём в глазах. Мем, конечно, уже устарел, но конфликт — абсолютно вечный:
Гуманитарии и технари по-разному смотрят на мир. Это касается не только жизни, но и вполне себе рабочих процессов. И если ты пришёл в IT из «не того лагеря» — понять, как устроен этот диалог, важно, чтобы не стать Барби/Кеном в комнате с Оппенгеймерами.
Честно говоря, поначалу я действительно примерно так себя и чувствовал. В команде у меня есть и IT-архитектор, и CTO — и когда они начинали обсуждать технические детали архитектуры, я ощущал себя буквально как Кен в исполнении Райана Гослинга, слушающий великие технические умы. Не стеснялся после таких созвонов кидать коллегам этот мем — он идеально описывал моё состояние.
Но шутки шутками, а тема серьёзная. У многих руководителей, даже с техническим бэкграундом, сейчас та же проблема. Многие из них обладают и техническим образованием и опытом разработки, но они кодили в последний раз слишком давно и не понимают актуальной проблематики.
И суть вопроса, о котором хочу поговорить — как управлять людьми и командами, в чьей работе ты не всё понимаешь. Иногда это не фигура речи — я действительно могу совсем не разбираться в деталях, особенно если это новая сфера. И даже если что-то понимаю, мой уровень техграмотности всё равно будет ниже, чем у сотрудников.
Я прошёл путь из «не-IT» в IT. По образованию я — экономист, выпускник международного экономического факультета МГИМО. В институте изучал арабский, а не Python, о чём люблю шутить. Изучение редкого и сложного языка вроде арабского, занимает столько же времени (а для кого-то и больше), сколько освоение языка программирования. Только вот применимость этих навыков на рынке — мягко говоря, разная.
Своих однокашников в IT сфере почти не встречаю. Большинство работает в консалтинге, финансах, маркетинге — но в разработке их нет. Даже с экономическим образованием в целом в индустрии немного людей, а уж конкретно из моего вуза — единицы. Хотя, конечно, я знаю разработчиков-экономистов, но чаще всего это те, у кого мышление ближе к математике.
Сначала я три года был финансовым аналитиком в «большой четвёрке» — и быстро понял, что мне скучно и не хватает креатива. Ушёл в продуктовую аналитику, проработал там три года. А последние восемь лет занимался сначала внедрением BI и DWH, из которых последние три — продуктовой разработкой аналитического продукта.
Если говорить о карьерных вехах, то две ключевые точки перехода в IT были такими:
В 2015–2016 году перешёл из финансовой аналитики в «Яндекс», тогда термин «продуктовая аналитика» был не сильно распространен, но по сути я занимался именно этим.
В 2018 году пришёл поднимать направление BI с нуля в банке «Зенит» — это был первый раз, когда я работал не в маркетинге или финансах. С тех самых пор я руковожу разработчиками в разных ролях, например,в своей компании. А ещё был менеджером в IT-департаменте, директором по аналитике, который занимается в том числе и IT-процессами, руководил проектным офисом.
Важно отметить, что на возможность перехода в IT сильно повлиял мой предпринимательский опыт. Он стал тем самым фактором, который помог «перепрыгнуть» в IT-сферу, хотя ни в «Яндексе», ни в банке «Зенит» путь из финансового анализа в продуктовую аналитику, а затем в корпоративный BI, нельзя назвать типичным.
Но к моменту перехода в «Яндекс» у меня уже было собственное бюро переводов — я сам настраивал маркетинговые каналы и неплохо понимал, чем занимается продуктовый аналитик. А перед тем, как попасть в банк «Зенит», уже полтора года внедрял BI-проекты в своей компании «Конгру». Именно этот опыт я и продавал на собеседовании.
Тем не менее, фактор удачи в этих переходах был не менее важен, не всё можно заранее спланировать.
Мои роли в IT с самого начала были скорее управленческими. Даже на старте я не писал код — по крайней мере, не было такого, чтобы это входило в мои прямые обязанности. Если не считать этапа продуктового аналитика (а в моём случае это был скорее BI, Excel и DAX, чем код на Python), то в разработку в привычном смысле я не заходил.
Почему эта тема в целом важна — и лично для меня, и для таких же «гуманитариев»? Потому что стратегически выгоднее работать в растущих отраслях. Важно искать те рынки, где у старшего поколения нет большого преимущества. В моём случае, когда я начинал карьеру в начале 2010-х в финансовом анализе, было уже очевидно: рынок насыщен, карьерных треков мало. Финансовыми директорами уже стали те, кто работал в «большой четверке» еще в 90-х, директорами департаментов становились в 2000-х, а в 2010-х — максимум, на что ты мог претендовать с опытом 5+ лет, — это начальник отдела. Сейчас и таких возможностей практически нет. «Exit opportunities» почти отсутствуют, особенно если речь идёт о сильном росте дохода.
Мне и самому не слишком нравилась работа в финансах, но я бы, честно, мог и потерпеть ради понятных перспектив. Проблема была в другом: их тоже особо не было. Поэтому мой принцип сработал чётко — «куда рынок, туда и я». IT в десятые как раз был таким растущим рынком, и я смог зайти туда через аналитику данных — потому что, во-первых, это ближе мне по типу мышления, а во-вторых, я понимал, какую ценность могу дать этому направлению.
Продакт в современном IT-мире
В классических моделях лидерства такое раньше случалось редко: руководителем чаще становился самый опытный сотрудник в конкретной профессии ну или, как минимум, владеющей мат частью на экспертном уровне сотрудник с хорошими навыками общения. Но в современном IT — норма, что продакт или РП может не разбираться в технологиях на должном уровне, а это создаёт барьеры в коммуникации, ожиданиях, взаимопонимании. И я попробую рассказать, как с этим работать — как заслужить авторитет, не будучи экспертом в области.
Со стороны разработчиков тоже важно понимать, зачем обсуждать такие темы. Речь ведь не только о руководителях. Это может быть заказчик, product owner, менеджер — кто угодно, чья работа влияет на вашу, но кто не говорит с вами на одном языке и не может физически понять вашу техническую проблематику.
Если говорить именно о руководстве, существует три классических модели лидерства:
Быть самым сильным специалистом в команде — тебя уважают за экспертность.
Управлять за счёт выстроенных процессов — опираться на систему.
Вдохновлять и задавать стратегию — вести за собой, даже не зная всех деталей.
Когда руководитель — гуманитарий, первый путь сразу отпадает. Остаются процессы и стратегия. Управление через процессы — рабочая модель, но есть нюанс: если у тебя нет технической экспертизы, ты не можешь проконтролировать глубину технических решений. Тимлиды могут перезакладываться по срокам, давать не амбициозные оценки и ты не распознаешь этого. А значит, велика вероятность, что команда будет работать медленно, не потому что саботаж, а просто «на всякий случай». А задача руководителя — наоборот: создавать условия, в которых команда выкладывается по максимуму, без выгорания, но и без самозамедления.
Поэтому самый адекватный путь в таких условиях — это стратегия и вдохновение. Задача — не «контролировать», а вовлекать. Чтобы люди понимали, зачем они пишут этот код, как он влияет на бизнес и пользователей. Чтобы было ощущение, что это их продукт, их вклад и их рост.
Это может звучать банально, но на рынке огромное количество команд, которые работают «по инерции», не видят ни смысла, ни перспектив. В такой ситуации твоя задача — зажечь, увлечь, донести пользу проекта, быть мостом между командой и бизнесом. Объяснять, зачем это нужно, давать понятный фидбэк от себя и заказчиков. И тогда — даже без глубокого технического понимания — ты сможешь быть эффективным лидером.
Лайфхаки для гуманитария-руководителя технической командой
Не притворяться технарём. Одна из распространённых ошибок — делать вид, будто ты понимаешь технические детали на уровне команды. Я всегда прямо говорю, когда чего-то не понимаю, и не стесняюсь заранее предупредить: «Скорее всего, я не вникну в детали этого обсуждения». И добавляю: «Если вы не договоритесь и решение придётся принимать мне — я его приму, но оно может быть не лучшим. Реализовывать его всё равно вам».
Классика: споры между архитектором и СТО, или тимлидами фронта и бэка. Я могу разобраться до определённого уровня, посоветоваться с кем-то, но не буду ощущать эту задачу «на кончиках пальцев». Поэтому логика простая: если не договоритесь — будет решение «сверху», и оно, возможно, вам не понравится. Значит, лучше договориться без моего вмешательства или дать два варианта со своими плюсами и минусами.
Мыслить как предприниматель. В бизнесе есть понятная модель: один партнёр отвечает за продукт и продажи, второй отвечает за техническую часть. Это нормальная схема, когда ты полностью отдаёшь ответственность за технику, а сам отвечаешь за стратегию, продажи и приоритеты. Да, есть риск ошибиться в партнёре — у меня такое было, но в целом я не боюсь делегировать всё техническое. Главное — чтобы команда была готова нести за это ответственность и давать результат.
Создать ценность. Вопрос, который может возникнуть в команде: а зачем нам вообще такой руководитель? Зачем тот, кто не кодит, не лезет в детали и, в целом, «ничего не делает»? Ответ — в создании ценности, которую команда сама признаёт. Не формально, не «потому что начальник сказал», а по-настоящему. Это не про давление — оно в IT работает плохо. Зачастую, если давить на команду, то результат станет ещё хуже. А вот чёткая стратегия, понятные приоритеты, ясность, для кого, что и зачем мы делаем — это ценность, которую уважают.
Не бояться роли переводчика. Нужно самому понимать свою ценность. Я не лезу в код, но я связующее звено между бизнесом и разработкой. Это важно. Если бы заказчики и разработчики могли понимать друг друга напрямую, и делать это комфортно и эффективно — моя роль была бы не нужна. Но это утопия. Инженер, который умеет и любит общаться — редкость, как и заказчик, который можем сам чётко сформулировать, что именно и для какой цели ему нужно. Поэтому вся эта прослойка в виде ПО, РП и т.д. — не бюрократия, а необходимость.
Я называю это «поженить бизнес и технологии». Потому что, если убрать этого связующего, кажется, что станет проще. Но на практике нет: заказчики не могут корректно формулировать требования, а разработчики — управлять ожиданиями. Особенно если речь о топ-менеджменте крупной компании. Там нужен человек, который умеет переводить с «бизнесового» на «технический» язык и обратно. И это критично.
Обеспечивать обратную связь. Если ты не технарь, твоя зона ответственности — объяснить, зачем мы что-то делаем. И делать это не разово, а системно. Без регулярного фидбэка мотивация команды всё равно будет проседать.
Управлять через процессы. Даже если ты не кодишь, никто не отменял планирование, спринты, релизные планы. Важно уметь синхронизироваться с тимлидами, где-то продавить сроки, где-то услышать. Я, например, считаю, что амбициозные оценки лучше, даже если дедлайны иногда будут срываться. Перезакладываться и работать в расслабленном темпе — хуже. Конечно, бывают исключения — например, в проектах с госучастием, где срыв сроков равен максимальным рискам. Но в бизнесе — наоборот: смелее сроки, выше темп — лучше результат.
Подстраиваться под команду. Хорошие инженеры — часто интроверты и не самые адаптивные люди. И это ок. А вот я, как руководитель, адаптироваться могу и считаю это своей профессиональной обязанностью. Не стоит пытаться передавить команду ради самоутверждения — это выжигает мотивацию. Директивный стиль в IT работает слабо. Где-то он необходим, но чаще — вреден. Чем больше гибкости проявляешь, тем эффективнее работа.
Как мотивировать команду
Ключевое — чтобы люди ощущали результат своей работы. Не просто крутились в процессах, а понимали, зачем всё это и к чему привело.
1. Показать результат — и получить фидбэк
Мы регулярно проводим демо:
Внутри команды — каждый показывает, что получилось.
Фокус работы идет на конечный результат, в зачет идут только полностью завершенный и готовый к использованию функционал.
Если всё хорошо, то на встречу я иду не один и прямо прошу заказчика сказать команде, что они молодцы. Если всё не очень, то на встречу я скорее пойду один, максимум возьму тимлида для ответов на вопросы по технической части
Это важная часть — не просто доделать фичу, а услышать: «Мы это запустили, это полезно».
2. Публичная похвала, приватная критика
Простое правило: ругать — только наедине, никогда тимлида не ругать при команде, например. Хвалить — максимально публично. Если кто-то сделал крутую штуку — то сам рассказываю, почему она важна, или это делает заказчик или команда.
3. Неформальное взаимодействие
Раз в квартал — тимбилдинги, где делаем что-то вне процесса: игры, обсуждения идей, внутрикомандные инициативы. Это не про «пиццу и пледы», а про укрепление связей.
С ключевыми сотрудниками — неформальное общение: спокойно сходить в ресторан, поговорить без галстуков, чтобы чувствовалось, что мы команда, а не вертикаль.
Всё это помогает превратить команду в единый механизм, где все движутся в одном направлении. Только если команда понимает, в какую сторону развивается продукт и почему именно так, то сотрудники начинают работать эффективнее. Тогда включённость, обратная связь и мотивация вырастают органично — без давления и искусственных стимулов.
Вместо вывода
Хочу закончить статью мыслью: далеко не всегда самый эффективный руководитель технической команды — сам технарь. Если роль требует решения большого количества нелинейных вопросов, например, договориться с заказчиком, «продать» идею, сориентироваться в ситуации высокой неопределенности, создать стратегию развития и прочее, то более эффективным руководителем, по логике, будет гуманитарий даже с очень базовым техническим бекграундом. И это необходимо понимать обеим сторонам:)
