Лекцию на тему этой статьи я читал для студентов ИРИТ-РтФ УрФУ — материал особенно полезен начинающим специалистам, перед которыми стоит выбор, как строить карьеру. Поговорим о том, что такое продуктовая команда и как она связана с потенциальной карьерой, почему нужно думать про продукт, какие в продукте есть источники компетенции и какие роли там можно играть.
В общем, это размышление на тему «Что бы я делал, будь мне сегодня 20, если бы я знал то, что знаю сейчас». Ведь все, что я говорю, — это выводы из моего опыта. С 1997 года я занимаюсь интернетом и за это время играл разные роли и их комбинации: дизайнера, UX-инженера, разных менеджеров, арт-директора, директора по продукту и дольше всего — директора.
В бэкграунде я специалист по пользовательскому опыту, но достаточно давно не работаю руками, а командую другими людьми: программистами, дизайнерами, менеджерами. Моя область экспертизы — это клиентский опыт и управление продуктами.
Прежде чем рассказывать про карьерные пути, мы немного поговорим про продукт, потому что в области автоматизации бизнеса, в которой мы работаем и про которую рассказываем, в России в последние 10 лет, а в мире, наверное, в последние 40, произошло большое изменение — развился и завоевал популярность продуктовый подход.
Первое, что мы представляем при слове продукты, — это то, что есть в магазинах: например, крафтовый сыр или автомобили. Но я имею в виду немного другое — цифровые продукты: поисковые сервисы, VR-игры или другой опыт взаимодействия человека и машины.
Цифровые продукты — это не разовая деятельность, а постоянный процесс изменения поведения клиентов, в ходе которого они получают ценность. То есть от взаимодействия с продуктом в жизни клиентов происходит что-то хорошее, они это замечают и готовы за это платить.
В общем смысле продукты для тех, кто за них платит, — это ценность, а для тех, кто их продает, — это процесс создания ценности и источник прибыли.
До продуктового подхода к развитию бизнеса большинство из нас придерживалось проектного подхода. Проект — это мероприятие по изменению чего-либо, и проектный подход ориентирован на то, чтобы запускать какие-то изменения в бизнесе. Изменения происходят — и проекты заканчиваются.
А с продуктами наоборот — их создатели стараются, чтобы они не заканчивались и приносили все больше прибыли.
Не поймите меня неправильно. Проектный менеджмент нужен. И в бизнесе есть задачи, которые строятся от дедлайна. Их просто нельзя сделать в продуктовом подходе, и приходится делать в проектном.
Продуктовый подход добавил к проектному фокус на постоянное управляемое развитие. Его основные идеи:
Продуктовый подход — это комбинация трех идей: как с помощью постепенных изменений и опираясь на данные быстро вырастить бизнес. Думаю, в ближайшие минимум 10 лет этот подход будет считаться лучшей практикой управления и автоматизации цифровых бизнесов.
Я провел много собеседований и заметил, что в основном инженеры всё равно какой породы — программисты, дизайнеры, тестировщики — имеют два убеждения по поводу карьеры.
Во-первых, 90% на вопрос «Какую работу вы хотите?» отвечают «Интересную», и каждый под этим словом понимает что-то свое. (Но об этом позже.)
А во-вторых, для новичков очень важная ценность — рост профессионального скилла. Большинство фокусируется на индивидуальных навыках. И это здорово, что люди, которые приходят в отрасль, хотят расти. Если инженер не хочет прокачивать свои навыки постоянно, он выбрал не ту профессию. Но гораздо важнее для компании не это: бизнес интересуют не атомарные таланты, а люди, способные образовывать социальные молекулы, которые объединяются в эффективные цепочки и создают ценность.
Чтобы добиться своих карьерных целей, нужно понимать не только то, какие скиллы качать, а еще и каким способом и с какими людьми хочется или придется образовывать эффективные связки. То есть нужно уметь стать частью продуктовой команды, а не просто скиллованным спецом. А тем, кто думает о карьере руководителя, нужно уметь такую команду создавать.
Уметь быть полезной частью группы важно не только инженерам. Это вообще основной фактор полезности в любых задачах, для которых нужны усилия нескольких человек. Если вы играли в командные компьютерные игры, думаю, вы согласитесь: важно, чтобы сокомандники всегда делали что-то уместное и могли подхватить в нужный момент. У меня, например, такого опыта было достаточно и в пешем туризме. Важно чувствовать соседа, иметь возможность переложить на него часть ответственности, быть уверенным, что в критический момент он сделает именно то, что вы от него ожидаете. Важно уметь шерить сознание на «того парня». И тогда вы становитесь коллективным мозгом, организмом, сделанным из многих людей.
И это в еще большей степени важно для бизнеса. Команда, которая делает продукт, должна уметь:
Если подразделение, которое занимается автоматизацией, этими навыками не обладает, то командой оно не является — это просто россыпь людей. И это плохо как для сотрудников — всех тошнит друг от друга, и кажется, что все какие-то дураки, потому что делают не то, что нужно (они, скорее всего, не глупые, просто ваши ожидания от них не совпадают с реальностью), так и для компании — все процессы очень медленные, все работают из-под палки, решения банальные и компромиссные, только по регламенту, потому что люди друг друга не поддерживают.
Команда продукта — главный драйвер продуктового бизнеса.
Это профессионалы, которые командуют сами собой и у которых компания покупает их индивидуальную компетенцию. Специалистам в информационных технологиях повезло. Я часто говорю, что ИТ — лучший из миров, потому что тут работают интересные и умные люди и им доступно достаточно много карьерных путей, которые позволяют играть индивидуальные роли: оставаться специалистами и никем не командовать, но при этом наращивать свою ценность для компании. Важно только найти подходящую специализацию.
Верный способ понять, подходит ли вам специализация, ответить на вопрос, способны ли вы в ней попасть в состояние потока.
Например, я в бэкграунде — UX-инженер и, честно сказать, разрабатывать дизайн мне нравится гораздо больше, чем принимать решения, взаимодействовать с партнерами и разбираться с проблемами людей. И вот, когда вышла Midjourney — нейросеть, создающая изображения по текстовым описаниям, я получил повод нырнуть в поток — это когда начинаешь что-то делать, а потом смотришь на часы и думаешь: «О, боже мой, наступило послезавтра, а я и не заметил». Но, в отличие от подобной ситуации с компьютерной игрой или сериалом, когда выныриваешь из потока, обнаруживаешь, что чему-то научился и создал что-то, чем можно хвастаться перед коллегами. Такие инженерные радости и заставляют оставаться специалистами.
Хотя карьера узкого специалиста ничем не плоха, обычно под ростом в компании подразумевается движение по лестнице управленцев: по мере того, как у человека становится больше опыта, на него падает больше ответственности, и он начинает управлять не только собой. Другими словами, он получает роль менеджера, а потом и руководителя.
Тут много слов, начинающихся с буквы C, что значит сhief и указывает на C-level — самый высокий уровень должностей, который предполагает ответственность за какую-то область целиком. Обычно корпорация считает, что получить роль С-уровня — это то, к чему должен стремиться каждый, но, как, наверное, вы уже поняли из текста, это далеко не всегда правда. У руководителей свои радости и проблемы, у специалистов — свои.
К этой группе я в какой-то степени причисляю и себя, потому что у меня много разных компетенций. Правда, это значит, что моя родная компетенция — UX-дизайн — от этого страдает. Если бы я занимался только UX-дизайном, я бы сейчас был более глубоким и ценным UX-спецом, чем я есть. Этим я расплачиваюсь за то, что работаю руководителем, а не специалистом. Но зато я занимаюсь много чем еще, у меня широкий набор компетенций.
Чем моложе компания, тем больше аргументов за то, чтобы делать ставку на сверхуниверсалов. Потому что, когда команда состоит примерно из одного человека, хорошо, если он может сделать всё сам: выбрать место для бизнеса, проверить бизнес-модель, найти клиентов, разработать дизайн, запрограммировать, протестировать, внедрить. И я таких людей знаю — они очень ценные.
Но часто оказывается, что сверхуниверсалы не умеют ни с кем работать, не могут образовывать молекулы. Это значит, что для них есть применение только на том этапе жизни компании, когда в ней еще нет коллектива.
Когда я рассказываю про продуктовую команду студентам-айтишникам, то часто слышу от них вопрос: «Мы же программисты, зачем нам все остальные роли?». И вот пришло время разобраться, что такое интересная работа. Я собрал список из ответов, которые получал от студентов и кандидатов, и из собственных размышлений.
Итак, интересная работа:
Список у каждого может быть свой.
Что значит интересная работа — понятно. Но как такую получить?
Чтобы работа была интересной, нужно влиять на то, какие задачи вам достаются. А для этого нужно, чтобы ваш голос слышали и чтобы с вами считались.
С вами будут считаться, если вы ценный специалист, которого страшно потерять и на которого можно опереться, то есть вы:
А если вы не найдете себе команду, для которой будете ценным, вы не сможете ни на что влиять, и то, интересная у вас работа или неинтересная, будет результатом случайности: повезло или не повезло.
Я подсветил роли, для которых IT-бэкграунд очень важен:
В колонке руководителей такой бэкграунд важен для каждой из ролей, потому что, если у руководителя бизнеса, который опирается на автоматизацию, есть IT-бэкграунд, то шансы на то, что компании удастся создать продукт, который будет быстро расти и захватит большие рынки, на порядки выше.
Большинство руководителей продуктов вышли или из программистов, или из аналитиков. Таких, как я, кто вышел из дизайнеров, процентов 10 — это достаточно редкая мутация. Но еще меньше хороших CPO, которые изначально были просто менеджерами и не имели за душой опыта работы руками. То же самое с маркетингом. Но маркетинг — это отдельная хардовая квалификация.
Есть два пути стать «IT + что-то еще»:1) сначала стать айтишником, а потом выбрать для себя какие-то дополнительные менеджерско руководительские скиллы;2) сначала стать специалистом в какой-то другой области, а потом понять: «Господи, теперь мне надо как-то разобраться в IT».Первый путь сильно органичнее и проще.
Я не подсветил только две специальности: исследователи и продавцы. Исследователи, в первую очередь те, которые изучают клиентский опыт, играют очень важную роль в развитии продуктов. Они собирают первичную информацию о том, как ведут себя люди и бизнесы, и делают на основании этого выводы. И большинство из них в прошлом — продавцы, ведь, чтобы исследовать людей, надо хотеть и уметь с ними говорить. А еще уметь преодолевать социальный барьер — условно, звонить по телефону и не стесняться.
Тем не менее, если исследователь или продавец в прошлом айтишники, они тоже будут более ценными, просто для них это не экстремально важно.
У меня есть сын, ему 23, в прошлом году он работал в стартапе по производству грузоподъемных электровеликов. Директор этого стартапа — инженер, а начинал он с того, что торговал всяким персональным электротранспортом. И он хороший CEO для этого этапа бизнеса, потому что умеет и программировать, и торговать.
Или обратный пример — основатель селф-паблишинг-платформы Rideró, в которой я сооснователь. Он нашел источник технической компетенции снаружи, потому что сам программировать не умел. В итоге из-за того, что он такой источник нашел, у нас получился продукт. Но из-за того, что он сам не программист, вижен компании построен не столько вокруг технологии, сколько вокруг сервиса.
Я тоже не программист, и это меня изрядно ограничивает. Я не могу сам придумывать программную архитектуру. Я могу найти нишу, сделать изобретение, спроектировать пользовательский опыт, но когда начну думать про то, какими средствами это делать, мне нужен будет мозг другого человека. Мои решения будут ограничены известной мне лучшей практикой — я не смогу придумать что-то принципиально новое в программировании.
Но у руководителя есть специальная компетенция — он умеет командовать «через голову», то есть подчиненными, которые занимаются чем-то, в чем он не понимает. Чтобы обрести эту компетенцию, нужно научиться опираться на компетенции других, научиться думать другими людьми.
Я нарисовал график развития карьеры и отметил на нем точку, в которой обычно всё начинается.
Вертикальная ось показывает широту компетенций: узкий специалист разбирается в чем-то одном, а универсал — во многом, например, он не только умеет программировать физические движки, но и знаком с современными CG-подходами для геймдева, знает, как проектировать вокруг этого опыт. Повторюсь: чем крупнее компания, тем больше в ней ролей для узких специалистов. И наоборот.
Горизонтальная ось показывает широту ответственности: сотрудник отвечает только за себя, а руководитель — за многих подчиненных.
Практически любая карьера начинается с того, что человек разбирается в чем-то одном и отвечает только за себя.
Как я уже говорил, развиваться в рамках левого нижнего квадрата — тоже хорошая стратегия. Но естественный ток карьерных путей всех подталкивает вправо наверх — к руководителям-универсалам.
Любой бизнес лимитирован временем людей, которые способны принимать решения. Поэтому если кто-нибудь в компании показывает, что может принимать решения и нести ответственность за свои слова, люди его слушаются, и с помощью других он может добиваться предсказуемых результатов — компания будет пытаться сделать из него руководителя. А значит, человеку придется погружаться в соседние контексты, и это будет делать из него универсала.
На схеме — обобщенная карьерная лесенка: на старте есть разные специализации, а дальше начинаются линейки ответственности. Стажеры, джуны, мидлы и сеньоры отличаются друг от друга тем, насколько большой кусок работы им можно поручить. Но сеньор — это еще и источник компетенции, именно он растит джунов, делится с ними опытом и дает обратную связь.
Сотрудников, которые доходят до сеньора, компания заинтересована направлять в соседние специализации. Самая логичная линейка — сеньор программист становится тимлидом, а затем CTO. Но на самом деле и QA-лиды, и проджект-менеджеры, и продакты отлично получаются из людей, которые начинали как программисты.
Развиваться в сторону одной из линеек можно и на более ранних этапах. Например, если джун хочет быть проджектом, то ему уже можно наблюдать, как ведет себя менеджер, и брать какие-то его таски на себя. И когда джун доберется до мидла, то пойдет не в сеньор программиста, а в другую линейку.
Розовые на схеме — это места, которые можно занимать, оставаясь специалистом. А синие — это роли с большим объемом ответственности, которые можно получить, если пойти выше по лесенке.
Из тестировщиков получаются QA, из разработчиков — сначала тимлиды, потом технические директора, из аналитиков — проджекты, из исследователей — продакты. (На самом деле продакты получаются и из аналитиков тоже.) Из продактов получаются директора продуктов, из маркетологов — директора по маркетингу.
А CEO получается произвольно, но компании сильно повезет, если он придет из одной из трех C-level-линеек. Если CEO в прошлом СTO, значит, у компании будет сильная технология, она сможет на нее опираться. Если, как в моем случае, директор умеет командовать продуктами, то у компании будет сильная продуктовая компетенция — она будет уметь создавать продукты. Если директор понимает в маркетинге, тогда сильной стороной будет привлечение клиентов с помощью внешних каналов.
Директор может прийти и не из этих линеек, то есть не из IT. Например, в прошлом он может быть продавцом или снабженцем. Тогда у компании, скорее всего, не будет сильной IT-культуры, и интересных карьерных путей для айтишников в ней будет меньше.
Тем, кто любит синицу в руках, нужно идти в корпорации. Там больше порядка, больше условий для комфортной работы. Стартапы — для авантюрных, для тех, кто любит риск, кому меньше важен комфорт и больше важна личная значимость.
В корпорациях есть позиции для узких специалистов и заранее понятно, что делать. В стартапах команда зачастую состоит человек из четырех, поэтому все делают всё, и быть узким специалистом сложно. А еще стажерских вакансий в стартапах обычно нет — для этого в компании должен быть свободный сеньор, который готов стажеров выращивать.
В корпорации можно получать стабильную зарплату, зато в стартапе больше шансов заработать по-настоящему большие деньги. И в С-level прийти гораздо проще, когда вас, условно, четверо — в небольших компаниях на визитках у 80% штата есть слово «директор».
В стартап можно попасть даже совсем без квалификации, но нужно быть готовым тащить на себе много ответственности. Есть только два пути: или выплыть, или сдохнуть.
Есть пять компетенций, без которых бизнесу, строящемуся вокруг автоматизации, будет очень плохо.
1. Предприниматель. Если нет предпринимателя, можно просто не вставать. Предприниматель — это человек, кому приходит идея изменить мир и на этом заработать. И в первые годы жизни компании он — главный, потому что:
2. Технология. Если компания хочет занять свою долю на рынке, она неизбежно должна обеспечить лучшие в своей нише процессы. То есть процессы с самой низкой себестоимостью на единицу доставленной ценности. И в 80% это предполагает автоматизацию, поэтому так важен человек, который возглавит разработку.
3. Отраслевая компетенция. У каждого рынка это что-то свое: если мы делаем технологический стартап в области фармакологии, то должны понимать, как разрабатывать и продавать лекарства, если в строительстве — как строить и продавать дома, если в геймдеве — должны уметь создавать впечатляющий геймплей.
Я как трекер веду стартап, который занимается авторынком. Создатели — команда айтишников, никто из них не командовал автосалоном, не продавал машины. Они нашли рынок и научились на нем зарабатывать, но, чтобы расти дальше, им нужен кто-то с отраслевой компетенцией. Можно, конечно, научиться всему самим, но обычно бизнес просто берет в команду кого-нибудь, у кого эта компетенция уже есть — человека с опытом работы в отрасли.
4. Продажи. В отличие от предпринимателя, продавцы не придумывают, что продавать, — они оптимизируют способы продажи. Добиваются, чтобы сделок было больше и доставались они дешевле.
Раньше управление продажами было достаточно далекой от IT областью, пока не возникли стратегии продаж, опирающиеся на анализ данных и автоматизацию, то есть продажи через разные интерфейсы. В этом случае продавец командует не людьми, а комбинацией из продукта и маркетинга. То есть ставит задачи для команды разработчиков и маркетологов. И хоть из айтишников редко получаются руководители продаж, но экспертиза в управлении продажами от разработки требуется достаточно глубокая.
5. Маркетинг. В России под словом маркетинг обычно понимается performance-маркетинг — привлечение трафика с оплатой за действие так, чтобы он эффективно конвертировался в клиентов. Другими словами, это маркетинг на основе данных с быстрым наглядным результатом.
Маркетолог сегодня — это человек, который понимает, как работать в большой куче специфических программных продуктов вроде управления рекламными кампаниями в социальных сетях и поиске. Но очень часто эффективная маркетинговая стратегия строится на замене ручного труда автоматизацией. И тут есть гора задач для data science и машинного обучения, не говоря уже просто об интеграции.
В каждом конкретном случае любая из этих компетенций может быть критической — без которой вообще ничего не получится, но чаще всего критическими являются предпринимательская и техническая компетенции. По-хорошему, аутсорсить можно только некритические — а источник критических нужно иметь внутри компании.
Источник компетенции — первый человек в компании, который умеет командовать такими, как он. Быть источником компетенции значит добиваться бизнес-целей с помощью этого навыка, а также формировать эту компетенцию внутри компании — уметь нанимать таких людей, онбордить их, учить, управлять ими и в конечном итоге увольнять.
Без источника компетенции стартовать ее использование очень дорого и рискованно. Но найти источник для каждой из пяти линеек карьерной лестницы — всегда очень сложно. Большая боль всей отрасли — найти CTO. То же самое с хорошим директором по продукту и с сильным предпринимателем.
Когда в 1997 году я начинал заниматься интернетом, источников знания и доступа к хорошей практике было мало, и мы делали страшную ерунду. А сейчас всего этого много. И пока вы в начале карьеры, то рискуете только личным временем, поэтому можете взять и попробовать сделать свой продукт. С первого раза, конечно, не получится, но поймете вы многое.
Вставайте на грабли, пока они бьют не больно, а вы рискуете только временем.
Если вы хотите узнать подробности про отдельные роли: кто за что отвечает, что лучше всего умеет и чем интересным занимается — скачивайте мою презентацию. В ней я разобрал роли инвестора, предпринимателя/CEO, руководителя разработки, продакта, проджект-менеджера, разработчика, DevOps, UX-инженера/дизайнера, QA, исследователя и маркетолога.
А если вы уже во всем разобрались и готовы начать свой путь в IT-компании, отправьте отклик на нашу почту [email protected] — у нас бывают вакансии для любого опыта, в том числе стажерские позиции.