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

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

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

Так что же мы ищем для руководителей проектов? Какие характеристики инструмента, который поможет легко управлять коммуникацией? Я думаю, необходимо найти, возможность общаться в режиме реального времени (skype, IM), и также в режиме отложенных сообщений в свободное время (email), одновременно составляя проектные документы, и всякого рода отчеты.

Ответ на наш вопрос – Google Wave!

Wave это платформа и новый стандарт связи от гиганта ИТ индустрии.

Wave это:
– Разговор и документ одновременно. Люди могут общаться и работать с форматированным текстом, добавлять фотографии, видеоматериалы, карты и многое другое.

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

— Прямая трансляция – по мере ввода текста, все участники волны видят изменения и могут добавлять различные расширения (plug-ins) в режиме реального времени.

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

Лично мне Wave понравился, и удалось даже увидеть, как им пользуются в рамках небольшого проекта. Одним словом Зачёт!

Однако для полного успеха Google Wave необходимо пересмотреть взгляд на процесс коммуникаций у большого числа людей. К тому же предстоит найти способы внедрять Wave в корпоративных масштабах.
Из последних новостей – Google объявил о прекращении развития Google Wave 4 августа 2010. Google Wave просуществует в виде отдельного продукта как минимум до конца года. Технологии, использованные в Wave, Google планирует применить в других проектах.
Надеюсь, доживем до еще более революционных проектов от Google.

Полезные ссылки:
Google Wave
Посмотреть как другие используют Google Wave
Книга по Google Wave на русском

Использованные материалы
Project Management Google Wave

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

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

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

Большая нацеленность на требования в проектном менеджменте
Вышедшее недавно 4е издание PMBOK® (Project Management Body of Knowledge) Содержит новую секцию 5.1 под названием “Сбор требований”. Которая содержит описание нескольких техник сбора требований, которые менеджер проекта должен уметь исспользовать для своего проекта. Это всего лишь часть техник описанных в Business Analysis Body of Knowledge (BABOK®), т.о. и бизнес аналитик также обязан быть знаком с ними.

Изменение подхода к требованиям
Начиная с 2009 года виден новый тренд в технике бизнес анализа. Уменьшение популярности вариантов-использования(use cases) и движение в сторону пользовательских историй (user stories) и требованиях основанных на сценариях. Use cases все еще продолжают исспользоватся для сложных требований с запутанными интерфейсами. Также наблюдается уменьшение упора на спецификацию требований, и большая нацеленность на моделирование, прототипирование и диаграммы. Есть много причин по которым наблюдается уход от формально написанных спецификаций, однако это не значит, что не нужны письменные спецификации, но показывает что, обострилась необходимость в более новых и более эфективных методах для документирования требований.

С чего начать изучать бизнес анализ
Несколько полезных ресурсов по бизнес-анализу (спасибо уходит Татьяне Прашко, нашему ведущему бизнес-аналитику)
Requirements Networking Group – where requirements gather meet
Practical Analyst - Practical Insight for Business Analysts and Project Professionals

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

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

In English:

A Girl’s Guide to Project Management: Elizabeth’s cornerstone to project management is on time, on budget, on scope. She shows you how to accomplish this through her own experiences, as well as from guest posts.

Managing Project Development: Johanna Rothman is the president of Rothman Consulting Group, Inc in Massachusetts. Her blog is for people who want to think about how they manage people, projects, and risk.

The Enlightened Manager: Cheri Baker is the owner of Emergence Consulting in Washington state. Recent posts include the subtle facilitator, e-learning, and self promotion.

Stepping Into PM: Soma is an aspiring project manager and business analyst who blogs about mistakes, the learning process, and the journey. Posts often deal with items that were helpful.

Raven’s Brain: She is a senior project manager in Seattle and blogs about her profession and other related items. There hasn’t been a new post in a while, but she does have an active Twitter feed.

Keeping the Peace: Margaret helps professionals free themselves from work related conflicts. Project managers will find loads of help in categories such as communication, inspiration, leadership, and others.

PMI Women in Project Management: This PMI group holds events all over the country for female project managers. View their calendar, read a newsletter, or get updates.

На русском:

Control Freak: Евгения Фирсова руководтель отдела веб-интерфейсов пишет об управлении людьми, задачами и проблемами.

RUNBNY: Наталья Брызгалова – менеджер интернет проектов. Блог о том, как происходит руководство командой в процессе разработки Интернет-проекта: корпоративного сайта, блога или другого Интернет-ресурса.

Если вы тоже знаете интересные блоги присылайте свои ссылки на них.

Регулярно слушаю различные подкасты. И решил сделать подборку известных мне подкастов по управлению проектами (на русском) и project management (на английском)

На великом и могучем нашлось всего ничего:

PodFM.ru: Подкасты c тэгом “Управление проектами”

PROJECT MASTER

На международном анлийском:

The PMO Podcast: This weekly program is where you will find ten minutes of insights and ideas including a points memo, featured story, and mailbag.

The Project Management Podcast: The PM Podcast looks at how project management shapes the business world and helps you achieve the level of skill you will need to succeed. Recent episodes examined the four week PMO and project management in Ethiopia.

PM War Stories: Get true life accounts from expert project managers here. Thirty episodes and counting discuss a variety of topics.

PM 411: Stop here for a project manager internet radio show, discussion forum, and more. The latest episodes deal with schedule killers and how to deal with them.

Manager Tools: This award winning podcast is a must for any manager, including project. In addition to manager tools, you can also get career tools, a blog, forums, and even a “how to interview” series.

Controlling Chaos: Although it is currently on hiatus, this podcast still has 38 episodes for the listening. Topics include managing gray areas, building effective teams, and others.

clarkeching’s Podcast: TOC, Critical Chain, Lean, Agile …

Кривая опыта (Experience curve) – термин, примененный в 1966 году компанией Boston Consulting Group.

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

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

Эффект кривой обучения

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

Эффект специализации

По мере роста производства и числа работников, компания может позволить себе вводить специализацию. Если 2 человека выполняют одну и ту же задачу, можно разделить ее между ними. Первый выполняет одну часть задачи, второй другую половину. Поэтому каждый может выполнить свою часть задачи дважды. Согласно описанному выше эффекту кривой обучения, специализация позволит снизить на 10-15% время на выпуск продукции, или на 10-15% увеличить объем.

Если опыт удваивается одновременно со специализацией, то эти 2 эффекта произойдут одновременно, что может увеличить производительность на 20-30%

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

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

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

Уровень команды

Очевидно, что одна и та же команда выполнит новый проект, аналогичный предыдущему, быстрее. Так как она уже сработалась, притерлась и выработала некие внутренние стандарты. Скорее всего, что примерно на эти же 10-15% (при условии что проект действительно аналогичный). Далее скорость выполнения типовых проектов будет расти незначительно – 7%, 3%, 2%, 1%. Однако суммарный эффект будет весьма ощутим. Дальнейшее увеличение производительности уже будет возможна только при внедрении новых технологий.

Выводы:
Используйте имеющуюся сработанную команды для выполнения повторных подобных проектов.

Уровень работника

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

Человек без опыта изготовит табуретку за 60 мин. Далее каждую последующую он будет изготавливать на 10% быстрее

Cкорость изготовления табуретки

Человек с улицы (0 табуреток опыта) – 60 мин
Подмастерье (3 табуретки опыта) – 43,7 мин
Специалист (5 табуреток опыта) – 35,4 мин
Мастер (10 табуреток опыта) – 20,9 мин

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

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

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

Про кривую опыта можно почитать тут:

Experience curve effects
Кривые опыта
О чем говорит кривая опыта?

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

Далее пробуем посчитать — насколько же ваш проект выгоден? :-)

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

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

Давайте теперь посчитаем затраты на оказание этих услуг. Что же происходило? :) Программисты программировали, тестировщики тестировали, и так далее — обобщая, люди тратили рабочее время на заказчика. Зарплата всех работников, задействованых в проекте, суммарно составила 600 тугриков. И сколько же у нас получается прибыли для организации? 400 тугриков?

Конечно же, нет. Для начала давайте вспомним, что в прошедшем месяце мы дополнительно купили для нужд программистов специализированную программную компоненту, стоимостью 100 тугриков. Что ж, добавим её к затратам, проверим чтобы больше ничего не забыли — вуаля, получаем прибыль в 300 тугриков?..

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

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

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

Если у вас есть что добавить по этому вопросу — добро пожаловать в комментарии :-)

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

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

Однако в результате переключений на выполнение каждой задачи потребовалось ~7 дней. Первый менеджер получил задачу на 4 дня позже чем мог бы, соответственно были задержаны другие задания связанные с выполненным далее по цепочке (тестирование, релиз и т.п.), была задержана оплата и т.п.

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

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

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

В заключение приведу несколько общих рекомендаций:

• Создавайте очередь задач исполнителю с определенными приоритетами. Необходимо однозначное понимание что, зачем следует выполнять. Очередь необходима для того чтобы исполнитель мог переключаться на следующую задачу, при завершении текущей (а не сидеть в ожидании), либо при невозможности выполнения текущей (на время разрешенная появившихся вопросов) опять же дело не стаяло на месте.
• Все задачи должны быть в одном месте (системе, программе или т.п.) Чтобы задания не терялись и не размывались между системами. Чтобы была возможность контролировать, кто, чем занимается в данный момент, сколько у кого уходит времени.
• Каждая задача помимо приоритета должна иметь оцененный срок выполнения, чтобы менеджер мог эффективно управлять своими ресурсами.
]]> http://pm.by/articles/management/ispolnitel-i-mnogozadachnost/feed/ 3 http://pm.by/managers/menedzher-i-mnogozadachnost/ http://pm.by/managers/menedzher-i-mnogozadachnost/#comments Sun, 10 Jan 2010 20:38:24 +0000 Сергей Синькевич http://pm.by/managers/menedzher-i-mnogozadachnost/ Существует несколько мнений на то, является ли работа в многозадачном режиме эффективной, может ли она быть полезной, и не миф ли это в принципе. Однако приходится признавать что для современного менеджера (в том числе и в разработке программного обеспечения) это вполне обьективная реальность.

Достаточно много известных людей уже высказывались на эту тему. Приведу несколько ссылок:

• Джоэл Спольски
• Опасная многозадачность
• 5 самых опасных заблуждений тайм-менеджмента
• Миф о многозадачности

Что ж, давайте попробуем самостоятельно взглянуть на этот аспект деятельности менеджера. Если взглянуть на ежедневную работу, выполняемую руководителем (например, менеджером проекта), то можно заметить, что переключение контекста происходит чрезвычайно часто. Работа с текущей почтой кажется однообразным занятием только для тех, кто не понимает что происходит. Мы же знаем, что каждое новое полученное или отправленное письмо представляет собой или новую задачу, или продолжение одной из старых. Сколько писем проходит через почтовый ящик среднего современного менеджера? 100? 300? Иногда это число измеряется не в сотнях, но в тысячах… А ведь еще есть работа с документацией, с различного рода системами таск-, баг- и ишью-трекинга. Каждый новый пункт, который мы открываем в такой системе — это новый контекст. Суммируя и усредняя, давайте будем считать, что в среднем число переключений будет равно 500.

Несложно посчитать что (8 часов рабочего дня * 60 минут) / 500 = около 1 минуты — это максимальное время переключения между контекстами, которое менеджер может себе позволить. А ведь еще необходимо провести обработку и регистрацию поступившей информации.

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

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

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

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

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

]]> http://pm.by/managers/menedzher-i-mnogozadachnost/feed/ 2 http://pm.by/tools/besplatnyj-xronometrazh/ http://pm.by/tools/besplatnyj-xronometrazh/#comments Sun, 10 Jan 2010 18:19:28 +0000 Сергей Синькевич http://pm.by/tools/besplatnyj-xronometrazh/ Вновь подниму тему персональной эффективности, и напомню коллегам о пользе хронометража личного и рабочего времени. Чтобы не изобретать велосипед, дам ссылку на выдержку из книги известного гуру тайм-менеджента Глеба Архангельского: вот она.
Известно что любая идея чахнет без подходящего инструмента, поэтому в дополнение темы о программах измерения рабочих активностей по времени, позволю себе добавить бесплатный аналог, которым сам пользуюсь уже некоторое время: ManicTime.
По функциональности, из плюсов — возможность делать личные тэги по задачам/проектам (что реально очень удобно), интуитивно понятный интерфейс; из минусов — обьём потребляемой памяти (все-таки .NET :)
]]> http://pm.by/tools/besplatnyj-xronometrazh/feed/ 0 http://pm.by/books/microsoft-office-2010-chto-novogo/ http://pm.by/books/microsoft-office-2010-chto-novogo/#comments Sun, 03 Jan 2010 22:03:39 +0000 Денис Журавлев http://pm.by/books/microsoft-office-2010-chto-novogo/ На нас надвигается новая волна продуктов от Microsoft. И вот уже до нас докатился отзвуки Office 2010 beta (оффициальный релиз запланирован в ближайшие пол-года). Что же можно ожидать в новой версии можно узнать из бесплатно распространяемой 200 - страничной книги Катерины Мюрей "First Look Office 2010" (PDF, 10Mb)
]]> На нас надвигается новая волна продуктов от Microsoft. И вот уже до нас докатились отзвуки Office 2010 beta (оффициальный релиз запланирован в ближайшие пол-года). Что же можно ожидать в новой версии можно узнать из бесплатно распространяемой 200-страничной книги Катерины Мюрей “First Look Office 2010” (PDF, 10Mb)

Краткое оглавление:

Part I Envision the Possibilities
1 Welcome to Office 2010
2 Express Yourself Effectively and Efficiently
3 Collaborate in the Office and Around the World

Part II Hit the Ground Running
4 Create and Share Compelling Documents with Word 2010
5 Create Smart Data Insights with Excel 2010
6 Manage Rich Communications with Outlook 2010
7 Produce Dynamic Presentations with PowerPoint 2010
8 Organize, Store, and Share Ideas with OneNote 2010
9 Collaborate Effectively with SharePoint Workspace 2010
10 Create Effective Marketing Materials with Publisher 2010
11 Make Sense of Your Data with Access 2010

Part III Next Steps with Office 2010
12 Putting It All Together
13 Security in Office 2010
14 Training Made Easy

]]> http://pm.by/books/microsoft-office-2010-chto-novogo/feed/ 0