Как оформить этапы работы над проектом

Обновлено: 13.05.2024

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

Содержимое публикации

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

Разберёмся в значении некоторых слов:

Алгоритм разработки проекта таков: проблема – цель – результат.

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

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

Поставить задачи. (Что необходимо сделать, чтобы достичь цели проекта.)

Наметить этапы работы. (Разделить всю работу на части)

Выбрать способы решения задач на каждом этапе.

Определить сроки выполнения работы (поэтапно и в целом).

Структура проекта такова: введение, основная часть, заключение.

1. Выбор темы. Тема – предмет рассмотрения; это то главное, о чём сообщается, что обсуждается, исследуется, изображается. Возможно, на помощь придут следующие вопросы:

*Что мне интересно больше всего?

*Что из изученного в школе хотелось бы узнать более глубоко?

2. Формулировка темы проекта.

3. Определение цели проекта.

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

Формулировка цели - это одно предложение, являющееся ответом на вопрос: зачем нам нужен этот проект?

4. Постановка задач проекта.

Задача – это то, что необходимо решить, выполнить. В задачах определяется, как достичь цели.

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

5. Высказать одну или несколько гипотез.

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

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

Возможно, что в джунглях люди встретили говорящего попугая.

Люди договорились друг с другом дать названия разным предметам.

Цель: Выяснить, как толковый словарь помогает в жизни.

Изучить строение словаря.

Определить, когда и где можно использовать словарь.

Придумать рекламу для толкового словаря.

Гипотеза: В наше время невозможно обойтись без толкового словаря.

6. Работа с информацией.

1) Сбор информации.

Постараться узнать как можно больше о предмете исследования.

Может быть устная информация. Например, вам кто – то о чём – то рассказал, сообщил (родители, одноклассники, учителя, соседи, продавец в магазине и т.д.).

2) Методы исследования.

Зададим себе вопрос: как мы можем узнать что – то новое о том, что исследуем? Для этого надо определить, какими методами мы можем пользоваться, а затем выстроить их по порядку.

Метод (греч.) – способ, приём познания явлений окружающего мира; способ действия. Методов много. Для своего исследования выбирайте только те, которые нужны.

Эксперимент – это опыт, ставится для изучения, исследования чего – либо.

Изучение источника исследования.

Поиск информации (в книгах, словарях, энциклопедиях, интернете и т.д.).

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

Фонетический анализ (размышление: какие звуки мы слышим, какова их характеристика), морфемный анализ (анализ частей слова).

Анализ – всесторонний разбор, рассмотрение явления.

Синтез – это обобщение данных, добытых анализом.

3) Результаты исследования.

Все проекты предполагают создание информационного или творческого продукта.

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

4) Вывод. Вывод - это логический итог рассуждений, умозаключение.

7. Защита проекта. Теперь проект нужно оформить и представить публично, то есть показать, ознакомить с ним других. Но ведь вы не только продемонстрируете, покажете, представите собравшимся свою работу. Вы будете рассказывать, чтобы всех убедить: ваши исследования верные, ваши выводы правильные. Вы будете защищать то, что сделали.

Текст выступления

Ниже дано начало каждой фразы, а вы, дополнив предложения, получите текст своего выступления.

Тема моего / нашего проекта …Цель моей / нашей работы …Задачи моего / нашего исследования: …Я / Мы выдвинул(и) гипотезу: …Творческим продуктом будет …Моя / Наша работа актуальна, потому что …

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала немного теории. Что же такое проект?

Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.

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

Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).

Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).

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

Тщательное планирование необходимо.

“Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.” (Цитата С. Макконнелл “Совершенный код”)

Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают “серебрянной пули”.

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

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

Первая и самая начальная фаза, это зафиксировать для себя требования. Описать проект: его историю (описать как он возник), изменение бизнес-среды (может быть связано с экономикой, конкуренцией и т.д.), какой путь развития выбран для проекта и пояснить причину выбора. Определить конкретные результаты и выгоды, которые будут достигнуты.
Планирование бюджетов и сроков. Обязательно установите временные рамки, в которые ожидается достижение целей. Желательно зафиксировать бюджет на риски, взять от максимальной планки около 30% (пусть это и будет запас на “Черный День”). Зарезервировать ресурсы (не только финансовые, но и временные, а также, необходимые специалисты — тоже являются ресурсами) для рисков, которые могут повлиять на проект. Если рисков слишком много, то необходимо переосмыслить задачу в голове.
Содержание проекта. Представляете себе финальную точку и начинаете декомпозицию работ (это всегда должен быть актуальный и регулярно обновляющийся документ) или иерархическая структура работ (выписать все шаги по проекту, объединив в блоки).
Этапы работы над проектом. Подходы к разработке зависят от предварительного понимания всех требований к системе, если на этапе проектирования возможно определить около 80% требований, то процесс будет более последовательным (скорее всего, это будут проекты, с уже отработанным бизнес-процессом, перенесение проекта на новые технологии, либо системы, которые влияют на здоровье/жизнь людей).

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

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

Управление рисками. Рисковое событие — это все факторы, влияющие на ход развития проекта. Произведите взвешивание по категориям: вероятность — случится это событие или нет, и влияние событий — низкое / высокое. Зарезервируйте ресурсы для рисков. Если рисков слишком много, то необходимо переосмыслить весь проект.

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

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

Зафиксируйте план управления вехами (события) — ориентиры, чтобы понять прибыли ли вы в точку, которая отражает необходимый результат или ещё нет. Веха — это результат события, но никак не процесс. Будьте внимательны! Перечислите и кратко опишите важные достижения проекта, которые будут служить основными контрольными точками оценки хода выполнения проекта и его стоимости. Как правило, это точки, в которых выполнение какого-либо действия или группы действий приводит к тому, что проект достигает вехи, производя очень заметный или значительный результат.

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

“Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок” (Цитата С. Макконнелл “Совершенный Код”)

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

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

Какие же это будут этапы?

Бюджетирование проекта. От чего зависит стоимость разработки?
Техническое задание. Как правильно составлять?
Проектирование и прототипирование проекта. Как правильно собрать данные и спроектировать понятный интерфейс с минимальным количеством переделок/доработок.
Реализация проекта (как двигаться из точки А в точку Б). Первый релиз (альфа/бета/полноценный запуск)
Поддержка проекта. Что входит и сколько это должно стоить ?

Заказчик отвечает за грамотную постановку цели, а Исполнители - помогает в достижении этой цели, делиться своим опытом. Грамотное управление и планирование приведет проект к поставленной цели (но помните, что есть еще внешние факторы и держите “руку на пульсе”).

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

Совсем немного введения

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

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

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

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

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

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

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

Из второстепенных материалов:

Роадмап проекта, где указываем календарный план работ и майлстоуны

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

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

Этап Инициации

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

Общая информация о проекте

Целевая аудитория проекта и ее проблемы (потребности), которые будет решать продукт

Ожидаемые выгоды от проекта (для ЦА)

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

Основные экраны и информация на них (в текстовом виде), которая составляется на основе требований к функциям из пункта выше.

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

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

Также можно составить Роадмап проекта на этом этапе, где указать календарный план работ и майлстоуны:

Этап Разработки

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

Для каждого компонента системы указывается следующее:

Список use cases (можно постепенно дополнять use case диаграмму или сразу сделать ее в полном объеме) с описанием каждого use case

Описание экранов (также можно постепенно составлять схему экранов или карту сайта)

База данных для компонента (может постепенно дополняться или разрабатываться сразу полностью)

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

Этап Запуска

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

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

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

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