Как Вы заставляете нетехнических людей ценить проблему неUI? [закрытый]
@ Ответ RajeevPNadig был тем, что я искал, но код возвращает неправильные значения, как написано.
Мое редактирование ответа было отклонено, и мне сказали, чтобы он был опубликован как мой собственный ответ. Это может вернуть некоторые результаты, которые кажутся немного странными, но не являются технически неправильными.
// startDate must be a
function dateAgo(date) {
var startDate = new Date(date);
var diffDate = new Date(new Date() - startDate);
return ((diffDate.toISOString().slice(0, 4) - 1970) + "Y " +
diffDate.getMonth() + "M " + (diffDate.getDate()-1) + "D");
}
Тогда вы можете использовать его следующим образом:
// based on a current date of 2018-03-09
dateAgo('1972-11-30'); // "45Y 3M 9D"
dateAgo('2017-03-09'); // "1Y 0M 0D"
dateAgo('2018-01-09'); // "0Y 2M 0D"
dateAgo('2018-02-09'); // "0Y 0M 28D" -- a little odd, but not wrong
dateAgo('2018-02-01'); // "0Y 1M 5D" -- definitely "feels" wrong
dateAgo('2018-03-09'); // "0Y 0M 0D"
Вещи могут получить немного странно, если вы вызываете dateAgo с текущей датой и не используете строку YYYY-MM-DD, то есть:
oneMinuteAgo = Date.now() - 60000;
dateAgo(oneMinuteAgo); // "0Y 11M 30D" -- ???
Если ваш вариант использования - это только строки даты, то это должно работать очень хорошо для большинства людей.
11 ответов
Каждое ремесло имеет свои несексуальные стороны. Вещи, которые должны быть сделаны, но никто не замечает их непосредственно. В продуктовом магазине кто-то должен организовать, как и когда заполнить полки бакалеи, таким образом, они всегда выглядят новыми. В прачечной Вам нужен кто-то, кто думает о том, как процессы должны быть оптимизированы так, чтобы клиент получил свою одежду вовремя.
хитрая часть: клиент не заметит, когда эти тонкие вещи были сделаны правильно ДО УВЕДОМЛЕНИЙ HE ОНИ ОТСУТСТВУЮТ! Как то, когда прачечная не готова вовремя, но два дня поздно, или овощи в супермаркете имеют коричневые пятна и выглядят ужасными.
То же идет для IT. Вы не замечаете хорошие транзакции, пока Ваш крупный клиент не стучит в Вашу дверь и говорит Вам, что важный и дорогой проект перестал работать, потому что записи базы данных Вашего продукта были загадочно перепутаны. Вы не замечаете хорошей безопасности, пока клиентские данные кредитной карты не обнаруживаются в Elbonia (и вскоре после того, как слово находится в центральных газетах, предупреждающих клиентов Вашей компании).
вещь действительно необходимо стучать в снова и снова, и снова то, что программное обеспечение не статично. Об этом нужно заботиться даже после того, как его фаза начального развития закончена. Это не просто продукт, который Вы покупаете однажды и забываете о. Каждый автопроизводитель знает, что сервисы имеют главное значение для продуктов, которые они создают, просто потому что вещи произойдут, которые должны быть зафиксированы и улучшены. Это - то же с программным обеспечением.
Так делают презентацию, визуализируют, выражают словами, переводят Вашу техническую информацию в преимущества. Деловые люди не заботятся о Вашем желании эстетики кода в проекте рефакторинга, но они поймут, что Ваши изменения помогут продукту стать более надежным, получить лучшую репутацию и уменьшить объем будущих запросов на обслуживание. Заставьте их понять путем показа им преимуществ!
Большой +1 для аналогий и метафор. Если возможно, найдите тот, который найдет отклик у личных интересов Вашей аудитории (если это будут 1-2 человека). Для общих метафор я часто использую пригородное движение или метро по некоторым причинам.
, например, Мы в настоящее время перемещаем приложение от OODB до Пост-ГРЭС/Быть в спящем режиме: объем этой работы сделан в Выпуске '4'. Многие специалисты по проблемной области спрашивали, почему существует так мало стоящих с пользователем функций в R4. Я регулярно говорю им, что мы 'разрывали город, чтобы вставить метро. Это очень дорого и бесспорно опасно, но после того как это сделано, преимущества в R5 + будут поразительны, действительно'. Истинный разговор более включен, но я могу возвратиться к этой теме снова и снова, много позже R4. Месяцы с этого времени, я надеюсь сказать, что "Вы попросили X, и это теперь очень легко - точно, потому что Вы позволяете нам вставить то метро назад в R4".
Самый верный способ заставить верхнее управление уровнем подкупать на технической разработке состоит в том, чтобы представить его измеримым способом. Идеально эта измеримая мера находится в $$. Необходимо объяснить им последствия экономии на целостности данных, безопасности, транзакциях, и т.д. и как это будет влиять на customer\user сообщество и в конечном счете нижнюю строку. Необходимо быть осторожными в этих ситуациях, потому что иногда управление ожидает эти нефункциональные требования к "просто работе". Если это верно, необходимо или оценить высоко, и работа над этими объектами вместе с видимой работой UI (незнание является счастьем), или необходимо зарегистрировать эти области потребности, поскольку Вы общаетесь с управлением поэтому, если вещи действительно разлагаются, как Вы ожидаете, это не Ваше задание, которое находится на строке.
Люди того же самого делали в течение тысяч лет: нарисуйте изображения. Схематически изобразите проблемы, используйте визуальные метафоры, знакомые Вашей аудитории, перетащите проблему в их территорию.
Принятие они не являются намеренно тупыми...
К сожалению, это обычно берет аварию или два, прежде чем этот материал привлечет внимание, которого это заслуживает.
Это действительно зависит, на что похоже Ваше управление, но у меня была удача со старым добрым кристально честным fearmongering. Если Вы проходите несколько ситуаций восстановления и указываете кто-то попытка быть обвиненными, если они происходят, которого может быть достаточно, чтобы заставить их arsecovering инстинкты умереть и наконец обратить внимание :)
Автомобильные аналогии.
Все знают, что 'система' и это достаточно сложны для изображения страшной ситуации.
Я борюсь с по существу тем же видом ситуации. Является ли это выходом управлением или принятием пользователем/спонсором, проблема остается одним из различных словарей, приоритетов и перспектив. я задал подобный вопрос здесь .
я также получил разнообразные ответы, дразняще близко к полезному, но достаточно не совсем категоричный. Просмотр и поиск НАСТОЛЬКО использующих соответствующих ключевых слов привели меня находить применимое понимание в различных ответах распространенным по многим несвязанным вопросам. Найти и извлечь эти драгоценные камни привели меня позировать этот вопрос на горной промышленности сайта .
было бы полезно смочь отметить различные ответы и видеть их всех в единственном списке, но увы, та функциональность еще не доступна в ТАК. Я предложил это на uservoice.
Hope Вы находите что-то, что можно использовать из ссылок, которые я дал.
Правильный вид противостояния вопросу является секретом.
- это хорошо для катастрофического отказа каждых 5 веб-страниц?
- мы должны защитить номера кредитных карт?
- , придется хорошо заплатить подрядчикам для развертывания патча каждые выходные?
- Вы хотели это теперь, или Вы хотели, чтобы это работало?
Устойчивость. Когда это сводится к нему, необходимо говорить их язык, который является, как это влияет на их нижнюю строку. Если это - проблема безопасности или правильности, необходимо сказать им, что клиенты не собираются хотеть неправильно действовать продукты, неважно, как хороший они смотрят.
Мне нравится идея Технический Долг , потому что это позволяет техническим вопросам быть переведенными (хотя свободно) в денежные проблемы - и деньги - что-то, что большинство менеджеров действительно понимает.
, Хотя идея технического долга была первоначально применена к архитектурным проблемам, это может использоваться более широко для любого типа ситуации, где существует давление, чтобы срезать путь - то есть, войти в технический долг - а не сделать это, исправляются в первый раз. (Делать правильно его является эквивалентом коплению купить что-то - это занимает время - вместо того, чтобы покупать его в кредит и войти в долг.)
Так же, как долги могут быть хорошими (например, ипотечные кредиты) и плохо (например, кредитные карты), таким образом, технический долг может быть хорошим и плохим. Я не попытаюсь характеризовать различия полностью, но хороший технический долг может быть прослежен точно, так, чтобы Вы знали, сколько в долгах Вы.
Так, попытайтесь объяснить свою важную, проблему неUI с точки зрения технического долга и стоимости не фиксации его с точки зрения выплачивания процентов по той задолженности.
Описательное изображение действительно помогает нетехническим людям понять то, о чем Вы говорите. Например, ниже пример от Sun, описывающего, как информация обрабатывается в одном из их несколько сложных приложений.
(источник: sun.com )
Попытка объяснить это приложение в словах была бы невозможна нетехнарю. Указание на схему и говорит, что взгляд, эта часть является нашим слабым местом, мы должны улучшить его. Это будет иметь смысл им. Если они будут чувствовать, что у них есть некоторое понимание того, что Вы делаете, то они будут намного более готовы поддерживать Ваш запрос.