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

Я готовлюсь начать свой новый проект по разработке ERP-системы с открытым исходным кодом . Что на самом деле меня смущает:

  1. С чего начать: с чего начать? (Подготовка среды или подготовка документов в первую очередь)
  2. какие документы мне подготовить? (Я читал об инициационном документе проекта PID, FSD, BRD, руководстве пользователя и т. д.)
  3. Хорошая идея — создать блог и веб-сайт до начала, иначе это займет много времени (или это можно сделать позже).
  4. некоторые программы, которые могут помочь

Некоторые уточнения:

  1. Мой проект посвящен разработке веб-системы ERP с открытым исходным кодом.
  2. В настоящее время у меня нет реального клиента (поэтому у меня нет конкретных требований к клиенту, но, конечно, я определил свои требования к проекту)
  3. Поскольку его открытый исходный код должен ли я рассмотреть какие-либо дополнительные шаги? (сообщество, лицензирование?)
  4. У меня есть представление о Жизненных Циклах Проекта, но на самом деле, как я могу его реализовать.

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

Так что образ не ясен для меня.

Ответы (3)

Это очень широкий вопрос, от общего «с чего начать» до очень конкретного об Open Source. Я сосредоточусь на том, «с чего начать»…

Что касается размера этого проекта (ERP), я бы начал с выяснения, есть ли у вас рынок для него. Вы говорите, что у вас пока нет реального клиента, но знаете ли вы, что вам нужно, чтобы убедить потенциальных клиентов внедрить ваше решение? Могут ли они начать с одного модуля или вам нужно несколько доступных модулей, прежде чем вы действительно сможете что-то опубликовать? Проекту нужна четкая цель , иначе он начнет дрейфовать еще до того, как вы начнете.

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

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

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

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

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

Если ваша команда будет встречаться только «онлайн», то лучше начать со среды для совместной работы. Тем не менее, я бы начал с общей папки Dropbox или чего-то еще (только не усложняйте), пока вы действительно не запустите проект.

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

Когда это ясно и согласовано, вы можете начать.

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

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

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

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

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

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

+1 за «[т] суть не в том, чтобы размазывать чернила по мертвым деревьям» и за уточнение акцента на этапе инициации проекта.

Я предполагаю, что вы находитесь на этапе инициации/запуска проекта.

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

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

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

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