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

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

Зачем нужна дорожная карта?

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

В нее не должна входить каждая функция продукта и подробные списки багов. Этот стратегический документ предназначен для отдельного планирования. Обязательно следует актуализировать roadmap продукта на протяжении всего его жизненного цикла.

Включенные функции, инициативы и требования должны создаваться и инициироваться многими сторонами: руководством, клиентами, sales-менеджерами, партнерами, службой поддержки, разработчиками, финансистами и, конечно, продуктовиками. Дорожные карты не ограничиваются продуктами: их цели аналогичны для разных видов (например, маркетинговые и IT-роадмапы).

Любая дорожная карта, ориентированная на свою аудиторию, имеет свои особенности.

• Дорожные карты для разработчиков обычно фокусируются на функциях, спринтах, релизах и майлстоунах. Они довольно короткие и, как правило, более масштабные.
• Дорожные карты для продавцов сфокусированы на сочетании функций и преимуществ для клиентов.
• Внешние дорожные карты (для клиентов или партнеров) ориентированы на основных преимуществах продукта для них. Как любой внешний документ, этот вид дорожной карты продукта должен быть привлекательным, визуально понятным и доступным.

Также дорожные карты отличаются в разных командах. К примеру, роадмап в Agile-команде будет отличаться от типовой дорожной карты в Waterfall.

Отличия дорожные карты в Agile и Waterfall

• Команды Waterfall обычно бизнес-ориентированы, основаны на финансовых метриках. В Agile цели ориентированы на клиента (например, рост пользователей и удовлетворенность клиентов).
• Дорожные карты в Waterfall отражают завершения в срок год или два года, а дорожная карта Agile обычно отражает квартальные завершенности. Планирование в компаниях Waterfall и Agile также отличается в зависимости от сроков.
• Различия также связаны с принципом взаимодействия. Взаимодействия в командах Waterfall последовательны, а члены Agile-команд работают в соответствии с кросс-функциональностью и одновременностью действий.
• Наконец, дорожные карты Waterfall имеют ограниченную гибкость, а дорожные карты Agile гораздо более гибки, как и сама методология.

Не существует идеального подхода, как визуально создавать дорожную карту; вы можете использовать разные шаблоны для отображения основных данных:

• Стратегические инициативы глобального уровня
• Релизы по периодам (кварталам)
• Детализированные функции
• Информация о баг фиксинге

Как создать идеальную дорожную карту?

Электронные таблицы

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

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

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

Презентации

Гораздо проще представить визуально дорожную карту в ПО, предназначенном для создания презентаций. Здесь у менеджера продукта больше возможностей и свободы действий.

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

Именно поэтому сегодня все популярнее становится сервис для управления продуктами с функционалом для создания дорожных карт.

Почему специальные сервисы лучше простых способов создания дорожной карты?

У менеджеров продуктов сегодня есть возможность визуализировать дорожные карты с помощью лучших управленческих инструментов, которые помогают:

• Представить визуально дорожную карту продукта
• Связать глобальную стратегию с процессами дорожной карты
• Определить и оценить идеи
• Сотрудничать со всеми заинтересованными сторонами (включая клиентов и нетехнических коллег)
• Интегрироваться со сторонними системами

Какой сервис выбрать? Вот ТОП-7 платформ для менеджеров продуктов, которые заботятся о качественной визуализации дорожной карты:

Roadmunk

Hygger

Taskworld

Proofhub

GanttPRO

Wizeline

Roadmap planner

Если сервис для управления продуктом определен, можно приступать к созданию дорожной карты. С чего начать? Как создать понятную всем дорожную карту?

Основные этапы создания дорожной карты

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

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

1. Определение стратегии

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

2. Кастомизация релизов

Здесь вы выбираете функции, которые нужно выделить, и решаете, должны ли внутренние или внешние данные представляться в каждом релизе или нет. Даты внешних и внутренних релизов могут быть разными.

3. Приоритизация фич

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

Существуют различные метрики, которые помогают оценить вашу стратегию.

Нетрудно создать свою собственную оценочную карту по вашему виду продукта, поскольку каждый продукт является чем-то уникальным. Имея свою оценочную карту, вы сможете объективно расставить приоритеты в своих дорожных картах.

Не забывайте об общих правилах по установлению приоритетов и известных методологиях приоритизации.

4. Совместное использование дорожной карты

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

В качестве заключение

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

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

Хорошо разработанное программное обеспечение с опцией roadmap является мощным стратегическим инструментом в управлении продуктами.

А каков ваш опыт использования дорожных карт? Делитесь своими идеями и историями успеха.

????️ Дорожная карта: что это, как ее составить и почему она обязательно нужна разработчику

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

Зачем нужна дорожная карта

В каких случаях точно пригодится дорожная карта:

• Если вы джун и не знаете, куда и как развиваться дальше;
• Если вы «застряли» на одной позиции;
• Если вы хотите поменять направление разработки.

Например, представим, что… вы пару лет работаете QA-инженером. Но чувствуете, будто «уперлись в стену»: получаете не так много, как хотелось бы; все надоело и будущее на этой должности кажется каким-то бесперспективным.

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

Но как спланировать переход и сделать его максимально плавным? Вот тут на помощь приходит дорожная карта.

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

К тому же правильно (подробно) оформленная дорожная карта может здорово помочь во время подготовки к собеседованию. Например, с ней вы четко знаете, какие навыки изучили, а также где и по каким ссылкам можно освежить память, если вдруг это понадобится.

Роадмап бывает в виде:

• списка;
• схемы;
• таблицы;
• презентации.

Чаще всего он встречается в виде схем. Но вы можете оформить его как угодно — потому что пользоваться им только вам.

Как составить дорожную карту программисту

1. Определитесь с целью

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

Например, представим, что вы работаете Junior Python-разработчиком уже около года. Логично, что вы умеете в Python, MySQL, Git, Django и т. д.

Тогда ответьте себе на вопросы:

• Вы планируете развиваться дальше и становиться разработчиком уровня Middle или Senior?

• Вам наскучило выбранное направление и вы хотите попробовать себя в чем-то новом, но в рамках ИТ?

• Вы хотите углубляться в Python или подучить лучше другой язык?

Далее на них можно ответить примерно вот так соответственно:

• Если вы планируете развиваться в уже выбранном направлении, то посмотрите, какие навыки требуют работодатели от Middle- и Senior-специалистов.

• Если вам надоела разработка, то есть смысл присмотреться к смежным направлениям — менеджменту или аналитике, а заодно выписать навыки, которые требуются для желаемых позиций.

• Если вы хотите развиваться в Python, но при этом не относиться напрямую к отделу разработки, то приглядитесь к смежным направлениям в ИТ, которые чаще всего используют этот язык в работе. Например, Data-Science, аналитика и т. д.

В целом такой подход можно назвать универсальным. Замените слово Python на любой другой язык/языки и задайте себе наводящие вопросы.

Вопросы могут быть какие угодно. Главное на данном этапе — выяснить, как вы хотите развиваться (вертикально или горизонтально) и куда:

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

Горизонтальный рост — это расширение смежных навыков и знаний. К примеру, если UX-дизайнер решит стать продуктовыми дизайнером.

Но помните, что цель должна быть конкретной, измеримой, достижимой, релевантной и времязатратной (принцип SMART).

В чем суть этого пункта: у вас есть точка А, нужно выбрать точку B.

2. Определитесь с навыками

Для этого посмотрите, какие навыки требуют работодатели в вакансиях на желаемую должность (вашу точку B). Для этого подойдет тот же самый хх.ру.

• открываете любой job-сайт;
• вводите желаемую позицию;
• смотрите, какие навыки работодатели чаще всего запрашивают на нее;
• распределяете все навыки на этапы или модули.

Сейчас объясню.

Например. Допустим, вы хотите перейти из фронтенда в аналитику данных. Смотрите на хх.ру, что требуют в вакансиях на аналитика, и выписываете навыки. Получается примерно следующее:

• 1 модуль. SQL;
• 2 модуль. Python;
• 3 модуль. Excel;
• 4 модуль. Power BI;

1 модуль = 1 навык

Желательно отсортировать от наиболее распространенного навыка до наименее.

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

Статья по теме

???? 5 soft skills, которые помогут тебе дорасти до Senior-разработчика

3. Распланируйте свое время

Поставьте конкретные временные рамки на изучение каждого модуля.

Например. Представим, что вы решили с нуля вкатиться в IT и стать верстальщиком. Тогда это будет выглядеть так:

• 1 модуль. HTML/CSS — 2 месяца: с сентября по ноябрь 2023.
• 2 модуль. JavaScript — 6 месяцев: с ноября 2023 по май 2024.

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

Объясняю на примере 1 модуля:

1 модуль	HTML	CSS	Длительность изучения
Теги, атрибуты, элементы, списки изображения, адреса, ссылки и якоря, таблицы, формы.	Способы подключения, синтаксис, простые селекторы, составные селекторы, текст и шрифт, цвет и фон, display, блочная модель, float, clearfix.	2 месяца: с сентября по ноябрь 2023.

1. Все это можно удобнее оформить в таск-трекере, но об этом будет чуть ниже.
2. Статья по теме
3. Повышаем свою продуктивность: 6 ключевых факторов

4. Приступайте к обучению

Есть два варианта, как начать двигаться к цели:

• Записаться на курсы. Это самый простой и относительно эффективный способ.

• Составить список из обучающих материалов. Это может быть все что угодно: ссылки на бесплатные курсы (их много на Stepik), тренажеры, образовательные платформы, видеоролики, книги, подкасты и так далее. Не забудьте приложить все полезные материалы к вашей «шпаргалке» — это пригодится, когда вы захотите освежить память перед собеседованием на новую должность.

Совет

Составляйте роадмап в пределах от 1,5 до 5 лет — это оптимальная временная перспектива. Делать дорожную карту на период от 5 до 10 лет и больше — точно не стоит.

Почему:

• Во-первых, IT-рынок слишком быстро меняется и вы вряд ли угадаете с трендами ближайшего десятилетия.
• Во-вторых, ставить перед собой грандиозные цели — классно. Но! Их будет сложнее правильно распланировать по шагам, а значит, появятся слишком высокие риски того, что вы не справитесь. Например, впадете в прокрастинацию (что часто случается перед масштабными задачами), передумаете в процессе и т. д.

Где составить дорожную карту

Дорожная карта Python-разработчика 2023 — Tproger — сайт для программистов о программировании

Если вы восхищаетесь Python так же, как и я, и задумываетесь о карьере Python-разработчика, вам понадобится наша дорожная карта по Python. В августе 2023 года этот ЯП возглавил рейтинг популярнейших языков согласно индексу TIOBE. Помимо Машинного / Глубокого обучения в этой вселенной существует еще много прекрасных высокооплачиваемых направлений.

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

Плюс с ходом времени вы поймете, каким именно разработчиком хотите стать, и некоторые продукты изучать вообще не придется.

Так что эта дорожная карта Python стоит воспринимать как некий универсальный листинг для новобранца, который играется со многим и так находит для себя самое интересное.

Основы Python

Старательно сокращаемый раздел знаний во всяческих онлайн-университетах, что ловят волну и хотят набрать как можно больше студентов на раскрученные факультеты. Что ж, если вы еще не определились, каким именно разработчиком хотите стать, упор рекомендую сделать именно на эту часть. Это пригодится и на собеседовании Full Stack Python Developer, и DevOps и Data Scientist.

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

Среды разработки

В мире питонических IDE все довольно просто: лидерство делят VSCode и PyCharm. За ними следует вереница универсальных сред разработки вроде Sublime. Здесь скучной документации почти не будет: развлекайтесь с красочными темами, тонко настраивайте среду под себя.

Деплой

Условно в эту категорию можно поместить инструменты, необходимые для развертывания и поддержания ваших программ:

• Git для грамотного хранения версий кода (так называемое версионирование)
• Docker для быстрой развертки копий программы на разных устройствах
• Kubernetes для непрерывного деплоя из репозитория для нескольких устройств
• Linux как типичная дешевая операционка для развертывания вашей программы

Фреймворки

Их, безусловно, больше двух, но для старта достаточно пощупать Django и Flask. И попутно задеть ngrok – утилиту для развертывания локальных серверов, хоть ее и отнесла в предыдущую категорию.

Сбор и хранение данных

Поскольку информации придается огромное значение, то и инструментария для ее сбора, обработки и хранения создали много. Углубляться в специализированные хранилища Big Data не станем на сей раз, это есть в роадмапе Data Science.

Но общепринятые принципы хранения понимать стоит точно. А это SQL (Structured Query Language – “структурированный язык запросов”).

Уставшие от этого застоявшегося в развитии стандарта разработчики создали NoSQL, однако огромная доля сервисов сегодня все равно придерживается первого варианта.

API

С этим разделом знаний знакомиться было непросто. Концепция программного интерфейса стала для меня прозрачной, только когда на работе без нее стало не обойтись. Если вы когда-нибудь собирали ботов в nocode-конструкторах, то наверняка задумывались, как извлекать логи разговоров. С этим и помогает API.

К примеру, в моей компании одного из ботов держат на конструкторе Aimylogic, из которого логи отдает Aimylogic Reporter API.

Боты

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

Разработка на JavaScript с нуля в 2022 году: дорожная карта

Чтобы создать своего Telegram-бота на Python, вы можете использовать библиотеки вроде aiogram. Познакомившись с одной, вам будет просто освоить и следующую: все они опираются на API мессенджеров вроде Telegram.

Тестирование

Эту рубрику вообще легко опустить, если вы нацелились в мир Data Science.

Однако в будущем это понадобится и MLOps – разработчику, непрерывно совершенствующему ПО на базе Machine Learning, так что пройтись по основам тестов стоит.

Для новичков отлично подойдет библиотека selenium – наглядный инструмент для автоматизации веб-серфинга. Попробуйте собрать свой UI-тест на selenium, как в этой статье, и для универсального старта этого будет предостаточно.

Data Science

В целом переход на должность дата-сайентиста часто рассматривается как следующая стадия развития Python-разработчика. Эта крупная ветка заслуживает отдельной дорожной карты по Data Science.

Дорожная карта Data Science 2023: пошаговый гайд

Заключение

Какой бы путь вы ни избрали, главное – искать любимое. Тогда можно пережить и невысокую зарплату джуниора, и сваливание на разработчика непомерного числа задач, и плохое качество ТЗ. В первые пару лет программисты часто скачут с проекта на проект, активно берутся за стартапы и некоммерческие проекты.

Но называть их job hoppers (“прыгающими с работы на работу”) не стоит, ведь именно на этом этапе они решают, какую специальность выбрать, а для этого нужно перелопатить сотни страниц документации, горы тредов на StackOverflow и даже разобраться со своим внутренним запросом к себе как профессионалу.

Детей в 17-18 лет перед университетом вынуждают выбрать профессию на всю жизнь, а с выбором “Каким разработчиком хочу стать?” задача точно такая же: только перепробовав, определитесь.

Дорожная карта программиста: что это, как ее составить и почему она обязательно нужна разработчику : Backend Developer

Ксения Кравченко

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

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

В данной статье разберемся, зачем она нужна, как правильно ее составить и где «подглядеть» роадмап для айтишников всех направлений ????

Зачем нужна дорожная карта

В каких случаях точно пригодится дорожная карта:

• Если вы джун и не знаете, куда и как развиваться дальше;
• Если вы «застряли» на одной позиции;
• Если вы хотите поменять направление разработки.

Например, представим, что… вы пару лет работаете QA-инженером. Но чувствуете, будто «уперлись в стену»: получаете не так много, как хотелось бы; все надоело и будущее на этой должности кажется каким-то бесперспективным.

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

Но как спланировать переход и сделать его максимально плавным? Вот тут на помощь приходит дорожная карта.

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

К тому же правильно (подробно) оформленная дорожная карта может здорово помочь во время подготовки к собеседованию. Например, с ней вы четко знаете, какие навыки изучили, а также где и по каким ссылкам можно освежить память, если вдруг это понадобится.

Роадмап бывает в виде:

• списка;
• схемы;
• таблицы;
• презентации.

Чаще всего он встречается в виде схем. Но вы можете оформить его как угодно — потому что пользоваться им только вам.

Как составить дорожную карту программисту

1. Определитесь с целью

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

Например, представим, что вы работаете Junior Python-разработчиком уже около года. Логично, что вы умеете в Python, MySQL, Git, Django и т. д.

Тогда ответьте себе на вопросы:

• Вы планируете развиваться дальше и становиться разработчиком уровня Middle или Senior?

• Вам наскучило выбранное направление и вы хотите попробовать себя в чем-то новом, но в рамках ИТ?

• Вы хотите углубляться в Python или подучить лучше другой язык?

Далее на них можно ответить примерно вот так соответственно:

• Если вы планируете развиваться в уже выбранном направлении, то посмотрите, какие навыки требуют работодатели от Middle- и Senior-специалистов.

• Если вам надоела разработка, то есть смысл присмотреться к смежным направлениям — менеджменту или аналитике, а заодно выписать навыки, которые требуются для желаемых позиций.

• Если вы хотите развиваться в Python, но при этом не относиться напрямую к отделу разработки, то приглядитесь к смежным направлениям в ИТ, которые чаще всего используют этот язык в работе. Например, Data-Science, аналитика и т. д.

В целом такой подход можно назвать универсальным. Замените слово Python на любой другой язык/языки и задайте себе наводящие вопросы.

Вопросы могут быть какие угодно. Главное на данном этапе — выяснить, как вы хотите развиваться (вертикально или горизонтально) и куда:

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

Горизонтальный рост — это расширение смежных навыков и знаний. К примеру, если UX-дизайнер решит стать продуктовыми дизайнером.

Но помните, что цель должна быть конкретной, измеримой, достижимой, релевантной и времязатратной (принцип SMART).

В чем суть этого пункта: у вас есть точка А, нужно выбрать точку B.

2. Определитесь с навыками

Для этого посмотрите, какие навыки требуют работодатели в вакансиях на желаемую должность (вашу точку B). Для этого подойдет тот же самый хх.ру.

• открываете любой job-сайт;
• вводите желаемую позицию;
• смотрите, какие навыки работодатели чаще всего запрашивают на нее;
• распределяете все навыки на этапы или модули.

Сейчас объясню.

Например. Допустим, вы хотите перейти из фронтенда в аналитику данных. Смотрите на хх.ру, что требуют в вакансиях на аналитика, и выписываете навыки. Получается примерно следующее:

• 1 модуль. SQL;
• 2 модуль. Python;
• 3 модуль. Excel;
• 4 модуль. Power BI;

1 модуль = 1 навык

Желательно отсортировать от наиболее распространенного навыка до наименее.

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

Статья по теме ???? 5 soft skills, которые помогут тебе дорасти до Senior-разработчика

3. Распланируйте свое время

Поставьте конкретные временные рамки на изучение каждого модуля.

Например. Представим, что вы решили с нуля вкатиться в IT и стать верстальщиком. Тогда это будет выглядеть так:

• 1 модуль. HTML/CSS — 2 месяца: с сентября по ноябрь 2023.
• 2 модуль. JavaScript — 6 месяцев: с ноября 2023 по май 2024.

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

Объясняю на примере 1 модуля:

1 модуль	HTML	CSS	Длительность изучения
Теги, атрибуты, элементы, списки изображения, адреса, ссылки и якоря, таблицы, формы.	Способы подключения, синтаксис, простые селекторы, составные селекторы, текст и шрифт, цвет и фон, display, блочная модель, float, clearfix.	2 месяца: с сентября по ноябрь 2023.

Все это можно удобнее оформить в таск-трекере, но об этом будет чуть ниже.

Статья по теме Повышаем свою продуктивность: 6 ключевых факторов

4. Приступайте к обучению

Есть два варианта, как начать двигаться к цели:

• Записаться на курсы. Это самый простой и относительно эффективный способ.

• Составить список из обучающих материалов. Это может быть все что угодно: ссылки на бесплатные курсы (их много на Stepik), тренажеры, образовательные платформы, видеоролики, книги, подкасты и так далее. Не забудьте приложить все полезные материалы к вашей «шпаргалке» — это пригодится, когда вы захотите освежить память перед собеседованием на новую должность.

Совет

Составляйте роадмап в пределах от 1,5 до 5 лет — это оптимальная временная перспектива. Делать дорожную карту на период от 5 до 10 лет и больше — точно не стоит.

Почему:

• Во-первых, IT-рынок слишком быстро меняется и вы вряд ли угадаете с трендами ближайшего десятилетия.
• Во-вторых, ставить перед собой грандиозные цели — классно. Но! Их будет сложнее правильно распланировать по шагам, а значит, появятся слишком высокие риски того, что вы не справитесь. Например, впадете в прокрастинацию (что часто случается перед масштабными задачами), передумаете в процессе и т. д.

Где составить дорожную карту

Дорожная карта — что это такое и чем она полезна разработчику? — Инди на DTF

Как одна простая схема помогла нам в разработке и продвижении цифровой настольной игры Fated Kingdom.

{«id»:34951,»gtm»:null}

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

Технологическая дорожная карта (англ. Technology Roadmap) — краткосрочный или долгосрочный план выпуска производителем какого-либо продукта.

Википедия, Свободная энциклопедия

В случае с геймдевом продукт — это игра. Например, наша Fated Kingdom. Это цифровая настолка для 2-4 человек с полной свободой действий в сеттинге темного фэнтези. Разработка велась с весны 2016 года, а 28 мая игра стала доступна в раннем доступе Steam. Всего в команде два человека: геймдизайнер/художник и программист.

Ранний доступ — это не релиз, а лишь один из шагов к нему. При отсутствии четкого планирования процесс «допила» игры может растянуться на несколько лет, даже когда в команде достаточно кадров. За доказательствами далеко ходить не нужно: в Steam есть десятки игр, для которых плашка «Early Access» стала приговором. Иногда даже смертельным.

Даже крупные проекты подолгу «висят» в раннем доступе. Например, DayZ пробыла в нем пять лет. Чего не хватило девелоперу, что все так затянулось? Денег? Нет, игра стала хитом еще в декабре 2013. Может быть умелых кадров? Сомнительно, учитывая штат Bohemia Interactive в 211 человек. А вот планирования и четкого видения будущего проекта — запросто!

Дорожная карта DayZ на 2015 год

С самого начала разработчики не имели представления, какой игра должна стать на релизе. В сети есть дорожная карта образца 2015 года, где расписана работа на каждый квартал, но после этого у команды DayZ с планированием как-то не задалось. Результат — релиз через три года и смешанные отзывы от фанатов, которые банально устали ждать.

Вряд ли отсутствие дорожной карты — это главная причина такой ситуации. Но как минимум одна из причин затянувшейся разработки и не самого радушного приема релизной версии сообществом. Почему? Об этом мы и поговорим далее по тексту.

Разработка 3D-игры с мультиплеером и графикой с упором на реализм — задача, мягко говоря, не самая простая, особенно когда речь идет о дебютном проекте. Нужно продумывать множество разных аспектов и тщательно вести дизайн-документ, а также все сопутствующие материалы, чтобы не утонуть в идеях и краткосрочных задачах, раздувая сроки раз за разом.

Один из первых прототипов Fated Kingdom, до раннего доступа все пришлось переписать по несколько раз из-за отсутствия строгого планирования

Каждой команде стоит вести дорожную карту хотя бы внутри коллектива. Это помогает более трезво оценивать объем работ и сроки. Когда мы начинали делать Fated Kingdom, то первое время рассчитывали добраться до раннего доступа за год. И только потом, когда поняли, что сильно ошиблись, решили серьезно взяться за дело и набросали первый план разработки.

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

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

Позже мы пробовали использовать Trello в качестве интерактивной дорожной карты, но поняли, что гораздо удобнее организовать работу в этом сервисе по другим принципам. «Трелло» — это очень гибкий инструмент, который позволяет не только выстраивать структуру проекта в виде карточек, но и быстро ее наращивать, добавляя вложения, комментарии, ссылки, описания и теги.

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

Каждые несколько месяцев Bungie публикует план разработки Destiny 2

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

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

Руководство по дорожной карте продукта: что она из себя представляет и как ее создать

Краткое описание: дорожная карта продукта — это стратегия долгосрочного развития продукта или решения.

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

В процессе agile-разработки дорожная карта обеспечивает необходимый контекст для ежедневной работы команды; она должна меняться вслед за изменениями в конкурентной среде.

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

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

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

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

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

Дорожные карты бывают разных форм и предназначены для различных аудиторий.

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

Среди распространенных версий — карты со сведениями о приоритетных ценностях для поставки клиентам, целевых датах релизах и контрольных точках.

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

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

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

Внутренние дорожные карты для отдела продаж. Акцент в этих дорожных картах сделан на новых возможностях и преимуществах для клиентов.

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

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

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

Самым большим преимуществом дорожной карты продукта является стратегическое видение, которое она дает всем заинтересованным сторонам. Дорожная карта соотносит более крупные цели продукта и компании с трудозатратами на разработку и тем самым объединяет команды и согласовывает их действия вокруг общих целей по созданию великолепных продуктов.

• Руководству организации дорожная карта предоставляет обновленные сведения о состоянии запланированных функций и улучшений в понятном формате, соответствующем целям компании.
• Для владельцев и менеджеров продуктов дорожные карты объединяют команды, работающие над важными улучшениями продуктов, и позволяют удобно сообщать о приоритетах и причинах такой приоритизации смежным командам.
• Самим разработчикам дорожные карты дают представление о ситуации в целом, которое позволяет участникам команды сосредоточиться на наиболее важных задачах, избежать изменений объема работ и быстро принимать самостоятельные решения.

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

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

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

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

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

Слишком тщательная или недостаточная проработка деталей в дорожной карте может дать чересчур поверхностное представление о продукте или, что еще хуже, отпугнуть читателя.

Дорожная карта с нужным количеством деталей и некоторой визуальной привлекательностью способна обеспечить необходимую вовлеченность основных заинтересованных сторон.

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

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

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

Такая иерархия позволяет команде по продукту и команде разработчиков принимать решения вместе и дает представление о том, как тот или иной объем работы укладывается в общую картину.

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

Дорожная карта должна обновляться так часто, как это необходимо (каждую неделю или две), чтобы оставаться достоверным источником информации. Неактуальная дорожная карта подрывает эффективность работы, как все мы чувствовали это в тот или иной момент времени.

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

Подобные единичные запросы указывают на недоверие к карте и огромные потенциальные затраты времени.

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

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

Если на обновление дорожной карты вы тратите время, которое можете (и должны) тратить на реализацию проекта, подумайте о том, чтобы изменить график и способы получения входных данных, обратной связи и данных со всей компании, чтобы расставить приоритеты для своих инициатив.

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

• Подробностей в дорожной карте должно быть ровно столько, сколько требуется аудитории.
• В дорожной карте должен сохраняться баланс: она в равной степени должна ориентироваться на краткосрочные тактические задачи и на их связи с долгосрочными целями.
• Регулярно просматривайте дорожные карты и вносите коррективы при изменении планов.
• Убедитесь, что у всех есть доступ к дорожной карте (и что к ней регулярно обращаются).
• Оставайтесь на связи с заинтересованными сторонами на всех уровнях, чтобы обеспечить согласованность действий.

Готовы создать собственную дорожную карту? Начните работу бесплатно с Jira Product Discovery.