Ну а зачем ты у меня спрашиваешь, если до этого писал так, как будто знаешь? Там стоит диодный мост, зачастую даже стабилитронный мост + гасящие конденсаторы + сглаживающие конденсаторы.
В самсунговских зарядках, к примеру, было ровно так.
Вместо того, чтобы выдать безопасные источники питания, учитель пережёг все зарядки от телефонов, которые принесли ученики. Со словами «они плохие». Превосходно.
Чувак, это дети. Если с ними что-то случится — а паяльником залезть в схему под напряжением как нечего делать. Паяльник, скорее всего заземлён, и это будет ноль на фазу — то будет плохо всем, и автору, и детям. Не знаю, кому хуже.
решено снабдить каждого юного радиолюбителя блоком питания на 5В. У большинства они уже наверняка есть: почти любая зарядка от телефона, планшета, плеера и т.д. У кого нет — я раздам из собственных запасов.
Ойойойойой! Даже и не думайте так делать! У этих зарядок от телефона и планшета НЕТ гальванической развязки с первичным контуром (220В), соответственно, ими нельзя пользоваться в работе начинающих радиоинженеров.
Однако большинство пунктов этой статьи посвящены сбору бизнес-требований
Это не так, и вам на это указывают. Однако обозначим это ваше высказывание как [А].
В ПОЛОВИНА статьи посвящена сбору и выявлению требований
Это не так. Обозначим эту вашу фразу как [Б].
кроме тех аспектов что я УЖЕ написал в статье
Вы ничего не сказали про аспекты
Кроме того, чуть ниже вы писали мне вот что: «Короче«Нужно анализировать бизнес-требования». Как это относится к теме статьи — вы так и не пояснили» (пусть это будет [В]).
Непонятно, зачем тогда вы половину и даже большинство пунктов своей статьи, согласно вашим словам, соответственно, [Б] и [А], посвятили вопросам, которые, согласно вашему же высказыванию [В], непонятно как относятся к теме статьи?
Да, давайте уже прекратим, видимо, мне не удастся вам пояснить, что анализ бизнес-требований имеет первостепенное отношение к тому, «Как сделать такую ERP систему, чтобы пользователи не бегали в ИТ за отчетами»
Вы обещали переключиться на обсуждение, но всё пытаетесь давать советы, не касающиеся темы. Странно.
По поводу отличного парня: если он для вас авторитет, я мог бы показать письмо от него, где он хвалит меня за аккуратность подхода к анализу проблемы и постановке задачи, и последовательность изложения. Думаю, он не стал бы лгать или приукрашивать
Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.
Это замечание означает, что у вас фактически есть скоуп пользователей за рамками фокус-группы при разработке. Т.е. вы обкатываете систему на одной группе, а по факту ею начинает пользоваться другая (те самые телефонные пользователи), нужды которых вы не исследовали. Просто для этой группы у вашей БИЗНЕС-системы выставлен такой специфический API, «телефонный».
Что вы дальше будете делать с этой информацией?
Сделаю так, чтобы в моём процессе разработке существовал агент, представляющий интересы этой группы, оценю несколькими независимыми способами стоимость удовлетворения этих интересов различными вариантами решений и буду поступать в соответствии с полученными цифрами.
Ну ок. Приходит к вам задача —..
Вы меня извините, но представителей бизнеса и по конкретным задачам я консультирую платно. Это принципиальная позиция по ряду причин. Если интересует — прошу в личные сообщения.
Замечу только, что отдельные требования в отрыве от общей системы требований и сути бизнес-процесса рассматривать бессмысленно, всё равно что просить нарисовать проект домика, а по готовности уточнить, что нужен был домик для слепого жирафа
Возможно, полезный совет: если у вас есть статистика и данные, это очень, очень хорошо, их стоит показывать на слайде в соответствующем месте. Именно что с развесовкой (80%, 20%, 3 месяца)
Ход мысли думаю, что понял, не согласен категорически. Потому что к тому, что изложено, возникают вопросы:
Далее я решал уже проблему «длинного хвоста»
Я так и сказал, вы решаете те проблемы, которые хотите, вместо тех, которые пользователю нужны. Он понятия не имеет про «длинные хвосты», это проблема вашего способа анализа и вашей области (разработка систем). Доклад имеет смысл «Как я решал проблемы своей системы, вызванные проблемогенерирующими решениями, принятыми мной же»
Все их формализовывать и выдавать в интерфейс а) слишком дорого б)слишком захламит интерфейс редкими операциями.
Я и говорю — вы решаете сэкономить. Если слайд будет назван «как сэкономить на бизнес-анализе, и при этом закрыть Х% потребностей» — я вообще не буду спорить и полностью соглашусь с докладом.
Но в 20% случаев пользователь использует очень разнообразные выборки
В третий раз напишу: выясните, _почему_ ему нужны эти разнообразные выборки. Потратьте уже эти деньги. Ваша система не даёт ему нужных данных, он крутится как может. Очевидно, бедный юзер уже готов сам придумать, какие запросы составить и в каком порядке выполнить, чтобы достать информацию, которая ему нужна, из явно недружелюбной системы.
Не надо идти у него на поводу — решение «дать конструктор» в случае OLTP очевидное и неправильное: пользователю нужно решить сиюминутные оперативные проблемы, и решение, которое он попросит, будет таким же ситуативным и уродливым.
в большинстве случаев очень похожий источник данных в системе есть. Но не хватает его некой обработки.
Вы опять подменяете проблему видением её очевидного решения. В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения.
Если будет преложен пользователю инструмент, который остается удобным без навыков программирования но снимает 20-40% таких запросов, то это — хорошо.
Не знаю. По-моему, нет. Вы опять решаете задачу «как заставить пользователя составлять запросы»
Далее я формализовал, какие инструменты для этого нужны: доступ ко всем данным, фильтры, выгрузка в популярный формат.
Я заметил, да. Опять же обращу внимание — для чего «этого»? Для того, чтобы порешать проблемы, перечень которых вы перед собой достаточно волюнтаристски поставили. Это тоже пойнт моего возражения.
мой ход рассуждения не противоречит Вашему
Конечно, противоречит. Я утверждаю «не надо решать проблемы собственного решения, предложите решение без этих проблем». Но куда там, вы уже спешите «формализовал, какие инструменты для этого нужны» (решать, замечу, ваши проблемы).
Сперва — решаем основные сценарии. Потом работаем над длинным хвостом.
Знаете, я достаточно много общаюсь с разработчиками, чтобы говорить, что это — слова для напускания тумана, не опрокидывающиеся ни во что материальное, и ни в какие обязательства, и уж тем более преимущества. Их без потери смысла может применить и электромонтёр, и тот, кто красит заборы.
но для этого «длинного хвоста» сделайте более продвинутую кнопку фильтров.
Скажите, вы правда считаете, что если фильтры передвинуть в отдельное окно, открывающееся по кнопке, а не держать на основной форме, то это серьёзный вклад в улучшение UX? По мне — так не поменялось ни-че-го.
Да, давайте переключимся на обсуждение.
Вообще не хотел вас ни в чём обвинять и не обвинял. Если это где-то так прозвучало, что типа ваши слова — то не берите на своё счёт, это была такая фигура речи и форма высказывания, когда говорят от первого лица. Вы тоже, пожалуйста не приписывайте мне манипуляций и другого, я это точно не хотел бы проделывать.
Ну так вот.
Аргумент по поводу таблиц вот какой. Есть хорошая ценная максима «нужно дать пользователю ценные ему данные, а для этого следует снабдить его инструментом (в вашем случае — фильтрами)». Мне кажется, что в докладе акценты расставлены таким образом, что максима искажается, разворачивается и начинает звучать в обратную сторону: «нужно сделать пользователю фильтры, чтобы он мог выбирать ценные данные».
Чувствуете разницу?
Появляется чисто технический аспект «а что такое хорошие фильтры? а что такое хорошая таблица?». И разработчик отвечает так, как разработчик «это когда бесконечно гибко», «это когда ВСЁ настраивается», а пользователь задвигается на второй план. Я из опыта могу судить, это происходит потому, что разработчикам интересно «искать там, где светло, а не там где потеряли ключи» (ну, т.е. делать то, что они могут сделать, как им кажется, хорошо — сложные фильтры с овер 9000 полей и конструкций, а не то, что нужно пользователю в его повседневной работе).
Главный первый совет звучит так: изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик, или вообще без лишних кликов, по дефолту уже были бы все данные. Это лучший self-service, когда даже self service не требуется. Поверьте, это окупается. И наоброт, интерфейсы «your typical app» всячески и дальше подталкивают к такому же уродскому UX, и от него чертовски сложно избавиться, и очень дешёво клепать всё неудобнее и неудобнее
Это не причины, это выдуманное обоснование, почему следует делать так, как сделали вы. Это можно топ-менеджерам на демо крутить, там, нервы, показывать ролик про счастливого пользователя, собирающего себе подфильтровку на огромном экране, рядом радостные жена и дети.
Я ж не спорю, что вы умеете или нет разрабатывать сложные фильтры. Умеете, могёте. Знаете, как. Пацаны вообще ребята. Но только цель «сделать ему удобно» заменилась целью «сделать офигенный фильтр». Круто, и разработчиков есть чем занять, и ползователь вроде занят чем-то, но не то.
Я понимаю, лучше всего разработчики умеют… разрабатывать. К сожалению, каждому конкретному бизнес-пользователю нужно не это, ему фиолетово, умеете вы разрабатывать, или не умеете. Но вы это считаете гордостью, наличие кнопки со СЛОЖНЫМИ фильтрами. А это, напротив, замаскированный провал аналитической работы. Надеюсь, когда-нибудь поймёте.
P. S. В целом, мне кажется, вы слишком много мне советуете, что мне делать, а что нет; и второй раз мне пеняете, что я не смотрел ролик. Если беседу в этом стиле вы называете обсуждением, то я в таких обсуждениях не участвую. Мне непонятно, с какой целью вы занимаете защитную позицию. Вы хотите выслушать, кто что думает по этому поводу — вот. Напрасно пытаетесь переубедить.
Если вы хотите извлечь пользу, вам следует слушать, а не менторствовать в комментариях, иначе получается не обмен мнениями, а проповедование.
Как считаете, какие лишние? А может есть те, которые бы Вы сами добавили?
А знаете, вы напишите текстом список, если интересно обсудить. А то отсылать к минуте и секунде видео ненаглядно, а без этого — непредметно.
Ну а на то, что успел углядеть — только без обид на то, что я скажу, ок? Я бы 2/3 выкинул, начиная с первого же. Они там не просто полезные, они там вредные местами. Вот, скажем, возьмем совет «сделать могучий фильтр». Это _очень_ вредный совет.
Вы по сути тут призываете дистанцироваться от реальных бизнес-сценариев и потребностей пользователя. Выкатываете ему конструктор некоторой мощности, и даёте ему пинка под зад. Мол, «я понятия не имею, зачем тебе моя программа, вон, фильтры есть, собери себе что-то, что поможет тебе решить твою задачу. А какая у тебя задача, что ты там за выборки собираешься выборки делать, и что за бизнес-кейсы, я понятия не имею, мне не до тебя, глупый ты юзер, иди, не мешай дяде разработчику».
Проверочный вопрос — попробуйте, перечислите 5 самых частых сложных фильтров, которыми юзеры пользуются чаще всего. Не можете? Это потому, что вам неинтересно, что именно пользователю нужно. Человеку, купившему дрель, не нужна дрель — ему нужны дырки. Человеку, пользующемуся фильтрами, не нужны фильтры — ему нужны интересные ему данные. Изучайте своих пользователей, узнавайте, понимайте сценарии, предоставляйте инструменты.
Как я считаю, пример с 1С вы приводите совершенно неверный. 1С — это конструктор для программиста; предполагается, что разработчик конфигурации запилит этот UI до состояния «ура, пользователю есть всё для его конкретной работы», а не «на тебе груду полей, фильтров и условий, и учебник булевой алгебры впридачу».
Описывается, как именно хорошо, и что именно предлагается сделать. Но для этого нужно посмотреть
Я смотрел, да. Реально полезный совет — это навигатор по связям, очень хорошая фича. Что не порадовало в нём — это другая терминология: в модели у вас сущности, а навигатор почему-то в терминах таблиц. Видимо, сами разработчики мыслят в терминах «сущность» = «плюс-минс таблица», что непременно им потом «аукнется» семантическими разрывами.
Ещё один хороший совет — история по сущностям. Остальные — на мой взгляд либо вредные, либо не относятся к self-service BI, а к рациональному дизайну интерфейсов.
Совершенно верно говорите, есть ещё мотивационная часть, которую я не упоминал из-за бесконечного разнообразия.
Но в данных советах в видео нет «перестаньте считать, что вы монополисты» или «начните рефакторинг», или «не оставляйте на todo», разве нет? Соответственно, если в ситуации виновата неверная мотивация, то она и не подвинется. Именно это я и имел в виду своим комментарием
… Ответ на вопрос в заголовке и многие другие вопросы читайте в новом выпуске журнале «А х его з» :)
Если честно, встречный вопрос — не кажется ли вам, что 10 советов — это слишком много? Я серьёзно.
И ещё вопрос: я вот смотрю на кадры презентации и читаю текст «Сделайте отличные таблицы» или «Заполнение форм должно быть понятно», и задаюсь вопросом — неужели есть хоть один разработчик, который изобразил ERP-систему, потом смотрит на форму и делает вывод: «да, отстой таблицы вышли» или там «да, сделали систему и в ней запроектировали формы непонятные вообще». Нет же. Все стараются делать самое лучшее; при этом совершенно непонятно, откуда берётся такое количество отстойного софта (особенно корпоративного).
С их-то точки зрения разработано так, что таблицы отличные, и форма заполняется понятно; они уже следуют вашим советам изначально.
В самсунговских зарядках, к примеру, было ровно так.
Чувак, это дети. Если с ними что-то случится — а паяльником залезть в схему под напряжением как нечего делать. Паяльник, скорее всего заземлён, и это будет ноль на фазу — то будет плохо всем, и автору, и детям. Не знаю, кому хуже.
В 99% зарядок для телефонов/смартфонов никакого намёка на импульсное преобразование нет, и трансформатор туда не ставят — это тупо дорого.
Это ОЧЕНЬ опасно для детей!
— YAGNI
— DRY
— fail fast (let it crash)
Это не так. Обозначим эту вашу фразу как [Б].
Вы ничего не сказали про аспекты
Кроме того, чуть ниже вы писали мне вот что: «Короче«Нужно анализировать бизнес-требования». Как это относится к теме статьи — вы так и не пояснили» (пусть это будет [В]).
Непонятно, зачем тогда вы половину и даже большинство пунктов своей статьи, согласно вашим словам, соответственно, [Б] и [А], посвятили вопросам, которые, согласно вашему же высказыванию [В], непонятно как относятся к теме статьи?
По поводу отличного парня: если он для вас авторитет, я мог бы показать письмо от него, где он хвалит меня за аккуратность подхода к анализу проблемы и постановке задачи, и последовательность изложения. Думаю, он не стал бы лгать или приукрашивать
Сделаю так, чтобы в моём процессе разработке существовал агент, представляющий интересы этой группы, оценю несколькими независимыми способами стоимость удовлетворения этих интересов различными вариантами решений и буду поступать в соответствии с полученными цифрами.
Вы меня извините, но представителей бизнеса и по конкретным задачам я консультирую платно. Это принципиальная позиция по ряду причин. Если интересует — прошу в личные сообщения.
Замечу только, что отдельные требования в отрыве от общей системы требований и сути бизнес-процесса рассматривать бессмысленно, всё равно что просить нарисовать проект домика, а по готовности уточнить, что нужен был домик для слепого жирафа
Ход мысли думаю, что понял, не согласен категорически. Потому что к тому, что изложено, возникают вопросы:
Я так и сказал, вы решаете те проблемы, которые хотите, вместо тех, которые пользователю нужны. Он понятия не имеет про «длинные хвосты», это проблема вашего способа анализа и вашей области (разработка систем). Доклад имеет смысл «Как я решал проблемы своей системы, вызванные проблемогенерирующими решениями, принятыми мной же»
Я и говорю — вы решаете сэкономить. Если слайд будет назван «как сэкономить на бизнес-анализе, и при этом закрыть Х% потребностей» — я вообще не буду спорить и полностью соглашусь с докладом.
В третий раз напишу: выясните, _почему_ ему нужны эти разнообразные выборки. Потратьте уже эти деньги. Ваша система не даёт ему нужных данных, он крутится как может. Очевидно, бедный юзер уже готов сам придумать, какие запросы составить и в каком порядке выполнить, чтобы достать информацию, которая ему нужна, из явно недружелюбной системы.
Не надо идти у него на поводу — решение «дать конструктор» в случае OLTP очевидное и неправильное: пользователю нужно решить сиюминутные оперативные проблемы, и решение, которое он попросит, будет таким же ситуативным и уродливым.
Вы опять подменяете проблему видением её очевидного решения. В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения.
Не знаю. По-моему, нет. Вы опять решаете задачу «как заставить пользователя составлять запросы»
Я заметил, да. Опять же обращу внимание — для чего «этого»? Для того, чтобы порешать проблемы, перечень которых вы перед собой достаточно волюнтаристски поставили. Это тоже пойнт моего возражения.
Конечно, противоречит. Я утверждаю «не надо решать проблемы собственного решения, предложите решение без этих проблем». Но куда там, вы уже спешите «формализовал, какие инструменты для этого нужны» (решать, замечу, ваши проблемы).
Знаете, я достаточно много общаюсь с разработчиками, чтобы говорить, что это — слова для напускания тумана, не опрокидывающиеся ни во что материальное, и ни в какие обязательства, и уж тем более преимущества. Их без потери смысла может применить и электромонтёр, и тот, кто красит заборы.
Скажите, вы правда считаете, что если фильтры передвинуть в отдельное окно, открывающееся по кнопке, а не держать на основной форме, то это серьёзный вклад в улучшение UX? По мне — так не поменялось ни-че-го.
Вообще не хотел вас ни в чём обвинять и не обвинял. Если это где-то так прозвучало, что типа ваши слова — то не берите на своё счёт, это была такая фигура речи и форма высказывания, когда говорят от первого лица. Вы тоже, пожалуйста не приписывайте мне манипуляций и другого, я это точно не хотел бы проделывать.
Ну так вот.
Аргумент по поводу таблиц вот какой. Есть хорошая ценная максима «нужно дать пользователю ценные ему данные, а для этого следует снабдить его инструментом (в вашем случае — фильтрами)». Мне кажется, что в докладе акценты расставлены таким образом, что максима искажается, разворачивается и начинает звучать в обратную сторону: «нужно сделать пользователю фильтры, чтобы он мог выбирать ценные данные».
Чувствуете разницу?
Появляется чисто технический аспект «а что такое хорошие фильтры? а что такое хорошая таблица?». И разработчик отвечает так, как разработчик «это когда бесконечно гибко», «это когда ВСЁ настраивается», а пользователь задвигается на второй план. Я из опыта могу судить, это происходит потому, что разработчикам интересно «искать там, где светло, а не там где потеряли ключи» (ну, т.е. делать то, что они могут сделать, как им кажется, хорошо — сложные фильтры с овер 9000 полей и конструкций, а не то, что нужно пользователю в его повседневной работе).
Главный первый совет звучит так: изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик, или вообще без лишних кликов, по дефолту уже были бы все данные. Это лучший self-service, когда даже self service не требуется. Поверьте, это окупается. И наоброт, интерфейсы «your typical app» всячески и дальше подталкивают к такому же уродскому UX, и от него чертовски сложно избавиться, и очень дешёво клепать всё неудобнее и неудобнее
Это не причины, это выдуманное обоснование, почему следует делать так, как сделали вы. Это можно топ-менеджерам на демо крутить, там, нервы, показывать ролик про счастливого пользователя, собирающего себе подфильтровку на огромном экране, рядом радостные жена и дети.
Я ж не спорю, что вы умеете или нет разрабатывать сложные фильтры. Умеете, могёте. Знаете, как. Пацаны вообще ребята. Но только цель «сделать ему удобно» заменилась целью «сделать офигенный фильтр». Круто, и разработчиков есть чем занять, и ползователь вроде занят чем-то, но не то.
Я понимаю, лучше всего разработчики умеют… разрабатывать. К сожалению, каждому конкретному бизнес-пользователю нужно не это, ему фиолетово, умеете вы разрабатывать, или не умеете. Но вы это считаете гордостью, наличие кнопки со СЛОЖНЫМИ фильтрами. А это, напротив, замаскированный провал аналитической работы. Надеюсь, когда-нибудь поймёте.
P. S. В целом, мне кажется, вы слишком много мне советуете, что мне делать, а что нет; и второй раз мне пеняете, что я не смотрел ролик. Если беседу в этом стиле вы называете обсуждением, то я в таких обсуждениях не участвую. Мне непонятно, с какой целью вы занимаете защитную позицию. Вы хотите выслушать, кто что думает по этому поводу — вот. Напрасно пытаетесь переубедить.
Если вы хотите извлечь пользу, вам следует слушать, а не менторствовать в комментариях, иначе получается не обмен мнениями, а проповедование.
А знаете, вы напишите текстом список, если интересно обсудить. А то отсылать к минуте и секунде видео ненаглядно, а без этого — непредметно.
Ну а на то, что успел углядеть — только без обид на то, что я скажу, ок? Я бы 2/3 выкинул, начиная с первого же. Они там не просто полезные, они там вредные местами. Вот, скажем, возьмем совет «сделать могучий фильтр». Это _очень_ вредный совет.
Вы по сути тут призываете дистанцироваться от реальных бизнес-сценариев и потребностей пользователя. Выкатываете ему конструктор некоторой мощности, и даёте ему пинка под зад. Мол, «я понятия не имею, зачем тебе моя программа, вон, фильтры есть, собери себе что-то, что поможет тебе решить твою задачу. А какая у тебя задача, что ты там за выборки собираешься выборки делать, и что за бизнес-кейсы, я понятия не имею, мне не до тебя, глупый ты юзер, иди, не мешай дяде разработчику».
Проверочный вопрос — попробуйте, перечислите 5 самых частых сложных фильтров, которыми юзеры пользуются чаще всего. Не можете? Это потому, что вам неинтересно, что именно пользователю нужно. Человеку, купившему дрель, не нужна дрель — ему нужны дырки. Человеку, пользующемуся фильтрами, не нужны фильтры — ему нужны интересные ему данные. Изучайте своих пользователей, узнавайте, понимайте сценарии, предоставляйте инструменты.
Как я считаю, пример с 1С вы приводите совершенно неверный. 1С — это конструктор для программиста; предполагается, что разработчик конфигурации запилит этот UI до состояния «ура, пользователю есть всё для его конкретной работы», а не «на тебе груду полей, фильтров и условий, и учебник булевой алгебры впридачу».
Я смотрел, да. Реально полезный совет — это навигатор по связям, очень хорошая фича. Что не порадовало в нём — это другая терминология: в модели у вас сущности, а навигатор почему-то в терминах таблиц. Видимо, сами разработчики мыслят в терминах «сущность» = «плюс-минс таблица», что непременно им потом «аукнется» семантическими разрывами.
Ещё один хороший совет — история по сущностям. Остальные — на мой взгляд либо вредные, либо не относятся к self-service BI, а к рациональному дизайну интерфейсов.
Но в данных советах в видео нет «перестаньте считать, что вы монополисты» или «начните рефакторинг», или «не оставляйте на todo», разве нет? Соответственно, если в ситуации виновата неверная мотивация, то она и не подвинется. Именно это я и имел в виду своим комментарием
Если честно, встречный вопрос — не кажется ли вам, что 10 советов — это слишком много? Я серьёзно.
И ещё вопрос: я вот смотрю на кадры презентации и читаю текст «Сделайте отличные таблицы» или «Заполнение форм должно быть понятно», и задаюсь вопросом — неужели есть хоть один разработчик, который изобразил ERP-систему, потом смотрит на форму и делает вывод: «да, отстой таблицы вышли» или там «да, сделали систему и в ней запроектировали формы непонятные вообще». Нет же. Все стараются делать самое лучшее; при этом совершенно непонятно, откуда берётся такое количество отстойного софта (особенно корпоративного).
С их-то точки зрения разработано так, что таблицы отличные, и форма заполняется понятно; они уже следуют вашим советам изначально.