Рубрика: IT Project

Проект IT Transformation

13-22012011_3Наступил месяц декабрь. За окном падает легкий снег  и я думаю, теперь уже можно считать, что проект ИТ трансформации у нас, наконец, закончился. Ну, в основном, закончился. У нас нет орг.структуры, у нас нет CIO, нет так же руководителя проектного офиса ИТ, менеджера основного ИТ проекта, нет стратегии, но… зато у нас есть целевая архитектура (target architecture). Не то чтоб совсем актуальная, ну да ладно. Это уже мой третий проект ИТ трансформации, поэтому если кто решил трансформировать свой ИТ, но не знает с чего(или с кого) начать, обращайтесь Continue reading «Проект IT Transformation»

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

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

Неопределенность качества информационных систем

forsalecarПредположим у вас есть команда лучших программистов в мире и они разрабатывают гениальный программный продукт. Лучший в своем классе. Способный после короткого 1,5-2 недельного обучения пользователей катастрофически повысить производительность их труда. К сожалению, вы вряд ли сможете выгодно продать такой программный продукт. Не сможете потому, что есть сотни или тысячи других людей, продающих информационные технологии. А заказчик (пользователь) он просто не очень понимает, какая программа, действительно, хорошая, а какая нет. Для него программное обеспечение как часы. Он видит только циферблат и стрелки, но не знает, как устроен механизм внутри часов.  Продавать хорошее программное обеспечение это как продавать хороший, но не очень новый автомобиль. Он не попадал в аварию и регулярно проходил ТО. Вы-то знаете, что за пять лет эксплуатации с машиной не было никаких проблем. Но покупатель этого не знает. Он видит перед собой еще сотню внешне таких же машин — кузов вроде не битый, салон в хорошем состоянии, моторный отсек чистый и 99% из них имеют скрытые проблемы (потому их и продают).  Вы никогда не получите за такую машину справедливую цену, так зачем же её продавать?  Continue reading «Неопределенность качества информационных систем»

Программная инженерия. Управление рисками

Я немного присматриваю за тем, как в одном из вузов готовят программных инженеров (специальность 231000), и буду иногда писать в блог свои впечатления. Так получилось, что сразу после вводной лекции к курсу студентов ознакомили с управлением рисками ИТ-проекта. Наверное, такая последовательность изложения материалов не очень верна, но почему-то вот так сложилось. Поэтому сегодня пару слов об управлении рисками. Про риски сказано много. Сказано. что их надо выявлять, оценивать, мониторить, митигировать и т.д. Все это я повторять не стану, а выскажу своё понимание рисков.

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

Небольшое отступление. То, что план проекта и расписание проекта – это не одно и то же, знают многие. Не многие помнят, что английское слово plan может являться не только существительным, но и глаголом. Хороший проектный менеджер считает, что план — это именно глагол, а не существительное.

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

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

Gartner: Projects Today, «Change Operations» Tomorrow

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

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

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

Интеграция новых приложений в корпоративный ИТ-ландшафт

Большинство методологий разработки  программного обеспечения предполагают создание программного продукта с нуля. Они сформировались в те времена, когда требовалось автоматизировать операции заказчика, осуществляемые до этого вручную. Пользователи работали с бумажными документами, информацию хранили в локальных файлах и обменивались ими по электронной почте. Разработчик документировал требования, описывал бизнес-процессы, реализовывал и внедрял решение. Continue reading «Интеграция новых приложений в корпоративный ИТ-ландшафт»

Atlassian JIRA 5.0(beta) закручивает воронку событий

Когда-то я рассказывал о решении tibbr от TIBCO Software (см. Интранет, интеграционная среда или корпоративный портал?) Предназначено оно для того, чтоб собрать все потоки событий в корпоративную ленту сообщений. Лента чем-то напоминает twitter, но подписываетесь вы не на сообщения от конкретного персонажа, а на определенную тему. Естественно, организация сама для себя может построить необходимую иерархию тем. Посылать сообщения в ленту могут в равной степени люди и приложения.

Похоже, что JIRA направляется тем же путем. Сейчас идет beta-тестирование пятой версии. В анонсе к ней 5 Reasons to get JIRA 5 Beta в качестве первых трех преимуществ указана интегрируемость решения. Continue reading «Atlassian JIRA 5.0(beta) закручивает воронку событий»