Проект? - Это просто! Часть 5. Документы и роли проекта

Еще всего лишь лет 200-300 назад мир был устроен так, что что если ты чего-то придумал, то сам должен был суметь и сделать, либо стать над душей у того кто может: «отдать что-то в производство» было невозможно — не было подходящего «языка», чтобы объяснить кому-то, что тебе нужно. Точно так же, если ты умел что-то сделать, а не мог ничего нового придумать — тоже приходилось искать, кто бы тебе такую работу дал…

Все изменилось с появлением проектирования, и практически все, что мы вокруг себя видим, появилось потому, что одному в голову пришла хорошая идея, другой понял, как можно было бы ее реализовать, третий расписал инструкции для того, кто может сделать, тот сделал, и вот уже мы все этим пользуемся… А формат «проекта» позволил всем им сработать вместе, понимая друг друга…

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

Предыдущий материал: Идея, интересы, требования, концепция и архитектура

Ранее мы определили основные этапы проекта, а затем их частично детализировали. И почти сразу возник вопрос — а кто какую работу в проекте делает и кто за какой этап отвечает? Кто, к примеру, выбирает способ решения проблемы — сам потребитель? Ожидает этого от «разработчика»? Просит совета у соседа? Привлекает внешнего консультанта?

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

Некоторые «роли» мы уже обозначили. К примеру, «потребитель» решения — тот, чья проблема решается данным проектом. Физически — это может быть кто угодно: проект может быть сделан для мамы, папы или бабушки, для друга или соседа, для организации-партнера, «для учителя», чтобы поставил хорошую отметку, «для школы», чтобы «защитить ее честь» на конкурсе, и даже для себя самого, чтобы потом пользоваться.

К сожалению, даже роли в разных предметных сферах называют по-разному, так что используем самые типичные…

Потребность, проблема, мотив — обычно за «потребителем».

Работа с требованиями и предложение идеи (концепции) решения, обычно за «аналитиком». Причем, поскольку, как говорили, есть две группы требований — касающиеся проблемы потребителя и касающиеся непосредственно разработки, то аналитики бывают разные: как правило, «бизнес-аналитик» работает со стороны бизнес-заказчика или как привлекаемый консультант, а со стороны «разработчика» с требованиями работает «системный» аналитик.

В крупных проектах непосредственно сбор требований и их анализ разделяют, и собирают их, к примеру, инженеры по требованиям, а уже анализ выполняют аналитики — так, доктор Хаус в известном сериале делал выводы на основе результатов исследований и анализов, но собирали эти данные другие «специально обученные люди».

Архитектурой систем логично занимается «архитектор», и это всем известно по сферам строительства и IT. Проектированием — «проектировщики». Если в проекте есть взаимодействия с человеком, и требуется проектировать сценарии этого взаимодействия, пользовательские интерфейсы и т.п. — в проекте может появится «дизайнер». «Инженер» в проекте отвечает за формальную реализацию требований — чтобы получилось именно то, что было задано, работало надежно и как нужно. Важно, что за это инженер несет ответственность, вплоть до уголовной.

К примеру, если вам построили дом, а он взял и развалимся, то отвечать будет не архитектор, предложивший его образ, и не дизайнер, разрабатывавший интерьер, а инженер, делавший расчеты…

Реализуют проект, воплощают решение обычно профильные специалисты, а используют — «пользователи».

Для простого индивидуального или группового школьного проекта обычно достаточно пяти ролей «потребитель», «аналитик» (он же «архитектор»), «проектировщик», «мастер», «пользователь».

Важно, что каждый этап проекта имеет на выходе конкретный результат, с которым роль в проекте прямо связана:

Аналитик — тот, кто взаимодействуя с потребителем и другими заинтересованными лицами, готовит реестр требований, который станет основой для разработки концепции, а зачем участвует вместе с архитектором в разработке концепции.

Архитектор — вместе с аналитиком разрабатывает некое «первичное описание» того, как «выглядит» (концепция) и как «устроено» (архитектура) решение.

Проектировщик — на основе концепции и архитектуры решения составляет «описания» и «инструкции» как «мастеру» (мастерам) предложенное решение практчески реализоват.

«Мастер» — непосредственно воплощает решение, следуя полученным от проектировщика описаниям и инструкциям

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

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

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

Те, кто знаком с программированием, увидят, что разные этапы работают как функции в программе, но данные между ними передаются через согласованные интерфейсы; если нужные данные не переданы следующей функции в нужном ей формате, то программа работать не будет!

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

О том, как работает такой модуль — или человек в данной роли! — мы судим по тому, что он выдает, получив «на вход» нужные данные!

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

Именно такая организация работ в проекте позволяет команде проекта быть взаимозаменяемой и взаимодействовать с остальным миром (хотя бы на уровне использования материалов и комплектующих), где действуют именно эти принципы!

Можно встретить еще такое распределение функций по ролям:

• Идея и концепция на основе анализа требований — аналитик
• Основные принципы возможного решения — архитектор
• Составление инструкций по реалиации — проектироващик
• Собственно реализация — специалисты, «мастера», исполнители и пр.

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

Жили-были мыши. Все их обижали. И пошли мыши к Мудрой Сове:
— Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать?
Подумала сова и говорит:
— Мыши! Станьте ёжиками! Будете колючими и за вами охотится перестанут.
Побежали мыши радостно:
— Станем ёжиками! Станем ёжиками!
Вдруг одна остановилась:
— А кто-нибудь знает, как стать ёжиками?
Никто. Побежали обратно к сове.
— Сова! А как нам стать ёжиками???
— Мыши! Реализация — не ко мне! Я — аналитик!

Поэтому в небольшом проекте функции аналитика (кто представляет как может быть) и архитектора (кто понимает, как это может быть сделано) либо объединяются, либо они работают совместно.

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

• проблема
• идея
• требования
• концепция
• архитектора
• проектирование
• реализация

Для своей темы проекта уточните, как называются этапы и соответствующие им роли в данной предметной сфере.

(Продолжение следует)

К оглавлению