что такое проектный подход

Управление проектами: операционный vs. проектный подход

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

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

1. Операционный уровень — это уровень операций длительностью несколько часов (обычно называемых «тасками») и проблем, возникающих по мере выполнения этих задач. На этом уровне скапливается много «мелочовки», здесь некогда думать, нужно быстро выполнять.
2. Проектный уровень — это уровень работ длительностью несколько дней, блоков работ и контрольных точек. На этом уровне нужно больше анализировать, прогнозировать, нежели скорее запускать задачу в работу. Здесь также решаются проблемы, проводится дополнительная работа с рисками.
3. Программный уровень — это уровень куратора проекта или менеджера программы/портфеля, который в меньшей степени погружен в проект, и его как правило интересует прохождение контрольных точек, решение крупных проблем и рисков.
4. Ручное управление. Это самый простой, однако и самый влиятельный подход по сравнению с другими. Если «вождь» отдал поручение, то оно обязательно к исполнению, не важно что там в планах и программах. Вся работа строится на поручениях менеджера. Нет поручений — нет работы.
Внимание! Все перечисленные подходы применяются при управлении проектом, а не какой-то один конкретный из них.

Метафоры

Ручное управление
Образ — указать рукой на то, что нужно делать.

Операционное управление
Образ — конвейер.
Мы настраиваем работу конвейера. Формируем задачи, передаем их в конвейер, а он дальше самостоятельно распределяет их между освободившимися участниками команды.
Главный принцип:«Нормально делай — нормально и будет».

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

Горизонты мышления

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

Операционный уровень

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

Проектный уровень

Проектный подход подразумевает под собой контроль всего проекта целиком. Однако на на практике для проектов длительностью около года и более не всегда целесообразно держать весь проект в поле зрения. Поэтому в таких ситуациях применяется метод «набегающий волны». Вначале берется в работу один этап, он детализируется на более мелкие работы(длительностью 2-3 месяца). Затем выполняется работа по управлению преимущественно только этим этапом. А затем при переходе на следующий этап «приходит следующая волна» и процесс повторяется снова. Однако проектный подход не ограничивается только управлением текущего этапа, периодически нужно смотреть в далекое будущее — на следующие этапы.
Итак, горизонт мышления — этап проекта (проект целиком — для небольших проектов).

Контроль выполнения

Для чего нужен контроль и какие результаты контроля мы должны получить?

Результатами процесса контроля должна быть следующая информация:
— Статус (что выполнено, какие проблемы возникли?)
Содержание: что выполнено
Сроки: сколько времени было затрачено
Стоимость: сколько денег было затрачено
Изменения: какие запросы на изменения появились (с оценкой влияния на содержание/сроки/стоимость)
Проблемы: какие проблемы возникают
и другое

— Отклонения (что не успели выполнить или перевыполнили?)
Содержание: что не успели выполнить/перевыполнили относительно планируемого
Сроки: на сколько времени отстали/опередили? сколько времени нужно, чтобы доделать запланированное
Стоимость: сколько денег было перерасходавано/сэкономлено? сколько средств нужно, чтобы доделать запланированное
и другое

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

Как часто проводить контроль?

Контроль операций — проводить постоянно.
Контроль проекта — регулярно (1 раз в неделю, 1 раз в 2 недели).

Вывод

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

Оба эти подхода должны использоваться в проектной деятельности.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюмируем

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

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

Источник

Что такое управление проектами

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

Что такое проект и его управление

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

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

Чем отличается проектное управление от традиционного менеджмента

Рассмотрим отличия разных систем управления наглядно.

Зачем нужно управление проектами

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

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

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

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

Предикт

Стандарты управления проектами

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

Есть международные стандарты управления проектами – правила организации работы в разных странах. Один из самых известных стандартов – PMBOK (A Guide to the Project Management Body of Knowledge). Это руководство по управлению проектами, где есть вся терминология и базовые принципы. Его применяют в более 160 странах мира.

Роли в проекте

Роль в проекте – это набор функций и полномочий для разделения обязанностей между членами команды. Стандарт PMBOK выделяет следующие роли:

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

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

Кто такой руководитель проекта

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

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

Какие компетенции понадобятся руководителю проектов в работе:

Преимущества проектного метода управления и его недостатки

Плюсы проектного управления:

Основные этапы управления проектом

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

Инициирование проекта

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

Планирование проекта

Теперь нужно определить, как именно будет выполняться проект:

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

Исполнение проекта

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

Мониторинг и контроль проекта

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

Контролировать работу легче с помощью автоматизированных систем: CRM и других сервисов. Например, сквозная аналитика от Calltouch поможет проанализировать эффективность интернет-рекламы. Система объединяет данные со всех площадок в одном окне. С помощью наглядных отчетов можно сделать выводы об эффективности, оптимизировать затраты и выстроить полноценную воронку продаж.

Сквозная аналитика

Закрытие проекта

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

Подходы к управлению жизненным циклом проекта

Жизненным циклом можно управлять: от этого зависит результативность проекта. По подходам к управлению жизненные циклы делят на:

Какую выбрать методологию

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

Waterfall

Эту модель еще называют каскадной или водопадной. Главный принцип метода – последовательное и четкое соблюдение всех этапов по заранее продуманному плану. Например, этапы разработки IT-продукта по методологии Waterfall:

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

Agile

В отличие от Waterfall, Agile – целый набор гибких методик. Его главная ценность – это качество продукта, поэтому agile-команды постоянно поддерживают контакт с заказчиком и готовы к любым изменениям и доработкам. Обычно методология используется в IT-сфере при работе небольших групп сотрудников, занятых творческой работой.

Scrum

Scrum – это часть методологии Agile. Здесь тоже в приоритете результат и удовлетворение запросов заказчика, поэтому его максимально вовлекают в процесс. Работа состоит из коротких периодов – спринтов. В рамках спринта создается часть продукта, которую тестируют демонстрируют клиенту. По обратной связи от клиента команда улучшает эффективность.

Kanban

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

Инструменты для управления проектами

Чтобы руководителю было проще выстраивать и контролировать процессы, разработчики создают специальные сервисы и ПО, которые автоматизируют часть работы. Самые популярные:

Заключение

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

Источник