В статье из 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% запросов.
Предположим, клиент должен выбрать один из двух сценариев:
Подрядчик А :
Подрядчик Б :
В обоих сценариях было доставлено одинаковое количество запросов; тем не менее, заказчик чувствовал, что «чрезмерно загруженный» Подрядчик А прилагал 100% усилий, и использовал это для подтверждения того, что оставшиеся запросы действительно были трудными, на счет Подрядчика А.
С другой стороны, заказчик чувствовал, что Подрядчик Б не прилагает 100% усилий, и его неспособность выполнить все запросы была вызвана нехваткой Подрядчика Б или способностью.
Отказ от ответственности: я не защищаю чрезмерную приверженность как стратегию; это всего лишь наблюдение за возможной реальной ситуацией в мире, в которой чрезмерное выполнение может иметь положительные результаты.
источник
Вы должны сказать им, чтобы дать вам время, чтобы создать «шип решение» .
Решение Spike - это небольшая программа, которая, кодируя ее, позволяет выяснить, как сделать, или даже вообще возможно, что-то, что создает неопределенность в проекте.
Например, предположим, что вы никогда не отправляли SMS программно, но каким-то образом вы знаете, что это возможно. Шиповым решением было бы сделать небольшую программу, которая отправляет SMS. Таким образом, это больше не является неопределенностью, и вы можете сделать дополнительные оценки целесообразности.
Вот что написано в документации по eXtreme Programming :
источник
Согласно моему опыту, когда пользователь запрашивает что-то, вы должны попросить его предоставить подробную информацию о том, что пользователь действительно хочет или нуждается. Чаще всего вы никогда не услышите о запросе снова.
источник