Как управлять проектами легко и быстро

Содержание

Управление проектами: 10 заповедей счастливого проджект-менеджера

2 512 просмотров

Почему правильное управление проектами — залог хорошей прибыли и новых клиентов

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

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

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

Первый шаг в управлении проектами

Очень важно отправить производителю керамической плитки приветственное письмо. Наше выглядит так:

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

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

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

Почему правильное управление проектами — залог хорошей прибыли и новых клиентов?

Система управления проектами : 10 заповедей счастливого проджект-менеджера

1. Не обещайте лишнего

Кому будет лучше, если Вы пообещаете мобильную версию сайта о керамической плитке, а окажется, что вы забыли обговорить это с разработчиком? Как результат: раздутый бюджет, незапланированные траты, недовольный клиент и проклинающая Вас команда. Иногда можно предложить какую-нибудь «плюшку» в подарок, но перед тем, как обещать — проконсультируйтесь с командой и, главное, руководством.

2. Подходите к управлению проектами без лишних эмоций

Не стоит вести разговоров на повышенных тонах с клиентом и командой. Если производитель плитки вдруг скажет: «Я заплатил такие деньги вот за ЭТО? Где результат?» — старайтесь не нервничать. Менеджмент проектов требует навыков дипломатичного общения. Команда Uni Consulting ведет каждый проект с терпением и любовью. Кстати, в футере мы так и пишем:

3. Ставьте несколько дедлайнов

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

Вы можете рассчитать время работы, но не учесть, что заказчик исчезнет на пару дней, не отвечая на сообщения. Чтобы избежать таких проблем, пропишите отдельный пункт, который учитывает увеличение срока проекта на то количество дней, которое отсутствовал клиент. Теперь нам предстоит поделить это время на этапы. Процесс создания посадочной страницы состоит из 3 частей:

  • Сбор исходных данных;
  • Анализ;
  • Прототипирование и копирайтинг;
  • Дизайн;
  • Верстка и програминг;
  • А/Б тестирование (если предусмотрено бюджетом)

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

4. Не перекладывайте ответственность за управление проектами на других

Клиент вовремя не внес правки в текст, и поэтому у дизайнера теперь 4 дня на работу вместо заявленных 7. Кого винить? Только себя. Помните, что, делегируя задачи, Вы не делегируете ответственность. Если система управления проектами даст сбой — это будет только Ваша вина. Объясните клиенту, что если он вовремя не внесет правки, то команда не закончит проект в срок.

5. Утверждайте проект на каждом этапе

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

Создайте документ для пожеланий и замечаний заказчика в Google Docs. Так, к примеру, выглядит наш файл для правок по дизайну.

Клиент загружает скриншот части лендинга и в следующей графе добавляет комментарий с правками.

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

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

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

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

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

7. Сомневаетесь — переспросите

Правильное управление проектами = дотошное управление проектами . Бывают случаи, когда заказчик вскользь упоминает о важных фактах, которые нельзя пропускать. «Вы знаете, я работаю еще и в формате B2B», говорит он. Ну что ж: «Спасибо за детали!», думаем мы.

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

Внимательно перечитывайте таблицу с правками. Обращайте внимание на пометки, типа: «Может, сделать еще одно всплывающее окно?». Затем уточните у заказчика, что это: рекомендация, совет или руководство к действию.

8. Записывайте все, что проговариваете

Выстроить грамотную систему follow-up — значит сделать менеджмент проектов легким и прозрачным. Любой скайп-колл или встреча заканчиваются письменным резюме. Старайтесь записывать все договоренности, замечания и важные моменты. Так каждое действие будет задокументировано, и в нужный момент Вы предъявите клиенту доказательства своей правоты. Этим решаются все проблемы, начинающиеся с «я этого не говорил…».

9. Не все такие умные, как Вы

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

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

10. Вы = клиенты, которых Вы обслуживаете

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

Управление проектами — дело тонкое. Здесь не бывает мелочей и лишней информации. Только выстроив четкую и понятную схему коммуникации «заказчик=>проджект-менеджер=>команда», можно приниматься за реализацию проекта.

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

Источник: http://onlineteam.me/upravlenie-proektami-10-zapovedej-schastlivogo-prodzhekt-menedzhera/

Как управлять проектами: правило 99/50/1

Основатель диджитал-студии @tinyheartsapps рассказал о том, как грамотно распределять своё время при управлении проектами. А мы перевели эти рекомендации.

Как-то раз я обедал со своим другом Бреннаном из SoapBox, мы разговаривали о том, как развивать бизнес. И он упомянул замечательный способ управления большим количеством проектов в условиях непредсказуемости (я имею в виду стартапы).

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

Вам необходимо правильно распределять свое время

Чтобы избежать этих неприятных последствий, Бреннан рассказал мне о правиле 1/50/99% (я предпочитаю называть его метод 99/50/1%), которое он использует, чтобы успевать работать сразу над несколькими проектами. Этот метод лежит в основе взаимодействия с вашими проектными командами. Я принял его на вооружение и адаптировал для своей студии.

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

В начале проекта, когда предстоит сделать еще 99% работы

В середине, когда остается около 50% работы

Непосредственно перед финишем, когда необходимо завершить всего 1% работы

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

99%: Стратегия высокого уровня (определение проблемы и решения)

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

Обычно участие на этом этапе — это вводные встречи и/или просмотры первоначальных эскизов.

В итоге вы и ваша команда определитесь с видением и целями («Мы хотим быть лучшими в том-то и том-то» или «Мы хотим, чтобы пользователи сказали о нас то-то и то-то»).

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

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

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

Базовые характеристики: «Это те свойства, которые мы считаем само собой разумеющимися. Клиенты обычно их даже не упоминают, потому что они чрезвычайно важны или являются базовыми для определения ценности продукта».

Основные/желаемые свойства: «Это свойства, которые клиенты желают иметь, но не ожидают их получить. Чем больше таких стимулирующих характеристик мы заложим, тем счастливее будет клиент. Удачная работа в этой области позволяет нам делать их довольными».

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

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

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

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

Вот некоторые работы, которые моя команда обычно выполняет в период от 99% до 50%:

Проработка технической стороны

Анализ конкурентной среды

Создание основных характеристик

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

50%: Сбор обратной связи (коррекция курса)

Итак, ваша команда усердно работала над проектом в течение какого-то времени и готова дать вам обратную связь. Это отметка 50%. Ура, мы более-менее на половине пути!

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

Критика дизайна

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

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

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

Обратная связь от разработчиков

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

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

Забегая вперед, вот некоторые задачи, которые наша команда решает в период от 50% до 1%:

Улучшение дизайна продукта

Завершение создания базовых свойств, добавление желаемых и привлекательных характеристик

Подготовка к запуску

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

Если же все движется гладко, вы пока здесь не нужны!

1%: Завершение работы над проектом

Ого, запуск уже совсем не за горами! Быстро же мы обернулись! Но не обольщайтесь. Любой опытный разработчик, дизайнер или менеджер проекта знает, что оставшиеся 10% критически важны. Работа над ними всегда отнимает очень много времени.

Это называется правило 90/90:

«Первые 90% кода отнимают первые 90% времени разработки. Оставшиеся 10% кода отнимают другие 90% времени разработки. — Том Каргилл (Tom Cargill), Bell Labs

На этом этапе вам необходимо тщательно исследовать все мелкие детали (внешний вид приложения, изменение версий, исправления в позиционировании, детали элементов на уровне пикселей).

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

Вместо заключения

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

Метод «99-50-1» помогает лучше распоряжаться своим временем и быть уверенным в том, что ваша работа направлена на создание поистине замечательного продукта.

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

Источник: http://www.iidf.ru/media/articles/lifehacks/kak-upravlyat-proektami-pravilo-99-50-1/

Как управлять проектами

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

Представление организационной структуры проектов

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

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

  • Дерево целей и результатов, разбитое на функциональные модули (блоки).
  • Фазы «жизни» проекта, представленные в виде наглядной модели.
  • Схема организационной структуры проекта.
  • Матрица распределения ответственности участников проекта.
  • Сетевая модель, показывающая последовательность реализации частей проекта.
  • Дерево ресурсов и дерево стоимости.
  • Реестр рисков проекта.

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

Принципы организации команды проекта

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

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

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

  • Устав или паспорт проекта.
  • Утвержденные положения о структуре организации управления проектом.
  • Положения об обязанностях и степени ответственности каждого члена команды проекта.
  • Различные приказы и локальные акты.

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

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

Существует несколько эффективных способов управления проектами. Кратко рассмотрим здесь три самых популярных, каждый из которых подходит для управления определенным типом проектной деятельности.

  • Agile. Это набор методов, которые позволяют максимально гибко осуществлять управление продуктами и проектами. Главной особенностью Agile является разбиение проекта на отдельные небольшие подпроекты, которые могут реализовываться отдельно друг от друга и впоследствии «собираться» в готовый цельный продукт. Основные этапы работы над «большим» проектом в полной мере применяются к каждому мини-проекту в отдельности. Инкременты (результаты) подпроектов передаются заказчику гораздо быстрее, а изменения в них можно вносить без ущерба для других частей проекта и серьезных затрат. Ключевыми плюсами Agile являются его адаптивность, гибкость и быстрая реакция на изменения в концепции проекта. К минусам можно отнести возможную потерю концентрации на значимых частях проекта ввиду «размытия» работы над ним и разделения на отдельные части.
  • Scrum. Данный способ управления проектами представляет собой идеальный вариант сочетания структурированности и гибкости. Весь процесс работы разбивается на фиксированные временные отрезки – спринты. Длительность каждого спринта определяется на начальном этапе разработки, исходя из реальных возможностей команды и количества материальных ресурсов. Как правило, один спринт может длиться от 2 до 4 недель. Результатом спринта является готовый продукт, обладающий ограниченными возможностями, но вполне функциональный. В ходе каждого последующего спринта в проект могут вноситься различные изменения – опции могут не только добавляться, но и удаляться. Scrum прекрасно подходит для управления разнообразными видами проектов, но только при наличии в команде высококлассных специалистов, которые смогут в полной мере реализовать плюсы и максимально нивелировать минусы данного способа.
  • Kanban. Этот способ управления проектами был разработан в далеком 1953 году японским инженером Тайичи Оно, который работал в компании Тойота. Суть способа состоит в поэтапной передаче инкремента проекта из этапа в этап до приведения его в соответствие с запланированным «идеалом». Kanban не ограничивает время выполнения работы над каждым этапом и, в отличие от Scrum, менее зависим от профессионализма и уровня слаженности команды. Этот способ совершенно не подходит для работы в условиях перманентного «дедлайна». Kanban позволяет предельно точно рассчитывать нагрузку на команду проекта, логично расставлять ограничения и концентрировать внимание на улучшении отдельных частей проекта, что делает его одним из лучших способов управления проектами.

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

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

  • Постановка целей и последующее управление ими.
  • Календарное планирование этапов проекта.
  • Контроль состава работ и управление ими.
  • Работа с договорами и управление поставками.
  • Контроль документооборота и управление коммуникациями.
  • Кадровая политика, управление работы с персоналом.

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

  • Контроль отчетности проекта.
  • Контроль изменений и проблем, возникающих в ходе работы над проектом.
  • Управление рисками.

Инструментами, которые обеспечивают реализацию управления проектом, являются:

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

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

Источник: http://zhazhda.biz/base/kak-upravlyat-proektami

Мультизадачность или как работать над несколькими проектами сразу

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

Работа над несколькими проектами: что это значит

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

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

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

Несоблюдение сроков сдачи

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

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

Зависание специалиста над решаемой задачей

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

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

Трудности с переключением между выполняемыми активностями

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

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

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

Распыление ресурсов на множество активностей

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

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

При каких обстоятельствах допускается многозадачность?

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

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

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

  1. Исполнитель объективно оценил собственные возможности и решил, что справится с определенным количеством назначенных проектов. Завышать планку не следует, потому что это неизбежно приведет к стрессам, чрезмерным нагрузкам, неудовлетворительным итогам.
  2. В настоящее время у исполнителя отсутствуют невыполненные задания с истекающими сроками. Следовательно, данное обстоятельство позволяет взять сразу несколько проектов в работу, учитывая ресурсные лимиты. Если имеются заказы, ещё требующие доработки, получение дополнительных заданий может оказаться рискованным.
  3. Фрилансер не увлекается бесконтрольным привлечением новых заказов, успешная и своевременная сдача которых нередко становится проблематичной. Если исполнитель с готовностью берется за новые задания, но часто не доводит их до конца из-за возникающих сложностей, ему рекомендуется воздержаться от многозадачной работы.
  4. Исполнитель (менеджер) предпочитает действовать в ускоренном режиме, так как подобный подход соответствует его характеру. Он не боится значительных объемов, сложных задач, сжатых сроков. Однако каждый фрилансер должен хорошо знать предел собственных возможностей. Не все исполнители могут работать в экстремальных условиях. Следовательно, браться нужно только за те задания, которые фрилансер (менеджер) в состоянии вовремя реализовать.
  5. Профессиональная деятельность фрилансера (менеджера) не наносит ущерба интересам его семьи. В первую очередь это касается времени, уделяемого близким людям. Оно должно быть достаточным.

Как повысить эффективность многозадачной работы: советы экспертов

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

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

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

Планирование и организация

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

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

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

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

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

Кроме того, продвинутым исполнителям (менеджерам) рекомендуется пользоваться проверенными алгоритмами проектного управления. Например, можно успешно применять SCRUM – эффективный метод управления проектами.

Тайм-менеджмент

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

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

Согласование сроков исполнения заданий с заказчиками

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

Вывод

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

Источник: http://investpad.ru/business-and-freelance/sovety-po-ehffektivnoj-rabote-s-proektami/

Продакшн и управление проектами — как успевать в дедлайн?

Исследование консалтинговой компании PM Solutions в 2011 году показало, что треть IT-проектов, стоимостью почти $75 млн, являются рискованными и могут быть завершены вне сроков или превысить бюджет. Как сообщили опрошенные компании, 12% проектов в итоге проваливаются, а спасти удается 25%. Респонденты представляли производственную сферу, банковский бизнес, финансы и страхование, здравоохранение, государственный сектор, образование и другие.

Компании, которые применяли методологии управления проектами, не могли выполнить проекты в 9% случаев; компании, которые наоборот не пользовались установленными практиками, проваливались в 21% случаев. Не в пользу организаций, которые не задействовали методологии проектного менеджмента, и процент успешных проектов: 43% против 61%.

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

10 ключевых факторов успешного проекта

  1. Компетенция проектного менеджера (ПМ). Умения и навыки руководителя проекта очень важны. Согласно результатам исследования PMI Solutions, это отметили 65% респондентов.
  2. Использование проверенной методологии или способность импровизировать. Для проектного менеджмента создано уже множество практик и методологий. Они имеют особые принципы, которые помогают управлять большинством ситуаций, возникающих на протяжении жизненного цикла проекта. Гибкие методологии поощряют импровизацию ПМ и изменяются согласно требованиям современных проектов.
  3. Надежный бизнес-план или обоснование проекта. Это причина появления проекта, которая была поддержана руководством или заказчиком. Ваш бизнес-план должен перечислять и объяснять все ожидаемые выгоды проекта.
  4. Критерии успешности проекта должны измеряться. Ставьте конкретную и реалистичную цель для проектной команды (ПК): улучшение продаж на 10% за квартал, создание программного обеспечения, которое выполнит те или другие задачи и т.д.
  5. Детальный план. Составляйте реалистичное расписание, задавайте точные требования к ресурсам, обозначайте контрольные события, учитывайте риски.
  6. Мотивация команды. Поддерживайте ее на высоком уровне, следя за участием исполнителей в процессе, решайте конфликты и проблемы.
  7. Умение говорить «нет». Не все ПМ и участники ПК могут отказать, когда это необходимо. Никогда не обещайте того, что нельзя выполнить. Твердо говорите «нет» и будьте готовы объяснить причину.
  8. Избежание разрастания проекта. Вы должны однозначно утвердить план проекта с заказчиком или руководством, чтобы минимизировать количество дополнительной работы.
  9. Управление рисками. Мы писали о методологии моделирования событий, которая анализирует комплексные отношения между рисками.
  10. Закрытие проекта. Он должен быть завершен при достижении критериев успешности. Иначе проект будет дальше потреблять ресурсы или меняться под новые требования.

Критерии готового проекта в продакшн

Продакшн — это фаза проекта, в ходе которой происходит создание готового продукта и подготовка его к распространению или передаче заказчику.

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

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

Фазы проекта:

  1. Инициирование проекта
  2. Планирование съемок
  3. Проведение съемки
  4. Монтаж
  5. Распространение отснятого материала

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

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

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

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

Вопросы, которые задает себе ПМ при инициировании проекта:

  • Какие цели должны быть достигнуты?
  • Как измерить критерии успешности?
  • Какие каналы распространения оптимально подходят для будущего ролика, учитывая его формат или длительность?
  • Нужно ли вам привлекать съемочную группу или актеров? Если да, то какими будут их четкие обязанности?
  • Какое оборудование требуется для видеосъемки, записи звука, освещения?
  • Где снимать ролик? Нужны ли специальные разрешения и лицензии — например, при использовании ли дрона или съемок в публичных местах?
  • Потребуется ли обезопасить коллектив от непогоды при съемках на открытой местности?
  • Нужно ли полностью снять ролик, или стоит задействовать стоковые записи, анимацию?
  • Требуется ли составить детальный список сцен?

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

Вопросы для планирования перед съемкой:

  • Есть ли у вас все необходимое оборудование? Готово ли оно для использования?
  • Все ли участники процесса знают четко свои обязанности?
  • Вы подготовлены надлежащим образом к погоде в день съемки?
  • Подготовлены ли необходимые лицензии, разрешения, контракты?
  • Учитывает ли ваш бюджет затраты, которые не связаны со съемкой: еду, напитки и т.д.?
  • Все реквизиты для съемок упакованы и готовы к использованию?
  • Во что будут одеты актеры? Нужны ли им услуги визажиста или парикмахера?

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

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

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

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

Важные сцены снимите несколькими способами.

Вопросы для проведения съемки:

  • Если съемки проходят в одном месте, обеспечены ли для каждого дубля одинаковое освещение и план для съемок?
  • Вы реализовали все замыслы в съемке? Если нет, то что делать с идеями, которые не были использованы?
  • Вы получили достаточно материала из закадровых съемок?
  • Все ли упаковано к концу рабочего дня?
  • Вы конспектировали съемочный процесс?

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

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

Вопросы для монтажа:

  • Сумеете ли вы вспомнить спустя полгода содержание видеофрагментов по их имени?
  • Будет ли смонтированное видео подходить для выбранной платформы распространения?
  • Оптимизированы ли экспортные настройки ролика, чтобы им могли делиться в соцсетях?
  • Получили ли вы тот результат, который планировали?

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

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

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

Управление сроками проекта, или тайм-менеджмент — это процессы, направленные на завершение проекта до дедлайна и с соблюдением заданных критериев готовности. Выделяют 6 таких процессов:

1. Определение состава операций

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

Пакет работ — это совокупность операций с общими целями и функциями. Операции в ИСР — работы, которые приносят конкретный результат при внедрении проекта.

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

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

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

Состав операций

2. Нахождение логических взаимосвязей между операциями

Для этого ПК задействует следующие методы и инструменты:

  1. метод предшествования, или операции в узлах. Зависимые операции в виде прямоугольников, они же узлы, соединяются дугами на диаграмме Ганта. Типичны связи, когда начало выполнения операции или ее окончание зависит от старта или окончания второй.
  2. метод стрелочных диаграмм. Имеет второе название — операции на дугах. На диаграмме зависимости — это узлы, в которые соединяются дуги.
  3. шаблоны расписания проекта. Их можно использовать, чтобы ускорить подготовку расписания.
  4. определение последовательности операций. Порядок их выполнения нельзя менять, если существует жесткая зависимость между операциями. Также на последовательность влияет внешняя зависимость: поставки оборудования, климат, конкуренция и т.д.
  5. использование опережений и задержек. Отображаются минусом и плюсом соответственно на диаграмме. Начало операции через три дня после завершения предыдущей будет показано как +3 над соединяющей их дугой. Опережение применяется, когда один из отделов может приступить к операции, параллельно над которой работает другой отдел.

3. Оценка ресурсов операций

Заключается в определении, какие сотрудники или оборудование будут задействованы в проекте.

Для этого используются такие инструменты:

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

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

4. Оценка длительности операций

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

Для оценки длительности операций задействуют следующие инструменты:

  • Параметрическая оценка: общее количество ресурсов умножается на производительность рабочего периода или количество рабочего времени. После чего делится на количество привлеченных ресурсов.
    Р(общ)*В(произв)/Р(привл)=Оценка
  • Оценка по аналогам: за основу берется продолжительность предыдущей операции, которая схожа по своим параметрам с плановой.
  • Оценка по трем точкам: ПМ составляет наиболее вероятный, оптимистичный и пессимистичный сценарии. Средняя из этих трех оценок и станет оценкой для длительности операции.
  • Анализ резервов: ПМ может добавить резерв в расписание проекта для учета рисков. При уточнении информации его можно изменять либо убрать вовсе.

5. Разработка расписания

Происходит непрерывно в ходе проекта. Иногда требуется провести новые оценки ресурсов и длительности ресурсов.

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

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

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

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

На первой гистограмме мы видим, что в 1-ю неделю расписания для выполнения 4 задач задействованы не все ресурсы, когда на 4 и 5 неделе происходит их перерасход — сотрудники должны работать сверхурочно. Чтобы перераспределить ресурсы и выровнять загрузку, выполнение 3-ей задачи разгружается на 6-ую неделю, а 4-я задача полностью переходит на 7-ю неделю.

6. Управление изменениями в расписании

Используются:

  • системы отслеживания проекта и уровни авторизации изменений
  • измерение эффективности с помощью индекса выполнения сроков
  • анализ отклонений

Управление качеством

Проходит на протяжении всего цикла проекта. Состоит из следующих стадий:

  1. Концепция. Формулируются принципы обеспечения качества, которое удовлетворит запросы потребителей.
  2. Планирование. Определяются стандарты качества — международные, национальные или корпоративные, которые оправдают ожидания участников проекта.
  3. Организация. Создаются необходимые технические, организационные и финансовые условия, чтобы требования к качеству проекта были выполнены.
  4. Контроль. Проходит проверка, как текущие показатели проекта соответствуют заложенным стандартам качества.
  5. Регулирование и анализ. Анализируются изменения качества на протяжении проекта, формируется список отклонений, после чего проводятся и документируются корректирующие действия.
  6. Завершение. Проходит оценка качества проекта. Составляется список претензий в случае несоответствия определенным стандартам. Также анализируется полученный опыт по управлению качеством.

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

Для планирования качества задействуют такие инструменты:

  • Анализ выгод и затрат. Его цель — обеспечить нужное соотношение между доходами и затратами в проекте.
  • Стоимость качества. Рассчитывается совокупная стоимость всех процессов, которые направлены на улучшение качества продукта либо услуги.
  • Планирование экспериментов. Статистический метод, который изучает факторы влияния на проект.
  • Бенчмаркинг. Проводится сравнение проекта с аналогичными.

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

Инструменты, которые задействуют для контроля качества:

  1. Контрольные диаграммы
  2. Диаграммы зависимостей
  3. Диаграмма Парето
  4. Диаграмма причинно-следственных связей
  5. Инспекция и тестирование стандартов
  6. Статистические выборки
  7. Проверка исправления дефектов

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

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

Состав участников. Команда управления проектом состоит из:

  • Куратора или спонсора
  • Руководителя
  • Архитектора системы
  • Администратора

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

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

Чтобы распределить функции и обязанности в команде управления, составляются ролевые инструкции. В них обозначаются цели, функции, полномочия и субординация участников.

Куратор или спонсор

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

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

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

Архитектор системы

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

Администратор проекта

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

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

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

Формирование команды

Первоначальный состав команды формируется на основе общей ИСР. Затем его можно изменить после разработки детального расписания. Однако изменение уровня квалификации участников команды может как уменьшить, так и увеличить риски проекта и повлиять на длительность операций.

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

Способы урегулирования конфликтов:

  • Принуждение одной из сторон конфликта
  • Сглаживание противоречий
  • Компромисс, который закрепляется документально
  • Детальное изучение разногласий и принятие взвешенного решения
  • Уклонение — откладывание конфликта на неопределенный срок.

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

Навыки общего менеджмента

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

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

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

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

Вердикт

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

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

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

Источник: http://worksection.com/blog/how-to-manage-deadline.html

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

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

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

Классический подход для жёсткого планирования

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

  • Инициация – проведение совещаний и мозговых штурмов
  • Планирование проекта
  • Разработка проекта
  • Реализация проекта
  • Тестирование продукта.
  • Мониторинг
  • Завершение

Для каких проектов используется?

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

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

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

Prince2 для органов власти и крупного бизнеса

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

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

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

Для каких проектов используется?

Подходит для крупных компаний и государственных организаций.

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

Agile для гибкого планирования

Agile не является методом, скорее это набор принципов, на основе которых происходит управление проектами.

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

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

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

Для каких проектов используется?

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

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

Упрощает работу организации в соответствии с принципами Agile использование практик, которые мы рассмотрим далее.

Scrum для совершенствования процессов

Scrum — это популярный метод управления проектами, который позволяет реализовать принципы Agile. Подходит для управления небольшой командой в 5-9 человек, предполагает 3 роли: владелец продукта, Scrum‑мастер и другие члены команды. Команду возглавляет Scrum‑мастер, основная задача которого – убрать все препятствия, мешающие эффективному выполнению задач.

Команда работает короткими циклами в 2-4 недели, которые называют «спринтами». Спринт начинается с планирования задач на время его действия и заканчивается обзорами, на которых предусмотрены демонстрация продукта и обсуждение усовершенствований.

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

Для каких проектов используется?

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

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

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

Kanban для уже сложившейся команды

Kanban — это подход к управлению проектами по методологии Agile. Его принципы: выполнение задач «точно в срок», прозрачность процесса разработки для всех членов команды и равномерное распределение нагрузки между работниками.

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

  • визуализация рабочего процесса;
  • ограничение количества задач, которые находятся в процессе выполнения;
  • постоянное измерение производительности и оптимизация процесса.

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

Для каких проектов используется?

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

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

Хотите узнать больше о том, как организовать эффективную работу команды? Выберите курс по управлению проектами на TechMePlease и погрузитесь во все тонкости менеджмента.

Источник: http://blog.teachmeplease.ru/posts/top-5-metodov-upravleniya-proektami

Проджект менеджмент [основные методы управления проектами]

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

Содержание

1. Метод «Водопад» (Waterfall)

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

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

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

  1. Детализация потребительских требований;
  2. Концепция, дизайн и планирование;
  3. Создание материального продукта (строительство, написание кода и т. д.);
  4. Интеграция в существующие системы;
  5. Валидация (тестирование, отладка и т. д.);
  6. Сборка продукта;
  7. Постоянное техническое обслуживание.

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

2. Метод критического пути (Critical Path Method)

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

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

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

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

3. Метод управления критическими цепочками

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

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

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

4. Гибкий метод управления проектами (Agile)

Группа экспертов по разработке программного обеспечения разработала основы Agile System чуть более 15 лет назад. Они создали новый способ создания пользы для потребителей и взаимодействия с ними. Этот способ характеризовался четырьмя ключевыми аспектами:

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

За короткое время эксперты проджект менеджмента расширили эти концепции до отдельных фреймворков:

  • «Скрам»;
  • «Канбан»;
  • Экстремальное программирование;
  • Адаптивное управление проектами.

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

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

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

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

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

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

5. Agile и Scrum

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

Команды Scrum встречаются для ежемесячных сессий, на которых они разбивают свои проекты и результаты на 15- или 30-дневные части, называемые «спринтами». Работая над этими небольшими объемами, команды избегают перегрузок в производстве, типичных для других методологий управления проектами. Перераспределяя приоритеты своих усилий каждый месяц, для удовлетворения потребительского спроса, они могут оставаться гибкими и мотивированными — повышая производительность и удовлетворенность клиентов.

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

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

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

Скрам мастер

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

Владелец продукта

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

Участник команды

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

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

Scrum работает особенно хорошо, когда команды получают существенную поддержку от высшего руководства в виде открытых финансовых и временных бюджетов.

6. Agile и Kanban

Канбан первоначально разработан компанией Toyota в 1940-х годах. Kanban на японском означает «сигнальная карта». Этот метод основывался на картах Канбан, которые указывают на необходимость изменения порядка поставок. Многие менеджеры считают Канбан системой экономного производства, потому что она устраняет проблему потери времени и ресурсов. Короче говоря, Канбан делает компании «худыми и подлыми».

Многие руководители проектов используют концепции Канбан в сочетании с Agile методами. Гениальность Канбан в том, что производство происходит по требованию, при котором заказчик «протягивает» изделия через производственную базу.

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

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

  • In Queue (британский термин, означающий «в очереди»);
  • В процессе;
  • Недавно завершено.

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

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

Гибридная методология управления гибридными Agile / Kanban проектами лучше всего подходит для небольших групп, которые работают в одном месте. Даже люди, работающие независимо друг от друга, находят этот метод управления проектами полезным.

7. Agile и экстремальное программирование

Как и все Agile-системы, экстремальное программирование ориентировано на командную работу и удовлетворение потребностей клиентов. Такая система имеет пять основных принципов:

  • Коммуникация;
  • Простота;
  • Обратная связь;
  • Уважение;
  • Смелость.

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

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

8. Agile и Adaptive Project Framework

Адаптивная управление проектом позволяет Agile-командам работать с оптимальной гибкостью и реализовать идею «проворности». Иногда командам приходиться перенастраивать свои системы и протоколы во время работы из-за недостаточно определенных целей и результатов.

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

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

Сходство между Agile методами

Независимо от выбранного типа Agile метода, все они имеют определенные общие характеристики. Agile команды:

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

9. Скоростная разработка приложений

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

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

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

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

10. Запуск нового продукта (New Product Introduction)

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

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

11. Packaged Enabled Reengineering

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

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

12. PRINCE2

PRINCE2 — это комплексная методология управления проектами, которую не следует путать с PMBOK (the Project Management Institute’s Project Management Body of Knowledge).

PRINCE2 используется правительством Соединенного Королевства, многими организациями частного сектора по всему миру иможет многое предложить американским организациям:

  • Усиление контроля над ресурсами;
  • Повышение эффективности управления проектными рисками;
  • Четкое распределение ответственности между структурами;
  • Акцентирование на конечных пользователях «Кто, когда и почему»;
  • Последовательное, организованное планирование и исполнение;
  • Регулярное, обоснованное рассмотрение рабочих циклов.

13. Метод шести сигм

Компания Motorola изначально разработала высокопрофессиональную систему «Шесть сигм» для устранения недостатков. Они хотели, чтобы их продукты и услуги полностью соответствовали их первоначальным требованиям на протяжении всего процесса проектирования, производства и доставки.

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

“Шесть сигм”-менеджеры используют 5 технологических этапов, которые вместе называются DMAIC-S (define, measure, analyze, improve, synergize):

  • Определи потребности клиентов. Менеджеры могут определить масштаб и цель проекта, определив и составив профиль идеальных клиентов и поняв, как им обслуживать их.
  • Измерь производительность процесса. Создав соответствующие метрики для сбора данных о производительности, менеджеры могут определить, насколько хорошо система удовлетворяет потребности потребителей.
  • Проанализируй общие проблемы. Менеджеры “Шести сигм” изучают проблемы производительности, чтобы определить их коренные причины и подкрепить свои наблюдения достоверными данными.
  • Усовершенствуй систему. Руководители проектируют, тестируют и запускают новые системы для устранения основных причин системных проблем. Они опираются на данные, оценивая эти решения (и реализуя свои корректирующие меры).
  • Объедини эти результаты по всей компании.

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

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

14. Метод маркировки результатов

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

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

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

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

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

15. Институт управления проектами (PMI)

Некоторые менеджеры считают PMI’s Guide to the Project Management Body of Knowledge (PMBOK) самостоятельной методологией управления проектами. Другие считают его скорее справочником. Но, безусловно, этот сборник предоставляет необходимый набор условных обозначений и стандартизирует профессиональные термины, используемые менеджерами проектов.

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

  1. Инициирование.
  2. Планирование.
  3. Выполнение.
  4. Контроль.
  5. Завершение.

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

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

  • Многопользовательский потенциал (т. е. может ли вся твоя команда использовать его одновременно?).
  • Функции управления проектами, которые хорошо сочетаются с выбранным методом.
  • Отзывы от руководителей проектов, которые разделяют твою корпоративную философию.
  • Максимальная емкость базы данных.
  • Надежность и простота использования.
  • Необходимые сроки обучения / перехода на новое место работы.
  • Информация основанная на данных vs. визуальных интерфейсов.
  • Инструменты для создания диаграмм и отслеживания рабочих процессов

Компании, которые разработали твою программную платформу управления проектами, вероятно, сформировали её в соответствии с конкретной стратегией. Например, метод скоростной разработки приложений хорошо синхронизируется с объектно-ориентированными языками программирования, такими как Java и C++. Такие сервисы, как MeisterTask и Trello предлагают интерактивные «доски», которые идеально сочетаются с корпоративными Kanban структурами.

Узнай у своего поставщика программной платформы, какие стратегии управления эффективнее всего работают с их системами, и какие варианты (особенно Agile) они поддерживают.

Источник: http://brammels.com/career/project-management/

С чего начать работу над проектом: 6 обязательных действий

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

1. Определяем владельца проекта

В самом начале следует ответить на вопрос: кому и зачем нужен этот проект? В случае с внешним заказчиком все просто – там есть конкретный клиент. Во внутренних же проектах главное заинтересованное лицо – это владелец проекта.

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

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

2. Определяем всех заинтересованных лиц

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

  • инициатор,
  • руководитель проекта,
  • конечные пользователи.

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

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

3. Определяем цели проекта

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

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

4. Определяем результаты проекта

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

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

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

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

5. Беремся за планирование проекта

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

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

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

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

6. Составляем устав проекта

Зафиксировать все это (цели, результаты, критерии успеха, ответственность каждого) можно в уставе проекта. Готовый устав проекта должен утвердить его владелец.

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

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

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

Консультант по управлению и инвестициям, руководитель проектов. Автор и ведущий ряда семинаров по управлению проектами, в том числе курса «Менеджер профессионал advanced».

Опыт ведения корпоративных программ обучения проектному подходу и инструментам проектного управления: «Геймстрим» (Wargaming), «Велком», «Милавица», «Санта Бремор» и др.

Источник: http://probusiness.io/do_it/422-s-chego-nachat-rabotu-nad-proektom-6-obyazatelnykh-deystviy.html

Управление проектами. Быстрый старт
Ким Хелдман, 2008

Книга содержит базовую информацию и рекомендации для тех, кто решил сделать первый шаг на пути к профессиональному управлению проектами, может стать основой для накопления знаний за счет профессионального обучения, знакомства со специальной литературой, общения с коллегами. Термины, концепции и процессы, представленные в книге, соответствуют американскому стандарту управления проектами (Giude to the Project Management Body of Knowledge – PMBOK). Книга предназначена для тех, кто только начинает карьеру в области управления проектами и закладывает фундамент для постижения основ профессиональной методологии. Но все примеры, шаблоны и контрольные списки, приведенные в книге, можно использовать в любом проекте.

Оглавление

  • Предисловие редактора русского издания
  • Введение
  • Глава 1. Строительство фундамента

Приведённый ознакомительный фрагмент книги Управление проектами. Быстрый старт предоставлен нашим книжным партнёром — компанией ЛитРес.

Глава 1. Строительство фундамента

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

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

В этой главе мы начнем строить фундамент процесса успешного управления проектами:

Определение управления проектами;

Различные организационные структуры;

Группы процессов управления проектами;

Критерии проекта;

Ограничения и их воздействие;

Сертификация управления проектами.

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

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

Что можно назвать проектом?

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

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

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

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

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

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

Таблица 1.1. Проекты и текущие операции

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

Потребитель — конечный пользователь или получатель проектного товара или услуги. С точки зрения компании, потребители бывают внутренними и внешними.

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

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

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

Взгляд с высоты птичьего полета

Первым примером проекта является книга, которую вы держите в руках. Вы еще не дочитали ее до конца (конечно, если вы читаете ее в первый раз). Без сомнения, вы задаетесь вопросом: «Смогу ли я получить необходимую информацию?» или «Смогу ли я, прочитав эту книгу, более эффективно выполнить следующий проект?» Естественно, на оба вопроса я отвечу «да», но вы об этом еще не догадываетесь. Только освоив книгу до конца, вы сможете ответить на свои вопросы, все обдумать и обнаружить, что ваш багаж пополнился новыми знаниями и инструментами управления следующим проектом. Другими словами, вы удовлетворили свое любопытство и углубили знания об управлении проектами.

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

Проекты возникают по необходимости, относящейся к ожиданиям потребителей от конечных результатов. Но как достичь этих результатов? Как определить степень удовлетворенности потребителей? В табл. 1.2 представлена панорама контрольного списка планов, которые мы будем составлять, и методов, которые мы будем применять в ходе выполнения проекта. Не страшно, если вы не все поймете сразу. Постепенно мы детально обсудим каждый пункт. Еще раз этот список мы пройдем в том же формате в Приложении С «Образец контрольного перечня управления проектом».

Контрольный список проектных процессов (Checklist of Project Processes) можно загрузить по адресу www.sybex.com или www.harborlightpress.com .

Таблица 1.2. Контрольный список проектных процессов

Уставы, графики, бюджеты — ничего себе! Если вам кажется, что это безумный объем работы, то вы правы. Но любое дело стоит времени и усилий, потраченных на его тщательное и правильное выполнение. А объем сил и средств, вложенных в каждый пункт списка, зависит от размера проекта. Может, вам станет легче, когда вы узнаете, что для маленьких проектов некоторые пункты можно совмещать или сокращать, в зависимости от задания и последствий его неудачного выполнения для вашего карьерного роста.

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

Знание структуры организации

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

Функциональные организации

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

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

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

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

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

Функциональная организация имеет следующие преимущества.

Четкая структура подчинения — участники проектной группы подчиняются одному начальнику и ясно понимают структуру власти.

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

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

Недостатки функциональной организации перечислены ниже.

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

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

• Конкуренция ресурсов — при выполнении множества задач и проектов ресурсы отдела истощаются под грузом ответственности, что негативно сказывается на эффективности работы. (Если честно, такое случается в любой структуре.)

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

Проектно-ориентированные организации

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

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

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

Совмещенность — все участники проекта физически располагаются в одном месте.

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

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

Проектно-ориентированные организации имеют следующие преимущества:

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

Менеджеры проектов принимают решения самостоятельно — это конкретизирует коммуникацию, решение проблем и расстановку приоритетов. Решения принимаются именно здесь.

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

Проектно-ориентированные организации имеют следующие недостатки.

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

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

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

Матричные организации

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

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

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

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

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

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

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

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

Сильная матричная организация обладает следующими преимуществами.

Организация ориентирована на выполнение проектных работ — ресурсы направляются преимущественно на выполнение проекта.

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

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

Недостатки матричной организации представлены ниже.

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

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

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

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

Использование преимуществ практики управления проектами

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

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

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

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

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

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

• совершенствование выполнения проекта в целом;

• сокращение срока выполнения проекта;

• сокращение проектных рисков;

• совершенствование взаимодействия и обеспечение открытой коммуникационной среды;

• разработка стандартной методики для всей организации;

• обеспечение последовательной отчетности;

• повышение точности проектных отчетов.

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

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

Однако покупать чужие решения совсем не обязательно. Потратив немного времени и усилий, с благословения группы управления можно разработать собственные методы, опираясь на стандарты, установленные такими организациями, как Институт управления проектами (Project Management Institute — PMI). PMI разрабатывает действующие международные стандарты управления проектами, и я во многом руководствовался их рекомендациями, методологией и терминологией при создании этой книги. Кроме методологии PMI, существуют другие, не менее эффективные технологии управления. Далее в этой главе я приведу адреса нескольких Web-сайтов, где можно найти свежие идеи и подходы к управлению проектами.

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

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

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

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

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

Попробуйте проверить сами. Войдите в любимую поисковую систему Интернета и введите «информационные системы управления проектами» (или «project management software»). Результат поиска даст вам целое множество разных систем, от планирования и распределения времени до оценки рисков и т. д. Существует огромное количество разнообразных программных продуктов. Неужели все они так уж необходимы? И так полезны? Это зависит от многих факторов.

Давным-давно, в древние времена не было компьютеров и, соответственно, программного обеспечения. Все делалось — только представьте себе! — на бумаге. Это я в том смысле, что полезность инструмента зависит от количества приложенного к нему труда. Автоматизация процессов, конечно, помогает при планировании, разработке графиков, контроле (это всего лишь несколько функций из списка), но при этом требуется понимать, откуда берутся результаты, появляющиеся на экране. Сегодня во всех начальных школах детей учат выполнять арифметические действия в уме и заставляют заучивать таблицу умножения. Зачем это делается, если можно в первый же день занятий раздать первоклассникам калькуляторы? Затем, что дети должны понимать, почему при нажатии кнопок 2 × 2 на дисплее появляется цифра 4. (При этом каждый раз возникает вопрос: что будет, когда инопланетяне вторгнутся на Землю, перевернут вверх ногами электромагнитное поле и все компьютеры превратятся в пресс-папье в стиле ар деко? Как тогда производить расчеты?) Знание формул, процессов и теории, на основании которой делаются выводы, позволит значительно глубже осознать степень воздействия на проект любых изменений и рисков.

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

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

Шаблоны форматов проектов

Вы когда-нибудь в детстве рисовали по трафаретам? Берете в одну руку любимый карандаш номер два, другой плотно прижимаете трафарет к бумаге, обводите его и получаете практически идеальную форму. Шаблоны — это примерно то же самое. Они обеспечивают единообразный формат всего плана, от констатации целей до отчета о ходе работ, и могут использоваться многократно. Далее мы рассмотрим несколько примеров таких шаблонов. Если они раззадорят ваш аппетит и вам захочется получить больше информации, посетите сайты, где можно найти шаблоны, информацию и статьи по управлению проектами. Вот адреса некоторых из них:

Задействуйте любимую поисковую систему — может быть, вам удастся найти что-то еще.

Журнал проекта

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

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

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

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

Понимание процессов проекта

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

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

Жизненный цикл проекта — все этапы проекта в комплексе с самого начала проекта до его завершения.

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

Эстафетная передача — переход между фазами жизненного цикла проекта.

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

Процесс инициации

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

• определение основных целей проекта;

• определение критериев выбора проекта;

• назначение менеджера проекта;

• разработка устава проекта;

• подписание устава проекта.

Инициация — первая группа процессов, когда заказывается, утверждается и начинается разработка проекта.

Процесс планирования

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

• определение результатов проекта;

• разработка и публикация констатации содержания проекта;

• согласование бюджета проекта;

• определение проектных операций и расчетов;

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

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

Процесс выполнения

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

• создание и комплектация проектной группы;

• управление и руководство проектной группой;

• получение других проектных ресурсов;

• проведение статусных контрольных совещаний;

• управление развитием проекта;

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

Процесс мониторинга и контроля

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

• измерение выполнения в соответствии с планом;

• выполнение корректирующих операций в случае превышения лимита показателей;

• оценка эффективности корректирующих операций;

• обеспечение хода развития проекта в соответствии с планом;

• оценка и осуществление изменений.

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

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

Процесс завершения

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

• приемка результатов проекта;

• документирование уроков, извлеченных из проекта;

• архивация отчетных документов;

• оформление завершения проекта;

• высвобождение проектных ресурсов.

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

Представьте себе, что у вас в шкафу на полке стоит лекарство, которое позволяет вылечить любую болезнь. Чтобы научиться управлять проектами, вам достаточно запомнить формулу такого лекарства: IPECC (Initiating — Инициализация, Planning — Планирование, Executing — Исполнение, Controlling — Контроль, Closing — Завершение). Обратите внимание: из группы управления вы должны удалить такое понятие, как «мониторинг». Если вы сможете эффективно применять эти методики, ваш проект должен стать успешным.

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

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

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

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

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

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

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

Новое — это хорошо забытое старое

Даже повторяя некоторые процессы, которые применяли наши древние коллеги, мы называем их по-другому. Институт управления проектами (Project Management Institute — PMI) ведет активную деятельность по разработке универсальных стандартов, рекомендаций и терминологии управления проектами, которые можно использовать в любой промышленной области. Стандартизация названий процессов и деталей проектов дает возможность всем участникам одинаково воспринимать рабочую тему. Если вы сообщаете о проблемах с расписанием ресурсов (scheduling resources for tasks), мне становится сразу понятно, о чем идет речь и на каком этапе процесса управления вы находитесь.

Заинтересованное лицо (stakeholder) — любое лицо, имеющее личную заинтересованность в проекте.

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

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

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

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

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

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

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

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

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

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

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

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

Удовлетворение потребителей

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

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

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

Жонглирование

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

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

Но иногда выделить основное ограничение бывает непросто. Вот пример: начальник передал вам новый проект модернизации сети компании. Требуется до 1 ноября преобразовать сеть компании в соответствии с последними технологиями, при этом бюджет ни на цент не должен превышать 150 000 долл. США. Как в этой ситуации определить приоритетное ограничение? На первый взгляд, это невозможно. Проект в равной степени ограничен и бюджетом, и сроками. Тогда задайте начальнику вопрос: «Если бы перед вами стоял выбор — завершить проект к 1 ноября или остаться в рамках бюджета, что бы вы предпочли?» Если начальник выбирает бюджет, это говорит о том, что финансовый вопрос имеет преимущественное значение. Значит ли это, что сроки можно не соблюдать? Нет, это значит, что в случае возникновения каких-либо проблем начальника можно убедить более гибко подойти к решению вопроса сроков, так как вы понимаете, что бюджет в любом случае останется неизменным.

Источник: http://kartaslov.ru/%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8/%D0%A5%D0%B5%D0%BB%D0%B4%D0%BC%D0%B0%D0%BD_%D0%9A_%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8_%D0%91%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82/3

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

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

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

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

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

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

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

Для работы с командой:

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

Для работы с клиентом:

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

Инструменты менеджера проекта

  • 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. Записки с передовой. Хенрик Книберг;
  • Обнимите своих клиентов. Джек Митчелл;
  • Русская модель управления. Александр Прохоров.

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

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

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

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

  • Бюро Горбунова;
  • «Хабр». очень старомодный и нотационный, читать статьи по менеджменту на «Хабре» стоит только для того, чтобы понять, как думают разработчики: учиться общаться с людьми стоит в других местах;
  • .
  • Проект «Эвотора» о малом бизнесе в России;
  • «Тёмная сторона». Про MVP и как отделять важное от остального;
  • «Бабаева, к доске!». Про ченджмаркетинг;
  • «Деловая переписка». Как писать по работе;
  • «Цифровой этикет». Как не бесить друг друга в интернете;
  • «Чёт приуныл». Про критическое продуктовое мышление. А ещё есть очень классный блог, где контент не дублирует контент канала;
  • «Экстраполяция менеджмента».

Книги, статьи и — это хорошо. Но если у тебя есть интерес к менеджменту, то 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».

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

Источник: http://livetyping.com/ru/blog/chto-nuzhno-znat-i-umet-chtoby-rabotat-menedzherom-proektov