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

13

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

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

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

TCSGrad
источник
20
В программировании все возможно. Просто помните, что «Да» не является ответом на «Сколько времени это займет?»
Стивен Эверс
9
@SnOrfus: Некоторые проблемы просто не могут быть решены. Если вы думаете иначе, запрограммируйте программу прогнозирования погоды, которая сообщит вам, будет ли у нас белое Рождество.
Лорен Печтел
5
@Earlz: это предполагает, что вселенная детерминирована, что не обязательно верно.
whatsisname
4
Извините, невозможно. Погода становится хаотичной через семь-десять дней. Есть очень известная статья на тему «Предсказуемость: взмах крыльев бабочки в Бразилии запускает торнадо в Техасе? Эдвард Лоренц.
Дэвид Хаммен
26
Если программисты собираются давать обещания, которые они не могут сдержать, что будут делать продавцы?
JeffO

Ответы:

20

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

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

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

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

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

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

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

Дэвид Хаммен
источник
2
+1 Я не просматривал этот список, связанный ранее, хорошая работа для указания на то, что там есть действительно ужасный совет. Парень может быть хорошим разработчиком, я понятия не имею, но он уверен, что он, как правило, не очень хороший знак, и этот совет гласит, что он приходит от какой-то ежемесячной тряпки для ИТ-менеджеров.
Джимми Хоффа
+1 - я никогда не говорю «Нет» клиентам (если я не хочу их больше видеть) - Это всегда в духе «Это будет стоить X долларов», «Ваш технологический стек не поддерживает это» и т. Д. «Нет» закрывает вопрос мертвым. используйте ответы, которые открывают это для дальнейшего обсуждения. например, "... но я мог бы дать вам 90% того, что вы хотите, за 10% стоимости" или ".... Но я мог бы реализовать это таким образом и дать вам решение, которое работает таким образом ...."
Mattnz
1
@mattnz - Сложно сказать «Нет», но иногда это необходимо. "Можете ли вы сделать это изменение к завтрашнему дню?" Ну нет. Но я могу получить его к концу недели. «Не могли бы вы провести анализ по методу Монте-Карло с каждой из этих нескольких сотен контрольных переменных, случайным образом меняющихся за цикл?» Это тот, который получил ответ «в каком тысячелетии вы хотите получить результат». Я обсудил проклятие размерности и предложил свести этот список к чему-то разумному. Важно то, что вы говорите «нет», но иногда вам приходится говорить «нет». Дипломатически, конечно.
Дэвид Хэммен
Частота отказов в 10% была бы ОГРОМНЫМ улучшением по сравнению с текущими средними показателями успешной доставки ПО.
Грэм
Что касается аналогии с посадкой самолетов - самолеты приземляются благополучно каждый день. Если я пилот и отвечаю «позвольте мне вернуться к вам по этому вопросу» на вопрос, могу ли я благополучно приземлиться, это не принесет мне никакой кармы с пассажирами. Даже если я знаю, что есть небольшая вероятность неудачной посадки, это хороший пример того, где проявление уверенности в моих способностях пилота важнее, чем сосредоточение на малой вероятности неудачи.
Клифф
24

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

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

Жанна Боярская
источник
17
Часто лучше убедиться, что клиент сообщает вам, какую проблему он хочет решить, а не заставлять его идти вразрез с решением, которое он хочет . Получите проблему .. и скажите им решение.
Саймон Уайтхед
+1 и более - два очень хороших замечания, которые вы делаете - никогда не говорите «нет» и не теряйте авторитет со своим клиентом.
Mattnz
+1 «Клиент будет уважать вас, если вы честны». Это утверждение так верно и стоит золота. При представлении вариантов клиенту будьте честны. Просто скажите им, что они просят не какой-то заранее созданный виджет, который вы можете купить и подключить. Дайте им знать, что они просят о специальном решении, а специальное программное обеспечение очень дорого. Обычно это приводит к одной из двух вещей. 1.) Они хотят рентабельную альтернативу. 2.) Они готовы платить за нестандартное решение. В любом случае это победа / победа.
Майкл Райли - AKA Gunny
6

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

Джошуа Бернс
источник
6

Этот вопрос был официально изучен и рассматривается совместно разработанным Кодексом этики 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

DeveloperDon
источник
+1 за ссылку на кодекс этики за ответ на вопрос об этике.
Джей Элстон
5

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

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

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

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

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

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

Билл
источник
4

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

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

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

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

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

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

Подрядчик А :

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

Подрядчик Б :

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

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

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

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

утес
источник
3

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

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

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

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

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

Тулаинс Кордова
источник
1

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

ронин
источник
1
это лучший способ ... сделать пользователей несчастными. Чаще всего это приводит к сокращению прибыли
комнат
3
Честно говоря, для некоторых внутренних разработчиков это не страшная идея. Внутренняя работа, как правило, не оплачивается напрямую (ИТ - это только часть общего бюджета), и вы можете быть перегружены запросами на дерьмо, потому что заказчики не теряют денег, рассылая вам работу.
Грэм