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

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

Программные продукты обычно представляют собой совокупность программ и необходимых

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

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

2. Выполнен в срок.

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

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

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

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

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

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

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

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

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



2. Методы управления проектами разработки программных средств

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

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

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

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

2. Управление. Определение и управление производственными процессами.

3. Производство. Проектирование и разработка ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Проектировщик базы данных.

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

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

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

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

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

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

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

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

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

- Переводчик.

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

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

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

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

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

- Технолог.

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

- Другие.

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

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

- Руководитель проекта + системный аналитик (+ системный архитектор)

- Системный архитектор + разработчик

- Системный аналитик + проектировщик тестов (+ технический писатель)

- Системный аналитик + проектировщик интерфейса пользователя

- Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик)

Крайне нежелательно совмещать следующие роли:

- Разработчик + руководитель проекта

- Разработчик + системный аналитик.

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

- Разработчик + тестировщик

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

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

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

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

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

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

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

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



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

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

Жизненный цикл и основные продукты программного проекта

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

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

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

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

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

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

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

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

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

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

Сочетание итеративности и инкрементальности обеспечивает эффективность разработки и существенное снижение рисков по ходу проекта. Об этом мы еще будем говорить.

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

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

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

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

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

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

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

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

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

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

- Финансовая ценность.

- Стратегическая ценность.

- Уровень рисков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4 Особенности рисков программных проектов и способы реагирования

В мировой практике выделяют пять основных причин неудачного исполнения проекта:

- Требования заказчика отсутствуют / не полны / подвержены частым изменениям.

- Отсутствие необходимых ресурсов и опыта.

- Отсутствие рабочего взаимодействия с заказчиком.

- Неполнота планирования. «Забытые работы».

- Ошибки в оценках трудоемкостей и сроков работ.

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

К часто упускаемым требованиям можно отнести:

- Функциональные

o Программы установки, настройки, конфигурации.

o Миграция данных.

o Интерфейсы с внешними системами.

o Справочная система.

- Общесистемные

o Производительность.

o Надежность.

o Открытость.

o Масштабируемость.

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

o Кросплатформенность.

o Эргономичность.

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

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

- Переоценка проекта каждый раз, когда требования добавляются / изменяются (уклонение).

- Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).

- Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).

Для большинства программных продуктов применим принцип Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

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

- Привлечь экспертов-консультантов на начальных этапах.

- Учитывать в оценках трудоемкости издержки на обучение сотрудников.

- Уменьшать потери от текучести кадров, привлекая на начальном этапе избыточное число участников.

- Учесть в оценках «время разгона» для новых сотрудников.

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

- Постоянное взаимодействие.

- Согласование пользовательских интерфейсов и разработка прототипа продукта.

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

При планировании работ по проекту часто «забывают»:

- Обучение.

- Координация работ.

- Уточнение требований.

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

- Разработка и поддержка скриптов автосборки.

- Разработка автотестов.

- Создание тестовых данных.

- Обработка запросов на изменения.

И еще. Не стоит надеяться, что участники проекта будут каждую неделю по 40 часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени. К списку наиболее распространенных причин этого относятся:

- Сопровождение действующих систем.

- Повышение квалификации.

- Участие в подготовке технико-коммерческих предложений.

- Участие в презентациях.

- Административная работа.

- Отпуска, праздники, больничные.

Рекомендация, планировать, что разработчики, которые назначены в проект на 100% будут реально работать над ваши ми задачами в среднем от 24 до 32 часов в неделю.



Заключение

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

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

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

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

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

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

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

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

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

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

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

2. Управление. Определение и управление производственными процессами.

3. Производство. Проектирование и разработка ПО.

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

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

У программного проекта имеется четыре фактора, которые определяют его успешность:

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

2. Выполнен в срок.

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

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

Литература

1. Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: ДМК-Пресс.2002.

2. Грей К, Ларсен Э. Управление проектами. Пер. с англ. - М.: «Дело и Сервис».2003.

3. Дитхелм Г. Управление проектами. В 2 т.: Пер. с нем. - СПб.: Издательский дом «Бизнес - пресса», 2003.-258 с.

4. Кофанов Ю.Н. Теоретические основы конструирования, технологии и надежности радиоэлектронных средств. - М.: Радио и связь, 1991.-360 с.

5. ЛитвакБ.Г. Экспертная информация. Методы получения и анализа. - М.: Радио и связь, 1982.

6. Руководство к Своду знаний по управлению проектами. Третье издание (Руководство PMBOK)/. Американский национальный стандарт ANSI/PMI 99-001-2004.

7. Топка В.В. Вероятностное моделирование в управлении проектами. - М., 1995 (Препринт / Институт проблем управления).

8. Управление проектами. Основы профессиональных знаний. Национальные требования к компетенции специалистов. - М.: Изд-во «Консалтинговое Агентство «КУБС Групп - Кооперация, Бизнес-Сервис», 2001.

9. Управление проектами: Основы профессиональных знаний. Национальные требования к компетентности специалистов. М.: Изд-во «Консалтинговое Агенство «КУБС Групп - Кооперация, Бизнес - Сервис», 2001-265 с.

10. Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4). М.: «Путь», 2000 - 384 с.

Размещено на Allbest.ru