«Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению программными проектами Москва 2009 1 Содержание Отзыв на книгу Об авторе Благодарности ...»

С.АРХИПЕНКОВ

Лекции по

управлению

программными

проектами

2009

Содержание

Стоимость Время

МОСКВА

2009

МОСКВА

С. Архипенков

Лекции по управлению программными проектами Москва 2009 1 Содержание Отзыв на книгу

Об авторе

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

Предисловие

Лекция 1. Введение в программную инженерию

История и основные понятия

Отличия программной инженерии от других отраслей

Эволюция подходов к управлению программными проектами........ Модели процесса разработки ПО

Что надо делать для успеха программного проекта

Выводы

Дополнительная литература и источники

Лекция 2. Управление проектами. Определения и концепции............... Проект - основа инноваций

Критерии успешности проекта

Проект и организационная структура компании

Организация проектной команды

Жизненный цикл проекта. Фазы и продукты

Выводы

Дополнительная литература и источники

Лекция 3. Инициация проекта

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

Концепция проекта

Цели и результаты проекта

Допущения и ограничения

Ключевые участники и заинтересованные стороны

Ресурсы

Сроки

Риски

Критерии приемки

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

Выводы

Дополнительная литература и источники

Лекция 4. Планирование проекта

Уточнение содержания и состава работ

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

Планирование организационной структуры

Планирование управления конфигурациям

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

Базовое расписание проекта

Выводы

Дополнительная литература и источники

Лекция 5. Управление рисками проекта

Основные понятия

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

Идентификация рисков

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

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

Планирование реагирования на риски

Главные риски программных проектов и способы реагирования.... Управление проектом, направленное на снижение рисков............... Мониторинг и контроль рисков

Выводы

Дополнительная литература и источники

Лекция 6. Оценка трудоемкости и сроков разработки ПО

Оценка - вероятностное утверждение

Негативные последствия «агрессивного» расписания

Прагматичный подход. Метод PERT

Обзор метода функциональных точек

Основы методики COCOMO II

Выводы

Дополнительная литература и источники

Лекция 7. Формирование команды

Лидерство и управление

Правильные люди

Мотивация

Эффективное взаимодействие

Выводы

Дополнительная литература и источники

Лекция 8. Реализация проекта

Рабочее планирование

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

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

Выводы

Дополнительная литература и источники

Заключение. Растите профессионалов

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

Теперь не буду, С. Архипенков меня опередил.

В книжке С. Архипенкова в достаточно интересной форме описаны основные элементы управления программными проектами. Автор, конечно, скромничает, говоря, что он охватил только 20% объема материала, я думаю, что гораздо больше. С массой интересных примеров описывается понятие программной инженерии, её сходства и отличия по сравнению с другими областями управления, далее в увлекательной форме описываются понятия проекта, жизненного цикла, планирования, управления рисками, вопросы формирования коллектива и реального управления. Некоторые свежие примеры (аналогия с киноиндустрией, культ «Карго» и многие другие) я обязательно буду использовать в своих лекциях. Каждая глава завершается выводами, где в краткой форме формулируются основные идеи раздела управления проектами.

Мои студенты будут в восторге от этой книги, прежде всего благодаря выводам.

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

По въевшейся профессорской привычке не удержусь от нескольких замечаний.

Прежде всего, меня резануло слишком частое упоминание программирования как ремесла, лишенного строгой научной базы. Разумеется, это не так.

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

На странице 44 в сноске есть язвительное замечание, что «в 2000 году ещё оставались те, кто верил, что из модели UML можно будет генерировать исходный код». Мы уже много лет создаем информационные системы, программное обеспечение для телефонных станций и других систем реального времени практически без единой строки кода, написанного вручную. Да, действительно, пришлось многие вещи додумать, защитить несколько диссертаций, но практический опыт промышленного применения показывает, что цитируемая идея вовсе не была эфемерной.

Если бы эту книгу писал я, то, конечно, не уделил бы столько внимания несколько шарлатанской идее определения объема будущего ПО на основе функциональных точек. Этот метод, и то с натяжкой, работает только для типового ПО. С. Архипенков всего второй человек среди моих знакомых, который верит в этот метод. Первым был профессор Александр Самочадин из Санкт-Петербургского Политеха, да и тот недавно в частной беседе признался, что разочаровался в нем.

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

Я с удовольствием буду рекомендовать книгу С. Архипенкова своим студентам и аспирантам, а если удастся, то и сотрудникам нашего холдинга AT Software.

Об авторе Эксперт в управлении проектами, PMP PMI. В разработке ПО более 30 лет.

Создавал имитационные модели сложных космических систем в Центре управления полетами (ЦНИИМаш). Руководил коммерческой разработкой ПО и проектами организационного развития в компаниях PriceWaterhouseCoopers, Luxoft, CBOSS. Выполнял проекты по заказу Европейского космического агентства, «Даймлер-Бенц Аэроспейс», корпорации «Боинг», ЦБ РФ, ОАО «Газпром». Автор книг, статей и учебных курсов по информационным технологиям и управлению программными проектами.

[email protected].

Благодарности Учителя это не те, кто учит, а те, у кого учатся. Мне повезло, для меня такими учителями стали Н.А.Анфимов, И.К.Бажинов, А.Т.Горяченков, Ю.А.Мозжорин, Н.Н.Нетылев, А.И.Шеховцов, а также многие другие научные работники и специалисты ЦНИИМаш. Еще больше было учителей, у которых я учился тому, как не надо руководить людьми. Всем спасибо!

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

С этим трудно было спорить, поскольку разработка ПО имеет свою специфику, которая плохо укладывается в классическое управление проектами. Поэтому было решено подготовить собственный курс по управлению проектами именно в разработке ПО. Так появилась первая версия данного «курса молодого бойца», который предназначался для начинающих руководителей проектов и их начальников. Не ставилась задача, заменить свод знаний PMBOK от PMI. Знать и понимать лучшие практики, изложенные в этом руководстве, должен каждый профессиональный менеджер проекта. В лекции вошли лишь 20% знаний о дисциплине управления проектами, но эти знания будут востребованы в 80% ситуаций, с которыми участникам проекта придется столкнуться в реальной работе.

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

Ну, и кому от этого счастье?

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

И еще больше времени у него уходит на понимание того, почему надо делать именно так, а не иначе. Хотелось бы восполнить данный пробел.

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

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

Лекция 1. Введение в программную инженерию История и основные понятия Программная инженерия есть применение определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного Термин software (программное обеспечение, ПО) ввел в 1958 году всемирно известный статистик Джон Тьюкей (John Tukey). Термин software engineering (программная инженерия) впервые появился в названии конференции НАТО, состоявшейся в Германии в 1968 году и посвященной так называемому кризису программного обеспечения. С 1990-го по 1995 год велась работа над международным стандартом, который должен был дать единое представление о процессах разработки программного обеспечения. В результате был выпущен стандарт ISO/IEC 12207 [2]. В 2004 году в отрасли был создан основополагающий труд «Руководство к своду знаний по программной инженерии» (SWEBOK) [3], в котором были собраны основные теоретические и практические знания, накопленные в этой отрасли.

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

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

Цели могут быть любые: воспроизведение звука в динамике ПК, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели.

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

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

программист и потребитель.

Профессиональный программист – человек, который занимается профессиональным программированием.

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

Программный продукт – совокупность программ и сопроводительной документации по их установке, настройке, использованию и доработке.

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

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

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

Модель процесса разработки ПО – формализованное представление процесса разработки ПО. Часто при описании процессов вместо слова модель употребляется термин методология, что приводит к неоправданному расширению данного понятия.

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

Software requirements – программные требования.

Software design – дизайн (архитектура).

Software construction – конструирование программного обеспечения.

Software testing – тестирование.

5. Software maintenance Software configuration management – конфигурационное управление.

Software engineering management – управление в программной Software engineering process – процессы программной инженерии.

Software engineering tools and methods – инструменты и методы.

10. Software quality – качество программного обеспечения.

Дополнительные области знаний включают в себя:

Computer engineering – разработка компьютеров.

Computer science – информатика.

Management – общий менеджмент.

Mathematics – математика.

Project management – управление проектами.

Quality management – управление качеством.

Systems engineering – системное проектирование.

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

Отличия программной инженерии от других отраслей Standish Group, проанализировав работу сотен американских корпораций и итоги выполнения нескольких десятков тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» [4] пришла к следующим неутешительным выводам (Рисунок 2):

Только 35 % проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и 46 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. Среднее превышение сроков составило 120%, среднее превышение затрат 100%, обычно исключалось значительное число 19 % проектов полностью провалились и были аннулированы до Рисунок 2. Результаты анализа успешность программных проектов за 2006 год Сразу дам ответы на вечные российские вопросы «Кто виноват?» и «Что Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то «хаоса» не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью, потому что то, что производят программисты – нематериально, это коллективные ментальные модели, записанные на языке программирования. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО лежат в области психологии.

Гуру программирования Ф. Брукс в 1975 году писал [5]: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов».

То, что производят программисты нематериально – это коллективные мысли и идеи, выраженные на языке программирования. Я не говорю, что производство ПО суперсложная интеллектуальная деятельность. Отрасль еще только зарождается. Время вхождения в профессию сильно меньше, чем в других инженерных дисциплинах. Разрабатывать ПО точно не сложнее, чем делать ракеты. Просто в силу уникальности отрасли опыт профессионалов, накопленный в материальном производстве и изложенный в стандарте PMI PMBOK [6], мало способствует успеху в управлении программным проектом.

Управлять разработкой ПО надо иначе.

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

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

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

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

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

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

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

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

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

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

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

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

И на каждом уровне абстракций их деталей становится все больше и больше.

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

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

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

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

Еще в начале 70-х замечательный ученый академик А.П.Ершов сказал [8]:

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

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

А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет так же далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского.

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

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

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

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

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

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

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

Количество провальных проектов в этих областях ничуть не меньше, чем в программировании. Дай Бог, если хотя бы пятая часть кинофильмов не «ложится на полки» после первого показа. Об этом же пишет авторитет в управлении программными проектами У.Ройс [7]: «Менеджеры программных проектов смогут добиться большего, если будут применять методы управления, характерные для киноиндустрии».

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

«Водопад» или каскадная модель. Жесткое управление с обратной связью.

Расчет опорной траектории (план проекта), измерение отклонений, коррекция и возврат на опорную траекторию. Лучше, но не эффективно.

«Гибкое управление». Расчет опорной траектории, измерение отклонений, расчет новой попадающей траектории и коррекция для выхода на нее. «Планы ничто, планирование - все» (Эйзенхауэр, Дуайт Дэвид) «Метод частых поставок». Самонаведение. Расчет опорной траектории, измерение отклонений, уточнение цели, расчет новой попадающей траектории и коррекция для выхода на нее.

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

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

Известно, что производительность разных программистов может отличаться в десятки раз. Утверждаю, что производительность одного и того же программиста может так же отличаться в десятки раз. Заставьте лучшего в мире бегуна бегать в мешке, и он покажет в 10 раз худший результат. Заставьте документацию (которую, как правило, никто не читает) в угоду «Методологии»

(именно с большой буквы ‘М’), - и его производительность снизится в 10 раз.

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

Модели процесса разработки ПО Модели (или, как еще любят говорить, методологии) процессов разработки ПО принято классифицировать по «весу» - количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

Наиболее распространенные современные модели процесса разработки ПО представлены на Рисунок 1.

Рисунок 3 Различные модели процесса разработки ПО и их распределение по «весу»

ГОСТы ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке ПО. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, строгое следование этим гостам не только приводит к водопадному подходу, но и требует очень высокой степени формализованности разработки.

На основе этих стандартов разрабатываются программные системы по госзаказам в России.

SW-CMM В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software [9] в качестве эталонной модели организации разработки программного обеспечения.

Данная модель определяет пять уровней зрелости процесса разработки ПО.

1. Начальный — процесс разработки носит хаотический характер.

Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей.

2. Повторяемый — установлены основные процессы управления проектами:

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

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

4. Управляемый — собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта.

Анализируется значение и динамика этих данных.

5. Оптимизируемый — постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP Унифицированный процесс (Rational Unified Process, RUP) [10] был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML.. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

MSF Microsoft Solutions Framework (MSF) [11] - это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.

PSP/TSP Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [12,13]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:

учитывать время, затраченное на работу над проектом;

учитывать найденные дефекты;

классифицировать типы дефектов;

оценивать размер задачи;

планировать программные задачи;

распределять их по времени и составлять график работы.

выполнять индивидуальную проверку проекта и архитектуры;

осуществлять индивидуальную проверку кода;

выполнять регрессионное тестирование.

численностью 3–20 разработчиков. Команды должны:

установить собственные цели;

составить свой процесс и планы;

отслеживать работу;

поддерживать мотивацию и максимальную производительность.

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

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

Выбор модели процесса достоинства и свои недостатки (Таблица 1).

Таблица 1. Плюсы и минусы тяжелых и легких моделей процессов разработки ПО модели Легкие Меньше непроизводительных Эффективность сильно зависит управлением проектом, рисками, способностей, требуют более изменениями, конфигурациями. квалифицированной, проектирования, основной упор функциональности, совмещение выполняемых проектов Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа «Карго» - религии самолетопоклонников.

В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения («муштру») и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи «USA». Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО» [14] проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет [15, 16]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что :

У каждого проекта должна быть своя модель процесса разработки.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х П» (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Рисунок 4. «Закон 4-х П». Процесс в проекте должен определяться в зависимости от проекта, Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.

Что надо делать для успеха программного проекта Стив Макконнелл в своей книге [17] приводит тест программного проекта на выживание. Этот чек-лист из 33-х пунктов, который я считаю необходимым процитировать с небольшими корректировками. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих Чтобы программный проект стал успешным, необходимо:

1. Четко ставить цели.

2. Определять способ достижения целей.

3. Контролировать и управлять реализацией.

4. Анализировать угрозы и противодействовать им.

5. Создавать команду.

1.1. Концепция определяет ясные недвусмысленные цели.

1.2. Все члены команды считают концепцию реалистичной.

1.3. У проекта имеется обоснование экономической эффективности.

1.4. Разработан прототип пользовательского интерфейса.

1.5. Разработана спецификация целевых функций программного продукта.

1.6. С конечными пользователями продукта налажена двухсторонняя связь 2. Определяем способ достижения целей 2.1. Имеется детальный письменный план разработки продукта.

2.2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).

2.3. После каждой фазы проекта обновляется расписание и бюджет.

2.4. Архитектура и проектные решения документированы.

2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.

2.6. Определен план многоэтапной поставки продукта.

2.7. В плане учтены обучение, выходные, отпуска, больничные.

2.8. План проекта и расписание одобрен всеми участниками команды.

3. Контролируем и управляем реализацией 3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.

3.2. У проекта есть менеджер, причем только один!

3.3. В плане проекта определены «бинарные» контрольные точки.

3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.

3.5. Между руководством и разработчиками установлены доверительные 3.6. Установлена процедура управления изменениями в проекте.

3.7. Определены лица, ответственные за решение о принятии изменений в 3.8. План, расписание и статусная информация по проекту доступна каждому участнику.

3.9. Код системы проходит автоматическое рецензирование.

3.10. Применяется система управления дефектами.

4. Анализируем угрозы 4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.

4.2. Руководитель проекта отслеживает возникновение новых рисков.

4.3. Для каждого подрядчика определено лицо, ответственное за работу с 5. Работаем над созданием команды 5.1. Опыт команды достаточен для выполнения проекта.

5.2. У команды достаточная компетенция в прикладной области.

5.3. В проекте имеется технический лидер.

5.4. Численность персонала достаточна.

5.5. У команды имеется достаточная сплоченность.

5.6. Все участники привержены проекту.

Оценка и интерпретация теста Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

Поправочные коэффициенты:

Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать. Именно об этом пойдет речь Выводы То, что производят программисты нематериально – это коллективные мысли и идеи, выраженные на языке программирования. В силу уникальности отрасли опыт, накопленный в отраслях материального производства, мало способствует успеху в управлении программным проектом. Прямые аналогии с этими отраслями не работают. Управлять разработкой ПО надо иначе.

Не существует единственного правильного процесса разработки ПО.

Эффективный производственный процесс должен основываться на итеративности, инкрементальности, самоуправляемости команды и адаптивности. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.

Чтобы программный проект стал успешным, необходимо:

2. Определять способ достижения целей.

3. Контролировать и управлять реализацией.

4. Анализировать угрозы и противодействовать им.

5. Создавать команду.

Дополнительная литература и источники 1. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering 2. EEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle «Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.

David Rubinstein, «Standish Group Report: There’s Less Development (http://www.sdtimes.com/content/article.aspx?ArticleID=30247) Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.

«PMBOK. Руководство к Своду знаний по управлению проектами», 3-е Уолкер Ройс, «Адаптивный стиль управления программными Ершов А. П., «О человеческом и эстетическом факторе в программировании». Информатика и образование. 1993. № 6.

9. Paulk, Mark C., and others, Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24). Pittsburgh, Pa.: Software Engineering Institute, 10. Филипп Крачтен, «Введение в Rational Unified Process», Вильямс, 2002 г.

11. «MSF, Microsoft, Microsoft Solutions Framework», Отдел MSF, Microsoft, 12. M. Pomeroy-Huff, J. Mullaney, R. Cannon, M. Sebern, «The Personal Software Process (PSP) Body of Knowledge», version 1.0, SPECIAL 13. Watts S. Humphrey, «The Team Software Process (TSP)», Technical Report 14. Kent Beck, and others, «Manifesto for Agile Software Development», (http://www.agilemanifesto.org/) 15. А. Коуберн, «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения», Humans and Technology Technical Report, Oct.1999 (русский перевод К.Максимов, А.Максимова, http://www.maxkir.com/sd/people_as_nonlinearRUS.htm) 16. А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод К.Максимов, А.Максимова, http://www.maxkir.com/sd/methyperproject_RUS.htm).

17. С. Макконнелл, «Остаться в живых. Руководство для менеджеров программных проектов», «Питер», 2006.

Лекция 2. Управление проектами. Определения и концепции Проект - основа инноваций Классическое управление проектами [1] выделяет два вида организации человеческой деятельности: операционная и проектная.

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

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

Проект - временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.

У операционной и проектной деятельности есть ряд общих характеристик:

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

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

Уникальность так же важное отличие проектной деятельности от операционной.

Если бы результаты проекта не носили уникальный характер, работу по их достижению можно было бы четко регламентировать, установить производственные нормативы и реализовывать в рамках операционной деятельности (конвейер). Задача проекта – достижение конкретной бизнесцели. Задача операционной деятельности – обеспечение нормального течения Проект - это средство стратегического развития (Рисунок 5). Цель – описание того, что мы хотим достичь. Стратегия – констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а Рисунок 5. Проект – средство стратегического развития Таким образом, каждая работа, которую выполняет конкретный сотрудник, привязывается к достижению стратегических целей организации.

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

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

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

Наиболее известные центры компетенции:

PMI, Project Management Institute, PMBOK - американский национальный стандарт ANSI/PMI 99-001-2004.

IPMA, International Project Management Association. В России - СОВНЕТ.

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

Эпоха перемен. Все в мире стало непрерывно и стремительно изменяться.

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

Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали [2].

Глобализация. Всеобщая взаимозависимость и взаимосвязанность.

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

Интернет. Конкуренция без границ. Пример. Google. За ночь любой из нас в принципе может создать многомиллионную компанию у себя в гараже. С помощью Интернета вы можете выйти на рынок, на котором более 100 млн.

Все решают таланты. Простая мобилизация средств и усилий уже не может обеспечить прогресс. Вспомним Ф. Брукса [3], «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Идею богатства теперь связывают не с деньгами, а с людьми, не с финансовым капиталом, а с «человеческим». Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора. Работники интеллектуального труда начинают самостоятельно определять себе цену.

Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата.

Репродуктивная деятельность уходит в прошлое. В постиндустриальном обществе интеллект - основная производственная сила. Сегодня от 70 до 80% всего, что сегодня делается людьми, производится при помощи их интеллекта [4]. В любом товаре, сделанном в США, доля зарплаты составляет процентов. Но это в среднем по всем товарам. Что касается разработки ПО, то почти все, что в этой отрасли производится, создается при помощи интеллекта.

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

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

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

Критерии успешности проекта Задача проекта – достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника» (Рисунок 6). Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие.

Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание.

Рисунок 6. «Железный треугольник» ограничений проекта Согласно текущей редакции стандарта PMBOK [1], проект считается успешным, если удовлетворены все требования заказчика и участников проекта. Поэтому у проекта разработки ПО сегодня не три, а четыре фактора успеха:

Выполнен в соответствие со спецификациями.

Выполнен в пределах бюджета.

Каждый участник команды уходил с работы в 18:00 с чувством успеха.

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

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

Современное предприятие обязано относиться к своим работникам так же, как к своим лучшим клиентам. Главный капитал современной компании – это знания.

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

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

Синоним функциональной структуры - иерархическая структура (Рисунок 7).

Рисунок 7. Функциональная структура Функциональная структура имеет следующие особенности:

Сохраняется принцип единоначалия Хорошо приспособлены для операционной деятельности.

Специализация подразделений позволяет накапливать экспертизу.

Затруднено принятие решений и коммуникации между исполнителями.

Осуществляются только через руководство.

Управление сконцентрировано и держится на компетенции высшего Как правило, неэффективен контроль за ходом проекта (нет целостной Функциональная структура предполагает многоуровневую иерархию.

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

министерства, ведомства, научные институты и предприятия советского периода.

На другом краю спектра организационных структур находится проектная структура (Рисунок 8).

Рисунок 8. Проектная структура В чисто проектных организациях:

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

Персонал на проект набирается по временным контрактам.

После завершения проекта персонал увольняется.

Медленный старт.

Опыт не аккумулируется.

Команды не сохраняются.

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

В разработке ПО наиболее распространена матричная организация. Различают три вида матричной организационной структуры: слабая, сбалансированная и сильная (Рисунок 9 - Рисунок 11). Причем, в компаниях, которые занимаются продуктовой разработкой ПО, функциональные подразделения определяются в соответствие с линейкой продуктов. Например, отдел разработки CRM-систем, отдел разработки финансовых систем, отдел разработки дополнительных продуктов.

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

Рисунок 9. Слабая матрица В слабой матрице роль и полномочия сотрудника, который координирует проект, сильно ограничены. Реальное руководство проектом осуществляет один из функциональных руководителей. Координатор проекта, его еще часто называют «трекер», помогает этому руководителю собирать информацию о статусе выполняемых проектных работ, учитывает затраты, составляет отчеты.

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

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

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

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

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

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

Анализ. Извлечение, документирование и сопровождение требований к Управление. Определение и управление производственными Производство. Проектирование и разработка ПО.

Тестирование. Тестирование ПО.

Обеспечение. Производство дополнительных продуктов и услуг.

Группа анализа включает в себя следующие роли:

Бизнес-аналитик. Построение модели предметной области (онтологии).

Бизнес-архитектор. Разрабатывает бизнес-концепцию системы.

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

Специалист по требованиям. Документирование и сопровождение требований к продукту.

Менеджер продукта (функциональный заказчик). Представляет в проекте интересы пользователей продукта.

Группа управления состоит из следующих ролей:

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

Принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.

Руководитель группы тестирования. Определение целей и стратегии тестирования, управление тестированием.

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

В производственную группу входят:

Проектировщик. Проектирование компонентов и подсистем в соответствие с общей архитектурой, разработка архитектурно значимых Проектировщик базы данных.

Проектировщик интерфейса пользователя.

Разработчик. Проектирование, реализация и отладка отдельных модулей системы.

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

Группа тестирования в проекте состоит из следующих ролей:

Проектировщик тестов. Разработка тестовых сценариев.

Разработчик автоматизированных тестов.

Тестировщик. Тестирование продукта. Анализ и документирование результатов.

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

Технический писатель.

Дизайнер графического интерфейса.

Разработчик учебных курсов, тренер.

Участник рецензирования.

Продажи и маркетинг.

Системный администратор.

Специалист по инструментальным средствам.

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

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

Руководитель проекта + системный аналитик (+ системный архитектор) Системный архитектор + разработчик Системный аналитик + проектировщик тестов (+ технический писатель) Системный аналитик + проектировщик интерфейса пользователя Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик) Крайне нежелательно совмещать следующие роли:

Разработчик + руководитель проекта Разработчик + системный аналитик.

Разработчик + проектировщик интерфейсов пользователя.

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

Программисты любят и умеют программировать. Пусть они этим и занимаются.

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

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

Из профессиональных программистов получаются отличные тестировщики.

Лучшая команда тестирования, которую я встречал, была в Luxoft. Это были маститые программисты из одного академического НИИ с опытом 20-30 лет.

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

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

В модели Scrum рекомендуются ежедневные совещания по состоянию работ – «Stand Up Meeting», но мне кажется, что это применимо, скорее, для небольших рабочих групп от 3 до 5 разработчиков. Хотя в критические периоды проекта, приходилось проводить и ежедневные совещания.

Важно помнить, что организационная структура проекта – «живой» организм.

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

Жизненный цикл проекта. Фазы и продукты Ранее уже отмечалось, что каждый программный продукт имеет свой жизненный цикл, в который проект разработки очередного релиза входит как одна из фаз. Аналогично, каждый проект разработки ПО имеет свой собственный жизненный цикл, который состоит из четырех фаз (Рисунок 12).

Рисунок 12. Жизненный цикл и основные продукты программного проекта На фазе инициации проекта необходимо понять, что и зачем мы будем делать – разработать концепцию проекта. Фаза планирования определяет, как мы будем это делать. На фазе реализации происходит материализация наших идей в виде документированного и протестированного программного продукта.

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

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

Более подробно о каждой фазе проекта и их продуктах будет рассказано в последующих лекциях.

Завершая обзор управления проектами «с высоты птичьего полета», необходимо упомянуть еще об одной особенности проекта по сравнению с операционной деятельностью. Если в операционной деятельности ресурсы расходуются более-менее равномерно по времени, то в проектном управлении расходование ресурсов в единицу времени имеет явно выраженное колоколообразное распределение (Рисунок 13) Рисунок 13. Распределение ресурсов по фазам проекта Проект часто начинается с идеи, которая появляется у одного человека.

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

В современных моделях разработки ПО реализация осуществляется на основе сочетания итеративного и инкрементального подходов.

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

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

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

Выводы Проект - этот средство стратегического развития. Цель – описание того, что мы хотим достичь. Стратегия – констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а цели в Участников типового проекта разработки ПО можно условно разделить на пять Анализ. Извлечение, документирование и сопровождение требований к Производство. Проектирование и разработка ПО.

Обеспечение. Производство дополнительных продуктов и услуг.

У программного проекта имеется четыре фактора, которые определяют его Выполнен в соответствие со спецификациями.

Каждый участник команды уходил с работы в 18:00 с чувством успеха.

Дополнительная литература и источники «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е Стивен Р. Кови, «7 навыков высокоэффективных людей. Мощные инструменты развития личности», 2-е изд., М., Альпина Бизнес Букс, Брукс Фредерик, "Мифический человеко-месяц, или Как создаются программные комплексы", Пер. с англ., СПб., Символ-Плюс, 1999.

Кьелл А. Нордстрем, Йонас Риддерстрале, «Бизнес в стиле фанк.

Капитал пляшет под дудку таланта», Стокгольмская школа экономики в Санкт-Петербурге, 2005.

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

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

Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется.

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

В российской практике данный документ чаще называется Концепция проекта.

Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического В компании, которая принимает решение о старте того или иного проекта разработки ПО, должна существовать единая система критериев для оценки его значимости. Система критериев должна позволять из множества возможных для реализации проектов выбрать наиболее приоритетные для компании.

Приоритет любого проекта должен определяться на основе оценки трех его характеристик:

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

Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет.

Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.

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

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

Шкала оценки стратегической ценности проекта может иметь следующий вид:

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

Повторение конкурентами затруднено или потребует от 1 до 2 лет.

Выше среднего. Создает временные конкурентные преимущества.

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

Конкурентное преимущество может быть удержано в течение 1 года.

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

Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.

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

Примерная шкала оценки уровня рисков проекта может иметь следующий вид:

Низкий. Цели проекта и требования хорошо поняты и документированы.

Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

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

Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют.

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

Концепция проекта У каждого проекта должна быть концепция. Если проект небольшой, то для изложения концепции часто достаточно несколько абзацев. Однако, стартовать проект без концепции, это все равно, что отправлять корабль в плавание, не определив для него пункт назначения.

Концепция проекта разрабатывается на основе анализа потребностей бизнеса.

Главная функция документа - подтверждение и согласование единого видения целей, задач и результатов всеми участниками проекта. Концепция определяет что и зачем делается в проекте.

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

Ключевые участники и заинтересованные стороны Обоснование полезности проекта В качестве примера, который позволит иллюстрировать теоретическое изложение основ управления проектами, возьмем реальный проект разработки ПО для автоматизации одного из подразделений крупной производственной компании. Назовем его «Автоматизированная система продажи документации».

Краткая легенда проекта. Заказчик ОАО «ХYZ» является одним из ведущих производителей сложных технических изделий. Отдел «123», входящий в ОАО «XYZ», отвечает за продажу дополнительной сопроводительной документации Дополнительная документация не входит в стандартную поставку, поскольку владелец этого технического изделия не всегда сам его эксплуатирует, а передает в эксплуатацию другой компании, которая становится клиентом «XYZ», и закупает у нее эксплуатационную документацию. Ремонт и техобслуживание конкретного изделия может выполнять третья компания, которой уже потребуется детальная техническая документация по ремонту и обслуживанию. Она также становится клиентом «XYZ» и закупает у нее требуемую продукцию.

Основная функция отдела «123» - получение и обработка заказов на дополнительную документацию, согласно ежегодно рассылаемому каталогу. В связи с переездом отдела «123» в новое здание, была поставлена задача на разработку и поставку системы, автоматизирующей основную деятельность Текст документа Концепция проекта, который будет приводиться в качестве примера, будем выделять цветом фона.

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

Изменения в Компании. Например, автоматизация ряда бизнеспроцессов для повышения эффективности основной производственной Реализация стратегических планов. Например, завоевание значительной доли растущего рынка за счет вывода на него нового Выполнение контрактов. Например, разработка программного Разрешение специфических проблем. Например, доработка программного продукта в целях приведения его в соответствие с Цели должны быть значимыми (направленными на достижение стратегических целей Компании), конкретными (специфичными для данного проекта), измеримыми (т.е иметь проверяемые количественные оценки), реальными (достижимыми). Четкое определение бизнес-целей важно, поскольку существенно влияет на все процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Например, если реальные затраты на проект будут превосходить будущие доходы от его реализации.

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

Какие именно бизнес-выгоды получит заказчик в результате проекта.

Какой продукт или услуга. Что конкретно будет произведено по Высокоуровневые требования. Краткое описание и при необходимости ключевые свойства и/или характеристики продукта/услуги.

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

Соответствующий раздел документа концепция проекта создания «Автоматизированной системы продажи документации» будет выглядеть 1. Цели и результаты проекта 1.1. Целью проекта является повышение эффективности основной производственной деятельности отдела «123».

1.2. Дополнительными целями проекта являются:

1.2.1. Установление долгосрочных отношений с важным заказчиком ОАО «XYZ».

1.2.2. Выход на новый перспективный рынок современных B2C систем.

2. Результаты проекта должны обеспечить:

2.1. Снижение затрат на обработку заявок.

2.2. Снижение сроков обработки заявок.

2.3. Повышение оперативности доступа к информации о наличии продукции.

2.4. Повышение оперативности доступа к информации о прохождении заявок.

2.5. Повышение надежности и полноты хранения информации о поступивших заявках и результатах их обработки.

3. Продуктами проекта являются:

3.1. Прикладное ПО и документация пользователей.

3.2. Базовое ПО.

3.3. Оборудование ЛВС, рабочие станции, сервера и операционно-системное ПО.

3.4. Проведение пуско-наладочных работ и ввод в опытную эксплуатацию.

3.5. Обучение пользователей и администраторов системы.

3.6. Сопровождение системы на этапе опытной эксплуатации.

3.7. Передача системы в промышленную эксплуатацию.

4. Система должна автоматизировать следующие функции:

4.1. Авторизация и аутентификация пользователей.

4.2. Просмотр каталога продуктов.

4.3. Поиск продуктов по каталогу.

4.4. Заказ выбранных продуктов.

4.5. Просмотр информации о статусе заказа.

4.6. Информирование клиента об изменении статуса заказа.

4.7. Просмотр и обработка заказов исполнителями из службы продаж.

4.8. Просмотр статистики поступления и обработки заказов за период.

4.9. Подготовка и сопровождение каталога продукции.

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

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

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

Специфические требования к защите информации.

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

Содержание этого раздела для нашего проекта-примера выглядит следующим 5. Допущения и ограничения 5.1. Проектирование прикладного ПО выполняется с использованием UML.

5.2. Средством разработки ПО является Symantec Visual Cafe for Java.

5.3. В качестве промежуточного ПО сопровождения и поддержки каталога используется 5.4. Нагрузка на систему не должна быть более 100 одновременно работающих пользователей.

5.5. В рамки проекта не входят:

5.5.1. Защита системы от преднамеренного взлома.

5.5.2. Разработка B2B API и интеграция с другими системами.

Ключевые участники и заинтересованные стороны Одна из задач фазы инициации проекта это выявить и описать всех его участников. Согласно [1] к участникам проекта относятся все заинтересованные стороны (stakeholders), лица и организации, например заказчики, спонсоры, исполняющая организация, которые активно участвуют в проекте или чьи интересы могут быть затронуты при исполнении или завершении проекта.

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

К ключевым участникам программного проекта, как правило, относятся:

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

Проект стартовал в 2000 году, тема UML тогда была на слуху и даже оставались те, кто верил, что из модели на UML можно будет генерировать исходный код.

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

Еще один пример горячей темы и не оправдавшихся надежд – это объектно-ориентированные базы данных. У заказчика проекта уже были закуплены лицензии на эту базу данных и он очень хотел получить возврат от этих инвестиций. Поэтому ее использование в проекте стало одним из требований. К счастью, нам удалось быть достаточно убедительными и обосновать необходимость дополнительно использовать RDBMS Oracle для решения транзакционных задач. О том, к чему это привело, я подробно рассказал в своей книге: С. Архипенков, "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Москва, 2008 (http://www.happypm.com/sw_team_management.pdf).

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

Содержание этого раздела в концепции-примере будет иметь вид.

6. Ключевые участники и заинтересованные стороны 6.1. Спонсор проекта - директор Департамента информатизации ОАО «XYZ»