Управление продуктами и проектами что это

Продукт VS проект: отличия подходов

На связи Factory5 (входит в группу Ctrl2GO) — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.

И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании, и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но Резеда Несынова, исполнительный директор Factory5, разложила всё по полочкам.

Продукт и проект — основные отличия

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

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

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

По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.

Объект управления

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

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

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

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

В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».

Эффективность — на что ориентируемся

не превысить плановую себестоимость,

выполнить требования заказчика.

маржинальность, за счет монетизации и продвижения,

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

Требования — как ими управлять

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

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

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

Структура работы — как работаем

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

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

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

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

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

Ответственность — кто за что отвечает

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

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

Особенности работы в продукте и проекте

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

Проект не равно продукт

Есть мнение, что результатом проекта является продукт. Это не правда.

Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:

Проект ориентирован на одного клиента и его специфические требования.

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

ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:

материалы для продаж,

настроенная служба поддержки и т.д.

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

Резюмируем

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

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

Источник

Проект или продукт: чем отличаются обязанности Project Manager и Product Manager

Сергей Мацнев, директор проектного офиса в Sifox, рассказывает о сходствах и различиях двух профессий.

Кто такой Project Manager

Должность руководителя проекта существует довольно давно. Профессия хоть и не древнейшая, но на строительстве пирамид протопроджекты скорее всего уже задействовались. Официально эта роль была стандартизована в 1960-е в США, тогда же появился институт управления проектами PMI.

Для понимания роли менеджера проектов важно уточнить, что такое проект. Согласно определению PMI,

проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Всё, что нужно знать о рекламе в мобильных играх

Аналитический обзор Gameloft: рекламные форматы, портрет аудитории, надёжные бенчмарки.

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

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

Кто такой Product Manager

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

Термин «продукт» трактуется уже не так однозначно, как проект, но можно ориентироваться на следующее определение:

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

Выглядит довольно однозначно.

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

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

Какие должны быть навыки у продакт- и проджект-менеджеров

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

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

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

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

Сходства и различия

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

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

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

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

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

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

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

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

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

Источник

Продакт и проджект: кто такие, чем отличаются и как ими стать

Как выучиться на самые актуальные менеджерские профессии

Продакт- и проджект-менеджер — две разные, но одинаково популярные современные профессии.

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

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

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

На самом деле продакт анализирует рынок и конкурентов, общается с пользователями, закапывается в аналитику, проводит эксперименты, анализирует и разрабатывает пользовательские сценарии.

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

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

В 2016 году я проходил курсы по продуктовому менеджменту от «Нетологии», но они на самом деле были больше про проджект-менеджмент и управление проектами, поэтому не сильно помогли. Реальные знания пришли с опытом, первыми шишками, болью и страданиями. Из академического были только статьи и книги, например «Спроси маму», «Бизнес с нуля. Lean Startup».

Как победить выгорание

Как еще можно стать продактом

Курсы. На рынке много глубоких курсов для продактов — какие-то чуть хуже, какие-то лучше, но все довольно хорошие. Длятся они, как правило, год, некоторые — 14 месяцев. Они хорошо погружают в профессию, ее специфику и весь пул задач. Можно пройти длинный курс, а можно — двухмесячный Go Practice. Он тоже будет считаться кейсом, который можно прикрепить в портфолио. Go Practice — это крутая штука, которая за два месяца научит мышлению продакта и тому, как подходить к задачам с точки зрения данных.

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

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

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

Ошибки на старте и эффект Даннинга — Крюгера

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

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

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

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

Как я набираю новых продактов

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

После выполнения тестового формируется огромная табличка. Я создаю воронку: оцениваю кандидатов по четырем критериям, отбираю топ-10 и созваниваюсь с ними по «Зуму». На этом этапе важно определить их культурный код: насколько человек близок мне по духу и кайфово ли будет с ним работать. Тут нет определенных критериев — только ощущения и интуиция.

Я задаю им 20—30 объемных вопросов. Есть базовые, чтобы понять, что вдохновляет человека и как он решил стать продактом. Спрашиваю про задачи и о том, что принесло наибольшее удовлетворение за последний год. Когда последний раз учился и чему, с каким руководителем хотел бы работать, что важно в работе. Эти вопросы раскрывают мотивацию человека.

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

Стоит ли идти в профессию

Понять, ваше это или нет, можно только в боевых условиях. Курсы, книги и лекции нужны скорее для общего понимания. Они также помогут для расширения навыков, когда вы уже определились.

Финансовые перспективы продактов. В Москве талантливые джуны могут зарабатывать от 70 до 120 тысяч рублей. Мидлы — от 120 до 200 тысяч, но чаще в районе 150—160 тысяч рублей. Сениоры — от 200 до 260 тысяч рублей, CPO и Head of Product получают от 260 тысяч и выше.

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

В конце 2018 года почувствовал, что перестал получать удовольствие от работы, и захотел все поменять. Мои проекты были связаны со сферой обслуживания, а денег в городе больше не становилось. Передо мной стоял выбор: или кредитоваться, чтобы расширить бизнес и отъесть доли конкурентов, или закрываться. Я не чувствовал, что готов брать кредит, поэтому разбирался, какие у меня есть профессиональные возможности дальше.

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

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

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

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

До ИТ у меня уже был практический опыт управления проектами и собственными бизнесами, но при этом я никогда не управлял разработкой. Во всякие курсы я не верю: считаю, что при наличии интернета и умения искать можно и самому набраться знаний, чтобы попасть в проджекты. Я читал много материалов на «Хабре» и vc.ru, в которых люди делились историями о проблемах в разработке, — мне помогло.

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

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

У нас крутая компания, и в ней много хороших специалистов. Именно там я начал регулярно общаться с разработчиками, узнавать технические подробности и особенности того, чем мы занимаемся. Например, если у нас был проект, связанный с видео, то я изучал, как конкретно он работает «под капотом» и почему именно так. На некоторых проектах активно лез в код, изучал его, гуглил неизвестное. Как обычно, помогал «Хабр»: к примеру, у команды разработки «Одноклассников» хорошие статьи про видео.

В итоге спустя шесть месяцев работы в компании я прошел аттестацию и стал просто проджектом, без приставки «джун». На этом не остановился и продолжал читать технические статьи и всякое разное про менеджмент. Неплохими книгами показались «Scrum и Kanban: выжимаем максимум», «Человеческий фактор. Успешные проекты и команды» и «45 татуировок менеджера. Правила российского руководителя». Кроме чтения книг и статей, все это время я наращивал практический опыт просто в процессе работы. Еще через полгода я прошел аттестацию и получил повышение до сениор-проджект-менеджера.

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

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

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

Как стать проджектом

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

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

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

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

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

Источник