Как сделать потребность в проекте

Добавил пользователь Валентин П.
Обновлено: 04.10.2024

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

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

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

Пошаговое составление плана проекта

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

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

Шаг 1. Представьте свой план в виде карты проекта.

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

Какой путь назначения? Как вы поймете, что проект завершен?
Кто пойдет по этой карте?
Какие контрольные точки предстоит пройти по пути и какое между ними примерное расстояние?
С какими препятствиями можно столкнуться? Есть ли альтернативные маршруты?

Шаг 2. Познакомьтесь с заинтересованными сторонами.

Ознакомьтесь с неприятными фактами организационной политики, трудными личностями и возможными дискуссионными вопросами, которые могут влиять на процесс управления проектом. Ларри В. Смит, PMP и менеджер проектов в Software Technology Support Center, подчеркивает важность проведения анализа заинтересованных сторон. По словам Смита, все участники хотят, чтобы проект увенчался успехом, но забыв о потребностях хотя бы одного влиятельного участника, можно все испортить.

Смит рекомендует уделить время следующему:

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

Шаг 3. Без лишних иллюзий составьте календарный график работ.

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

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

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

Шаг 4. Привлеките помощников.

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

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

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

Совет. Шаблон плана проекта доступен бесплатно. Не требуется даже указывать адрес электронной почты.Получить PDF-файл.

Шаг 5. Определите цели и объем работ.

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

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

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

Шаг 6. Спрогнозируйте (и предотвратите) неожиданные ситуации.

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

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

Совет. Воспользуйтесь методом DACI для своевременного принятия обоснованных решений по проекту.

Шаг 7. Выберите предпочтительный подход к управлению проектом.

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

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

Шаг 8. Напишите и проверьте план.

Ниже приведены некоторые полезные подробности, которые должны быть в составе любого плана, независимо от его формата.

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

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

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

Шаг 9. Поделитесь своим планом… и держитесь 😉

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

Шаг первый. Идея

За семнадцать лет работы команда конкурса молодёжных проектов убедилась: самые яркие проекты — те, в которых авторы ищут решение насущных вопросов тех мест, где они сами живут или получают образование. Обдумывая идею проекта, оглянитесь: каких улучшений ждут жители вашего города, села, района? Может быть, им не хватает спортивной площадки и вы придумаете, как и где её разместить? Возможно, жителям вашего посёлка было бы интересно узнать его историю? Посмотрите на окружающий вас город и его жителей: возможно, именно ваш проект сможет сделать их жизнь лучше и интереснее.

Шаг второй. Поиск решения

Когда проблема определена, нужно найти способ ее решения. Для начала оно может быть достаточно общим — уточнить и развить его можно будет потом. Оценить выбранную проблему и предполагаемый путь её решения помогает наставник. Чаще всего ими становятся педагоги, которые охотно работают с учениками над проектами, оттачивая навыки социально-проектной деятельности студентов и школьников.

Шаг третий. Создание команды

Хорошая команда — залог успешного проекта, а следовательно, и победы в конкурсе. Лидером команды, как правило, становится автор проекта, а основной направляющей силой — наставник. Но найти и собрать команду — это ещё не всё. Важно, чтобы её участники были:

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

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

Шаг четвертый. Планирование

На этом этапе нужно сформулировать основные составляющие проекта:

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

Шаг пятый. Получение поддержки

На этом этапе важно найти поддержку, например общественных организаций и/или администрации города, региона или посёлка. Что для этого надо сделать? Рассказывайте о своём проекте! Пресса, профессиональные сообщества, вузы города — всё это поможет вам сделать проект популярным, а значит, быстрее получить поддержку для его развития. Попросите организации подготовить рекомендательные письма, в которых будет показана актуальность и значимость поставленной вами проблемы. Если идея вашего проекта направлена на развитие города и улучшение жизни его жителей, то у вас очень высокие шансы найти поддержку. Главное — показать и доказать, что предлагаемые вами решения практичны, и объяснить, какая конкретно поддержка и от каких структур может вам понадобиться.

Шаг шестой. Подать заявку на конкурс

Шаг седьмой. Пройти заочный этап

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

Шаг восьмой. Защитить проект

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

Что проектная деятельность даёт школьникам и проектам?

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

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

Победители конкурса получают не только призы и медали, но и:

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

Эксперты ИТ-компании SimbirSoft накопили большой опыт предварительной оценки проектов и рассказывают об этом в статье, подготовленной для TAdviser.

Содержание

В начале работы над ИТ-проектом, как правило, проводят оценку. Её отсутствие или неточность может сформировать неправильные ожидания по срокам и бюджету проекта.

За более чем 20 лет разработки ИТ-систем разной сложности мы в SimbirSoft накопили большой опыт предварительной оценки проектов. В среднем за год специалисты нашей компании анализируют по 400 идей клиентов, даже при отсутствии подробного технического задания или иной документации. Расскажем, как выстроенные в компании процессы позволяют проводить предварительную оценку ИТ-проекта быстро, точно и прозрачно.

Актуальные методы оценки ИТ-проекта

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

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

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

По нашему мнению, такой подход позволяет учесть все необходимые работы и подобрать оптимальный состав команды специалистов. Сроки выполнения предварительной оценки методом по фичам зависят от особенностей проекта: для стандартного приложения – до 8 часов при условии одновременного проведения оценки всеми экспертами сразу. Но в этом процессе могут участвовать специалисты нескольких направлений, поэтому в среднем предварительная оценка занимает 3-5 дней.

Есть два общепринятых варианта подсчета трудозатрат:

1. диапазонный метод (от X до Y часов), когда оценщик на основании своего опыта дает пессимистические и оптимистические данные по трудозатратам на фичу,
2. метод PERT – расчет выполняется по трем точкам:

где t_o – оптимистическое время – минимально возможная длительность выполнения задачи,
t_p – пессимистическое время – максимально возможная длительность выполнения задачи,
t_m – наиболее вероятное время – наиболее вероятная длительность выполнения задачи,
t_e – ожидаемое время – оценка длительности выполнения задачи на основе оценок оптимистического, пессимистического и наиболее вероятного времени.

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

Как проходит предварительная оценка

Отправляя заявку в ИТ-компанию, заказчик обычно преследует одну из целей:

Рассмотрим, как проходит процесс предварительной оценки ИТ-проекта. Расскажем на примере нашей компании.

Этап № 1 – обсуждение проекта и потребностей клиента

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

На этом этапе формируются ответы на ключевые вопросы:

Границы разработки – какие этапы работы нам нужно оценить (и в перспективе выполнить), а какие клиент берет на себя?
Какие направления разработки стоит подключить к оценке?
Какой стек будет предпочтителен?
Что еще нужно заложить в оценку? Например, клиент решает, что дизайн будет разрабатывать сам. Значит, в оценку нужно включить время на приемку дизайна заказчика – проверить, соответствует ли дизайн функционалу системы.

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

Этап № 2 – presale

Далее к работе подключаются пресейлы направлений – специалисты, которые будут делать оценку ИТ-проекта по своей части. Модератор создает чат, куда подключаются все необходимые эксперты. В крупных компаниях этот подход позволяет специалистам провести оценку в удобное время, но в рамках четко установленных сроков. Поскольку все пресейлы – высококвалифицированные специалисты, и они постоянно задействованы на коммерческих проектах.

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

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

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

Например: оценка разработки одной фичи не должна превышать 8 (в крайнем случае - 16) часов, а диапазон разброса минимальных и максимальных значений не должен превышать 40%. В ином случае возможен высокий уровень неопределенности в реализации фичи, что может привести к увеличению рисков проекта. Также есть обязательное требование, чтобы оценщик зафиксировал в комментариях, как он видит реализацию задачи за указанное время.

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

Этап № 3 – подготовка коммерческого предложения

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

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

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

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

Выбор – за клиентом

Чек-лист: что подготовить к брифингу для оценки по фичам

Рассказываем, какие особенности будущей ИТ-системы владельцу продукта важно обсудить с подрядчиком перед началом оценки проекта по фичам. Для наибольшей объективности мы рекомендуем клиентам обсудить ответы вместе со своей командой. Еще раз подчеркнем, что это базовый набор вопросов, но в зависимости от особенностей проекта он может изменяться и дополняться.

Блок 1. Общее описание будущей ИТ-системы:
* Какие задачи она должна решать?
* Кто ей будет пользоваться, на каких устройствах и что можно будет делать с помощью этой ИТ-системы?
* Требования к производительности и нагрузке системы. Интеграция с какими внешними и внутренними сервисами предполагается и т.п.
* Есть ли у нее аналоги? Что в них нравится, а что нет?

Блок 2. Варианты сотрудничества:
* Предполагаемые зоны ответственности и формат работы над системой
* Будет ли команда заказчика принимать участие в разработке?
* Были ли уже какие-то наработки?
* Какие требования к code style, стандартам и сертификации предъявляются?

Блок 3. Реализация будущей ИТ-системы:
* Ожидания по срокам и бюджету.
* Предпочтения по архитектуре, стеку, фреймворкам, системе управления базами данных и т.п.
* Есть ли брендбук для разработки дизайна?
* Какую статистику/аналитику предполагается собирать? Планируется ли подключение внешних систем аналитики?
* Требуется ли нагрузочное и автоматизированное тестирование?

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

Все ресурсы подразделяются на три основные категории:

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

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

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

Процесс оценки потребности проекта в ресурсах

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

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

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

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