На конкретном примере рассматривается: как выбрать момент для внедрения процессов, как показать пользу от внедрения процесса, как выбрать авторов и формат описания, и, самое главное - как проконтролировать внедрение процесса.
Презентация показывает значимость процесса Инициирования Проекта (Project Initiation), а также его основного артефакта - Устава Проекта (Project Charter). Устав Проекта описывает Правила взаимодействия с заказчиком и решает многие проблемы на ранних стадиях. Но к сожалению Устав не всегда делают качественно, или вообще не делают, что и приводит ко множеству разочарований, взаимных претензий и т.п.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Презентация показывает значимость процесса Инициирования Проекта (Project Initiation), а также его основного артефакта - Устава Проекта (Project Charter). Устав Проекта описывает Правила взаимодействия с заказчиком и решает многие проблемы на ранних стадиях. Но к сожалению Устав не всегда делают качественно, или вообще не делают, что и приводит ко множеству разочарований, взаимных претензий и т.п.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Открытый курс, занятие 3 часть 2 - PMBOK® за 2,5 часаIvan Selikhovkin
Открытый (бесплатный) курс по управлению проектами.
Третье занятие в двух частях - посвященное быстрому знакомству с PMBOK® 5th edition. Разбираются все процессы и некоторые их связи для областей знаний: управление качеством, управление HR, управление коммуникациями, управление рисками, управление закупками, управление заинтересованными сторонами. Также сводятся воедино алгоритмы управления проектом.
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Презентация делалась в 2006 году, но может быть еще актуальна для всех, кто связан с тематикой CRM (Customer Relationship Management).
Я рассказывал о том, как защитить проект перед заказчиком, как объяснить руководителю организации зачем ему нужна система CRM
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
TPI Next®: оптимизируем процессы тестирования по-взрослому
Думали ли вы когда-либо о том, к какому уровню зрелости принадлежит ваш процесс тестирования? Или, например, как ответить на вопрос о том, насколько эффективно работает ваша команда тестировщиков? Здесь легче всего дать субъективный ответ, и, например, сказать: мы работаем хорошо, у нас все автоматизировано и мы находим много дефектов.
Однако нельзя расценивать подобный ответ, как корректный. Оценить зрелость и эффективность процесса тестирования по-настоящему можно лишь используя ту или иную модель оценки, каждая из которых имеет массу своих особенностей и не всегда применима в большинстве случаев.
TPI® Next – модель оценки зрелости процессов тестирования в масштабах компании или отдельного проекта. Она помогает понять какими сильными и слабыми сторонами обладает ваш процесс и дает представление о том, в каком направлении двигаться для его оптимизации.
TPI® Next разбивает процесс тестирования на ключевые подобласти, каждая из которых подвергается анализу и получает свою оценку зрелости – от начальной до оптимальной. Делается это на основе четко описанных критериев для той или иной области, что дает возможность дать конкретный ответ на вопрос о том, чего не хватает процессу для перехода на следующую ступень зрелости.
Используя подход, описанный в TPI® Next, я провел оценку зрелости процесса тестирования в нескольких проектах компании в разные периоды их развития. Подвергнув полученные данные анализу, я смог определить каких практик и подходов не хватает той или иной команде для того, чтобы считать свои проекты более зрелыми и эффективными.
Использовав получе
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Оценка эффективности от внедрения и использования методологии и инструменталь...Alexander Novichkov
http://cmcons.com
http://anovichkov.msk.ru
Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational.
Практика внедрения и взаимодействия с заказчиком.
15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Открытый курс, занятие 3 часть 2 - PMBOK® за 2,5 часаIvan Selikhovkin
Открытый (бесплатный) курс по управлению проектами.
Третье занятие в двух частях - посвященное быстрому знакомству с PMBOK® 5th edition. Разбираются все процессы и некоторые их связи для областей знаний: управление качеством, управление HR, управление коммуникациями, управление рисками, управление закупками, управление заинтересованными сторонами. Также сводятся воедино алгоритмы управления проектом.
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Презентация делалась в 2006 году, но может быть еще актуальна для всех, кто связан с тематикой CRM (Customer Relationship Management).
Я рассказывал о том, как защитить проект перед заказчиком, как объяснить руководителю организации зачем ему нужна система CRM
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
TPI Next®: оптимизируем процессы тестирования по-взрослому
Думали ли вы когда-либо о том, к какому уровню зрелости принадлежит ваш процесс тестирования? Или, например, как ответить на вопрос о том, насколько эффективно работает ваша команда тестировщиков? Здесь легче всего дать субъективный ответ, и, например, сказать: мы работаем хорошо, у нас все автоматизировано и мы находим много дефектов.
Однако нельзя расценивать подобный ответ, как корректный. Оценить зрелость и эффективность процесса тестирования по-настоящему можно лишь используя ту или иную модель оценки, каждая из которых имеет массу своих особенностей и не всегда применима в большинстве случаев.
TPI® Next – модель оценки зрелости процессов тестирования в масштабах компании или отдельного проекта. Она помогает понять какими сильными и слабыми сторонами обладает ваш процесс и дает представление о том, в каком направлении двигаться для его оптимизации.
TPI® Next разбивает процесс тестирования на ключевые подобласти, каждая из которых подвергается анализу и получает свою оценку зрелости – от начальной до оптимальной. Делается это на основе четко описанных критериев для той или иной области, что дает возможность дать конкретный ответ на вопрос о том, чего не хватает процессу для перехода на следующую ступень зрелости.
Используя подход, описанный в TPI® Next, я провел оценку зрелости процесса тестирования в нескольких проектах компании в разные периоды их развития. Подвергнув полученные данные анализу, я смог определить каких практик и подходов не хватает той или иной команде для того, чтобы считать свои проекты более зрелыми и эффективными.
Использовав получе
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Оценка эффективности от внедрения и использования методологии и инструменталь...Alexander Novichkov
http://cmcons.com
http://anovichkov.msk.ru
Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational.
Практика внедрения и взаимодействия с заказчиком.
15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Формирование и управление командой проекта
• Выбор партнера. Ключевые роли и люди на Проекте;
• Различия в подходах к внедрению систем;
• Мотивация персонала на достижение результата и преодоление сопротивления внутри компании.
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html
Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Презентация с доклада на SPC UA 2012. Видео тут - http://sharepoint-channel.com/stanislav-vyshhepan-iskusstvo-upravleniya-sharepoint-kak-poluchit-maksimalnuyu-vygodu-dlya-biznesa-videozapis-doklada-na-spcua-2012
Это первый вебинар блока "Разбор ситуаций". Весь блок направлен на то, чтобы увидеть конкретную ситуацию со стороны, в контексте всего проекта, чтобы лучше понимать возможные действия в ней.
На этом вебинаре мы разберем ситуацию с изменениями в проекте, инициатором которых выступает заказчик. Мы посмотрим на ситуацию глазами менеджера проекта и увидим, где его зоны влияния в ней.
Строим процессы управления собственными руками. Советы начинающимCleverics
1. Чем отличается самостоятельное внедрение от работы с внешним подрядчиком
2. Внедрение процесса – о чем не забыть, кроме автоматизации
3. Риски проекта по внедрению процесса
4. Есть ли жизнь после внедрения?
This two days course provides classic approaches for Planning and Risk Management. It is based on both easily applicable practical approaches and PMBOK guidelines. Major ideas are how reasonable classic can help things done on schedule, on budget.
Corporate consulting for fast growing, transforming IT companies which are looking for better operations efficiency, better business processes, building Quality Management System (QMS)
Мастер класс был проведен на конференции PMCon #4, Харьков, 2017.
Мы начнем мастер-класс с разминки - обсудим кто какие метрики применял, чем они были полезны или бесполезны. Затем рассмотрим принципиальный вопрос - зачем нужны метрики и какова их роль в ИТ-бизнесе. Потом, на большом практическом занятии узнаем как правильно увязывать процессы и проблемы реального мира с метриками, и, соответственно, как разумный подбор метрик может помочь их решить. Завершим мастер-класс обсуждением условий, при которых применение метрик имеет смысл.
This Overview represents such important and complicated at the first glance discipline as Software Measurements which is comprehensively covered in the training.
The following topics are covered in simple and logical thought chanes:
- process and product quality
- team and personal performance
- HR and business metrics
- raw data to executive dashboard evolution and vice versa
- size model
- business circumstances
- answers to many whats, whys, hows
- provides theoretical background
- and practice, practice, practice...
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
2. текст
2
О себе
CTO в Team International, LLC.
www.teaminternational.com.
• В IT с 1996 года. Работал по нескольким IT
специальностям. С 2001 – управление проектами,
процессами, операционной деятельностью
Веду проект ИТ Тюнинг, www.it-tuning.com.
Настройка операционной деятельности:
• Оптимизация процессов, управление проектами,
оценка персонала, непрерывность бизнеса,
кроссфункциональное взаимодействие
Сергей Поволяшко
Лидирующее участие во
внедрении CMMI L3
Project Management
Professional (PMP), PMI
ISO 27001 Expert
www.it-tuning.com
5. www.it-tuning.com
Проблемы
Проблемы отсутствия процесса?
Неясно
• Кто что делает и за что отвечает
• Кто кому чего должен
• Какой будет результат
• Какое будет качество
• Какие инженерные практики применяются
• Как управляется проект
• Что такое хорошо (заказчик vs исполнитель)
7. www.it-tuning.com
Решения
Что мешало?
• Сопротивление изменениям
• Процесс – это бюрократия
• Не лезьте не в свое дело
• Нехватка времени
• Взаимное недопонимание
• Непонимание ценности процессов
• Нехватка процессного опыта
8. www.it-tuning.com
Опыт внедрения
• Процесс «Инициирование Проекта»
• Действующие лица
• Sales
• Топ менеджмент
• ПМ-ы
• Акаунт менеджеры
• Пытались внедрить 1.5 – 2 года – безуспешно
• Внедрили за 3-4 месяца
16. www.it-tuning.com
Нужен правильный МОМЕНТ
Внедрили за 3-4 месяца
Теория эволюции:
постепенное осознание ценности процессов
Теория большого взрыва:
Cерьезные и быстрые проблемы с
заказчиками.
Все согласны на все, даже на процесс
17. www.it-tuning.com
Большой взрыв – проблемы сзаказчиками
• Качество работы – у каждого свое «хорошо»
• Инженерные практики – перечень и применение разные
• Управление проектом –договоренность иреальность разные
• Коммуникации –«нас не слышат» с обеих сторон
• Саботаж со стороны команды заказчика
• Проблемы с квалификацией членов команды с обеих сторон
• Нехватка документации инежелание ее делать
• Отсутствие установленных процессов
• Непонимание принципов методологий и ихприменимости
• Слишком много решателей
Внедрили за 3-4 месяца
20. www.it-tuning.com
Что было не так?
• Не были описаны Правила Игры с заказчиком, т.е. КАК
мы работаем
Внедрили за 3-4 месяца
21. www.it-tuning.com
Что было не так?
• Не были описаны Правила Игры с заказчиком, т.е. КАК
мы работаем
Предложено решение
• Внедрить процесс Инициирования Проекта
• Основной результат – Устав Проекта
Внедрили за 3-4 месяца
23. www.it-tuning.com
Формат описания
Визуальный (по возможности)
• Блок схема
• Линейные шаги
Последовательность шагов процесса
Перечень и формат результатов
Четкие ответственности
Напр. модель RACI
28. www.it-tuning.com
Итоги
1. Выбрать МОМЕНТ
2. Определить ДЕЙСТВУЮЩИХ лиц
3. ДОХОДЧИВО донести проблемы и РЕШЕНИЯ
4. Выбрать АВТОРОВ и написать ПРОЦЕСС
5. УТВЕРДИТЬ Процесс
6. Проконтролировать ВНЕДРЕНИЕ
7. УЛУЧШАТЬ Процесс