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

В статье из HN я натолкнулся на следующий совет:

Всегда говорите своему клиенту / пользователю «да», даже если вы не уверены. 90% времени вы найдете способ сделать это. 10% времени вы вернетесь и извинитесь. Маленькая цена, чтобы заплатить за основной личный рост

Но я всегда думал, что нужно выполнить анализ осуществимости, прежде чем давать какие-либо обещания клиенту / пользователю, чтобы они ни в коем случае не были введены в заблуждение. При каких обстоятельствах должен применяться вышеуказанный совет?

Это второй вопрос в короткой последовательности, вызванный этой статьей.

• Хороший программист: я оптимизирую код. Лучший программист: я структурирую данные. Лучший программист: какая разница?
  Для этого есть другое название: преждевременная оптимизация.

• Никогда не используйте ранние выходы.
  Это правило «единая точка входа / единая точка выхода». Это патч над реальной проблемой, которая заключается в том, что ранний выход может оставить беспорядок. Правильное правило - «навести порядок». Еще лучшим правилом является использование конструкций данных, которые очищаются после себя, чтобы программисту не приходилось беспокоиться о том, чтобы очистить свой беспорядок.

• А теперь всегда говорите своему клиенту / пользователю «да», даже если вы не уверены. 90% времени вы найдете способ сделать это.
  Это тоже невероятно плохой совет.

Иногда вашему клиенту нужно сказать «нет» или «в каком тысячелетии вы этого хотите?» Не обещайте того, что разрушит вашу архитектуру, будет стоить намного больше, чем клиент готов потратить, или что вы не знаете, как этого добиться. Вы знаете технологию, а не клиент. Если вы не знаете, как это сделать, не говорите, что можете это сделать. Если вы не уверены, скажите, что вам нужно время, чтобы выяснить, возможно ли это. Лучше быть честным, и это избавит вас от неприятностей.

Клиенты быстро становятся бывшими, если вы не можете выполнить свои обещания. Уровень отказов 10% может показаться небольшим, но именно на 10% ваши клиенты будут ориентироваться. Иногда они предъявляют иск, когда вы не выполняете то, что обещали. Вы действительно не хотите этого. В других случаях, уверенность в том, что вы выполнили обещание, может обанкротиться, сойти с ума или потерять супруга, потому что вы работаете 18 часов в сутки. Вы тоже этого не хотите.

Подумайте об этом так: что, по вашему мнению, могло бы произойти с авиационной отраслью, если бы 90% всех посадок были успешными? Как вы думаете, возвращение и извинения за 10%, которые потерпели крах, что-нибудь исправят?

Было бы лучше сказать «Я думаю, что это можно сделать». или "Я проверю и вернусь к вам". У меня были времена, когда я говорил «нет» или встречный предлагал что-то. Если клиент хочет «приложение на основе браузера, которое работает без подключения к Интернету и использует тактильную обратную связь», это возможно. Но это дорого, и было бы полезно обсудить реальные потребности.

Клиент будет уважать вас, если вы честны. В совете, о котором идет речь, человек ошибается в 10% случаев. Если я работаю с кем-то, кто обычно ошибается один из каждых десяти раз, я не собираюсь доверять ему / ей вообще. Это ужасный послужной список.

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

Этот вопрос был официально изучен и рассматривается совместно разработанным Кодексом этики IEEE Computer Society / ACM. .

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

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

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

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

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

Есть история с первых дней существования суперкомпьютеров, когда Сеймур Крей и команда Control Data Corporation были близки к запуску продукта, и еще одна очень крупная компьютерная компания рассказала своим клиентам, что она также близка к запуску. Ложь стоила CDC большого бизнеса и переросла в судебный процесс, когда крупная компания не смогла представить никаких достоверных доказательств своих претензий. Результатом стало то, что в то время было крупным урегулированием на сумму 80 миллионов долларов 1970 года (около 223 миллионов долларов в 2012 году с учетом инфляции). Вы можете прочитать об этом здесь:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

При наличии достаточного количества времени, ресурсов и гибкости в определении успеха все возможно. Пример белой x-массы прост, если вам нужна точность выше 50%, и у вас есть географическое местоположение пользователя и немного статистических данных.

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

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

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

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

С другой стороны, когда имеешь дело с разумными клиентами с разумными ресурсами, иногда нет ничего хуже, чем сказать клиенту, что некоторые функции должны быть отключены после того, как ты согласишься на это, потому что они, возможно, уже сбежали и потратили время / деньги / ресурсы на продвижение или документирование этого и то, что 10%, возможно, было тем, что получило проект greenlit во-первых. Попадание в те ситуации, и вы только что потеряли клиента, и, скорее всего, получили очень устную плохую ссылку на весь рынок.

Играя адвоката дьявола

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

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

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

Поскольку нет абсолютных критериев для измерения сложности запроса, часто для клиента важнее доверие к исполнителю на 100%, а не к выполнению 90% или 100% запросов.

Предположим, клиент должен выбрать один из двух сценариев:

Подрядчик А :

• Уверены, что они могут доставить на все запросы
• Результат: 90% запросов доставлено
• Клиент доволен что подрядчик приложил 100% усилий
• Заказчик понимает, что незавершенные запросы были вызваны непредвиденными проблемами, которые, вероятно, находятся вне контроля подрядчиков.

Подрядчик Б :

• Обязан к доставке на 90% запросов. Не уверены, что они могут поставить на оставшиеся 10%
• Результат: 90% запросов доставлено
• Заказчик разочарован тем, что подрядчик не пытался выполнить остальные 10% своих запросов
• Заказчик предполагает, что неполные 10% запросов были вызваны либо недостаточными усилиями, либо способностью подрядчика.

В обоих сценариях было доставлено одинаковое количество запросов; тем не менее, заказчик чувствовал, что «чрезмерно загруженный» Подрядчик А прилагал 100% усилий, и использовал это для подтверждения того, что оставшиеся запросы действительно были трудными, на счет Подрядчика А.

С другой стороны, заказчик чувствовал, что Подрядчик Б не прилагает 100% усилий, и его неспособность выполнить все запросы была вызвана нехваткой Подрядчика Б или способностью.

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

Вы должны сказать им, чтобы дать вам время, чтобы создать «шип решение» .

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

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

Вот что написано в документации по eXtreme Programming :

Создавайте шиповые решения, чтобы найти ответы на сложные технические или дизайнерские проблемы. Решение Spike - очень простая программа для изучения потенциальных решений. Создайте шип только для решения рассматриваемой проблемы и игнорируйте все другие проблемы. Большинство шипов недостаточно хороши, чтобы их удерживать, поэтому рассчитывайте выбросить их. Цель состоит в том, чтобы уменьшить риск технической проблемы или повысить надежность оценки пользовательской истории. Когда из-за технических сложностей возникает опасность задержать развитие системы, поставьте пару разработчиков на проблему на неделю или две и уменьшите потенциальный риск.

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