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

Обзор сертификаций в области управления проектами

Мы изучили актуальные на лето 2019 года сертификации по проектному менеджменту. В статье представлены как международные сертификации, так и их российские аналоги.

PMI (Project Management Institute) – организация, занимающаяся разработкой методологии в области проектного менеджмента. Система обучения подробно описана в американском стандарте PMBOK. PMI олицетворяет процессуальный подход в управлении, в котором стандартизировано планирование, реализация, контроль изменений и завершение проекта.

Различают несколько сертификаций под эгидой PMI

  • PMP (Project Management Professional) – подтверждает знания и умения по стандарту PMBOK. Действует с 1984 года и предназначена, в основном, для руководителей проекта. Для допуска к экзамену (тестированию на ПК) необходимо минимум 3 года работать в отрасли, иметь высшее образование (бакалавр и выше). Сдавать экзамены можно как в США, так и на территории РФ. В последнем случае сдача проходит в одном из центров тестирования Prometric и на русском языке. Сертификат действует 3 года с возможностью продления. Стоимость сдачи экзаменов – 405 $ для членов PMI и 555 $ для остальных.
  • CAPM (Certified Associate in Project Management) – «упрощенный» вариант PMP со смягченными требованиями к кандидатам. Подойдет для потенциальных членов команды проекта. Для допуска к экзаменам достаточно иметь среднее образование и 1 год работы в проектах. Сертификат действует 5 лет и стоит 225 $ для членов PMI и 300 $ для остальных кандидатов.
  • PgMP (Program Management Professional) – «продвинутая» программа, для сдачи экзамена необходимо иметь 4-х летний опыт работы в качестве проектного менеджера. Экзамен стоит 800 $ для членов PMI и 1000 $ для остальных кандидатов. Сертификат подтверждает способность специалиста управлять несколькими связанными проектами. Срок действия PgMP – 3 года.
  • PMI не требует обязательного прохождения курсов для доступа к экзамену, достаточно использовать материалы онлайн-библиотеки. Тем не менее, на сайте института представлен список аккредитованных учебных центров во всех регионах.

    IPMA (International Project Management Association) – швейцарская организация, создавшая европейский подход в проектном менеджменте, основанный на развитии навыков и компетенций специалистов. Подробно идеи подхода озвучены в стандарте PM ICB.

    IPMA работает через систему национальных отделений в 68 странах мира, в том числе и в России. Каждое отделение разрабатывает собственный стандарт, который учитывает особенности местного законодательства и экономики, и сертифицирует специалистов. В России эти функции возложены на организацию СОВНЕТ, которая обучает и готовит специалистов к экзаменам.

    Сертификация IPMA действует с 1998 года и состоит из 4-х уровней:

  • Уровень D – участник проекта, технический специалист, младший менеджер. Это самая простая сертификация, здесь нет требований по опыту работы, достаточно иметь степень бакалавра. За доступ к экзамену нужно заплатить 350 $ для членов IPMA и 450 $ для всех остальных.
  • Уровень С – руководитель проектов. Требования по опыту работы: 3 года на должности менеджера проектов. Стоимость для членов IPMA – 995 $, для остальных кандидатов — 1225 $.
  • Уровень B – старший руководитель проектов, который одновременно может курировать несколько проектов. На момент подачи заявления нужно подтвердить 3-х летний опыт работы. Стоимость – 1195 $ для членов IPMA и 1425 $ для всех остальных.
  • Уровень A (высший уровень) – директор проектов, вице-президент, топ-менеджер, который контролирует проектный портфель компании. Для доступа к экзамену необходимо подтвердить 5-летний опыт работы в качестве руководителя программ. Стоимость – 1495 $ для членов IPMA и 1725 $ для остальных.
  • Каждый сертификат выдается на 5 лет, есть возможность его продления. Для соискателей сертификации уровня D экзамен проходит в виде письменного тестирования, для всех остальных – тесты + командное решение кейса + личное собеседование.

    Сертификация PRINCE2

    Методология PRINCE2 используется как базовый стандарт для управления проектами на территории ЕС, Великобритании и в рамках ряда подразделений ООН. Методология разработана в 1996 году Секретариатом кабмина Великобритании, а в 2013 году права на товарный знак PRINCE2 перешли компании AXELOS. В основе методологии – трехуровневое управление проектами, четкое распределение задач между участниками.

    Сертификация состоит из двух уровней:

  • Foundation – наличие сертификата подтверждает глубокие знания методологии PRINCE2, готовность работать в команде в качестве техспециалиста, менеджера проекта или его ассистента. Требований по опыту работы или образованию нет.
  • Practitioner – для проектных менеджеров, руководителей проектов. Необходимо иметь сертификацию предыдущего уровня или один из продуктов PMI или IPMA.
  • Экзамены проходят в форме тестирования, они доступны на русском языке, можно сдавать в одном из аккредитованных тестовых центров, которые сотрудничают с AXELOS. Стоимость экзаменов зависит от выбранного центра. В основном, один экзамен стоит в диапазоне 14-18 тыс. руб. На момент получения сертификата необходимо быть членом PRINCE2 и ежегодно оплачивать членский взнос в размере 50 фунтов (66,39 $).

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

    Сертификация ПМ СТАНДАРТ (PM STANDARD)

    Отечественный аналог международных сертификаций, основанный на российских подходах, практиках и ГОСТах. Программный продукт разработан ЦОРПУ (Центром оценки и развития проектного управления).

    Есть несколько уровней ПМ Стандарт:

  • Базовый уровень – соответствует позиции участника команды проекта, подтверждает наличие знаний и навыков в части проектного управления, в том числе, опираясь на стандарты ГОСТ и ИСО. Стоимость экзамена – 7000 руб.
  • Координатор проектов – состоит из нескольких модулей: специалист проектного офиса, руководитель проектов, сложных и комплексных проектов. Стоимость экзамена – от 10 до 32 тыс. руб. Необходимо подтвердить опыт работы (от года до пяти лет в зависимости от выбранной компетенции), и предоставить сертификат базового уровня (или сертификат PRINCE2, PMI или IPMA).

  • Залог успешного прохождения сертификационного испытания — качественная подготовка.

    Сроки действия сертификатов – 5 лет. Проходить сертификацию можно в одном из 35 региональных центров или удаленно в режиме онлайн. ЦОРПУ предлагает 3 бесплатные попытки тестовой сдачи экзамена. Учиться можно как самостоятельно, так и при помощи аккредитованных партнеров учебных программ. Их список представлен на официальном сайте ЦОРПУ.

    Востребованность сертификаций в СНГ

    Мы сделали небольшое исследование и посчитали количество вакансий на рынке СНГ (Россия, Украина, Белоруссия, Казахстан) с явно указанными требованиями знания PMBOK, PRINCE2, IPMA, PM STANDARD. Искали на сайтах hh.ru, hh.kz, jobs.tut.by и hh.ua и получили такие результаты:

    PMI IPMA PRINCE2 PM STANDARD
    Россия 428 82 66 12
    Казахстан 8 9 2 1
    Белоруссия 3 1 2
    Украина 5 3 3

    Наибольшей востребованностью среди работодателей пользуется сертификация PMI. На втором и третьем месте примерно с одинаковыми показателями идут IPMA и PRINCE2. Вакансий, где требуют сертификат ПМ СТАНДАРТ, мало. Скорее всего, это связанно с высоким доверием работодателей к международным сертификациям.

    Вот основные сферы, где ищут сертифицированных менеджеров и руководителей проектов:

    • IT и телеком;
    • строительство;
    • производство;
    • руководящие посты в крупных компаниях любой сферы.
    • Работодатели разделились на две категории:

      1. Первая категория указывает сертификаты PMI/IPMA/PRINCE2 как существенный плюс кандидату.
      2. Вторая категория указывает наличие сертификатов по стандартам проектного управления (PMP, IPMA, PRINCE2) в разделе обязательных требований.
      3. Если обобщить, то работодатели ждут от соискателей знание методологий и умение применять их на практике, знание соответствующего ПО, опыт управления процессами и командой.

        Вопросы начинающих: чем отличается проектный менеджер от бизнес-аналитика?

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

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

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

        Вопрос 2: Например, при собрании и моделировании требований от клиента/покупателя, чем отличается задача проектного менеджера и бизнес аналитика?Бизнес аналитик разговаривает с клиентом, получает требования, моделирует, а потом передает их технической команде. Затем начинается непосредственно разработка, работа над структурой приложения, к примеру. Где тут проектный менеджер? Бизнес аналитик выполняет за проектного менеджера его работу?

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

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

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

        Вопрос 3: проектный менеджер не направлен на коммуникацию с клиентом, даже если в проект вносятся изменения во время разработки?

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

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

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

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

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

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

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

        Бизнес аналитик — лицо проекта, потому что заказчик общается непосредственно с ним.

        Запись и перевод: Ольга Мезенцева

        Источник: https://www.youtube.com/watch?v=CaCuxGtp2xQ&t=1916s

        Автор: Abhishek Srivastava, Experienced IT professional, Индия

        Требования проектный менеджер

        Менеджеры проектов не нужны

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

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

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

        Примечание редактора: этот текст — результат доклада Дмитрия Круглова из компании Arrival на митапе «Пиэмная».

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

        Управление проектами — не прерогатива IT. Это наука, которой больше 50 лет. Наука, у которой есть своя священная книга. Конечно, PMBoK не единственная в своем роде, есть PRINCE и, наверняка, ещё несколько книг, более-менее претендующих на лавры. Но PMBоK является основой международных стандартов и это говорит о её высоком уровне признания. Так что будем отталкиваться от неё.

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

        Например, управлять проектными требованиями. Или управлять ожиданиями. Может быть вы помните про управление сроками. Наверняка коллеги, представляющие бизнес, регулярно спрашивают, когда именно будет готова та или иная задача. Может быть вы вспомните про управление стейкхолдерами, что встречается гораздо реже. Ещё что? Управление коммуникациями. Последнее встречается так же редко, как стейкхолдеры. А ведь это важная и непростая задача в наше время, когда все участники проекта предпочитают делиться важной информацией в Telegram, вместо требуемых по уставу проекта электронных писем. Как тут управлять коммуникациями, если вас просто не зовут в чат, в котором обсуждают, например, качество вашей работы?

        Сравните то, что удалось вспомнить, с перечнем из PMBoK:

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

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

        Что является артефактом работы менеджера проектов? Из всех возможных артефактов, включая сообщения в Telegram: «Добавьте меня, наконец-то, в ваш чат, я не могу без этого управлять проектом!», — в первую очередь я бы отметил диаграмму Гантта. Это прекрасный инструмент, который может ответить на множество вопросов про проект и помогает визуализировать большинство областей деятельности менеджера проектов. Ведь хорошая диаграмма Гантта содержит в себе сроки, ресурсы, стоимость, зависимости. Туда можно добавить в качестве задач требования по коммуникациям. Можно добавить даже управление стейкхолдерами и их ожиданиями с помощью вех и описания ожидаемого результата. Получается универсальный инструмент на все случаи жизни.


        Большая часть задач этих областей решается через управление одной сущностью — диаграммой Гантта.

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

        Что же получается: у нас есть профессия, есть деятельность и есть хороший артефакт, как ее результат. Так в чем подвох?

        Всё дело в нюансах. Вот, например, с Ганттом не все так хорошо.

        Во-первых, диаграммы больших проектов рано или поздно становятся нечитаемыми. У меня был опыт работы с проектом масштаба «больше года» в Microsoft Project. Чтобы распечатать его план, нужно было склеивать шесть листов A4. На одном листе текст получался слишком мелким.

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

        В-третьих, надо признать, что многие диаграммы никто, кроме самого менеджера проекта, не читает. Получается, что этот артефакт произведен PM-ом и ему же одному нужен и понятен.

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

        Если попробовать погуглить тему полезности менеджеров проектов в IT, станет понятно, что эта дискуссия ведется давно. Она успела стать очередным холиваром, как, например, противостояние любителей iOS и Android, Windows или OS X. Только цитаты в результатах поиска ещё более эмоциональны: «Нужны ли нам PM?», «Почему мы решили избавиться от PMов», «Является ли работа PM-а бесполезной?».

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

        Начиная работать в компании, где у меня есть задача построить в очередной раз команду разработки с нуля, я осознал, что на ближайшие полгода-год у меня нет задач для PM-а. Сначала я его добавил в оргструктуру по привычке. А потом своей же рукой и вычеркнул. Вычеркнул интуитивно, но задался вопросом: «Почему так получилось?».

        Мое исследование причин привело к пониманию, что IT обладает рядом уникальных качеств, которые позволили внедрить гибкие методологии. Существует классическое сравнение: строительство дома и разработка программного обеспечения. Это в чём-то похожие дисциплины, недаром в обеих есть роль архитектора. И там, и там существует набор функциональных и нефункциональных требований, существует инфраструктура, внутренние коммуникации, сборка, доставка и интеграция.

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

        В IT продукт цифровой. И производственный цикл может быть очень коротким. За два десятка лет мы смогли создать инструменты и технологии, которые привели к появлению гибких методологий разработки. Тут я готов спорить, что причинно-следственная связь именно такая: возможность быстро экспериментировать и получать работающий результат привела к тому, что возникли методологии, как именно это делать. Конечно, это короткая положительная обратная связь, и следом продолжили развиваться инструменты. А потом опять доработали методологии. И так далее по спирали мы несемся ко все более и более короткому time to market.

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

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

        Поэтому в гибких методологиях поступают просто — говорят одному человеку от бизнеса что-то в духе: «Ты крайний за деньги, за трафик и за конверсию. И нам, если честно, все равно, что и с каким приоритетом ты делаешь в продукте. Главное, чтобы к концу года конверсия выросла с 1% до 1,1%, а то проект убыточен». И PO получает право единолично принимать решения, сам определяет приоритет, создает соответствующие артефакты (планы, roadmap-ы, требования) и забирает кусок работы у PM-а.

        Лет десять назад в IT начали менять устоявшуюся архитектуру.

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

        Не сказать, чтобы это было новой идеей. Как называют универсальных разработчиков? Full stack. Один из разработчиков старше 30 лет на собеседовании сказал: «Я был full stack разработчиком во времена, когда термина full stack еще не существовало». Когда-то мы все были фулстеками, потому что нужно было делать вообще всё, включая администрирование баз данных и настройку компьютера директора.

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

        Системный аналитик (SA)

        Системный аналитик — не новая роль, и во многих Agile методологиях её нет. Не берусь утверждать наверняка, но возможно в явном виде она есть в SAFE. Но SAFE, в целом, пограничная методология. Тем не менее, эта роль крайне полезна и интересна. Она, как смазка в сложном механизме, позволяет ему работать тихо и гладко. Системный аналитик это частично владелец продукта, частично архитектор. Он уточняет и детализирует требования бизнеса до уровня конкретных фич. Лучшие из системных аналитиков способны продвигать свои идеи и видение в обе стороны, используя комбинацию технической грамотности и soft skills. Там, где работают системные аналитики, менеджер проекта лишен деятельности по управлению требованиями.

        Scrum Master сильно потеснил роль менеджера проекта. Жаль, что сейчас сами SM стали кандидатами на вымирание.

        Серьезно, рано или поздно Scrum Master будет преподавать в школах. Будут уроки про Agile, где Scrum Master будет рассказывать 12-летним школьникам, как работают гибкие методологии и какие существуют практики. Уже сейчас опыт работы по Agile стал повсеместным явлением среди разработчиков. На интервью 19 из 20 человек работают по двухнедельным итерациям, а разговор о процессах превращается в перечисление их параметров:

        — В чем оценка?
        — Story Points.
        — Какой Velocity?
        — 68.
        — А как планируете проекты?
        — В «маечных» оценках S, M, L.

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

        Конечно, так не везде. Наверняка есть много компаний, которые нужно дотягивать до рыночных стандартов и это не быстрый процесс. В России и через 10 лет можно будет найти работу Scrum Master-ом в каком-нибудь «Леноблхозпромлесповал», когда организация решит своих трех программистов перевести на Agile.

        За время своей популярности Scrum Master-а успели полностью забрать у PM-а все вопросы внутри проектной команды. Забрали не на себя, а на членов команды, фасилитируя их вовлечение в проектную работу. Это, кстати, заметно подняло уровень зрелости IT в глазах бизнеса.

        Или всё-таки не нужны

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

        Что же осталось у менеджеров проектов после этого? Остались коммуникации, интеграция и закупки. Кажется, не так много, чтобы держать на этой роли выделенного человека? Самое время сказать, что PM-ы не нужны. Но нет.

        Есть категории IT-проектов, в которых без выделенного менеджера провал практически гарантирован.

        Проекты в реальном мире

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

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

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

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

        Проекты с большой ценой ошибки

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

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

        Проекты без части ролей

        Жизнь — суровая штука, и взять по выделенному человеку на каждую из ролей не всегда возможно. Пока мир не совершенен, останутся PM-ы, которые выполняют работу Product Owner-а. Или PM-ы, которые де-факто работают техлидами. Такие совмещения часто свойственны стартапам.

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

        Текст подготовили:
        Автор — Дмитрий Круглов
        Редакторы — Евгений Шкляр, Денис Вонсаровский
        Мнение автора по некоторым вопросам может не совпадать с мнением редакции блога и компании Яндекс.Деньги.

        Ключевые навыки менеджера проектов

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

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

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

        Качества менеджера проекта

        Гибкие навыки для себя:

      4. умение переспрашивать до тех пор, пока в голове не сложится ясная картина;
      5. умение быть в меньшинстве и не терять самообладания, когда не поддерживает тебя;
      6. стрессоустойчивость;
      7. привычка работать в многозадачном режиме. Поможет правильно распределять свою нагрузку, приоритизировать задачи, принимать правильные решения в меняющихся условиях и под давлением;
      8. любовь к сложностям и необычным задачам;
      9. критическое мышление. Поможет выходить из сложных ситуаций.
      10. Для работы с командой:

      11. оптимизм. Как бы всё ни было плохо, ты должен поднимать настрой клиенту и команде и не переносить на них свои страхи;
      12. пунктуальность;
      13. умение оценивать срочность задач, отделять важное от второстепенного, не паниковать и не кидаться решать задачу сразу, когда она появилась;
      14. умение формулировать свои мысли;
      15. хорошо развитая эмпатия, чтобы правильно улавливать состояние клиента и участников команды;
      16. аналитический ум. Поможет взвешивать имеющиеся данные и факторы, чтобы оценивать риски, пессимистичные и оптимистичные сценарии и выводить из них нечто реалистичное. Это поможет управлять ожиданиями клиента;
      17. самоорганизация и эффективное управление временем. Поможет грамотно управлять задачами и укладываться в дедлайны;
      18. умение находить нестандартные решения;
      19. Для работы с клиентом:

      20. желание докопаться до сути вещей, постоянно задавать себе вопросы «чтобы что?», «почему так?» ;
      21. исполнительность;
      22. гибкость ума;
      23. коммуникабельность и грамотная речь. Важны, чтобы правильно донести информацию о принятых решениях, мотивировать команду, направить клиента на размышления в полезном для проекта русле.
      24. Инструменты менеджера проекта

        • Slack, Skype, Telegram — мессенджеры и средства связи. Всё ремесло менеджера держится на умении коммуницировать, поэтому вы будете проводить очень много времени в этих приложениях. Переписки нужно обязательно сохранять;
        • Basecamp — для постановки задач и обсуждений, в которых могут участвовать несколько человек, включая не только команду, но и клиента;
        • YouTrack — одновременно и система отслеживания ошибок (), и место, где формулируются и ставятся задачи;
        • Trello — менеджер задач, устроенный по принципу : вы создаёте задачи в виде карточек, придумываете колонки, символизирующие этапы выполнения задачи, и переносите карточки от одного этапа к другому. Trello существует в виде десктопного, мобильного и ;
        • Google Документы — набор для создания текстовых документов, таблиц и презентаций;
        • Tick — приложение, которое следит за тем, сколько времени уходит на задачу у исполнителя. Это помогает менеджеру в планировании бюджета. Можно использовать на мобильных устройствах обеих платформ, как расширение в Chrome и как десктнопное приложение для Mac;
        • Float — инструмент, помогающий в наглядной форме запланировать время специалистов и в дальнейшем распоряжаться им. Работает онлайн, на и в связке со Slack и Zapier;
        • Zeplin — десктопное и , которое служит для подробного хранения . Zeplin позволяет объединить в группы, хранить и отображать все экраны, элементы интерфейса и расстояния между ними, цветовые и текстовые стили. Для экономии времени и экологичного производства рекомендуем вам построить культуру профессионального общения между разработчиком и дизайнером на связке Zeplin и графического редактора Sketch.
        • Книги для менеджеров проектов

        • Новые правила деловой переписки. Максим Ильяхов, Людмила Сарычева;
        • Пиши, сокращай. Максим Ильяхов, Людмила Сарычева;
        • 45 татуировок менеджера. Максим Батырев;
        • Критическая цепь. Элияху Голдратт;
        • Deadline. Роман об управлении проектами. Том ДеМарко;
        • Я слышу вас насквозь. Эффективная техника переговоров. Марк Гоулстон;
        • Думай медленно… Решай быстро. Дэниел Канеман;
        • Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения. Том ДеМарко, Тимоти Листер;
        • Идеальный руководитель: почему им нельзя стать и что из этого следует. Ицхак Адизес;
        • Искусство войны. ;
        • Сначала нарушьте все правила. Маркус Бакингем, Курт Коффман;
        • Вовремя и в рамках бюджета. Управление проектами по методу критической цепи. Лоуренс Лич;
        • A Guide to the Project Management Body of Knowledge;
        • Как пасти котов. Дж. Рейнвотер;
        • Оргуправленическое мышление. Георгий Щедровицкий;
        • Лидер и племя: пять уровней корпоративной культуры. Джон Кинг и Дэйв Логан;
        • Человеческий фактор. Успешные проекты и команды. Том ДеМарко, Тимоти Листер;
        • Мифический , или как создаются программные системы. Фредерик Брукс;
        • 7 навыков высокоэффективных людей. Стивен Кови;
        • Договориться можно обо всём. Гевин Кеннеди;
        • Чёрный лебедь. Нассим Николас Талеб;
        • Цель. Процесс непрерывного улучшения. Элияху Моше Голдратт;
        • Игры, в которые играют люди. Эрик Берн;
        • Длинный хвост. Крис Андерсон;
        • Рабы «Майкрософта». Дуглас Коупленд;
        • Scrum и XP. Записки с передовой. Хенрик Книберг;
        • Обнимите своих клиентов. Джек Митчелл;
        • Русская модель управления. Александр Прохоров.

        Какие статьи и ссылки стоит хранить в закладках и перечитывать

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

        За чем и за кем следить в интернете

        Менеджмент — абстрактная штука. Её можно применять везде, как и черпать знания из всех смежных и не очень сфер. Но всё же:

      25. Бюро Горбунова;
      26. «Хабр». очень старомодный и нотационный, читать статьи по менеджменту на «Хабре» стоит только для того, чтобы понять, как думают разработчики: учиться общаться с людьми стоит в других местах;
      27. .
      28. Проект «Эвотора» о малом бизнесе в России;
      29. «Тёмная сторона». Про MVP и как отделять важное от остального;
      30. «Бабаева, к доске!». Про ченджмаркетинг;
      31. «Деловая переписка». Как писать по работе;
      32. «Цифровой этикет». Как не бесить друг друга в интернете;
      33. «Чёт приуныл». Про критическое продуктовое мышление. А ещё есть очень классный блог, где контент не дублирует контент канала;
      34. «Экстраполяция менеджмента».
      35. Книги, статьи и — это хорошо. Но если у тебя есть интерес к менеджменту, то 90% прочтённого ты, скорее всего, уже умеешь делать интуитивно. Остальные 10% знаний закрываются конкретными инструментами, которые ты будешь использовать в работе.

        Зарплата менеджеров проектов

        В феврале 2019 года сервис «Мой круг» поделился с читателями «Хабра» отчётом по зарплатам различных на второе полугодие 2019 года, составленным на основе анализа 8500 зарплат, собранных калькулятором сервиса. Согласно этому отчёту, зарплата менеджера проектов колеблется от 43 до 180 тысяч рублей в месяц.

        Каким надо быть, чтобы работать менеджером проектов

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

        Владислав Сиренко, старший менеджер проектов Лайв Тайпинг

        «Я начинал с организации людей в студсовете ВУЗа. Студсовет занимается проведением ивентов в рамках факультета. Сначала я был заместителем председателя, потом — председателем, и когда я был в этих двух ролях, я проводил 4–5 мероприятий в год и брал за них ответственность. Это был первый зрелый опыт организации.

        На ранних курсах ВУЗа возник интерес к созданию сайтов. Я собрал небольшую команду и дизайнеров и искал для них заказы, выполняя роль и одновременно. Я общался с клиентом и выяснял требования к продукту, передавал требования команде, и мы вместе искали классное решение. Мы набили руку и на следующем шаге захотели создать свой продукт. Возник стартап, где я был продуктовым и проектным менеджером. Но опыта всё равно не хватало: всей команде нужно было развиваться дальше.

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

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

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

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

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

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

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

        Что важнее: процесс или результат? Я ставлю результат, но не далёкий, а более близкий и достижимый, который получаю декомпозицией. Результат я воспринимаю как чекпоинт в играх, на котором можно вздохнуть и сказать себе: «Вот мы молодцы!». И я предпочитаю идти от одной такой точки до другой.

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

        Роман Дмитриев, менеджер проектов Лайв Тайпинг

        «В 2016 году, во время обучения в ВУЗе, мы с моим товарищем по общежитию решили продавать лендинги. Мы были студентами, изучали вёрстку, фронтенд и дизайн.

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

        В таком режиме мы продержались 1 год и 7 месяцев. С нами работало 17 человек, бюджеты проектов лежали в диапазоне от 20 до 200 тысяч рублей. Впоследствии наш инвестор по личным причинам перестал давать нам деньги, а мой компаньон уехал учиться за границу. Мы закрыли все проекты и закончили дело. Для меня встал вопрос о поиске работы менеджера проектов. Хотелось развития, поэтому проекты должны были быть крупными.

        Я не получил должность проектного менеджера в одной компании: мне сказали, что совмещать работу с учёбой не получится, но предложили заниматься холодными звонками. Через 1,5 месяца я получил первую зарплату, и она оказалась такой низкой, что стала последней. Чуть позже технический директор Лайв Тайпинг нашёл моё резюме на hh.ru, предложил мне работу, и я согласился.

        В то время, когда я продавал лендинги, я поймал себя на том, что работаю по 16 часов в сутки, сплю 5–6 часов, оставшееся время трачу на еду и разговоры — и не устаю, а получаю удовольствие. Я понял, что нашёл дело, которое наполняет меня, а не опустошает: как поставить задачу разработчику, что сказать клиенту, как построить задачи в очередь, как спроектировать интерфейс так, чтобы клиент остался доволен и его задача была решена. И чем дальше я развивался, тем больше мне нравится. Чтобы лучше разобраться в этом, советую почитать книгу „Поток“ Михая Чиксентмихайи.

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

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

        Таким образом я „изобрёл“ ещё много вещей. Они были продуктом логики: когда передо мной вставала незнакомая задача, я прикидывал несколько путей её решения, анализировал, куда может завести каждый из них, и выбирал оптимальный. Вместо точной аналитики здесь больше подходит понятие байесовской вероятности. Например, нужно подсчитать количество монет в куче. Вы смотрите на неё и примерно представляете высоту кучи в монетах, ширину стороны её основания в монетах, учитываете форму кучи, считаете по формулам из школьного курса геометрии и получаете примерный результат.

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

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

        Любовь Тимошенко, менеджер проектов Лайв Тайпинг

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

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

        Было сложно начинать. Я работала с маркетологами и одним разработчиком, занимающимся фронтендом и бэкендом одновременно. Процесс программирования выглядел для меня как магия, когда из ничего получается , поэтому первые три месяца я не понимала разработчика. После того, как мы разделили задачи для фронтенда и бэкенда, разработчик занялся задачами, которые нельзя было „пощупать“; в итоге я не понимала, в каком статусе находится проект.

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

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

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

        Илья Помазков, менеджер проектов Лайв Тайпинг

        «В ВУЗе я учился на специальности » », которая связана с управлением проектами. Она направлена на создание и развитие проектов в сфере IT, экономики, бизнеса Во время учёбы у меня был опыт работы с международной молодёжной ассоциацией AIESEC, где я с нуля создал несколько проектов. В рамках одного из них зарубежные специалисты приезжали в Омск и читали лекции о трендах в современных специальностях. Здесь зародился мой интерес к организации .

        Был опыт в организации ивентов, среди которых — форум молодых лидеров YouLead. На последнем курсе ВУЗа я получил практическое задание по запуску и доведению его до рабочего прототипа, которым можно пользоваться. Так зародился проект «Вечер в Омске» — путеводитель по городским местам и событиям. После этого я получил грант на форуме «Ритм», потраченный на специалистов и маркетинг, и понял, что этот проект интересен людям и его готовы поддерживать. Также была инициативная команда, готовая им заниматься, но ей нужно было управлять, то есть применять навыки, которые я получил до этого. Так появился интерес к продуктовому и проектному менеджменту.

        «Вечер в Омске» дал мне огромный толчок в осознании . Благодаря этому проекту у меня появился опыт работы с проблемными ситуациями в рамках горящих сроков, ответственности перед инвестором и разрешения конфликтов внутри команды.

        «Вечер в Омске» стал отличным стартом для погружения в сферу управления проектами, но, конечно, без ошибок не обошлось. Все ошибки были изучены на больших ретроспективах, а опыт управления первой до сих пор напоминает мне о том, каких моментов в менеджменте стоит избегать. Это, например, личные отношения и конфликты между разработчиками, срыв сроков желания сделать всё и сразу, отсутствие правильного ТЗ и декомпозиции задач, разумного управления ресурсами.

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

        В ВУЗе, рамках предмета «Управление проектами», я познакомился с PMBOK — настольной книгой менеджеров. На её основе было много практических занятий, что помогло сложиться пониманию менеджмента. Но усилить понимание можно только практикой, взяв методологию вроде Agile и применив её на конкретном проекте.

        У меня нет мании читать умную литературу, я больше склонен к статьям. Но книга «Вовремя и в рамках бюджета» единственная для меня из профессиональной литературы, которая показывает, что в менеджменте много разной аналитики и статистики, и есть много инструментов для создания качественного проекта. Но контент, который мне действительно помог — это конференции крупных компаний вроде Facebook и Apple».

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

        Читайте так же:  Информация о налоговом вычете за обучение. Как оформить вычет на обучение детей

    admin