В новой вакансии просят опыт, которого, судя по названию должности, у вас нет. Но что-то из этой работы вы уже точно делали: уточняли требования, разбирали данные, оценивали риски, предлагали решения. Просто это было ещё в прежней роли и пока не сложилось в отдельную историю.
В новой вакансии просят опыт, которого, судя по названию должности, у вас нет. Но что-то из этой работы вы уже точно делали: уточняли требования, разбирали данные, оценивали риски, предлагали решения. Просто это было ещё в прежней роли и пока не сложилось в отдельную историю.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Если разработчик помогал исследовать пользовательскую проблему, он не станет от этого продактом. Но у него появился продуктовый кейс. Аналитик, участвовавший в выборе архитектуры, ещё не архитектор — зато он может рассказать о реальном техническом решении. Такой опыт не отменяет пробелов, но позволяет не начинать разговор с работодателем со слов «я совсем новичок».
Связать старую и новую роли помогают артефакты: документы, расчёты, схемы и решения, по которым видно, какую задачу человек взял на себя и что из этого получилось.
Представим разработчика, который время от времени собирает обратную связь, предлагает изменить пользовательский сценарий, обсуждает метрики и помогает уточнять требования. В резюме всё это помещается в одну строку Software Engineer. За ней легко не заметить работу, которая уже соприкасается с Product Management.
Если собрать problem statement, разбор сценария, предложение с несколькими вариантами решения и анализ после запуска, история становится объёмнее. Нет, эти материалы не превращают разработчика в продакта, но показывают, какую часть продуктовой задачи он действительно выполнил.
С другими переходами происходит примерно то же самое. Опыт новой роли сначала появляется небольшими фрагментами внутри старой: в отчёте, тестовой стратегии, ADR, разговоре с пользователем или решении, которое пришлось защищать перед командой. Артефакты помогают не приписать себе лишнего, а точнее описать уже сделанное.
Конечно, не всякий рабочий документ можно положить в портфолио. Внутренние данные, пользовательскую информацию и материалы под NDA нельзя публиковать без разрешения. Иногда кейс приходится обезличить, пересобрать на открытых данных или оставить для устного рассказа.
Продуктовая часть работы может начаться с вопроса «зачем?». Команда получает задачу добавить фильтр или переделать онбординг, а за короткой формулировкой обнаруживается пользовательская проблема, которую ещё предстоит понять.
Человек, который уточняет, кто сталкивается с этой проблемой, как сейчас устроен сценарий и по какому признаку можно оценить изменение, уже выходит за рамки простой реализации требования. Из такого эпизода получается первый продуктовый артефакт:
проблема → пользователи → текущий сценарий → варианты решения → критерий успеха.
Со временем к этому может добавиться приоритизация. Небольшой список задач приходится сравнивать по частотности проблемы, ожидаемому влиянию, стоимости реализации, рискам и зависимостям. Где-то удаётся поучаствовать в интервью с пользователем, где-то — собрать материалы для discovery или представить решение на refinement. Масштаб здесь не так важен, как возможность отделить собственный вклад от работы команды.
На собеседовании такой опыт звучит убедительнее общего «мне интересен бизнес». Например:
«Команда получила несколько похожих запросов. Я сгруппировал их, проверил, насколько часто возникает проблема, и предложил два варианта решения. Для оценки результата мы выбрали метрику, а после запуска сравнили её с исходным уровнем».
Это похоже на формат, который Amazon рекомендует для PM-интервью: разбирать конкретные ситуации, объяснять свои действия и причины решений, добавлять метрики там, где они уместны, и выстраивать ответ по STAR. Подробнее этот подход описан в материале Amazon о подготовке к интервью.
Если во время такой работы обнаружатся пробелы в теории, их можно закрывать точечно. Software Product Management Specialization Университета Альберты посвящена Agile-разработке и взаимодействию в продуктовой команде. В Real-World Product Management Specialization есть практические задания — от персон и PRD до метрик и подготовки к PM-интервью. Курс Product Management 101 охватывает market intelligence, стратегию, разработку продукта и управление его жизненным циклом. А на edX собраны отдельные курсы и программы, в том числе Университета Мэриленда.
С книгами работает тот же принцип: полезнее выбирать их под конкретный вопрос. Marty Cagan — Inspired рассказывает о работе продуктовых команд и создании технологических продуктов. Gayle Laakmann McDowell, Jackie Bavaro — Cracking the PM Interview посвящена найму и подготовке к интервью на продуктовые позиции. Cole Nussbaumer Knaflic — Storytelling with Data пригодится, если нужно научиться понятнее представлять данные.
В Data легко сосредоточиться на инструментах: SQL, Python, Excel, системе визуализации. Но сами по себе они мало рассказывают о том, как человек рассуждает. Для этого нужен кейс, в котором есть вопрос, данные, способ анализа и решение.
Материал для него нередко находится в текущей работе. Специалист поддержки может разобраться, с чем связаны обращения и сколько времени занимает их решение. Разработчик — посмотреть на ошибки, задержки или использование функции. QA-инженер — изучить распределение дефектов по компонентам, а product manager — конверсию на отдельных шагах сценария.
Во всех этих историях сохраняется одна и та же логика:
вопрос → данные → метод → вывод → решение.
Допустим, после релиза выросло число обращений. Само наблюдение ещё не объясняет, что случилось. Приходится смотреть, у каких пользователей произошёл рост, на каком шаге, в каких версиях продукта и какие ещё события могли повлиять на результат. Так небольшой отчёт постепенно становится аналитическим кейсом.
Если для такого кейса не хватает технической базы, можно посмотреть IBM Data Analyst Professional Certificate. В программу входят Excel, SQL, Python, визуализация и практические проекты. Data Analyst Skillpath: Zero to Hero in Excel, SQL & Python тоже объединяет эти три инструмента и рассчитан на начинающих.
Сертификат можно добавить в резюме. Но разговор обычно становится содержательнее, когда кандидат может открыть законченный анализ и объяснить, почему выбрал этот метод, чего не хватало в данных и как команда использовала выводы.
С качеством работают не только люди с QA в названии должности. Разработчики воспроизводят дефекты и пишут тесты, поддержка собирает сведения об ошибках, продуктовая команда участвует в приёмке функций. Вопрос в том, можно ли увидеть за отдельными проверками более общую картину.
Такой картиной может стать risk-based test strategy для небольшой функции. Вместо длинного перечня тест-кейсов в ней объясняется, что может сломаться, чем это грозит пользователю или бизнесу, какие сценарии критичны и какие проверки имеет смысл автоматизировать. Там же честно фиксируются ограничения: что команда не успела проверить и какой риск остался.
Следующим кейсом иногда становится регрессионное тестирование компонента, проверка API или качество конкретного релиза. Здесь интересен не только объём работы, но и логика выбора. Почему из сорока сценариев семь оказались критичными для оплаты? Почему автоматизировали именно их? Изменилось ли после этого время прогона, стали ли дефекты находить раньше?
Если цифр нет, их не нужно восстанавливать по памяти. Можно описать наблюдаемый результат и пояснить, откуда он известен. Такой рассказ будет скромнее, зато его легче защищать на интервью.
Разобраться в методах тестирования помогает Software Testing and Automation Specialization Университета Миннесоты. В программе есть black-box и white-box testing, автоматизация, тестирование веб- и мобильных приложений и формальные методы. В Software QA & Test Automation Engineering собраны практические инструменты, в том числе Selenium, Cypress, JMeter и Postman.
Первый архитектурный кейс не обязательно связан с системой на миллиарды запросов. Гораздо ближе обычно находятся решения из собственного проекта: разделить компонент, выбрать очередь вместо синхронного вызова, изменить способ хранения данных или убрать узкое место.
Пока такое решение живёт только в переписке и памяти команды, человеку со стороны трудно понять его контекст. ADR собирает историю в короткую форму:
контекст → решение → рассмотренные варианты → компромиссы → последствия.
К документу можно добавить диаграмму и обсудить его с командой. Если решение ещё не принято, вместо ADR может появиться RFC с вариантами и открытыми вопросами. В обоих случаях ценно не само оформление, а ход мысли: почему возникла проблема, от каких альтернатив отказались и с какими последствиями согласились.
Martin Fowler определяет ADR как короткий документ об одном значимом решении. Он нужен не только для истории проекта: запись помогает прояснить аргументы и вынести разногласия в обсуждение. Но красивый ADR сам по себе, конечно, не делает автора архитектором. Он становится частью карьерного кейса, когда связан с реальным решением и его последствиями.
Для теоретической базы можно обратиться к Software Design and Architecture Specialization Университета Альберты. В программе есть принципы проектирования, паттерны, архитектурные стили и визуальная документация; практическая часть построена вокруг Java- и Android-проекта. Курс Software Architecture из этой специализации разбирает UML, архитектурные стили, атрибуты качества и ATAM. Software Architecture & Design of Modern Large Scale Systems посвящён системным требованиям, масштабируемости, доступности, производительности и архитектурным компромиссам.
Из книг можно выбрать Designing Data-Intensive Applications Мартина Клеппманна — о данных, распределённых системах и компромиссах — и The Software Architect’s Elevator Грегора Хоппе — о связи технических решений с устройством организации.
У каждой траектории будут свои документы и свои признаки ответственности. В кратком виде картина выглядит так:
| Новая роль | Что может найтись в прежней работе | Возможный артефакт | О чём получится рассказать |
| Product | требования, пользовательские проблемы, приоритеты, метрики | problem statement, PRD, предложение по roadmap, разбор метрик | как исследовали проблему, выбирали приоритет и представляли решение |
| Data | отчёты, SQL, Excel, продуктовые и операционные показатели | SQL-анализ, дашборд, data story, анализ эксперимента | как сформулировали вопрос и довели анализ до решения |
| QA | дефекты, релизы, инциденты, проверки изменений | test strategy, risk matrix, regression suite, автотесты | как выбирали критичные проверки и работали с риском |
| Architecture | интеграции, технический долг, нагрузка, технические компромиссы | ADR, C4- или UML-диаграмма, RFC, материалы architecture review | как провели решение от формулировки проблемы до согласования |
Эту таблицу не стоит воспринимать как набор обязательных документов. Один содержательный кейс иногда говорит о человеке больше, чем папка шаблонных артефактов. Рабочая связка остаётся простой:
артефакт → личная ответственность → результат или последствия.
Из нескольких кейсов имеет смысл выбрать те, что ближе к конкретной вакансии. Рассказ можно начать с контекста: что происходило и почему вообще понадобилось решение. Затем обозначить границы собственной ответственности, вспомнить рассмотренные варианты и закончить результатом.
Результат не обязательно выражается ростом метрики на десятки процентов. Решение могли принять, процесс — изменить, риск — обнаружить до релиза. Важно лишь не выдавать предположение за факт и быть готовым объяснить, откуда известен эффект.
Есть ещё один вопрос, который делает такой рассказ человечнее: что сейчас хотелось бы сделать иначе. Он не обесценивает кейс, а показывает, что опыт уже осмыслен и у него видны границы.
Смена роли редко происходит в один день. Сначала в привычной работе появляется новая задача, затем — немного больше ответственности, а потом и история, которую уже можно вынести на собеседование.
Для product management такой историей может стать разбор пользовательской проблемы, для data — аналитический кейс, для QA — стратегия тестирования, для architecture — ADR или RFC. Ни один из этих документов не заменяет опыт в новой должности. Но каждый помогает показать, что прежние годы работы не нужно списывать со счёта.
Курсы и книги остаются вспомогательными. Они закрывают конкретные пробелы между тем, что человек уже делал, и тем, чего потребует новая роль. А сам переход становится не обнулением, а продолжением маршрута — с новым направлением, но с накопленным багажом.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.