Гибкость в объеме проекта? - PullRequest
3 голосов
/ 11 октября 2008

Насколько гибким должен быть программист, если клиент запрашивает требования, не входящие в область проекта?

Ответы [ 5 ]

1 голос
/ 11 октября 2008

Общая перспектива:

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

Правовая перспектива:

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

Бизнес-перспектива:

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

Наконец: «Клиент всегда прав». - (до того момента, когда вы должны сдаться и просто уйти.)

0 голосов
/ 11 октября 2008

Заранее определите список функций, которые будет выполнять система.

Если клиент добавляет новую функцию, то соответственно увеличивают стоимость и время.

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

0 голосов
/ 11 октября 2008

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

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

0 голосов
/ 11 октября 2008

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

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

0 голосов
/ 11 октября 2008

На этот вопрос нельзя дать общий ответ. Это зависит от проекта к проекту.

Примеры:

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

Клиент тесно связан с $$, короткими сроками, другими проектами на ходу, я вряд ли буду гибким.

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

...