Методические рекомендации по представлению результатов проектной деятельности

 

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

- ПАСПОРТ ПРОЕКТА (см. приложение 1)

- ПИСЬМЕННЫЙ ОТЧЕТ ПО КУРСОВОМУ ПРОЕКТУ;

- ПРЕЗЕНТАЦИЮ РЕАЛИЗОВАННОГО ПРОЕКТА.

ПИСЬМЕННЫЙ ОТЧЕТ ПО КУРСОВОМУ ПРОЕКТУ является результатом проектной деятельности студентов, на его основе могут быть оценены результаты деятельности команды проекта. Качество его подготовки характеризует результативность проектной деятельности в целом. Наличие письменного отчета, подготовленного в соответствии с представленными требованиями, является обязательным условием получения зачетных единиц по дисциплине «Технология проектной деятельности».

ТИТУЛЬНЫЙ ЛИСТ письменного отчета по проекту должен содержать ряд формальных обязательных реквизитов. Пример титульного листа с содержанием полных реквизитов представлен в приложении 2.

СОДЕРЖАНИЕ должно наглядно демонстрировать этапы выполненного проекта. Предпочтительно, чтобы в содержании были отражены следующие разделы с постраничной нумерацией.

ВВЕДЕНИЕ............................................................................................

1 НАЗВАНИЕ ПЕРВОЙ ГЛАВЫ.........................................................

1.1 Название параграфа.........................................................................

1.2 Название параграфа.........................................................................

2 НАЗВАНИЕ ВТОРОЙ ГЛАВЫ.........................................................

2.1 Название параграфа.........................................................................

ЗАКЛЮЧЕНИЕ.......................................................................................

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ.............................

ПРИЛОЖЕНИЕ......................................................................................

Структура проекта определяется особенностями выбранной для решения проблемы, разработанной командой проекта логикой и методами выполнения проекта. Исходя из рекомендуемой структуры письменного отчета по проекту его объем должен составлять: – около 20 - 25 страниц. Примерный вариант структуры письменного отчета по проекту представлен в приложении 2. Предлагаемый вариант структуры является примерным, состав разделов по содержанию не является исчерпывающим и может варьироваться при определении содержания конкретного проекта командой во взаимодействии с руководителем проекта.

ПОДГОТОВКА ПРЕЗЕНТАЦИИ И ЗАЩИТА ПРОЕКТА.

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

В презентации проекта обязательно должны быть отражены следующие вопросы:

– проблема, на решение которой направлен проект, и ее значимость;

– структура и логика проекта;

– методы и инструменты, использованные для работы над проектом;

– результаты проектной деятельности.

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

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

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

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

• Оптимальное число строк на слайде – от 6 до 11. Перегруженность и мелкий шрифт тяжелы для восприятия. Недогруженность оставляет впечатление, что выступление поверхностно и плохо подготовлено.

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

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

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

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

В среднем время на презентацию одного проекта составляет 8-10 минут, 5–10 минут занимают следующие за докладом вопросы участников защиты.

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

КРИТЕРИИ ОЦЕНИВАНИЯ РЕЗУЛЬТАТОВ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ.

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

Таблица 1.

Критерии оценки проекта

Составляющие проекта	Критерии для оценивания
Постановка проблемы и ее обоснованность, формулирование целей и задач	Актуальность, теоретическая и практическая значимость выдвинутых проблем; корректность постановки целей и задач исследования, их соответствие заявленной теме и содержанию работы; степень реалистичности целей и задач; разумность масштаба работ.
Выполнение и оформление проекта	Объем и полнота разработок, самостоятельность, законченность, подготовленность предлагаемых решений; логичность, взаимосвязь и последовательность этапов реализации проекта; уровень творчества, оригинальность раскрытия темы, подходов, предлагаемых решений; обоснованность отбора теоретического материала; уровень используемого инструментария в работе над проектом; качество отчета: оформление, соответствие стандартным требованиям; стилистическое единство и языковая грамотность.
Результат выполнения проекта	Перспективы развития проекта после его завершения; соответствие ожиданий от проекта / планируемого результата полученному продукту; степень решения заявленной проблемы.
Презентация результатов работы, защита проекта	Качество доклада: композиция, полнота представления работы, подходов, результатов; аргументированность, профессионализм изложения результатов работы над проектом; ответы на вопросы: полнота, аргументированность, стремление использовать ответы для успешного раскрытия темы и сильных сторон работы.

 

Примерный вариант структуры письменного отчета по проекту:

 

МИНОБРНАУКИ РОССИИ

федеральное государственное бюджетное

образовательное учреждение высшего образования

«Череповецкий государственный университет»

 

 

Дисциплина_________ «Технология проектной деятельности»__________

 

Наименование курсового проекта ____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

 

Проектная команда: ___________________________________________________________________________          

                               ______________________________________________________________         

                               ______________________________________________________________         

                          ______________________________________________________________         

                               ______________________________________________________________

                               ______________________________________________________________

                               ______________________________________________________________

                               ______________________________________________________________

                               ______________________________________________________________

                               ______________________________________________________________         

                                           ФИО                                                           оценка

 

 

Руководитель проектного обучения: _________________________________________________

                                                                               ФИО                            Подпись

 

 

Череповец

2020                             

 

ВВЕДЕНИЕ

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

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

 

ГЛАВА I. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

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

 

1.1 Теоретико-методические основы исследования проблемы на основе анализа и систематизации существующих подходов к ее рассмотрению.

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

1.2 Технологии управления проектами.

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

Управление проектами – это планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта. (ГОСТ Р 54869―2011: Проектный менеджмент. Требования к управлению проектом). Грамотное управление проектами это методология, искусство организации, планирования, руководства, координации трудовых, финансовых, материально-технических ресурсов на протяжении всего проектного цикла, направленное на достижение его целей путем применения современных методов, техники и технологии управления для получения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.

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

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

Наиболее очевидный способ сделать свой проект более управляемым - это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Жизненный цикл в классическом варианте представляет собой последовательные шаги по разработке и реализации проекта. Рассмотрим их более подробно:

1. Вхождение в проект. Проблематизация.

- Выделение проблемы

- Генерация и систематизация идей

- Целеполагание, разбиение цели на задачи

2. Маркетинговый анализ.

- Анализ существующего опыта решения данной проблемы.

- Анализ информации о существующих аналогах продуктового результата.

3. Работа со стейкхолдерами и описание продуктового результата.

- Выявление требований к проекту через работу со стейкхолдерами.

-  Анализ продуктового результата.

4.  Планирование содержания проекта.

- Выбор технологии планирования.

- Составление плана реализации проекта.

5. Составление бюджета и определение рисков проекта.

6. Подготовка паспорта проекта.

7. Реализация проекта.

- Мониторинг хода реализации проекта.

- Ведение проектной документации.

8. Завершение и выход из проекта.

- Оформление и представление результатов.

- Рефлексия образовательного результата.

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

В классическом менеджменте выделяют 5 этапов проектного управления, но можно добавлять и дополнительные этапы, если того требует проект [4] https://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/.Рассмотрим 5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения.

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

Этап 5. Мониторинг и завершение проекта. В зависимости от проекта данная фаза может состоять из простой передачи Заказчику результатов проекта или же из длительного процесса взаимодействия с клиентами по улучшению проекта и повышению их удовлетворённости, и поддержке результатов проекта. Последнее относится к проектам в области клиентского сервиса и программного обеспечения. Все этапы проектирования представлены на рисунке 2.

Основная слабая сторона классического проектного менеджмента –недостаток гибкости, когда содержание проекта остаётся практически неизменным в течение всего проекта. Но если в проекте ресурсы и время не являются ключевыми ограничениями, а содержание проекта подвержено изменениям – возможно вам стоит присмотреться к другим системам управления проектами.

 

Рис.2 Схема классического проектного подхода.

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

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

Гибкие технологии Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на рисунке 3.

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

 

 

Рис. 3 Схема работы по Agile

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

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

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

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

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

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту, см. рисунок 4. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

 

 

Рис.4. Схема процесса Scrum

Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.

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

Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.

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

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

Однако, Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться.

Технология Kanban в отличии от представленных ранее позволяет оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может, быть как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей, рисунок 5.

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

 

Рис.5. Схема работы по Kanban

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

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

Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.

Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.

Постоянное улучшение (kaizen): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команд с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд. При правильной настройке и управлении, Kanban может принести большую пользу команде проекта. Точный расчёт нагрузки на команду, правильная расстановка ограничений и концентрация на постоянном улучшении — всё это позволяет Kanban серьёзно экономить ресурсы и укладывать в дедлайны и бюджет. И всё это в сочетании с гибкостью. Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

 

ГЛАВА II. ОПИСАНИЕ ЭТАПОВ ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА И РЕЗУЛЬТАТОВ ЕГО РЕАЛИЗАЦИИ

В практической главе письменного отчета по проекту проводится описание этапов работы над проектом. Структура курсового проекта:

I этап. Проблематизация.

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

2. Первая приблизительная формулировка проблемы (Методика 6-ти вопросов): что происходит? где происходит? когда происходит? сколько? откуда известно? почему это важно?

3. Поиск первопричин проблемы: Методика «5 Why».

4. Приоритизация первопричин: «Дерево проблем», «Диаграмма Ишикавы».

5. Итоговая формулировка проблемы: «Методика 5-ти вопросов» - Для кого? Для чего? Что хотим получить? Какие критерии? Какой срок?

6. Генерация идей  по сформулированной проблеме: «Мозговой штурм», «Метод шести шляп»;

7. Приоритизация и отбор идеи для реализации проекта: Проведение критического анализа и приоритизация сгенерированных идей; Ранжирование решений, «Множество Парето»).

8. Постановка цели и задач проекта («SMART», «GROW» и др.).

II этап. Маркетинговый анализ.

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

1. Проведение маркетинговых исследований;

2. Сбор, обработка и обобщение данных, полученных в результате исследований;

3. Выборка ключевых моментов по опыту решения данной проблемы из обработанных данных;

4.  Формулировка выводов.

III этап. Описание продуктового результата и показателей результативности проекта:

1. Анализ стейкхолдеров проекта: классификация стейкхолдеров по степени их влияния на проект и степени заинтересованности участия в нем. Определение перечня ключевых стейкхолдеров (Карта заинтересованных лиц, «Матрица влияния»).

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

3. Разработка индикаторов оценки успешности реализации проекта (KPI).

4. SWOT-анализ продуктового результата, выявление преимуществ и ограничений вашего продукта.

5. Формулировка ценностного предложения.

IV этап. Планирование содержания проекта.

1. Определение видов работ по проекту; структурная декомпозиция работ; оценка длительности выполнения работ.

2. Разработка календарного плана реализации проекта, (диаграмма Гантта).

3. Составление плана коммуникаций в проекте: внутренних (внутри команды проекта) и внешних (с внешними стейкхолдерами).

4. Формирование «Матрицы ответственности».

V этап. Составление бюджета.

1. Определение видов затрат по проекту и оценка их стоимости.

2. Определение источников доходов проекта.

3. Определение бизнес-модели проекта.

VI этап. Определение рисков проекта и разработка системы мер по управлению ими.

1.Составление реестра рисков проекта.

2.Качественная и количественная оценка рисков: определение ранга приоритетности риска по матрице «вероятность наступления — степень влияния».

3.Определение методов реагирования на риски: избежание, минимизация, передача, принятие.

4.Составление плана управления рисками.

VII этап. Реализация проекта (при завершении предыдущих 6-ти этапов)

1. Выбор подхода к управлению проектом: традиционная (каскадная) технология, гибкие технологии (Agile).

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

3. Мониторинг хода реализации проекта в контрольных точках.

4. Ведение проектной документации.

5. Проводится оценка индивидуального вклада участников проекта в командную работу.

VIII этап. Завершение проекта и выход из проекта.

1. Оформление и представление результатов проекта.

2. Рефлексия образовательного результата.

3. Анализ отклонений и трудностей, возникших в ходе выполнения проекта.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ должен включать все основные источники информации, использованные при выполнении проекта:

– нормативно-правовые документы,

– научные издания – монографии, периодические издания;

– статистические данные.

В ПРИЛОЖЕНИЕвыносятся материалы по проекту, которыеважны для понимания и подтверждения его результатов, но в силу объема или структуры не могут быть размещены в основном тексте письменного отчета по проекту.