Отзыв на книгу ЛОУРЕНС ЛИЧ / LAWRENCE P. LEACH “Вовремя и в рамках бюджета: Управление проектами по методу критической цепи (Critical Chain Project Management)”
Рецензия на книгу Джеффа Сазерленда "SCRUM. Революционный метод управления пр...Valerii Kosenko
О чем книга?
О более широком позиционировании Scrum как “методологии управления проектами, бизнесом” и даже “жизненным состоянием” (с.55), и “решением серьезных проблем человечества” (с.231) взамен существующего позиционирования как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне постоянной критики каскадной модели и диаграммы Ганта.
О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56).
Об управлении противоположном “Макиавелли” (с.182)
И вы не поверите - про бирюзовые организации, такие как Morning Star (с.257)
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Рецензия на книгу Джеффа Сазерленда "SCRUM. Революционный метод управления пр...Valerii Kosenko
О чем книга?
О более широком позиционировании Scrum как “методологии управления проектами, бизнесом” и даже “жизненным состоянием” (с.55), и “решением серьезных проблем человечества” (с.231) взамен существующего позиционирования как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне постоянной критики каскадной модели и диаграммы Ганта.
О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56).
Об управлении противоположном “Макиавелли” (с.182)
И вы не поверите - про бирюзовые организации, такие как Morning Star (с.257)
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Понятие юзабилити
● Работа с 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 и фреймворков для
создания сайтов
Открытый курс, занятие 3 часть 2 - PMBOK® за 2,5 часаIvan Selikhovkin
Открытый (бесплатный) курс по управлению проектами.
Третье занятие в двух частях - посвященное быстрому знакомству с PMBOK® 5th edition. Разбираются все процессы и некоторые их связи для областей знаний: управление качеством, управление HR, управление коммуникациями, управление рисками, управление закупками, управление заинтересованными сторонами. Также сводятся воедино алгоритмы управления проектом.
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Понятие юзабилити
● Работа с 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 и фреймворков для
создания сайтов
Открытый курс, занятие 3 часть 2 - PMBOK® за 2,5 часаIvan Selikhovkin
Открытый (бесплатный) курс по управлению проектами.
Третье занятие в двух частях - посвященное быстрому знакомству с PMBOK® 5th edition. Разбираются все процессы и некоторые их связи для областей знаний: управление качеством, управление HR, управление коммуникациями, управление рисками, управление закупками, управление заинтересованными сторонами. Также сводятся воедино алгоритмы управления проектом.
Многофакторная оптимизация VS Стратегия голубого океана - Результаты исследов...Valerii Kosenko
Пример исследования по определение факторов конкуренции, которые могут быть использованы для разработки стратегической канвы голубого океана на примере офисной мебели и теплотехнического оборудования.
Развитие торговой сети в регионах: как оценить потенциал нового рынка?Valerii Kosenko
Презентация доклада "Развитие торговой сети в регионах: как оценить потенциал нового рынка? Оценка эффективности вложений в маркетинг" в ноябре 2005 года
Презентация открытой программы обучения по категорийному менеджменту.
Цена файла Power Point - 100 EUR.
Оплата на карту.
Формулировка: пополнение карты.
Функции аналитика в Agile-команде, как его "встроить", нужен ли он, как быть с кросс-функциональностью. Презентация - см. http://www.slideshare.net/biBIGine/agile-sef09?type=presentation
Project Management (FOZZY, COMFY, STB TV channel, PMO setup, and management, Agile, Scrum, Waterfall, Hybrid), Business Process Management (DTEK, VAD, IDEF0, CFFC, BPMN 2.0, BPMS implementation), Republic of Kazakhstan (Project Management Consulting Services), two business trips to China, teach the project and process management, SaaS pet project SDTEST®.
G&T Power – сюжетная тестовая игра, которая измеряет четыре лидерских soft-компетенции:
1. системное мышление,
2. адаптивность,
3. способность достигать результат,
4. эффективное взаимодействие с другими людьми.
"Встречают по одежке, а провожают по уму".
Становится правилом у работодателей при приеме на работу менеджеров высокого уровня требовать у них видение их деятельности. Чтобы заметить результаты работы ТОП-менеджера нужно от 3-х до 20 месяцев. Владельцы бизнеса справедливо хотят видеть кого же они нанимают управлять своим детищем в самом начале, а не по истечении 3-х или более месяцев.
Я имею результативный (100%) опыт разработки самопрезентаций для ТОП-менеджеров при приеме их на работу.
Самопрезентация для кандидата на должность руководителя VIP Car Bentley.
Обратите внимание на прогноз, сделанный в 2004 году, и фактические данные продаж за 2005-2006 годы.
Презентация мастер-класса "Как научиться управлять правами и полномочиями"
Critical Chain Project Management
1.
Управление проектами в России
набирает все большую популярность и
поддержку на государственном уровне.
В ответ на запросы рынка в издательстве
“Альпина паблишер” издана книга ЛОУРЕНС
ЛИЧ / LAWRENCE P. LEACH “Вовремя и в
рамках бюджета: Управление проектами по
методу критической цепи (Critical Chain Project
Management)”.
Мы, Валерий Косенко и Денис Иванов,
хотим поделиться с вами, уважаемые коллеги,
своими впечатлениями от прочтения и анализа
данной книги.
“О чем книга?”
“Стоит ли ее читать?”
“Что запомнилось?”
О чем книга?
О “принципах ССРМ вкупе с некоторыми сопутствующими положениями теории
ограничения систем, TQM, шести сигм, бережливого производства, гибких методологий
Agile и РМВОК” (стр.307).
О теории ограничения систем (ТОС) Э.Голдратта применительно к теории и
практике управления проектами. А если быть точнее о переносе теоретических
предположений и практических достижений ТОС в производственных системах на
систему управления проектами.
Как пишет автор на стр.218 “Главная идея, заимствованная из производства,
состоит в том, что чем дальше от ограничения находится ресурс, тем большую
дополнительную мощность и/или буфер он должен иметь, чтобы не повлиять на общее
время выполнения работ.”
Стоит ли ее читать?
Если Вы менеджер проекта или работаете в сфере управления проектами, то
читайте, как минимум по 2м причинам:
в книге перечислены многие исходные предпосылки внедрения / использования
проектного управления в организации “вообще”, а не только по методу критической цепи,
метод критической цепи уже используется в проектном управлении, и о нем как
минимум нужно иметь представление.
Но смею предположить (это мое личное мнение), что есть условия при которых
этот метод не принесет Вам практической пользы. Вот они:
1
2. Начните чтение с 6й главы “Создание плана отдельного проекта по методу
критической цепи”, 6.1. Процесс (стр.184):
“1. Найдите критическую цепь.
1.1.....
1.2....
1.3....
1.4.Устраните конфликт ресурсов, запланировав выполнение некоторых операций на
более ранний срок.
2. Найдите способ снизить влияние критической цепи.
3. Подчините все операции, цепочки и ресурсы нуждам критической цепи.
4. Сократите общую длительность проекта, используя дополнительные ресурсы на
определенных участках, чтобы снять конфликты.
5. Возвращайтесь на этап 1, не позволяя инерционности мышления стать ограничением.”
Теперь внимание, задаем вопрос в стиле мыслительных процессов ТОС:
Вот как читается эта схема:
“ЕСЛИ проект имеет фиксированную/ административную дату окончания проекта (не
подлежит переносу на более поздний срок),
2
3. И дата начала проекта ≠ дате начала планирования графика проекта по методу ССРМ
(у вас есть время на планирование),
И при выполнении п.1.4. (перенос старта на более ранние сроки) планирование вышло
(дата начала проекта) за текущую дату,
И дополнительных ресурсов нет (п.4. нет возможности реализовать),
ТО планирование по методу ССРМ для отдельного проекта нельзя выполнить? (выше
перечислены его ограничения?).
Затем перейдите к чтению 7ой главы, где описано как создать сводный план
нескольких проектов методом ССРМ (стр.218 220).
Задаем вопрос в стиле мыслительных процессов ТОС:
Вот как читается эта схема:
“ЕСЛИ не определена приоритетность проектов,
И все ресурсы, кроме ограничения, НЕ имеют избыточной мощности (т.е. загружены на
100%, а на 100% должен быть загружен только ресурсограничение!),
И ресурс, предшествующий ограничению, НЕ превосходит его по мощности (т.е. загружен
на 100%),
И ресурсы, следующие за ограничением, НЕ превосходят его по мощности (т.е.
загружены на 100%),
3
4. И до самого завершения проекта(ов) работы НЕ идут со скоростью ограничения,
ТО планирование по методу ССРМ для нескольких проектов нельзя выполнить? (выше
перечислены его ограничения?)
Эти вопросы будут Вам полезны для самоанализа системы управления в своих
организациях, т.к. дают информацию о возможности внедрения системы управления
проектами “вообще”, а не только по методу критической цепи.
Что запомнилось?
Книга во многих местах очень спорная и указанные в ней рекомендации работают
только в определенном типе культуры или парадигме. Об этом автор недвусмысленно
говорит:
на стр.265266: “Я предпочитаю рассказывать о моделях поведения,
необходимых для успешной работы ССРМ. Руководство многих компаний ошибочно
полагает, что главное — закупить специальное программное обеспечение. Нет, суть не в
этом. Главное, что предстоит сделать, — это изменить привычный стиль поведения
людей.”
в разделе 9.2.5. В ПЛЕНУ ПАРАДИГМЫ (стр.286288).
Абсолютно согласны здесь с автором и готовы это подтвердить своими
исследованиями по Спиральной динамике на ресурсе www.sdtest.ru.
Стр.102 "На своих занятиях в PMI я устраиваю неофициальное исследование. Я
спрашиваю, сколько студентов в планах своих проектов указывают загрузку по ресурсам
(то есть обозначают, какие ресурсы назначены на выполнение каких операций, как на рис.
3.2). Обычно это от половины до двух третей слушателей. Затем я спрашиваю, кто из них
проводит выравнивание ресурсов. Обычно таковых около 5%. Получается, что примерно
95% проектов уже с самого начала обречены на провал. Не забывайте, что я опрашивал
элиту управления проектами, большинство из них — сертифицированные
профессионалы РМР."
Этот факт говорит о том, то так называемая "элита" не использует технические
возможности Microsoft Project, а все что написано в этом абзаце по сути описание Task
management, где математические расчеты по формуле Д=Т/Е заменены экспертными
оценками. В момент издания английского варианта книги издательством Artech House,
Inc., в 2005, в августе 2002 года, уже вышла книга Tim Pyron "Special Edition Using
Microsoft Project 2002", в которой описано как указывать загрузку по ресурсам."
В продолжении использования MS Project на стр.116 переходим по ссылке
http://www.advancedprojects.com и читаем в Updates: CCPM+, our project management
software addin to Microsoft Project now includes the Project Chain View. The Project Chain
View enables project teams to know exactly where to focus work to keep the project on
schedule, and to plan ahead for schedule improvement if and when needed. This tool turns
project management around, from looking through the rear view mirror with variance
4
5. explanations to driving the project forward by looking through the windshield to focus on what
matters most.
Утверждение на стр. 170 сильно удивляет: "В то время как в традиционном
управлении проектами указание ресурсов (исполнителей) в расписании проекта лишь
рекомендованная практика, в управлении методом критической цепи это — обязательное
требование." Т.е. PMI в PMBOK "лишь рекомендует указывать ресурсы"?
А вот как на стр.178 автор объясняет как завершить проект в "рамках бюджета"
(фраза из заголовка книги): "большинство менеджеров пакетов работ научены тратить все
деньги, выделенные на их работы, чтобы, не дай бог, в следующий раз не дали меньшую
сумму. Размер буфера на расходы будет напрямую зависеть от вашей способности
переломить этот образ мыслей." Переломить образ мыслей?!
Стр.190192, раздел 6.3.2. СЛОЖНЫЙ ПРИМЕР "На рис. 6.11 работы
представлены в виде диаграммы Гантта, составленной средствами MS Project."
Перенесемся на стр.184 п. "1.1.1. Постройте логическую последовательность операций со
связями типа «поздний финиш»." ВНИМАНИЕ! На всех рисунках (6.11. 6.13.) показан
график проекта, построенный методом "ранний старт", а не «поздний финиш». Кому
интересно лично поработать с "живой моделью" в MS Project обращайтесь, получите.
В 8й главе рассказывается об отчетности и показаны некоторые примеры отчетов
(стр.244245). Со своей стороны хотим показать вам как настроить и использовать
некоторые отчеты по ССРМ в MS Project, которые Вы найдете в Приложении №1.
Стр.294 “В ССРМ используется упрощенный подход к управлению рисками,
поскольку под рисками понимаются только особые причины вариабельности.” Странным
выглядит вот такое предположение на стр.296 “Если вам кажется, что по вашему —
относительно небольшому — проекту одних только максимально вероятных и ощутимых
рисков намного больше, чем 10, стоит задуматься, а надо ли вообще за такой проект
браться.” без рассмотрения термина “риск аппетит”.
Общее впечатление от книги она написана для поклонников ТОС, а не для
сертифицированных менеджеров проектов (PMI, PRINCE2, IPMA….) и специалистов по
календарносетевому планированию, которые профессионально работают с
профессиональным программным обеспечением по управлению проектами. В
Приложении №2 читатели найдут ссылки на материалы о том, как эту же тему
раскрывают на русскоговорящем пространстве сертифицированные ТОС специалисты.
5
6. ПРИЛОЖЕНИЕ № 1
Как настроить и использовать отчеты по ССРМ в MS Project
Вариант № 1.
Ввод задач с полной длительностью без ресурсов для визуализации буфера
проекта на Диаграмме Гантта.
1. Установить связь ФинишСтарт между "Окончание проекта" и "Зеленый буфер" во
время планирования (до сохранения базового плана).
2. Сохранить базовый план проекта:
2.1. дата Базового окончания красного буфера станет датой Базового окончания
всего проекта и будет отображаться в строке 0 (ноль),
2.2. это даст возможность отслеживать степень использования проектного буфера.
3. Перевести режим задачи буферов в "Ручной" после завершения планирования (до
сохранения базового плана).
3.1. После перевода задач буферов в режим "Ручной" буфер не будет двигаться
по временной шкале.
4. Удалить базовый план с задач проектного буфера.
5. Удалить связь ФинишСтарт между "Окончание проекта" и "Зеленый буфер" Веха
(Окончание проекта) будет "двигаться над буфером" в случае отклонения от плана. Что
удобно отразить на одном рисунке временной шкалы.
6
7. ВНИМАНИЕ!
После удаления связи ФинишСтарт между "Окончание проекта" и "Зеленый буфер"
может измениться Критический путь, т.к. у всех задач проекта появится свободный
временной резерв величиною в буфер.
5. Ввести для каждого буфера % завершения = 100%, чтобы они не “портили” показатель
% завершения.
Вариант № 2.
Ввод задач с НЕ полной длительностью без ресурсов для визуализации
ресурсного буфера на Диаграмме Гантта.
Как видно на рисунке Длительность рабочих дней = 2, Календарная длительность = 24.
Несмотря на разрыв в рисунке на Диаграмме Гантта, на временной шкале буфер
выглядит цельным отрезком=24 календарным дням.
7