1. 01 Жизненный цикл проекта
1.1. Предиктивные
1.1.1. Предиктивный ЖЦ
1.1.1.1. Тщательное планирование на ранних этапах проекта
1.1.1.2. Небольшое количество изменений в требованиях
1.1.1.3. Единовременная поставка результатов
1.1.2. описание
1.1.2.1. определяются в начале проекта
1.1.2.1.1. продукт
1.1.2.1.2. поставляемые результаты
1.1.2.2. тщательно управляются
1.1.2.2.1. любые изменения в содержании
1.2. Адаптивные
1.2.1. Итеративный, итерационный ЖЦ
1.2.1.1. На начало разработки требования могут быть незавершенными
1.2.1.2. Последовательное приближение к образу готового продукта
1.2.1.3. Процесс повторяется, обеспечивая создание новой версии продукта для каждого цикла
1.2.1.4. ❗ На больших или очень больших проектах: Известны ключевые требования, но детали реализации могут изменяться с течением времени
1.2.2. Инкрементальный ЖЦ
1.2.2.1. Требования зафиксированы для конкретной сборки
1.2.2.2. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности,
1.2.2.2.1. а затем уже последовательное добавление новых функций, так называемых инкрементов.
1.2.3. Описание
1.2.3.1. продукт разрабатывается
1.2.3.1.1. в ходе многократных итераций
1.2.3.2. детальное содержание
1.2.3.2.1. определяется для каждой итерации только после начала итерации
2. 02 Жизненный цикл разработки ПО (SDLC)
2.1. это
2.1.1. ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования
2.1.2. время от начального момента создания какого-либо программного продукта, до конца его разработки и внедрения
2.2. Этапы SDLC
2.2.1. 1. Планирование системы
2.2.1.1. Определить, что н сделать, какие пробл решить при помощи
2.2.1.1.1. определения проблем, целей, ресурсов (персонал и тп)
2.2.1.1.2. изучить возмо-сти алт-ых решений путём встреч с клиентами, консультантами и сотрудниками
2.2.1.1.3. изучить, как сделать продукт лучше, чем у конкурентов
2.2.1.2. после завершения анализа на тапе планировани будет 3 варианта
2.2.1.2.1. разработать новую систему
2.2.1.2.2. улучшить существующую
2.2.1.2.3. оставить систему как есть
2.2.2. 2. Анализ будущей системы
2.2.2.1. Определяются требования к разарабатываемой системе: что н польз и как это реализовать
2.2.2.2. выполняется проверка: является ли этот проект экономически / организационно / технологически осуществимым
2.2.3. 3. Проектирование и Дизайн системы
2.2.3.1. Эта фаза определяет
2.2.3.1.1. элементы системы
2.2.3.1.2. компоненты
2.2.3.1.3. уровень безопасности
2.2.3.1.4. модули
2.2.3.1.5. архитектуру
2.2.3.1.6. различные интерфейсы
2.2.3.1.7. типы данных, которыми оперирует система
2.2.3.2. как
2.2.3.2.1. Дизайн системы в общих чертах может быть сделан ручкой на листке бумаги - он определяет, как система будет выглядеть и как функционировать
2.2.3.2.2. Затем делается расширенный, детальный дизайн, с учетом всех функциональных и технических требований, как логически, так и физически
2.2.3.3. Дизайн системы
2.2.3.3.1. Архитектурный дизайн
2.2.3.3.2. Визуальный дизайн
2.2.4. 4. IMPLEMENTATION Разработка
2.2.4.1. именно здесь пишется код
2.2.4.2. если система включает хардверную часть, фаза внедрения будет включать в себя конфигурацию и настройку «железа» под определенные требования и функции
2.2.5. 5. Тестирование, интеграция
2.2.5.1. На этом этапе происходит сборка различных компонентов и подсистем в одну целостную систему
2.2.5.2. Затем мы подаем системе различные входные данные и анализируем выход, поведение и функционирование
2.2.5.3. Тестирование может выполняться настоящими пользователями или специальной командой сотрудников, также оно может быть ручным и автоматизированным, с тем, чтобы удостовериться, что актуальные результаты работы системы совпадают с предусмотренными и желательными
2.2.6. 6. MAINTENANCE Доставка и Поддержка
2.2.6.1. На этой фазе осуществляется периодическая техническая поддержка системы, чтобы убедиться, что система не устарела. Сюда входит замена старого оборудования и постоянная оценка производительности.
2.2.6.2. Также здесь осуществляются апдейты определенных компонентов с целью удостовериться, что система отвечает нужным стандартам и новейшим технологиям, чтобы не быть подверженной текущим угрозам безопасности
2.3. Примеры SDLC
2.3.1. Каскадная (водопадная) модель
2.3.1.1. Преимущества
2.3.1.1.1. Последовательное выполнение этапов проекта в строго фиксированном порядке
2.3.1.1.2. Позволяет оценивать качество продукта на каждом этапе
2.3.1.2. Недостатки
2.3.1.2.1. Отсутствие обратных связей между этапами
2.3.1.2.2. Не соответствует реальным условиям разработки программного продукта
2.3.2. Спиральная модель
2.3.2.1. 4 ключевые фазы
2.3.2.1.1. Проработка целей, альтернатив и ограничений
2.3.2.1.2. Анализ рисков и прототипирование
2.3.2.1.3. Разработка (промежуточной версии) продукта
2.3.2.1.4. Планирование следующего цикла
2.3.2.2. Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование, делающий упор на начальные этапы жизненного цикла: анализ и проектирование.
2.3.2.2.1. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
2.3.2.3. Недостатки
2.3.2.3.1. Высокие накладные расходы
2.3.2.3.2. Сложность применения для небольших проектов
2.3.2.3.3. Высокая зависимость успеха от качества анализа рисков
2.3.2.4. Преимущества
2.3.2.4.1. Глубокий анализ рисков
2.3.2.4.2. Подходит для крупных проектов
2.3.2.4.3. Достаточно раннее прототипирование
3. 03 Критерии успеха и неудач ИТ-проектов
3.1. Причины неудач
3.1.1. Недостаточное планирование
3.1.2. Отсутствие поддержки со стороны ЛПР
3.1.3. Низкое качество коммуникаций, недостаточность
3.1.4. Неэффективное управление
3.1.5. Отсутствие гибкости
3.1.6. Неполноценное использование методик, фрэймворков
3.1.7. Игнорирование: сроков, бюджетов, планов
3.2. Критерии успеха
3.2.1. Реализованы ключевые функции системы
3.2.2. Субъективная и объективная оценка заказчика
3.2.3. Ввод в эксплуатацию
3.2.4. Количество активных пользователей в системе
3.2.5. Достигнуты цели проекта
3.2.6. Сроки, бюджеты, качество :)
3.2.7. Дополнительные критерии успеха
3.2.7.1. Проект способствует реализации стратегии компании на рынке
3.2.7.2. Повысилась квалификация персонала
3.2.7.3. Укрепился имидж компании
3.2.7.4. Повысилась лояльность существующих клиентов
3.2.7.5. Заключены новые контракты и сделки
3.2.7.6. Произошел выход на новые рынки и другое
4. 04 Как правильно стартовать проект
4.1. Структура PMBoK 6. 5 фаз развития проекта
4.1.1. Инициация
4.1.2. Планирование
4.1.3. Исполнение
4.1.4. Мониторинг и Контроль
4.1.5. Закрытие
4.2. Принципы
4.2.1. Принцип “удава”
4.2.2. Принцип “яйца”
4.2.2.1. «Скорлупа яйца» — Устав проекта, который пишется в начале проекта
4.2.2.2. «Внутреннее содержимое яйца»
4.2.2.2.1. содержимое проекта (что собираемся сделать, требования и функционал), сроки, стоимость
4.2.2.2.2. коммуникации, риски, закупки, качество, HR.
4.2.3. Принцип “командности и проактивности”
4.3. Как на старте понять вероятность успеха?
4.3.1. Наличие четкой структуры управления проектом
4.3.2. Ресурсов (финансовых и человеческих)
4.3.3. Вовлеченность заказчика;
4.3.4. Степень проработки содержания проекта (scope);
4.3.5. Соответствие ожиданий заказчика и существующей реальности;
4.3.6. Наличие и уровень знаний и подготовки у руководителя проекта под задачи проекта
4.3.7. Владение бизнес сферой проекта;
4.3.8. Уровень проработки рисков и допущений.
4.4. Почему не стоит идти руководителем проекта в некоторые проекты?
4.4.1. Проект не соответствует вашим целям, как руководителя проекта;
4.4.2. Технология и сфера проекта вам не знакома, а эти знания необходимы;
4.4.3. Цель проекта вам кажется неосуществимой;
4.4.4. На этапе инициации вы видите объективные риски не успешности проекта, которые не воспринимаются заказчиком;
4.4.5. Вам принципиальны организационные моменты (график работы с заказчиком, необходимость командировок и т.д.).
4.5. Заинтересованные стороны и участники проекта
4.5.1. Участники проекта
4.5.1.1. Спонсор
4.5.1.2. Заказчик
4.5.1.2.1. Источники ожиданий заказчика
4.5.1.2.2. Способы формирования ожиданий
4.5.1.3. Пользователи
4.5.1.4. Руководитель проекта
4.5.1.5. Команда проекта
4.5.1.6. Заинтересованные лица
4.5.2. Заинтересованные стороны проекта
4.5.2.1. Спонсор
4.5.2.2. Инвестор
4.5.2.3. Команда
4.5.2.4. Пользователи
4.5.2.5. Конкуренты
4.5.2.6. Регуляторы
4.5.3. Где их искать?
4.5.3.1. Документы
4.5.3.2. Кто просил проект?
4.5.3.3. На кого повлияет проект?
4.5.3.4. Кто может влиять?
4.5.3.5. Авторитет “Сын-студент” :)
4.5.4. Реестр заинтересованных сторон
4.5.4.1. Имя
4.5.4.2. Роль в проекте
4.5.4.3. Должность
4.5.4.4. Непосредственный начальник
4.5.4.5. Контактная информация
4.5.4.6. "Предпочитаемый вид коммуникаций"
4.5.4.7. Главные ожидания
4.5.4.8. Главные требования
4.5.4.9. Влияние на проект
4.5.4.10. Отношение к проекту
4.5.4.11. Интерес к проекту
4.5.4.12. Комментарий
4.5.5. Матрица “Влияние-Интерес”
5. 05 Кто есть в команде. Специальности в ИТ
5.1. Менеджмент
5.1.1. Администратор проекта
5.1.2. Руководитель проекта
5.1.3. Менеджер продукта
5.1.4. Delivery менеджер
5.1.5. Аккаунт-менеджер
5.1.6. Руководитель РМО
5.2. Бизнес-анализ
5.2.1. Бизнес-аналитик
5.2.2. Системный аналитик
5.2.3. Технический писатель
5.2.4. Дата аналитик/ BI аналитик (business intelligence)
5.3. Дизайн
5.3.1. UI дизайнер UX дизайнер
5.4. Разработка
5.4.1. Программист (backend, frontend, full stack, mobile)
5.4.2. Верстальщик
5.4.3. Data base developer
5.4.4. Роль Архитектор
5.4.5. Роль Тимлид
5.5. Тестирование
5.5.1. Мануальный тестировщик
5.5.2. Автоматизатор
5.5.3. Специалист нагрузочного тестирования
5.5.4. Специалист по тестированию безопасности
5.5.5. другое
5.6. Системное администрирование
5.6.1. Системный администратор
5.6.2. DevOps
5.6.3. Специалист по безопасности ПО
5.7. Техническая поддержка
5.7.1. Специалист тех поддержки Уровень 1
5.7.2. Специалист тех поддержки Уровень 2
5.7.3. Специалист тех поддержки Уровень 3
5.7.4. Другое (Канбан, ITSM)
5.8. Маркетинг
5.8.1. SEO специалист
5.8.2. SMM специалист
5.8.3. Контент-менеджер