Существует множество способов потратить освоить бюджет. Но, пожалуй, наиболее запутанный и наименее предсказуемый из них это project management. Мне довелось не только руководить проектами, но и получить определенное образование в этой области. И речь идет не о курсах выходного дня по управлению проектами, а о более чем 500-часовом обучении в одной из известных школ управления.
Причина неэффективности проектного управления достаточно проста. За многолетнюю историю своего существования эта дисциплина насобирала такое количество подходов и методологий, что использование их напоминает перебор множества ключей, висящей на огромной связки, для открытия незапертой двери. Методы подготовки к высадке на Луну или строительства небоскребов, благодаря проектному менеджменту, применяются для разработки ИТ-решений или же обработки клиентских запросов. Даже такие базовые виды деятельности менеджера ИТ-проектов, как планирование, контроль и управления рисками являют собой настолько явный фарс, что остается только удивляться тому, что какие-то из ИТ проектов еще и доходят до запуска.
Начнем с планирования. Я даже не буду вспоминать мифический человеко-месяц Брукса и рассуждать о неприемлемости «водопадной» модели создания программного обеспечения. Это слишком сложно для современных IT project manager. Те немногие из них, кто смотрел работы Брукса и Йордона относятся к ним примерно так же как к цитатам с bash.org-а, т.е. как к кусочкам текста, для каждого из которых требуется нажать кнопку «смешно» или «не смешно». Но я буду говорить совсем о простом. Первое распространенное заблуждениt проектного менеджера заключается в том, что английское слово plan является существительным, обозначающим диаграмму, схему или чертеж. Это не совсем так. Слово plan это еще и глагол, означающий намериваться, задумывать, проектировать, затевать. Из первого заблуждения у проектного менеджера возникает второе заблуждение, о необходимости использования для планирования программного продукта MS Project. MS Project замечательный инструмент, если речь, например, идет о заполнении табелей учета рабочего времени, но он совершенно не подходит для проектирования и реализации ИТ-решений. Другой вредной привычкой проектного управляющего является чрезмерное увлечение телефонными разговорами и электронной почтой. Телефон хорош для приватной беседы и получения неформальных указаний из министерства, а электронная почта для массовых рассылок заведомо ложной информации, именуемой в народе спамом.
Какими же инструментами должен пользоваться лидер ИТ-команды? На самом деле, их всего три: общий сетевой каталог проекта, перечень задач и список рассылки.
Общий каталог информации играет в командной работе базовую роль, а именно предоставляет участникам команды иметь единое видение проекта. Не так важно будет ли это общая папка сетевом диске, версионное хранилище с поддержкой WebDAV или дорогостоящая ECM, главное чтоб источник информации у всех был единый.
Перечень задач – инструмент менее любимый в современной офисной среде. Ведь благодаря ему становится ясно кто, что и когда должен сделать. Он лишает нас бесценной возможности спонтанного человеческого общения на многочасовых совещаниях в обсуждении извечных вопросов добра и зла, столь важных для современного цивилизованного человека. Впрочем, придумано множество эффективных способов перечню задач. Первый и наиболее эффективный заключается в том, что проектный менеджер ведет локальный список работ и никому его не показывает. Зачем тратить силы и нервы согласуя срок завершения работы с её исполнителем. Гораздо проще записать, кто и что делает в своем блокнотике, а затем своевременно эскалировать руководству срывы сроков, случившиеся по вине нерадивых работников. Еще один эффективный способ сплотить команду заключается в том, чтоб ответственность за ту или иную задачу возложить на нескольких исполнителей. Тогда каждый из безответственных за решение задачи будет испытывать как легкое чувство вины, так и более явное чувство негодования пассивностью коллег.
И наконец, список рассылки, он же журнал проекта (блоги, RSS и т.д.). С какой радостью люди пишут всякую хрень в блогах, твиттере и других социальных инструментах. Но к проектам они подходят более основательно. Для того чтоб обменяться последними новостями надо заблаговременно назначить встречу, согласовать agenda, забронировать переговорную. Причем, для больших проектов лучше провести несколько встреч, ведь тогда разным группам заинтересованных лиц можно представить разные, порой прямо противоположные версии произошедшего. Не этому ли нас учили на курсах эффективной проектной коммуникации.
А теперь пару слов серьезно. Как вы поняли, у меня есть глубокая неудовлетворенность деятельностью современных мне project manager-ов. Потому, я и далее буду в своем блоге фиксировать моменты, связанные с их невежеством, ограниченностью и неэффективностью. Если и Вам есть чем поделиться, welcome
Накануне Нового года принято не только писать блог, но и перечитывать записи за год прошедший (см. прошлогодний обзор). На самом деле, читать собственные записи даже полезней, чем писать новые. Так несколько дней назад я раскопал в своем старом живом журнале который давно забросил, майскую заметку 2006(!) года «Адаптивная модель бизнес-процесса”, в которой написал примерно следующее:
