перевод с английского магистра Айко О.В. книги Джеймса Тейлора - Управление проектов в области информационных технологий. Глава 2: управление проектами
James Taylor - Managing Information Technology Projects—
Applying Project Management Strategies to Software, Hardware, and Integration Initiatives.
Chapter 2: The Foundations of Project Management
|
Предисловие Управление проектами, в той или иной форме, существует уже тысячи лет. Характерными примерами являются строительство большой пирамиды, вождение Моисеем евреев по пустыне, храм и дворец, построенный Соломоном, и раскошные здания греков и римлян. Как эти проекты были выполнены нас всех поражает воображение, особенно с учетом средств в день. Например, каким образом Великая Пирамида в Хеопса, состоящий из примерно 2300000 каменных блоков весом две до семидесяти тонн, построенный с такой точностью? Это пирамида, размером с сорока этажное здание, стоит на тринадцати акров земли, что даже сегодня отклоняется менее чем на дюйм от уровня. С приходом электричества и индустриализации, возросла сложность проектов. Раньше проекты были упражнениями на выносливость для народов, строились десятилетиями. Теперь проекты сложнее из-за их масштаба и уровня технологичности. Проекты становились гораздо сложнее и технологичнее. Катализатором этих улучшений является II мировая война и затем как результат «холодная война». Вторая мировая война привела к совершенствованию управления проектами, которые никогда не были до этого использованы. Производство и производственные линии были оптимизированы для получения военных материалов, которые производились быстрее и лучше. Подобное производство требует новых и более совершенных методов управления проектами, что привело к волне нового мышления в области управления проектами. В Соединенных Штатах министерство обороны (DOD) приступило к разработке новых и более совершенных инструментов и методов управления проектами. Проекты такие, как субмарина «Поларис» вовлекли в разработку множество подрядчиков и разработчиков, что было практически невозможно планировать или отслеживать, контролировать весь процесс, используя стандартные методы управления. Таким образом, были разработаны методы для последовательного разработки проекта, а так же методы отслеживания, контроля и прогнозирования проекта. Следовательно, DOD разработал почти все традиционные средства управления проектами, которые используются профессиональными руководителями проектов и сегодня. Затем начали появляться проекты в области IT, которые создали больше проблем управления проектами, которые немного отличаются от проектов связанных с производством. Эти проекты поставлены в более жесткие условия, так как этот рынок быстро изменяется и что бы успевать за рынком, проекты поставлены в более жесткие графики выполнения. IT индустрия получило более широкое распространение. Взрыв на IT индустрию в мире позволил решить многие деловые проблемы и открыл новые направления бизнеса, но и создали ряд серьезных проблем в управлении. Преимущества и проблемы Одним из основных преимуществ IT является то, что компании в настоящее время имеют возможность общаться очень мобильно, через корпоративные сети, национальных и международных сетей, что является основой практически для любого бизнеса сегодня. В этой новой возможности, каждая компания имеет возможность сделать процессы управления более эффективными и результативными. К сожалению, многие предприятия не имеют опыта или не хотят вводить IT технологии у себя на предприятиях. Идя в ногу с IT изменениями на рынке, предприятие постоянно улучшает свои методы управления проектами. На сегодняшний день методы управления IT проектами не являются удовлетворительным, и основной причиной этого является отсутствие планирования проекта, вызванный необходимостью спешить за рынком. Другая причина заключается в отсутствии организационной составляющей разработки проекта, которая требует, среди прочего, официального документирования каждого шага проекта, специально отобранных и подготовленных кадров, управления проектами которые понимают и используют стандартные инструменты управления проектами. Процесс управления проектами обсуждаются в следующей главе. Основные методы управления проектами Для обеспечения единого понимания методов управления проекта, в этой главе будут определены основные условия для разработки проекта и рассмотрим четыре наиболее важных инструментов управления проектами: декомпозиция работы (WBS), диаграмма Гантт, сетевой анализ и фактическое значение. Эти важные инструменты управления проектами, независимо от типа проекта. Проект и управления проектами. Проект, как правило, одноразовая деятельность с четко определенными желаемыми конечными результатоми. Именно это одноразовая особенность, и отличает проектную деятельность с функциональной деятельностью. Например, отдел кадров на предприятии имеет одинаковые и повторяющие функции, работники которого постоянно выполняют эти функции. Проект можно назвать уникальным с временными усилиями по выработке конкретных результатов для заказчика, указанных им критериев эффективности. Уникальность проекта. Каждый проект является уникальным. Никакие два проекта не одинаковы, несмотря на то, что для однотипных проектов существуют шаблоны. Каждый их проектов имеет свои отличительные особенности. Даже если два проекта одинаковы по техническим характеристикам, то исполнение его и сам результат всегда отличаются, несмотря на казалось бы одинаковые проекты. Кроме того, разработчики и клиенты, как правило, различны для каждого проекта. Продолжительность проекта В рамках проекта, его продолжительность, зависит от отрасли и среднему времени реализации проекта в этой отрасли. Например, в строительной промышленности, дом может быть построен в течение шести месяцев, а больница может занять два года. В аэрокосмической промышленности, разработка нового самолета может продолжаться десять и более лет. Поэтому время не значит, краткосрочные или долгосрочные планы, как обычно мы используем его, а это означает, что есть определенные начало и конец указывающие на определенные результаты за определенное время. Заказчик Клиент определяет уровень производительности, необходимой для реализации проекта результатов. Заказчик или клиент определяет эти критерии эффективности с точки зрения своих потребностей. Ответственность за решение проблем клиента несет руководитель проекта, он должен толковать требования для разработчиков и получить согласие клиента, требования должны максимально соответствовать потребностям клиента. Он также несет ответственность руководителя проекта, который определяет или разрабатывает стандарты в отношении которых определяется эти требования. В некоторых случаях, отраслевые стандарты могут быть использована для определения критериев эффективности. Иногда стандарты являются частью критериев эффективности. Например, требование означающее время неисправности (MTBF), количество часов также может служить в качестве стандарта. Это происходит потому, что MTBF является количественной мерой и могут использоваться со средним приемлемым значениям для аналогичных систем. Когда стандарты отсутствуют, руководитель проекта отвечает за способ определения, является ли продукт приемлемым для заказчика. Одним из путей могло бы стать использование независимой группы определения качества. Другим способом может быть, использовать стандартный или разработанный другой кампанией продукт в качестве базового. Ключ к успеху в выявлении, толкования, оценки и требований заказчика является получение клиентом соглашения о вашей интерпретации этих требований. Управление проектом Управление проектом является специализированным подходом к управлению бизнеса. Традиционная точка зрения управления заключается в том, что мы планируем, ведем учет, анализируем и контролировать бизнес процессы. Управление проектом включает в себя эти функции, а также включает проект инициирования и прекращения. Оба традиционных и процессов управления проектами показаны графически в экспозиции 2-1 и 2-2, соответственно. Мы можем определить управление проектами, как искусство и науку управления проектами. За конкретное время, разработчик должен при имеющихся ресурсах, решить поставленную задачу. Управление проектами – это и искусство и наука одновременно. Она является искусством, поскольку он предполагает организацию процесса в одну цепочку действий. Процесс организации многих рабочих групп, на достижение единого результата и является самой сложной частью проекта. Большинство возникающих проблем, связанные с человеческим фактором: урегулирование конфликтов, создание команды, ведение собраний. Технические проблемы намного легче, чем решить человеческие проблемы. Эти технические средства делают управление проектом частью науки. Есть много инструментов управления проектами. Некоторые довольно простые. С другими связаны довольно сложные расчеты. Многие из этих инструментов, представлены в этой книге, но есть четыре наиболее важных из них – WBS, диаграмма Гантт, анализ сети и полученные значения. Разбиение структуры. WBS является наиболее важным инструментом управления проектами. С хорошим WBS, руководитель проекта может развивать все другие средства, необходимые для успешного управления проектом. Когда WBS сделали правильно, она является основой для планирования, учет, анализа и контроля проекта. Что такое WBS? A WBS представляет собой структурированный способ разложения проекта на различные компоненты – программное обеспечение, аппаратное обеспечение, сети, услуги, документы, труда, тестирования, внедрения, установки, и эксплуатации. Иными словами, WBS является способом уменьшения проекта в последовательно более низкие и подробные уровни. Есть два способа представления WBS. Первая и наиболее распространенная форма называется формат с отступлениями. Так назвали потому что делается отступ при переходе к более низкому уровню. В графическая форма напоминает об организационной структуре и особенно полезен для тех, кто предпочитает визуальные представления. Однако, он требует много времени для разработки, особенно для крупных, сложных проектов. Не все программное обеспечение по управлению проектами поддерживает графический формат, но все они поддержать формат с отступом. В WBS уровнях. WBS уровнях, каждый уровень ссылается на более низких уровень детализации, обычно верхний уровень это имя или название проекта. Как правило, WBS составляется до третьего или четвертого уровня, но редко бывает ниже пятого уровня. Есть два ключевых момента в WBS составлении. Во-первых, в каждом уровне нельзя рассматривать весь проект в целом, а только лишь часть его рассматриваемая на данном уровне. Речь идет о сложности проекта. В WBS на третьем уровне можно легко описать простой проект из нескольких задач. В таких проектах, как строительство дома, больницы, или самолета, требует подробного WBS, до пятого уровня. Каждый из WBS уровней можно охарактеризовать следующим образом: Уровень один. Название проекта или имя заказчика. Уровень два. Записи с участием основных подсистем проекта, или разделов проекта на этом уровне. Например, в проекте разработке автомобиля будет включать двигатель, шасси, интерьер, и кузов. Уровень три. Каждый уровень также может состоять из одного или нескольких основных задач деятельности. Например, если второй уровень подсистемы является двигателем, то задачами третьего уровня может быть вентилятор или карбюратор, которые являются частью двигателя. Уровень четыре. Каждый элемент третьего уровня можно разложившийся в несколько дискретных образований, и так далее, вплоть до желаемого уровня детализации проекта. Например, карбюратор еще можно разложить на части и детали из которых он состоит. Все эти подуровни входят как четвертый уровень в WBS. Уровень Пять. Как правило пункты включающие в этот уровень зависят от предыдущих уровней, но работы по нему могут выполняться отдельно. Примером пятого уровня работы могут быть детали двигателя которые могут разрабатывать отдельные люди или группы. Теперь график и бюджет на проект могут быть определены. Образец WBS представлен в примере 2-5. Следует отметить несколько ключевых моментов об этом примере. Во-первых, название проекта на первом уровне. Во-вторых, не все основные подсистемы или подпроекты раскладываются на более низких уровнях. Нужно раскладывать элементы в WBS до того уровня, до которого можно назначить ответственных лиц, создать бюджета для этого уровня и графика выполнения этой задачи. Каждый руководитель проекта будет иметь более низкие уровни разложения WBS. Примечание к примеру 2-5, были включены в проект управленческие функции на отдельном уровне. Хотя эти функции не являются задачами проекта в разложении WBS элементов, показ этих функций является хорошей основой для финансового обеспечения данного проекта. В противном случае, расходы на управление проектом будут определяться более сложными усилиями и будут сложно прогнозируемыми. Поэтому вместо распределения руководителем проекта время для каждой задачи, гораздо легче включить отдельным WBS уровень в который включают общую стоимость проекта и срок выполнения подзадач. Основная цель разработки WBS состоит в том, чтобы каждая подзадача были определены. Определять или фиксировать взаимозависимости задач на разных уровнях не является целью. По сути, это лучше не думать с точки зрения задачи зависимостей пока все задачи определены. Сосредоточитесь на идентификации всех задач сразу, потому что если это не находится в WBS, это не находится в проекте. Сеть - это инструмент, используемый, чтобы показать взаимоотношения задач. |