Дмитрий Лукьянов - Стандарты в управлении проектами: от «водопада» до «гибких» подходов

1. Project Management Standards:
from Waterfall to Agile Approaches
Dmytro Lukianov
PhD (project&program management),
IPMA-A

2. Project Management Standards:
from Waterfall to Agile Approaches

3. «Проект» и «Управление проектом»
Доклад будет посвящен тому, что такое «профессиональная
деятельность», какими «атрибутами» она обладает и кого можно
считать «профессионалом». В докладе будет предложена некоторая
«ретроспектива» для подходов к управлению проектами, которые
используются в ИТ-сфере, а последнее время и переносятся в другие
отрасли, а также дан прогноз их дальнейшего развития.
Важной частью доклада будет рассмотрение системных
ограничений, присущих системам управления проектами при
увеличении комплексности проекта и количества участников, а также
предложены рекомендации по их учету.

4. Время, которое у нас есть - 40 минут.
Поехали! :)

5. Начнем с… «великой тайны» ;)

6. «Управления проектами» - нет!

7. «Управления деятельностью людей» - есть!

8. Управление «проектами»…
Откуда оно взялось?

9. История Agile. Знакомые лица?
https://agilescout.com/history-of-agile-the-influencers-and-drivers-of-the-agile-movement/

10. История Agile
http://devprom.ru/news/История-Agile
https://agilescout.com/history-of-agile-the-influencers-and-drivers-of-the-agile-movement/

11. Кто все эти люди???

12. Собственно, с них, возможно, все и началось…
Анри
Файоль
Фредерик
Тейлор
Генри
Гантт

13. Анри Файоль: функции и принципы управления
Основные стороны деятельности включают:
1. Техническую: производство продукта.
2. Коммерческую: закупку товаров, продажу и обмен
готовой продукции.
3. Финансовую: получение и использование капитала.
4. Обеспечение безопасности труда и собственности.
5. Ведение отчетности.
6. Собственно управление
http://dps.smrtlc.ru/Int_Encycl/Man_princ_of.htm

14. Анри Файоль: функции и принципы управления
Собственно управление, в котором Файоль выделяет 5 функций, или
типов задач, менеджера:
1) Планирование. Постановка целей, поиск путей их достижения и
определение направлений, в которых должно продвигаться предприятие.
2) Организация. Конструирование и создание структуры,
соответствующей целям и средствам, намеченным в ходе планирования.
3) Командование. Оперативное руководство исполнителями
спланированных мероприятий.
4) Координация. Согласование и упорядочение деятельности
подразделений и представителей организации, направленное на
достижение наибольшей общей эффективности.
5) Контроль. Оценка эффективности в соответствии с разработанной
ранее системой правил.
http://dps.smrtlc.ru/Int_Encycl/Man_princ_of.htm

15. Фредерик Тейлор о производительности труда:
В своей книге «Принципы научного менеджмента» Фредерик Тейлор
изложил пять принципов повышения производительности труда.
▪ первый принцип: надо изучить задачу и проанализировать движения,
которые требуются для ее выполнения;
▪ второй принцип сводится к описанию каждого движения, составляющих
его усилий и измерению времени, затраченного на каждое из них;
▪ третий принцип призывает устранить все лишние движения;
▪ четвертый принцип: оставшиеся движения последовательно
соединяются так, чтобы работник тратил на них минимум физических и
умственных усилий и, естественно, времени;
▪ пятый принцип: необходимо изменить конструкцию инструментов,
используемых работником для выполнения задачи.
http://free.megacampus.ru/xbookM0011/index.html?go=part-004*page.htm

16. Генри Гант о сотрудничестве:
«Доктрина служения — это не просто исправно работающая
экономика… Единственным условием промышленного мира
является промышленная демократия… Должна быть очевидной
мысль о том, что с возрастанием сложности современной
системы предпринимательства эффективная работа может
быть обеспечена только следованием за теми, кто фактически
умеет выполнять функции контроля и при этом сполна осознает
социальную ответственность. Если же предпринимательской
системой попытаются управлять люди, не осознающие
реальных движущих сил, ее эффективность снизится…».
http://21biz.ru/genri-gant-kak-predstavitel-shkoly-nauchnogo-upravleniya/

17. Генри Гант о сотрудничестве:
«Иными словами, условия, в которых может
функционировать развитая производственная и
предпринимательская система для обеспечения
сложных системных требований современной
цивилизации, должна определяться только
подлинными лидерами — людьми, понимающими
механизм действия движущих сил общества и
видящими свою высшую цель — служение обществу».
http://21biz.ru/genri-gant-kak-predstavitel-shkoly-nauchnogo-upravleniya/

18. Неужели это про… ценности?
А где же «управление проектами»?

19. «Проект»

20. «Управление проектом»

21. Как вы думаете? Где это написано???

22. «Водопад»
(ай-ай, какой «нафталин»)

23. В 1970 году Уинстон Ройс описал в виде концепции то, что
сейчас принято называть «водопадная модель»
• Определение требований
• Проектирование
• Конструирование (также «реализация» либо «кодирование»)
• Воплощение
• Тестирование и отладка (также «верификация»)
• Инсталляция
• Поддержка
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

24. с чего начиналась логика «каскадной/
водопадной модели» у Ройса:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

25. РМВОК=зло?
Потому что РМВОК=«водопад»

26. Закон Голла
Сложная рабочая система неизменно получается
из простой рабочей системы. Сложная система,
разработанная с нуля, никогда не работает. И никакие
улучшения не заставят ее работать. Начинать следует с
простой рабочей системы.
(закон Голла, 1986)
https://habrahabr.ru/company/edison/blog/272483/

27. Дополнение к Закону Голла
Сложная система управления неизменно
получается из простой работающей системы
управления. Сложная система, разработанная и
внедренная с нуля, никогда не работает. И никакие
улучшения не заставят ее работать. Начинать следует с
простой рабочей системы управления.
ДЛ

28. Problem/Challenge
«Pure Agile/Scrum» limitations

29. Совет от Сальвадора Дали:
Для начала научитесь рисовать и
писать как старые мастера, а уж потом
действуйте по своему усмотрению - и
вас всегда будут уважать.
http://socratify.net/quotes/salvador-dali/29548

30. Совет от ДЛ:
Для начала научитесь планировать и
управлять с «водопадом», а уж потом
действуйте по своему усмотрению - и
вас всегда будут уважать.
http://socratify.net/quotes/salvador-dali/29548

31. «Гибкие технологии»
= действительно
«настоящее
управление»
А может кто-то еще
придумывал «реальное
управление» раньше»?

32. Гьюлик и Урвик: Синтез управления и организации
Описывая те виды управленческой деятельности,
которые наблюдаются во всех организациях, Гьюлик
изобрел акроним POSDCORB, первые буквы которого
соответствуют английским словам "планирование,
организация, подбор персонала, командование,
координация, отчетность и бюджетирование".
POSDCORB задумывался как связующее звено между
теорией управления и реальной управленческой
практикой.
http://dps.smrtlc.ru/Int_Encycl/Man_princ_of.htm

33. Гьюлик и Урвик: Синтез управления и организации
1. Планирование - определение целей, которые должны быть достигнуты, и
средств, которые могут при этом использоваться.
2. Организация - создание формальной структуры, в рамках которой
происходит распределение обязанностей и полномочий.
3. Подбор персонала - набор и подготовка групп людей, которые исполняют
работу, и обеспечение благоприятных условий их труда.
4. Командование - принятие решений и непосредственное руководство
подчиненными, а также исполнение прочих обязанностей лидера.
5. Координация - поддержание связи между подразделениями организации.
6. Отчетность - информирование тех, кому управленец подотчетен, а также
его подчиненных, о ходе работ. Реализация этой функции невозможна без
ведения записей, проведения исследований и осуществления проверок.
7. Бюджетирование - разработка фискальных мер и ведение финансовых
документов.
http://dps.smrtlc.ru/Int_Encycl/Man_princ_of.htm

34. Гьюлик и Урвик: Синтез управления и организации
Списки принципов, сформулированных Файолем, Муни,
Рейли, Гьюликом и Урвиком, многократно подвергались
критике как со стороны управленцев, пытавшихся применить
их на практике, так и ученых-теоретиков. Их основные
замечания можно суммировать следующим образом:
1) все эти принципы - не более, чем расхожие банальности;
2) они основываются на ложных исходных предпосылках;
3) они двусмысленны и, соответственно, не могут иметь
практического применения.
http://dps.smrtlc.ru/Int_Encycl/Man_princ_of.htm

35. Системы
управления
проектами
…и как они
«развиваются»

36. Закон Конвея
«Организации, проектирующие системы, …
производят их, копируя структуры
коммуникации, сложившиеся в этих
организациях»
(Конвей, 1968)
https://habrahabr.ru/company/edison/blog/272483/

37. Стандарты в
управлении
проектами…
«коровьи тропы» и зачем
их «асфальтировать»?

38. «Профессионализация деятельности»:
• Отличающаяся своими результатами деятельность
• Отличающийся своими «смыслами» глоссарий
• Отличающиеся своими «компетенциями» персонал
• Отличающиеся своими «рекомендациями» подходы к организации
деятельности
• Система обеспечивающая передачу знаний (Образование)
• Профессиональное сообщество
• Система «отличий» внутри такой деятельности, признаваемая «внутри» и
«снаружи» такой сферы

39. PMI:
• Стандарт касательно компетенций персонала
• Профессиональный глоссарий
• Стандарты относительно подходов к деятельности (Проект-Программа-
Портфель)
• Рекомендации («Практические стандарты» касательно отдельных аспектов
деятельности)
• Институт «Образовательных провайдеров» (REP)
• Система «Членства» и «Сообществ»
• Развитая система сертификации, признаваемая во всем мире

40. PMI:
http://www.pmi.org/

41. «Гибкие подходы»:
• Различные «Роли» участников проектной деятельности
• Профессиональный глоссарий
• Стандарты относительно подходов к деятельности («Гайды» и
др.)
• Рекомендации («Принципы» и др.)
• Система «распространения знаний» через тренинговые
программы и конференции
• Системы сертификаций, борющиеся между собой

42. SCRUM:
https://www.scrum.org/

43. DSDM:
https://www.agilebusiness.org/what-is-dsdm

44. AgileLAB:
http://agilelab.org/

45. Agile:
https://www.agileconsortium.net/

46. Проблемы, с
которыми борется
«современное
управление
проектами»…
…и «борется» по-разному

47. Боб Айелло, консультант и главный редактор, CM
Best Practices Consulting:
• Масштабируемость:
• Нужны гибкие практики, которые работают
как в небольших, так и в крупных проектах.
https://www.ibm.com/developerworks/ru/library/r-agile-process-maturity/index.html

48. Это «масштабирование» или нет?
и кто это? ;)

49. Боб Айелло, консультант и главный редактор, CM
Best Practices Consulting:
• Масштабируемая гибкая разработка
предполагает принятие практик, которые с
одинаковой эффективностью можно использовать
как в обычной небольшой группе, так и в крупных
проектах.
https://www.ibm.com/developerworks/ru/library/r-agile-process-maturity/index.html

50. Боб Айелло, консультант и главный редактор, CM
Best Practices Consulting:
• Управление жизненным циклом приложений
(application lifecycle management – ALM)
обеспечивает повторяемость благодаря
поддержке SDLC (software delivery lifecycle) –
полного жизненного цикла поставки ПО или систем…
Зрелые гибкие практики являются
повторяемыми, предсказуемыми и могут
масштабироваться для поддержки групп
требуемого размера.
https://www.ibm.com/developerworks/ru/library/r-agile-process-maturity/index.html

51. 10 главных ошибок масштабирования систем
1. Проектирование реализации, но не поиск
архитектурного решения
2. Проектирование без расчета на ошибку
3. Вертикальное масштабирование вместо распределения
нагрузки
4. Использование неверных инструментов
https://habrahabr.ru/company/edison/blog/269861/

52. 10 главных ошибок масштабирования систем
Организационные неудачи
5. Разделение по функциям
6. Слишком большие команды
7. Неумение ухаживать за своим садом
https://habrahabr.ru/company/edison/blog/269861/

53. 10 главных ошибок масштабирования систем
Сбой процесса
8. Неспособность учиться
9. Вера в Agile как в панацею
10. Нагрузочное и тестирование производительности
покажут все проблемы масштабирования
https://habrahabr.ru/company/edison/blog/269861/

54. U-p-p-p-s!
A piece of theory…
;)

55. Масштабируемость системы
• Система называется масштабируемой, если она способна
увеличивать производительность пропорционально
дополнительным ресурсам. Масштабируемость можно
оценить через отношение прироста производительности
системы к приросту используемых ресурсов.
• Чем ближе это отношение к единице, тем лучше. Также
под масштабируемостью понимается возможность
наращивания дополнительных ресурсов без структурных
изменений центрального узла системы.
http://www.gpedia.com/ru/gpedia/Масштабируемость

56. Система
• Система — совокупность интегрированных и
регулярно взаимодействующих или взаимозависимых
элементов, созданная для достижения
определенных целей, причем отношения между
элементами определены и устойчивы, а общая
производительность или функциональность
системы лучше, чем у простой суммы элементов
(РМВОК)
https://ru.wikipedia.org/wiki/Система

57. Масштабируемость системы
• Вертикальное масштабирование — увеличение
производительности каждого компонента
системы с целью повышения общей
производительности. Масштабируемость в этом
контексте означает возможность заменять в
существующей вычислительной системе компоненты
более мощными и быстрыми по мере роста
требований и развития технологий. (IBM Redbook:
The RS/6000 SP Inside Out, id: SG24-5374-00, стр.15)
http://www.gpedia.com/ru/gpedia/Масштабируемость

58. Масштабируемость команды
• Вертикальное масштабирование команды —
увеличение производительности каждого
участника системы (члена команды) с целью
повышения общей производительности.
Масштабируемость в этом контексте означает
возможность заменять в существующей команде
существующих участников более производитьльными
и быстрыми по мере роста требований и развития
компетенций участников команд.
ДЛ

59. Масштабируемость системы
• Горизонтальное масштабирование — разбиение
системы на более мелкие структурные компоненты
и разнесение их по отдельным физическим машинам
(или их группам), и (или) увеличение количества
серверов, параллельно выполняющих одну и ту же
функцию. Масштабируемость в этом контексте означает
возможность добавлять к системе новые узлы,
серверы, процессоры для увеличения общей
производительности.(IBM Redbook: The RS/6000 SP
Inside Out, id: SG24-5374-00, стр.15)
http://www.gpedia.com/ru/gpedia/Масштабируемость

60. Масштабируемость системы
• Горизонтальное масштабирование. Этот способ
масштабирования может требовать внесения
изменений в программы, чтобы программы могли в
полной мере пользоваться возросшим количеством
ресурсов.
• (IBM Redbook: The RS/6000 SP Inside Out, id:
SG24-5374-00, стр.15)
http://www.gpedia.com/ru/gpedia/Масштабируемость

61. Масштабируемость команды
• Горизонтальное масштабирование — разбиение команды
с ее ростом на более мелкие структурные компоненты
(рабочие группы) и разнесение их по отдельным объемам
работ («пакетам работ»), и (или) увеличение количества
команд, параллельно выполняющих одну и ту же рабочую
функцию. Масштабируемость в этом контексте означает
возможность добавлять к системе новые команды
(участников), для увеличения общей
производительности.
ДЛ

62. Масштабируемость команды
• Горизонтальное масштабирование. Этот способ
масштабирования может требовать внесения изменений
в набор компетенций участников команд и
существующую систему управления, чтобы команды
(участники) могли в полной мере пользоваться
возросшим количеством ресурсов.
ДЛ

63. Закон Амдала (англ. Amdahl's law, иногда также
Закон Амдаля-Уэра)
• Джин Амдал сформулировал закон в 1967 году, обнаружив
простое по существу, но непреодолимое по содержанию
ограничение на рост производительности при
распараллеливании вычислений: «В случае, когда задача
разделяется на несколько частей, суммарное время её
выполнения на параллельной системе не может быть
меньше времени выполнения самого длинного
фрагмента»
https://ru.wikipedia.org/wiki/Закон_Амдала

64. Закон Амдала (англ. Amdahl's law, иногда также
Закон Амдаля-Уэра)
• Таблица показывает, во сколько раз быстрее
выполнится программа с долей последовательных
вычислений α при использовании p процессоров
https://ru.wikipedia.org/wiki/Закон_Амдала

65. Закон Амдала (англ. Amdahl's law, иногда также
Закон Амдаля-Уэра)
• Закон Амдала показывает, что прирост
эффективности вычислений зависит от алгоритма
задачи и ограничен сверху для любой задачи с α ≠ 0.
• Не для всякой задачи имеет смысл наращивание
числа процессоров в вычислительной системе!!!
https://ru.wikipedia.org/wiki/Закон_Амдала

66. Закон Амдала (англ. Amdahl's law, иногда также
Закон Амдаля-Уэра)
• Более того, если учесть время, необходимое для передачи
данных между узлами вычислительной системы, то
зависимость времени вычислений от числа узлов будет
иметь максимум.
• Это накладывает ограничение на масштабируемость
вычислительной системы, то есть означает, что с
определенного момента добавление новых узлов в
систему будет увеличивать время расчёта задачи.
https://ru.wikipedia.org/wiki/Закон_Амдала

67. Коэффициент «человечности» к Закону Амдала
• С людьми все гораздо хуже.
• Ими нельзя управлять как процессорами ;)
ДЛ

68. Закон Конвея
• «Эффективная сложная команда неизменно
возникает из простого продуктивного аналога.
Сложная команда, собранная с нуля, результативно
функционировать не может. И никакие изменения не
заставят ее работать. Дело стоит начинать с уже
сработавшейся командой».
https://habrahabr.ru/company/edison/blog/272483/

69. Законы Келли
• Масштаб ПО всегда будет увеличиваться
пропорционально имеющимся ресурсам — первый
закон Келли
• Внутри каждого большого проекта в области
разработки есть маленький побочный проект вне
основной задачи — второй закон Келли
https://habrahabr.ru/company/edison/blog/272483/

70. Дополнение ко второму закону Келли
• Внутри каждого большого проекта в области
разработки есть маленький побочный проект вне
основной задачи — проект по созданию системы
управления этим проектом!
ДЛ

71. Закон Лукьянова
• В управлении проектами, обладающими свойствами
уникальности ни одна команда проекта не будет
изначально обладать необходимым набором
компетенций и объемом знаний для его
гарантированной успешной реализации
https://www.researchgate.net/publication/
282877128_GIPOTEZA_O_PREDOPREDELENNOJ_NEDOSTATOCNOSTI_ZNANIJ_I_
KOMPETENCIJ_V_PROEKTNYH_KOMANDAH?ev=prf_pub

72. Выводы:
• Вертикальное масштабирование идеально, но в командах,
состоящих из людей, видимо, а) ограничено параметрами
человека и б) количеством участников в команде
• Горизонтальное масштабирование подразумевает
распараллеливание процесса на негарантированно равные по
длительности блоки работ и может требовать взаимоучета
результатов операций в каждом из потоков (последовательности
операций) - возникает потребность в учете последовательностей
в использовании результатов «параллельных работ»
ДЛ

73. Выводы:
• При увеличении доли «горизонтального
масштабирования» с учетом последовательности
операций эффект от масштабирования уменьшается
• Команды должны оставаться самоорганизующимися,
саморазвивающимися и самоуправляемыми!
ДЛ

75. –Abraham Lincoln
«Книги нужны, чтобы напоминать человеку,
что его оригинальные мысли не так уж новы».

76. Scrum Values
https://dou.ua/lenta/articles/scrum-guide-july-2016/

77. и ценности Scrum ;)
Да пребудет с вами разум!
http://pmb.com.ua/