В проектной деятельности часто говорят о жизненном цикле проекта. Что это такое, как организовать работу над проектом, как выглядит проектный цикл на примере космической отрасли, показывает Алексей Федосеев.
Схема жизненного цикла проекта
Напомним классическую для инженерии XX века схему жизненного цикла проекта: постановка проблемы, идея, планирование, разработка, испытания, внедрение, утилизация. Вариант два: мы поняли, что сделали не то, и проходим цикл заново. Вариант три: мы уходим на новый цикл проекта следующего уровня.
Для понимания проектного цикла нужно разобраться в том, что постановка проблемы — это обнаружение разрыва в реальности, который не решается существующими средствами. Классический пример из истории космической инженерии — мониторинг пожаров. Огромная территория страны, принципиально невозможно обнаружить за тысячу километров от нас, в тайге, на севере, очаг пожара, который важно начать тушить в ближайшие сутки. При этом нет средств обнаружения, нет людей, которые жили бы на этой территории и сообщали о пожарах, нет возможности патрулировать территорию на самолетах. Отсутствие. Разрыв. Мы обнаружили проблему.
Теперь начинаем конструировать решение: превращать проблему в идею. Новые технологии дают нам возможность закрыть разрыв: мы отправляем на орбиту аппарат или набор аппаратов, и они обеспечивают мониторинг пожаров. Мы начинаем двигаться по циклу: планировать работы, считать ресурсы, запускать работы, получать результаты.
На стыке между постановкой задачи и разработкой решения существует критически важный этап постановки ТЗ. ТЗ задает рамку, внутри которой действуют инженеры. На этапе обсуждения ТЗ уже можно обсуждать стоимость решений. Например, чем выше орбита спутника, тем дороже будет его выведение в космос, зато аппарат сможет видеть большую площадь поверхности. Если спутник находится на низкой орбите — его будет дешево выводить, но он будет все время куда-то улетать, поэтому нужно много аппаратов. Этот дизайнерский выбор решений — наиболее сложная и интересная часть инженерной разработки, поэтому там применяют моделирование и симуляторы. Есть специальные оценочные модели, суперупрощения, которые позволяют грубо оценить инженерные решения на ранних этапах, например, стоимость килограмма спутника. Именно на этапе постановки ТЗ собирается команда, распределяются задачи.
Большая компания имеет возможность организовать множество разных проектных команд так, чтобы кто-то работал на проверочных и эскизных проектах, а кто-то вел большой проект. Космические стартапы не могут себе это позволить, они последовательно делают проекты одной командой, запускают пробные аппараты.
Логика учебного проекта принципиально иная. Школьники в большой степени будут исходить из своих возможностей, а не только из проблемы. Например, на проектной смене они будут думать, какую исследовательскую задачу решает их кубсат, и им нужно привлекать специалистов по исследованию космических лучей.
Дальше в проектном цикле идет разработка решения. Это самая понятная часть, где нужно работать, удерживая требования, сроки, ресурсы. Управление разработкой в реальных проектах осуществляет кто-то из команды, а в детско-взрослом проекте с координацией помогают взрослые.
Испытание опытного образца — когда мы переходим от технологии к продукту — очень важный этап. Дальше внедрение и употребление. В случае спутника утилизация проектируется сразу. На низких орбитах это проще: спутник сгорает в атмосфере. Большие и тяжелые аппараты на высоких орбитах не спускают вниз — есть риск задеть другие аппараты. Их уводят на пустые орбиты, орбиты захоронения, где летают мертвые корабли. Они будут летать очень долго, пока существует Земля, потому что никакая сила не заставит их приблизиться к планете.
В идеале утилизация — очень важный этап, и это не просто захоронение, а присвоение полезного, как в живых системах. В современных кружках мы очень редко доходим до этого этапа: не учимся на ошибках своих проектов, не умеем присваивать полезное, превращать его в следующие шаги. Для нас, как для Кружкового движения, это точка поиска в проектной деятельности.
Жизненный цикл в ИТ и киберфизике
В отличие от ИТ, космический инженер не может пройти по проектному циклу несколько раз. Запустив аппарат в космос, мы можем только получать его данные, в лучшем случае — немного что-то перепрограммировать. Поэтому нужно максимально много промоделировать, протестировать и верифицировать.
Напомним схему разработки проекта в ИТ и киберфизике: мы движемся по спирали. Одновременно может происходить внедрение и разработка нового решения, может подменяться проблема. Когда мы говорим про киберфизические системы в космосе, например Starlink, мы говорим про «вечную» доработку. Этапы разработки, испытания и внедрения начинают «заползать» друг на друга. Систему нужно проектировать так, чтобы ее можно было модифицировать, или так, чтобы она могла работать, даже когда какой-то из узлов перестал работать.
В космической инженерии интересно соотносятся собственно инженерные и исследовательские проекты. Есть область исследований, например, космическая медицина или теоретическая физика. В ней есть программа исследований — например, в НИИЯФ МГУ изучают космические лучи сверхвысоких энергий: как они бьют в атмосферу, и по каскаду широких ливней мы восстанавливаем, откуда что прилетело. Внутри этих программ возникают исследовательские проекты, и для них необходимы бывают инженерные проекты — например, запуск кубсата. Вся эта система подчинена большим исследовательским программам, и это значит, что школьник сам не поставит проблему: он самостоятельно не может выйти на этот уровень, ему необходима постановка проблемы от эксперта.
Схема учебного проекта
Схема учебного проекта — это редуцированная версия схемы жизненного цикла. Внедрение не запланировано. Достаточно прототипа, который показывает, что команда разобралась в проблеме, получила обратную связь от экспертов. В проекте есть важный этап рефлексии, где присваивается опыт, полученный участниками. Присвоить результаты проекта не получается — это возможно только после прохождения полного жизненного цикла, а присвоить опыт команды можно.
Заметим, инженеры часто останавливаются на этапе испытаний — и не только в школьных проектах, но и в большом мире. Запуска аппаратов можно ждать по два года, а потом запуск отменяется.
Схема учебного проекта рабочая и отлаженная, в ней два фокуса и два результата: продуктовый и образовательный результат. Есть проектная команда и внешние роли: наставник (удерживает норму), стейкхолдер (запрос и ресурсы) и пользователь (обратная связь). Внутри проекта выделяются проектировщик техносоциальной системы (предприниматель), дизайнер продукта и разработчик решения (инженер).
Но у этой схемы есть недостаток: она сфокусирована на проектном замысле. Из-за того что команда не доходит до внедрения, она не может разобраться, решает проект проблему или нет. В лучшем случае команда получает экспертную оценку. Но это не сравнится с полным прохождением проектного цикла. Даже в инженерном соревновании, таком как соревнования студенческих гоночных болидов «Формула Студент», инженер получает мощную обратную связь, когда пилот команды на сконструированном болиде проехал по треку и занял предпоследнее место. А еще мощнее обратная связь, когда аппарат улетел в космос, работал — и вдруг перестал. И команда понимает, что при разработке решила пренебречь вспышками на Солнце, потому что их было слишком дорого экранировать, а аппарат сгорел при первой же такой вспышке.
Этап внедрения. Нам, как педагогам, интересно думать о проектах с внедрением. И это значит, что проектная общность не должна развалиться после защиты. На наши проектные школы на Ладоге молодые инженеры приезжают через год и бывают шокированы тем, что их решениями, сделанными на благо острова Кильпола, не пользуются. Не пользуются беседкой, которую заливает дождем из-за ошибки в проектировании свеса крыши, проектами умного энергообеспечения, интерактивными системами. И наступает момент самоопределения: школьник хочет заниматься своим проектом всерьез и долго? Воли надолго работать над конкретным проектом у людей в подростковом возрасте очень мало.
Схема проекта с внедрением требует новой сущности — проектной общности. Например, вчерашние школьники ездят на Ладогу, выступают как помощники наставников и волонтеры и заодно поддерживают свой школьный проект.
Иногда совместный бизнес является инструментом, который позволяет удержать проектную общность. Инженер ведь смотрит на проект изнутри: наша команда придумала решение. В тот момент, когда инженер доходит до необходимости масштабировать и внедрять, он теряет волю и все бросает. Предприниматель смотрит снаружи. Ему важнее не то, что мы сделали, а для кого сделали, где найти ресурсы.