Pull to refresh

От кода до roadmap: как я перешел из разработки в управление продуктом

Reading time 13 min
Views 25K
Во многих IT-компаниях продуктовыми менеджерами становятся бывшие программисты. Это логично, ведь они понимают процесс разработки «изнутри». Но даже они совершают ошибки из-за непонимания процессов, отсутствия навыков управления и незнания инструментов. Так первое время было и со мной, поэтому сегодня я расскажу о своем опыте перехода из разработчиков в ПМы, приятных открытиях и косяках, а также о том, что помогло облегчить такую «карьерную трансформацию». Чтобы не солировать, дополню историю цитатами моих друзей и коллег по отрасли.

Сразу предупрежу: продукт, над которым сейчас работаю, пока под NDA, поэтому некоторые имена и детали оставил «за кадром».

Как меня занесло в ПМ
Для начала — немного о том, почему я сменил амплуа. Меня зовут Артур, я работаю (и работал) в IoT-стартапе, разрабатывающем платформу и создающем отраслевые решения на основе интернета вещей в формате black label, — сначала ведущим разработчиком, а затем продуктовым менеджером. Интернет вещей — область новая, нестабильная, конкурентный рынок только формируется, потенциальные клиенты пока не очень понимают, что это и зачем это нужно, технологии меняются... Логично, что стартапы тоже «лихорадит», у них регулярно меняются структура, кадровый состав и продуктовый портфель.
Вот в этом самом портфеле нашей компании и завалялся один незавершенный продуктовый проект. Не самый сложный в реализации и понятный клиентам (будущая любовь наших продажников), имеющий потенциально широкое применение и способный быстро принести хорошую прибыль. Но реализация шла очень и очень вяло (силы уходили на ключевые задачи), в воздухе минимум полгода висел вопрос «а когда мы им займемся?». После небольшого внутреннего кризиса решили назначить отдельного ответственного за этот продукт и выделить на него ресурсы.
Почему выбор пал на меня? Во-первых, я регулярно раздражал руководителей вопросами «а что у нас с проектом X?» и «а когда мы займемся проектом X?», чем завоевал себе репутацию «того, кому больше всех надо» (как оказалось позже, самую правильную репутацию для проджектов и продактов). Во-вторых, продукт находится в предметной области, в которой я разбираюсь, и я бы все равно оказался в команде реализации, но не стал бы в ней главным и незаменимым.
Вообще, обычно разработчики переходят в продакты, потому что в будущем не видят себя программистами, но не хотят покидать привычную IT-индустрию. Вторая популярная причина — профессиональное выгорание, усталость от кода.
Почему решился я? Не то чтобы я «выгорел» или мне надоело кодить — я люблю программирование, но не настолько, чтобы болезненно переживать расставание с ним. Мне сразу сказали, что работать буду в тестовом режиме и в любой момент могу «соскочить» обратно — значит, я ничем не рискую и ничего не теряю. Это раз.
Во-вторых, IoT — сфера специфическая, поэтому, соглашаясь, я уберег себя и коллег от необходимости долго «погружать» стороннего менеджера в рынок и тормозить проект. И третье — у меня в голове была еще не до конца оформившаяся идея по созданию собственного стартапа, поэтому я расценил происходящее как хороший шанс попробовать себя в роли СЕО «на минималках».
В первые дни казалось, что на меня обрушилось больше информации, чем за все предыдущие годы работы (это даже с учетом базы разработчика). Но со временем я выработал новый рабочий режим и освоился. Хотя за эти девять месяцев и совершил пару променадов по граблям. И вот какие выводы я для себя сделал.
Нужно принять как факт, что...
1. Планы можно и нужно корректировать. Это нормально
Не знаю, почему, но в нашем поколении все еще сидит сталинское «план — это что-то неизменное, высеченное в камне». На первое свое собрание в качестве ПМ я принес красивый план реализации с прописанными сроками, дедлайнами, ролями каждого... Уже через месяц этот план разбился вдребезги.
Намеченные подрядчики ушли куда-то в подполье. На что-то не дали бюджета. Один из ключевых разработчиков попал на две недели в больницу, второй из-за того, что ему приходилось работать за двоих, затягивал сроки. Да и я сам полторы недели вникал в то, с чем думал разобраться за три дня. И, кстати, управился бы за неделю, если бы не тратил много времени на самобичевание из-за того, что ничего не успеваю.
Первое впечатление от работы — неожиданно много проблем с определением сроков по задачам. Не в том плане, что программист не может мне сказать, сколько времени займет выполнение задачи, обычно оценка является более-менее корректной. Но появляются разнообразные внешние факторы, которые сложно учитывать при попытке оценить срок выполнения проекта. Это то, что и раньше часто происходило, но чего я, будучи разработчиком и работая в той же компании, не замечал.
Дмитрий, в прошлом суровый JSник, завсегдатай всех профильных конф, — теперь ПМ в IoT-компании.
Отдельный плюс позиции продакта — возможность самому выбирать и внедрять систему планирования, если не в масштабах всей компании, то хотя бы внутри команды. Главное — не зацикливаться на чем-то одном и не бояться пробовать новое.
Сейчас для планирования и контроля работы по проектам мы используем систему ELMA Проекты+, которая является частью более глобальной системы управления бизнес-процессами ELMA BPM.
За счет встроенной BPM для каждого проекта можно создать единое инфополе для взаимодействия заказчиков (у нас это, в основном, отделы коммерции, маркетинга, аналитики) и тех, кто их хотелки воплощает в жизнь. Это очень выручает в сложных проектах, где в работу нужно включаться обеим сторонам, а цели мирить с возможностями. В системе есть то, без чего невозможна работа продакта: управление календарем, ресурсами проекта, комментирование задач с сохранением истории. А еще прикольная фича — «проектный конвейер». Она помогает автоматизировать повторные этапы работы (например, обновление визуальных элементов продукта). В том же Trello для этого приходится создавать шаблоны задач.
2. Команда — ваше все, хоть вы сами ее и не собираете
Продакт — все-таки не СЕО, он не собирает команду под себя, поэтому нужно учиться работать с тем коллективом, какой есть. Например, руководитель отдела продаж у нас любил «солировать» и мог вдохновенно толкать получасовые речи о космических кораблях, которые бороздят Большой театр, пока тимлиды отмалчивались, вздыхали и тупили в телефонах. В итоге коэффициент полезности совещаний был объективно низким, все выходили уставшими и с ощущением зря потраченного времени.
Я пробовал собирать встречи только с разработчиками, но они стали уходить в интересные исключительно им дебри, а то, что реально важно для пользователей и для рынка, оставалось в головах продажников и маркетологов.
Помог случай. Однажды я пропускал планерку и попросил того самого руководителя отдела продаж вести протокол. Как мне после передали, ему роли «вице-председателя» оказалось достаточно для самовыражения, и по своей части он все проговорил коротко и ясно. С тех пор я часто прошу его вести протоколы — и лишних речей меньше, и я сам могу качественно модерировать встречу.
Мне, кстати, неудобно самому вести протокол, меня это очень отвлекает. Хотя человеку многозадачному и более расфокусированному это, наверное, помогает концентрироваться.
Продакт — человек на пересечении всех и всего, при этом объем требуемых от него знаний зависит от того, кто еще есть в команде и насколько он компетентен. Контроль разработки может быть распределен между продактом и проджектом, выбор стратегии и позиционирования — между продактом и маркетологом (или бренд-стратегом), а разработкой дорожной карты может заниматься как продакт самолично, так и продакт в связке с СЕО, если последний является инициатором, а не просто контролирующим лицом. Общайтесь, реально много общайтесь и чертите границы зон ответственности и доверия.
В свое время удивил тот факт, что у разработчиков и менеджеров часто не совпадает взгляд на ценность разных фич. То, чем гордится разработчик, может не впечатлить менеджерский отдел — и наоборот, то, чем менеджеры «хвастаются» перед клиентами, разработчики могут считать неважным и неинтересным. Мне же нужно как-то консолидировать мнения и приоритеты.
Вика, которую я знал как Android-разработчика и любительницу похоливарить на тему «ios vs android», стала ПМ в компании, делающей мобильные приложения.
3. ПМ гораздо реже работает «руками»
Как верно отметил кто-то на Хабре, размышляя о роли ПМ, важно не пытаться быть «человеком-швейцарским ножом» и не стараться закрыть собой функции нескольких отделов.
В сторону позиции «осьминог-многорук» я иногда «скатывался» и ранее — повторюсь, я работаю в стартапе, где потребности обычно растут быстрее, чем штат. Несколько раз я усаживался за не очень-то горящие задачи совершенно не по своему профилю — например, работал с железом. Мне это казалось хорошей возможностью расширить свои скилы, но сейчас я понимаю, что, с точки зрения менеджмента, задачи выполнялись долго и неэффективно. Вложение времени в то, чтобы я развивался не по профилю, для компании невыгодно. Лучше было бы на время поиска штатного специалиста привлекать подрядчиков или стажеров.
Когда я стал ПМом, мне часто казалось, что проще переделать все самому, чем назначать встречу, общаться, контролировать переделки, проверять, все ли сделано...
Но со временем я понял, что это расшатывает дисциплину и приводит к тому, что коллеги начинают работать менее аккуратно, зная, что за них и так «все поправят». К тому же я так расширяю свою и без того немаленькую зону ответственности.
Бывший директор отдела разработки Twitter Дэвид Лофтеснесс в своем «90-дневном плане для разработчиков, собирающихся стать менеджерами» рассказывал, что он затянул с прекращением программистской работы, из-за этого вовремя не дал критической оценки одного из членов своей команды, который не справлялся со своими обязанностями. Это стало для него важным уроком, и с тех пор он стал уделять программированию минимум времени, и то по остаточному принципу.
Не пытайтесь закрыть собой все «дыры» — вас просто не хватит на это, а вот если не устранить причину сбоев, то весь корабль пойдет ко дну.
Еще до того, как начать работу в менеджменте, я получил хорошую «вакцину» от того, чтобы пытаться «все делать руками». У меня перед глазами был пример нашего продакта — до прихода в компанию у него на Урале было свое маленькое рекламное агентство, поэтому он пришел «и жнецом, и на дуде игрецом», разбирался и в дизайне, и (на базовом уровне) в кодинге, и в брендинге, и в поисковом продвижении, вдобавок «горел» продуктом и постоянно генерил новые идеи...

Бюджеты инвестор выделял скромные, в штате, кроме ПМа, было четыре человека (я, пиарщик, администратор, оператор-монтажер и звукорежиссер) — и десяток не закрываемых таким составом задач, то же SEO... Вместо того чтобы выделить неделю (или даже пару) на то, чтобы собрать пул необходимых подрядчиков, он пытался сделать все сам.

Навыков хватало, а вот человека — нет. «Распыляясь» на разнородные задачки (и еще и «перескакивая» с одной на другую) он ничего не успевал доделать, совсем запустил свои непосредственно менеджерские обязанности (отчего среди других сотрудников начались разброд и шатания) и вдобавок полностью «выгорел», физически и морально. В итоге сейчас стартап официально загнулся, а тот менеджер бросил все и ушел преподавать танцы. Вот такая история.
Мой хороший друг Костя, ранее бывший фронт-миддл в той самой компании, обучающей иностранному языку, сейчас с головой ушел в геймдев в качестве ПМ.
4. Мнение пользователей — то, о чем не стоит забывать
Когда вы начинаете работать с продуктом, у вас быстро «замыливается» взгляд. Я помню, что мы долго совершенствовали раздел с описанием продукта на лендинге, я гонял копирайтера-фрилансера и заставлял его делать по десять итераций, мы могли по двадцать минут спорить с дизайнером по поводу расположения того или иного текстового блока на третьем экране... Наконец, мы пришли к идеальному, как мне казалось, варианту — но спустя месяц статистика по сайту и по обратной связи от клиентов не поменялась.
Посмотрел по метрике и карте кликов, попросил нескольких знакомых из потенциальной целевой аудитории при мне посмотреть на сайт — и понял, что люди, глядя на главную страницу, не улавливали ни сути продукта, ни того, что он может им дать, и уходили. Хотя мне (человеку, работавшему с продуктом с момента создания идеи) казалось, что все «и так понятно». В итоге поработали над главной, и число тех, кто не смотрит дальше первого экрана, заметно снизилось.
Что в итоге помогло мне освоиться
1. Я стал активно использовать проги и инструменты
Да, можно стирать одежду вручную, особенно если вы это делаете раз в год. Но вот отказываться от экономящего время и силы инструментария в повседневной работе не стоит. Есть много классных совершенно бесплатных инструментов.
Главным, конечно, будет софт, в котором ведется основное планирование. Изначально мы работали в Trello, но, честно говоря, не впечатлились. Основной экран не очень наглядный, хотя то, что инструмент бесплатный, радует. Да и чек-листы в нем вести удобно. Потом перешли в Kaiten, чистый интерфейс и внутреннее устройство мне нравится, но и багов достаточно — например, с точки зрения работы с архивом.
Кстати, покупку платного софта нужно оправдывать, но, если она экономит человеко-часы, руководство от нее никогда не откажется. Например, первое время я чертил диаграммы Ганта в Excel или в «Google Таблицах». В итоге изменения, синхронизация и даже банальное «раскрашивание» табличек занимало неоправданно много времени, к тому же возникали сбивки и путаницы. Потестили «GanttPro» — небо и земля: есть возможность сразу видеть всю картину проекта во времени, а не просто огромный список тасков. Удобно спланировать проект, рассчитать время и стоимость, согласовать с заказчиком, сразу же распределить роли и начать работать, так как инструмент прост в освоении. Особенно приятно, что сервис дружит с русским языком, то есть с технической и языковой поддержкой все будет в порядке. Помимо планирования работы команды, GanttPro помогает мне при презентации проектов и подготовке отчетности.
В пересчете на мои часы покупка таких прог для компании точно выгодна — не говоря уже об экономии временных ресурсов и о повышении качества работы, которое растет, когда тратишь меньше времени и сил на операционку.
2. Я использую собственное железо
У нас кросс-платформенный продукт, поэтому мне в дополнение к моему старенькому «яблоку» потребовалось Android-устройство. Просить и потом ждать казенный не хотелось, поэтому купил сам. Я яблочник со стажем и не особо разбираюсь в зоопарке Android-устройств, выбирал по соотношению характеристик и цены. Взял Camon 12 от пока что малоизвестных на рынке TECNO за 9к, и этого оказалось более чем достаточно. Экран большой и яркий, ОЗУ хватает (4 Гб) для тестирования продукта и моих бытовых задач типа проверки почты, Telegram и звонков, батарейка у меня живет двое суток (4000mAh дают о себе знать), камера с макро и 4 вспышками регулярно выручает, когда основной телефон садится. Допускаю, что, возможно, использую телефон не на полную, но такие уж задачи я перед ним ставлю.
Главный плюс второго телефона для меня — можно попробовать себя в роли пользователя до релиза и своевременно выловить многие баги. Иногда лучше не ждать бюджетов и решений «свыше», а просто брать и делать. Личная техника в работе предпочтительна еще и тем, что ты можешь делать с ней что хочешь без чьего-либо разрешения. В крупных компаниях такое иногда пресекает служба безопасности (такой же разумности инициатива, как и закрытие USB портов).
3. Я целенаправленно выделял время на саморазвитие
Первое время, читая на работе полезные статейки и книги, пока другие кодили, я испытывал угрызения совести, пытался кодить сам (о том, чем это закончилось, писал выше), откладывал чтение всякого полезного на вечер, в итоге информация попадала в уставшую голову, все путалось и на следующий же день выветривалось...
Позже в спокойные дни я стал выделять себе законное время на то, чтобы «повникать» в тему с учетом того, что не существует сканера, позволяющего безошибочно оценивать полезность той или иной литературы, и это нормально — иногда с сожалением закрывать книгу или материал и чувствовать, что зря потратил время.
Кстати, по большинству предметных областей (кроме, разве что, интернет-маркетинга, в котором все меняется со скоростью света) я рекомендую читать не только красивые томики из раздела бизнес-литературы, но и банальные вузовские учебники — в них обычно мало бахвальства и пустого «вдохновлятельства», плюс информация хорошо структурирована. Вон в издательстве Юрайт в этом году вышло «Управление продуктом», может, читал уже кто?
Что и про что я читал? Про управление (тут я начал с классики, с Питера Друкера), про построение бизнес-моделей («Построение бизнес-моделей» Александра Остервальдера и Ива Пинье очень хороша, прямо готовый практикум), про нетворкинг (мне неплохо зашла «Никогда не ешьте в одиночку» Кита Феррацци и Тала Рэз), про бизнес (например, «Стратегия голубого океана» Рене Моборна), про маркетинг и брендинг (хорошая «Как растут бренды» Байрона Шарпа), про тайм-менеджмент (Аллена и Архангельского я еще до перехода на должность ПМ изучал активно, но упомянуть их здесь лишним не будет).
Вообще, продакту могут быть полезными самые разные знания. Мой друг Дима, например, вовсю погружался в психотипы, Censydiam и архетипы, а я вот уверен, что мне в работе весьма пригодились некоторые сведения из «Гарри Поттера и методов рационального мышления» Элиезера Юдковского.
4. Я общался с продактами и специалистами с других рынков
«Сарафанное радио» мне здорово помогло. Контакты хорошего исследовательского агентства я получил от продакта, работающего в ритейле, а от коллеги по отрасли узнал, что дешевые места для стендов на одной из отраслевых выставок размещают там, куда не ступает нога человека, поэтому на ту выставку идти нужно или по дорогому тарифу, или никак.
Еще я постарался разузнать, где «водятся» хорошие специалисты по нужным направлениям (например, дизайнеры обитают на Dribble и на Behance), вступил в пару профессиональных чатиков и групп в Facebook и Telegram и убедился, что искать там быстрее и эффективнее, чем в поисковиках или на фриланс-базах.
5. Я стал креативить и пробовать разные методики взаимодействия
Продакту нужно быть креативным. Безусловно, многие рабочие механики и методики стоит почерпнуть из книг и статей («просто читать» без внедрения — не лучшее занятие), но можно придумывать и свои.
Я постоянно мониторю новости рынка, и раньше раз в неделю делал рассылку-обзор со ссылками, которые, естественно, почти никто не открывал (ссылки я, естественно, предварительно прошиваю). После стал делать короткий дайджест (абзац с пересказом плюс ссылка на статью), его хотя бы кто-то начал проглядывать, но все равно до многих ценная информация так и не доходила. В итоге я попросил начальство выделить мне пять минут в день, стал готовить короткую презентацию, в одно и то же время выключать свет (у нас open space) и устраивать мини-кинопоказ с основными новостями. Это привлекало уже больше внимания, но все равно многие не поворачивали головы. Внес последнее изменение — перенес ревью с утра понедельника на вечер четверга, когда все уже порядком подустали, но еще не спешат на пятничное веселье — сработало!
Не жалею ли я о смене профессии?
Нет. Во-первых, это прокачало меня как личность, и многие навыки продакта помогают и в «нерабочей» жизни. Я заметил, что эффективнее решаю вопросы вне работы, лучше договариваюсь с людьми. Общению и делам новая позиция пошла на пользу.
Во-вторых, я очень люблю чувство, когда «из ничего» создается что-то ценное, это мне нравилось и в кодинге. Когда ты являешься не только исполнителем, но и «предводителем», то это чувство во сто крат сильнее.
В-третьих, такая работа более динамична, в ней больше разнообразия, больше общения, больше разнородных задач, она расширяет кругозор.
Сейчас продукт находится на стадии пилотного запуска, это самая «жара» для продакта, поскольку одновременно дел много и по доработке (баги выявляются не только изнутри, но и извне, а значит, исправлять их нужно шустрее), и по выводу на рынок (это встречи, много встреч, график дня постоянно «скачет»). Я рад, что подключаюсь к проекту не на этом этапе, иначе мне было бы куда сложнее.
Оставил ли я идею о собственном стартапе? Нет. Правда, теперь я понимаю, какая тонна операционки вроде встреч с очень важными потенциальными клиентами, подписания ежедневно увеличивающейся кипы бумаг и необходимости вникать в 1000 и 1 вопрос за один рабочий день лежит на плечах СЕО, и пока раздумываю, так ли мне это надо. Тем более, продактом я чувствую себя более чем комфортно.
Всем прочитавшим — спасибо, всем вдохновившимся повторить — удачи! Если у кого есть похожие истории перехода в другое направление — делитесь в комментариях, что вам помогло, как прошел период адаптации, будет очень интересно почитать о таком опыте у других людей.
Tags:
Hubs:
+21
Comments 12
Comments Comments 12