Вы смотрите на это с совершенно неправильной точки зрения. Это не глупый запрос от клиента, который ничего не знает о технологиях. Это ограничение дизайна, которое, по вашему мнению, вносит риск в проект.
Таким образом, вы делаете все, что делаете, когда сталкиваетесь с риском в проекте: определите его, оцените и порекомендуйте стратегию смягчения последствий.
- Определите риск. Сказать, что это вызовет «проблемы с производительностью» и «не будет легко масштабируемым», не определяет риск. Вы должны точно указать, что вы имеете в виду. Что не собирается выполнять и почему? Какие изменения в масштабе столкнутся с этими проблемами?
- Оцените риск. Хорошо, вы думаете, что есть проблема. Насколько плохо? Насколько вы можете быть уверены, что эти проблемы с производительностью действительно произойдут? Как это повлияет на пользователей, если они это сделают? Вы говорите, что программа не может масштабироваться: рост в масштабе, который выставит дефект дизайна даже в картах? Самое главное, откуда вы это знаете? Здесь время, потраченное на создание и тестирование прототипа, может спасти вас от бессмысленных споров.
- Рекомендовать стратегию смягчения последствий. Каков правильный способ реализации этого? Почему это правильный путь? Опять же, откуда вы это знаете? Опять же, прототип - ваш друг.
После выполнения этого упражнения получится несколько вещей.
Во-первых, вы можете обнаружить, что, хотя вы правы в отношении каждого конкретного случая, когда вы соединяете их все вместе, это не имеет значения. Да, эта программа не будет работать хорошо или масштабироваться хорошо, но если ни один из ее прогнозируемых вариантов использования не столкнется с этими проблемами, ее легко не стоит решать.
Во-вторых, существует огромная разница между тем, чтобы говорить кому-то «Это не сработает, я просто знаю это» и говорить ему «Я сравнил ожидаемые варианты использования, и похоже, что такой подход приведет к через четыре или пять секунд времени отклика на пользовательскую транзакцию. "
В-третьих, если вы знаете, из каких условий произойдет сбой программного обеспечения, и вы сформулируете эти проблемы для клиента, и клиент говорит: «Мы действительно хотим, чтобы это работало именно так», вы выполнили свою ответственность. Если это не удается из-за того, что клиент решает не снижать риск, который вы определили, никто не может указать вам и сказать, что это была ошибка программиста.
Прежде всего, доказательства опережают мнение . Вы сформулировали весь этот вопрос как пример вашего мнения по сравнению с клиентом. Это проигрышное предложение. То, что вам нужно сделать, это сформулировать это как «вот проблема, которую мы должны решить». И чтобы сформулировать вопрос таким образом, вы должны продемонстрировать существование проблемы, а для этого вам нужны доказательства.
В конечном счете, именно клиент решает, следует ли снизить риск, а не вы. Это зависит от вас, чтобы дать ему наилучшую информацию, чтобы поддержать его решение. И вам нужно ясно дать понять, что это его решение.
Я неоднократно обнаруживал, что простое электронное письмо идеально фокусирует внимание:
Я проверял дизайн, и я думаю, что здесь есть риск, который нам нужно обсудить. [Подход A] действительно чувствителен к объему транзакции, и я беспокоюсь, что у нас будет достаточно пользователей, чтобы столкнуться с проблемами.
Я провел небольшой тест, используя [Подход B], и он намного менее чувствителен; в моем простом прототипе я смог получить из него X транзакций в секунду. Это имеет смысл, потому что [техническое сравнение того, как эти два подхода обрабатывают вещи].
Меня это особенно беспокоит, потому что [опишите, как программа не сможет работать, если она работает плохо].
Это кажется мне серьезной проблемой. Если бы это был я, я бы использовал [Подход B], потому что [опишите, как этот подход уменьшит риск].
Но вы гораздо лучше знакомы с [подходом А], чем я, и я с радостью подчинюсь вашим указаниям по этому вопросу. Как вы думаете, что мы должны делать?
В этом сообщении очень четко сказано: «Если вы игнорируете то, что я вам говорю, вот как проект потерпит неудачу, и у меня будет документация, демонстрирующая, что вы сказали мне сделать это таким образом». Это также на самом деле не говорит , что.