Коммерческое предложение
Определение RFI, RFP (Proposal)
Определение MSA, SOW
Структура MSA, SOW
Структура КП (RFP Proposal)
Типы контрактов
Фиксированная стоимость (Fixed Price)
Время и стоимость (Time & Material)
Командный контракт (Dedicated Team)
Подходы к выбору контракта и методологии проекта
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 3. Лекция 17-18. Управление интеграцией проектаYana Brodetski
Управление внедрением проекта
Разработка проектного плана (процессы планирования)
Создание и структура плана проекта
Содержание плана проекта
Правила составления технической документации
Написание технического задания
Руководство и управление работами проекта
Мониторинг и контроль работ проекта
Интегрированный контроль изменений проекта
Закрытие проекта или фазы проекта
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Модуль 4. Лекция 19-20. Управление содержанием проектаYana Brodetski
Управление содержанием проекта (Project Scope)
Создание плана управления содержанием проекта
Свойства и функции проекта
План работ для достижения результата.
Сбор требований
Инструменты и методы сбора требований
Что такое бизнес-требования?
Определение функциональных требований
Определение нефункциональных требований
Правила описания требований
Как описывать нефункциональные требования
Структура документа для описания требованиий
Матрица отслеживания требований. (документация)
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Модуль 3. Лекция 17-18. Управление интеграцией проектаYana Brodetski
Управление внедрением проекта
Разработка проектного плана (процессы планирования)
Создание и структура плана проекта
Содержание плана проекта
Правила составления технической документации
Написание технического задания
Руководство и управление работами проекта
Мониторинг и контроль работ проекта
Интегрированный контроль изменений проекта
Закрытие проекта или фазы проекта
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Модуль 4. Лекция 19-20. Управление содержанием проектаYana Brodetski
Управление содержанием проекта (Project Scope)
Создание плана управления содержанием проекта
Свойства и функции проекта
План работ для достижения результата.
Сбор требований
Инструменты и методы сбора требований
Что такое бизнес-требования?
Определение функциональных требований
Определение нефункциональных требований
Правила описания требований
Как описывать нефункциональные требования
Структура документа для описания требованиий
Матрица отслеживания требований. (документация)
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
PMBOK v5'e göre hazırlanmış olan Kapsam Yönetimi eğitimi sunusudur. Sunu ve sunudaki resimler türkçe hazırlanmıştır, sunularda bulunan dokümanlar zip olarak ayrıca yüklenecektir
2. Project management body of knowledgeBhuWan Khadka
ICT Project Management is an IOE syllabus based subject. It provides knowledges about various project environment, management skill, effective and ineffectiveness of project manages, leadership etc.Provided by Project Management Sir of KU.
Processes that organize, manage and lead the project team. Project team is comprised of the people with assigned roles and responsibilities for completing the project.
This presentation about project management tools... From this presentation you will know about different project management tool's features,benefit,good side and bad side .Hope this project will help you to select a good project management tools.
Thank You..
Seminario Metodologias Predictivas vs Agiles. UTN FRBA 16.06.2014Alejandro Gabay
Metodologías de Dirección de Proyectos ¿Predictivas vs. Agiles? ¿PMI® vs. Scrum?
Dictado en la UTN - FRBA, el 16 de Junio de 2014.
El objetivo de esta charla es trazar algunos paralelos entre Agile y los estándares del PMI, partiendo de una revisión de scrum para luego comparar los procesos propuestos por el PMI® en el PMBoK®.
Las organizaciones y las oficinas de proyectos discuten actualmente si las metodología ágiles son o no la solución para la gestión de proyectos de desarrollo de software y también si estas metodologías son aplicables en otros ámbitos fuera del mundo IT.
- Listado de temas
¿Qué es el PMBoK®?
Ciclos de vida y Areas de Conocmiento
El manifiesto agil.
Scrum como marco de trabajo.
Revisión de procesos del PMBoK® comparados con Scrum
PMP Knowledge Areas - PMBOK 6 (PMI) INFOGRAPHICJonathan Donado
PMP Knowledge Areas & Process Group - PMBOK 6.0. knowledge areas
Estudy for the PMP exam by learning and memorizing the 49 process groups in PMBOK
by Jonathan Donado
MBA - IESE
Senior Executive Fellows (SEF) - Harvard University
#PMP #PMI #projectmanagement
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
PMBOK v5'e göre hazırlanmış olan Kapsam Yönetimi eğitimi sunusudur. Sunu ve sunudaki resimler türkçe hazırlanmıştır, sunularda bulunan dokümanlar zip olarak ayrıca yüklenecektir
2. Project management body of knowledgeBhuWan Khadka
ICT Project Management is an IOE syllabus based subject. It provides knowledges about various project environment, management skill, effective and ineffectiveness of project manages, leadership etc.Provided by Project Management Sir of KU.
Processes that organize, manage and lead the project team. Project team is comprised of the people with assigned roles and responsibilities for completing the project.
This presentation about project management tools... From this presentation you will know about different project management tool's features,benefit,good side and bad side .Hope this project will help you to select a good project management tools.
Thank You..
Seminario Metodologias Predictivas vs Agiles. UTN FRBA 16.06.2014Alejandro Gabay
Metodologías de Dirección de Proyectos ¿Predictivas vs. Agiles? ¿PMI® vs. Scrum?
Dictado en la UTN - FRBA, el 16 de Junio de 2014.
El objetivo de esta charla es trazar algunos paralelos entre Agile y los estándares del PMI, partiendo de una revisión de scrum para luego comparar los procesos propuestos por el PMI® en el PMBoK®.
Las organizaciones y las oficinas de proyectos discuten actualmente si las metodología ágiles son o no la solución para la gestión de proyectos de desarrollo de software y también si estas metodologías son aplicables en otros ámbitos fuera del mundo IT.
- Listado de temas
¿Qué es el PMBoK®?
Ciclos de vida y Areas de Conocmiento
El manifiesto agil.
Scrum como marco de trabajo.
Revisión de procesos del PMBoK® comparados con Scrum
PMP Knowledge Areas - PMBOK 6 (PMI) INFOGRAPHICJonathan Donado
PMP Knowledge Areas & Process Group - PMBOK 6.0. knowledge areas
Estudy for the PMP exam by learning and memorizing the 49 process groups in PMBOK
by Jonathan Donado
MBA - IESE
Senior Executive Fellows (SEF) - Harvard University
#PMP #PMI #projectmanagement
Это слайды с вебинара: http://coach.ak-itconsulting.com/2014/04/price-models/
В ходе вебинара участники:
- Узнают о наиболее популяных моделях ценообразования IT-бизнеса (Contacting, Cost +, Time and material, Fixed price)
- Осознаете плюсы и минусы каждой модели
- Определите как модель ценообразования влияет на рядового сотрудника
Нестандартные ситуации клиент-исполнитель. Обходимся малой кровью.AGIMA
Как выстроить взаимоотношения с клиентом и правильно доносить свои идеи.
О чем стоит говорить, а о чем лучше промолчать.
Истинные потребности клиента.
Круговая порука правок.
Как не задушить проект.
Общие правила коммуникации.
Договоренности/правила игры.
Нарушение договоренностей.
Как комментировать правки.
Иван Дубровин, Возможные подходы к контрактованию в AgileScrumTrek
Сравнительный анализ моделей заключения контрактов на Agile-разработку ПО: -"Традиционный" fixed-price и fixed-scope -Time materail -Agile fixed-price плюсы и минусы каждого варианта, рекомендуемый подход к составлению Agile fixed-price контракта.
Это доклад на онлайн-конференции, посвящённой управлению качеством в проектах. Рассматриваются различия подходов к управлению качеством в "гибких" и "водопадных" методологиях и подход "stage-gate" как разумный компромисс между ними.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Модуль 15. Лекция 57-58. Обзоры платформ для различных проектовYana Brodetski
Обзоры платформ для различных
проектов (e-commerce, corporate, forum):
● Prestashop
● Wordpress
● Joomla
● Opencart
● YII
● Bitrix 24
● WIX
● Saas – платформы
● Рекомендации по выбору CMS и фреймворков для
создания сайтов
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Модуль 12. Лекция 51-52. Управление изменениями проектаYana Brodetski
Управление изменениями проекта
● Планирование управления изменениями
на проекте
● Составление плана управления
изменениями
● Разница между изменением и багом
● Методы оценки влияния изменения на
проект
● Утверждение и внесение изменений на
всех этапах проекта
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование реагирования на риски:
● Входы
● Инструменты и методы
● Стратегия реагирования на угрозы
● Стратегия реагирования на возможности
● Стратегия реагирования на потери
● Выходы
● Контроль рисков
● Входы
● Инструменты и методы
● Аудиты и переоценка рисков
● Выходы
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Качественный анализ рисков:
● Входы
● Инструменты и методы
● Формирование матрицы вероятности и воздействия.
● Определение категорий рисков
● Выходы
● Количественный анализ рисков
● Входы
● Инструменты и методы
● Методы сбора и представления информации
● Методы количественного анализа и моделирования рисков
● Выходы
Модуль 11. Лекция 45-46. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование управления рисками:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Идентификация рисков
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 41-42. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Развитие команды проекта:
● Входы
● Инструменты и методы
● Навыки межличностного общения
● Обучение
● Выходы
● Управление командой проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 39-40. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Планирование управление
человеческими ресурсами:
● Входы
● Инструменты и методы
● Выходы
● Набор команды проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана
Модуль 8. Лекция 35-36. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Обеспечение качества
● Входы
● Инструменты и методы
● Диаграммы сходства
● Диаграммы процесса осуществления программы
● Ориентированные графы взаимоотношений
● Древовидные диаграммы
● Матрицы приоритетов
● Диаграммы сети операций
● Матричные диаграммы
● Выходы
● Контроль качества
● Входы
● Методы и инструменты
● Выходы
Модуль 8. Лекция 33-34. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Определение управлением качества
● Качество продукта и проекта
● Принципы качество ISO 9000
● Планирование качества
● Входы
● Методы и инструменты
● Диаграмма причинно-следственных связей
● Блок –схемы
● Листы сбора данных
● Диаграмма Парето
● Гистограммы
● Контрольные карты
● Диаграммы разброса
● Выходы
Модуль 6. Лекция 29-30. Управление сроками проектаYana Brodetski
Разработка расписания
● Анализ сети расписания
● Метод критического пути
● Метод критической цепи
● Методы оптимизации ресурсов
● Методы моделирования: “что если”;имитация
● Опережения и задержки
● Сжатие расписания
● Диаграммы: Ганта, контрольных событий, сети расписания проекта
● Контроль расписания проекта
Модуль 6. Лекция 27-28. Управление сроками проектаYana Brodetski
Управление сроками проекта
● Определение последовательности операций
● Метод диаграмм предшествования (PDM)
● Определение зависимостей
● Опережение и задержки
● Оценка ресурсов операций
● Оценка “Снизу верх”
● Оценка длительности операций
● Аналоговая оценка
● Параметрическая оценка
● Оценка по 3 точкам
● Метод Дельфи
Модуль 6. Лекция 25-26. Управление срока проектаYana Brodetski
Управление сроками проекта
● Планирование управление расписанием
● Входы
● Инструменты и методы
● Выходы
● Определение операций
● Инструменты: планирование методом набегающей волны. ● Выходы:
● Список и параметры операций
● Список контрольных событий
● Расписание согласно методологии
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
2. Лекция 13-14
Управление внедрением проекта
● Коммерческое предложение
● Определение RFI, RFP (Proposal)
● Определение MSA, SOW
● Структура MSA, SOW
● Структура КП (RFP Proposal)
● Типы контрактов
● Фиксированная стоимость (Fixed Price)
● Время и стоимость (Time & Material)
● Командный контракт (Dedicated Team)
● Подходы к выбору контракта и методологии
проекта
3. Определение RFI, RFP
Запрос на информацию( англ. RFI – Requestfor Information)
– документ или письмо, который публикуетили рассылает
организация,заинтересованная в приобретениикаких-либо
товаров или услуг. Цель документа — собрать письменную
информациюо возможностяхразличных поставщиков.Как
правило, запрос предполагает определённый
структурированный форматответа, благодаря чему может
использоватьсядля сравнения информации.
Формат, чаще, табличный.
Содержит в себе:
● Краткое содержание
● Сроки/даты
● Критерии оценки
4. Определение RFI, RFP
Запрос на предложение (англ. Requestfor Proposal)- это
заявка на оказаниеуслуги или создание проекта, которую
создаёт заказчикдля проведения конкурса. В ней находят
отражениете цели, которых хочет достичь заказчик, KPI,
критерии к участникамтендера и ряд других важных
показателей.
Бывает:
● Формальнозапрошенное предложение
● Неформальноезапрошенное предложение
● Незапрашиваемоепредложение
Ответом на RFP обычно становится RFPResponse,( т.е
коммерческое предложение)- еще называют Proposal
Коммерческоепредложение (Proposal)- это документ с
предложением от поставщикауслуг потенциальному клиенту
5. Определение MSA & SOW
PROPOSAL ≠SOW ≠MSA
Договор о предоставленииуслуг (англ. Master Service
Agreement , MSA) - это договор, в котором указаны
обязанностии обязательстваодной стороны с другой
(англ. Statement of Work, SOW) - является формальным
документом, который фиксирует и определяет рабочие
действия,конечные результатыи сроки, которые Компания
должна выполнить привыполнениизадания работы /
проекта для клиента
В IT MSA & SOW вместе - это ваше договорное соглашение
MSA определяет общие условия для совместной работы.
SOW - это дополнение, ориентированное на проект к
соглашению об основной услуге, где указывают проблемы,
которую необходимо решить, расписание,цену
6. Структура MSA
● Общая информация
● Проджет Менеджмент
● Поставки
● Поддержка ( да/нет)
● Оплата/расходы
● Аудиты
● Конфиденциальность
● Разрешениеспора
● Лицензионныегранты
● Сроки прекращения работ
● Гарантии
● Возмещениеущерба
● Страховка
7. Структура SOW
● Вступление
● Описание проекта
● Проектный подход и организация
● Результат поставки: продукт/ПО
● Длительностьи этапы проекта
● Критерии приемки
● Контроль изменений
● Информацияо рейтах/ стоимости
● Отмена или окончаниепроекта
● Уведомленияи контактная информация
● Соглашение
● Аппендикс А: пример формы на запрос об изменениях
● Аппендикс Б: поправки к MSA
8. Структура Proposal
● Титульнаястраница
● Сопроводительноеписьмо
● Резюме для руководства
● Содержание:
● Общая информация
● Проектный подход
● Предположенияи ограничения
● Методы кейсов ( успешныеистории)
● Дополнительныеуслуги
● Конфиденциальность
● Аппендикс
10. Proposal - содержание
● Общая информация
● Корпоративный профиль
● Описание компании и бизнеса
● 1-2 страницы
● Добавляем изображения, структурукомпании, локации
● Бизнес цели
● Подробное описание проблем / бизнес-целей, как вы это
понимаете
● Проектный подход
● Объём проекта
● Реализация проекта (архитектура, серверная часть,
разработка, тестирование и поставка)
● Предлагаемый график (фазы, этапы)
11. Proposal - содержание
● Штат проекта (персонал)
● План коммуникаций
● План поставки
● Модель ценообразования ( модель контракта)
● Предположенияи ограничения
● Предположения - это то, что мы предполагаем может
появится в проекте/продукте
● Ограничения - потенциальные недостатки, которые не
поддаются контролю
Предположения ≠ Ограничения
● Успешные истории
● Клиент, описание проекта, длительность проекта,
технологии, преимущества для клиентов, отзывы клиентов
12. Proposal - содержание
● Дополнительные услуги
● Тренинги
● СМС рассылка
● Маркетинговые исследования
● Продвижение продукта
● Конфиденциальность
● Аппендикс
● Физическая и сетевая инфраструктура
● Награды и сертификаты
● Стандарты качества
● Клиентская база ( логотипы компаний, с которыми
работали)
● Условия оплаты
● Поддержка
13. Типы контрактов в IT аутсорс
Около 80 % ІТ компаний Украины — это сервисные
outsourcing компании. В большинствеслучаев
контрагентами таких компаний являютсязарубежные
заказчики, которые используют международные
модели ценообразования.Взаимоотношениямежду
сторонами оформляютсяв виде outsourcing contracts, у
каждого из которых свои условия применимости:
● Фиксированная стоимость(Fixed Price)
● “Времяи материалы”( Time & Material)
● Аутстаффинг контракт ( DedicatedTeam)
14. Фиксированная стоимость (Fixed Price)
Fixed Price Contract – это контракт, в котором
подразумевается фиксированная суммаоплаты за
определенный объём работ.
Идеальноподходит для малых и средних
проектов, где требования,
спецификациии
графики могут быть
четко определены
до начала
разработки проекта.
15. Фиксированная стоимость (Fixed Price)
Основные этапы работ по этой модели:
● Заказчик отправляетзапроси требованияк проекту.
● Исполнительи заказчик обсуждаютвсе детали.
● Исполнительотправляеткоммерческоепредложение,
график платежей и расписаниевыполненияработ.
● Обе стороны договариваютсяи согласуютвсе
моменты,подписываетсядоговор.
● Исполнительпредоставляетполностью
реализованноерешение.
● Клиент одобряетпроект.
Ключевыемоментыданного варианта сотрудничества:
● Фиксированныйбюджет
● Постоянныйобъемпроекта
● Установленный временнойинтервал
● Возможныйкомпромисспокачеству
16. Фиксированная стоимость (Fixed Price)
“+ ” модели:
● подходит для малых и средних проектов;
● четкие требованияи четко определенные цели и этапы;
● низкий риск для заказчиков, поскольку риск успешного
завершения проекта лежит на исполнителе;
● требуется относительнонебольшой контроль заказчика;
● фиксированная цена,основанная наоценке проекта до
начала реализации проекта;
● заверения в том, что проект будет завершен в рамках
согласованногобюджета и сроков;
● исполнитель оченьмотивирован,чтобы быть
эффективными продуктивным.
17. Фиксированная стоимость (Fixed Price)
“- ” модели:
● требуетсявремяи ресурсы дляполногои экспертногоопределения
требований,результатови критериевприемлемости;
● отсутствиеконтролянад процессом реализациипроекта,участия
персоналаи материальныхзатрат;
● разработчикиредкообщаютсянапрямуюс заказчиками и не могут
обсуждатькаждуюпроблему,а прииспользовании Waterfall и после
утверждениякаждойстадииразработки - внесение изменений
является очень проблемным
● возможны проблемыс качеством конечного продукта,поскольку
проектуправляетсятолькоисполнителем;
● заказчик должен платитьотдельноза любые существенные
отклоненияот первоначальныхтребованийпроекта;
● низкий уровень знаний после реализациипроекта,поскольку
командаразработчиковможетразойтись по его завершению.
18. Время и Материалы (Time & Material)
Названиеэтой модели можно перевести, как «оплата по
факту»,то есть вы платите подрядчику за конечный
результат,исходя из трудозатрат исполнителя.
При этом вы оплачиваете не объем выполненнойработы, а
человеко-часы, потраченные командой на получение
нужного вам результата.
Эта модель оптимальна
для тех случаев,
когда не удается с
ходу определить
объем работы и
сроки ее выполнения.
19. Время и Материалы (Time & Material)
Для какихпроектовподходит данныйтип
договоров:
● Когда требования не являются точными или спецификациине могут быть
четко определены;
● Когда на первых этапах проект все еще является «сырым», и нет
достаточных данных для правильной оценки конечной стоимости;
● Когда клиент имеет постоянный поток задач или улучшений, но они
разбросаны во времени и не могут быть предсказаны заранее;
● Когда объем проекта неизвестен или реализация распространяется в
течение нескольких месяцев или даже лет;
● Когда клиент требует высокого уровня гибкости или запросов на
изменение, часто появляются в процессе разработки;
● Когда клиент хочет более прямого контроля над процессом или
предоставляет определенные ресурсы, которые могут влиять на
реализацию проекта;
● Когда проект связан с развивающимися рынками,новыми технологиями
или непроверенными объектами.
20. Время и Материалы (Time & Material)
“+” модели:
● Заказчик платит за час независимоот продолжительностипроектаразработки
программногообеспечения
● Изменяющиеся требованиялегко влияют и корректируютрабочийпроцесс
исполнителя
● Клиент получает высококачественныйи проверенныйпродукт.
“-” модели:
● риск потериприбыли разработчикомвследствие
установленияцены ниже средней рыночной
ставки.
● некоторыеклиенты могут запрашивать
скидки по почасовойставке исполнителя.
● соблазн подрядчика увеличения
расчетноговремени разработкипрограммного обеспечения
● отсутствие строго определенныхсроковили
гарантийв завершениипроектаи бюджетная
смета может отличаться от конечной стоимости и менее контролироваться
21. Dedicated Team Model
Dedicated Team — это бизнес-модель,в которой обе стороны
взаимносоглашаются с рабочей нагрузкой и требованиямк
проекту с указаниемнеобходимого количества времени, а
аутсорсинговаякомпания предоставляет IT-специалистов,
отвечающихтребованиямзаказчика, которые полностью
концентрируются на его проектах.
Заказчик имеет полный
управленческийконтроль
над проектом и командой,
а исполнитель выполняет
функциюрекрутера
персонала и
административной
поддержки.
22. Dedicated Team Model
Сотрудничество по данной модели можно разделить на несколько этапов:
● Клиент определяет количество и набор навыков потенциальных сотрудников;
● Исполнитель ищет IT-специалистов с соответствующими знаниями и
квалификацией;
● Разработчики собираются в команду и начинают работу;
● Они постоянно работают только для проекта клиента, узнают его спецификуи
видят общую идею каждой отдельной задачи;
● Аутсорсинговая компания становится
первоначальным посредником между новой
командой и заказчиком,но со временем эта
Команда становится все более приверженной
его проекту и компании клиента в целом.
Они разделяют видение компании и очень
заинтересованы в достижении бизнес-целей
компании.
23. Dedicated Team Model
“+” модели:
● полныйконтроль над выбором, мотивацией и управлением выделеннымичленамикоманды;
● повседневная связь и управлениес использованием веб-инструментов;
● гибкий подход, полностью предсказуемыезатраты ибюджетный контроль;
● рабочая нагрузка и объем не фиксированы, и запросы на изменение могутбыть сделаны в любой
момент;
● лояльная команда внешнего персонала, с которой клиент может устанавливать те же рабочие
отношения и правила, что и с основным персоналом;
● когда отдельныечлены команды работаютнекоторое время с клиентом, они имеют глубокое
понимание ожиданий клиента и четко видят цель для достижения успеха;
● сплоченность и стабильность команды; передачазнаний о проекте и знакомство с бизнесом клиента
“-” модели:
● низкая эффективность для краткосрочныхпроектов;
● дороже модели Time & Material и Fixed Price;
● выбор членов команды может занять некоторое время и отложить начало проекта, в то время как во
время разработки прииспользовании модели Time & Material работа может начаться в течение
ближайшего времени;
● у выделенныхчленов команды меньше возможностей изучать новые методики вне своей областив
проекте;
● клиент должен играть активную роль в общении и переговорахи инвестировать много времени в
управление.
25. Выбор методологии : Бюджет
Бюджет - это отличный инструмент,который поможет вам
определить, как вы должны управлятьсвоим программным
проектом. Например, если ваш бюджет позволяет просто
реализоватьфункцию,и вам необходимо обратитьваше
вниманиена определение приоритетов
26. Выбор методологии : Сроки
Времяимеет значение. Гибкиевременные ограничения
означают гибкие подходы к управлениюпроектами. И
наоборот, если у вас установлены фиксированныесроки,
лучше использоватьболее традиционныеподходы.
27. Выбор методологии : Контракт
Контракт с фиксированной ценой предполагает методологию водопада или RUP,
поддерживаемую фиксированными требованиями и уточненными критериями
приемлемости. Выделенный командный контракт (dedicated team)
предназначен для более сложных случаев. Вы должны подумать о координации
работы членов вашей команды. Вы должны оказывать положительное влияние
на их мотивацию и ежедневную производительность.