Month of Testing — 20 тематических вебинаров, 17 спикеров, подготовка к сертификации ISTQB!
×Закрыть

Что должен уметь PM и как развиваться на уровнях junior, middle, senior

Меня зовут Дмитрий Растатурин, я работаю в компании Daxx NL и отвечаю за операционный менеджмент в Pindrop NL (компания-клиент). Наши end-customers — это Европа, основной рынок — Нидерланды, а также Франция, Бенилюкс и UK.

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

Речь пойдет о проектах среднего уровня (то есть суровый энтерпрайз со сложной архитектурой и одностраничные сайты исключаем). Пример одного из проектов — SaaS-платформа для автоматизации ивент-менеджмента у крупного вендора в нескольких локациях.

Компоненты роли PM

Сфера менеджмента в ИТ охватывает довольно много смежных областей, поэтому необходимо учитывать, что в разных компаниях набор обязанностей может (а, вернее, будет всегда) отличаться. В этой статье я пишу о них с точки зрения project management (концентрация на проекте), а также delivery / operations management (мы управляем каким-то количеством проектов, распределенными командами, то есть концентрация на процессах).

Можно выделить такие главные компоненты роли PM-а:

  1. Основы архитектуры. Управление релизами.
  2. Планирование.
  3. Коммуникация.
  4. People Management.
  5. Владение инструментами.
  6. Управление требованиями и документация.
  7. Управление бюджетом.

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

Давайте рассмотрим эту модель в привычной структуре, поскольку для начала нужно понять, как работают компоненты системы, и только потом двигаться на следующий уровень (step by step): Junior, Middle, Senior.

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

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

Основы архитектуры. Управление релизами

Junior

Необходимо понимание следующих основ:

  • Клиентская / серверная часть (Backend, Frontend).
  • API.
  • HTTP и запросы.
  • ООП.
  • Release management — процесс, отвечающий за внедрение и контроль качества (части) вашего (кода) продукта, развернутого в ИТ-среде. В том числе в рамках управления релизами разрабатываются политики внедрения новых версий программного и аппаратного обеспечения. Релиз — это здоровье проекта. Иногда нужно делать релизы чаще, иногда нет. Далее я расскажу о том, как управлять кросс-проектными релизами для проектов среднего уровня.

Middle

  • Управление версиями.
    • Здесь необходимо уточнить, что нам необходимо понимание, как работает процесс Git, что такое коммиты, как происходит релиз технически, но менеджер не будет заниматься реализацией проекта (проверять pull requests, осуществлять релиз технически) — это роль команды. От менеджера в данном случае требуется координация процесса, но не его реализация.
  • Gitflow:
  • Понимание, как создается сборка продукта (билд), доставка (deployment) в нужную среду (environment(s): development, staging, production).
  • Что такое Continuous Integration (CI), то есть непрерывная интеграция кода (очень частые обновления системы (кода вашего проекта), но небольшими частями, и последующая автоматизация этого процесса).

Senior

  • Имплементация практик Continuous Delivery.
  • Business Intelligence (BI): имплементация и автоматическая отчетность.
  • Мониторинг процессов в реальном времени:
    • конфигурация автоматических нотификаций аналитики по выбранным метрикам;
    • для начала подойдет eazyBI.

Что прочитать: «Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation» by Jez Humble, David Farley (минимум на уровне Middle).

Кейс

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

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

В нашей компании мы применяем кросс-проектный Скрам. Почему я говорю «кросс-проектный»? Мы используем Atlassian Portfolio для управления большим количеством проектов, и концепция CPR (cross-project releases) прекрасно интегрируется в наш процесс.

Далее расскажу немного больше об управлении итерациями в планировании проекта.

Планирование

Junior

  • Что такое Waterfall.
  • Что такое Agile (в первую очередь мы хотим понимать, что представляет собой Scrum / Kanban).
  • Что такое Lean.
  • Типы контрактов. Отличия Fixed Price от Time & Material.
  • Управление бюджетом проекта.

Middle

  • Управление процессом планирования.
  • Умение взять на себя роль Скрам-мастера (а часто совмещение этой и ПМ ролей).
  • Работа с эстимейтами (см. книгу Mike Cohn), одновременная работа на нескольких уровнях планирования (high-level, story level, technical level).
  • Построение Gantt-графиков для клиента.
  • Грамотное планирование релизов и планирование итераций.
  • Концепции PMBOK, PRINCE2, их отличия от методологий Agile.

Senior

  • Внедрение различных моделей планирования и понимание, какая подходит данному проекту.
  • Управление кросс-проектными релизами.
  • Релиз менеджмента в портфолио проектов.
  • Продажа спринтов клиенту.

Что прочитать:

Кейс

Мы работаем на нескольких уровнях одновременно (контракт не учитываем, для примера берем общую модель):

  • High (Epic) level: rough planning (range pessimistic / optimistic + разделение рисков с клиентом, где это возможно). Для оценки вероятности используется классическая модель PERT. На этом уровне мы продаем проект.
  • Business (story) level: на уровне user story, планирование итераций с описанием / acceptance criteria, но без технической декомпозиции. Планирование фич по модели Kano. Это планирование итераций после того, как проект подтвержден и приоритизирован скоуп проекта.
  • Technical (sub-task level): технические задачи для разработчика. Планирование в рамках одной итерации. Задачи на этом уровне максимально детализированы.

Мы используем классические двухнедельные спринты и в их названии придерживаемся формата «Sprint-X-year-month-week», для того чтобы:

А. Product Owner знал, когда он получит определенный функционал на staging environment (то есть среда, идентичная по конфигурации лайв серверу) без необходимости идти в календарь релизов.

Б. Через полгода мы можем легко сказать, в каком релизе мы закончили такую-то фичу.

Например, сейчас мы заканчиваем Sprint-3-18.6.2, то есть PО знает, что требуемый функционал он увидит на демо в конце второй недели июня. Это также позволяет более удобно планировать задачи для следующих итераций.

Как мы управляем версионностью?
Поскольку релиз итерации — это не всегда релиз в лайв, для релизов клиенту (staging) / в лайв, мы используем следующее управление версиями: в Git и в релиз-тикете.

Как мы это делаем в Jira, и если, например, необходим хотфикс до окончания итерации?
Создается тикет с кастомным issueType = `Release`, где указывается (Git) версия, и далее тикет планируется как часть итерации. Рекомендую внимательно прочитать, что такое управление версиями, поскольку зависимостей очень много в любом процессе, и правильная версионность позволяет грамотно ими управлять.

Как мы планируем ресурсы, которые могут быть разделены между несколькими небольшими проектами?
Мы используем термин Capacity каждого FTE, то есть каждый член команды (команды также разделены в Atlassian Portfolio) имеет определенное количество часов в спринте, которые мы можем использовать. В Capacity автоматически включены риски, и также часть времени мы резервируем на случай непредвиденных рисков. То есть при правильной конфигурации менеджер может управлять ресурсами и строить планирование быстро и эффективно (конечно, должна работать двусторонняя синхронизация с Jira). Но ему нужно помнить о том, что релиз должен быть выполнен (а их может быть несколько, если мы говорим об управлении портфолио проектов) и скоуп не может быть перегружен.

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

Коммуникация

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

Junior

  • Английский: upper-intermediate (min B2).
  • Грамотная коммуникация рисков.
  • Коммуникация в команде, позиция командного лидера.

Middle

  • Английский: fluent (C1, C2).
  • Управление проектом с момента подписания SOW (до релиза, возможно, исключая управление бюджетом).
  • Управление рисками проекта и грамотная коммуникация рисков клиенту.

Senior

  • Английский: fluent (C1, C2).
  • Работа со стейкхолдерами (заинтересованными лицами проекта) С-уровня.
  • Участие в presale.
  • Delivery management.

Что прочитать: «Договориться можно обо всем» Гэвина Кеннеди

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

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

Кейс

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

Что мы сделали? Мы описали скоуп в рамках новых требований как Time & Material, декомпозировали на несколько фаз (Epics), начиная с MVP (minimum viable product), приоритизировали stories вместе с продакт-оунером, провели переговоры с клиентом, используя изначальные требования, построили планирование и провели клиента через весь процесс.

People Management

Junior

  • Коммуникация прогресса заказчику и требований команде.

Middle

  • Умение работать с конфликтами в команде.
  • Управление рисками в команде.
  • Проведение 1×1 митингов.

Senior

  • Имплементация KPI, оценка performance (интеграция с BI).
  • Управление кросс-проектными / shared / remote командами.
  • Проведение интервью.

Что прочитать: «Черная книга менеджера» Славы Панкратова (короткая книга, не о методологиях, а об отношениях между менеджером и бизнесом).

Инструменты

Junior

  • Jira (user level), Confluence, Google Docs, Email / Slack.

Middle

  • Jira advanced level, Confluence, инструменты прототипирования (Balsamiq Mockups, Proto.io, Axure etc, если необходимо), MS Project or similar.

Senior

  • Jira deep configuration, Atlassian Portfolio, BI / process analytics systems (ServiceClarity & others).

Что прочитать: «JIRA Essentials» by Patrick Li, Third Edition.

Управление требованиями и документация

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

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

Документируются не только требования, но и митинги по время итерации:

А также процессы и политики внутри компании.

Управление бюджетом

Junior

  • Управление только скоупом проекта (управление бюджетом — минимум, уровень Middle).

Middle

  • Оценка проекта и коммуникация данных клиенту.
  • Анализ трекинга времени.
  • Коммуникация бюджета / управление бюджетом — в зависимости от политики компании.
  • Репортинг.

Senior

  • Администрирование часов.
  • Мониторинг бюджета в BI.
  • Автоматические нотификации о превышении бюджета (по итерациям / релизам).
  • Бюджет команды / проекта.
  • Бюджетирование на определённый период времени наперёд.
  • Гибкое инвойсирование T&M часов (конфигурация экспорта в зависимости от аккаунта).

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

Выводы

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

Как я говорил в начале статьи, я намеренно даю информацию в таком формате, чтобы начинающий специалист не оказался посреди океана информации, не зная, за что браться. Градацию «junior — middle — senior» следует воспринимать условно. Аналогично можно использовать «A — B — C», поэтому не стоит предполагать, что менеджер проектов среднего уровня будет обладать именно таким сетом навыков.

В конце выделим несколько важных тезисов, которые определяют квалификацию и опыт менеджера:

  • Мы управляем процессом, а не процесс управляет нами. Если менеджер is not in charge, вероятность того, что проект закончится успешно, — практически нулевая.
  • Продукт нужно знать на уровне архитектуры, то есть вы должны понимать, что вы отдаете клиенту, как взаимодействуют модули, логику продукта etc.
  • Не создавайте лишнюю работу, старайтесь упростить все, что можно упростить:
    • Касательно планирования задач и управления бэклогом — еще раз, изучите Kano Model of Satisfaction, а также как приоритезировать задачи и учитывать риски и зависимости. Кстати, Mike Cohn пишет об этом очень хорошо.
    • Всегда учитывайте влияние задачи на логику продукта.
  • Не принимайте решения за разработчиков. Никогда не продавайте проект без оценки команды, если задачи выполнять будете не вы сами.
  • Становитесь на сторону заказчика при коммуникации с ним, и на сторону команды при коммуникации с командой. Изучайте бизнес заказчика. Изучайте предметную область продукта.
  • Планируйте и управляйте планированием на нескольких уровнях.
  • Всегда считайте и учитывайте риски.
  • Время — деньги. Always be in control of your budget.
  • Структура и предсказуемость процессов. Процессы должны быть предсказуемыми для команды и заказчика. Да, именно так.
  • Процессы должны быть гибкими. Если процесс рассыпается при малейшем отхождении от плана, это не процесс.
  • Вы всегда работаете с людьми. Без команды вы не сможете сделать ничего, а без клиента вам будет нечем платить зарплату. Работайте по обе стороны баррикад :)
LinkedIn

36 комментариев

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

Чудова вичерпна стаття про роботу ПМ!

p.s. здається лінк не вірний

«The Lean Startup» by Eric Ries.

Спасибо! Крутая статья 100%

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

Я бы отметил что самые важные навыки проектного менеджера это:
1. Умение организовывать
а) людей и их деятельность
б) информацию и её форму
2. Умение коммуницировать
а) разобраться в том что кому надо и кто что хочет
3. Умение продавать
а) что угодно (идеи, проекты, задачи, людей, ...)
4. Умение договариваться с заказчиком/коллегой/начальством/...
а) WIN/WIN
б) WIN/LOSE но мы WIN в следующий раз
в) убедить кого то делать то что он не хочет/ему за это не платят/ему это не нужно/я вообще тут полы мою, алё.

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

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

Неплохая статья, спасибо! Вот меня всегда интересовало — что делают Junior Project Manager’ы? Основная роль Project Manager — ведь брать на себя ответственность за проект целиком. Или джун тут больше секретарь-помощник? Я не рассматриваю случай, когда Project Manager вырос из технического специалиста, там все чуток по другому, чем в статье.

Или джун тут больше секретарь-помощник

практически да, с той разницей что обычно у них договоренность через 6-12 мес стать ПМом

я как то на пьянке в лондонской командировке начал по этому поводу шутить когда впервые услышал этот термин, чем, как обычно, обидел пару ребят которые присутствовали на пьянке с такой лычкой)))

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

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

Ну, вообще да, мы этим вопросом тоже задавались :) В целом, в большинстве случае — это координация задач, и по большей части таск менеджмент в JIRA, когда нужно создать и проконтролировать определенные задачи, а это ведь тоже время. А человек учится, задает вопросы, и постепенно начинает работать более самостоятельно. Есть даже позиция «Project Coordinator».

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

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

Какой первостепенный совет можно дать программисту?
— каждые пол часа вставать и общаться с людьми(в данном случае вонючей палочкой-выручалочкой становится сигарета)
— завести девушку
— завести кота
— занятся спортом
— поставить рядом с монитором растение

Программисты, объединимся для создания вывода)

Чудова стаття! Дякую )

Глобальная проблема статьи это наличие ПМа в ситуации когда используется Scrum. Это не совместимые понятия. Либо это не Scrum.

Общая проблема украинских аутсорсов это искаженное понимание того что такое есть «проект». Этим термином называется все что угодно, и любая роль не, координирующая усилия людей, пытается себя именовать проектным менеджером. Проект это всё-таки четко определенное понятие, а управление им это сложная дисциплина, включающая в себя некий минимум — скоуп, время, бюджет, качество. Если нет этих составляющих, то и нет управления проектом, а, скорее, просто участие в нем. В аутсорсинге это скорее team management, и где-то service delivery management.

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

Спасибо за конструктивный комментарий. Я не говорю, что ПМ должен быть Скрам Мастером априори. С моей точки зрения:
1. ПМ должен понимать, что такое итеративная разработка, и почему частые релизы выгодны команде и бизнесу (эта тема также связана с continuous delivery)
2. ПМ должен уметь построить процесс, но не обязательно выполнять роль Скрам Мастера)
3. В случаях, когда вы работаете с shared pull of resources, и состав проектной команды меняется динамически, вы не сможете построить полноценный Скрам, по той причине, что при наличии 7+ проектов одновременно, вам нужно будет запускать 7 итераций, что для проектов длительностью 1-3 месяца очень дорого, и Скрам митинги будут съедать большую часть вашего бюджета (именно поэтому мы работаем с CPR). А если добавить, что проект выполняется не в одной локации, то покупать отдельного человека мне кажется не самым эффективным решением. Для больших проектов в аутсорсе — здесь да, но такие проекты вне рамок данной статьи.

Я рекомендую, все же, поглубже изучить Scrum. Тогда станет понятно что роли ПМ в нем (и возле него) нет.

«Управление» процессом — у Скрам Мастера, проектом (наполнением/графиком/бюджетом/качеством) — у Продакт Оунера, инженерными практиками — у самих команд. Остаётся общий people management, контракты и занятие ими никак не тянет на «управление проектом» по определению, а скорее просто общий функциональный/линейный менеджмент.

В каких-то других Agile фреймворках подружить итеративно-инкрементальный подход и дисциплину управления проектами вполне реально. Даже в PMBOK есть на эту тему. Но не в Scrum.

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

Также не согласен насчёт общего функционального / линейного менеджмента, вы упускаете риск менеджмент (а это серьёзный аспект проекта), также аналитику (а это то, как вы считаете ваши часы == ваш бюджет)

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

Немного несогласен с тем, что Junior PM-ы должны уже уметь работать с рисками. Это довольно тонкая вещь, которая приходит только с опытом и даже если на джуна повесить управление рисками или их комуникацию с клиентом, то в большинстве случаев они её успешно провалят. Но возможно еще вопрос — а кого вы считаете junior, middle, senior?

Как я писал, градация довольно условна, поскольку в разных компаниях роль ПМа может сильно варьироваться. Также добавлю, что Junior PM, в большинстве случаях, не будет вести весь проект самостоятельно (по крайней мере, проект, в котором необходима работа с рисками), а будет выполнять часть работы по проекту (то есть заниматься координацией ресурсов, контролем выполнения задач и т.д.) под руководством старшего коллеги. Аналогично с управлением бюджетом. Но знать и изучать тему риск менеджмента необходимо с самого начала, на мой взгляд.

Статтья годная. Однако неокрепшие умы начинающих ПМ-ов могут быть дезориентированы немного скомканной подачей кейзов без объяснений — то, что вам может показаться как само собой понятным (продажа сапорта t&m, декомпозиция с промежуточными mvp и тд) на самом деле — тема для отдельной статтьи.

Согласен, материала много, можно написать более детально в 2-3 статьях

PMBoK це не концепції,а збірник кращих світових практик . І в останнє видання (шосте) включені також і практики Agile. Тому протиставлення PMBoK i Agile не коректне.

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

> PM
> Junior
> ООП

Яка практична цінність?

Речь идёт об основах, конечно, хотя технический менеджер, который не навязывает свое мнение, подарок для команды. Практическая ценность: лучшее понимание логики продукта, зависимостей между различными модулями, лучшее описание пользовательских историй, понимание аналитики по спринту (т.е. если менеджер понимает, почему на эту таску было нужно именно столько времени), консультация клиента в фазе Presale, более грамотное построение WBS, то есть высокоуровневая декомпозиция MVP релиза. Это не уровень Junior, но читать теорию я бы рекомендовал с самого начала, и углубляться при необходимости.

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

Отличная статья, есть желание только уточнить/добавить к архитектуре пару слов.

Основы архитектуры. Управление релизами.
Управление версиями.

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

От себя еще бы в архитектуру, в зависимости от проектов добавил бы:
Middle:
— Понимание MV* патернов .
— Микросервисы. habr.com/post/249183
Senior:
— Виды и типы баз данных.

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

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

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

Чудова стаття, дякую! Вичерпна і реальна картина по PM. Пишіть ще!

Основы архитектуры

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

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

Дмитрий, спасибо за статью! )

В разделе «Коммуникация» пропущены слова Middle, Senior

Привет, Дима :)

Подписаться на комментарии