Содержание 5

Содержание

Благодарностиавтора

ПредисловиеСьюзанСнедакер

Глава1.КакуправлениепроектамиприменимокIT?

Введение

Системы улучшения бизнес-процессов

Институт управления проектами

CMM и CMMI

Шесть сигма

ISO 9000

Обзор управления проектами

Статистика успешных и провальных проектов

Факторы успеха проекта

Фактор успеха 1: поддержка руководства

Фактор успеха 2: вовлечение пользователей

Фактор успеха 3: опытный руководитель проекта

Фактор успеха 4: четко определенные цели проекта

Фактор успеха 5: четко определенный (и уменьшенный) объем

Фактор успеха 6: более краткосрочное планирование, большое число контрольных точек

Фактор успеха 7: четко определенный процесс управления проектом............. Фактор успеха 8: стандартная инфраструктура

Четыре ограничения проекта

Проекты, программы и портфолио

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава2.КаккорпоративнаястратегиясоотноситсясIT?

Введение

Обзор корпоративной стратегии в современном окружении

Поддержка корпоративной стратегии со стороны IT – еще один шаг вперед

6 Содержание Стратегия и тактика

Конкурентное преимущество

Понимание стратегий вашей компании

Корпоративные стратегии и IT

Стратегии бизнеса и IT

Методы, помогающие в разработке IT-стратегий

Разработка IT-стратегии

Переход от стратегии к действиям

Оценка вашего IT-окружения

Оценка ваших IT-проектов

Категории IT-проектов

Разработка операционного плана для IT

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава3.Руководствопокорпоративнымполитикам

Введение

Основы корпоративных политик

Выявление источников власти

Власть положения

Власть информации

Власть ресурсов

Власть компетентности

Власть продуктивности

Власть личности

Методы влияния

Угрозы

Обмен

Призывы к ценности, эмоциям или разуму

Парадокс власти

Эффективная работа в политическом окружении

Согласитесь с тем, что политики существуют

Развивайте позитивные взаимоотношения

Создайте свою систему обмена

Слушайте внимательно

Общайтесь больше

Помните о том, чего нельзя говорить

Содержание Делитесь властью

Знайте свою систему ценностей

Планируйте, как политика будет влиять на вашу работу

Отслеживайте политические перемены

Преодоление политических препятствий

Спонсорство высокого уровня

Разработка бизнес-плана

Расчет и демонстрация ROI (уменьшение TCO)

Эффективные контрмеры

Политики услуг

Сотрудничество с партнерами по бизнесу

Проектная группа

Участие клиентов/пользователей

План коммуникаций

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава4.УправлениегруппойIT-проекта

Введение

Современная ситуация с управлением

Чего на самом деле хотят люди?

Причины неудовлетворенности работой

Основы удовлетворенности работой

Стили работы и проектная группа

Управление различными стилями работы

Вопросы культуры

Управление людьми, принадлежащими к разным культурам

Управление разными возрастными группами

Мужчина, женщина и технология

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

Убедитесь, что состав группы соответствует задаче

Четко определяйте цель проекта и группы

Четко определяйте роль каждого сотрудника, поддерживайте уникальные умения и таланты

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

Работайте в команде, определяйте ее культуру и особенности

8 Содержание Разрабатывайте стратегии решения проблем сообща

Создайте в группе атмосферу вежливости и уважения

Признавайте индивидуальные и коллективные достижения

Эффективно управляйте временем вашей команды

Определите правила коммуникаций

Внедряйте технологии для улучшения сотрудничества и взаимодействия в реальном времени

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава5.ОпределениеIT-проекта

Введение

Обзор процесса управления проектом

Истоки проекта

Проверка предложения проекта

Создайте подготовительную проектную группу

Проанализируйте существующее предложение проекта

Проверьте проектную информацию

Определение проекта

Определение проблемы

Определение формулировки миссии проекта

Определение возможных решений

Выбор оптимального решения

Разработка предложения проекта

Создание оценки

Определение спонсора проекта

Утверждение проверенного предложения проекта

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава6.ОрганизацияIT-проекта

Введение

Определение целей проекта

Формулировка цели проекта

Цели проекта, или его главные результаты

Определите, что включается и что не включается в проект

Определение заинтересованных лиц

Определение заинтересованных лиц вашего IT-проекта

Определение категорий заинтересованных лиц

Управление ожиданиями заинтересованных лиц

Определение требований проекта

Управление требованиями

Усовершенствование параметров проекта

Критерии успеха

Критерии приемлемости

Масштаб, цена, время и качество

Сетка гибкости

Ограничения

Риски

Вехи (контрольные точки)

Техническое задание или устав проекта

Определение инфраструктуры проекта

Определение процессов проекта

Критерии приемлемости

План управления риском

План управления изменениями

План коммуникаций

План управления качеством

Отчеты о состоянии проекта

Отслеживание дефектов/ошибок/проблем

Процедуры эскалации

Процедуры документирования

Процедуры утверждения

План развертывания

План эксплуатации

План обучения

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава7.Качествоснуля

Введение

Понятие качества

Качество или класс

10 Содержание Компоненты управления качеством

Удовлетворение ожиданий пользователей

Предотвращение вместо исправления

Постоянное улучшение

Вовлечение руководства

Стоимость качества

Планирование качества

Требования пользователей

Функциональные требования

Технические требования

Критерии приемлемости

Параметры качества

Контрольный список качества

Контроль качества

План управления качеством

Параметры качества

Процессы и процедуры проекта

Отчет о состоянии

Отслеживание проблем

Управление изменениями

Тестирование качества

Предотвращение и проверка

Определенные процедуры тестирования качества

Выборки

Анализ

Разрешение проблем

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава8.СозданиегруппыIT-проекта

Введение

Определение требований к проектной группе

Роли и ответственность

Компетенции

Наличие персонала

Определение интерфейсов проекта

Определение кадровых потребностей и ограничений

Определение ролей и ответственности

Привлечение нужных сотрудников

Формирование команды

Список группы

Обучение

Процессы и процедуры

Согласие

Начальная встреча группы

Технологии, используемые в группе

Управление работой

Признание и вознаграждения

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава9.ПланированиеIT-проекта

Введение

Разработка декомпозиции работ

Качество и декомпозиция работ

Разделение проекта на составные части

Основные результаты выполнения главных задач

От главных задач к более мелким

Проверка масштаба

Владельцы задач

Критерии завершения

Критерии входа/выхода

Программы управления проектом

Детали задачи

Функциональные и технические требования

Разработка сетевого графика

Ключевые моменты

Создание графика

Критический путь

Резерв времени

Разработка расписания проекта

Компетенции и расписание

Расписание: завышенные оценки или резервы

12 Содержание Разработка бюджета проекта

Оценка потока денежных средств

Осуществление контроля затрат

Определение рисков проекта

Определение рисков IT-проекта

Оцените риски IT-проекта количественно

Снижайте риски IT-проекта

Планирование коммуникаций в проекте

Развитие коммуникаций в рамках проекта

Контрольные точки для оценки коммуникации

Завершение плана проекта

Заключение

Краткое изложение решений

Разработка декомпозиции работ

Разработка сетевого графика

Разработка расписания проекта

Разработка бюджета проекта

Определение рисков проекта

Планирование коммуникации в проекте

Завершение плана проекта

Часто задаваемые вопросы

Глава10.УправлениеIT-проектом

Введение

Начало работы над проектом

Объявление о начале работы

Выполнение плана проекта

Контроль развития проекта

Отчеты о развитии проекта

Риски и резервные планы

Определение прогресса проекта

Управление отклонениями

Управление связанными планами

Управление изменениями в проекте

Отклонения от плана

Изменения в расписании

Изменения в бюджете

Изменения масштаба проекта

Управление запросами на изменения

Корректирующие действия

Управление рисками проекта

Управление проектной группой

Эффективное управление IT-проектом

Решение рабочих проблем вашей проектной группы

Решение проблем с проведением встреч проектной команды

Как решать проблемы взаимоотношений

Завершение проектной работы

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава11.ОтслеживаниеразвитияIT-проектов

Введение

Технические инструменты отслеживания

Анализ освоенного объема

Индекс выполнения сроков

Индекс выполнения стоимости

Оценка на момент завершения

Критический коэффициент

Проверка результатов проекта

Модульное тестирование

Интеграционное тестирование

Юзабилити-тестирование

Приемочное тестирование

Бета-тестирование

Регрессионное тестирование

Тестирование производительности

Эталонное тестирование

Тестирование безопасности

Подготовка к внедрению, развертыванию и передаче в эксплуатацию

Внедрение

Развертывание

Передача в эксплуатацию

14 Содержание Разрешение общих проблем проекта

Проблемы с масштабом

Проблемы с качеством

Проблемы с расписанием

Проблемы с бюджетом

Проблемы с персоналом

Проблемы со спонсором проекта

Проблемы с поставщиками проекта

Проблемы с клиентами, пользователями, заинтересованными лицами........ Заключение

Краткое изложение решений

Часто задаваемые вопросы

Глава12.ЗавершениеIT-проекта

Введение

Работа по завершению проекта

Записи о проблемах

Запросы на изменения / запросы на работу

Отчеты об ошибках

Подготовка заключительной документации

Техническая документация

Окончательный обновленный план проекта

Отчет о завершении проекта

Окончательное подписание проекта

Формальное подписание проекта

Передача в эксплуатацию

Ликвидация активов проекта

Анализ полученных уроков

Административное завершение

Безопасность

Работа с документами

Вопросы регулирования

Анализ работы персонала

Заключительная встреча группы

Заключение

Краткое изложение решений

Часто задаваемые вопросы

Благодарностиавтора Создание книги – дело стоящее, но силами одного человека тут не обойтись. Прежде всего хочу поблагодарить моих ближайших друзей и членов семьи – Лизу (Lisa), Эми (Amy), Ди Энн (Dee Ann), Рози (Rosie), Джеки Браун (Jackie Brown) и Бейли (Bailee). Спасибо за то, что они с пониманием отнеслись к написанию моей книги. Спасибо моей маме Энни (Anne) за уроки по английской грамматике (они начались с моего рождения и продолжаются по сей день) и за поддержку моих писательских опытов. Спасибо моему папе Ричарду (Richard) за то, что он привил мне любовь к технике. Особая благодарность – моей дорогой подруге Ширли (Shirley) за постоянное подбадривание.

Я хотела бы поблагодарить моего друга по МВА Пэтти Хёниг (Patty Hoenig) за то, что она познакомила меня с талантливым редактором этой книги, Нэлсом. Глубоко признательна Нэлсу за его титанический труд по редактированию. Я искренне наслаждалась нашим виртуальным общением, книга очень выиграла от наших совместных усилий. Нэлс помог мне углубить и расширить ее содержание. Это было невероятное удовольствие совместного творчества – каждый раз я вспоминаю о нем с замиранием сердца.

Мне хочется поблагодарить и тех моих друзей и коллег, которые помогли собрать реальные примеры из жизни для этой книги: Эми Баттери (Amy Buttery), Криса Комптона (Chris Compton), Гэри Фроста (Gary Frost), Дэвида Гэтмена (David Getman), Лоррейн Гуче (Lorraine Gutsche), Нэлса Хёнига (Nels Hoenig), Криса Ланди (Chris Landi), Лизу Майнц (Lisa Mainz), Кима Нейгла (Kim Nagle), Сонала Рану (Sonal Rana) и Ральфа Шпитцена (Ralph Spitzen).

Отдельная признательность Нику Маммане (Nick Mammana) за призывы к совершенству на заре моей жизни и «сенсею» Кену Карсону (Ken Carson) за то, что он научил меня понимать кайдзен  – философию постоянного развития. Оба этих человека помогли мне развить те профессиональные и личные качества, которыми я обладаю сегодня.

В заключение мне хотелось бы поблагодарить всех выдающихся людей из издательства Syngress, которые помогли этой книге родиться на свет.

Спасибо Эндрю (Andrew) за то, что эта книга появилась на свет, а Джейми (Jaime) – за то, что сделала этот процесс максимально приятным, и за ее настойчивые усилия на всех фронтах. Теперь я полагаю, что имею право какое-то время передохнуть; искренне желаю всем вам того же.

16 Предисловие ПредисловиеСьюзан В отличие от других книг об управлении IT-проектами, эта книга объединяет базовые сведения об управлении IT-проектами, информацию о процессах и процедурах, а также основах бизнеса. Многие профессионалы в сфере IT – очень яркие люди, которые беззаветно преданы технологиям.

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

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

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

То же самое справедливо и для основ управления IT-проектом. Большинство людей не будут внедрять систему с начала до конца, не испытывая сильного давления и поддержки со стороны руководства. Вот почему системы управления проектом (а также любые другие улучшения) становятся не чем иным, как однодневной инициативой, а этот синдром очень быстро приводит к скептическому восприятию любого процесса улучшения. Поэтому я решила пойти другим путем. Никогда не старайтесь внедрять систему с начала до конца, если у вас не получается это сделать! Беритесь за одну задачу и доводите ее до конца, затем добавляйте следующую – тогда начнется постепенное улучшение. Именно так меня учили на самых разных семинарах: надо браться за одно дело и доводить его до конца, только потом приниматься за следующее – в каждый момент времени можно заниматься чем-то одним. Естественно, было бы замечательно сделать все за один день, но так никогда не бывает, поэтому моя задача состоит в том, чтобы научить вас постепенно улучшать ваши навыки в управлении IT-проектами, даже если это займет 6, 12 или 18 месяцев. Лучше поздно, чем никогда!

Эта книга не представляет исчерпывающий взгляд на управление ITпроектами. Она предназначена для того, чтобы помочь вам управлять ITпроектом с минимальными усилиями и максимальным результатом. Если вы ищете энциклопедию по формальному управлению IT-проектами, вам нужны другие источники (отсылаю вас к PMBOK). Данная книга описывает процесс управления IT-проектом, который не является тяжелым делом.

Все, кто меня знает, не сомневаются в том, что я человек, ориентированный на результат: я ненавижу процесс ради самого процесса! Единственный процесс, который доставляет мне удовольствие, – тот, что приводит к желаемому результату. Поэтому в данной книге представлен минималистский подход к процессу (когда «меньше» значит «больше»). При таком подходе процессы представляют собой самый короткий и простой путь из точки А в точку В.

Я много лет училась карате шотокан, и мой учитель Кен Карсон всегда говорил: «Для обретения силы нужен хорошо заложенный фундамент, а скорость дается практикой». Когда учитель шестого дана, имеющий черный пояс (по карате и дзюдо), который занимается обучением и тренировками более 60 лет, говорит, что это так, – это на самом деле так. Компании и профессионалы в сфере IT, которые внедряют согласованные практики управления проектами, должны построить надежный фундамент. По мере того как компании все лучше знакомятся с процессами и делают их общим достоянием, они приобретают знания и быстродействие. Побеждают те компании, которые сильнее, быстрее и умнее. Но это достигается не в одно 18 Предисловие касание!.. Это результат постепенного улучшения. По мере внедрения практик управления проектом вы, ваш IT-проект, ваш отдел и ваша компания будут непрерывно улучшаться. Данная книга откроет вам кратчайший путь к  этим умениям, так что вы сможете быстро изучить основы и начать использовать их уже сегодня.

Хорошее начало – половина успеха!

Рассматриваемыетемы:

Системыулучшениябизнес-процессов Обзоруправленияпроектами Факторыуспехапроекта Четыреограниченияпроекта Проекты,программыипортфолио Заключение Краткоеизложениерешений Частозадаваемыевопросы 20 Глава1.КакуправлениепроектамиприменимокIT?

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

Системы улучшения бизнес-процессов Об улучшении бизнес-процессов (BPI – business process improvement) в той или иной форме говорят уже не один десяток лет. Компании постоянно ищут пути для того, чтобы работать более эффективно, а эффективность зачастую приводит к конкурентным преимуществам. Если компания может создать более продвинутую компьютерную программу или автозапчасть с меньшей себестоимостью, чем другая компания, – это явное преимущество. Такую продукцию можно продать дешевле, чем конкуренты; тогда компания сможет захватить большую долю рынка. Другой вариант – продавать деталь по той же цене, что и конкуренты, зарабатывая при этом большую прибыль.

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

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

Институт управления проектами (Project Management Institute, PMI) повсеместно признан в США как лидер в области управления проектами и компания, которая устанавливает и продвигает стандарты управления проектами.

PMI насчитывает 150 тысяч членов в 150 странах. Институт выдает два сертификата в управлении проектами, каждый из которых сегодня считается «золотым стандартом» в управлении проектами. Кроме того, PMI издает «Свод знаний по управлению проектами» (Project Management Body of Knowledge), спонсирует семинары, конференции и тренинги, связанные с управлением проектами. Есть и другие международные компании аналогичного профиля, такие как Международная ассоциация управления проектами, которая базируется в Нидерландах. Сегодня на рынке есть много других, вполне достойных тренингов по УП и программ сертификации, включая программы от ведущих университетов и колледжей по всему миру. Некоторые программы и сертификаты более популярны, чем прочие. Сертификация PMI – это общепринятый стандарт, но помните, что во многих случаях сертификаты УП не нужны для работы. Если вы хотите получить должность менеджера проектов, такой сертификат может помочь, но вполне достаточно будет опыта и знаний в области УП. Прочитав эту книгу, вы лучше поймете, что входит в УП – и, если собираетесь продолжить свою карьеру как менеджер проектов, можете пройти формальное обучение и сертификацию. Много интересного об УП вы найдете на нашем сайте в Интернете www.pmi.org.

CMM и CMMI Модель зрелости возможностей (CMM – the capability maturity model) и набор моделей совершенствования процессов (CMMI – the capability maturity model integration) – это не системы управления проектами, а методологии улучшения процессов. В институте разработки ПО (SEI – Software Engineering Institute) университета Карнеги Мелон эти модели были разработаны как подходы к улучшению процессов в разработке программного 22 Глава1.КакуправлениепроектамиприменимокIT?

обеспечения. Сейчас CMM уступает свои позиции CMMI. Система CMMI фокусируется на различных дисциплинах, таких как разработка ПО, разработка систем, интеграция продуктов и разработка процессов, а также работа с поставщиками. Как написано на сайте SEI, процесс CMMI при разработке ПО фокусируется на «применении систематического, строгого и количественного подхода к разработке, функционированию и поддержке ПО».

Применение систематического, строгого и количественного подхода по сути своей аналогично управлению проектами. Есть несомненное пересечение между процессами УП и CMMI, и они могут сосуществовать в компании, причем в совокупности дают синергетический эффект. Более подробную информацию о CMMI можно найти на сайте SEI – www.sei.cmu.edu.

Шесть сигма «Шесть сигма» – это еще одна система улучшения процессов, которая как ураган захватила Америку. «Шесть сигма» – это очень жесткий процесс, который помогает компаниям фокусироваться на разработке и поставке практически совершенных продуктов и услуг. Термин «шесть сигма» взят из математической статистики – он измеряет, как далеко отклоняется данный процесс от совершенства. С точки зрения математики шесть сигма означают меньше 3,4 дефекта на миллион. Проще говоря, это означает, что 99,99966  % выхода всей продукции удовлетворяет стандартам качества.

Суть метода «шесть сигма» в том, что если вы можете измерить все дефекты процесса, то можете постоянно стремиться к их устранению, чтобы количество дефектов максимально приблизилось к нулю. Данный процесс улучшения качества был придуман в компании Motorola в 1970-е  годы, когда она столкнулась с серьезными проблемами в области качества. Проект был разработан Микелем Харри (Mikel Harry), старшим инженером в подразделении Government Electronic; именно он назвал метод «шесть сигма». В первый же год после внедрения практики «шесть сигма» компания Motorola сэкономила 250 млн долл. Позднее Джек Уэлч (Jack Welch), CEO компании General Electric, активно использовал «шесть сигма» в своей компании, после чего данная методика стала быстро распространяться. По утверждению GE, компания сэкономила 750 млн долл. в 1995 году, а компания Allied Signal говорит об экономии 165 млн долл. благодаря внедрению методологии «шесть сигма».

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

и титул чемпиона. Компания General Electric потратила более 465 млн долл.

на то, чтобы обучить более 10 тысяч сотрудников и сертифицировать их по этой системе.

Ситуация осложняется в силу того, что по «шесть сигма» нет универсального руководства, как в случае с CMMI. Поскольку система используется в индустрии, ее реализацию определяют разные компании. Есть общие параметры, но сертификация «шесть сигма» и бизнес-процессы для каждого конкретного случая свои. Например, если вы получили сертификат «черный пояс» в одной компании, а затем перешли в другую, вам придется пройти повторную сертификацию или переобучение. Другой вариант под названием «сокращенные шесть сигма» стал очень популярным на рынке. Для более подробного изучения данной темы вы можете набрать запрос «шесть сигма» в вашей любимой поисковой машине и получить большой список компаний, которые предлагают информацию о программе «шесть сигма» и сертификацию по ней.

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

ISO Международная организация по стандартизации (the International Standards Organization, ISO) – это некоммерческая организация, целью которой являются разработка и поддержка стандартов в самых разных отраслях. Один из самых известных примеров – ISO 9000, который стал международным мерилом требований качества при взаимодействии бизнеса с бизнесом. Еще один нарождающийся «общий стандарт» (то есть не предназначенный только для бизнеса или индустрии) – ISO 14000, который призван стать не менее (если не более) распространенным, чем ISO 9000, с тем чтобы помочь компаниям удовлетворить требованиям окружающей среды. Недавние перемены в стандарте ISO 9000 привели к объединению стандартов ISO 9001, ISO 9002 и ISO 9003 в новый стандарт ISO9001:2000, который становится единственным стандартом сертификации в семействе ISO 9000. ISO 9001:2000 – это единственный стандарт в семействе ISO 9000 для тех требований к системе качества компании, которая может быть сертифицирована внешним агентством.

Данный стандарт декларирует, что слово «продукт» применимо к услугам, 24 Глава1.КакуправлениепроектамиприменимокIT?

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

Так же как CMM, CMMI или «шесть сигма», стандарт ISO концентрируется на развитии согласованных, определенных и повторяемых процессов для улучшения качества. Чтобы узнать больше об ISO, вы можете посетить сайт www.iso.org.

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

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

Статистика успешных и провальных проектов В 1986 году Альфред Спектор (Alfred Spector), президент компании Transarc, выступил соавтором статьи, сравнивавшей постройку мостов с разработкой ПО. Как отмечалось в статье, мосты строятся вовремя, в пределах бюджета, и они не падают. А вот создание ПО редко укладывается во временные и бюджетные рамки, и полученный продукт почти всегда «ломается». Спектор предположил, что мосты строятся вовремя, в рамках бюджета и не падают потому, что конструкция и процесс постройки утверждены и разработчик практически не имеет возможности их менять. Естественно, такая практика создания мостов была выработана за 3000 лет. А вот разработка ПО – это относительно новая сфера деятельности. Она насчитывает не 3000, а всего 60–70 лет. Как и все молодые отрасли, разработка ПО сильно изменилась с момента своего рождения, но все еще напоминает ребенка, не умеющего ходить: то она мчится со скоростью света, то через мгновение спотыкается и останавливается по непонятной причине.

Мир разработки программного обеспечения кое в чем отличается, скажем, от модернизации инфраструктуры корпоративной сети. Однако проблемы, с которыми приходится сталкиваться в проектах разработки ПО, характерны для всех типов IT-проектов, поэтому мы изучим некоторые данные, собранные компанией Standish Group International Inc. при разработке ПО.

Standish Group International (или просто Standish Group) начала исследовать провалы и успехи проектов ПО еще в 1990-е годы. С тех пор каждые два года публиковался отчет под названием CHAOS Report, где приводилась статистика по многим аспектам разработки проектов ПО. Интересно, что в первом отчете (1994 год) только 16 % всех проектов увенчались успехом, 31  % провалились, а 53% считались проблемными. Термин «проблемные»

означает, что проекты вышли за рамки временного плана, бюджета или же не отвечают поставленным задачам в плане функционала или качества.

«Успешные» проекты выполняются вовремя, в рамках бюджета и отвечают практически всем первоначально определенным требованиям. Итак, в 1994 году только 16 % проектов были успешными.

Существует и менее известная статистика, которая касается провала проектов. В  1995 году компании США потратили более 250 млрд долл. на разработку ПО. Средняя цена разработки проекта в крупной компании составляла около 2,3 млн долл. Для средних компаний эта цена была равна примерно 1,3 млн долл., а для малых предприятий – примерно 430 млн долл.

Это очень большие суммы, особенно для малого бизнеса. Давайте проделаем простые математические расчеты. По состоянию на 1995 год стоимость прекращенных проектов в частных и государственных компаниях составляла около 81 млрд долл. Если каждый проект в области ПО обходится малым компаниям в 434 тыс. долл. и только 16 % из них заканчиваются успешно, подумайте о миллионах долларов, которые теряет малый бизнес! Количество средних и крупных компаний тоже имеет значение, но все же потери малого бизнеса особенно болезненны.

Через шесть лет, в 2000 году, «интернет-бум» был уже в самом разгаре, и компании, занимающиеся ПО, стоили гроши (да и то многие считали эту цену завышенной!). Естественно предположить, что эффективность разработки ПО заметно выросла благодаря деньгам, времени и усилиям, которые были вложены в ее развитие. По оценке Standish Group, в 2000 году уже 28 % всех проектов ПО можно было назвать успешными. Неплохой результат всего за шесть лет развития, но есть и плохая новость: 23 % всех проектов 26 Глава1.КакуправлениепроектамиприменимокIT?

по-прежнему проваливаются, а 29  % остаются проблемными. Достаточно сложно пойти к начальнику и сказать: «Давайте-ка потратим полмиллиона долларов на этот IT-проект, хотя его шансы на успех равны 28 %», – но именно так и поступают люди, внедряя те или иные проекты без четко установленного процесса управления.

А вот еще более печальные новости: для большинства проектов в категории успешных (28  %) характерны стремительно раздувающиеся объемы издержек! По словам экспертов компании Standish Group, «руководители IT-департаментов компаний рассказывают, что они проводят свою оценку стоимости проекта, умножают на два, а потом добавляют еще половину!».

Поэтому показатель 28%-ного успеха достигается только при условии, что расходы утраиваются. Тогда получается, что эти 28 % недалеко ушли от 16 % по состоянию на 1994 год – просто IT-профессионалы научились лучше предвидеть и оценивать стоимость разработки.

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

Естественно, проблема совсем не в разработке ПО, поэтому не пытайтесь спихнуть всю ответственность на программистов. Как вы вскоре поймете, есть множество организационных аспектов, которые могут послужить причиной провала проекта (а также его успеха), а кроме того, каждый участник проекта в той или иной степени отвечает за его успех. После того как вы узнали плохую новость, давайте посмотрим, что могут предпринять компании и IT-менеджеры для того, чтобы повысить шанс на успех всех IT-проектов (в том числе и по разработке ПО). Если после этого не появится хороших новостей, то всех нас ожидают большие проблемы!

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

Когда стало ясно, что компьютерный рынок имеет все шансы на развитие, одна английская компания решила создать домашний компьютер.

Он был построен на процессоре Zilog Z80 и имел 128 Кб ОЗУ – огромный объем памяти по тем временам! В нем были последовательные порты RS232/RS432 и выходной порт RGB, порт для принтера Centronics, два порта для внешних джойстиков, кассетный интерфейс, слот для картриджей ROM и слот расширения. В компьютере был предусмотрен четырехканальный стереозвук. Через несколько лет появятся еще и графический сопроцессор (названный «Ник» (Nick) в честь одного из разработчиков) и звуковой сопроцессор «Дейв» (Dave – по имени другого разработчика), которые возьмут на себя часть нагрузки процессора Z80. Для 1983 года это были невероятные возможности.

В сентябре 1983 года компания объявила о выпуске своего флагманского продукта «Предприятие 128». Товар не поступал в продажу до весны 1984 года. В это время компания принимала предварительные заказы, поскольку товары просто не были готовы к поставке. Было получено около 80 тысяч предварительных заказов – по тому времени очень неплохо для рынка домашних компьютеров.

К несчастью, на этом хорошие новости заканчиваются! Разрекламированные в 1983 году компьютеры так и не были поставлены до 1985-го, когда на рынке появилось много конкурентов. У них было меньше возможностей, но их продукция была дешевле. Через несколько лет после выпуска «Предприятия 128» компания разорилась и навсегда исчезла с рынка. Очень много устройств этого типа было продано в Венгрии, поэтому там на долгие годы возник обширный контингент пользователей «Предприятия 128».

Извлеченный урок. Проекты, которые не укладываются в сроки, выходят из бюджета и реализуют функции, которые никому не нужны (или не понятны), обречены на провал. Сотрудники компании усвоили этот урок, но, к сожалению, слишком поздно. Об этом случае можно прочесть в Интернете по адресу: http://en.wikipedia.org/wiki/Enterprise_128.

Факторы успеха проекта Есть много факторов, которые компании и IT-менеджеры могут использовать для того, чтобы повысить шанс любого IT-проекта на успех. Мы рассмотрим эти факторы в том порядке, в каком они обычно влияют на успех проекта. С течением времени их приоритетность меняется, но весь список в целом остается неизменным. Если вы хотите найти убедительные доводы в пользу внедрения управления проектами в своей компании, то вам надо особенно внимательно прочитать эту главу: тогда в вашем распоряжении 28 Глава1.КакуправлениепроектамиприменимокIT?

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

Фактор успеха 1: поддержка руководства Поддержка руководства – это фактор номер один, влияющий на успех проекта. Конечно, это не удивительно. Если руководители не поддерживают проект, они будут неохотно выделять необходимые для него ресурсы (рабочее время, финансы, оборудование и т. д.). Они будут неохотно защищать проект, если в ходе его выполнения возникнут проблемы или его будет «топить» корпоративная бюрократия. Заинтересованное руководство может помочь сформировать группы из разных департаментов, особенно когда проект большой и выполняется сотрудниками нескольких отделов. Наконец, благодаря поддержке руководства проект становится заметным в компании, что может быть хорошо или плохо в зависимости от его результатов.

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

Фактор успеха 2: вовлечение пользователей Вовлечение пользователей стоит в нашем списке под номером два только потому, что если проект не завершится, то он не может быть успешным;

следовательно, основной залог успеха – все-таки поддержка руководства.

Но и вовлечение пользователей почти так же важно.