Как я должен сообщить своему клиенту, что изменения в бэкенде после запуска продукта — это не просто исправление ошибки или улучшение?

Просто расскажи им факты.

Привет.

К сожалению, использование Firebase — это не простое изменение проекта, оно требует значительной переделки архитектуры. По очень грубой оценке, я думаю, что это займет около <некоторого числа> недель усилий. Созвонимся для дальнейшего обсуждения?

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

По своей природе внутренние элементы систем практически невидимы для клиентов/конечных пользователей, и поэтому они часто испытывают трудности с пониманием того объема сложности и работы, которые в них заложены. Это не их вина, и такие разработчики, как вы и я, должны помочь им преодолеть этот разрыв и выразить его в понятных им терминах. Метафоры хороши для этого, особенно если вы можете использовать их, чтобы показать различия между изменением типа «исправление ошибки» и более значительным изменением, таким как то, о котором они говорят. Конкретный вариант зависит от человека, с которым вы разговариваете, но сравнивайте его с такими вещами, как замена шины (исправление ошибки) и полная замена двигателя (переход на firebase) на автомобиле или замена окна (исправление ошибки) по сравнению со структурой. работа на фундаменте здания (пожарная база) - это то, о чем я говорю.

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

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

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

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

Не беспокойтесь о проекте № 2, потому что, честно говоря, вы можете зайти в раздел «Компьютерные концерты» на Craigslist в любом крупном городе и посмотреть, сколько сторон пытаются — ежедневно — выполнять работу бесплатно с обещаниями дополнительных работать позже. Это очень распространенная суета.

Будьте более обеспокоены тем, что этот клиент не пытается переиграть вас в проекте №1. Установите свою цену и придерживайтесь ее. Я рекомендую вам взимать почасовую оплату, потому что помимо изменений вашего кода клиент также будет ожидать, что вы перенесете существующие данные в Firebase. Разработайте письменный документ о объеме работ и попросите вашего клиента подписать его, прежде чем вы начнете какую-либо работу. Этот шаг сокращает недоразумения позже.

Я предполагаю, что у вас есть контракт с клиентом.

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

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

Это лучший способ сообщить об этом.

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

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

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

Есть очень простое правило - клиент всегда прав. Пока клиент платит.

Стоимость: перенос всех ваших данных из MySQL в Firebase (ничего не потеряв). Обновление клиентского ПО. Убедить всех конечных пользователей обновить свои приложения — это сложная задача, потому что конечные пользователи ненавидят такие вещи, и вы понесете убытки.

Обновление клиентского ПО — дело самое нетривиальное. Вы перейдете от хорошо протестированного приложения к чему-то, что снова находится в альфа-состоянии. Вы перейдете от стандартной и протестированной среды к проприетарному решению. Это связано с затратами, Firebase не бесплатен, и в зависимости от того, что вы делаете, это может быть недешево. И из того, что я читал здесь и там в Интернете, Firebase легко справляется с простыми задачами, но может превратиться в кошмар, когда вы выходите за пределы. MySQL будет здесь через пять, десять, 20 лет. Нет гарантии с Firebase. Firebase будет меняться всякий раз, когда Google захочет его изменить.

Наконец, каков его источник информации? Он разговаривал с кем-то из Google? Firebase — это продукт Google. Конечно, кто-то из Google похвалит его до небес.

Таким образом, вы сделаете оценку для этого «простого» изменения. Оценка будет основана на ваших оценках, а не на мнении клиентов. Если он считает вашу оценку завышенной, вы можете предложить ему в качестве альтернативы выполнить эту работу, оплачивая каждый день фактической работы. Вы уж точно не сделаете этого из-за его низкой оценки. Скажите ему, что вы профессиональный разработчик программного обеспечения и знаете лучше, чем продавец Google.