Я должен управлять текущим развитием и обслуживанием веб-домена клиента. Есть много идей по добавлению функций в будущем.
Мне было интересно, какой будет наилучшая практика для текущего проекта. Должен ли я оставить один проект открытым и продолжать добавлять задачи и вехи для каждого этапа продвижения?
или я должен просто создавать новые проекты для каждого этапа разработки?
Мне интересно, не станет ли проект слишком громоздким, если я буду постоянно добавлять к нему что-то еще, и не будет ли лучше иметь небольшие проекты, которые я смогу закрыть после завершения. Но это заставляет меня задуматься об обслуживании этих закрытых проектов.
PS: я использую проекты zoho, если это имеет значение.
По определению то, что вы описываете, вообще не является проектом, потому что у него нет определенного начала и конца:
Проект является временным в том смысле, что он имеет определенное начало и конец во времени и, следовательно, определенный объем и ресурсы. ~ PMI
Однако есть несколько способов превратить эту концепцию в проект(ы). Одним из них было бы создание резерва элементов от исправлений ошибок до новых функций. Затем возьмите стопку из них — заверните их в тайм-бокс — и работайте над ними до конца тайм-бокса. Я не решаюсь ссылаться на Scrum здесь, потому что Scrum довольно жестко определен в своих ролях, обязанностях и артефактах, но именно так работает Scrum с точки зрения PM.
Цель состоит в том, чтобы создать определенный объем работ, а затем зафиксировать продолжительность, в течение которой эта работа будет завершена, чтобы она действительно была проектом. Если вы разделите свои билеты на три категории, это довольно легко сделать в истинном «проектном стиле» - в подобных ситуациях я использовал следующее: новая разработка, нефункциональный дефект (текст слишком далеко вправо), функциональный дефект (вещи падают, когда я делаю X). Нефункциональные дефекты и новые разработки помещаются в список ожидания, потому что нам нужно ждать, пока время, бюджет и человеческие ресурсы будут подготовлены и определены. Функциональные дефекты постоянно обрабатываются и/или добавляются в проект (график должен позволять разработчикам работать с 80% или менее мощностями, в зависимости от стабильности системы, для работы над функциональными дефектами).
По сути, лучшая практика с точки зрения PMI, основанная на моем понимании PMBOK, — это определение объема работ и временных рамок — как минимум; в противном случае вы не работаете над проектом. С более гибкой точки зрения, лучше всего вообще отказаться от концепции проекта и использовать более экономичный подход — заявки приходят — они расставлены по приоритетам — вы выполняете те, которые имеют наивысший приоритет, на основе срока выполнения « так скоро, как возможно". Когда билет готов, протестирован и благословлен, вы можете либо выпустить обновление продукта; или, подождите, соберите и интегрируйте их в более накопительный выпуск позже.
Надеюсь, это поможет.
http://www.pmi.org/About-Us/About-Us-What-is-Project-Management.aspx
http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704
Я бы закрыл первоначальный проект. Я бы запланировал последующие «выпуски», каждый из которых может быть отдельным проектом, определяемым объемом функций, которые вы собираетесь включить в него, и ограниченными датами начала и окончания.
Нейлдеймонд
Джош Брюс