Библиотека Интернет Индустрии I2R.ru

Эти мысли навеяны статьей  Майка Ньюэлла "Проект "если бы", в которой приводится пример того, как несколько объективных причин вкупе с неудачным руководством могут привести IT проект к краху.

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

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

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

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

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

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

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

В книге Э.У. Старобинский "Как управлять персоналом" предлагается такой вариант скользящего графика. При рабочем дне с 8 до 17 работник может прийти на работу в диапазоне с 8 до 10 часов и покинуть работу с 15 до 17 часов, однако с 10 до 12 и с 14 до 15 он обязательно должен находиться на рабочем месте. Это позволит обеспечить работу менеджера проекта и своевременный контроль за ходом ведения работы.

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

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

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

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

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

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

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

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

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

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