Рубрика: IT Project

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

Я немного присматриваю за тем, как в одном из вузов готовят программных инженеров (специальность 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, проекты бывают разными. Значительная часть активностей, осуществляемых организациями, заключается в улучшениях уже существующих продуктов. Вести их в формате традиционных проектов, как-то совсем неразумно. Кстати, в ИТ уже давно существуют процессы управления проблемами и управления изменениями. Вопрос в том, насколько широко трактовать эти процессы. Например, замена устаревшей ИТ системы на новую, казалось бы, типичный пример ИТ проекта. В действительности, эта активность намного ближе к управлению проблемой (недостаточная масштабируемость или функциональность системы). Возможно, качественное решение проблем освободит нас от необходимости инициировать новый проект и внедрять новую ИТ систему. Это как раз то, о чем я собираюсь рассказывать в теме Интеграция новых приложений в корпоративный ИТ-ландшафт

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

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

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

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

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

Adaptive case management и GTD

Наверное, занимаясь адаптивным кейс-менеджментом нельзя было пройти мимо идеи Getting Thinks Done (GTD) Дэвида Аллена. Наконец и я прочитал эту книжку о «доведении дел до завершения» и то, что говорят о ней в Интернете. Книжка хорошая. Насколько эффективен сам метод, мне сказать сложно, т.к. я его не практиковал, но судя по огромному количеству обсуждений и массе различного ПО, людям он нравится. (Ну или людям нравится об этом поговорить).

Я не буду рассказывать про сам метод, информации о нем в сети, действительно, очень много. Приведу всего одну цитату:

Чаще всего причиной того, что что-то крутится в ваших мыслях, является ваше желание изменить это что-то, однако:

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

Для того чтобы в голове постоянно не крутились тревожные мысли о работе, человеку нужна уверенность в том, что он ничего не упустил и для каждого случая знает как поступить правильно. Такая же уверенность не помешала бы и отдельному подразделению или рабочей группе проекта. Но если сотрудник волен сам решать, какую систему персональной организации труда ему использовать, вести ли свои дела в Evernote, OmniFocus, Remember The Milk, Doit.im, на листочках или в расширениях почтового клиента, то для совместной работы без хорошего issue tracker-а не обойтись.

На текущий момент, персональные органайзеры и средства коллективной работы – это разные классы систем, но тренд на их сближение достаточно отчетлив. Успеют ли в него влиться системы адаптивного кейс-менеджмента, или же они останутся оторванными от BPM-движков worklist-ами, вот это вопрос.

Software product management (3) Change management

Продолжаю серию заметок о различиях заказного ПО и программного продукта. Я уже упоминал о том, что причиной долго времени внесения изменений в ИТ системы может являться сам процесс внесения изменений. Все мы учились на унифицированном процессе разработки ПО. Потому верим в цикл разработки, включающий сбор и анализ требований, проектирование, разработку, тестирование и развертывание решения. Большинство попыток оптимизации этого цикла сводятся к сокращению времени этих фаз. Гибкие методологии, такие как SCRUM предлагают зафиксировать вместо объема работ длительность итерации, т.е. цикл (sprint) разработки составляет всегда X недель (2 или 4), а объем требований для каждого цикла разработки определяется исходя из их сложности. В любом случае, внесение изменений в систему осуществляется только посредством разработки. Продолжить чтение «Software product management (3) Change management»

WordPress для управления задачами и проектами

BuggyPress — еще один плагин для WordPress, реализующий простую систему управления задачами. Этот плагин добавляет к традиционному WP блогу две новых сущности: project и issue. И проекты и задачи порождены из обычных сообщений, но имеют соответствующий тип и потому не попадают в общую ленту. Создание и редактирование проектов и задач производится через административную консоль:

Посмотреть задачи и проекты можно в стандартном представлении блога:

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

Плагин BuggyPress интересен не только тем, что позволяет управлять проектами и задачами, но в первую очередь тем как он сделан. Напомню, что структура базы данных WP очень проста, всего 11 таблиц (для просмотра базы WP можно установить соответствующий плагин, например хорошо известный Adminer). В отличии от ряда других плагинов BuggyPress ничего нового в структуру базы не привносит. Т.е. и сообщения и задачи сохраняются в таблице wp-posts. Статусы, приоритеты и прочие атрибуты задач определяются в таблице wp_terms. История изменений задач ведется в таблице wp_postmeta. Т.е. вся логика реализована посредством расширения существующих в wordpress механизмов. Хороший пример архитектуры решения.

PS: Большинство текущих тем отображают только сообщения типа post. Что нужно сделать для отображения сообщений других типов написано здесь: Showing custom post types on your home/blog page Подробное описание таксономий: Введение в пользовательскую таксономию WordPress 3.0

Ожидания, разочарования и прогнозы 2010/2011

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

Безусловным хитом года 2010 стала тема адаптивного кейс менеджмента. Adaptive Case Management это разумная середина между излишней наукообразностью BPM подхода и отсутствием таковой у подхода ECM. Продолжить чтение «Ожидания, разочарования и прогнозы 2010/2011»

Еще несколько слов про CHG

Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.

Продолжить чтение «Еще несколько слов про CHG»