Орест Татомир “Ефективна розумова праця і її вплив на строки проектів” Kyiv Project Management Day (28.10.2017)
•Download as PPTX, PDF•
0 likes•134 views
Kyiv Project Management Day (28.10.2017) Орест Татомир “Ефективна розумова праця і її вплив на строки проектів”
Recommended
Recommended
More Related Content
More from Lviv Startup Club
More from Lviv Startup Club (20)
Орест Татомир “Ефективна розумова праця і її вплив на строки проектів” Kyiv Project Management Day (28.10.2017)
- 1. 1CONFIDENTIAL Mind Work Simple rules to follow September 16, 2017
- 2. 2CONFIDENTIAL About myself • Business Analyst @ EPAM • Ментор для BA • Certified Scrum Product Owner (2014) • 9 лет в ІТ • 7 как BA
- 3. 3CONFIDENTIAL Project issues Глобальна статистика за останні 30 років: • 60% проектів закінчуєть з певним типом проблеми ( не вчасно, понад бюджет, не в тому обємі) http://www.sei.cmu.edu
- 4. 4CONFIDENTIAL • Изначальные сроки не соблюдаются • Бюджеты превышаются • Слишком много изменений по ходу проекта • Слишком много работы нужно переделывать • Слишком часто нет обещанных ресурсов • Необходимые инструменты и расходные материалы недоступны • Постоянная борьба за приоритеты между проектами Что же обычно идет не так?
- 5. 5CONFIDENTIAL • Оценка это всегда вероятность • Сумма оценок стремится к нормальному распределению • В оценки закладываются всевозможные риски Оценка Безопасная оценка (80 – 90% уверенности в завершении задачи в срок Время Вероятность Начало работы Агрессивная оценка Наиболее вероятная оценка
- 6. 6CONFIDENTIAL •Распределение не нормальное •Подстраховка огромна Реальная оценка Безопасная оценка (80 – 90% уверенности в завершении задачи в срок Время Вероятность Начало работы Агрессивная оценка Наиболее вероятная оценка
- 7. 7CONFIDENTIAL Типичный проектный план Самая длинная связанная цепочка задач1 Подстраховка в каждой задаче2 Фокус на соблюдении сроков начала и конца каждой задачи лежащей на критическом пути3 Task C Task D Task E Task F Task A Task B Task G Start Finish
- 8. 8CONFIDENTIAL • Проект – ето целая система • Цель проекта – ето поставка результата вовремя, в бюджете и нужном функционале • Time-to-Market очень важен для бизнеса • Наша возможность выполнения интелектуальных заданий вовремя или даже раньше становится основным конкурентным преимуществом на рынке труда Projects
- 9. 9CONFIDENTIAL • Много внимания локальным задачам • Синдром стюдента • Закон Паркинсона • Мультитаскинг • Все вместе Куда деваются наши «класные» естимейты?
- 10. 10CONFIDENTIAL •100% загрузка не дает желанного результата Локальна оптимізація не працює
- 11. 11CONFIDENTIAL • Если каждую задачу выполнить в срок, то и весь проект будет выполнен в срок. Так ли это? • Возможности от раннего завершения, будут упущены • Если выполнение задачи на критическом пути будет задержано, то скорее всего будет задержан и сам проект Концентрация на локальных задачах
- 12. 12CONFIDENTIAL • Работа постоянно откладывается на потом. • Чем больше заложено подстраховки, тем больше вероятность, что найдутся какие- то более важные дела. • Проект с идеальной подстраховкой, т.е. без срока окончания, скорее всего вообще никогда не будет завершен. Синдром студента
- 14. 14CONFIDENTIAL • Работа стремится занять всё время, отведенное на нее. • Если на работу выделить много времени, всегда найдется что улучшить. • Если выполнить работу раньше срока, то в следующий раз тебе точно не дадут достаточно времени Закон Паркинсона Время Усилия
- 15. 15CONFIDENTIAL • От переключения между задачами, время выполнения каждой задачи возрастает. • Общее время завершения всех параллельных задач вырастает еще сильнее. Многозадачность Время Задачи
- 16. 16CONFIDENTIAL Многозадачность (Все сразу) Задача 1 1 2 3 4 … 26 Задача 2 A B C D … Y Z Задача 3 ….
- 17. 17CONFIDENTIAL Многозадачность (Делаем последовательно) Задача 1 1 2 3 4 … 26 Задача 2 A B C D … Y Z Задача 3 ….
- 18. 18CONFIDENTIAL При планировании задач учитывать •Фокусироваться на достижении задач, а не 100% нагрузке •Помнить о синдроме стюдента •Ставить четкие дедлайны, так как работа займет все время отведенное на нее •Не обещать что сделает все задачи сразу •Быть честным с собой и колегами
- 19. 19CONFIDENTIAL • Курс « Управление проектами по методу ТОС» от Apple Consulting, 5-6 Декабря 2017 • Книга “Critical Chain: A Business Novel” Что дальше?
Editor's Notes
- Нет ничего более многообразного чем проектное управление, кругом одни проекты. В самых различных областях. ЭПАМ мультипроектная среда, любой аккаунт и т.п. Сама суть нашего бизнеса — это проектное управление. Но что удивительно, практически во всех проектах, не зависимо от области деятельности, можно наблюдать одни и те же симптомы. Вот они. Что удивительного в этом списке? Его писали не вы! На самом деле нет ничего удивительного в том, что этот список так похож для любых проектов нет. Причина в неопределенности. Именно неопределенность (или как ее иногда в шутку называют Мёрфи) и подходы к управлению ней является одной из причин выделения управления проектами в отдельную область знаний. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на ключевые параметры проекта (а мы знаем, что их три – сроки, бюджет, объем), на его успех. Не хотелось бы приводить всем известные данные о количестве проектов вышедших за рамки, сроки и т.п. Все это говорит, что Мерфи существует и по-прежнему актуальны методы борьбы с ним. Дальше мы, возможно не так подробно как хотелось бы, и рассмотрим один из таких методов – метод Критической Цепи, немного сравним его с классическими подходами и посмотрим на небольшой пример реальной реализации. Кстати говоря, начиная с 5 издания PMBoK критическая цепь туда официально включена, как допустимый инструмент контроля за проектом (раздел 6.6.2.3 Project Time Management – Develop Schedule.)
- Конечно же существует различные методы борьбы с рисками и неопределенностями. Риски идентифицируются, оцениваются количественно и качественно, и в конечном счете включаются в оценки. И наверное не для кого не секрет, что обычно ресурсов (времени, денег) на борьбу с неопределенностью закладывается очень много. Сначала сотрудник, а потом и его руководитель закладывают в оценку те риски, которые они предвидят (новая технология, неопытность исполнителей, недостаток информации и т.п.) Риски минимизируются путем добавления резервов в каждую задачу. А потом еще и сверху добавляется менеджерский резерв, задачи суммируются и получается всем известное распределение. Для того чтобы избежать рисков оценки всегда стараются давать с вероятностью не ниже 80%, а обычно все 95%.
- Кто сказал что подстраховки недостаточно. Вернемся к распределению вероятностей при оценках. На самом деле (в реальной жизни) оно не симметрично. На самом деле, распределение вот такое. И между 50 и 80% очень, очень большой запас по времени. Но реально люди бояться и дают минимум 80% или даже 90%. В результате подстраховка по времени огромна! Потому что людей вынуждают дать хоть какую-то оценку, а потом она внезапно становиться священной. Потому что в силу человеческой природы мы закладываем 80% подстраховки, хотя думаем что 10, да и еще бы добавить было бы неплохо "большинство людей ведут себя в соответствии с тем, как измеряется их деятельность" "Основное влияние на оценки по времени оказывает то, насколько сотрудник опоздал с завершением задания в прошлый раз" Три механизма того, как подстраховка закладывается почти в каждый элемент проекта: • оценка по времени основана на негативном опыте и оказывается в конце кривой распределения вероятности. • чем больше уровней менеджмента вовлечено в оценку по времени реализации проекта, тем выше окончательная оценка, так как каждый уровень добавляет свою подстраховку. • те, кто делают оценку, закладывают дополнительную подстраховку от глобального «урезания». Если суммировать, получается, что подстраховка составляет большую часть предполагаемого времени реализации проекта. Может быть ее достаточно, но мы управляем проектом так, что она вся разбазаривается?
- Затем составляется расписание проект и используется всем известный подход к контролю проекта связанный с контролем выполнения задач на критическом пути. Критический путь определяется как самая длинная цепочка в проекте состоящая из взаимосвязанных задач. Критический путь определяет длительность всего проекта. Если каждую задачу на пути выполнить в срок то и весь проект будет выполнен в срок. Именно такова обычная логика проектного управления. Фокусируйся на сроках начала и завершения задач, тогда и весь проект будет завершен в срок. Прекрасно! Но тогда откуда же все те проблемы? Видимо в этой логике есть какие-то изъяны.
- Cказать, что как это не прискорбно но люди в силу своей природы очень, очень любят локальные оптимизации. и очень очен плохо понимаю почему это плохо. И это серьезная проблема в применении ToC --- Есть тезис, что оптимизация системы в целом это как бы стратегическая цель, а локальные оптимизации это тактика. Это в корне не верный подход. Стратегия это увеличить эффективность всей системы. Тактика это поиск узкого места (ограничения) и увеличение общей эффективности через оптимизацию использования узкого места. Оптимизация локальных оптимумов она вообще в целом ничего не оптимизирует по определению. А как правило просто вредит. Почему? А потому что, как мы определили, функцией приближения к цели является проход. Проход ограничен. И Проход в целом по определению не может быть больше чем Проход в самом узком месте. Так вот, если ты оптимизируешь что-то что не является узким местом, то ты в лучшем случае вообще никак не влияешь на общий проход системы. Но как правило, ты только ухудшаешь положение узкого места и системы в целом. Например. Если ты оптимизировал что-то что перед узким местом, то ты скорее всего ухудшишь состояние системы, так как ты просто добьешься того что в системе увеличатся запасы и накладные расходы. Ну потому что кто-то станет делать больше, а то что он делает все равно через узкое место проходить не будет, а будет просто копиться. Если же ты оптимизируешь что-то после узкого места, то это будет просто бесполезная работа, так как ты просто создашь избыточную мощность, которая не будет востребована. Ведь узкое место все равно не выдаст больше чем сможет.
- Если работа выполнена раньше, это никак не используется. Ведь этого никто не ждет. Мы должны соблюдать сроки конца и начала работ. Такова логика концентрации на локальных оптимумах свойственная человеку. Я свое сделал и больше знать ничего не хочу. Но что еще хуже! Если вдруг какая-то работа задерживается, то она почти гарантированно задерживает все работы по цепочке дальше. Если вам конечно не повезло и там не было каких-то лагов между задачами, но обычно так не бывает. Если хотя бы одна часть проекта была завершена позже срока это значит весь проект будет завершен позже срока. Это таже самая проблема узкого места. Если у тебя 5 частей и вероятность каждого уложиться в сроки 50 % то общая вероятность начать интеграцию в срок 3%. Именно поэтому люди берут оценки с вероятностью 90%. Но потом эта подстраховка разбазаривается по причинам изложенным ниже. В случае сдвига по времени типичным решением в традиционном управлении проектами является применение корректирующих действий при срабатывании рисков путем урезания объема работ проекта или выделения дополнительных ресурсов. Это не делает счастливым ни заказчика, ни руководителей верхнего уровня.
- Вся работа откладывается на потом. Ведь подстраховки то заложено вон сколько! Дедлайн еще так далеко!
- Вся работа откладывается на потом. Ведь подстраховки то заложено вон сколько! Дедлайн еще так далеко!
- Но реально вряд ли работа будет выполнена раньше. Ведь как известно любая работа занимает всё отведенное для нее время. Всегда есть что улучшить! Допустим ты начальник отдела и тебе дали бюджет. И в конце года ты не смог его потратить весь. Вернешь ли ты его назад? Нет. Ты найдешь на что потратить его с пользой. То же самое и с работой. Если ты будешь делать ее быстрее, чем надо, то в следующий раз тебе просто не дадут столько времени сколько надо. Такова человеческая натура.
- В мультипроектной среде все еще гораздо хуже. Ведь обязательств больше, а при этом еще появляется конкуренция за ресурсы, которая приводит к переключениям с задачи на задачу, а это большие потери. Время потраченное на задание от переключения увеличивается на 10%. Но время потраченное на завершение задание может увеличится на 300%!