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

Меня зовут Настя, я менеджер проектов команды разработки в iSpring. Несколько лет я работала в техподдержке, и это стало хорошим стартом — но со временем хочется не просто работать с готовым продуктом, но и иметь отношение к его созданию. И здесь опыт в техподдержке помогает, ведь проджект-менеджер — среди прочего и саппорт для команды. В поддержке ты привыкаешь контролировать задачи, решения которых ждет клиент — что-то похожее происходит и в работе менеджера проектов, просто немного под другим углом. Расскажу, как навыки, полученные за годы работы в техподдержке, могут оказаться полезными на позиции PM-а.

Продукт

В продуктовых компаниях проджект-менеджер часто закрепляется за определенным проектом/проектами и хорошо знает только свои фичи. Это не дает посмотреть на продукт широко: ты сконцентрирован на определенном модуле, нет необходимости знать продукт целиком. Но если такая экспертиза у тебя есть, это большой и жирный профессиональный плюс: ты можешь понять, как функционал, за который ты отвечаешь, может влиять на остальные фичи в продукте. И чтобы мыслить не локально, а в рамках всего продукта или даже продуктовой линейки, — необходимо взаимодействие с клиентами и понимание, как они используют продукт. Поясню подробнее. 

Знание функционала всего продукта

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

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

Приведу пример: в одном из модулей нашего продукта мы хотели сделать кастомизацию уведомлений, но она конфликтовала с уведомлениями в других модулях. Поэтому необходимо было продумать комплексный подход к реализации уведомлений во всём продукте — без полного знания функционала эта задача заняла бы на порядок больше времени.

Знание сценариев использования продукта

Помимо знания функционала продукта в техподдержке ты начинаешь понимать, как именно клиенты пользуются продуктом. Ситуация: на этапе проектирования ты прописываешь фичи, а фактически клиенты используют их не так, как они были спроектированы. 

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

Команда

Опыт работы в техподдержке дает тебе очень ценный навык — умение работать с людьми. С самыми разными: исполнительными, ответственными, вечно недовольными, опаздывающими, креативными или упёртыми. Ты по-настоящему осознаешь, что все люди разные, и учишься находить подход к каждому независимо от характера человека и внешних обстоятельств. 

Индивидуальный подход

Для техподдержки важно не только качественное и быстрое решение проблем, но и высокий уровень сервиса: правильная коммуникация, умение наладить контакт с раздражённым клиентом и при этом сохранить самообладание.

Каждый новый звонок — это своего рода cold call, когда ты не знаешь ничего ни о человеке, ни об уровне его технических знаний. При этом ты должен всегда обеспечить одинаковый результат. И здесь индивидуальный подход обязателен: кому-то достаточно кратко объяснить ход решения, кому-то — подробно разжевать каждый шаг вплоть до “нажмите на иконку дважды”. 

В работе менеджера проектов это очень помогает: если хочешь эффективную, организованную команду — нужно уметь найти подход к каждому её участнику.

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

Условному senior-разработчику ты можешь дать задачу просто сделать все качественно и по уму, к начинающим джунам нужен принципиально другой подход: здесь помимо менеджера ты становишься немного учителем, наставником и даже психологом. Причем психологом ты должен быть и для себя самого — важно уметь иногда переступить через своё плохое настроение, чтобы это не сказалось на всей команде: для коллег ты всегда должен быть в тонусе, оставаться бодрым и позитивным, а негативные эмоции или настроение могут навредить рабочим отношениям и повлиять на результат. 

Развитие руководящих навыков

Когда ты работаешь в саппорте, ты учишься управлять ситуацией, а не пускать её на самотёк — от того, как ты умеешь брать ответственность и выруливать из самых сложных кейсов, зависит успешность твоей работы. 

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

Например: прямо перед релизом тестировщик находит баг в тестовой среде и тут же пишет разработчику с просьбой его починить. Разработчик бросает все горящие дела и берется за эту задачу как за самую приоритетную — ведь завтра релиз. От этого страдают другие задачи.

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

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

Работа с изменениями и неопределённостью

Техподдержка неплохо прокачивает и твои навыки работы в самых сложных условиях: сжатые дедлайны, общение с раздражёнными клиентами, необходимость быстро найти решение — это закаляет, и на должности PM-а подобные проблемы тебя уже не выбьют из колеи. 

Умение быстро находить решения

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

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

Тайм-менеджмент

В саппорте ты можешь просидеть весь день над кейсом, и вот на часах 18 часов, а у тебя ещё с десяток кейсов, которые нужно закрыть сегодня, потому что клиенты ждут ответа. Без качественного тайм-менеджмента тут никуда: или ты приоритезируешь задачи — или вы с командой сидите на работе до ночи. 

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

Например, в одном из наших модулей есть ограничение на количество пользователей — пока этот лимит никто не превышал.

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

И твоя задача как проджекта — безошибочно определять, какая задача важнее сейчас и как она влияет на функционал всего продукта.

Стрессоустойчивость

Мало кто звонит в саппорт, чтобы рассказать про свой позитивный опыт (практически никто). Это формирует в тебе неплохой уровень стрессоустойчивости: при возникновении конфликта ты сохраняешь самообладание и можешь как успокоить клиента, так и выйти на определенное конструктивное решение. 

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

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

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

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