Часть I

1. Введение и ограничения доклада2. Основные принципы управления проектом3. Инициация проекта4. Исполнение проекта5. Закрытие проекта

В докладе:Только тезисы. Без глубокого раскрытия.Личный опытПриводятся всем известные фактыЕсть тезисы жесткие по отношению к Заказчику

В докладе нет:Рассматриваются только проекты заказной

разработки ПОНет приверженности какой-то определенной

методологииНет упоминаний ГОСТовНет гибких методологий Нет универсальных решений

1. Проект должен иметь цели2. В организации должен быть процесс3. Необходимо думать о выходе из проекта4. Должна быть уверенность в успешном

выполнении проекта5. Менеджер не может думать и работать за

всех6. Нельзя жертвовать качеством

Оценка Создание ТКП Защита оценки Формальный старт проекта

Существует много разных методов оценки. Для выполнения оценки необходимо: ◦ Четко определить скоуп◦ Зафиксировать неопределенности и закрыть их

разумными допущениями◦ Сделать оценку несколькими способами, разными

людьми . Важно:◦ Просить на оценку комфортное временя◦ Не существует универсальных и точных методов оценки◦ Если оценка совпала с фактом на 99%, то это подгонка

результатов.◦ Оценка – устанавливает цель, к которой надо

стремиться.   Ее достижение зависит от нас (*).◦ Одну и ту же работу в разных условиях можно сделать за

разное время и бюджет.

В хорошем ТКП должны быть:◦ Техническая часть – рамки проекта, функции системы,

предлагаемое техническое решение◦ Коммерческая часть - бюджет, его обоснование,

условия и сроки оплаты◦ Описание процесса - сроки, команда, этапы,

материалы, правила коммуникации. Важно: ◦ Нельзя торопиться при создании ТКП◦ Процесс должен налагать обязательства на Заказчика.◦ Обязательно в ТКП донести Заказчику информацию о

рисках и связанных с ними допущениях.◦ Не все риски можно покрыть деньгами (*)

Оценку всегда приходится защищать! Защита бывает внутренняя и внешняя Принципы защиты:◦ Оценка должна быть понятна и аргументирована◦ Нельзя падать в оценках без убедительных

оснований◦ Нежелательно вестись на аргумент: «а Х сделает

это в N раз быстрее»

Необходимо: Подписанный договор или гарантийное письмо

Желательно: Чтобы команда была выделена к моменту старта

Триггер: Письмо по исполняющей организации о старте проекта

Сбор и анализ требований Дизайн/архитектура Кодирование/разработка Тестирование/контроль качества

Отвечает на вопрос: «Что делает система?». Цель: Зафиксировать требования, чтобы они не

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

проектирования: ◦ Функции системы◦ Нефункциональные требования

Детальные требования – нужны! Двигаться дальше можно когда:◦ Когда архитектор понимает нефункциональные

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

(пусть и с возможными переделками)◦ Когда Заказчик согласовал высокоуровневые требования

Отвечает на вопрос: «Как она это делает?» Цель: Создать архитектуру системы, отвечающую

требованиям к ней. Выводы: ◦ Архитектуру нельзя ставить впереди требований◦ При изменении требований может понадобиться

изменение архитектуры. В архитектуре должны быть отражены: ◦ Компоненты системы◦ Их взаимодействие (интерфейсы)◦ Интерфейсы с внешними системами◦ Набор технологий для реализации каждого компонента ◦ Предполагаемая схема развертывания

Желательно, чтобы архитектуру согласовал Заказчик.

Связывает вместе требования и архитектуру. Цель: Реализация системы отвечающей требованиям и

архитектуре. Важно: 

◦ Делать только то, что необходимо для выполнения целей проекта.◦ Реализовывать как можно проще.◦ Разрабатывать инкрементально. Чтобы каждый небольшой период

времени создавалась законченная, стабильная функциональность◦ Как можно раньше получить «отчуждаемую от разработчиков»

версию системы.◦ Не давать накапливаться дефектам.◦ Как можно раньше показать первую версию системы со стабильной

функциональностью Заказчику.◦ Запускать самые рискованные задачи как можно раньше. Снимать их

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

команде.

Отвечает на вопрос: «Готова ли система к сдаче?».

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

Выводы:1. Тестировать вечно не нужно. Как только цель

достигнута – можно переходить к сдаче.2. В готовой системе всегда есть дефекты. Этого

бояться не стоит3. Их наличие не должно препятствовать

нормальной работе пользователей.

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

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

стабильная версия системы.

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

Исполнить все формальности связанные с Закрытие контрактаУбедиться в том, что выставлены счета и получены деньги.Подвести итоги и извлечь уроки 

Три стратегии ПМа:2.Избавляться от проекта и забыть о нем3.Растягивать проект как можно дольше4.Закрывать проект и договариваться о

проекте поддержки и развития

Бесплатную гарантию давать нежелательно Гарантию лучше регламентировать SLA Гарантия должна иметь четкие временные рамки Для качественного гарантийного обслуживания

придется держать команду

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

Виртуальные (распределенные) команды Проектная коммуникация Работа во враждебной внешней среде и т.д.

Прошу задавать Ваши вопросы.