когда ошибка для клиента действительно является новой функцией [закрыта]

Question

Я читал какую-платежную-структуру-вы-используете-для-небольших-проектов и мне интересно, как вы, ребята, справляетесь с bug vs.особенность.Однажды у меня была ситуация, когда клиент хотел получить статические отчеты.Затем, ближе к концу проекта, после того как большая часть работы над отчетами была выполнена, он сказал, что всегда хотел динамичные отчеты.Это изменение было нелегким, потому что выбранная нами платформа не поддерживала динамические отчеты.Это была странная ситуация, потому что у клиента была команда программистов, так что они должны были знать.Может быть, это было просто отсутствие навыков общения.

Ребята, как вы справляетесь с клиентами, пытающимися заставить вас добавить функции, потому что они забыли, передумали или были неправильно поняты?

Я имею в виду большие возможности, а не маленькие.

Редактировать:

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

Answer 1

По моему опыту, поскольку я был по обе стороны от этого вопроса, обычно речь идет скорее об экономике, чем о программировании, управлении процессами или проектами.

Мы, клиенты, часто говорим: "возможно, это особенность, но если мы назовем это ошибкой, возможно, мы сможем заставить их сделать это бесплатно".

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

Я не верю, что что-то из этого изменится только потому, что у нас есть лучший способ сказать "это ошибка" или "это новая функция".

Answer 2

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

Answer 3

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

Я бы привел следующий аргумент в пользу Железного треугольника:
1) Очевидно, что мы хотим доставить необходимый вам продукт, поэтому давайте работать вместе.
2) Мы все понимаем, что независимо от того, как мы добрались до текущей точки, мы можем двигаться вперед только с того места, где мы находимся сегодня.
3) Мы также понимаем, что внедрение изменений потребует времени и денег, которые должны откуда-то взяться.
4) На данный момент у вас есть следующие варианты (выберите один)
* Замените работу, которая была запланирована для какой-либо другой функциональности, работой, необходимой для того, чтобы это изменение соответствовало бюджету и графику (пожертвуйте другими функциями).
* Продлить крайний срок (увеличить стоимость/сдвиг крайнего срока)
* Добавление ресурсов (увеличение стоимости)

Предупреждение:Хотя C имеет логический смысл, если вы выполняете работу производственного типа (создаете еще 1000 карандашей), в научно-исследовательских работах, таких как разработка программного обеспечения, это обычно просто еще одна разновидность B, где вы увеличиваете затраты и сдвиг сроков.

Answer 4

Если этого нет в плане проекта / письменном соглашении, это выходит за рамки.

Answer 5

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

Answer 6

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

Как только все это будет сделано, если клиент хочет, чтобы это было ближе к первоначальной дате запуска (и это возможно), добавьте дополнительные часы сверхурочной работы.

По крайней мере, это то, что я сделал.

Answer 7

Я беру с них плату.

Answer 8

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

Answer 9

Вопрос касается двух тем:ведение переговоров и управление проектами.

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

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

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

• Заложите в план некоторое время и бюджет на смежность, объясните заказчику, что любая смежность будет использоваться только по договоренности с ним.

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

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

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

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

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

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

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

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

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

Answer 10

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

Есть два очевидных способа избежать этого.

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

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

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

И не попадай больше в такое положение.

Answer 11

Что ж, если это правда, просто смирись с этим.Что тут объяснять, если вы согласились на что-то одно, а теперь он хочет сделать что-то еще?Получаете ли вы отпор?

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

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

Надеюсь, это поможет!

Answer 12

Что я делаю в этом случае, так это просматриваю предыдущую документацию и сообщения.

Например, если в документации / сообщении указано "Создавать отчеты".Если бы там не было конкретного упоминания о динамических отчетах, я бы не стал уступать клиенту.

Если есть какая-либо документация с надписью "динамические отчеты", то клиент был бы прав, и мне пришлось бы разрабатывать отчеты бесплатно.

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

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

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

Answer 13

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

• будущая работа - есть ли будущая работа с этим клиентом или потенциальная рекомендация для будущей работы?если это так, вы немного уступаете, пытаетесь вычеркнуть другие области результатов, которые, основываясь на данном примере, могли бы измениться в правильном направлении.
• платеж - удерживают ли они платеж на основании этого?и находится ли работа по-прежнему в пределах вашего буферизованного бюджета (вы ведь добавили буфер для этого типа работы - верно?что ж, в следующий раз так и будет - будущие клиенты платят за прошлые ошибки клиентов)
• доставляйте быстро и часто - IKIWISI -я знаю это, когда вижу - если это будет передано клиенту раньше, чем позже, тогда "интерпретация" / серые области уменьшаются ... итеративные доставки (даже неполные) творят чудеса

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

Answer 14

Я нахожусь в ситуации, когда это происходит на регулярной основе.Мы пишем веб-приложения, которые выполняют сложные задачи, затем, после того как мы выполним это в соответствии со спецификацией, пользователь повернется и скажет: "Мы хотим не только X & Y, но и Z".Z не входил в сферу действия проекта и, следовательно, недостижим в текущей системе, поэтому его необходимо переписать в acomodate для вновь введенных "функций".

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

Теперь я готовлюсь к этим незапланированным, но вероятным изменениям.