Рано или поздно всем нам что-то надоедает. И хорошо, если это старые добрые кеды с первого курса универа. Хуже, когда долго мучаешься над тем, что уже давно не приносит удовольствия. Например, работа в долгоиграющем проекте. Старина Фреденберг сказал бы, что у вас профессиональное выгорание. А мы скажем, что вы засиделись на своем проекте и вам пора сменить доменную область. То есть, отрасль в которой вы работаете: будь то автомобилестроение, e-commerce или мобильная реклама. Нет, не стоит сразу бросаться писать заявление на увольнение, собирать вещи в коробку и уходить в закат на поиски сокровищ Эльдорадо. Но что же делать? Засунуть голову в песок и остаться на месте, или рискнуть и сорвать джекпот? Рассказываем как наименее болезненно сменить доменную область и остаться в живых, не свернув с тропинки благоразумия.
Разберемся в терминологии
Доменные знания — понимание системы. Какие технологии нужно использовать для решения поставленных задач, какие специалисты выполняют работу и сколько времени им потребуется, чтобы совершить определенные действия. Приведем пример: вот есть некий абстрактный человек в вакууме. У человека есть много разных органов и всячески полезных частей тела. Так вот, за функционирование отдельных частей тела отвечают разные специалисты. Стоматолог — носитель знаний доменной области здоровья зубов, а офтальмолог — зрения. Но и первый, и второй — обладают обязательными знаниями в области общей медицины. По такой же аналогии работает софтверная разработка: проектный менеджер, работающий в мобайле — носитель знаний доменной области мобильной разработки, тогда как в вебе РМ должен разбираться в другом стеке технологий и понимать специфику работы фронтенд и бэкенд разработчиков. При этом, и тот и другой должны хорошо разбираться в специфике управления проектами и знать основные фреймворки.
Понять, как приобретать знания доменных областей нам помог Ярослав Ротарь — основатель IAMPM, преподаватель курсов DAO PM, Techmind и Middle PМ, проджект менеджер с опытом работы более чем со 100-та проектами.
Что делать, если релевантного опыта нет, а желание перейти в новый проект — есть?
Если заказчика смущает тот факт, что вы еще не работали с подобными проектами, а у вас нет времени на то, чтобы хорошо разобраться в теме — то это три ночи в поисковике, чтение статей, осознание того, какой контент присутствует и попытка его переварить. Чтобы развеять сомнения заказчика — предложите свой вариант решения, покажите, что разбирались в вопросе и заинтересованы в наилучшем результате.
С чего начать ознакомление с новой областью?
По мере работы в большом проекте, ты сталкиваешься с совершенно разными технологиями. Как бы банально это не звучало, первым делом нужно сходить в гугл. Предлагаю рассмотреть кейс: заказчик приходит и говорит “мы хотим разработать супер-систему, которая будет позволять пилотам дельтапланов в Лондоне получать быстрые заказы, подбирать их в точке и перевозить через специальные летные маршруты». Если вы никогда с подобным не сталкивались, то понятно, что это вас несколько удивит.
Первый шаг: разбираемся с глоссарием, чтобы понять на каком языке говорит заказчик, и что обозначают термины. Это необходимый минимум для входа.
Второй шаг: обращаемся к эксперту, который есть в ближайшем доступе. Можно написать, позвонить, сходить на форум за краткой консультацией. На моем опыте, иногда даже 15-ти минутный разговор с человеком, который погружен в технологию уже 5-10 лет, помогает обрести знания, которых не было даже у заказчика.
Третий шаг: полное погружение в проект и практика. Здесь часто помогает банальный энтузиазм, желание понять о чем идет речь и умение правильно задавать вопросы, непосредственно, самому заказчику — то есть тому, кто будет ставить РМ-у задачи. Если все эти составляющие склеить в одну, то этого будет более чем достаточно, чтобы погрузиться в проект.
Что можешь посоветовать тем, кто хочет перейти от технологии к технологии?
Если необходимо перейти от технологии к технологии, здесь проще — большинство компаний с радостью делятся своими кейсами и рассказывают, как они применяли ту, или иную технологию. Потому вы идете к своей любимой команде и спрашиваете, как это работает. Или идете к разработчикам — умных ребят немало. Но никогда не бегите к умным людям с вопросом “с чего мне начать?”. Нет ничего страшнее человека, который вообще не попытался разобраться, но спрашивает специалиста, который проработал 5-10 лет: «Расскажи мне все, что ты знаешь». Скорее всего, человек сильно удивится. Лучше постарайтесь заранее изучить тему, а потом прийти с конкретными вопросами. Это уважается и чувствуется. Еще можно пообщаться со спикерами профильных мероприятий.
Стоит ли ходить на технические мероприятия для разработчиков?
Да, но не на все. Выбирайте те, на которых получите ответы на такие вопросы:
Какие технологии мне нужно использовать, для каких проектов? То есть, если вы работаете в мобайле, в такой-то сфере часто используют технологии, относящиеся к мобайлу.
Где эти технологии максимально результативны, а где они несут некую угрозу?
Полезно, также, узнать где можно найти нужного специалиста или как узнать его стоимость. Если мероприятие не отвечает на эти вопросы, а раскрывает технические детали, оно тоже полезно, но если мы говорим о старте работы в новой доменной области — это будет излишне и только запутает.
Нужно понимать, что не ко всем проектам применимы эти советы. Бывают проекты, информация о которых отсутствует в свободном доступе, потому что они находятся в государственном, военном или финтех секторе. Если информацию нельзя найти в интернете, говорите, что принесете пользу в другом и подтянете доменные знания. Занимайтесь тем, что любите, развивайте свои hard и soft skills, и будет вам счастье.