Часто в проектной деятельности можно встретить «конструирование», когда идет процесс поиска нужного решения из числа неких имеющихся готовых, либо путём их комбинирования.
В этом смысле, распространившийся в последнее время термин «легоконструирование» совершенно правильно отражает суть происходящего на занятиях по «робототехнике»: обучающимся объясняют, какие есть в конструкторе типовые элементы и узлы, и предлагают скомбинировать подходящее решение для поставленной задачи.
Однако проблемой конструирования является то, что мы можем понять, насколько результат соответствует ожиданиям, лишь когда проект выполнен. Поэтому если оказывается, что на каком-то этапе конструирования были приняты неправильные решения, то получается, что время, усилия и ресурсы потрачены непродуктивно.
Это не является особо критичным, если имеется достаточно времени и необходимых для выполнения проекта ресурсов, либо если проблема имеет простое и очевидное решение (ср. «Пока умный мост искал, дурак речку вброд перешёл»). Однако в ответственном проекте, когда время и/или ресурсы ограничены, риск неправильных решений в процессе конструирования резко повышается и принцип «Что тут думать, трясти надо!» перестает работать.
Второй проблемой тут становится то, что у конструирования нет обобщенного объекта, решение всегда конкретно, и а этом проблема его технологизирования: мы не можем отделить процесс создания конструкции от ее воплощения.
Другими словами, конструкция может быть реализована только ее автором, у которого необходимое для этого знание находится «на кончиках пальцев», и к процессу конструирования становится затруднительно подключить несколько участников, чтобы работа шла быстрее.
Более того, даже имея конструктивное решение в виде образца или чертежей, мы можем понять, как оно устроено, но не факт, что сможем понять, как это сделано!
Пример задания: мы видим, что ученик собирает что-то из конструктора. Как узнать, проектирует он или конструирует? Приведите другие примеры.
Проектирование – следующий уровень конструктивного мышления. Каждый советский школьник когда-то знал, чем отличается «самый плохой архитектор от наилучшей пчелы»: «прежде чем строить ячейку из воска, он уже построил её в своей голове. В конце процесса труда получается результат, который уже в начале этого процесса имелся в представлении человека11».
Мы говорим о «проектировании» (в частности, в проектной деятельности) тогда, когда прежде, чем, приступить к действиям, мы сначала можем переставить себе, что именно должно быть сделано для получения требуемого результата, и каким образом это должно быть сделано.
То, что мы знаем, что именно и как должно быть сделано, означает, что можно определить и то, какие виды работ потребуются, какие для них будут нужны средства, а, соответственно, еще до начала работ определить стоимость, сроки и другие условия реализации проекта.
Важно, что в нормальных условиях результат проектирования не остается «в голове» у его автора, а является «отчуждаемым»: результатом процесса проектирования являются инструкции, которые позволяют реализовать, воплотить проект всем, кто обладает необходимыми для этого компетенциями.
Поскольку при конструировании что делать знает только автор проекта, который может разве что привлечь кого-то себе в помощь под непосредственным руководством, то объем выполняемых работ по проекту будет так или иначе определяться физическими возможностями автора. А вот в результате проектирования создаются инструкции, которые могут быть выполнены неограниченным количеством исполнителей. В свое время именно поэтому проектирование сделало возможной первую промышленную революцию.
В процессе работы над конкретным проектом именно проектирование дает возможность распределить выполняемые работы между несколькими участниками с тем, чтобы сократить сроки выполнения работ.
Под проектированием далее будем понимать выделенный (отделённый от реализации) этап проектной деятельности, сутью которого является формирование представления о том, как будет решаться задача и подготовка инструкций по реализации этого решения.
Иногда под проектированием в узком смысле понимают процесс подготовки проектной документации. В таком случае проектирование в широком смысле будем условно называть «разработкой», а того, кто, исходя из понимания проблемы условного или реального «заказчика», может представить подходящее решение и подготовить инструкции для «исполнителей» как это решение практически реализовать – «разработчиком» (developer).
Рассматривая в дальнейшем структуру проектной деятельности, мы также будем исходить из того, что она предполагает проектирование в качестве одного из своих этапов.
Последовательность проектной деятельности типична для большинства видов целенаправленной деятельности: сначала надо понять, в чем проблема, потом представить, как она может быть решена и затем реализовать это представление.
Строгого говоря, проектная деятельность и есть разновидность целенаправленной деятельности, где целью становиться представление о желаемом результате, и в простейшем случае это то самое «Сначала подумай, потом делай!».
Но давайте посмотрим, как это работает, более детально, на каких-то всем известных примерах. Вот, скажем, обращение больного к врачу можно тоже рассматривать как проект: у больного есть некая проблема, надо понять, в чем ее суть, понять, как ее устранить и предпринять необходимые действия (обладая, как говорили выше, необходимыми средствами и компетенциями).
Понимание сути проблемы в медицине называется диагностикой, на ее основе строится стратегия лечения и назначаются соответствующие процедуры:
Тут важно различать функциональные роли в проекте и конкретных лиц, которые этот проект выполняют. Так, семейный доктор может и осмотреть больного, и поставить диагноз, и решить, как именно лечить, и сам будет делать необходимые процедуры. А в современных клиниках эти роли оказываются четко разделены между специалистами, обладающими необходимыми компетенциями.
К примеру, главный герой известного сериала «Доктор Хаус» был именно диагностом, а стратегию лечения на основе поставленного им диагноза предлагал часто уже другой врач. Те, кто смотрел сериал, обратят также внимание, что хотя доктор Хаус часто сам осматривал больного или выполнял процедуры, но чаще всего он поручал сделать анализы, МРТ или собрать информацию кому-то другому. Соответственно, у нас в схеме появляется еще одна роль, связанная со сбором данных, необходимых для постановки диагноза.
Кроме того, обычной практикой является, когда разделены функции определения стратегии лечения и «назначения лечения», как плана процедур, которые будут выполнятся средним или младшим медицинским персоналом. Обычно такое назначение лечения делает врач-ординатор.
Ровно те же этапы присутствуют в любой проектной деятельности, хотя, в зависимости от ее предмета, как уже говорилось, функциональные этапы и соответствующие роли могут называться по-разному.
Возьмем строительство. Если требуется «нестандартная» постройка, то сначала надо «поставить диагноз» – понять, что именно требуется заказчику, для чего собрать информацию о требованиях к проекту и подготовить эскизное предложение.
Если оно устроит заказчика, то разрабатывается архитектурная концепция, которая содержит всю необходимую информацию для принятия решения о строительстве объекта.
Далее, на основании архитектурной концепции разрабатывается рабочий проект, содержащий, по сути, инструкции для строителей, которые обеспечат практическое воплощение архитектурного замысла, ранее согласованного с заказчиком.
Аналогичные этапы присутствуют также, к примеру, в машиностроении и разработке автоматизированных систем управления (ГОСТ 3412), что, кстати, имеет непосредственное отношение к проектной деятельности в предметной области «Технология».
Так, в машиностроении эскизному предложению обычно соответствует «техническое предложение», архитектурной концепции – «эскизный проект», а вместо строительно-монтажных работ будет собственно «производство».
Давайте обобщим смысл этапов работы над проектом и поймем, в чем состоит их суть, вне зависимости от конкретной предметной области.
Итак, сначала мы собираем информацию о проблеме, подлежащей решению и о требованиях к этому решению. Затем – «ставим диагноз»: представляем как может «выглядеть» решение данной проблем, каким образом она будет решаться в рамках данного проекта: например, больной должен быть избавлен от такой-то болезни, человек, которому нужен дом, снимет свою проблему, если у него будет дом, который выглядит вот так-то, проблема заказчика детали будет решена, если он получит деталь вот с такими и такими параметрами.
Другими словами, собрав информацию о проблеме, мы предлагаем некий образ ее решения, который и становится целью дальнейшей деятельности!
Представив себе что решит проблему, на следующем шаге мы должны понять, как это может быть устроено или реализовано.
Предпоследний шаг – это реализация, воплощение предлагаемого решения. Но для этого мы должны расписать для исполнителей конкретные инструкции, которым они должны будут следовать, чтобы проблема была решена. А выше мы выяснили, что эта стадия у нас считается проектированием.
Таким образом, получаем следующую обобщенную последовательность этапов работы над проектом:
Выше мы договорились считать проектированием стадии по формированию и подготовке к реализации предлагаемого решения. Соответственно, часто проектировщик или разработчик (developer) – это обобщенное название специалистов, выполняющих в проекте проектирование.
Те же этапы будут присутствовать также и в «исследовательском» проекте, просто будут, соответственно, иначе называться.
Данная последовательность фаз или стадий проекта, продолжающаяся от начала до окончания проекта называется жизненным циклом проекта13. Жизненный цикл проекта является частью общего жизненного цикла продукта, начинающегося с момента рождения идеи продукта, через его создание к эксплуатацию, вплоть до окончания использования и последующей утилизации.
Стадии эксплуатации и утилизации редко попадает в учебные проекты, и тут не рассматриваются, но возможны и «особые случаи», когда тема прямо связана с утилизацией или эксплуатацией – к примеру, надо сделать биоразлагаемую упаковку.