показать все 

А собственно, кто утверждает, что ИТ-проект неудачен? Возможно, мы потратили больше времени и денег, но и результат оказался намного значительнее запланированного. Измерять проекты вообще непросто, а ИТ-проекты особенно. Давайте подумаем, что тут можно сделать 

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

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

Именно поэтому я посвятила отдельную, седьмую, статью пиару и маркетингу проектов ИТ. Ведь на человека можно воздействовать, и именно эта область учит, как это надо делать. Для поборников нравственности и морали, выступающих против осознанного влияния (или манипулирования) на людей, скажу, что уж в данном случае эти действия точно работают на пользу как компании, так и самим сотрудникам. Потому что именно от того, насколько доброжелательно они встретят проект, зависит не только его оценка – это как раз побочный эффект, а и сам результат проекта – насколько эффективно они будут использовать то, что в результате получится.

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

Перейдем от эмоций к делу. Качество проектов ИТ зависит от двух составляющих:

• Качества того, что получилось, – результата проекта
• Качества ведения проекта: сроков, бюджета, эффективности использования ресурсов.

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

Рисунок 1. Наглядное изображение взаимосвязи основных параметров проекта

Качество результата проекта

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

Но тут возникает ряд вопросов.

Вопрос 1. Удовлетворенность проектом со стороны кого из представителей компании мерить?

Как минимум возникают три группы, мнение которых надо учитывать:

• Пользователи, которые применяют результаты проекта в своей деятельности.
• Персонал, обслуживающий и сопровождающий результаты проекта.
• Собственно бизнес – заказчик, которым обычно являются инвесторы или топ-менеджмент компании, которым зачем-то проект был нужен и именно они его согласовывали, утверждали и финансировали.

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

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

Вопрос 2. Кроме удовлетворенности, есть целый ряд показателей качества компонентов ИТ, создаваемых в результате проекта.

Приведем этот длинный список, например, для программного обеспечения (ПО), чтобы обозначить сложность этой области проектного управления ИТ.

Характеристики качества ПО по ИСО/МЭК 9126, 1994:

• Функциональные возможности (functionality) – это набор атрибутов, относящихся к функциям, выполняемым ПО, и их конкретным свойствам. Функции реализуют установленные или предполагаемые потребности заказчиков и предоставляются пользователям:
  • Пригодность – насколько ПО пригодно для использования в деятельности организации.
  • Правильность – точность удовлетворения требований к функционалу ПО.
  • Способность к взаимодействию – интеграционные возможности ПО.
  • Согласованность – качество взаимодействия ПО с другим ПО, используемым в организации; возможность совместного использования и отсутствия негативного влияния друг на друга.
  • Защищенность – насколько ПО защищено от взлома и несанкционированного доступа.
• Надежность – это набор атрибутов, относящихся к способности ПО сохранять требуемый уровень качества функционирования при установленных условиях за установленный период времени:
  • Стабильность – сохранение функциональности ПО при изменении внешней среды.
  • Устойчивость к ошибкам – возможность ПО функционировать (пусть и в ограниченном режиме) при выявлении ошибок.
  • Восстанавливаемость – способность ПО к восстановлению в случае сбоя, не нарушающего деятельность организации.
• Практичность (usability) – это набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей:
  • Понятность – уровень простоты использования ПО.
  • Обучаемость – насколько просто научить пользователя работе с ПО.
  • Практика использования – удобство использования системы в работе пользователей.
• Эффективность (efficiencies) – это набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях:
  • Характер изменения во времени – поведение ПО во времени, в частности, частота обновлений.
  • Характер изменения ресурсов – стабильность используемых ресурсов, в частности, затраты на поддержку и скорость обновления используемого оборудования.
• Сопровождаемость (maintainability) – это набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций):
  • Анализируемость – простота анализа функционирования ПО, в частности, причин появления ошибок и критических ситуаций.
  • Изменяемость, гибкость – простота изменения ПО в соответствии с потребностями организации.
  • Устойчивость – устойчивость ПО к изменениям архитектуры предприятия, в частности, оборудования и системного ПО.
  • Тестируемость – простота тестирования ПО при внесении в него изменений.
• Мобильность (portability) – это набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое:
  • Адаптируемость – способность ПО к переносу на новую инфраструктуру.
  • Простота внедрения – уровень усилий, которые приходится затрачивать на внедрение ПО.
  • Соответствие – набор инфраструктурных и системных компонентов, на которых может функционировать ПО.
  • Взаимозаменяемость – способность к замене компонент ПО.

Очевидно, что если для пользователей основные показатели качества ПО заключены в п. 3, относящемуся к юзабилити, то для группы сопровождения наиболее важны п. 5 и 6.

Именно поэтому, когда говорят, что в организации недовольны результатом проекта, мне всегда хочется спросить: «Кто недоволен?», «Почему недоволен?», «Что получилось хуже, а что лучше запланированного?».

Вопрос 3. Здесь возникает еще один аспект измерения качества результата проекта – когда это качество мерить.

Если говорить об удовлетворенности, например, пользователей, то она обыкновенно весьма невелика сразу после внедрения, потом медленно, но неуклонно растет и иногда начинает падать к завершению эксплуатации. Хотя последнее происходит не всегда, так как замена системы происходит далеко не только из-за того, что она перестала удовлетворять пользователей.

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

Чем больше проект, чем большую область деятельности компании он затрагивает, тем через больший срок после его завершения можно обоснованно оценить его качество

О топ-менеджменте я и не говорю: их настроение подвержено слишком многим влияниям. Да и сам топ-менеджер может поменяться, а тогда и отношение его к ПС будет совсем другим. Большое видится на расстоянии. И чем больше проект, чем большую область деятельности компании он затрагивает, тем через больший срок после его завершения можно обоснованно оценить его качество.

Вопрос 4. ИТ-проекты весьма часто достигают совсем не тех результатов, на которые рассчитывали.

Еще одно важное свойство ИТ-проектов – это то, что об-ласть использования их результатов очень часто совсем не совпадает с той, на которую рассчитывали при их открытии. С точки зрения классической удовлетворенности, проиллюстрированной на рис. 2, это означает, что они обречены на неудачу. Но, возвращаясь к тому, с чего я начала свою статью, иногда мы получаем от них эффект, который относится к тому, что мы запланировали, примерно так же, как «Титаник» к средней голливудской кинопродукции. 

Рисунок 2. Удовлетворенность заказчика результатами проекта

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

Качество ведения проекта

На первый взгляд кажется, что тут все намного проще. В бюджет и в сроки уложился – молодец. Но тогда получается, что единственное, что мы измеряем, – это точность планирования. Имеет ли это прямое отношение к качеству проекта? На этот вопрос я бы ответила «да». И только ли это определяет его качество? А вот тут ответ будет «нет». Потому что планирование – конечно, важная составляющая управления проектами, но далеко не единственная. Как же тогда определить, насколько хорошо мы управляли проектом. Тут можно предложить несколько вариантов.

Бенчмаркинг

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

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

Пост-анализ или возможность оглянуться

Уже выполнив проект, можно проанализировать его и понять, где можно было уменьшить затраты и сократить сроки. Если, например, бюджет был раздут в несколько раз, то могут быть два варианта:

• Мы все потратили – тогда мы не умеем не только планировать, а еще и тратить деньги.
• Мы потратили существенно меньше, чем планировали. Тогда все не так страшно, но с планированием дело обстоит не слишком хорошо. И стоит учесть эту ошибку в будущих проектах, попытавшись улучшить точность планирования бюджета.

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

Можно относиться к проектам ИТ как к досадной обязанности и ругать их на чем свет стоит. Но лучше смотреть на них как на проверку собственной прочности и профессионализма

Однако очевидно, что если правильно подходить к пост-анализу проекта, то точность планирования можно существенно улучшить.

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

Качество проекта как единой системы

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

Не могу не привести любимое высказывание моего отца, которое принадлежит Сергею Павловичу Королеву:

«Если ты сделаешь очень быстро (как тебе приказывают), но плохо, все очень скоро забудут, что ты сделал быстро, но очень долго будут ощущать и помнить, что сделал плохо. И, наоборот, все очень скоро забудут, что ты делал долго, и никогда не забудут, что сделал хорошо».

Если время не столь критично для проекта, то его результат всегда важнее.

К сожалению, во многих компаниях принято выполнять проекты в срок любой ценой, даже в ущерб качеству результата. Объяснить я могу это довольно просто: неопытные или просто слабые руководители, чтобы поддержать свой начальственный статус, начинают гонять РП за сроки выполнения проектов, не желая или не умея разобраться в сути проекта.

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

Однако в некоторых случаях, например, когда к внедрению системы приурочено бизнес-событие – открытие филиала или начало обслуживания розничных клиентов банка, ввод в действие нового цеха или интернет-магазина, – время становится критической характеристикой.

Так что, когда о проекте говорят, что он плохой и даже бесполезный, не спешите с выводами. Возможно, кто-то просто погорячился и не до конца осознал, что же получилось. ИТ-проекты должны иметь презумпцию невиновности!

Вот и подошел к концу наш цикл статей. И грустно, и весело. Грустно потому, что конец – это всегда грустно. Весело потому, что, надеюсь, мне что-то удалось рассказать, а вам о чем-то подумать, что, возможно, раньше ускользало от вашего внимания.

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

Надеюсь, что я хоть чуть-чуть вам в этом помогла. Удачи на трудном пути управления проектами ИТ!