Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Создание стандартов и методологии выполнения проектов



Проекты по определению — временные явления. Проект при­ходит и уходит. Но у него есть начало и конец. Однако только недавно проектные компании начали понимать, что, хотя про­екты приходят и уходят, управление проектами — это некая не­прерывная и постоянная особенность организации. Поскольку организация постоянно выполняет проекты, то функция УП должна быть встроена в саму структуру компании.

Почему?

Как правило, круг непосредственного взаимодействия высшего руководства — это 5—10 человек, и именно ими «опосредуются» его управление, решения, видение. Именно от них во многом за­висит, будут ли совпадать желаемый и реальный результаты управ­ления.

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

тоже получается свой — не тот, который нужен вам и вашей ком­пании.

Именно для предотвращения этих опасностей и возникают до­кументы, определяющие, регламентирующие, распределяющие пра­ва и ответственность, — стандарты и регламенты компании по УП.

Только, согласитесь, что без договоренности, внутреннего при­нятия этих правил это остается просто бумагой. Потому что нет той самой трансляции, внутренней энергии и убежденности в том, что именно это дело является правильным и правильно его надо делать именно так. Вот здесь как раз вам pi помогут требования стандарта ISO 9000 по обеспечению вовлеченности персонала и лидерству руководства [4].

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

Во многих организациях функция УП изначально выросла из ин­женерных подразделений. Но если она будет базироваться в ин­женерном подразделении, то это неправильно, потому что функ­ция УП охватывает не только инженерное подразделение, но и все другие функции в компании. Постепенно и пришли к тому, что стали использовать термин ЦУП (центр управления проек­тами) для обозначения подразделения, в функции которого и вхо­дит именно обеспечение качества проектов компании [6, 9].

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

• программисты и коммерсанты говорят и мыслят совершен­но разными категориями, поэтому им трудно найти общий язык (см. выше, к вопросу об анализе необходимости тре­бований);

• имея опыт работы со старыми бизнес-приложениями, со­трудники фирмы-заказчика напридумывали такое количе­ство новых требований, что система под их тяжестью едва могла шевелиться, при этом многие из этих требований так и остались реально невостребованными {см. выше к вопро­су об анализе степени сложности требований).

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

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





Дата публикования: 2015-01-04; Прочитано: 306 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2025 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.027 с)...