Проектирование сайтов - Подумайте о процессах наполнения сайта заранее / site update procedure content manager - Comments

Вот уж совсем

Денис Мальцев — Fri, 16 Feb 2007 13:57:09 +0300

Вот уж совсем не про разработку сайтов. Из мини-мемуаров биржевого брокера: "Если я купил актив, а его цена пошла вниз, я не спешу его продавать, а покупаю ещё, тем самым уменьшая среднюю цену покупки. Брокеры называют это "усреднение". Говорят, что усреднение погубило больше евреев, чем Гитлер."

Здорово, когда

Дмитрий Сергеев — Thu, 15 Feb 2007 22:46:26 +0300

Здорово, когда в организации есть пресс-служба, да еще и с отделами. Такое может позволить себе только большая компания.

Для маленьких выбор человека, "ответственного за сайт", -- нередко проблема. Особенно если нанимать кого-то нецелесообразно.

Вот так

Дмитрий Сергеев — Thu, 15 Feb 2007 22:40:22 +0300

Вот так совпадение! Месяц назад я показывал одному знакомому, как организовать такую цепочку с помощью Interstage BPM. Именно с авторами-редакторами и именно c публикацией на сайт.

В редакторе шаблонов (web-based, сделан на Java и работает вполне сносно) нарисовали модель процесса с развилкой (блок decision). Если редактору приходит "плохой" материал, то он возвращается на доработку, если "хороший" -- на сайт.

А потом по шаблону запускаются экземпляры процессов. И люди, ответственные за свои блоки, получают задания и передают результаты по цепочке дальше.

В этой штуке есть разделение доступа, учет времени, прикрепление файлов, передаваемые настраиваемые пользовательские параметры процесса. Не знаю только, что с системой извещений.

Изюминка в том, что можно рисовать модели достаточно сложных процессов, а работать всё будет одинаково легко.

Жаль, Interstage BPM платная. Как-нибудь поищу бесплатные аналоги. Наверняка есть.

здесь все

~xXx~ — Thu, 15 Feb 2007 21:48:47 +0300

здесь все зависит от того, где в компании находится контентщик. если чисто в маркетинге, то наверное проблема. у нас единый департамент занимается и маркетингом/рекламой и общественными связями. соотв., управление контентом сайта относится к деятельности одного из отделов пресс-службы, который напрямую общается с маркетигом/рекламой + перевязан посредством нескольких приказов с продуктовыми управлениями, HR и департаментами региональной сети. таким образом вся инфа стекается в одну точку.

у меня в

~xXx~ — Thu, 15 Feb 2007 21:42:38 +0300

у меня в конторе часть сайтов работет на RBC Contents. там как раз наличествует и пресловутая "цепочка публикаций". грубо говоря, один пользователь CMS вносит статью, контент-редактор знакомится с ней и либо правит сам, либо отправляет назад на доработку, либо отправляет другому пользователю для перевода на английский, либо попросту размещает на сайте. все операции имеют оповещение определенных сотрудников, участвующих в подготовке материала. Соотв., у разных пользователей разные возможности по публикации материалов + материал перед окончательной публикацией виден в тестовом зеркале фронтального сайта.

Workflow-системы --

Дмитрий Сергеев — Tue, 13 Feb 2007 16:10:45 +0300

Workflow-системы -- это системы, с помощью которых организации определяют, исполняют, отслеживают, координируют потоки работ. Подобные системы эффективны при удаленной работе или в случаях, когда сотрудники работают «распределенных офисных средах».

Workflow-системы состоят из двух классов компонент: средства моделирования потоков работ и программное обеспечение, поддерживающее работу конечных пользователей в рамках определенных моделей бизнес-процессов.

Подробнее о workflow в Википедии.

Еще нашлась статья об отличиях моделирования бизнес-процессов от управления потоками работ. На том же сайте есть и другие серьезные статьи.

В университете нам показывали BPM-софт от Fujitsu. Он web-based. Там есть и компонента для моделирования процессов, и ПО для конечных исполнителей работ. Можно скачать trial-версию и разные презентации. Есть и документация.

Абсолютно

Mr. Mishin Oleg — Mon, 12 Feb 2007 08:53:54 +0300

Абсолютно согласен. Но я пришел в эту компанию только в конце третьего года разработок, и в мои обязанности входило заставить этот бред работать.
Между прочим, про эффект влипания: очень интересно наблюдать его когда играешь на бирже - сам пару раз попадался: купишь тикеты, а когда видишь что надо уже продавать при убыточном баллансе - продавать жалко =)

Мне Денис

Дмитрий Сергеев — Sat, 10 Feb 2007 18:12:40 +0300

Мне Денис Мальцев недавно рассказал про эффект "влипания". Ваш случай :)

По-моему три года разработки -- большой срок для любого ПО. Нельзя так затягивать.

Да, могу. Один

Mr. Mishin Oleg — Wed, 07 Feb 2007 08:43:57 +0300

Да, могу.
Один пример в реально большой организации. Название думаю не важно, а вот про использование:

Компания занимается... не важно чем, потому как я подписывал инструкцию о неразглашении =) Пример очень интересный, и как раз на заданную тему.
В данном примере была сделана ошибка на стадии проектирования, и разработчиками системы документооборота было принято решение на 100% интегрировать систему документооборота в один из веб-проектов. Решение основывалось на том, что в процессе работы в программе использовались те же самые данные, что и на сайте - это была на самом деле большая и сложная БД и большой и сложный сайт с посещаемостью около 7-8 тысяч ежедневно (на данный момент). Это решение было принято изходя из меньшей стоимости такой системы по отношению к двум разделенным системам. На основе этого решения спроектировали сайт, все инструмены внутренней системы, и приступили к реализации.
Запуск проекта занял у разработчиков 1 год. Стоимость была астрономической, даже из рассчета сложности. В результате получили систему, которую пришлось заставлять работать еще 1 год, и то очень многе не работает до сих пор (через 4 года). Получилось, что замахнувшись на разработку специфичной (а именно поэтому не стали использовать готовые варианты) системы документооборота, разработчики переоценили свои силы. Но Бог с ними, с разработчиками. Чеерз 3 года с ними разорвали договор и стали дорабатывать систему ствоими силами, кстати довольно успешно.
На самом деле есть более страшное последствие: через три года с даты подписания договора систему документооборота и сайт наконец запустили, но это уже была устаревшая система документооборота и очень устаревший сайт. Поменялись не только технологии сайтостроения - поменялись технологические процессы в самой компании.
В связи с этим встали проблемы доработки системы, причем доработки кординальные. Текущая совершенно не поддавалась модернизации по нескольким причинам:
1. Полная завязка между WorkFlow и сайтом.
2. Неграмотно спроектиованная БД.
3. Некомментированный неструктурированный код, в котором не только весь дизайн интегрирован в PHP, но еще и этот PHP написан ужасно неграмотно: один index.php состоял из 8000 строк, а некоторые скрипты доходили и до 15000 строк, абсолютно нет структуры, типизации переменных... - одним словом этот код надо было видеть.
4. Немодульное строение системы, то есть нельзя заменить устаревший модуль новым.

Доработка системы слишком усложнилась. На интеграцию новой от профессионального разоработчика (а-ля Microsoft, Bitrix - именитых систем с хорошими качественными работами) не пошло руководство, аргументируя свое решение фразой "Деньги ведь уже уплачены - заставьте эту систему работать". Доработка текущей системы хоть и шла, но шла медленно. Компаний теряла деньги не только на постоянной доработке, но и потому что устаревший сайт было очень сложно вывести не только в прибыль, но и на самоокупаемость.

В результате, был сделан вывод: сэкономив на разработчике, компания допустила ошибки в проектировании, о которых поначалу и не подозревала.

Меня

Sergey — Tue, 06 Feb 2007 19:02:30 +0300

Меня интересуют и возможности систем Workflow и реальные примеры (и удачные и не очень).
Расскажите, что знаете.
Заранее спасибо.

Вас интересует,

Дмитрий Сергеев — Mon, 05 Feb 2007 19:54:25 +0300

Вас интересует, что даст организации использование ПО, поддерживающего workflow? Или конкретные примеры успехов и неудач?

Я никогда с таким ПО не работал в реальных проектах, но подобные системы видел и пробовал, знаю на что они способны. В любом случае поделюсь тем, что знаю.

Вы можете

Sergey — Sun, 04 Feb 2007 20:13:50 +0300

Вы можете привести примеры использования workflow в организациях?

Боюсь,

Дмитрий Сергеев — Thu, 01 Feb 2007 11:46:11 +0300

Боюсь, должность контент-менеджера трудно назвать почетной. Не каждый журналист согласится заниматься таким делом.

Правильно

Mr. X — Thu, 01 Feb 2007 03:48:49 +0300

Правильно написал!

Причем неплохо бы если бы это работало с внутреннего корпоративного сайта.

Контент менеджер должен быть и немножко журналистом, потому что не все начальники могут нормально формулировать мысли.

Решение

Mr. Mishin Oleg — Wed, 31 Jan 2007 15:59:09 +0300

Решение проблемы сведения с кор.процессами - создание адекватных задачам систем управления данными, в том числе CMS и WorkFlow. Если пользователю сложно освоить работу с пользовательским интерфейсом - это не проблема этого пользователя, это проблема дизайнера пользовательских интерфейсов (читай - разработчика). Не даром одним из пунктов грамотного ТЗ является утверждение этих самых интерфейсов, вплоть до скриншотов еще на стадии проектирования.

Иначе, возможен вариант, когда ключевой человек будет неспособен работать с системой после ее запуска, а это может повлечь ступор всей системы.

Подумайте о процессах наполнения сайта заранее / site update procedure content manager

Дмитрий Сергеев — Mon, 29 Jan 2007 22:25:49 +0300

Постепенно прихожу к мысли, что проект сайта должен включать описание процедур поддержки. Если пораньше озадачиться разработкой набора типовых действий специалистов, обеспечивающих работу сайта, можно увидеть неочевидные стороны. Всплывет недостающая функциональность, а излишества отвалятся.

Например, посмотрим на контент-менеджера, этого человека со странно звучащей должностью. Помимо прочего он добавляет на сайт новости. Попробуем разобраться с процедурой «Сбор и добавление новостей».

Новости в этом примере будут двух сортов: внутренние и внешние.

О том, что происходит в компании, контент-менеджер узнает от начальников отделов. Из службы логистики присылают информацию об открытии нового склада в Одинцово, из отдела маркетинга -- о зимних скидках всем покупателям с длинными волосами.

Как же эти внутренние новости попадают в руки нашего героя? Вариантов немало: по email или ICQ, через FTP-сервер, в устной форме по телефону и при личных встречах.