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

Question

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

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

Я имею в виду большие функции, а не маленькие.

EDIT:

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

Answer 1

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

Мы, клиент, часто говорим: «Это может быть функция, но если мы назовем это ошибкой, возможно, мы сможем заставить их сделать это бесплатно».

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

Речь идет о двух темах: ведение переговоров и управление проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 7

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

Answer 8

Я их заряжаю.

Answer 9

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

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

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

Answer 10

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

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

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

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

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

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