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

Ответ 1

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

Ответ 2

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

Что вы можете сделать:

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

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

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

Ответ 3

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

Самая сложная часть - это научиться говорить людям НЕТ, но это то, что вам нужно изучить.

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

В проекте, над которым я работал, нам удалось изменить

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

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

Ответ 9

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

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

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

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

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

Опять же, восстановился ад.

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

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

Ответ 10

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

Ответ 11

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

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

Как сказал Боб Кинг в своем комментарии, "нет" в профессиональном вопросе не плохо.

Ответ 12

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

Ответ 13

Scope Creep - это все о неутвержденных изменениях. Читая ваши вопросы, похоже, что вы знаете ответ, вам нужны требования, запросы на изменение и утверждения.

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

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

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

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

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

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

Ответ 14

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

Ответ 15

Вам придется самому управлять проектами. Подробнее об управлении Agile:

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

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