CC BY
0Баранов В.А.
Аспирант. Санкт-Петербургский реставрационно-строительный институт.
Методология гибкого подхода при управлении строительными проектами в американской экономической модели
Управление является каркасом любого строительного проекта, поскольку проекты постоянно развиваются и представляют собой хорошо спланированный процесс, который обеспечивает их успех. перерасходы, которые могут возникнуть в крупном строительном проекте, очень сложно спрогнозировать количественно из-за огромного количества задействованных переменных [1]. Практический пример: сегодня эта проблема решается с помощью технических средств BIM моделирования.
В основе убыточности строительных проектов лежит перерасход средств, превышение сроков строительства или необоснованный рост содержания проекта в части строительной и инженерной начинки [2], а также некорректное использование традиционных методов управления проектами (воздействие на участников со стороны контрольно-надзорных органов). Практический пример: лето 2023 г. остановка строительного проекта на намыве В.О. Санкт-Штербурга после проникновения на территорию стройплощадки федерального чиновника без всяких юридических оснований привело к остановке работ на период около 3 месяцев.
Высокая степень риска, требует иного подхода к управлению строительными проектами, чтобы способствовать более эффективному подходу, важно тщательно проанализировать управление и реализацию проектов, чтобы определить наиболее эффективные инструменты и методы, которые следует применять.
Чтобы быть флагманом в управлении проектом, необходимо рассмотреть инструментарий экономиста, состоящий из «традиционных», «гибридных» и «бережливых» (наличие хорошей федеральной крыши) методов. Изучение общего и особенного в подходах, позволяет американским экономистам разработать новую гибридную модель управления, подходящую для строительных проектов. Однако и в этом случае необходима адаптация для каждого проекта к конкретному случаю, поскольку, общеизвестно, что управление проектом за-
висит от конкретной ситуации.
Гибкий подход к управлению проектом - это следование при его реализации здравому смыслу. История гибкого управления проектами, берет начало в 1930-х годах из подхода к качеству проекта Уолтера Шерварта (доктор физики Иллинойского университета): «планируй-Делай-проверяй-Действуй» (PDCA).
В 1970-х годах доктор Уинстон Ройс (директор центра программных технологий, Техас) опубликовал исследование: «Управление разработкой больших программных систем» и предположил, что классический каскадный метод сам по себе неэффективен, делать все в одной последовательности не эффективно, и для достижения успеха необходимо параллелить многие из стадий реализации. Практический пример: изыскательские работы на земельном участке, совмещают с общестроительным проектированием и заказом технологического оборудования у производителей. Сегодня практика идет по пути коллаборации банка, застройщика, проектировщика, дизайнера, агентства по продажам, специалистов по ИКТ, что позволяет выводить на рынок конкурентный продукт.
Экономист Миллс (профессор Колумбийского университета) указывает на это в обсуждении прогрессивного развития подразделения федеральных систем IBM, которое содержится в опубликованном томе «принципы разработки программного обеспечения» [3]. Идея, возникшая в 1980 году, «визуальный контроль» в производственной системе Toyota является предвосхищением «информационных панелей». Американские экономисты заимствуют японскую идею в управлении проектом. Ее содержание: клиент не знает, что ему нужно, мы создаем продукт и убеждаем, что это именно, то что нужно, модно, удобно и всегда хорошо меняется на деньги.
Барри Бём (гарвардский поебанец, математик) [4] провел первое эмпирическое исследование проектов с использованием прототипи-рования, которое по сути 6bmo итеративной стратегией, и предположил, что итеративным подходам уделялось серьезное внимание в то время, скорее всего, из-за таких факторов, как увеличение количества персональных компьютеров и графических пользовательских интерфейсов. прототипирование, как способ быстрой «черновой» реализации базовой функциональности будущего девелоперского продукта, для анализа работы системы в целом.
В 1984 году понятие «факторинг», предвосхищение рефакторинга, описано в книге «Thinking Forth», где оно представлено как «организация кода в полезные фрагменты», которое «происходит во время детального проектирования и реализации». В 1985 году, возможно,
первой явно названной постепенной альтернативой классическому каскадному подходу стала Evolutionary delivery model Тома Гилба, получившая сокращение «Evo».
Барри Бём представляет «Спиральную модель разработки и улучшения программного обеспечения» - итеративную модель, ориентированную на выявление и снижение рисков с помощью соответствующих подходов [5]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Бём формулирует десять наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв между квалификацией специалистов и требованиями проекта
Риски ИКТ зафиксированные математиком, отразили наиболее подробно специфику работы при управлении над строительными проектами.
Модель трансформаций знаний нонаки-Такеучи. Японские исследователи: Хиротако Такеучи и Икудзиро Нонака опубликовали статью под названием «Игра по разработке новых продуктов» в журнале Harvard Business Review [6]. В статье Такеучи и Нонаки описана быстрая и гибкая стратегия разработки, позволяющая удовлетворить спрос на постоянные изменения в продукте и иначе управлять процессом разработки. Для достижения скорости и гибкости, компании должны по-другому управлять процессом разработки продукта.
В работе [7] Аббас и др., в 1988 году, Скотт Шульц описывает «timebox» как один из краеугольных камней подхода «быстрого итеративного производства прототипов», используемого на дочернем предприятии Du Pont, по информации Engineering Associates. В 1990 году, Билл Опдайк (эксперт по ИКТ) вместе с Ральфом Джонсоном (профессор-исследователь кафедры компьютерных наук Илли-
нойского университета) ввёл термин «рефакторинг» [8]. В документе «ACM SIGPLAN» данный термин расшифровывается следующим образом «Рефакторинг: помощь в проектировании инфраструктур приложений и развитии объектно-ориентированных систем». В 1991 году Джеймс Мартин в своей книге «Быстрая разработка приложений» описал «RAD», возможно, первый подход, в котором тесно связаны «time-boxing» и «итерации» в более гибком смысле «повторение полного процесса разработки программного обеспечения». Эта книга также описывает детали «time-box» в одной из глав. Термин «гибкость» впервые был замечен в производственном секторе [9] под названием «гибкое производство», еще до того, как этот термин стал популярным в области гибкого управления проектами. В 1992 году: полное описание «рефакторинга» представлено в диссертации Опдайка «Рефакторинг объектно-ориентированных фреймворков». Бьорнвиг и Коплиен пишут оригинальный шаблон процесса «StandUp Meeting» [10]. Исследователи Тернер и Кокрейн отметили, что «замороженные цели становятся неотъемлемой частью определения качества проекта, и говорят, что менеджеры проектов добиваются успеха, если они выполняют их вовремя и в рамках бюджета, независимо от того, является ли продукт полезным или выгодным для владельцев и пользователей» [11]. Это подчеркивает преимущества методов, которые формализуют переработку проекта и внесение изменений в надзорное дело на этапе выполнения. Ученые утверждают, что правильный технический дизайн девелоперского продукта проистекает из знания того, как поставить человека во главу угла и делать то что будет востребовано людьми.
В 1995 году Швабер К. (программист из Иллинойса) написал «процесс разработки SCRUM» он среди первых, кто ввел понятие «спринт» (sprint) как процесс итерации, хотя у него ее продолжительность варьируется [12]. Его монография "Программное обеспечение за 30 дней: как гибкие менеджеры превзошли все шансы, порадовали своих клиентов и повергли конкурентов в прах" стала для управленцев настольной книгой.
Эти различные методы, хотя их нельзя в полной мере назвать «гибкими», все они вдохновили методологию, образ мышления и философию «гибкой» разработки, используемой в настоящее время в области разработки программного обеспечения. Кент Бек (выпускник Орегонского университета, по информатике) и другие группы экспертов по программному обеспечению и управлению проектами встретились, чтобы обсудить общие моменты их достижений в разработке методов разработки проектов [13]. Эта группа создала «Agile
Manifesto», заявление о ценностях успешной разработки программного обеспечения [14].
Монография писателя и программиста Мэри поппендика «Бережливое программирование» привлекает внимание к структурным параллелям между «Гибким подходом» и идеями, известными как «Бережливый подход» или «Производственная система Toyota» [15].
Норман Керт в монографии «Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед» развивает идеи своей книги, опубликованной в 2001 году, вводит термин «Ретроспективный проект» (Project Retrospectives: A Handbook for Team Reviews); В 2002 году Scrum-сообщество приняло практику измерения «speed or velocity», этот новый подход появился под разными названиями. Наиболее часто используемое название - «гибкий подход» [16], в то время как тот же принцип и подход встречаются под названиями «бережливый» [17], «экстремальный» [18] и «адаптивный» [19], [20] М. Поппендик и др. описывает таблицу задач «бережливого подхода» как «kanban software system» в книге «Бережливая разработка программного обеспечения» [21].
В книге «Гибкая оценка и планирование», Майкл Кон (эксперт по ИКТ из Калифорнии) объяснил, что техника «Покерного планирования» и другие методы планирования популяризируются в сообществе Scrum [22]. Публикация «Бережливый подход предыстория» положила конец предыдущим неопределенностям в терминологии; в 2011 году практика «backlog grooming» становится официальным элементом Scrum благодаря ее включению в руководство по Scrum. С другой стороны, противники гибкого подхода обычно отмечают, что эти подходы являются лишь оправданием неиспользования основных и необходимых принципов разработки программного обеспечения и управления проектами [23], и что эмпирических доказательств успешного применения методологии «гибкого подхода» до сих пор не хватает. В то же время, недавние эмпирические исследования показывают, что «гибкий подход» доказал свою ценность [24]; [25]. Одно из этих исследований [24] показало, что правильное использование «гибкого подхода», высококвалифицированная проектная команда и соответствующая стратегия реализации являются ключевыми факторами успеха «гибкого подхода», в то время как процессы управления, организационная среда и участие клиентов оставались неизменными. Лиза Криспин и Джанет Грегори дали определение «гибкого теста», что стало первым кратким определением этой темы [26].
Согласно [27] «бережливое» и «гибкое» - особые понятия. По их мнению, бережливая разработка программного обеспечения должна
использоваться стабильно, предсказуемо и линейно. Напротив, «гибкий подход» выиграет от использования в динамичной, непредсказуемой, неопределенной и нелинейной среде. Другими словами, бережливый подход имеет больший потенциал в повторяющейся среде, например, для операций организации [27], [28]. Тарн Адамс (эксперт по ИКТ из Вашингтона) указывает, что некоторые предположения в «Agile Manifestó» неточны или ошибочны [29], Фернандес и Фернандес утверждают, что команда проекта может оказаться на пути бесполезной траты ресурсов, потому что решение или конечный результат неясны [13], Бек и др. добавляют, что новый «гибкий подход» может помешать любому первоначальному проектированию, и в свою очередь может повлиять на последующую реализацию проекта.
Заключение: подводя итог можно утверждать, что методология гибкого подхода при управлении строительными проектами в американской экономической модели представляет собой создание правильного девелоперского продукта с помощью управления. Питер Де Грейс (американский предприниматель) опубликовал эссе «Злые проблемы, праведные решения» в 1990 году. По словам Де Грейса, «злую» проблему на стройплощадке невозможно полностью понять, пока вы сначала не попытаетесь ее решить. Как показывает практика, злые проблемы в управлении строительными проектами возникают постоянно. Это опровергает идеи теоретика архитектуры из Академии художеств им. И.Е. Репина Владимира Григорьева: "делай все по чертежу и не будет пиздежу". В 1984 году президент Рейган, объявляя о выборе Дж. Питера Грейса на пост главы Комиссии по расточительству и неэффективности в федеральном правительстве, сказал: "У нас есть проблема, которая назревала 40 лет, и мы должны найти способы ее решения. Сегодня я повторю вам то, что сказал неделю назад, когда объявил о назначении: будьте смелее. Мы хотим, чтобы ваша команда работала как неутомимые ищейки. Делайте все возможное, чтобы искоренить неэффективность". Гибкий подход при управлении строительными проектами позволяет американцам успешно бороться с неэффективностью. Экономический опыт супостатов заслуживает внимания российских исследователей.
Библиографический список / References
1. Love P.E.D., Wang X., Sing C., Tiong R.L.K. Determining the probability of project cost overruns, J. Constr. Eng. Manag., Vol. 139. № 3. Р. 321-330, 2013.
2. Mahamid I., Bruland A., Dmaidi N. Causes of delay in road construction projects, J. Manag. Eng., 2012. Vol. 28. Р. 300-310.
3. H.D. Mills, The management of software engineering, Part I: Principles of software engineering, IBM Syst. J., 1980. Vol. 19. № 4. Р. 414-420.
4. Boehm B.W. "Software engineering economics," IEEE Trans. Softw. Eng. 1984. № 1. P. 4-21.
5. Boehm B. A spiral model of software development and enhancement, ACM SIGSOFT Softw. Eng. notes, 1986. Vol. 11. P. 14-24.
6. Takeuchi H., Nonaka I. The new new product development game, Harv. Bus. Rev., 1986. Vol. 64. № 1. P. 137-146.
7. Abbas N., Gravell A.M., Wills G.B. Historical roots of agile methods: Where did 'Agile thinking' come from? / International conference on agile processes and extreme programming in software engineering, 2008. P. 94-103.
8. Griswold W.G., Opdyke W.F. The birth of refactoring: A retrospective on the nature of high-impact software engineering research, IEEE Softw., 2015. Vol. 32. № 6. P. 30-38.
9. Nagel R.N., Dove R. 21st century manufacturing enterprise strategy: An industry-led view. Diane Publishing, 1991.
10. Bjornvig G., Coplien J.O. Organizational Patterns and Scrum: Fine-tuning your Agile Implementation.
11. Turner J.R., Cochrane R.A. Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them, Int. J. Proj. Manag., 1993. Vol. 11. № 2. P. 93-102.
12. Sutherland J., Schwaber K. The scrum papers, Nuts, Bolts Orig. an Agil. Process, 2007.
13. K. Beck et al., Manifesto for agile software development, 2001.
14. Poppendieck M. PROJECT & PROCESS MANAGEMENT-BEST PRACTICES-Lean Programming-Part 2 of 2. W. Edwards Deming's Total Quality Management still rings true for software., Softw. Dev., 2001. Vol. 9. № 6. P. 71-75.
15. Kerth N. Project retrospectives: a handbook for team reviews. Addison-Wesley, 2013.
16. Highsmith J. The agile revolution, Agil. Proj. Manag. Creat. Innov. Prod. Addison-Wes-ley, 2004.
17. Leaute T., Williams B.C. Coordinating agile systems through the model-based execution of temporal plans, in Proceedings of the National Conference on Artificial Intelligence, 2005. Vol. 20. № 1. P. 114.
18. DeCarlo D. Leading and managing extreme projects, Lead. to Lead., Vol. 2004. № 34. P. 51.
19. Shenhar A.J., Dvir D. Reinventing project management: the diamond approach to successful growth and innovation. Harvard Business Review Press, 2007.
20. Poppendieck M., Poppendieck T. Lean Software Development: An Agile Toolkit: An Agile Toolkit. Addison-Wesley, 2003.
21. Cohn M. Agile estimating and planning. Pearson Education, 2005.
22. Derby E., Larsen D., Schwaber K. Agile retrospectives: Making good teams great. Pragmatic Bookshelf, 2006.
23. Rakitin S.R. Software verification and validation for practitioners and managers. Artech House, Inc., 2001.
24. Chow T., Cao D.-B. A survey study of critical success factors in agile software projects, J. Syst. Softw. 2008. P. 961-971.
25. Dzamashvili Fogelström N., Gorschek T., Svahnberg M., Olsson P. The impact of agile principles on market - driven software product development, J. Softw. Maint. Evol. Res. Pract., 2010. Vol. 22. № 1. P. 53-80.
26. Crispin L., Gregory J. Agile testing: A practical guide for testers and agile teams. Pearson Education, 2009.
27. Putnik G.D., Putnik Z. Lean vs agile in the context of complexity management in organizations, Learn. Organ., 2012.
28. Tarne R, "Why agile may not be the silver bullet you're looking for," 2015. // URL: www. pmi.org.
29. Fernandez D.J., Fernandez J.D. Agile project management—agilism versus traditional approaches, J. Comput. Inf. Syst., 2008. Vol. 49. № 2. P. 10-17.
