Начинаем эти заметки фрагментами серии «Newsletter», которую ведет Майк Ньюэлл, вице-президент компании PSM Consulting, любезно разрешивший нам использовать его материалы. Легкая и непринужденная форма его рассказов прекрасно сочетается с серьезным содержанием. В первой заметке автор на примере конкретного проекта рассматривает проблемы, возникающие в результате игнорирования основ проектного управления.
 |
| Майк Ньюэлл — вице-президент компании PSM Consulting, сертифицированный профессиональный управляющий проектами (PMP), член Института управления проектами (PMI). Автор имеет многолетний успешный опыт руководства крупными проектами и консалтинга в этой области, проводит обучение на специализированных курсах по управлению проектами и PMP-сертификацию. Летом 2000 года Ньюэлл провел первую в России сертификацию по программе PMI. Связаться с ним можно по электронной почте: mnewell@psmconsult.com |
Рассмотрим пример. В рамках типичного современного ИТ-проекта предполагалось организовать оперативный просмотр через Web пяти финансовых отчетов для клиента, который, убедившись в том, что первая пятерка отчетов успешно выпущена, намерен продолжать подготовку остальных таким же образом.
Два члена группы, ведущей проект, посетили офис клиента вместе со специалистом по бизнес-разработкам, чтобы точно определить, что именно требуется сделать и какая для этого необходима инфраструктура.
Учитывая очень сжатые сроки проекта, клиент и подрядчик решили, что необходим менеджер проекта, который сможет гарантировать своевременное выполнение всей необходимой работы. И клиент, и подрядчик согласились с тем, что лишь половина всего рабочего времени менеджера будет посвящена этому проекту. Было организовано совещание, в котором приняли участие четыре ведущих специалиста, занятые в проекте со стороны клиента, два специалиста со стороны подрядчика и менеджер проекта. Затем менеджер проекта совместно с двумя членами группы разработал список действий, определил сроки реализации, необходимые для этого ресурсы, а также методику согласования и обмена информацией. На следующее совещание были приглашены представители клиента, участвующие в реализации проекта, которые внесли некоторые дополнения и исправления в список задач. Менеджер проекта с самого начала считал, что они должны согласиться с предложенным планом и подписать его. Клиент настаивал, чтобы ему был передан подписанный контракт, утвержденный всеми членами группы, работающей над проектом. Такое решение обеспечило бы уверенность в том, что каждый знает, что ему следует ожидать от других.
Однако, как это происходит во многих современных ИТ-проектах, некоторые члены группы появлялись в офисе клиента совсем ненадолго и предпочитали заканчивать свою работу самостоятельно, вне центрального офиса. Все, за исключением двух членов группы, работали именно так.
Проблемы стали возникать практически сразу. Один из членов группы заболел и был вынужден вернуться в свой родной город на лечение. Другой завяз в технических проблемах, связанных с каким-то ПО, и в переговорах с производителем, которые он вел по этому поводу. Менеджер проекта вмешался и решил этот вопрос, благодаря чему член группы смог продолжить работу. Затем команда увязла во множестве других проблем. Один из членов группы потерял водительские права. Кроме того, он превысил сумму, хранившуюся на кредитной карточке, и у него не было ни гроша в кармане, пока он ждал проверки своих расходных чеков. Все члены команды до последней минуты не могли спланировать свои командировки. Они были вынуждены откладывать поездку до последнего возможного рейса, нервничая из-за неясности или, что еще хуже, из-за того, что могут отменить рейс. Несмотря на то что члены группы были обязаны отчитываться менеджеру проекта о том, как расходуется их время и деньги, ему часто приходилось чуть не силком выпытывать из них эту информацию.
Тем временем клиент создал комитет, который отвечал за создание отчетов и хранил информацию о произведенных изменениях, но члены проектной группы, которые должны были работать над этой базой данных, чтобы корректно учитывать внесенные изменения, не закончили свою часть работы (не меняйте управляющую систему!). Затем один из членов группы отказался приезжать в офис клиента, чтобы писать программу для пользовательского интерфейса, сославшись на нехватку финансирования. Он согласился работать удаленно, но промежуточные результаты никогда не посылал. Примерно через десять дней такой работы он и вовсе ушел из компании.
Телефонные конференции должны были проходить дважды в день, но некоторые члены группы не считали себя обязанными участвовать в них или забывали, и им приходилось об этом напоминать. Один из членов группы был независимым разработчиком, работавшим по контракту, и имел еще и другие обязательства.
Вместо него был найден другой специалист, но он не имел всех необходимых для этой работы навыков, поэтому пришлось взять на подмогу еще одного человека. В момент его появления ни одного из членов проектной группы, за исключением менеджера проекта, не оказалось на месте. Менеджер смог показать новому сотруднику, что необходимо сделать, но код, который, как предполагалось, был уже написан, найти не удалось. В итоге новому члену группы пришлось начать все с нуля и написать необходимый код.
Потребовалась еще неделя круглосуточной (в буквальном смысле) работы сверх первоначально установленного срока окончания проекта, прежде чем система подготовки отчетов была готова и прошла ее «живая» демонстрация. Один из членов группы действительно оказался квалифицированным и надежным специалистом и наладил хорошие взаимоотношения с клиентом. Благодаря этому клиент согласился доверить тому же подрядчику реализацию следующего этапа.
Это типичный пример плохой организации работы группы, невыполнения обязанностей, плохой связи и плохого управления изменениями. Если бы менеджер проекта во время его реализации 100% времени находился на рабочем месте, если бы члены группы имели должную мотивацию и выполняли свои обязанности если бы...
Что необходимо сделать, чтобы не допустить повторения такой ситуации? В ближайших выпусках мы поговорим о том, как избежать подобного рода проблем.
Забавные эпизоды
# 1
Линда и Мэрион делятся впечатлениями о том, как трудно работать в небольшой компании.
- В прошлом году я начала работать по-новому, — рассказывает Линда. — Теперь я настаиваю, чтобы мои сотрудники каждые три месяца брали как минимум неделю отпуска.
- Зачем же это нужно? — спросила Мэрион.
- Это лучший способ понять, могу ли я без них обойтись, — объяснила Линда.
К счастью, такого рода руководителей становится все меньше и меньше в компаниях, и все мы можем брать отпуск, когда хотим.
#
2Я не устаю твердить о том, насколько важна взаимосвязь при реализации проекта. При этом управление — один из самых важных аспектов. Если сотрудники недостаточно общаются между собой, легко может возникнуть недопонимание. Когда это происходит, проблемы с проектом неминуемы. Вот история, которая это иллюстрирует.
Муж спрашивает свою жену:
- Чего бы ты хотела в свой день рождения?
- Было бы здорово опять почувствовать, что мне десять лет, — ответила она.
Утром в день ее рождения муж повел жену в парк аттракционов. Они посетили и «Гору смерти», и «Центрифугу», и «Стену страха». Короче, все, что там было. Когда пять часов спустя они выходили из парка, у нее кружилась голова и казалось, что желудок выворачивается наизнанку.
Они зашли в «Макдоналдс», где муж купил жене двойной биг-мак с большой картошкой и клубничный коктейль. Затем он повел жену в кино на «Звездные войны», где снова были гамбургеры, попкорн, кола и конфеты. Наконец они добрались до дома, и жена рухнула в постель.
Муж наклонился к ней и спросил:
- Ну как, дорогая, хорошо опять почувствовать, что тебе десять лет?
Приоткрыв один глаз, она с трудом прошептала:
- Дорогой, я имела в виду размер платья.