Как опыт работы в техподдержке может помочь в карьере менеджера проектов
Менеджеры проектов — супер универсальные люди: они должны и уметь выстроить процесс, и проконтролировать, чтобы результат был достигнут вовремя. Для этого важна правильная коммуникация: с командой, с заказчиком, с коллегами из других отделов. Конечно, не менее важно досконально знать весь продукт и понимать цели бизнеса для реализации проекта.
Меня зовут Настя, я менеджер проектов команды разработки в iSpring. Несколько лет я работала в техподдержке, и это стало хорошим стартом —, но со временем хочется не просто работать с готовым продуктом, но и иметь отношение к его созданию. И здесь опыт в техподдержке помогает, ведь проджект-менеджер — среди прочего и саппорт для команды. В поддержке ты привыкаешь контролировать задачи, решения которых ждет клиент — что-то похожее происходит и в работе менеджера проектов, просто немного под другим углом. Расскажу, как навыки, полученные за годы работы в техподдержке, могут оказаться полезными на позиции PM-а.
Продукт
В продуктовых компаниях проджект-менеджер часто закрепляется за определенным проектом/проектами и хорошо знает только свои фичи. Это не дает посмотреть на продукт широко: ты сконцентрирован на определенном модуле, нет необходимости знать продукт целиком. Но если такая экспертиза у тебя есть, это большой и жирный профессиональный плюс: ты можешь понять, как функционал, за который ты отвечаешь, может влиять на остальные фичи в продукте. И чтобы мыслить не локально, а в рамках всего продукта или даже продуктовой линейки, — необходимо взаимодействие с клиентами и понимание, как они используют продукт. Поясню подробнее.
Знание функционала всего продукта
Работая в техподдержке, никогда не знаешь, о чём тебя спросят на том конце провода, поэтому начинаешь разбираться в каждом уголке продукта. Ты сам не можешь придумать и половины кейсов, с которыми к тебе приходят реальные пользователи: иногда клиенты задают вопросы о функционале, которым ты даже никогда не пользовался —, но тебе все равно нужно дать быстрый и квалифицированный ответ. Так знание всего продукта становится просто профессиональной необходимостью для саппорта.
Как это помогает менеджеру проекта — очень просто: ты приходишь на новую должность с мощным бэкграундом и с первого дня можешь сконцентрироваться на новых процессах и результате — продукт ты уже знаешь. К тому же ты видишь связи разрабатываемой фичи с остальным функционалом продукта, понимаешь, что чему может помешать, и так далее. Комплексное видение помогает избежать ошибок.
Приведу пример: в одном из модулей нашего продукта мы хотели сделать кастомизацию уведомлений, но она конфликтовала с уведомлениями в других модулях. Поэтому необходимо было продумать комплексный подход к реализации уведомлений во всём продукте — без полного знания функционала эта задача заняла бы на порядок больше времени.
Знание сценариев использования продукта
Помимо знания функционала продукта в техподдержке ты начинаешь понимать, как именно клиенты пользуются продуктом. Ситуация: на этапе проектирования ты прописываешь фичи, а фактически клиенты используют их не так, как они были спроектированы.
Приходя в проджект-менеджмент, ты начинаешь думать кейсами клиентов и исходишь прежде всего из их запросов и нужд. Это помогает разрабатывать действительно полезный и интуитивно-понятный продукт.
Команда
Опыт работы в техподдержке дает тебе очень ценный навык — умение работать с людьми. С самыми разными: исполнительными, ответственными, вечно недовольными, опаздывающими, креативными или упёртыми. Ты по-настоящему осознаешь, что все люди разные, и учишься находить подход к каждому независимо от характера человека и внешних обстоятельств.
Индивидуальный подход
Для техподдержки важно не только качественное и быстрое решение проблем, но и высокий уровень сервиса: правильная коммуникация, умение наладить контакт с раздражённым клиентом и при этом сохранить самообладание.
Каждый новый звонок — это своего рода cold call, когда ты не знаешь ничего ни о человеке, ни об уровне его технических знаний. При этом ты должен всегда обеспечить одинаковый результат. И здесь индивидуальный подход обязателен: кому-то достаточно кратко объяснить ход решения, кому-то — подробно разжевать каждый шаг вплоть до «нажмите на иконку дважды».
В работе менеджера проектов это очень помогает: если хочешь эффективную, организованную команду — нужно уметь найти подход к каждому её участнику.
Любой стандартный подход к управлению может сыграть злую шутку. Все люди разные: кому-то для достижения результата достаточно описать простую последовательность действий, другому — подробно описать каждый шаг в этой последовательности и попутно ответить на множество вопросов.
Условному senior-разработчику ты можешь дать задачу просто сделать все качественно и по уму, к начинающим джунам нужен принципиально другой подход: здесь помимо менеджера ты становишься немного учителем, наставником и даже психологом. Причем психологом ты должен быть и для себя самого — важно уметь иногда переступить через своё плохое настроение, чтобы это не сказалось на всей команде: для коллег ты всегда должен быть в тонусе, оставаться бодрым и позитивным, а негативные эмоции или настроение могут навредить рабочим отношениям и повлиять на результат.
Развитие руководящих навыков
Когда ты работаешь в саппорте, ты учишься управлять ситуацией, а не пускать её на самотёк — от того, как ты умеешь брать ответственность и выруливать из самых сложных кейсов, зависит успешность твоей работы.
Это неплохо прокачивает тебя как руководителя, когда оказываешься среди разработчиков: чтобы сохранить эффективность работы, команда должна быть уверена, что у тебя все под контролем, что у тебя есть решение даже в самый неопределенный стрессовый момент.
Например: прямо перед релизом тестировщик находит баг в тестовой среде и тут же пишет разработчику с просьбой его починить. Разработчик бросает все горящие дела и берется за эту задачу как за самую приоритетную — ведь завтра релиз. От этого страдают другие задачи.
И если в этой цепочке между тестировщиком и разработчиком есть PM, имеющий опыт работы в техподдержке, он поможет, во-первых, понять, насколько серьезный баг, встречается ли он на проде или ограничивается только тестовой средой, во-вторых — посмотреть на проблему с точки зрения клиента и определить, с какой вероятностью пользователь может столкнуться с этим багом. Часто оказывается так, что баг вообще не относится к пользовательским сценариям или что воспроизвести его на проде практически невозможно — PM должен быстро это понять и, если баг не критичен, успокоить коллег, попросить разработчика продолжить заниматься запланированными задачами.
В такие моменты как раз и прокачиваются навыки руководителя — команда всегда знает, что ты решишь проблемный вопрос.
Работа с изменениями и неопределённостью
Техподдержка неплохо прокачивает и твои навыки работы в самых сложных условиях: сжатые дедлайны, общение с раздражёнными клиентами, необходимость быстро найти решение — это закаляет, и на должности PM-а подобные проблемы тебя уже не выбьют из колеи.
Умение быстро находить решения
Это где-то на стыке знания продукта и софт-скиллов. Работая в саппорте, ты часто имеешь дело с похожими кейсами и проблемами. Но не всегда — иногда готового решения, которое ты мог бы предложить клиенту, ещё нет. В техподдержке воркэраунды, или альтернативные решения — твои лучшие друзья! Если клиент звонит со специфичным кейсом, который ты не можешь решить здесь и сейчас, используя существующий функционал, можно предложить альтернативное решение: пусть оно будет состоять не из одного шага, а из трех —, но цель будет достигнута, задача клиента будет решена.
Воркэраунды помогают и в работе PM-а: решение сделать что-то иногда может оказаться слишком дорогим, поэтому ты должен найти обходной путь, который позволит выполнить задачу дешевле и быстрее, но при этом не потерять в качестве и достичь цели.
Тайм-менеджмент
В саппорте ты можешь просидеть весь день над кейсом, и вот на часах 18 часов, а у тебя ещё с десяток кейсов, которые нужно закрыть сегодня, потому что клиенты ждут ответа. Без качественного тайм-менеджмента тут никуда: или ты приоритезируешь задачи — или вы с командой сидите на работе до ночи.
Это ценный опыт, который помогает в работе проджекта: ты учишься концентрироваться в первую очередь на более важных задачах. Приоритетными считаются те задачи, которые напрямую влияют на продукт: ты сначала закрываешь кейсы, которые относятся к основным сценариям использования, и только потом заглядываешь в бэклог и начинаешь думать о дополнительных улучшениях вроде тени на виджете и добавления счетчика к текстовому полю — того, что не влияет на продукт, но что было бы неплохо сделать, чтобы продукт стал симпатичнее и аккуратнее.
Например, в одном из наших модулей есть ограничение на количество пользователей — пока этот лимит никто не превышал.
Однако это может измениться в любой момент, если кому-то из наших клиентов понадобится задействовать большое количество пользователей. Важно этого не допустить и решить проблему превентивно, поэтому задача по снятию ограничения в модуле в бэклоге всегда стоит выше, чем дополнительные задачи по доработкам дизайна или внутренним улучшениям, которые не видны клиенту.
И твоя задача как проджекта — безошибочно определять, какая задача важнее сейчас и как она влияет на функционал всего продукта.
Стрессоустойчивость
Мало кто звонит в саппорт, чтобы рассказать про свой позитивный опыт (практически никто). Это формирует в тебе неплохой уровень стрессоустойчивости: при возникновении конфликта ты сохраняешь самообладание и можешь как успокоить клиента, так и выйти на определенное конструктивное решение.
В разработке такая закалка спасает: идеальных условий не бывает — ты всегда должен балансировать и находить компромиссы, чтобы и достичь бизнес-цели, и грамотно распределить нагрузку внутри команды. Ограниченные ресурсы и строгие дедлайны вносят некоторый уровень стресса и неопределённости в рабочий процесс. И твоя задача как проджекта — успокоить людей, внушить уверенность, помочь разобраться в проблеме и решить её.
Частый кейс: разработчик ушел в отпуск или заболел. Если отпуск — вещь планируемая, то с болезнью все по-другому: она происходит как всегда в самый неподходящий момент, и ты должен оперативно найти качественную замену, забрифовать, проконтролировать результат — причем сделать это так, чтобы не пострадали другие функции, из которых ты временно выдернул сотрудника.
Впрочем, и в планировании встречаются ошибки: например, начинающий разработчик может приступить к задаче и в процессе понять, что для качественного её выполнения нужно дополнительно запросить доступы к базе или обновить зависимости, прежде чем писать новый код. А значит, потребуется на пару-тройку дней больше — сдвигается дедлайн по всей задаче. От этого никто не застрахован: важно выносить из ошибок максимум, чтобы не повторять их из раза в раз и повышать качество планирования. За всё это тоже отвечает менеджер проекта.
Конечно, в PM-ы можно пойти и после тестировщика или разработчика — важно иметь набор нужных навыков. Но на практике я поняла, что работа руководителем проекта становится эффективнее, когда у тебя есть опыт взаимодействия с клиентами, когда помимо досконального знания продукта ты можешь организовать работу команды, выстроить процессы, распределить нагрузку и взять ответственность. И кажется, работа в саппорте — лучшая школа для этого.
