Лучший способ избежать расползания границ проекта как разработчика без [закрытого] управления проектами

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

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

Расползание границ проекта - все о неутвержденных изменениях. Чтение Ваших вопросов, это похоже на Вас, знает ответ, Вам нужны требования, запросы на изменение и одобрения.

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

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

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

Теперь создают лист регистра Изменения. Этому нужен столбец для краткого описания, один для более длинного описания, даты, столбца для влияния и один для утвержденной даты и утвержденный. Столбец влияния является самым важным. Каждый раз, когда кто-то запрашивает изменение, необходимо разработать, как то изменение произведет объем, бюджет или расписание. Дополнительная функция может добавить 5 дней и 5 000$. Если необходимо поставить к Рождеству, необходимо удалить объект требования 1,2,3.

, После того как у Вас есть свои требования и метод для передачи изменения и влияния, самая твердая часть - то, что Вы не можете выполнить изменение без одобрения от Вашего спонсора. Это одобрение может быть электронным письмом или что бы то ни было. Но это должно явно сказать, что "Я утверждаю изменение номер 12". Без явного шага одобрения Вы не можете также обеспокоиться.

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

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

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

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

, Как Bob King сказал в своем комментарии, говорить "нет" в профессиональном вопросе не является плохой вещью.

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

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

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

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

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

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

Снова, восстановите последовавший ад.

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

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

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

Это не работает, если клиент никогда не хочет закончить. Посмотрите, можно ли установить некоторые разумные крайние сроки в контракте, такие как "мягкий reqs крайний срок" и "трудный reqs крайний срок".

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

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

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

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

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

самая твердая часть изучает, как сказать людям НИКАКОЙ , но это - что-то, что необходимо будет изучить.

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

второй тип происходит от небольших функций, добавляемых посреди цикла разработки. Это - то, где необходимо изучить, как сказать "нет". Вы can’t всегда говорят "нет", но действительно необходимо выбрать сражения. И помните, этот тип расползания границ проекта doesn’t прибывают из больших вещей. Это прибывает из большой мелочи. Смерть It’s из-за тысячи бумаги cutts.

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

, Что можно сделать:

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

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

, Но в целом, свяжитесь, свяжитесь, свяжитесь и станьте своего рода мини-руководителем проекта.

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

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

1. Составление спецификации требований, которая закончена заинтересованными сторонами
2. Оценка, сколько работы потребуется для создания то, что было указано
3. Каждый раз, когда изменение требуют, оцените, сколько это изменит, объем работы потребовал объяснения, что влияние на стоимость и дата завершения, вызванная изменением
4. , Говорит "нет" изменениям, которые не включают изменение в расписании
5. , Добираются, выход на принятых изменениях (включая принятие изменения в расписании)
6. Сохраняют журнал того, какие изменения требовали, и что было утверждено.

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