Когда ошибка для клиента действительно новая функция
Я читаю проекты "что такое оплата, структура, что ты используешь для маленьких", и мне интересно, как вы, ребята, справляетесь с ошибкой и функцией. Когда-то у меня была ситуация, когда клиент хотел получать статические отчеты. Затем, ближе к концу проекта, после того, как большая часть работы над отчетами была выполнена, он сказал, что всегда хотел динамические отчеты. Это изменение было нелегким, потому что выбранная нами среда не поддерживала динамические отчеты. Это была странная ситуация, потому что у клиента была команда программистов, поэтому они должны были знать. Может быть, это просто отсутствие навыков общения.
Как вы, ребята, имеете дело с клиентами, пытающимися заставить вас добавлять функции, потому что они забыли, передумали или были неправильно поняты?
Я имею в виду большие черты, а не маленькие.
РЕДАКТИРОВАТЬ:
Он заявил, что бюджет фиксированный и не может быть изменен, и что эта функция (как и любая) является критической, и без нее они не примут систему. (только в худшем случае)
14 ответов
По моему опыту, когда я занимался обеими сторонами этой проблемы, обычно это больше касается экономики, чем программирования, процессов или управления проектами.
Мы, клиент, часто говорим: "Это может быть функция, но если мы назовем это ошибкой, возможно, мы сможем заставить их сделать это бесплатно".
В конце концов, мы, программист, берем или не берем больше, основываясь на том, поможет ли это или повредит нашим шансам на будущую работу. Мы, клиент, берем морковь будущей работы, чтобы побудить программистов делать дополнительную работу бесплатно.
Я не верю, что все изменится только потому, что у нас есть лучший способ сказать "это ошибка" или "это новая функция".
Важно, чтобы обе стороны понимали, что они получают за свои деньги очень рано в процессе разработки программного обеспечения. Agile методология является отличным инструментом для управления этим процессом. Если у вас есть скорость вашей команды, вы можете довольно точно определить, сколько функций можно будет добавить за каждую итерацию. Оценивайте задачи и держите клиента вовлеченным в расстановку приоритетов, какие функции должны быть добавлены, а какие менее важными. После каждой итерации обязательно показывайте клиентскую демонстрацию, чтобы продемонстрировать работающую функциональность, с которой вы оба согласились работать в конце текущей итерации. Если клиенту нужна другая функция или значительно изменить ту, о которой вы уже договорились, оцените количество необходимых баллов (единиц работы, используемых в Agile), чтобы внести это новое изменение или переделать текущую часть функциональности. Это поможет им удалить другую функцию, которую они считают менее важной, чем текущая, которую они только что предложили. Это делает всех счастливыми, и нет никаких сюрпризов, когда продукт "отправляется"
Нет смысла пытаться спорить с ними из фича. В конце концов, проблемы со связью или нет, миссия состоит в том, чтобы предоставить клиенту то, что ему нужно в программном обеспечении.
Я бы пошел с аргументом железного треугольника следующим образом:
1) Очевидно, что мы хотим доставить нужный вам продукт, поэтому давайте работать вместе.
2) Мы все понимаем, что независимо от того, как мы добрались до текущей точки, мы можем двигаться вперед только с того места, где мы сегодня.
3) Мы также понимаем, что внедрение изменений потребует времени и денег, которые должны прийти откуда-то.
4) На данный момент ваши варианты являются (выберите один)
* Замените работу, которая была запланирована для некоторых других функций, работой, необходимой для этого изменения, чтобы остаться в рамках бюджета и графика (пожертвовать другими функциями)
* Продлить срок (увеличить стоимость / срок смены)
* Добавить ресурсы (увеличить стоимость)
Предупреждение: хотя C имеет логический смысл, если вы выполняете работу производственного типа (строите еще 1000 карандашей), в таких исследованиях и разработках, как разработка программного обеспечения, это, как правило, просто еще один вариант B, когда вы увеличиваете затраты и сроки.
Если этого нет в плане проекта / письменном соглашении, это выходит за рамки.
У нас есть письменная спецификация, и клиент подписывает ее, соглашаясь оплатить функции, описанные в этом документе. Если они позже передумают над чем-то простым, мы, как правило, будем работать над изменениями без дополнительной оплаты, но все, что вы описали, потребует нового заказа на покупку.
Вопрос о двух темах: ведение переговоров и управление проектами.
Что касается управления проектами, вам необходимо управлять риском, когда заказчик передумает или неправильно поймет соглашение. Вот список профилактических мер, которые обычно принимаются в проекте разработки программного обеспечения, его можно использовать в качестве контрольного списка при планировании или повторном рассмотрении проекта:
Избегайте большинства рисков, предварительно одобрив письменную спецификацию. В случае, если вы делаете меньшие итерации, спецификация для итерации одобрена. Он не должен быть слишком подробным, но должен определять ожидания клиентов и служить ориентиром. Детализируйте вещи, в которых вы не уверены, в спецификации.
У вас может быть возможность другой организации, которая напрямую сообщает клиенту, чтобы сделать определенные рискованные биты.
Вложите в план некоторое время и бюджет на непредвиденные расходы, объясните клиенту, что любой случай будет использоваться только по согласованию с ними.
Явно предлагайте клиенту альтернативные решения на стадии планирования, обсуждайте плюсы и минусы и документируйте решение.
Даже если вы сделаете водопад в несколько этапов проекта, вы сделаете небольшую демонстрацию для клиента или уточните требования. Воспользуйтесь этой возможностью, чтобы клиент по-прежнему согласился с предложенным решением.
Как указывает Webdtc, всегда подтверждают результаты телефонных и личных переговоров, отправляя краткое резюме по электронной почте.
Сохраняйте результаты, их прием и оплату для проектов дольше месяца. Даже если клиент платит в конце проекта, убедитесь, что вы получили подтверждение его промежуточных результатов.
Надеюсь, что следование этим советам никогда не поставит вас в трудную ситуацию, когда вам нужно будет договориться о результатах с клиентом постфактум, которому грозит неплатеж. Но если бы вы все-таки столкнулись с необоснованными требованиями, информация, которую вы бы накопили к тому времени, дала бы вам очень сильный рычаг. Советы по ведению переговоров:
Начните с понимания точного обоснования потребительского спроса. И какова их позиция. Подтвердите с клиентом, что вы его правильно поняли
На этом этапе это может быть ваша ошибка (маловероятно, если вы правильно управляли проектом), ошибка клиента (иногда они передумали) или сбой с обеих сторон (скорее всего).
Когда это все ваша вина, скорее всего, вам нужно будет проглотить таблетку и выучить урок. Однако вам нужно будет договориться с клиентом о новых сроках, чтобы проблема не стоила вам еще дороже. Всегда подумайте о том, чтобы предложить предупреждающее решение проблемы, созданной поверх программного обеспечения, которое у вас есть сейчас.
Когда это вина клиента или взаимная ошибка, начните с "нет". Отодвиньтесь, чтобы они поняли, что вы не берете на себя расходы, по крайней мере, не полностью. Не позволяйте им убедить вас, что они могут легко уйти, это никогда не правда. К этому моменту, даже если они не заплатили вам ни копейки, их инвестиции в проект будут значительными: время, потраченное на оценку предложений, участие в совещаниях, усилия, которые они приложили для информирования о требованиях, зависимость их и их клиентов от проекта, выполняемого в основном вовремя, в рамках бюджета и т. д. Возможно, вам все равно придется разделить расходы между двумя организациями, но начните с "нет", чтобы прояснить, что они несут такую же ответственность за усилия по своевременному уточнению требований, как и вы за выяснение того, что необходимо.
Я бы порекомендовал удостовериться в том, что требования как можно лучше проработаны и обе стороны точно понимают, что обещано. Это делает клиента счастливым, потому что меньше ситуаций, как вы описываете, и это делает вас счастливым, потому что вы не будете постоянно дергаться.
Ну, самый простой ответ заключается в том, что бюджет или контракт предусматривают требования. Изменения этих требований должны быть представлены как дополнительные, а затем пройти тот же процесс, что и первоначальный проект. Они должны быть заложены в бюджет и оценены.
Как только все это будет сделано, если клиент хочет, чтобы он приблизился к первоначальной дате запуска (и это выполнимо), добавьте дополнительное время сверхурочных часов.
По крайней мере, так я и сделал.
Мне кажется, что клиент может искать повод выйти из соглашения, ничего не платя. Если он может произвольно добавлять функции и настаивать на них для окончательного принятия без дополнительных затрат, у него есть способ заставить вас разорвать контракт.
Есть два очевидных способа избежать этого.
Один из них - платежи в процессе разработки, так что клиент не может извлекать большую часть платежей, и вы более или менее получаете компенсацию от того, что вы сделали в любой момент.
Еще один хороший контракт. Для любого разумного программного проекта несколько часов гонорара адвоката - это дешевая страховка от чего-то подобного. Если вы уверены, что можете подать в суд на клиента за согласованные сборы и выиграть, у клиента меньше шансов на неприятности, а если ничего не получится, вы можете подать в суд.
Я не знаю, по каким контрактным условиям вы работаете (и я в любом случае не юрист), но в такой ситуации я бы получил адвоката и посмотрел, в какой ситуации я оказался. Даже Если вы находитесь в сомнительной юридической позиции, возможно, что письмо от вашего адвоката поможет решить проблемы.
И не возвращайся в это положение снова.
Что я делаю в этом случае, так это смотрю предварительную документацию и сообщения.
Например, если в документации / сообщении написано "Создать отчеты". Если нет конкретного упоминания о динамических отчетах, я бы не поддался клиенту.
Если есть какая-либо документация с надписью "динамические отчеты", тогда клиент будет прав, и мне придется разрабатывать отчеты бесплатно.
Если есть сообщение о "динамических отчетах", я бы посмотрел, каков будет конечный результат. Вот где это может быть сложнее, потому что клиент часто может спросить: "Возможно ли создавать динамические отчеты?" и разработчик может сказать: "Да, это возможно". (значит, это возможно, но не значит, что мы это сделаем). Здесь я должен был бы объяснить, что, хотя и обсуждалось, это не входит в объем работ. Должно быть конкретное соглашение о том, что функция будет разработана.
Если вы не храните документацию и предыдущие сообщения, я бы сказал, что вы в растерянности и должны будете решить, собираетесь ли вы дать клиенту то, что он хочет, или рискуете потерять клиента.
Одна из худших вещей для меня - клиент, который настаивает на телефонной связи. Эти клиенты обычно играют быстро и легко со своими запросами. Я обычно делаю здесь, чтобы всегда делать с клиентом письменное наблюдение за всем, что обсуждается во время личной встречи или телефонного звонка, и требовать от клиента ответа, чтобы убедиться, что мы находимся на той же странице, что и выиграет не будет сделано
Ну, если это правда, просто пройди мимо. Что объяснить, если вы согласились на одно, а теперь он хочет сделать дополнительно? Вы получаете толчок назад?
Я бы дал понять, что мы изначально разработали статический отчет, и это было то, что было подписано. Это может быть расширено на динамические отчеты, и что вы можете предоставить цитату, если он хотел бы знать особенности.
Я часто использую аналогию строительства дома. Либо клиент меняет план, либо отделочные материалы, которые требуют больше времени, материалы, чтобы сделать то, что было первоначально согласовано.
Надеюсь, это поможет!
Я нахожусь в ситуации, когда это происходит на регулярной основе. Мы пишем веб-приложения, которые выполняют сложные задачи, и после того, как мы выполним их в соответствии со спецификацией, пользователь развернется и скажет: "Мы хотим не только X & Y, но и Z". Z не был в рамках проекта и, следовательно, не достижим в текущей системе, поэтому он должен быть переписан, чтобы добавить новые функции.
То, как мы обходим это, просто так. Обращайтесь с пользователем, как с идиотом, и лучше понимайте систему, чем он. Я знаю, что это звучит очень странно, и сначала, когда мой начальник представил меня этому, я прямо сказал ему, что никогда не буду относиться к пользователю как таковому - к сожалению, я научился трудному пути и теперь должен знать больше, чем пользователь, чтобы выполнить свои задачи., Смягчение последствий имеет первостепенное значение, и предвидение серьезных изменений, которые могут быть внесены, является навыком, приобретенным с течением времени.
Сейчас я смягчаю эти незапланированные, но вероятные изменения.
Там нет правильного ответа - только несколько неправильных. В спецификациях и требованиях больше пустого пространства, чем в информации - всегда есть место для интерпретации и недопонимания... к чему это действительно приводит:
- будущая работа - есть ли будущая работа с этим клиентом или потенциальная ссылка для будущей работы? если это так, вы немного уступите, постарайтесь снять серость с других областей результатов, которые, основываясь на этом экземпляре, могли бы повернуть в правильном направлении.
- оплата - они держат платеж, основанный на этом? и работа все еще в пределах вашего буферизованного бюджета (вы добавили буфер для этого типа работы - правильно? хорошо, в следующий раз вы будете - будущие клиенты платят за прошлые ошибки клиента)
- доставлять быстро и часто - IKIWISI - я знаю это, когда вижу - если он оказывается перед клиентом раньше, чем позже, тогда "интерпретация" / серые зоны сокращаются... итеративные доставки (даже неполные) творят чудеса
После того, как вы мало что можете сделать, если дело доходит до судебного иска, вы потеряли этого клиента и хорошую репутацию (потенциал) - будьте осторожны в том, как сильно вы его подталкиваете