Некоторые мысли:
1) От каких бы факторов ни зависела конечная цена, думаю, что описать
его можно достаточно чётко и точно. Потребуется помощь аналитиков по
выяснению и составлению требований, моделированию процесса "as is".и
т.д.
2) Изучить предметную область: стандарты, существующие решения, плюсы
и минусы. Создать библиотеку паттернов, написать guidelines.
3) Обсуждать в гугл группе. Файлы выкладывать на сайт или создать гугл
проджект.
4) На сколько это возможно, пройти полный цикл UCD
Если интерес к этому или подобному проекту у сообщества будет, то я
готов связаться с представителями реального бизнеса и выяснить
существует ли потребность в таком решении. При положительном ответе и
интересе подключить их к общению. Если нет, то выберем другое
направление. Благо отраслей, где есть потребность в эргономических
решениях, а тем более выполненных специалистами на энтузиазме, много.
Подобный проект будет реальным вкладом сообщества в развитие юзабилити
и эргономики, привлечёт интерес к сообществу и дисциплине в целом.
Кому интересно принять участие в таком проекте (можно отозваться и
написать интересующую Вас активность)? Идеи, комментарии предложения?
Хостелы - http://ru.wikipedia.org/wiki/%D0%A5%D0%BE%D1%81%D1%82%D0%B5%D0%BB
Какие активности Вам интересны? Мы можем обменяться контактами?
Почему Вы решили, что я имел в виду абстрактную гостиницу? Предложение
как раз для реально существующих с привлечением заинтересованных в
решении представителей отрасли и владельцев этих самых гостиниц.
Спасибо, Таня.
Какие активности Вам интересны? Мы можем обменяться контактами?
В конфигурации системы вводилось количество и типы номеров (кол-во
туристов) например:
количество - 5
тип - апартаменты
человек - 2
возможность доп мест - 0 (или кол-во если возможно)
возможность подселения - да/нет
тип нумерации: 101 - 106
таким образом добавляя записи формировался "номерной фонд"
далее при оформлении брони на туриста (группу туристов),
варианты размещения подбирались в соответствии с запросами.
При условии что на каждый номер оформлялась отдельная бронь.
внешне в веб интерфейсе это выглядело как обычная сетка.
горизонтально - даты, вертикально номера комнат (с типом)
каждая бронь представлялась в виде блока высотой в одну комнату, и
длинной в N дней (начальная и конечная дата)
этот блок можно было перемещать мышкой только вертикально, т.е.
выбирать в какой номер поселить.
сетка вертикально делилась линией по текущему дню. Всё что вчера -
неподдавалось редактированию, в т.ч. и "обрывки блоков"
т.е. можно было переселить туристов передвигая не весь блок, а только
от сегодняшнего дня до конца заезда.
В последствии был придуман классный алгоритм, основанный на
мативатических матрицах, где сама матрица выполняла роль сетки
а блоки туристов - массивы, которые сортировались в порядке убывания
методом максимального заполнения пространства матрицы...
таким образом автоматически предлагался вариант расселения туристов
именно в определенный номер, для того, чтоб
% простоя номеров был минимальным (простой между выездом одних
туристов и заездом следующих)
т.е. было опеределенное кол-во номеров, каторое было основным номерным
фондом (сегодня выезд одних и сразу заезд следующих)
и был фонд номеров, которые заполнялись в последнюю очередь, при
условии заполнения всех остальных.
Это кстати снизило расходы на персонал, т.к. был выделен состав
уборщиц, которые постоянно были при деле, и отдельно были те, которых
вызывали по необходимости.
В общем избавились от непропорциональной нагрузки на персонал.
Извините если что непонятно описал - спрашивайте разъясню.
On 17 дек 2008, 16:17, Павел Коноплицкий <amaze...@gmail.com> wrote: