Как сделать проектное задание

Обновлено: 08.07.2024

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

Этапы проекта

Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.

Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.

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

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

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

Проектные артефакты

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

Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.

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

Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.

Реализация: акт сдачи-приёмки работ, замечания и доработки.

Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.

Так могут выглядеть основные артефакты по IT-проекту:

Техническое задание (цели, требования, техническая документация).
Паспорт проекта (свод данных, участники и их зоны ответственности).
Макеты и дизайн.
Результаты исследований.
Итоги встреч и других коммуникаций.
Список задач.
Итоги проекта (доступы, документация, права).
Планы на будущее (доработки).

Сбор артефактов

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

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

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

После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.

Виды артефактов

Артефакты делятся на формальные и неформальные.

Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.

Виды заказчиков

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

Государственный заказчик (управление, больница, школа).
Близкий к государственной сфере.
Бизнес-заказчик.
Стартап (небольшой бизнес-заказчик).

Зона ответственности заказчика

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

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

В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.

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

Чтобы составить матрицу RACI, нужно выполнить следующие шаги:

Составить список процессов или зон ответственности.
Выделить функциональные роли.
Назначить встречу с заказчиком и командой.
Описать матрицу.
Определить несоответствия (опционально).
Проконтролировать выполнение назначенных ролей.

При этом важно соблюдать основные принципы:

A должен быть в каждой задаче только один.
R должен быть в каждой задаче, и их может быть несколько.

Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!

Этапы проекта

Проектные артефакты

Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.

Реализация: акт сдачи-приёмки работ, замечания и доработки.

Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.

Так могут выглядеть основные артефакты по IT-проекту:

Техническое задание (цели, требования, техническая документация).
Паспорт проекта (свод данных, участники и их зоны ответственности).
Макеты и дизайн.
Результаты исследований.
Итоги встреч и других коммуникаций.
Список задач.
Итоги проекта (доступы, документация, права).
Планы на будущее (доработки).

Сбор артефактов

Виды артефактов

Артефакты делятся на формальные и неформальные.

Виды заказчиков

Государственный заказчик (управление, больница, школа).
Близкий к государственной сфере.
Бизнес-заказчик.
Стартап (небольшой бизнес-заказчик).

Зона ответственности заказчика

Чтобы составить матрицу RACI, нужно выполнить следующие шаги:

Составить список процессов или зон ответственности.
Выделить функциональные роли.
Назначить встречу с заказчиком и командой.
Описать матрицу.
Определить несоответствия (опционально).
Проконтролировать выполнение назначенных ролей.

При этом важно соблюдать основные принципы:

A должен быть в каждой задаче только один.
R должен быть в каждой задаче, и их может быть несколько.

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

Источник

Рамки исследования

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на проектирование программы.

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

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

Источник

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

Проектные решения VS проектной документации?

Как всё прекрасно на бумаге,
Как легко следовать словам.
Как просто сделать так, что ты непогрешим.

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

В сопроводительном письме присутствовала примерно такая фраза:

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

Описание слона не по ГОСТ

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

На мой взгляд, основным критерием хорошего описания постановки задачи (проектного решения) является не выполнение формальных требований ГОСТ, а однозначное описание условий успешного завершения работ по выполнению требований заказчика. С этой точки зрения, фактически неотъемлемой частью любого проектного решения является описание тестовых заданий по проверке требований.

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

описание автоматизируемого процесса (как правило, в формате BPMN – не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата;
перечень ролей и их полномочий;
определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) — пренебрежение данным пунктом может увеличить время разработки в разы;
определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).

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

определение атомарных действий, по которым должно (может) производиться ограничение доступа, определение иерархии этих действий;
определение перечня атрибутов объекта, по которым должно (может) производиться ограничение доступа.

Лучше один раз увидеть

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

Многое (если не все) на проекте зависит от того, как представители заказчика представляют себе конечный результат. Поэтому уже на начальных этапах проектирование макетов пользовательского интерфейса имеет ключевое значение для успешности проекта. Уточняйте и конкретизируйте требования заказчика в понятных ему терминах внешнего описания программного продукта. Диалог с представителями заказчика, основанный на обсуждении макетов экранных форм, показал себя гораздо более эффективным, чем диалог по обсуждению форматов входных и выходных данных и алгоритмов их преобразования (основные разделы в ОПЗ, созданном в соответствии с ГОСТ).

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

Хотелось бы сказать несколько слов о принципах проектирования пользовательских интерфейсов для автоматизированных систем управления. Несмотря на лавинообразный рост использования мобильных устройств, для автоматизированных систем управления, применяемых в государственных учреждениях, настольные компьютеры и ноутбуки остаются вне конкуренции (так же, как и для решения задач программирования и системного администрирования). В настоящее время для прототипирования интерфейсов появилось множество разнообразных средств. Однако за разъяснением особенностей применения Figma или Axure в интересах мобильных устройств теряются 10% примитивных способов, которые позволяют проектировать 90% пользовательских интерфейсов АСУ.

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

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

Я не буду приводить здесь пример интерфейса IntelliJ IDEA или PhpStorm, однако попробую препарировать на составные части основные составляющие такого UI, с точки зрения аналитика автоматизированной системы управления.

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

В рамках описания любой списковой формы при проектировании должны быть определены:

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

В рамках описания карточки объекта при проектировании должны быть определены:

Строительные леса и опалубка

Обычно люди очень много думают. Но беда в том, что они думают о проблемах, а не о решениях этих проблем.

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

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

План для маэстро

Всё должно быть изложено так просто, как только возможно, но не проще.

Зачастую, когда речь заходит о планировании работ по анализу и программированию, возникает множество споров о том, как можно оценить сроки получения результатов в этом случае. Однако проведенный выше анализ этой творческой деятельности позволяет сделать предположение о том, что в рамках программного проекта это все-таки возможно. Первым шагом к этому становится разбиение работ по проектированию системы на части, которые можно проконтролировать с периодичностью не менее раза в неделю. Необходимо стремится к тому, чтобы трудозатраты аналитика на формирование одного проектного решения не превышали 5 рабочих дней (в терминах объема такое проектное решение должно состоять примерно из 20-30 страниц – согласно ГОСТ Р ИСО/МЭК 15910-2002). Соответственно по тем же нормативам на рецензирование того же проектного решения у программиста должно уходить максимум 3 часа.

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

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

Как правило, для получения сроков выполнения задач на анализ, достаточно экспертной оценки самого исполнителя, но в случае возникновения споров можно применить прагматичный подход. Для повышения объективности оценки трудоемкости задач на анализ может быть использован online-калькулятор, который позволяет спланировать и оценить трудозатраты на проведение аналитической работы. С использованием данного инструмента можно сформировать перечень запланированных работ, уточнить их формулировки в зависимости от специфики проекта. Для каждой из планируемых работ учитывается минимальная, максимальная и наиболее вероятная оценка трудозатрат. В результате расчета формируется ожидаемая трудоемкость выполнения задачи и рассчитывается оптимальный резерв времени, который необходимо оставить для страховки. Сформированное описание постановки задачи на анализ можно скопировать прямо в поле описания задачи JIRA.

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

[A] — позволяет отслеживать изменения, которые вносятся в документ по замечаниям заказчика, при этом используются следующие цифры: 0 — для внутреннего рассмотрения (рабочий вариант); 1 — для первого документа, согласованного внутри компании, при передаче его на рассмотрение заказчику; 2+ - варианты версий при переделке по замечаниям заказчика.
[B] — позволяют отслеживать изменения, которые вносятся в документ по замечаниям членов проектной команды.

1. В случае необходимости ответственный аналитик должен запланировать в JIRA задачи на проведение информационных обследований с представителями заказчика (эти задачи связываются с соответствующими требованиями).

Желательно до встречи в первом приближении сформировать макеты пользовательского интерфейса, которые можно будет обсудить с заказчиком. При проведении информационного обследования необходимо обсудить с заказчиком основной бизнес-процесс, с его точки зрения (пользовательскую историю — user story), альтернативные пути, в каком виде заказчик видит конечный результат.

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

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

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

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

Послесловие

В рамках этого цикла настоящее время готовится к публикации:

Задачи проектной работы – этапы, которые нужно выполнить для достижения цели, поставленной при работе над проектной работой, включая как теоретическую, так и практическую часть.

Задачи во введении проектной работы

Задачи в проектной работе должны вытекать из поставленной цели и дополнять её так как они отражают выбранные пути для решения поставленной цели.

Особенности подготовки задач проектной (исследовательской) работы

Рассмотрим особенности подготовки задач в проектной работе:

После чего перечисляются задачи, каждая с новой строки.

Особенности подготовки задач в проектной работе

Примеры возможных глаголов, которыми можно начать характеристику задачи представлены ниже:

Выяснить
Доказать
Измерить
Изучить
Исследовать
Найти
Обобщить
Ознакомиться c
Описать
Определить
Познакомиться c
Показать
Получить
Предложить
Проанализировать
Провести анализ
Провести
Проработать
Проследить
Разработать
Рассчитать
Реализовать
Сделать
Собрать
Согласовать
Составить
Сопоставить
Сравнить
Узнать
Установить

Характеристика задач во введении проектной работы

Также для подготовки задач можно использовать такие конструкции:

Изучить литературу по теме .
Выяснить значение терминов …
Найти примеры … в … / собрать материал … / изучить состав … / измерить уровень …
Провести опрос / эксперимент /наблюдение/ анкетирование
Сравнить/ сопоставить /проанализировать полученные результаты
Сделать выводы о …
Познакомиться, понаблюдать…

Как сформулировать задачи в проектной (исследовательской) работе

Для того чтобы правильно сформулировать задачи проектной работы необходимо:

Определится с тем, как можно достичь поставленной цели т.е. какие необходимо рассмотреть материалы в теоретической части и на какие пункты можно их разделить (желательно 2-4 параграфа), например:
- изучить историю развития храмов Древнего Рима;
- рассмотреть основные храмы Древнего Рима;
- выявить особенности конструкции храмов Древнего Рима.

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

подготовка и проведение анкетирования одноклассников;
анализ полученных результатов;
разработка рекомендаций (если предполагает тема).

подготовительную (подготовка анкетных листов, материалов для проведения опытов, сбор информации, поиск информации или материалов и т.д.)
сам процесс реализации (анкетирование, опыты, расчёт каких-либо данных, анализ статистических данных, изготовление модели, макета, прибора и т.д.).

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

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

Ошибки при подготовке задач проектной (исследовательской) работы

Решая какие задачи необходимо решить в ходе выполнения проектной работы для достижения поставленной цели можно допустить ряд ошибок:

Задач в проектной работе не может быть меньше 2-х так как проектная работа не может состоять из 1 главы или параграфа.
Количество задач не соответствует количеству этапов, которые были реализованы в ходе выполнения проектной работы (обычно количество задач соответствует количеству параграфов, в некоторых случаях может быть незначительно больше или меньше).
Указаны лишние задачи:
- написание проекта;
- подготовка каких-либо конкретных разделов проекта (Введения, Заключения, Списка использованных источников);
- оформление проектной работы;
- подготовка продукта проектной деятельности;
- подготовка презентации и речи на защиту;
- защита проектной работы.
Большое количество задачи, не следует делать их больше 10 (для начальной школы не более 6).
Лишний текст – в задачах не описываются конкретные пункты, не используется текст по теме работы, не ставятся сноски.
Копирование чужих задач – каждая работа индивидуальна, используя чужие материалы хорошего результата добиться не получится, кроме того, это плагиат.
Неправильное расположение задач во введении – они должны находиться сразу после цели.

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

Учитель отбирает возможные темы и предлагает их учащимся.

Учащиеся обсуждают и принимают общее решение по теме.

Учитель предлагает учащимся совместно отобрать тему проекта.

Группа учащихся совместно с учителем отбирает темы и предлагает классу для обсуждения

Учитель участвует в обсуждении тем, предложенных учащимися.

Учащиеся самостоятельно подбирают темы и предлагают классу для обсуждения.

1.2. Выделение подтем в тем проекта

Учитель предварительно вычленяет подтемы и предлагает учащимся для выбора

Каждый ученик выбирает себе подтему или предлагает новую.

Учитель принимает участие в обсуждении с учащимися подтем проекта

Учащиеся активно обсуждают и предлагают варианты подтем. Каждый ученик выбирает одну из них для себя (т.е. выбирает себе роль).

1.3. Формирование творческих групп

Учитель проводит организационную работу по объединению школьников, выбравших себе конкретные подтемы и виды деятельности

Учащиеся уже определили свои роли и группируются в соответствии с ними в малые команды

1.4. Подготовка материалов к исследовательской работе: формулировка вопросов, на которые нужно ответить, задание для команд, отбор литературы

Если проект объемный, то учитель заранее разрабатывает задания, вопросы для поисковой деятельности и литературу

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

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

1.5. Определение форм выражения итогов проектной деятельности

Учитель принимает участие в обсуждении

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

2. Разработка проекта

Учитель консультирует, координирует работу учащихся, стимулирует их деятельность.

Учащиеся осуществляют поисковую деятельность

3. Оформление результатов

Учитель консультирует, координирует работу учащихся, стимулирует их деятельность.

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

4. Презентация

Учитель организует экспертизу (например, приглашает в качестве экспертов старших школьников или параллельный класс, родителей и др).

Докладывают о результатах своей работы

5. Рефлексия

Оценивает свою деятельность по педагогическому руководству деятельностью детей, учитывает их оценки

Осуществляют рефлексию процесса, себя в нем с учетом оценки других. Желательна групповая рефлексия

Векленко Светлана Ильинична

Этапы выполнения проектов (реализация проектной технологии)

Деятельность учителя

Деятельность учащихся

1. Разработка проектного задания

1.1. Выбор темы проекта

Учитель отбирает возможные темы и предлагает их учащимся.

Учащиеся обсуждают и принимают общее решение по теме.

Учитель предлагает учащимся совместно отобрать тему проекта.

Группа учащихся совместно с учителем отбирает темы и предлагает классу для обсуждения

Учитель участвует в обсуждении тем, предложенных учащимися.

Учащиеся самостоятельно подбирают темы и предлагают классу для обсуждения.

1.2. Выделение подтем в тем проекта

Учитель предварительно вычленяет подтемы и предлагает учащимся для выбора

Каждый ученик выбирает себе подтему или предлагает новую.

Учитель принимает участие в обсуждении с учащимися подтем проекта

1.3. Формирование творческих групп

Учащиеся уже определили свои роли и группируются в соответствии с ними в малые команды

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

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

1.5. Определение форм выражения итогов проектной деятельности

Учитель принимает участие в обсуждении

2. Разработка проекта

Учитель консультирует, координирует работу учащихся, стимулирует их деятельность.

Учащиеся осуществляют поисковую деятельность

3. Оформление результатов

Учитель консультирует, координирует работу учащихся, стимулирует их деятельность.

4. Презентация

Докладывают о результатах своей работы

5. Рефлексия

Оценивает свою деятельность по педагогическому руководству деятельностью детей, учитывает их оценки

Осуществляют рефлексию процесса, себя в нем с учетом оценки других. Желательна групповая рефлексия

Читайте также: