Метка: IT Strategy

Воспоминания о 2013-м

pace_layers_houseНакануне Нового года принято не только писать блог, но и перечитывать записи за год прошедший (см. прошлогодний обзор). На самом деле, читать собственные записи даже полезней, чем писать новые. Так несколько дней назад я раскопал в своем старом живом журнале  который давно забросил,  майскую заметку 2006(!) года «Адаптивная модель бизнес-процесса”, в которой написал примерно следующее:

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

Никакого Adaptive Case Management-а в 2006 году, как вы сами понимаете, еще не было. Но, оказывается потребность в такого рода решения не только существовала, но и была мною озвучена. Продолжить чтение «Воспоминания о 2013-м»

Ресурсное планирование и отслеживание трудозатрат

Нужно больше арахисаНачиная эту заметку, я должен сделать два предварительных замечания. Во-первых, тема ресурсного планирования не имеет какого-либо отношения к архитектуре информационных систем. Разве что, кроме того случая, когда архитекторам начинают задавать вопрос а почему это вас так много, а архитектуру вы рисуете так долго. К сожалению, у меня в очередной раз произошел этот самый случай и мне хочется поделиться удачными и не очень удачными вариантами ответа на этот вопрос. Во-вторых, мой многолетний опыт показывает, что ресурсное планирование и отслеживание трудозатрат knowledge workers обычно никак не влияет на размер материальной мотивации, но практически всегда разрушает мотивацию нематериальную, причем делает это очень быстро.  Продолжить чтение «Ресурсное планирование и отслеживание трудозатрат»

Gartner: Projects Today, «Change Operations» Tomorrow

За пару дней до Нового года Андрей Коптелов поделился ссылкой на июльскую статью Владимира Иванова Доклад Gartner: Будьте готовы к будущему управления портфелями и программами проектов Я решил разобраться более подробно в том, что предрекает Gartner проектному менеджменту и кроме презентации Be Prepared For the Future of Program and Portfolio Management посмотрел их более ранние работы:

Не стану пересказывать статью Владимира Иванова. Позволю себе лишь несколько акцентов. Итак, аналитики предсказывают, что организации на треть сократят сроки и стоимость реализуемых проектов (Думаю, в наших условиях речь может идти о 50% и больше). Это приведет к серьезному давлению, как на проектные офисы, так и на средства их автоматизации. Системы управления проектами и портфелями проектов мне никогда не нравились, так что туда им и дорога. Впрочем, проектные офисы, в отличии от «боевых» проектных менеджеров, тоже приносили проблем больше чем результатов. Одним словом, предсказания аналитиков вполне созвучны и моим рассуждениям:

Резонный вопрос: как организовать Getting Things Done в условиях такого давления. Как справедливо замечают аналитики Gartner, проекты бывают разными. Значительная часть активностей, осуществляемых организациями, заключается в улучшениях уже существующих продуктов. Вести их в формате традиционных проектов, как-то совсем неразумно. Кстати, в ИТ уже давно существуют процессы управления проблемами и управления изменениями. Вопрос в том, насколько широко трактовать эти процессы. Например, замена устаревшей ИТ системы на новую, казалось бы, типичный пример ИТ проекта. В действительности, эта активность намного ближе к управлению проблемой (недостаточная масштабируемость или функциональность системы). Возможно, качественное решение проблем освободит нас от необходимости инициировать новый проект и внедрять новую ИТ систему. Это как раз то, о чем я собираюсь рассказывать в теме Интеграция новых приложений в корпоративный ИТ-ландшафт

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

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

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

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

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