Управление смысловыми решениями: почему на сложных проектах теряются не только сроки, но и смысл

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

Парадокс в том, что этот пласт проблем, с одной стороны, реален и очень болезнен для практики, а с другой довольно слабо решается теми инструментами, к которым творческая индустрия обычно привыкла.

Я независимый операционный продюсер и работаю с командами именно таких проектов. На ряде крупных проектов мы вышли на этот класс проблем не теоретически, а практически через ошибки, перегруз, потери времени, сложность передачи решений и постепенное понимание, что привычный набор инструментов закрывает только часть задачи. В итоге мы начали искать собственные подходы и пришли к практике, которая соединила новую управленческую методику и прикладной IT-инструментарий. Эта статья о таком опыте.

Материал будет полезен как ключевым творческим специалистам, так и управленцам: продюсерам, менеджерам, шеф-редакторам, арт-директорам, кураторам, архитекторам, дизайнерам, специалистам по мультимедиа и другим участникам сложных проектов, где большой корпус творческих решений должен быть не только придуман, но и согласован, передан дальше в работу, сохранён в целостном виде и реализован без смысловых и творческих потерь.

Содержание статьи:

В качестве базового примера я буду опираться на экспозиционные проекты — это крупные проекты с сотнями экспонатов, единиц мультимедийного контента, оборудования, смысловых и драматургических решений. Но сама проблематика не ограничивается музейной или выставочной сферой. Аналогичные сложности возникают в видео- и CG-производстве, мультимедиа, анимации, digital, издательской деятельности и других творческих индустриях, где итоговый продукт собирается из большого числа взаимосвязанных авторских и проектных решений.

Ключевая ценность подхода, о котором пойдёт речь, в том, что подобные решения сегодня возможно начинать внедрять силами самой проектной команды: без большой собственной разработки, без тяжёлого входа в корпоративный IT-контур, без закупки дорогих специализированных систем и без обязательного привлечения программистов на старте. Делать это можно постепенно, в том ритме, который конкретной команде на конкретном проекте действительно посилен.

Под смысловой проектной информацией я понимаю ту информацию, которая содержит конкретные смысловые и творческие вводные, утверждения, гипотезы, ограничения, замечания, корректировки и фиксирующие решения. Она может существовать в виде текста, иллюстративного материала, таблиц, презентаций, комментариев, схем, сообщений, устных договорённостей и в других формах.

Именно этим она отличается от другой проектной информации — договорной, юридической, финансовой, административной, календарной, технической и иной служебной информации.

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

На практике смысловая информация формируется из нескольких основных источников.

Это лишь основные источники. В реальности корпус такой информации значительно шире и постоянно пополняется. Именно им на протяжении всего жизненного цикла проекта вынуждена оперировать вся проектная команда.

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

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

Этот хаос обычно распределён сразу по нескольким средам:

Но дело не только в объёме информации и не только в файловом хаосе. Главная трудность глубже.

Смысловая информация сама по себе — это ещё не решение. Это контекст, на который мы опираемся для принятия решений. И его критически важно связывать с тем уровнем проектной структуры, на который он влияет.

Одна новая вводная может относиться ко всему проекту, к одному конкретному смысловому объекту или даже к отдельной смысловой единице внутри него. Более того, одна и та же вводная может затрагивать сразу множество объектов и специалистов.

Именно поэтому смысловая информация требует не только хранения. Она требует операционной связки с теми проектными сущностями, на которые работает.

Смысловое решение проекта — это не абстрактная творческая идея и не один отдельный документ. Это совокупность согласованных решений по всем смысловым объектам проекта.

Иными словами, проект, как смысловой и творческий, считается решённым тогда, когда решён корпус его смысловых объектов.

Но и каждый смысловой объект решается не сам по себе. Он складывается из более частных решений по отдельным смысловым единицам — параметрам, свойствам, аспектам, позициям, за которые отвечают разные специалисты.

Таким образом, у нас есть два верхних уровня:

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

Если декомпозировать проект как комплексное творческое и смысловое решение на его конкретные составляющие, мы получим набор смысловых объектов. Для управления проектом такая декомпозиция необходима: без неё невозможно ни контролировать развитие решения, ни обеспечивать его согласованность, ни передавать его дальше в производство.

В экспозиционном проекте смысловыми объектами могут быть:

Именно из таких объектов в итоге и собирается общее смысловое решение проекта.

Задача команды — как творческой, так и менеджерской — состоит в том, чтобы:

Именно здесь возникает вторая принципиальная сложность.

Рассмотрим для примера смысловой объект «экспонат».

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

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

Именно здесь попытка управлять всем этим только через таск-менеджеры, канбан-доски, CRM, CMS или даже большие корпоративные системы начинает давать серьёзные сбои.

На первый взгляд может показаться, что описанная проблема решается обычными системами управления проектами и задачами. Но на практике это работает только до определённого масштаба и только в очень упрощённом виде.

Попытка свести его к линейному таску быстро приводит к ряду проблем.

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

Если декомпозировать проект на смысловые объекты в таск-менеджере через подзадачи, проект очень быстро получает сотни, а затем и тысячи административных единиц, которые нужно обслуживать: ставить, принимать, актуализировать, менять статусы, синхронизировать между собой. В любой индустрии это сложная задача. В творческой среде, где такая обслуживающая активность для конечного специалиста — художника, редактора, архитектора, куратора — часто глубоко неорганична, это становится особенно тяжёлой проблемой.

Если создать ещё один слой подзадач уже по категориям смысловых единиц, система очень быстро превращается в тяжёлую административную конструкцию, поддерживать которую в живом состоянии практически невозможно.

На практике поэтому почти неизбежно возникает разрыв.

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

Даже такие гибкие инструменты, как Excel, Google-таблицы или Notion, на определённом масштабе уже не дают комфортной среды одновременной работы большого числа специалистов с большим корпусом взаимосвязанных решений. Они могут быть полезными частями режима работы, но перестают быть достаточной средой для управления проектом как целостным смысловым решением.

В результате возникают последствия, знакомые очень многим командам:

Причин для таких последствий на сложных проектах и без того немало. Но этот пласт проблем — отдельный, системный и, что особенно важно, решаемый.

Если собрать сказанное выше в одну формулу, то мы имеем не одну, а несколько связанных групп проблем.

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

Каждый смысловой объект — это многосоставная проектная сущность, внутри которой работают разные специалисты, разные циклы, разные критерии готовности и разные режимы согласования.

Смысловую информацию недостаточно просто хранить. Её нужно адресно связывать с теми смысловыми объектами, единицами и зонами ответственности, на которые она влияет, чтобы специалисты могли оперативно проводить аудит своих решений и выявлять коллизии.

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

Если говорить максимально прямо, то проектной команде нужен не просто очередной архив документов и не просто ещё один таск-менеджер. Ей нужен инструмент, который позволял бы работать одновременно:

Когда ещё в 2021 году мы с проектной командой сформулировали эту проблему именно в таком виде, первый естественный шаг был очевиден: посмотреть, какие готовые решения уже существуют на рынке.

Мы изучили те инструменты, которыми уже пользовались, и ряд других систем, предлагаемых рынком. Но довольно быстро стало ясно: специализированных систем именно для управления таким типом творческих и смысловых процессов практически нет.

Что мы увидели на практике.

Существуют масштабные системы уровня SAP и им подобных, которыми управляются большие корпоративные и индустриальные контуры. Но для нашей задачи они оказались слишком тяжёлыми, дорогими и инерционными. Стоимость внедрения и сроки запуска в таких случаях сопоставимы уже с самостоятельным крупным проектом.

Более массовые инструменты — Мегаплан, Битрикс, Asana, ПланФикс, Яндекс Трекер, Jira и аналогичные системы — решают часть вопросов, но не закрывают всю архитектуру задачи. Они хорошо работают как среды задач, процессов, коммуникаций, заявок и контроля сроков, но не ориентированы на корпус сложных смысловых объектов и их многослойную творческую разработку.

Профильные музейные системы, например КАМИС и сходные решения, решают собственный круг задач: инвентаризацию, каталогизацию, учёт музейных предметов, связь с государственными реестрами и т.д. Но они не предназначены для управления процессом разработки и производства экспозиционного проекта как сложного корпуса смысловых решений.

Существуют и отдельные инструменты для ведения баз знаний, справочников, CRM-подобных процессов и других частных задач. Но они, как правило, закрывают только отдельные фрагменты задачи, плохо поддаются сложному развитию и не дают гибкой целостной проектной среды.

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

Итог оказался довольно закономерным.

Как выяснилось на практике, для нишевого сегмента разработки и производства экспозиционных проектов специализированных систем такого класса попросту нет. Более того, аналогичная нехватка ощущается и в других творческих нишах, где итоговый продукт складывается из большого числа взаимосвязанных смысловых решений.

Мы попробовали этот путь и довольно быстро получили убедительный результат: без собственной большой разработки, без программистов на старте и силами самих проектных специалистов.

Самые первые шаги этого опыта я уже описывал ранее в статье «CRM для экспонатов».

За последние пять лет разные версии системы — под конкретные проекты, команды или отдельные задачи — были собраны на разных платформах конструкторах таких систем: QuintaDB, Airtable, BPium и SeaTable. Подробнее о каждой из них и о критериях выбора я расскажу в следующей части этого материала.

С тех пор прошло немало времени. На одном из последних музейных проектов — площадка около 4 000 кв. метров, 20 залов, более 300 экспонатов, более 400 единиц мультимедийного контента, более 5 000 объектов авторского права и более 300 правообладателей, общий цикл работ более двух лет — первоначальные прототипы получили развитие в полноценную информационную систему и операционную среду, состоящую из нескольких связанных модулей. В сумме с ней работали уже сотни специалистов, включая подрядчиков и смежников.

А начиналось всё значительно скромнее: с одной реляционной базы, собранной на no-code платформе под небольшую, но критичную часть проектного процесса на крупном экспозиционном проекте. Эта база была придумана, собрана и наполнена реальными данными за две недели и сразу стала рабочим инструментом команды.

Проблема управления смысловой информацией и связанными с ней смысловыми решениями на сложных проектах реальна. И сегодня её уже можно начинать решать силами самой проектной команды — если рассматривать систему не как абстрактную «цифровизацию», а как рабочую среду управления контекстом, объектами, связями, ответственностью и решениями.

Главный вывод первой части для меня в том, что подобная система не обязана начинаться с большой реформы, отдельного IT-проекта или сразу с исчерпывающего описания всех будущих модулей. Если у неё правильно собрано ядро, она может расти постепенно: от одного живого рабочего контура — к более зрелой информационной системе и полноценной операционной среде.

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

По этой оценке система давала в работе следующие устойчивые эффекты.

Если пытаться перевести эти эффекты в осторожные количественные оценки, то на последнем крупном проекте я бы оценил сокращение части рабочих согласований и ряда сопутствующих коммуникаций как минимум в десятки процентов, а общий экономический эффект от снижения потерь, переделок и неслучившихся рисков — как минимум заметный на масштабе всего проекта. Это не строгая финансовая модель, но как продюсер я хорошо вижу, что система даёт не только удобство, а вполне реальный производственный выигрыш.

Во второй части я подробнее разберу, как устроена логика такой системы: из каких сущностей она собирается, как в ней связываются объекты, контекст, статусы и роли, и почему подобную среду сегодня можно начинать собирать силами самой проектной команды.

В третьей части — как такой подход внедряется и развивается на практике: какие рабочие эффекты он даёт, какие гипотезы подтверждаются или не подтверждаются, какие платформы для этого подходят и как подобная система может расти вместе с реальным проектом.

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

Сейчас я вижу в системе и серьёзный продуктовый потенциал. При этом мне по-прежнему важна её дальнейшая проверка и развитие на реальных проектах — там, где подобная среда действительно востребована и может быть проверена в живой работе.

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