ГУЗЕВА_П_СРБ_ПР1. социальное предпринимательство механизм управления проектами

Название	социальное предпринимательство механизм управления проектами
Дата	12.06.2022
Размер	43.1 Kb.
Формат файла
Имя файла	ГУЗЕВА_П_СРБ_ПР1.docx
Тип	Документы #586178

Российский государственный социальный университет

ПРАКТИЧЕСКОЕ ЗАДАНИЕ 1

ПО ДИСЦИПЛИНЕ

«СОЦИАЛЬНОЕ ПРЕДПРИНИМАТЕЛЬСТВО»
«МЕХАНИЗМ УПРАВЛЕНИЯ ПРОЕКТАМИ»

ФИО студента	Гузева Полина Дмитриевна
Направление подготовки	Социальная работа
Группа	СРБ-Б-04-Д-2019-1

Москва

Введение

Согласно официальной терминологии:

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

— Еще одно определение данного понятия из свода знаний PMBOK утверждает, что проект (в управленческой деятельности) — временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

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

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

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

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

— Проект имеет четкие функциональные рамки.

— Проект может потребовать использования рискованных решений.

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

— Для проекта может потребоваться уникальное расположение места реализации.

— Проект имеет ограниченные временные рамки. После завершения не продолжается.

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

Четыре этапа управления проектами

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

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

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

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

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

— Цели (по сути, это обоснование проекта).

— Сведения о руководителе проекта, проектной команде (включая роли и обязанности).

— Данные по клиенту, представители клиента и контактные данные.

— Основные этапы проекта.

— Риски и возможные проблемы.

— Список заинтересованных сторон и их участие в проекте.

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

— Ограничения, накладываемые организацией, окружением и внешней средой.

— Обоснование проекта, включая бизнес-обоснование и данные о ROI (Return on Investment).

— Суммарный бюджет проекта.

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

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

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

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

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

Этап «Закрытие»

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

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

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

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

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

Заключение

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

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

Термины «качество» и «одобрение клиента» определяются тремя факторами, между которыми руководитель проекта и проектная команда всегда должны держать проект в балансе между стоимостью, временем и объемом. Проектная команда с руководителем проекта не могут однозначно предсказать стоимость и время, необходимые для реализации проекта, но они действительно могут контролировать его объем. А вот уже исходя из объема можно установить сроки проекта и стоимость. Конечно, это грубое приближение к реальности, но суть верна. Объем определяет, за что отвечает проектная команда и, что не менее важно, за что она не отвечает. Только после того, как объем работ установлен, тогда цели, задачи и сроки могут быть четко определены. Попробую пояснить на примере, так как логика может быть не явно видна. У вас появился новый проект (иногда говорят «зашел» проект), из описания только «хотелки» клиента, а это значит конкретики, что делать и какова область применения (поговорим чуть ниже о ней) нет и, естественно, о сроках речи быть не может. Вы сначала формируете описание проекта, изучив которое можно спрогнозировать, какой может быть функционал проекта и его особенности, сколько может потребоваться времени на реализацию такого функционала (плюс риски), разбить на блоки и составить приблизительный план разработки проекта. После согласования проекта с клиентом можно будет приступить к проработке технического задания, а далее согласовать с клиентом. Функциональные блоки, в свою очередь, разбивают на задачи и подзадачи. Далее следует оценка задач с учетом рисков и временем на проверку, и тестирование. Руководитель проекта собирает их в список, планирует последовательность и расставляет приоритеты, далее следует этап проставления сроков (ведь мы понимаем, что временная оценка не равна сроку, через который будет сдача задачи заказчику). На этом этапе идет проставление сроков реализации с учетом отпусков, других проектов (если сотрудник задействован еще где-то) и рисков на пропуски рабочих дней (отгулы, болезнь и так далее). И вот тут, имея финальный объем работ и ресурсы, руководитель проекта может понять сроки на разработку проекта.

Список литературы:

1. Ананьич, Б.В. Банкирские дома в России. 1860-1914 гг. Очерки истории частного предпринимательства / Б.В. Ананьич. - М.: Наука, 2020. - 17 c.

2. Богалдин-Малых, В.В. Маркетинг и управление в сфере туризма и социально-культурного сервиса: Учебное пособие / В.В. Богалдин-Малых. - М.: МПСИ, 2017. - 39 c.

3. Борнстейн, Д. Как изменить мир. Социальное предпринимательство и сила новых идей / Д. Борнстейн. - М.: Альпина Паблишер, 2017. - 44 c.

4. Борнштейн, Дэвид Как изменить мир. Социальное предпринимательство и сила новых идей / Дэвид Борнштейн. - М.: Альпина Диджитал, 2021. - 36 c.

5. Государственное социальное страхование. - М.: Профиздат, 2020. - 34 c.

6. Гуц, А.К. Математические модели социальных систем / А.К. Гуц. - М.: [не указано], 2016. - 37 c.