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

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

Начнем с планирования. Я даже не буду вспоминать мифический человеко-месяц Брукса и рассуждать о неприемлемости «водопадной» модели создания программного обеспечения. Это слишком сложно для современных IT project manager. Те немногие из них, кто смотрел работы Брукса и Йордона относятся к ним примерно так же как к цитатам с bash.org-а, т.е. как к кусочкам текста, для каждого из которых требуется нажать кнопку «смешно» или «не смешно». Но я буду говорить совсем о простом. Первое распространенное заблуждениt проектного менеджера заключается в том, что английское слово plan является  существительным, обозначающим диаграмму, схему или чертеж. Это не совсем так. Слово plan это еще и глагол, означающий намериваться, задумывать, проектировать, затевать. Из первого заблуждения у проектного менеджера возникает второе заблуждение, о необходимости использования для планирования программного продукта MS Project. MS Project замечательный инструмент, если речь, например, идет о заполнении табелей учета рабочего времени, но он совершенно не подходит для проектирования и реализации ИТ-решений. Другой вредной привычкой проектного управляющего является чрезмерное увлечение телефонными разговорами и электронной почтой. Телефон хорош для приватной беседы и получения неформальных указаний из министерства, а электронная почта для массовых рассылок заведомо ложной информации, именуемой в народе спамом.

Какими же инструментами должен пользоваться лидер ИТ-команды? На самом деле, их всего три: общий сетевой каталог проекта, перечень задач и список рассылки.
Общий каталог информации играет в командной работе базовую роль, а именно предоставляет участникам команды иметь единое видение проекта. Не так важно будет ли это общая папка сетевом диске, версионное хранилище с поддержкой WebDAV или дорогостоящая ECM, главное чтоб источник информации у всех был единый.
Перечень задач – инструмент менее любимый в современной офисной среде. Ведь благодаря ему становится ясно кто, что и когда должен сделать. Он лишает нас бесценной возможности спонтанного человеческого общения на многочасовых совещаниях в обсуждении извечных вопросов добра и зла, столь важных для современного цивилизованного человека. Впрочем, придумано множество эффективных способов перечню задач. Первый и наиболее эффективный заключается в том, что проектный менеджер ведет локальный список работ и никому его не показывает. Зачем тратить силы и нервы согласуя срок завершения работы с её исполнителем. Гораздо проще записать, кто и что делает в своем блокнотике, а затем своевременно эскалировать руководству срывы сроков, случившиеся по вине нерадивых работников. Еще один эффективный способ сплотить команду заключается в том, чтоб ответственность за ту или иную задачу возложить на нескольких исполнителей. Тогда каждый из безответственных за решение задачи будет испытывать как легкое чувство вины, так и более явное чувство негодования пассивностью коллег.
И наконец, список рассылки, он же журнал проекта (блоги, RSS и т.д.). С какой радостью люди пишут всякую хрень в блогах, твиттере и других социальных инструментах. Но к проектам они подходят более основательно. Для того чтоб обменяться последними новостями надо заблаговременно назначить встречу, согласовать agenda, забронировать переговорную. Причем, для больших проектов лучше провести несколько встреч, ведь тогда разным группам заинтересованных лиц можно представить разные, порой прямо противоположные версии произошедшего. Не этому ли нас учили на курсах эффективной проектной коммуникации.

А теперь пару слов серьезно. Как вы поняли, у меня есть глубокая неудовлетворенность деятельностью современных мне project manager-ов. Потому, я и далее буду  в своем блоге фиксировать моменты, связанные с их невежеством, ограниченностью и неэффективностью. Если и Вам есть чем поделиться, welcome

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

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

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

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

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

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

  3. Наблюдаю картину, когда в управление проектами приходят неопытные кадры, не имеющие навыков управления людьми, не имеющие знаний в управлении проектами, и, главное, не желающие получать, осваивать и применять знания на практике.
    Вот пример, который сейчас прорабатываю практически: сделал корпоративный стандарт по управлению проектами для компании-клиента, но проекты как проваливались ранее, так и проваливаются сейчас. Провели аудит нескольких проектов, выявили общие закономерности, ведущие к неудачам – корпоративный стандарт не выполняется, его никто из менеджеров проектов не придерживается, контроль со стороны руководства – отсутствует. Снова ничего не изменилось – люди продолжают действовать по шаблонам, не учитывая ими же самими выявленные недостатки, а руководство не имеет воли контролировать.
    Теперь договорился с руководством о проведении обучения персонала практике инициации, планирования, контроля исполнения, мониторинга и управления, завершения.
    Следующий шаг – налаживание контроля и доведение до автоматизма. Потом – анализ полученных результатов и изменение стандарта с целью оптимизации.
    Для ИТ проектов, особенно связанных с программированием – поголовная безграмотность с момента сбора и анализа требований, выбора жизненного цикла проекта, незнание Personal Software Process и нежелание его придерживаться со стороны программистов(т.е. отсутствие технологичности в работе)и незнание преимуществ PSP со стороны менеджеров, влекущие за собой серьёзные проблемы с оценками сроков, нежелание изучать и использовать метод критической цепи из ТОС и т.д.
    То есть нужно отбирать тех, кому интересно, кто хочет учиться и учится, воплощать знания на практике,и помогать выстраивать технологичные процессы.
    При этом знание предметной области является желательным для понимания происходящего.

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

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

      Позиция, связанная с управление ИТ-проектом, все еще рассматривается не как самостоятельная область знаний/умений/опыта, а лишь как способ поднять себе зарплату.

      Что касается приведенного примера, то рекомендовал бы простую вещь, но эффективно используемую в Scrum. В этой практике вводится роль Scrum-master, основная цель которого, как раз в том, чтобы “склеить” всю команду и процессы. Другими словами, в данном случае нужен некоторый coach, который будет заниматься тем, чтобы предложенная методика работала.

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

    1. Честно говоря, я думаю, что основная причина неудачи проектов внедрения лежит не внутри проекта, а в его окружении, к сожалению 🙁 Еженедельные совещания с отчетом, тех. поддержка и инструкции по процессу – это хорошо.

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

      1. Окружение это конечно важный момент )

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

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

  4. Всё правильно – при внедрении новой системы нельзя забывать о том, что меняется так называемый Job Design – способ, которым люди выполняют свою работу. именно об обучении их новому способу выполнения своей работы с использованием опять же новой системы и идёт речь. Часто как раз на это менеджеры проектов НЕ обращают своё внимание, после чего удивляются, почему внедрение системы встречает сопротивление со стороны сотрудников.
    То есть надо помнить: “Учиться, учиться и учиться!” 😉

Добавить комментарий для Максим Смирнов Отменить ответ

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