“пользователь осуществляет операцию перехода на следующий раздел клиентского приложения путем двойного нажатия на левую кнопку манипулятора типа мышь”
В этом предложении явно чего-то нехватает. Совершенно же непонятно, о чем речь. Надо так: пользователь обладает возможнорстью осуществить операцию перехода на следующий раздел клиентского приложения путем последовательного выполнения двойного нажатия на левую кнопку манипулятора типа мышь
Прошу прощения, но чем Демо-версия, для получения доступа к которой необходимо заполнять форму, лучше той, для которой достаточно нажать кнопку? Это я к тому, что Verdox (необходимо что-то еще заполнять и оставлять свои данные) набрал максимум, хотя в то же время Optima Workflow и 1С Документооборот дают доступ только по нажатию кнопки без ввода каких-либо данных и при этом оценка ниже?
Оцнка — это моё субъективное впечатление от той или иной опции сайта. Касательно демо-версий — где-то я просто заполнил форму и сразу получил доступ. А где-то заполнил форму и получил доступ через неделю после нескольких переговоров. А где-то смог получить доступ сразу и без формы, по общему логину/паролю, но внутри такая мусорка, что невозможно разобраться и под одним пользователем одновременно 15 человек сидят…
Ну нет в небольших компаниях процессов, связывающих десятки подразделений по всей стране, с жесткими сроками реакции, изощренной системой безопасности и связей в реальном времени с множеством внешних сервисов.
Так ведь и поставщики СЭД/ECM давно уже вышли на рынок малого и среднего бизнеса с лёгкими и недорогими решениями.
Ну как можно объяснить скриншотами, что система принятия решения о выплате пенсии в НПФ и система принятия решения о выдаче потребительского кредита в банке практически ничем не отличаются по архитектуре и возможностям, хотя в каждой их них совершенно разные поля и действия сотрудников, и взаимодействуют они с совершенно различными внешними сервисами?
Ну обычно это делают так:
1. Платформа SuperSystem
1.1. Решение SuperSystem — Финансы и кредит
1.1.1 — Типовой кейс «Выдача потребительского кредита»
1.1.2 — …
1.2. Решение SuperSystem — НПФ
1.1.1 — Типовой кейс «Решение о выплате пенсии»
1.1.2 — …
Да, мне уже сказали, что по запросу они могут дать демо. Что до целой страницы — там только ролики, так что неправильно называть это демо. Хотя ролики очень хорошие — максимальную оценку за это им поставил.
Оценка СЭД по качеству маркетинга не совсем верный подход
Так я и не оценивал СЭД. Я оценивал именно маркетинг. Основаня мысль статьи — у вендоров СЭД устаревшая концепция позиционирования.
Сложность внедрения именно систем документооборота связана в первую очередь с необходимостью «дотачивать» любое внедряемое решение до требований заказчика.
Это не только в документообороте — это относится к любому корпоративному ПО. Однако это не повод закрываться от людей. Возможности адаптации также легко демонстрируются, как и типовой функционал. Надо только принять такой вектор
Поэтому на первый план при выборе СЭД выходят возможности ее кастомизации и настройки, доработки под конкретного заказчика и опыт внедренца, т.к. он позволяет переиспользовать наработки предыдущих внедрений этой системы.
Согласен. Причем решает компетенция именно внедренца а не вендора. Можно выбрать офигенное решение и таких бестолковых внедренцев, которые всё угробят.
Какого рынка? Рынка транснациональных корпораций? Мои друзья — это небольшая компания на 50 человек. Вы всерьез считаете, что для них надо было выбирать между EMC и IBM?
Я пользовался гуглом. Кто нагуглился — тот и участник рынка, ибо видно, что занимаются рекламой и продвижением.
Шарпоинт кстати представлен, одна из систем как раз на нём. А остальные… скажем так это как выбирать себе автомобиль, но Феррари и Ламбо сходу отмести.
Из разряда «переустанови плиз Винду, ты ж программист»
Типа того, да :)
p.s. у Directum'а точно есть демо-стенд (на прошлом месте работы его покупали), но там обратиться в тех. поддержку надо, чтобы дали доступ
Разумеется, если выйти на прямой контакт и попросить, то многие дадут, покажут и расскажут то, чего нет на виду. А если ты «завод», то приедут, установят, проведут демонстрацию и в кабак сводят.
Но цель моего исследования была — анализ того, что лежит в открытом доступе, попытка выяснить насколько вендоры открыты клиентам.
Почему нет? Если объем системы таков, что вы можете все сами проконтролировать + у вас есть ресурс по времени и деньгам, то зачем идти на компромисс? Вы платите — они делают. Какая вам разница, что происходит за кадром?
В комментах выше мы пришли к выводу, что проектировать надо с учетом квалификации исполнителя. Чем абстрактнее требования, тем больше у исполнителя возможностей сделать что-то «попроще» скажем так. Чрезмерная детализация снижает возможность такого манёвра.
Имеется в виду старый и проверенный трюк — найти особо сложное место, какое-то запутанное правило, например, и сделать вид, что вообще не вкурил как оно должно быть.
Просишь детализировать это требование, желательно с примерами и просчетом вариантов. Отображение времени в разных таймзонах, например. А пока заказчик это делает — срочно что-то допиливаешь. Так можно выиграть 1-2 дня :)
ИМО вам попался не самый квалифицированный разработчик
Ну квалификация любого разработчика имеет свои ограничения. Просто получилось так, что мы проектировали рассчитывая на супер-пупер-мега профи. А работать пришлось с обычными ребятами среднего уровня. А будь у нас требования не столь детализированы, они какие-то вещи опустили бы до своего уровня. Да, местами получилось бы не очень круто… но получилось бы :)
Лично я думаю, что проблема не в том, что разработчики хотят делать как знают, переосмысливать поведение тех или иных элементов — они просто вынуждены это делать, т.к. предметную область они не хотят учить, ни хотят в неё вникать.
И такой момент был. Часто меня пытались убедить сделать какие-то фичи по-другому. К счастью у меня были готовые сценарии, объясняющие почему спроектировано именно так. Мы же не от балды всё рисовали :) Так что это не было существенной проблемой.
Производительность труда пользователей может оказаться сильно ниже расчетной, переобучивать придется тех, кто в прошлом тысячелетии ещё под стол ходил.
Да верно, если пользователь работает в твоём приложении постоянно. Если же это какое-то вспомогательное ПО, то плохой UX выльется в потерю 5-10 минут рабочего времени в день. К тому же в корпоративе до сих пор много людей старшего возраста, которым такой интерфейс будет интуитивно понятнее.
Вот прямо сейчас моя практика показывает обратное :)
Это интересно. Я всегда считал, что такие случаи большая редкость. Впрочем наверняка у вас всё равно существенные трудозатраты уходят на разбор чужого кода, а местами и рефакторинг и пр. Следовательно для заказчика это дополнительные расходы. Следовательно определённый вендор-лок всё же имеет место. Нет?
А как еще может быть при аутсорсинге разработки? Всё творчество у проектировщика, а проектирование — сфера заказчика. Исполнитель может творить исключительно в рамках написания кода.
Тогда это не то. Вы говорите о праве исполнителя иметь своё мнение и пытаться убедить в нем заказчика. На мой взгляд — это само собой разумеется в любом проекте с адекватным заказчиком.
Под пространством для манёвра я полагаю возможность разработчика какие-то вещи делать по своему при том, что заказчик не будет иметь права требовать переделки даже если ему не понравится. В моём случае таким пространством были технологии разработки и правила написания кода. Но этого видимо мало.
В этом предложении явно чего-то нехватает. Совершенно же непонятно, о чем речь. Надо так: пользователь обладает возможнорстью осуществить операцию перехода на следующий раздел клиентского приложения путем последовательного выполнения двойного нажатия на левую кнопку манипулятора типа мышь
Оцнка — это моё субъективное впечатление от той или иной опции сайта. Касательно демо-версий — где-то я просто заполнил форму и сразу получил доступ. А где-то заполнил форму и получил доступ через неделю после нескольких переговоров. А где-то смог получить доступ сразу и без формы, по общему логину/паролю, но внутри такая мусорка, что невозможно разобраться и под одним пользователем одновременно 15 человек сидят…
Так ведь и поставщики СЭД/ECM давно уже вышли на рынок малого и среднего бизнеса с лёгкими и недорогими решениями.
Ну обычно это делают так:
1. Платформа SuperSystem
1.1. Решение SuperSystem — Финансы и кредит
1.1.1 — Типовой кейс «Выдача потребительского кредита»
1.1.2 — …
1.2. Решение SuperSystem — НПФ
1.1.1 — Типовой кейс «Решение о выплате пенсии»
1.1.2 — …
Так я и не оценивал СЭД. Я оценивал именно маркетинг. Основаня мысль статьи — у вендоров СЭД устаревшая концепция позиционирования.
Это не только в документообороте — это относится к любому корпоративному ПО. Однако это не повод закрываться от людей. Возможности адаптации также легко демонстрируются, как и типовой функционал. Надо только принять такой вектор
Согласен. Причем решает компетенция именно внедренца а не вендора. Можно выбрать офигенное решение и таких бестолковых внедренцев, которые всё угробят.
Какого рынка? Рынка транснациональных корпораций? Мои друзья — это небольшая компания на 50 человек. Вы всерьез считаете, что для них надо было выбирать между EMC и IBM?
Я пользовался гуглом. Кто нагуглился — тот и участник рынка, ибо видно, что занимаются рекламой и продвижением.
Шарпоинт кстати представлен, одна из систем как раз на нём. А остальные… скажем так это как выбирать себе автомобиль, но Феррари и Ламбо сходу отмести.
А ведь, насколько я понял, одна из лидирующих на рынке систем. Сотни внедрений, крупные проекты, заводы, газеты, пароходы…
Типа того, да :)
Разумеется, если выйти на прямой контакт и попросить, то многие дадут, покажут и расскажут то, чего нет на виду. А если ты «завод», то приедут, установят, проведут демонстрацию и в кабак сводят.
Но цель моего исследования была — анализ того, что лежит в открытом доступе, попытка выяснить насколько вендоры открыты клиентам.
В комментах выше мы пришли к выводу, что проектировать надо с учетом квалификации исполнителя. Чем абстрактнее требования, тем больше у исполнителя возможностей сделать что-то «попроще» скажем так. Чрезмерная детализация снижает возможность такого манёвра.
Просишь детализировать это требование, желательно с примерами и просчетом вариантов. Отображение времени в разных таймзонах, например. А пока заказчик это делает — срочно что-то допиливаешь. Так можно выиграть 1-2 дня :)
Ну квалификация любого разработчика имеет свои ограничения. Просто получилось так, что мы проектировали рассчитывая на супер-пупер-мега профи. А работать пришлось с обычными ребятами среднего уровня. А будь у нас требования не столь детализированы, они какие-то вещи опустили бы до своего уровня. Да, местами получилось бы не очень круто… но получилось бы :)
И такой момент был. Часто меня пытались убедить сделать какие-то фичи по-другому. К счастью у меня были готовые сценарии, объясняющие почему спроектировано именно так. Мы же не от балды всё рисовали :) Так что это не было существенной проблемой.
Да верно, если пользователь работает в твоём приложении постоянно. Если же это какое-то вспомогательное ПО, то плохой UX выльется в потерю 5-10 минут рабочего времени в день. К тому же в корпоративе до сих пор много людей старшего возраста, которым такой интерфейс будет интуитивно понятнее.
Это интересно. Я всегда считал, что такие случаи большая редкость. Впрочем наверняка у вас всё равно существенные трудозатраты уходят на разбор чужого кода, а местами и рефакторинг и пр. Следовательно для заказчика это дополнительные расходы. Следовательно определённый вендор-лок всё же имеет место. Нет?
Под пространством для манёвра я полагаю возможность разработчика какие-то вещи делать по своему при том, что заказчик не будет иметь права требовать переделки даже если ему не понравится. В моём случае таким пространством были технологии разработки и правила написания кода. Но этого видимо мало.
Угу. Только сначала надо что0то сделать со школами…