Подумайте о процессах наполнения сайта заранее

Дмитрий Сергеев, 29.01.2007 23:29

Кнопку можно переделать, источники потоньше настроить. Главная идея не в механизме добавления новостей на сайт, а в огромном значении тщательного изучения предметной области в начале проекта.

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

Кстати, здесь получилось, что процедуры -- это то же самое, что и пользовательские сценарии. На самом деле не это так.

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

А еще процедуры могут стать основой для написания должностных инструкций.

Дмитрий Сергеев, 31.01.2007 15:40

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

Но, боюсь, чаще всего процедуры по поддержке сайтов остаются за рамками основных и даже обеспечивающих процессов. В этом проблема. Такие процедуры нужно разрабатывать и находить им место, иначе с сайтом будет беда. Делать это лучше до начала создания сайта.

Sergey, 04.02.2007 20:13

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

Дмитрий Сергеев, 05.02.2007 19:54

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

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

Sergey, 06.02.2007 19:02

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

Дмитрий Сергеев, 13.02.2007 16:10

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

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

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

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

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

~xXx~, 15.02.2007 21:42

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

Дмитрий Сергеев, 15.02.2007 22:40

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

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

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

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

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

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

Mr. Mishin Oleg, 07.02.2007 08:43

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

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

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

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

Дмитрий Сергеев, 10.02.2007 18:12

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

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

Mr. Mishin Oleg, 12.02.2007 08:53

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

Денис Мальцев, 16.02.2007 13:57

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

Mr. X, 01.02.2007 03:48

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

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

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

Дмитрий Сергеев, 01.02.2007 11:46

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

~xXx~, 15.02.2007 21:48

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

Дмитрий Сергеев, 15.02.2007 22:46

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

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