Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Проекты и программы

За последние полгода я познакомился с огромной литературой по проектам и программам, ибо мало иметь опыт в них участия, нужно уметь еще и говорить об этом. Неделю назад я попытался написать на эту тему обстоятельный постинг, обложившись книжками и файлами. И потерпел фиаско: эта тема настолько необъятна, что цитировать разную литературу можно бесконечно. И тогда я договорился с собой, что напишу очень кратко и не заглядывая в книжки.

Проекты бывают классические (по версии PMBoK, project management body of knowledge) -- некоторое усилие-старание (endeavour), направленное на создание уникального продукта или услуги (service). У проекта есть дедлайн. Уникальность отличает проект от операций.

В жизни классические проекты можно встретить преимущественно в сборочных активностях (когда нужно собрать что-то большое из многих-многих мелких деталек). Тогда можно не спеша и качественно все спланировать, а затем выполнить этот план, используя запланированные заранее ресурсы в запланированное заранее время. И все будет ОК. Проблемы начинаются там, где по ходу дела меняются цели проекта, дедлайн время от времени приближается, а начальники, как водится, непрерывно вносят изменения в доступность ресуров. Тогда мы имеем дело с экстремальным управлением проектами (eXtreme project management, XMP. Он же -- radical project management). Да, именно так: это близкий родственник экстремального программирования в мире управления проектами. Основная фишка -- регулярное перепланирование и поддерживание тесных человеческих отношений в ходе выполнения работ. Основное состояние -- кувырком, потому как непрерывно перепланируются цели, сроки, ресурсы, способы работы и т.д.

Но это все были цветочки. Представьте, что у вас есть ресурсы (деньги, люди, оборудование), которые должны участвовать в нескольких проектах. Тогда вы должны работать с портфелем проектов -- программой. У программы нет дедлайна, дедлайны есть у проектов, входящих в программу. У программы вполне может быть бюджет. У классической программы управления проектами может не быть цели (они есть у отдельных проектов), но есть план-график, общий для входящих в нее проектов.

Но есть и неклассические программы (или наоборот, сверхклассические) -- "программы партии". Такие программы описывают туманное будущее -- широкими мазками -- и представляют собой, скорее, набор очень абстрактных целей. Они говорят "иди туда, никто не знает куда, найди то, никто не знает что". В подобного сорта программах объединяется исследовательская и проектная работа. Исследования говорят все более и более точные слова про цели, про возможные к использованию технологии, а проекты собственно делают шаги к этим уточняющимся целям. Такого сорта программы имеют стратегический уровень (идеологически сформулированные цели, никаких планов по их достижению, определение шагов -- конкретных тактических целей), тактический (исследовательские и проектные шаги в определенном направлении к конкретным целям) и оперативный (копошение внутри отдельных проектов). Поскольку внутри появились исследования, то планировать в таком исследовательско-проектном месиве уже почти невозможно.

Но и это еще не вся история: целью программы может быть или инженерное достижение, воплощенное в тупой материи (Манхэттенский проект, или проект засылки Лунохода на Луну), или проделывание чего-то с людьми (обеспечение развитого коммунизма/капитализма, реорганизация фирмы, церкви или государства). И вот тут выясняется, что классическая инженерная работа над людским материалом невозможна -- социальная инженерия ли, гуманитарные технологии ли, все одно получается много хуже, нежели с созданием атомной бомбы или полетом на Луну. Главное, невозможно построить сетевой график с ресурсами (комиссары? консультанты? политтехнологи? пасторы?), при котором можно думать о получении какого-то гарантированного результата даже по частным проектам в общей программе. Более того, технические требования на получение гарантированного результата тоже не могут существовать: на людей можно влиять, но невозможно предписывать их поведение (даже таким мощным инструментом, как нормативные акты).

Тем не менее, одни люди могут влиять на других людей (и необязательно силой. Могут влиять и уговорами, и материальными стимулами, и даже собственной "натурой" в некоторых случаях. Одни люди (организаторы) могут организовывать других людей (организуемых), создавая те или иные организации или даже общественные институты. Да, создавая и общественные институты -- их тоже создают люди (если нельзя назвать конкретного автора какого-либо института, то это еще не значит, что институты создают инопланетяне, или они появляются сами собой).

Организация1 программы организовывания организации2 -- вы еще не запутались? Просто организация1 организовывает организацию2 -- причем поначалу организация1 не вполне понимает, какая организация2 ей надобна, и понимание это появляется уже в ходе этого организовывания. На мой взгляд, довольно типичная ситуация. И в этой типичной ситуации невозможно использовать классические способы контрактации и планирования, использующиеся как при выполнении классических, так даже и экстремальных проектов. Программы организационного дизайна/редизайна требуют особых техник оценивания потребных на них ресурсов, особых техник контрактации спонсора программы с организаторами, особых техник планирования (непрерывного перепланирования), особых техник выполнения работы, особых техник использования результатов.

Увы, книжек про эти техники не пишут, почитать об этом негде, кроме редких иноязычных статей да немногих работ СМД-методологов по программированию. Подскажите, если ошибаюсь (литературы про change management не предлагать, это больше о проектах, а не программах).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 37 comments