Comments 49
… Ответ на вопрос в заголовке и многие другие вопросы читайте в новом выпуске журнале «А х его з» :)
Если честно, встречный вопрос — не кажется ли вам, что 10 советов — это слишком много? Я серьёзно.
И ещё вопрос: я вот смотрю на кадры презентации и читаю текст «Сделайте отличные таблицы» или «Заполнение форм должно быть понятно», и задаюсь вопросом — неужели есть хоть один разработчик, который изобразил ERP-систему, потом смотрит на форму и делает вывод: «да, отстой таблицы вышли» или там «да, сделали систему и в ней запроектировали формы непонятные вообще». Нет же. Все стараются делать самое лучшее; при этом совершенно непонятно, откуда берётся такое количество отстойного софта (особенно корпоративного).
С их-то точки зрения разработано так, что таблицы отличные, и форма заполняется понятно; они уже следуют вашим советам изначально.
Если честно, встречный вопрос — не кажется ли вам, что 10 советов — это слишком много? Я серьёзно.
И ещё вопрос: я вот смотрю на кадры презентации и читаю текст «Сделайте отличные таблицы» или «Заполнение форм должно быть понятно», и задаюсь вопросом — неужели есть хоть один разработчик, который изобразил ERP-систему, потом смотрит на форму и делает вывод: «да, отстой таблицы вышли» или там «да, сделали систему и в ней запроектировали формы непонятные вообще». Нет же. Все стараются делать самое лучшее; при этом совершенно непонятно, откуда берётся такое количество отстойного софта (особенно корпоративного).
С их-то точки зрения разработано так, что таблицы отличные, и форма заполняется понятно; они уже следуют вашим советам изначально.
UFO just landed and posted this here
Совершенно верно говорите, есть ещё мотивационная часть, которую я не упоминал из-за бесконечного разнообразия.
Но в данных советах в видео нет «перестаньте считать, что вы монополисты» или «начните рефакторинг», или «не оставляйте на todo», разве нет? Соответственно, если в ситуации виновата неверная мотивация, то она и не подвинется. Именно это я и имел в виду своим комментарием
Но в данных советах в видео нет «перестаньте считать, что вы монополисты» или «начните рефакторинг», или «не оставляйте на todo», разве нет? Соответственно, если в ситуации виновата неверная мотивация, то она и не подвинется. Именно это я и имел в виду своим комментарием
UFO just landed and posted this here
Коллеги, наверное я не смог удачно донести мысль? Те аспекты, которые я поднимаю по таблицам, на этапе разработки почти ничего не стоят и вряд ли с чем то конфликтуют. Конечно, есть и другие вещи, которые не делают, т.к. поджимали сроки и бюджет.
Но уж то, что касается таблиц, как мне кажется, не делается только из за нехватки понимания и опыта.
Но уж то, что касается таблиц, как мне кажется, не делается только из за нехватки понимания и опыта.
Не кажется ли вам, что 10 советов — это слишком много?
Как считаете, какие лишние? А может есть те, которые бы Вы сами добавили?
я вот смотрю на кадры презентации и читаю текст «Сделайте отличные таблицы»… неужели есть хоть один разработчик, который изобразил ERP-систему, потом смотрит на форму и делает вывод: «да, отстой таблицы вышли»
Уважаемый braindamaged, вы прочитали заголовок со слайда, но этого мало :) В выступлении я описываю, что такое хорошие таблицы с точки зрения Self-service BI, привожу удачные и неудачные примеры, показываю типовые ошибки.
Совет не просто «Сделайте хорошо». Описывается, как именно хорошо, и что именно предлагается сделать.
Но для этого нужно посмотреть :)
Хотел сделать статью с текстом, но признаюсь, пока нет времени. Разве что, если кто другой возьмется. Пока выложил хотя бы так, надеясь, что это будет кому-нибудь полезно.
Как считаете, какие лишние? А может есть те, которые бы Вы сами добавили?
А знаете, вы напишите текстом список, если интересно обсудить. А то отсылать к минуте и секунде видео ненаглядно, а без этого — непредметно.
Ну а на то, что успел углядеть — только без обид на то, что я скажу, ок? Я бы 2/3 выкинул, начиная с первого же. Они там не просто полезные, они там вредные местами. Вот, скажем, возьмем совет «сделать могучий фильтр». Это _очень_ вредный совет.
Вы по сути тут призываете дистанцироваться от реальных бизнес-сценариев и потребностей пользователя. Выкатываете ему конструктор некоторой мощности, и даёте ему пинка под зад. Мол, «я понятия не имею, зачем тебе моя программа, вон, фильтры есть, собери себе что-то, что поможет тебе решить твою задачу. А какая у тебя задача, что ты там за выборки собираешься выборки делать, и что за бизнес-кейсы, я понятия не имею, мне не до тебя, глупый ты юзер, иди, не мешай дяде разработчику».
Проверочный вопрос — попробуйте, перечислите 5 самых частых сложных фильтров, которыми юзеры пользуются чаще всего. Не можете? Это потому, что вам неинтересно, что именно пользователю нужно. Человеку, купившему дрель, не нужна дрель — ему нужны дырки. Человеку, пользующемуся фильтрами, не нужны фильтры — ему нужны интересные ему данные. Изучайте своих пользователей, узнавайте, понимайте сценарии, предоставляйте инструменты.
Как я считаю, пример с 1С вы приводите совершенно неверный. 1С — это конструктор для программиста; предполагается, что разработчик конфигурации запилит этот UI до состояния «ура, пользователю есть всё для его конкретной работы», а не «на тебе груду полей, фильтров и условий, и учебник булевой алгебры впридачу».
Описывается, как именно хорошо, и что именно предлагается сделать. Но для этого нужно посмотреть
Я смотрел, да. Реально полезный совет — это навигатор по связям, очень хорошая фича. Что не порадовало в нём — это другая терминология: в модели у вас сущности, а навигатор почему-то в терминах таблиц. Видимо, сами разработчики мыслят в терминах «сущность» = «плюс-минс таблица», что непременно им потом «аукнется» семантическими разрывами.
Ещё один хороший совет — история по сущностям. Остальные — на мой взгляд либо вредные, либо не относятся к self-service BI, а к рациональному дизайну интерфейсов.
Я думаю, мы бы могли интересно пообсуждать темы BI, если бы Вы захотели.
Например, интересная тема: Вы считаете, первый совет нужно выбросить, мне же он кажется самым полезным.
Почему он полезен — я пояснил, поясните, почему Вы считаете его лишним.
Но, конечно, будьте аккуратны в обсуждении:
По-моему в фильтрах я прямо привожу сценарий с документами. Поясняю причины, почему нужны такие фильтры. Если хотите пояснить свою точку зрения, попробуйте это сделать сами, не вкладывая от моего имени мысли, которых я не разделяю.
Например, интересная тема: Вы считаете, первый совет нужно выбросить, мне же он кажется самым полезным.
Почему он полезен — я пояснил, поясните, почему Вы считаете его лишним.
Но, конечно, будьте аккуратны в обсуждении:
… Вы по сути тут призываете дистанцироваться от реальных бизнес-сценариев и потребностей…
… Попробуйте, перечислите 5 самых частых сложных фильтров,… Не можете? Это потому…
По-моему в фильтрах я прямо привожу сценарий с документами. Поясняю причины, почему нужны такие фильтры. Если хотите пояснить свою точку зрения, попробуйте это сделать сами, не вкладывая от моего имени мысли, которых я не разделяю.
Поясняю причины, почему нужны такие фильтры
Это не причины, это выдуманное обоснование, почему следует делать так, как сделали вы. Это можно топ-менеджерам на демо крутить, там, нервы, показывать ролик про счастливого пользователя, собирающего себе подфильтровку на огромном экране, рядом радостные жена и дети.
Я ж не спорю, что вы умеете или нет разрабатывать сложные фильтры. Умеете, могёте. Знаете, как. Пацаны вообще ребята. Но только цель «сделать ему удобно» заменилась целью «сделать офигенный фильтр». Круто, и разработчиков есть чем занять, и ползователь вроде занят чем-то, но не то.
Я понимаю, лучше всего разработчики умеют… разрабатывать. К сожалению, каждому конкретному бизнес-пользователю нужно не это, ему фиолетово, умеете вы разрабатывать, или не умеете. Но вы это считаете гордостью, наличие кнопки со СЛОЖНЫМИ фильтрами. А это, напротив, замаскированный провал аналитической работы. Надеюсь, когда-нибудь поймёте.
P. S. В целом, мне кажется, вы слишком много мне советуете, что мне делать, а что нет; и второй раз мне пеняете, что я не смотрел ролик. Если беседу в этом стиле вы называете обсуждением, то я в таких обсуждениях не участвую. Мне непонятно, с какой целью вы занимаете защитную позицию. Вы хотите выслушать, кто что думает по этому поводу — вот. Напрасно пытаетесь переубедить.
Если вы хотите извлечь пользу, вам следует слушать, а не менторствовать в комментариях, иначе получается не обмен мнениями, а проповедование.
Перестаньте мешать человеку делать технологический штучки-дрючки. «Художник так видит», и нет ему дела до жалких смерт пользователей.
Еще мне очень понравилась ирония в конце ролика с картинкой «Apple app/Google app/Your app», автор даже не осознает что делает именно последний вариант.
Еще мне очень понравилась ирония в конце ролика с картинкой «Apple app/Google app/Your app», автор даже не осознает что делает именно последний вариант.
А какое Ваше мнение по поводу причин?
К сожалению моё объяснение вам ничего не даст. Оно будет довольно очевидным для некоторых присутствующих и полной ахинеей для вас.
Мой поинт в том что вы решаете технические задачи, вместо задач бизнеса. В задачах бизнеса нет таблиц, фильтров, и даже, свят свят, отчетов. Там есть некоторые сценарии и некоторый результат на выходе. Идеальным вариантом для пользователя была бы кнопка «сделать мою работу», конечно после этого пришлось бы работника сократить, так что там есть опциональная галочка «делать работу хорошо», которую он ответственно жмет каждый раз когда начальник приехал в плохом настроении(ведь это пока еще не отражается в системе). А ваша задача довести проект, до этой одной кнопки. При этом средства решения не имеют значения, если соблюдены требования. И пусть все будет на батниках, а пользовательский интерфейс на псевдо-ASCII-арте, пользователям(и стейкхолдерам) будет глубоко фиолетово. Но не дай бог вы пропустите хоть один кейс пользователя, то на вас полетят все шишки, и «мега» констукторами фильтров тут не обойтись.
Мой поинт в том что вы решаете технические задачи, вместо задач бизнеса. В задачах бизнеса нет таблиц, фильтров, и даже, свят свят, отчетов. Там есть некоторые сценарии и некоторый результат на выходе. Идеальным вариантом для пользователя была бы кнопка «сделать мою работу», конечно после этого пришлось бы работника сократить, так что там есть опциональная галочка «делать работу хорошо», которую он ответственно жмет каждый раз когда начальник приехал в плохом настроении(ведь это пока еще не отражается в системе). А ваша задача довести проект, до этой одной кнопки. При этом средства решения не имеют значения, если соблюдены требования. И пусть все будет на батниках, а пользовательский интерфейс на псевдо-ASCII-арте, пользователям(и стейкхолдерам) будет глубоко фиолетово. Но не дай бог вы пропустите хоть один кейс пользователя, то на вас полетят все шишки, и «мега» констукторами фильтров тут не обойтись.
И так, Вы написали «автор даже не осознает, что делает именно последний вариант». Видимо, имеется ввиду, что автор (я) не осознает причин, по которым захламляются учетные системы.
Я свою позицию по этому поводу написал. Судя по активности и рейтингу статьи, она была понятна большому количеству читателей. Попробуйте объяснить Вашу.
А то пока Ваша позиция звучит как «Я слишком умный для вас». Не кажется ли немного высокомерно? :)
Я свою позицию по этому поводу написал. Судя по активности и рейтингу статьи, она была понятна большому количеству читателей. Попробуйте объяснить Вашу.
А то пока Ваша позиция звучит как «Я слишком умный для вас». Не кажется ли немного высокомерно? :)
В прошлой теме обсуждалось то же само что и в этой. Что проектировать надо от требований бинеса, а не от гибкости используемых технологий.
В чем мой поинт я уже обозначил, с удовольствием приму аргументы почему я не прав. А вопросов «способностей» я не касался, все мы имеем разный опыт и в разном колчестве. Нет ничего плохого что кто то учится.
В чем мой поинт я уже обозначил, с удовольствием приму аргументы почему я не прав. А вопросов «способностей» я не касался, все мы имеем разный опыт и в разном колчестве. Нет ничего плохого что кто то учится.
Так вроде с тем, что нужно идти от бизнес-задач никто и не спорит. В статье по пункту 10 я написал, как именно этот подход порождает хаос. Непонятно, как этот подход противоречит теме как этой так и предыдущей статей.
Знаете секретные знания, не держите в себе :)
А то теперь позиция изменилась на «Бизнес-требования, что бы это не значило, решат все проблемы.»
Ну да. А еще красота спасет мир.
Попробуйте конкретней. Например, если Вы утверждаете, что бизнес-требованиям в статье было уделено мало места, то поясните, какой процесс формирования бизнес-требований не был учтен в статье?
Знаете секретные знания, не держите в себе :)
А то теперь позиция изменилась на «Бизнес-требования, что бы это не значило, решат все проблемы.»
Ну да. А еще красота спасет мир.
Попробуйте конкретней. Например, если Вы утверждаете, что бизнес-требованиям в статье было уделено мало места, то поясните, какой процесс формирования бизнес-требований не был учтен в статье?
Непонятно, как этот подход противоречит теме как этой так и предыдущей статей.
Как минимум тем, что не было сказано о сборе требований, их анализе и вообще о проектировании как таковом. В ролике говорится как недорого заткнуть «дыры» в сценариях работы плоьзователей, после того как этап анализа был пропущен или провален.
какой процесс формирования бизнес-требований не был учтен в статье?
Сбор, выявление, преобразование в логическую и физичечкую модель решения. Как с ними работать, как их собирать, какие есть варианты их удовлетворения. Были упомянуты технические решения некоторого круга задач из домена работы с абстрактными данными. Таблицы, отчеты, сущности, связи, итд. к бизнесу не относится. Почти ничего не было сказано про то, как проектировать бизнес софт( и соотвественно решить потребность в BI еще до того как у пользователей начнутся затруднения с выполнением своих задач).
Коллега, мы ведь говорим о пункте 10? Почему ЕРП системы захламляются? Вы предположили, что я не понимаю причин. Я дал ссылку на статью, где эти причины излагаю.
Вы написали, причину, которую я якобы не указал — это сбор бизнес-требований.
Однако большинство пунктов этой статьи посвящены сбору бизнес-требований. Я спросил, какой процесс не был учтен.
Вы пишете: сбор, выявление, преобразование в физическую модель.
ПРАВИЛЬНО ЛИ Я ПОНИМАЮ, ЧТО ЭТО НАЗВАНИЕ ПРОЦЕССОВ, КОТОРЫЕ Я НЕ УЧЕЛ В ПРИЧИНАХ?
В ПОЛОВИНА статьи посвящена сбору и выявлению требований. И вы все еще так и не сказали, как эти процессы влияют на захламление/очистку системы, кроме тех аспектов что я УЖЕ написал в статье.
Или я один из нас двоих слежу за нитью дискуссии? Если нет желания дискутировать, тогда стоило ли Вам ее продолжать?
Вы написали, причину, которую я якобы не указал — это сбор бизнес-требований.
Однако большинство пунктов этой статьи посвящены сбору бизнес-требований. Я спросил, какой процесс не был учтен.
Вы пишете: сбор, выявление, преобразование в физическую модель.
ПРАВИЛЬНО ЛИ Я ПОНИМАЮ, ЧТО ЭТО НАЗВАНИЕ ПРОЦЕССОВ, КОТОРЫЕ Я НЕ УЧЕЛ В ПРИЧИНАХ?
В ПОЛОВИНА статьи посвящена сбору и выявлению требований. И вы все еще так и не сказали, как эти процессы влияют на захламление/очистку системы, кроме тех аспектов что я УЖЕ написал в статье.
Или я один из нас двоих слежу за нитью дискуссии? Если нет желания дискутировать, тогда стоило ли Вам ее продолжать?
Однако большинство пунктов этой статьи посвящены сбору бизнес-требованийЭто не так, и вам на это указывают. Однако обозначим это ваше высказывание как [А].
В ПОЛОВИНА статьи посвящена сбору и выявлению требованийЭто не так. Обозначим эту вашу фразу как [Б].
кроме тех аспектов что я УЖЕ написал в статьеВы ничего не сказали про аспекты
Кроме того, чуть ниже вы писали мне вот что: «Короче«Нужно анализировать бизнес-требования». Как это относится к теме статьи — вы так и не пояснили» (пусть это будет [В]).
Непонятно, зачем тогда вы половину и даже большинство пунктов своей статьи, согласно вашим словам, соответственно, [Б] и [А], посвятили вопросам, которые, согласно вашему же высказыванию [В], непонятно как относятся к теме статьи?
Уважаемый braindamaged, специально для вас выписываю заголовки статьи:
Если вы решите статью прочесть, то увидите что и внутри статьи речь идет преимущественно о анализе требований разными людьми на проекте и совокупностью их решений.
1. В процессе покупки, ключевые решения принимают люди, которые не будут пользоваться софтом.
2. Во время внедрения ключевые решения принимают люди, которые не будут пользоваться софтом.
3. Информационные системы отражают бизнес-процесс компании, наложенный на универсальную болванку коробочной версии.
В: Почему бы заказчикам не покупать софт правильно, покупая 90% готового функционала?
В: А почему бы не объединять и не согласовывать требования?
Если вы решите статью прочесть, то увидите что и внутри статьи речь идет преимущественно о анализе требований разными людьми на проекте и совокупностью их решений.
Вдогонку. Видимо, Вы невнимательно читаете цепочку разговора. Мы с shai_hulud пытаемся обсудить причины захламления ЕРП систем, вскользь упомянутую в этом выступлении. Мои доводы о причинах захламления я указал в другой статье, ссылку на которую привел (о чем собственно и сказал в выступлении).
Внимательно перечитал ваш ответ, и понял, что ничего кроме обвинений он не содержал.
Бла-бла-бла. Сам так выступаю и рассказываю о «БОЛЬШОЙ КРАСНОЙ КНОПКЕ».
А вот в жизни приходится удобные таблицы и формы разрабатывать.
Вероятно, вы считаете своих оппонентов за идиотов?
Во-первых — касались Во вторых, учится то хорошо, что я и стараюсь делать. А вот не забыли ли Вы этот навык?
«Мой поинт в том что вы решаете технические задачи, вместо задач бизнеса. Идеальным вариантом для пользователя была бы кнопка «сделать мою работу»»
Бла-бла-бла. Сам так выступаю и рассказываю о «БОЛЬШОЙ КРАСНОЙ КНОПКЕ».
А вот в жизни приходится удобные таблицы и формы разрабатывать.
К сожалению моё объяснение вам ничего не даст.
Вероятно, вы считаете своих оппонентов за идиотов?
А вопросов «способностей» я не касался, все мы имеем разный опыт и в разном колчестве. Нет ничего плохого что кто то учится.
Во-первых — касались Во вторых, учится то хорошо, что я и стараюсь делать. А вот не забыли ли Вы этот навык?
Будьте корректны. То, что Вы не смотрели ролик, пенял лишь единожды, когда вы его еще видимо не посмотрели. Во второй раз предлагал и предлагаю обсуждение.
О своих пользователях я забочусь, обвинения беспочвенны, да и зачем они вообще?
Много советую не Вам а тем, кто пришел на форум, где я выступал. Да и нужно ли так нервничать из за советов? Выступление так построено, как 10 советов. Я же не принуждаю :)
Опять таки Вас не переубеждаю, а хочу выслушать и понять Ваши аргументы.
Я предложил тему обсуждения: «необходимость хороших таблиц для SelfService BI». Вы сказали, что выкинули бы данный совет. Я попросил аргументов (т.к. мои уже прозвучали).
Пока от меня идут предложения (и желание) обсуждать. От Вас — мелкие манипуляции, домыслы, обвинения. Давайте с этого места забудем об этом и переключимся на обсуждение.
И так: что в моих предположениях о таблицах Вам показалось лишним? Как бы Вы сами сформулировали главный первый совет?
О своих пользователях я забочусь, обвинения беспочвенны, да и зачем они вообще?
Много советую не Вам а тем, кто пришел на форум, где я выступал. Да и нужно ли так нервничать из за советов? Выступление так построено, как 10 советов. Я же не принуждаю :)
Опять таки Вас не переубеждаю, а хочу выслушать и понять Ваши аргументы.
Я предложил тему обсуждения: «необходимость хороших таблиц для SelfService BI». Вы сказали, что выкинули бы данный совет. Я попросил аргументов (т.к. мои уже прозвучали).
Пока от меня идут предложения (и желание) обсуждать. От Вас — мелкие манипуляции, домыслы, обвинения. Давайте с этого места забудем об этом и переключимся на обсуждение.
И так: что в моих предположениях о таблицах Вам показалось лишним? Как бы Вы сами сформулировали главный первый совет?
Да, давайте переключимся на обсуждение.
Вообще не хотел вас ни в чём обвинять и не обвинял. Если это где-то так прозвучало, что типа ваши слова — то не берите на своё счёт, это была такая фигура речи и форма высказывания, когда говорят от первого лица. Вы тоже, пожалуйста не приписывайте мне манипуляций и другого, я это точно не хотел бы проделывать.
Ну так вот.
Аргумент по поводу таблиц вот какой. Есть хорошая ценная максима «нужно дать пользователю ценные ему данные, а для этого следует снабдить его инструментом (в вашем случае — фильтрами)». Мне кажется, что в докладе акценты расставлены таким образом, что максима искажается, разворачивается и начинает звучать в обратную сторону: «нужно сделать пользователю фильтры, чтобы он мог выбирать ценные данные».
Чувствуете разницу?
Появляется чисто технический аспект «а что такое хорошие фильтры? а что такое хорошая таблица?». И разработчик отвечает так, как разработчик «это когда бесконечно гибко», «это когда ВСЁ настраивается», а пользователь задвигается на второй план. Я из опыта могу судить, это происходит потому, что разработчикам интересно «искать там, где светло, а не там где потеряли ключи» (ну, т.е. делать то, что они могут сделать, как им кажется, хорошо — сложные фильтры с овер 9000 полей и конструкций, а не то, что нужно пользователю в его повседневной работе).
Главный первый совет звучит так: изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик, или вообще без лишних кликов, по дефолту уже были бы все данные. Это лучший self-service, когда даже self service не требуется. Поверьте, это окупается. И наоброт, интерфейсы «your typical app» всячески и дальше подталкивают к такому же уродскому UX, и от него чертовски сложно избавиться, и очень дешёво клепать всё неудобнее и неудобнее
Вообще не хотел вас ни в чём обвинять и не обвинял. Если это где-то так прозвучало, что типа ваши слова — то не берите на своё счёт, это была такая фигура речи и форма высказывания, когда говорят от первого лица. Вы тоже, пожалуйста не приписывайте мне манипуляций и другого, я это точно не хотел бы проделывать.
Ну так вот.
Аргумент по поводу таблиц вот какой. Есть хорошая ценная максима «нужно дать пользователю ценные ему данные, а для этого следует снабдить его инструментом (в вашем случае — фильтрами)». Мне кажется, что в докладе акценты расставлены таким образом, что максима искажается, разворачивается и начинает звучать в обратную сторону: «нужно сделать пользователю фильтры, чтобы он мог выбирать ценные данные».
Чувствуете разницу?
Появляется чисто технический аспект «а что такое хорошие фильтры? а что такое хорошая таблица?». И разработчик отвечает так, как разработчик «это когда бесконечно гибко», «это когда ВСЁ настраивается», а пользователь задвигается на второй план. Я из опыта могу судить, это происходит потому, что разработчикам интересно «искать там, где светло, а не там где потеряли ключи» (ну, т.е. делать то, что они могут сделать, как им кажется, хорошо — сложные фильтры с овер 9000 полей и конструкций, а не то, что нужно пользователю в его повседневной работе).
Главный первый совет звучит так: изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик, или вообще без лишних кликов, по дефолту уже были бы все данные. Это лучший self-service, когда даже self service не требуется. Поверьте, это окупается. И наоброт, интерфейсы «your typical app» всячески и дальше подталкивают к такому же уродскому UX, и от него чертовски сложно избавиться, и очень дешёво клепать всё неудобнее и неудобнее
«нужно дать пользователю ценные ему данные»
Согласен.
изучите, какие сценарии нужны пользователю, сделайте так, чтобы 80% из них были доступны в 1 клик
Тоже согласен.
Вот результат того, что я исследовал:
У пользователей ERP систем есть т.н. «длинный хвост» разнообразных выборок данных.
Т.е. есть 20% наиболее частых выборок (и они используются в 80% случаев по частоте). Эти выборки формолизованны и доступ к ним обеспечен (через отчеты или интерфейс) в 1-2 клика.
Но в 20% случаев пользователь использует очень разнообразные выборки, которые ему вряд ли понадобятся, например, в течении этого месяца повторно.
При этом, если пользователей 100 человек, то каждый день 3-5-и из них будут требоваться те самые редкие выборки.
Это исследование я проводил в компании с 3-мя системами и примерно 100 пользователями.
Таким образом, то решение, что Вы предложили действительно необходимо делать (и его собственно все делают, в том числе мы ). Далее я решал уже проблему «длинного хвоста».
Мой ход мыслей, который привел к совету рекомендаций 3-х свойств таблиц.
1. Разнообразных запросов слишком много. Все их формализовывать и выдавать в интерфейс а) слишком дорого б)слишком захламит интерфейс редкими операциями.
2. Чтобы получить нужные данные пользователи обращаются в ИТ и это работает. Что хорошо. Но удлиняет цепочку получения данных, что плохо.
3. Анализ этого потока показывает, что в большинстве случаев очень похожий источник данных в системе есть. Но не хватает его некой обработки. Задачи от пользователя так и приходят: возьмите все договоры и отберите по условию <условие>.
4. Если будет преложен пользователю инструмент, который остается удобным без навыков программирования но снимает 20-40% таких запросов, то это — хорошо.
5. Далее я формализовал, какие инструменты для этого нужны: доступ ко всем данным, фильтры, выгрузка в популярный формат. Но так, чтобы не ухудшать жизнь остальным пользователям.
Таким образом, мой ход рассуждения не противоречит Вашему. И обозначенной Вами подмены понятий, как мне кажется, я не сделал.
Сперва — решаем основные сценарии. Потом работаем над длинным хвостом.
Если говорить только о фильтрах, то в выступлении так и сказал — сделайте удобными основные сценарии, но для этого «длинного хвоста» сделайте более продвинутую кнопку фильтров.
Согласны ли Вы с моим ходом мысли?
Возможно, полезный совет: если у вас есть статистика и данные, это очень, очень хорошо, их стоит показывать на слайде в соответствующем месте. Именно что с развесовкой (80%, 20%, 3 месяца)
Ход мысли думаю, что понял, не согласен категорически. Потому что к тому, что изложено, возникают вопросы:
Не надо идти у него на поводу — решение «дать конструктор» в случае OLTP очевидное и неправильное: пользователю нужно решить сиюминутные оперативные проблемы, и решение, которое он попросит, будет таким же ситуативным и уродливым.
Ход мысли думаю, что понял, не согласен категорически. Потому что к тому, что изложено, возникают вопросы:
Далее я решал уже проблему «длинного хвоста»Я так и сказал, вы решаете те проблемы, которые хотите, вместо тех, которые пользователю нужны. Он понятия не имеет про «длинные хвосты», это проблема вашего способа анализа и вашей области (разработка систем). Доклад имеет смысл «Как я решал проблемы своей системы, вызванные проблемогенерирующими решениями, принятыми мной же»
Все их формализовывать и выдавать в интерфейс а) слишком дорого б)слишком захламит интерфейс редкими операциями.Я и говорю — вы решаете сэкономить. Если слайд будет назван «как сэкономить на бизнес-анализе, и при этом закрыть Х% потребностей» — я вообще не буду спорить и полностью соглашусь с докладом.
Но в 20% случаев пользователь использует очень разнообразные выборкиВ третий раз напишу: выясните, _почему_ ему нужны эти разнообразные выборки. Потратьте уже эти деньги. Ваша система не даёт ему нужных данных, он крутится как может. Очевидно, бедный юзер уже готов сам придумать, какие запросы составить и в каком порядке выполнить, чтобы достать информацию, которая ему нужна, из явно недружелюбной системы.
Не надо идти у него на поводу — решение «дать конструктор» в случае OLTP очевидное и неправильное: пользователю нужно решить сиюминутные оперативные проблемы, и решение, которое он попросит, будет таким же ситуативным и уродливым.
в большинстве случаев очень похожий источник данных в системе есть. Но не хватает его некой обработки.Вы опять подменяете проблему видением её очевидного решения. В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения.
Если будет преложен пользователю инструмент, который остается удобным без навыков программирования но снимает 20-40% таких запросов, то это — хорошо.Не знаю. По-моему, нет. Вы опять решаете задачу «как заставить пользователя составлять запросы»
Далее я формализовал, какие инструменты для этого нужны: доступ ко всем данным, фильтры, выгрузка в популярный формат.Я заметил, да. Опять же обращу внимание — для чего «этого»? Для того, чтобы порешать проблемы, перечень которых вы перед собой достаточно волюнтаристски поставили. Это тоже пойнт моего возражения.
мой ход рассуждения не противоречит ВашемуКонечно, противоречит. Я утверждаю «не надо решать проблемы собственного решения, предложите решение без этих проблем». Но куда там, вы уже спешите «формализовал, какие инструменты для этого нужны» (решать, замечу, ваши проблемы).
Сперва — решаем основные сценарии. Потом работаем над длинным хвостом.Знаете, я достаточно много общаюсь с разработчиками, чтобы говорить, что это — слова для напускания тумана, не опрокидывающиеся ни во что материальное, и ни в какие обязательства, и уж тем более преимущества. Их без потери смысла может применить и электромонтёр, и тот, кто красит заборы.
но для этого «длинного хвоста» сделайте более продвинутую кнопку фильтров.Скажите, вы правда считаете, что если фильтры передвинуть в отдельное окно, открывающееся по кнопке, а не держать на основной форме, то это серьёзный вклад в улучшение UX? По мне — так не поменялось ни-че-го.
Хм. Я понимаю, Вашу логику но не совсем понимаю, как Вы предлагаете ее использовать для конкретных решений.
Вы пишите: " выясните, _почему_ ему нужны эти разнообразные выборки"
Ну ок, для нашей системы основные причины я знаю. Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.
Что вы дальше будете делать с этой информацией?
Вы пишите: «В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения».
Ну ок. Приходит к вам задача — «дайте перечень наших самых первых 10 клиентов». А затем: «отберите договора выше 10 млн. за прошлый год»
Ок. Какие бы Вы сделали шаги для того, чтобы решить задачу ускорения времени доступа вашего пользователя к этим данным?
Вы пишите: " выясните, _почему_ ему нужны эти разнообразные выборки"
Ну ок, для нашей системы основные причины я знаю. Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.
Что вы дальше будете делать с этой информацией?
Вы пишите: «В исходном домене нет проблемы «не хватает некоторой обработки уже существующей выборки», это ваш способ решения».
Ну ок. Приходит к вам задача — «дайте перечень наших самых первых 10 клиентов». А затем: «отберите договора выше 10 млн. за прошлый год»
Ок. Какие бы Вы сделали шаги для того, чтобы решить задачу ускорения времени доступа вашего пользователя к этим данным?
Звонят внешние клиенты, которые задают вопросы, на которые должен ответить менеджер.Это замечание означает, что у вас фактически есть скоуп пользователей за рамками фокус-группы при разработке. Т.е. вы обкатываете систему на одной группе, а по факту ею начинает пользоваться другая (те самые телефонные пользователи), нужды которых вы не исследовали. Просто для этой группы у вашей БИЗНЕС-системы выставлен такой специфический API, «телефонный».
Что вы дальше будете делать с этой информацией?Сделаю так, чтобы в моём процессе разработке существовал агент, представляющий интересы этой группы, оценю несколькими независимыми способами стоимость удовлетворения этих интересов различными вариантами решений и буду поступать в соответствии с полученными цифрами.
Ну ок. Приходит к вам задача —..Вы меня извините, но представителей бизнеса и по конкретным задачам я консультирую платно. Это принципиальная позиция по ряду причин. Если интересует — прошу в личные сообщения.
Замечу только, что отдельные требования в отрыве от общей системы требований и сути бизнес-процесса рассматривать бессмысленно, всё равно что просить нарисовать проект домика, а по готовности уточнить, что нужен был домик для слепого жирафа
О, кстати, сорри за оффтоп. Посмотрел, где Вы работаете. У Вас же работает отличный парень, Игорь Беспальчук. Был где-то на его выступлении о системном подходе. Мне очень понравилось то, как он стройно и последовательно излагает свои мысли.
Не обижайтесь, но мне кажется, этот навык был бы Вам полезен :)
Не обижайтесь, но мне кажется, этот навык был бы Вам полезен :)
Вы обещали переключиться на обсуждение, но всё пытаетесь давать советы, не касающиеся темы. Странно.
По поводу отличного парня: если он для вас авторитет, я мог бы показать письмо от него, где он хвалит меня за аккуратность подхода к анализу проблемы и постановке задачи, и последовательность изложения. Думаю, он не стал бы лгать или приукрашивать
По поводу отличного парня: если он для вас авторитет, я мог бы показать письмо от него, где он хвалит меня за аккуратность подхода к анализу проблемы и постановке задачи, и последовательность изложения. Думаю, он не стал бы лгать или приукрашивать
Советую посмотреть SugarCRM, там прекрасный мастер отчётов, который позволяет создавать отчёты по чём угодно. Внутри конечно жуть, но и писалось давно, сейчас с помощью нормальных ORM можно всё легко и изящно повторить.
Видал мастер отчетов и по-лучше :) Например, из того что видел, считаю, One Click report — наиболее легок для пользователя. А MSReporting наиболее функционален для разработчика (но вроде бы как позиционируется как мастер отчетов для пользователей в том числе).
Модуль в SugarCRM — не плох, но, мне кажется, и не так уж чтобы лидер.
Модуль в SugarCRM — не плох, но, мне кажется, и не так уж чтобы лидер.
UFO just landed and posted this here
1. Все ли колонки выдаем в таблицы?
Практически все. Исключаем небольшую часть если считаем, что они никогда не будут востребованы в таблицах или таблица и так слишком перегружена. Но такое случается редко. Например, большие текстовые поля с описанием.
2. Как храните состояние таблицы?
Менеджер колонок ExtJs был доработан. Точных причин не помню, надо бы Selmarilспросить. Его же можно поспрашивать о клиентской части. Признаюсь, вопрос про историю и ссылки не совсем понял.
Практически все. Исключаем небольшую часть если считаем, что они никогда не будут востребованы в таблицах или таблица и так слишком перегружена. Но такое случается редко. Например, большие текстовые поля с описанием.
2. Как храните состояние таблицы?
Менеджер колонок ExtJs был доработан. Точных причин не помню, надо бы Selmarilспросить. Его же можно поспрашивать о клиентской части. Признаюсь, вопрос про историю и ссылки не совсем понял.
Вопрос по поводу менеджера состояний. Как вы обходите проблему забывчивости пользователя, что-нибудь наменял, забыл. Позже открывает интерфейс и не может чего-то найти, смотрит документацию, там другая картина? Или таких вопросов не возникало?
Для решения этой проблемы мы ограничиваем то, что может менять пользователь. Например, не даем ему настраивать формы именно по этой причине.
Настройка колонок, или там, рабочего стола, таких вопросов вызывает. Но вообще да, каждый раз такой выбор — дилемма.
Кстати, есть типовое решение (плохое, но хороших мало :)) проблемы «переконфигурирования» — сброс системы в первоначальное состояние. Например, практикуется при сложной конфигурации настроек, когда пользователь может запутаться и перестать понимать, как все исправить.
Настройка колонок, или там, рабочего стола, таких вопросов вызывает. Но вообще да, каждый раз такой выбор — дилемма.
Кстати, есть типовое решение (плохое, но хороших мало :)) проблемы «переконфигурирования» — сброс системы в первоначальное состояние. Например, практикуется при сложной конфигурации настроек, когда пользователь может запутаться и перестать понимать, как все исправить.
UFO just landed and posted this here
Я бы добавил: Не делайте перенасыщенных интерфейсов, не пугайте пользователей 100 кнопками и десятками форм, связанных таблиц. Отображайте только то, что нужно. Дайте возможность получить то, чего нет в текущем интерфейсе.
Одно дело, когда пользователь пользуется с системой с запуска постепенно изучая нововведения, представьте придет новый сотрудник и увидит это. Даже нового разработчика такая система приведет в ужас, что уж говорить о клиентах.
Одно дело, когда пользователь пользуется с системой с запуска постепенно изучая нововведения, представьте придет новый сотрудник и увидит это. Даже нового разработчика такая система приведет в ужас, что уж говорить о клиентах.
Согласен. Совет под номером 10.
У вас в совете об этом очень поверхностно, хотелось акцентировать на этом внимание.
Взглянул продукт над которым вы работаете в надежде увидеть прорыв. Не вдаваясь глубоко в подробности (возможно продукт стоящий и его оценят по заслугам профи) обнаружил для себя непонятную систему со сложными наименованиями разделов типа «сущности», «настройки клонирования», связками таблиц… Если бы продукт писался для программиста, вопрос бы не возник. Не зная модели бизнес процессов, которые лежат в основе системы практически невозможно «въехать» в нее с разбегу, какие бы там небыли замечательные фильтры. В данном случае интерфейс не помог разобраться в системе, что могло бы стать «киллер-фичей».
Остался открытым вопрос по поводу агрегирующих сводных аналитических отчетов с группировками и сложными условиями фильтрации. По значению отфильтровать легко, очень хорошо что есть такой функционал, но его чаще всего не достаточно.
Увы, это проблема практически всех подобных систем — высокий порог входа для нового пользователя.
Организуются тренинги, курсы, пишутся тонны документации…
Порадовал salesforce в этом плане, но не могу сказать что там все интуитивно.
Взглянул продукт над которым вы работаете в надежде увидеть прорыв. Не вдаваясь глубоко в подробности (возможно продукт стоящий и его оценят по заслугам профи) обнаружил для себя непонятную систему со сложными наименованиями разделов типа «сущности», «настройки клонирования», связками таблиц… Если бы продукт писался для программиста, вопрос бы не возник. Не зная модели бизнес процессов, которые лежат в основе системы практически невозможно «въехать» в нее с разбегу, какие бы там небыли замечательные фильтры. В данном случае интерфейс не помог разобраться в системе, что могло бы стать «киллер-фичей».
Остался открытым вопрос по поводу агрегирующих сводных аналитических отчетов с группировками и сложными условиями фильтрации. По значению отфильтровать легко, очень хорошо что есть такой функционал, но его чаще всего не достаточно.
Увы, это проблема практически всех подобных систем — высокий порог входа для нового пользователя.
Организуются тренинги, курсы, пишутся тонны документации…
Порадовал salesforce в этом плане, но не могу сказать что там все интуитивно.
В целом — согласен. Правда для меня 1С — более образец чем движок Force.com
Во истину, нет пророков в отечестве своем :)
Идею же штатных отчетов со сложной аналитикой частично берет на себя OLAP ну или там его развитие вроде One Click Report. Но, все же я не видел ни разу, чтобы такие отчеты смогли переложить на пользователей и это работало.
Во истину, нет пророков в отечестве своем :)
Идею же штатных отчетов со сложной аналитикой частично берет на себя OLAP ну или там его развитие вроде One Click Report. Но, все же я не видел ни разу, чтобы такие отчеты смогли переложить на пользователей и это работало.
Sign up to leave a comment.
Как сделать такую ERP систему, чтобы пользователи не бегали в ИТ за отчетами