Лоуренс Лич - Вовремя и в рамках бюджета
• организация рабочих ячеек (в данном случае создание рабочих центров там, где естественным образом сложились рабочие группы);
• роли, ответственность и правила работы в команде;
• графическое представление рабочих инструкций;
• визуальный контроль;
• 5s (От японских слов seiri, seiton, seiso, seiketsu, shitsuke, что в переводе означает «сортировать, соблюдать порядок, содержать в чистоте, стандартизировать процедуры, совершенствовать». Первые три понятия относятся к общему поддержанию порядка на рабочем месте. Оставшиеся два — к самоорганизации работника, которая позволит ему придерживаться первых трех, а также к руководству, которое обязано следить за соблюдением перечисленных правил.)
Большинство этих инструментов бережливого производства могут напрямую использоваться в управлении проектами, а ТОС поможет определить, какой из них лучше применить в конкретной системе управления проектами. Детмер также говорит об опасности, которая подстерегает при слиянии подходов ТОС и бережливого производства, связанной с двумя присущими последнему подходу факторами: «В особенности необходимо пересмотреть такие положения бережливого производства, как чрезмерный упор на сокращение расходов и повышение производительности каждого элемента системы, поскольку это приводит к субоптимизации». Предлагаемый в настоящей книге подход ССРМ использует сильные стороны синтеза двух теорий, избегая при этом подобных ловушек.
2.3. Agile, или Облегченные методы управления проектамиЗначительной доли внимания удостоились легкие, или гибкие (agile), методы, предлагаемые для решения проблем, характерных для проектов, связанных с информационными технологиями. В Википедии говорится [7]: «Методы Agile возникли в середине 1990-х годов отчасти в противовес чрезвычайно формализованным методам, таким как Rational Unified Process (рациональный унифицированный процесс, RUP), Prince6, ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством». Причины, по которым в мире появились гибкие методы, описаны в главе 1: значительное превышение сроков и бюджета, неспособность добиться заявленных характеристик продукта в большинстве ИТ-проектов. Облегченные методы по ИТ-проектам включают:
1) быструю разработку приложений;
2) параллельную разработку приложений;
3) экстремальное программирование;
4) SCRUM7.
Подробное рассмотрение этих методов не является нашей целью.
Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:
«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000... что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта. Существующая модель управления проектами по PMI/ ISO 9000 устарела» (с. 60).
Несмотря на то, что далее Андерсон демонстрирует искусный подход к внедрению ССРМ в ИТ-проектах, по моим личным наблюдениям за ИТ-компаниями, столкнувшимися с трудностями при реализации проектов, многие из них не понимают традиционной методики, а если и применяют ее, то неправильно. Основные ошибки: неполное исходное определение содержания проекта (например, нет иерархической структуры работ) и использование неэффективного процесса управления изменениями или вообще полное отсутствие такового. Часть методов, которые называют альтернативой тяжеловесным технологиям РМВОК, на самом деле в этом своде знаний описаны. Наиболее яркий пример — подход «ускоренная спиральная разработка прототипов». И хотя гибкие методологии довольно эффективны в работе небольших команд над несложными системами программного обеспечения, я считаю, что в отношении масштабных проектов они играют скорее вспомогательную роль и не заменяют комплексных подходов, описанных в РМВОК и ОРМ3.
Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты,
как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.
Во-вторых, бывают проекты, задачу которых при запуске невозможно сформулировать целиком и полностью. К ним относятся многие проекты в сфере информационных технологий. Во многих случаях детали того, что предстоит сделать, в самом начале неясны, например при ремонте, техобслуживании или разработке нового лекарства. В таких проектах результаты первых шагов могут изменить последовательность дальнейших действий, и к подобным ситуациям наилучшим образом подходит планирование методом «набегающей волны». Вы детально планируете лишь то, что можете окинуть взором в данный момент с имеющейся у вас информацией и при существующих исходных установках, и уже в самом плане предусматриваете действия по его пересмотру при поступлении новых данных. Некоторые компании применяют данный подход при создании планов долгосрочных программ, когда не известны подробности более поздних этапов и нет четких прогнозов относительно финальных стадий программы. В самой программе запланирован ряд проектов по внесению существенных изменений в общий план. Это пример работы тезиса бережливого производства об устранении потерь, в данном случае — потерь времени на ненужное предварительное планирование.
