Notal System: справочники

В Notal System есть сущности "Задача", "Документ", "Пользователь", задачи организованы в бизнес-процесс, который описывается через "Состояния" и "Переходы". По сути, это основной конструктор, из которого все там строится. В этом наборе не хватает одной важной возможности - нет Справочников, к примеру - списка Контрагентов. Для того, чтобы реализовать эту возможность, рассмотрим их назначение и возможности использования.

Справочники, назначение
Справочники по сути это списки объектов, имеющих много реквизитов, эти объекты имеют какой-либо самостоятельный смысл (описывают объективную реальность (желательно чтобы её)), существуют достаточно продолжительное время в относительно неизменном виде и используются разными способами (это - прямое следствие их объективной реальности). К примеру, сущность "Пользователи" вполне удовлетворяет этому определению.
Другими примерами справочников (вполне тривиальными) являются:

• Контрагенты - юридические (как правило) лица, выступающие клиентами, поставщиками и т.п.
• Товары - если мы автоматизируем бизнес-процессы продажи, то логично иметь такой справочник. Переменным реквизитом (относительно часто меняющимся) тут будет цена.
• Скидки - тоже для торговли.
• Контакты - контактная информация по непосредственно людям (впрочем, и фирмам тоже - если нет индивидуализированных контактов). К одному контрагенту может относиться несколько контактов - хотя бы по его подразделениям.

Способы использования справочников
1. Хранение информации. Список контактов полезен сам по себе, особенно если в нем организован поиск и отбор по реквизитам. Считаем хранение долгополезной информации базовой функцией справочников.
2. В качестве реквизита других объектов. К примеру, у задачи/документа мы можем завести допреквизит Клиент типа "справочник.Контрагенты" и иметь под рукой нужную справочную информацию. Более интересное использование - поиск всех задач/документов, у которых одним из реквизитов (или определенным реквизитом) является данный элемент данного справочника.
3. Для формирования документов по шаблону. Сейчас мы умеем создавать документ на основе шаблона, передавая в него контекст архива и/или задачи. Если у документа уже будут заданы и заполнены реквизиты типа справочник (или у задачи), то возможности для заполнения текста документа значительно расширяются.

По сути, это основные способы использования справочников. Использование справочников для управления движением задачи (какие-либо переходы доступны в зависимости от значений каких-либо реквизитов задачи) пока не планируется - это слишком усложнит логику конфигурирования бизнес-процесса (хотя и даст интересные возможности).

Общая конструкция справочников
Надо иметь общий список справочников, из которого каждый справочник можно открыть в списке. Список одноуровневый. Из списка можно открыть элемент справочника для просмотра или редактирования.
Каждый справочник имеет свей id (число) и Наименование (к примеру, id=1 "Контрагенты"). Управление доступом осуществляется на уровне справочника в целом Т.е. если пользователь имеет доступ к справочнику "Контрагенты", то ко всем его элементам в равной степени. Управление доступом осуществляется по следующим параметрам:

• Просмотр справочника в списке (используется в т.ч. для заполнения реквизитов задачи или документа)
• Просмотр элемента со всеми его реквизитами
• Добавление нового элемента
• Редактирование элемента справочника (удаление не предусмотрено)

Справочник имеет свой набор реквизитов, которые могут иметь тип:

• Число
• Строка
• Дата
• Справочник определенного типа
• (возможно) Пользователь

Отображение в списке каждого реквизита может настраиваться (id виден всегда). Так же каждый реквизит может использоваться для отбора (числа и даты по интервалу значений; строки по "содержит", "не содержит", "начинается с", "не начинается с"; справочники по конкретному элементу) - это вполне заменит многоуровневость списков.
Сортировку предполагаем только по реквизитам типа строка, число, дата (в т.ч. по id и наименованию). Желательно иметь быстрый поиск по мере набора на клавиатуре (если несложно реализовать).
Для редактирования элементов и для просмотра применяется одна форма - самая простая, типа той, что мы используем для допреквизитов задачи. Позже можно задуматься над редактором форм.
Элемент справочника всегда имеет экранное представление в виде пары id+Наименование. Надо предусмотреть стандартные кнопки открытия списка для выбора элемента и открытия реквизита (выбранного элемента) на просмотр. Это должно быть сделано одинаково во всех местах, где справочник может использоваться как реквизит - в задачах, в документах и в справочниках (когда один справочник имеет реквизит типа другой справочник).

Стандартные отчеты по справочнику
1. Печатная форма списка. Должна учитывать установленные видимость реквизитов, сортировку и отбор.
2. Печатная форма элемента справочника. Очевидно.
3. Объекты со ссылками на данный элемент справочника. Выбираем элемент справочника и смотрим все задачи, все документы и все другие справочники, у которых данный элемент выбран в качестве какого-либо из реквизитов. Настройки данного отчета: выбор типа и ограничения объектов для поиска: к примеру, задачи данного бизнес-процесса, задачи в активных состояниях, только документы или документы данной категории. В частности, так можно посмотреть все подчиненные элементы данного элемента справочника - к примеру, все Контакты данного Контрагента.
4. Объекты с косвенными ссылками на данный элемент справочника. Примерно то же, что и предыдущий отчет, но сначала мы находим все элементы всех справочников, которые имеют данный элемент своим реквизитом, а потом строим предыдущий отчет уже по множеству найденных элементов. Это имеет смысл, если у нас есть конструкция типа "подчиненный справочник" - у справочника "Контакты" есть реквизит "Контрагент", то есть фактически мы имеем Контрагента и его Контакты (работников). К примеру, к Письмам (категория документов) у нас привязан только Контакт - нам интересно собрать всю переписку с данным Контрагентом. То есть по Контрагенту мы находим все его Контакты, а потом по этим Контактам - все документы.

Специальное использование справочников
Справочник Контактов надо использовать для отправки писем: создали документ с данным контактом и сразу отправили его по электронной почте по адресу, указанному в Контакте.
Можно рассмотреть возможность привязки элемента справочника к исполнителю и наоборот - привязку исполнителя к элементу справочника. То есть к пользователю мы можем привязать контакт и хранить там расширенную информацию о пользователе, а можем к контакту привязать пользователя, т.е. с этим контактом работает данный пользователь. Это требует додумывания.
Формирование и хранение выборок из справочников. Из справочника Контрагенты по определенным критериям выбрали возможных клиентов, разбили список на несколько частей и каждой части назначили исполнителя, который обзвонит этх потенциальных клиентов. Что это за объект - такая выборка и как с ней работать - требует додумывания.

Импорт/экспорт через XML
Требуется импорт справочников через XML - к примеру, выгрузкой из 1С. Критерии выгрузки - не важно. Проверка дубликатов при загрузке, причем дубликаты могут выявляться по реквизитам, не по id или Наименованию - к примеру, Контрагетов проверяем по ИНН.
Также желательно иметь экспорт справочников в XML.

Необходимые изменения, напрямую не связанные со справочниками
Поскольку одним из основных использований справочников является заполнение документов по шаблону, то надо сменить очередность действий при создании документа:

• нажимаем кнопку [создать новый]
• выбираем шаблон
• заполняем/редактируем описание документа
• заполняем реквизиты (допполя) документа
• и только теперь формируем документ по шаблону

Так же потребуется существенно расширить работу с передаваемым контекстом документов - нам уже надо будет брать отдельные поля из элементов справочников.
Удобно также при создании документа из задачи заполнять реквизиты (допполя) документа из реквизитов (допполей) задачи. Полезно уметь настраивать правила заполнения допполей в конфигураторе (из чего в задаче заполняем это поле документа).

Для начала: Контрагенты и Контакты
Поскольку описана слишком большая функциональность, для начала можно ограничиться двумя справочниками: Контрагентами и Контактами. Состав реквизитов будет уточнен отдельно. По ходу внедрения их будет реализован практически весь описанный функционал за исключением создания новых справочников и изменения набора реквизитов справочника.

Трекер Notal System: рассылка уведомлений (часть 2)

Интерфейс редактирования наборов критериев

Каждый набор критериев должен иметь уникальный номер (присваивается автоматически), для удобства каждый набор снабжаем именем. Наборы критериев должны быть видны в виде таблицы. Для редактирования наборов критериев должны быть кнопки:

• Создать новый
• Копировать (создать новый копированием)
• Редактировать
• Удалить

Редактирование набора критериев выполняется в отдельном окне.

Эту таблицу наборов критериев в конфигураторе разместить в бизнес-процессе отдельным пунктом (по аналогии с ролями).

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

Интерфейс редактирования одного набора критериев (специальное окно) должен включать в себя две части:

• Раздел критериев фильтрации комментария, состоящий, в свою очередь, из подразделов по типу комментария, по состоянию и по тегам (см. описание критериев).
• Раздел адресатов, тоже состоящий из двух подразделов - по ролям и по выделенным пользователям. Этот раздел отсутствует в интерфейсе пользователя - там адресатом является этот самый пользователь.

Отправка уведомлений по почте и через SMS - общие принципы

Это надстройка для системы, рассылать будем (или не будем) все те извещения, которые есть для пользователя в системе. Никакой дополнительной фильтрации не предусмотрено.

Пользователь сам устанавливает, будет ли он получать уведомления на почту и/или через SMS. Это потребует дополнения информации о пользователе следующими полями:

• Адрес электронной почты
• Мобильный телефон
• Флаг "Получать уведомления на почту"
• Флаг "Получать уведомления через SMS
• Префикс почтовых сообщений (см. ниже)

Все это надо разместить в интерфейсе пользователя с правом редактирования (по аналонии со сменой пароля).

Отправка уведомлений по почте

Письмо делается на основе внутреннего уведомления системы и содержит его текст полностью. Необходимые дополнения:

• Текст письма должен содержать ссылку на открытие задачи
• Заголовок письма начинается с префикса (см. след пункт) и содержит аббревиатуру бизнес-процесса и номер задачи
• Префикс письма нужен для возможности настройки пользователем сортировки входящих писем его почтового ящика. Поэтому пользователь может сам задать префикс для уведомлений. Если пользователем префикс не задан, используем "Notal System: ".
• Отправитель - ? Входящая почта все равно приниматься не будет - лучше чтобы не было возможности ее отправить.

Отправка уведомлений через SMS

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

В настоящий момент не реализуем и считаем, что вопрос требует додумывания.

Трекер Notal System: рассылка уведомлений (часть 1)

Постановка проблемы

Пользователям полезно оперативно получать информацию о происходящем с задачей, особенно если эта задача не у них на исполнении. К примеру:

• автору или владельцу задачи полезно узнать, что его задача отрицательно завершена
• исполнителю полезно узнать, что задача передана другому
• возможным исполнителям полезно узнать, что в накопителе (ждущем состоянии) появилась новая задача

Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.

События, которые могут являться основанием для уведомления

В настоящий момент считаем, что уведомления касаются только задач, т.е. все происходящее с документами из рассылки исключаем (при необходимости это будет описано в отдельном документе).

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

Содержание уведомлений и их хранение

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

Уведомления должны быть организованы как таблица базы данных, которая отображается разными способами: в пользовательском интерфейсе Notal System, как исходные данные для отправки почты или SMS. Для последних стоит завести соответствующие поля таблицы, в которых отмечать, что соответствующее сообщение отправлено.

Редактирование уведомлений не предусмотрено. Чистка истории уведомлений "ранее выбранной даты" может быть реализована в интерфейсе конфигуратора для пользователя с полными правами администратора.

Создание уведомлений: критерии отбора событий

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

Набор критериев создается для конкретного бизнес-процесса.

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

Первый критерий - тип комментария. Мы имеем комментарии трех типов:

• Движение
• Служебный
• Пользовательский

Выбираем один или несколько типов комментария.

Второй критерий - состояние. Мы можем указать конкретное состояние или определенный тип состояния:

• Активное
• Ждущее
• Финальное (без разделения)
• Финальное положительное
• Финальное отрицательное
• Любое состояние
• (Конкретное состояние)

Выбираем один вариант. При движении задачи тем самым мы можем отследить попадание задачи в определенное состояние (или состояние определенного типа), но не можем отследить уход задачи из данного состояния.

Третий критерий - теги задачи. Мы можем указать перечень тегов и способ их обработки "и"/"или". Если теги не выбраны, то критерий считается удовлетворенным.

К каждому комментарию применяются все имеющиеся наборы критериев - даже если удовлетворяет одному, то у другого набора могут быть другие адресаты.

Адресаты уведомлений

В каждом наборе критериев должен быть указан адресат или механизм создания адресатов. Имеем три варианта:

• Конкретный адресат
• По ролям
• По выделенным пользователям задачи

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

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

Третий вариант - указание выделенных пользователей задачи. К выделенным пользователям задачи относятся:

• Автор
• Владелец
• Основной исполнитель
• Текущий исполнитель
• Исполнитель до совершения движения - имеет смысл, если задача при движении меняет исполнителя.

Можно выбрать несколько пунктов или не выбирать ни одного.

Второй и третий вариант могут присутствовать одновременно. Эти варианты адресатов доступны при создании рассылки в интерфейсе конфигуратора. Права на создание/редактирование рассылки есть у администратора бизнес-процесса.

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

Адресат уведомления должен иметь право просмотра задачи. То есть по предыдущим критериям определяется набор пользователей, кому отправить уведомления, и этот набор прогоняется через фильтр прав на просмотр задачи - если пользователь не имеет права смотреть задачу, то ему и незачем получать уведомления о ней.

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

Заблокированные пользователи не могут получать уведомления - уведомления для них просто не должны создаваться.

Интерфейс просмотра уведомлений

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

• Бизнес-процесс
• Тип комментария
• Тип состояния

Уведомление должно являться ссылкой на открытие соответствующей задачи в новом окне (по аналогии с реестром задач).

Интерфейс редактирования наборов критериев

Для удобства каждый набор снабжаем именем, нумеруем все наборы по порядку. Наборы критериев должны быть видны в бизнес-процессе в виде таблицы (в интерфейсе конфигуратора ясно, где расположить в интерфейсе пользователя?).

(продолжение следует)

Notal System - наш трекер

Давно не писал сюда, возобновляю. За прошедший почти год трекер получил имя Notal System, получил свой сайт notalsystem.ru и свою wiki, где раполагается документация. На основе Notal System на нашем заводе автоматизированы три бизнес-процесса, один из них - маркетинговая подготовка производства (о ней как-нибудь напишу подробнее). Сейчас этот трекер внедряется в двух сторонних организациях - в общем, нормальная жизнь продукта. Какие плюсы:

• наглядное представление бизнес-процесса в виде диаграммы состояний - это понятно даже коммерсантам
• веб-интерфейс
• интеграция с офисными программами - Ms Office и Open Office
• наличие API, что позволяет интегрировать с любыми программами, способными отправлять и принимать веб-запросы (у нас на заводе интегрировано с 1С)
• удобно использовать для управления инцидентами - можно реализовать ITIL, к примеру

Некоторые недостатки (временные, разумеется):

• пока не сделано управление временем - у задачи нет срока исполнения. Это не мешает текущему управлению в том смысле, что можно посмотреть, сколько задача находится у исполнителя, не превышен ли норматив; а вот планировать на будущее пока неудобно
• во встроенном электронном архиве документы хранятся с историей версий, но пока не реализованы состояния документа - черновик/утвержден/отменен и т.п.

В общем, есть куда развиваться. Да, если вам интересно попробовать поработать с Notal System, то пишите мне на notal@nm.ru - сделаем вам свою базу, срок пробного использования два месяца.

Управление временем в трекере

1. Постановка проблемы

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

2. Что есть исполнение планового срока?

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

• у задачи планируется только одна контрольная точка на ее маршруте.
  
• попадание задачи в любое финальное состояние является наступлением запланированного события, если оно не наступило раньше (не отмечено в задаче как наступившее).

Но одних финальных состояний недостаточно для отслеживания сроков задачи. К примеру, в трекере модельной оснастки наступлением срока будет считаться еще и переход в состояние "Поставить на контроль в 1С", поскольку реально задача будет завершена только после акта разметки, т.е. когда по этой оснастке будет выпущена отливка. Но планируем мы только время изготовления, так что как факт наступления срока добавляем следующую возможность:

• первое попадание задачи в одно из выделенных состояний.

В задаче заводим реквизит факт наступления срока типа "дата", туда записываем эту дату. Кроме того, пишем служебный коммент, в котором отмечаем это событие.

Назначение события как факта исполнения делаем не для задачи, а для диаграммы. Т.е. мы не можем установить, что задача 1 считается исполненной при попадании в состояние 7, а задача 2 - при попадании в состояние 5; нет, правило устанавливается на уровне диаграммы: задача считается исполненной при попадании в любое из состояний 5, 6, 8. Реализовать это можно установкой флажка в состоянии.

3. Виды сроков

Срок типа "конкретная дата" не очень удобен - для отдаленных планов это слишком большая конкретика, удобнее планировать "в ноябре", "в 3 квартале" и т.п. Фактически задаче мы назначаем интервал времени. Поскольку задачи понимаются как нечто достаточно элементарное, то для крупных временных интервалов можно считать, что задача должна начаться и завершиться в этом периоде (требуется еще продумать этот момент).
Мы рассматриваем следующие календарные сроки:

• Дата
  
• Неделя (№ недели в году + год)
  
• Месяц (+ год)
  
• 1-4 неделя месяца (экзотика, но у нас используется в планировании производства)
  
• 1-3 декада месяца (у нас не используется и пока не делаем)

Кроме календарных сроков, т.е. имеющих жесткие привязки к календарю (дату начала и дату конца), удобно планировать по условным этапам или итерациям. Эти периоды не обязательно имеют даты начала/конца, но мы считаем, что они имеют определенную длительность - к примеру, по две недели. Тогда мы можем спланировать проект и оценить его трудоемкость и сроки в условных периодах, не зная еще даты запуска проекта (начальной даты первого периода). Этап/итерация это специальный объект со следующими свойствами:

• этапы рассматриваются сразу рядами: А1, А2 ... Аn. Относительно этапов в ряду считаем, что они идут один за другим и не пересекаются. Нам потребуется несколько рядов этапов для того, чтобы иметь возможность планировать независимые проекты.
  
• каждый этап имеет дату начала и дату конца (привязка к календарю), но они могут быть и на начальном этапе планирования будут пустыми. То есть мы создаем ряд этапов, раскидываем задачи проекта по этапам и потом устанавливаем конкретные даты этапам, причем не обязательно всем - можно только начальным, а более поздние пока без календарной привязки.
  
• для ряда этапов устанавливаем единую плановую длительность этапа - две недели, месяц - как выберем.

4. Назначение сроков задаче

Задаче могут быть назначены несколько сроков из разных рядов: к примеру, месяц Март и 12-я неделя года, этап А3 и этап В8. Из каждого ряда может быть назначен только один срок (что естественно, поскольку периоды в ряду не пересекаются). При назначении срока проверяем, не вступает ли он в конфликт с уже назначенными сроками: так при назначении срока "12-я неделя" мы должны проверить, что она пересекается со сроком "Март".
При назначении этапов А3 и В8 если у них указаны даты начала и конца, то проверяем, если не указаны - можем назначать.
По сути сроком задачи будет пересечение всех назначенных ей сроков, т.е. для задачи можно вычислить дату начала и дату конца. Эти даты не редактируются вручную, а пересчитываются при назначении срока задаче (в том числе при отцеплении задачи от ранее назначенного срока: был Март, сменили на Апрель или вообще убрали привязку к месяцу).
Дата начала не несет особого смысла - мы можем начать задачу и раньше, можем и позже. Важной является лишь дата конца и именно по ней мы будем определять, уложилось ли фактическое выполнение (см. п. 2) или нет.

5. Назначение срока этапу

Сроки этапов подчиняются следующим правилам:

• Этапы в ряду не пересекаются и идут по возрастанию
  
• При назначении дат начала и конца этапа необходимо учитывать уже назначенные сроки задач, входящих в эти этапы

Второе правило рассмотрим подробнее. При назначении дат начала и конца этапу они должны быть такими, чтобы ни у одной из входящих в этап задачи не возникло несовместимых сроков. Для этого по всем срокам всех задач этого этапа считаем C1 = max(ДатаНачала_k) и C2 = min(ДатаКонца_k). Условиями совместимости дат этапа с уже назначенными сроками будут:

ДатаНачалаЭтапа < C2
ДатаКонцаЭтапа > C1

6. Специальные операции с рядами этапов

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

• Расчет от более ранних этапов к более поздним - расчет от старта проекта
  
• Расчет от более поздних этапов к ранним - успеть к сроку
  
• Пересчет единичного этапа, предшествующий и следующий этапы считаем фиксированными

Для рядов этапов надо предусмотреть назначение дат исходя из начальной даты (начала первого этапа) и установленной длительности этапа в ряду. Это удобно, если запускаем новый проект и никакие сроки задачам еще не назначены. Если уже назначены какие-то другие сроки, то сначала надо проверить, не возникнет ли с ними конфликтов.
Также следует предусмотреть при изменении даты начала/конца этапа изменение дат соседних этапов в ряду: либо увеличение/сокращение длительности, либо сдвиг последующих этапов.

7. Взаимозависимость задач

Кроме описанных выше сроков полезно уметь учитывать взаимозависимость задач. К примеру, задача 56 требует того, что описано в задаче 48. Это не значит, что для начала задачи 56 требуется, чтобы была завершена задача 48 - часто достаточно выполнения только части ее. Поэтому рассматриваем эту зависимость как "начало-конец": задача 56 не может завершиться без того, чтобы началась задача 48. на языке сроков это означает следующее: в любом ряду этапов или календарных сроков (месяцев, недель), которые назначены обеим задачам, этап задачи 48 не может быть позже этапа задачи 56. Здесь мы неявно считаем, что задачи достаточно невелики и полностью укладываются в рассматриваемые этапы. Если рассматриваемые этапы достаточно велики (хотя бы неделя), то это вполне корректное предположение.
Соответственно, необходимо сделать следующие механизмы:

• Указание задаче списка предшествующих задач
  
• Построение дерева зависимых и зависящих задач
  
• Проверка корректности сроков зависимых задач относительно ряда календарных сроков или ряда этапов - т.е. проверяем, правильно ли раскиданы задачи по месяцам или по этапам

Управление правами в трекере

1 Общие положения
Управление правами осуществляется на основании ролей. В роли прописаны права на действия. Каждое право либо дано, либо нет.
Стоит сделать вектор (массив) объектов прав (то, на что устанавливаем права) и по этому образцу задавать права у ролей.
Права считаются независимыми друг от друга (т.е. при установке права не проверяется, есть или нет какие-то другие права).
Каждый пользователь может иметь несколько ролей. Права пользователя определяются объединением прав ролей, т.е. операцией .or. над векторами прав.
Каждое действие совершается, если у пользователя есть права хоть по одному основанию (особенности при движении, чтобы результат не вызвал противоречия с другими правами).

2 Инцидент (задача)
Права на инциденты устанавливаются в общих терминах, т.е. невозможно установить права на отдельный инцидент, права на него вычисляются по его свойствам (исполнитель, состояние и т.д.).
Для инцидента (за исключением права на создание) различаются права в разных есго отношениях с инцидентом:

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты
Часть действий (критически важные) сопровождаются служебными комментариями со стандартным текстом.

2.1 Создание инцидента
Да/нет

2.2 Просмотр инцидента

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.3 Передача инцидента

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.4 Комментирование

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.5 Редактирование текста инцидента

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты
Существенная особенность: редактирование текста инцидента не-Исполнителем возможно только в неактивном состоянии.

2.6 Изменение приоритета инцидента

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.7 Редактирование тегов инцидента
Назначение/удаление тегов у инцидента. Считаем теги, так же как и приоритет, не критичными для сохранения истории, поэтому не разделяем операции назначения и удаления тегов.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.8 Выбор рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи пуст} => {номер рамочной задачи непуст}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.9 Очистка рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи пуст}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.10 Изменение рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи непуст и не совпадает с начальным}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.11 Прицепление файла
Действие представляет собой добавление нового файла из ЭА.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.12 Отцепление файла

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

3 Состояние
Важное отличие прав на состояние от прав на инциденты состоит в том, что права на инциденты устанавливаются как по их свойствам, так и индивидуально.

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

все состояния

активные

ждущие

финальные

<по каждому состоянию индивидуально>

3.2 Быть исполнителем в состоянии
Показывает то, что данный исполнитель может быть исполнителем для инцидентов в данном состоянии.

активные

<по каждому состоянию индивидуально>

4 Переход
Право на переход означает, что данный пользователь имеет право сделать данный переход задачи. При этом не важно, имеет ли он право на конечное состояние этого перехода — для совершения перехода пользователь должен иметь право на просмотр инцидента (иначе он его просто не откроет), право на передачу инцидента (иначе ему просто не должна быть доступна кнопка движения инфцидента) и право на конкретный переход (к примеру, пользователь может выполнить задачу и передать на тестирование, но у него не будет права на смену исполнителя).
Желательно чтобы программа имела минимальный интеллект и вычисляла, может ли пользователь совершить хоть один переход (к примеру, у него права на переход без смены исполнителя, а в списке возможных исполнителей конечного состояния его нет).

4.1 Переход без доп.условий

все переходы

<по каждому переходу отдельно>

4.2 Переход в ситуации «я — Исполнитель»
Действие представляет собой ситуацию {задача в состоянии А, исполнитель Иванов} => {задача в состоянии Б (возможно Б=А), исполнитель Иванов}, т.е. некий переход вообще может быть недоступен, но доступен для пользователя, если он является текущим Исполнителем инцидента. При таком движении исполнитель не изменяется. Если данного пользователя нет в списке возможных исполнителей конечного состояния перехода, то такой переход не должен быть доступен вне зависимости от этого права.

все переходы

<по каждому переходу отдельно>

4.3 Переход в ситуации «я — Владелец»
Это возможность Владельцу дать права на движения его инцидентов.

все переходы

<по каждому переходу отдельно>

5 Прочие права
Прочие права должны описывать доступ к следующим объектам:

Реестр инцидентов

Отчеты (когда они будут написаны)

Создание/изменение текста тегов

...и т.д.
Доступ к файлам управляется на уровне прав электронного архива.
Все это будет описано в отдельном документе.

ER-диаграмма трекера (основные таблицы)

Это диаграмма "сущность-связь" нашего трекера. Разумеется, это логическая схема, к тому же на ней нет ничего, связанного с управлением доступом. Трекер пишется с таким расчетом, чтобы можно было под каждый бизнес-процесс заводить свой экземпляр трекера со своей диаграммой состояний. Для управления задачами IT-отдела - один экземпляр, для служебных записок отдела главного металлурга - другой, для заявок от клиентов (та основная задача, ради чего все затевается) - третий. Разумеется, пользователь должен входить в систему один раз и там быть сразу авторизован во всех системах, в которых зарегистрирован. Поэтому мы вынесли систему авторизации вовне.



В общем, с конца октября трекер у нас работает для управления задачами отдела IT, уже более-менее нормально. Чего не сделано из того, что есть на первой ER-диаграмме:

1. Механизм влияющих инцидентов. Управлять задачами, четко указывая, что "задача1 должна быть сделана раньше задачи2" - почти никогда такого нет; скорее "нельзя начинать делать задачу2, не начав делать задачу1" - почти наверняка эта самая зависимость касается только части задачи1, можно ее начать, сделать только то, что необходимо для задачи2, и сначала завершить задачу2, не завершая задачу1. То есть связь не типа "конец-начало", а более гибкая. Расставив зависимости, мы можем посмотреть, какие задачи надо взять в работу, чтобы можно было выполнить эту, нужную. Пока не сделано.

2. Подчиненные инциденты. Иногда одна задача дробится на несколько: к примеру, в заявке заказчика есть несколько деталей, сначала заявка рассматривается коммерческим директором и директором по производству целиком (они имеют право решить, что она нам не интересна), а потом доходит до отдела главного металлурга, где по деталям раздается нескольким технологам, дальше все движение идет по этим подзадачам. И в самом конце эти подзадачи опять собираются вместе и заказчику высылается протокол согласования цены по его заявке. Вот этот механизм - шла одна задача, потом разделилась, а потом снова собралась - пока не реализован. Идея такая: когда задача разделяется, то старая задача замирает без движения в некотором состоянии, и не может двинуться, пока все ее подчиненные задачи не придут в финальные состояния. При этом финальные состояния могут быть как положительными (технология оценена, есть калькуляция на деталь), так и отрицательными (данную деталь мы не можем произвести). Для этого предназначена ссылка "рамочный инцидент", но основная работа - в реализации логики движения. Пока не сделано.

3. Основной исполнитель. Для задач отдела IT ясно, что основное состояние - "в работе". Исполнитель в этом состоянии - тот, кто на самом деле и выполнил эту задачу. Для движения заявок - ясно, что это технолог (при этом менеджер коммерческого отдела, притащивший эту заявку, уже виден как автор задачи). В общем, ловить этого исполнителя и потом анализировать по нему статистику - полезно, но не слишком критично. Пока не сделано.

4. Прикрепленные файлы. Если к трекеру присобачить еще систему управления версиями (электронный архив), то получится хороший инструмент для автоматизации документооборота. Если все файлы хранятся в едином архиве, то в разных экземплярах трекера для разных бизнес-процессов рисуем свои диаграммы состояний - и вот оно, счастье! Это не только не сделано, это я только проектирую. Скорее всего, следующий пост будет об этом.

Диаграмма состояний трекера отдела IT

Для управления задачами отдела IT решили использовать такую диаграмму состояний:



При создании новая задача (инцидент) находится в виртуальном стартовом состоянии № 0 и должна быть переведена в какое-то нормальное состояние. Диаграмма по сути распадается на две - программистские задачи и прочие задачи. Нас в основном интересуют программистские задачи, но и прочие тоже важны - провести сеть в цех, к примеру, или выполнить тестирование базы 1С. Пусть для них будут свои состояния, но чтобы мы могли учитывать все задачи.
Программистские задачи. Бледно-желтые состояния это состояния ожидания, накопители. В них у задачи не может быть исполнителя. Руководитель проекта (разделение по проектам мы потом реализуем с помощью тегов) выдает задачи в работу конкретным исполнителям, задача переходит в активное состояние (ярко-зеленое). Нормальный путь - сделанная программистом задача передается на тестирование. Если все нормально, то с тестирования она переходит в финальное состояние "Выполнено". Финальные состояния различаются двух видов: положительные исходы (темно-зеленые) и отрицательные исходы (бордовые). Финальное состояние не имеет исполнителя и не может иметь исходящих стрелок.
На диаграмме изображены все возможные переходы между состояниями задачи (инцидента). К примеру, с тестирования задача может быть возвращена на доработку - сама диаграмма показывает, что признать задачу выполненной может только тот, кто проводил тестирование, не программист (теоретически; на практике эти роли могут совмещаться в одном человеке, но только потому, что нас мало). Жирной стрелкой показан переход, который предлагается по умолчанию. Т.е. из каждого нефинального состояния должна исходить ровно одна жирная стрелка.
В трекере не предусмотрено удаление задач; все переходы регистрируются в истории инцидента с указанием пользователя, который совершил это действие. Для единообразия смена исполнителя реализована как переход с совпадающими начальным и конечным состояниями. Добавление примечания регистрируется тоже как переход.

Исполнителей (программистов, тестеров) должны интересовать активные состояния (ярко-зеленые), а руководитель проекта в основном занят управлением инцидентами в пассивных состояниях - что передать в работу и когда это сделать. Отдельный вопрос - состояние № 9 "Help me!". Оно используется, если программист столкнулся с концептуальной проблемой, решение которой влияет на архитектуру системы. Тут важно, чтобы исполнитель распознал, что проблема не его уровня; выделение же таких проблем в отдельное состояние гарантирует, что руководитель проекта вовремя узнает о них.

Вот, вкратце, описание трекера. Он реализован в web-интерфейсе, работает в Опере и Мозилле.

Трекер - общая идея

Решили тут написать свой трекер в web-интерфейсе. С чего это вдруг:
1. Есть куча задач, которые можно решить на одной методологической основе - через управление инцидентами с использованием диаграмм состояний. Эти задачи (не все):
- задачи отдела IT (как создание нового функционала, так и поддержка существующего
- маркетинговая подготовка производства (управление заявками клиентов)
- управление ремонтами и доработкой модельной оснастки - фактически документооборот служебных записок ОГМет и цеха.
В общем, там, где приминимо понятие инцидента - спорадически возникающего объекта (события), разбираться с которым необходимо индивидуально (т.е. даже схожие не суммируются и не объединяются в группы/партии), к тому же маршрут инцидента не определен однозначно (возможны движения между разными исполнителыми, в том числе по циклу). Хочется иметь инструмент управления инцидентами, который можно настраивать для разных задач.
2. Но вроде бы много есть таких инструментов? При внимательном анализе - нет; в различных багтрекерах система состояний в основном прошита в архитектуре и не является настраиваемой (легко настраиваемой). Впрочем, есть и системы с настраиваемой диаграммой состояний - TrackStudio, к примеру, куда более навороченная, чем то, что мы в состоянии написать. По уму надо было бы на чем-то таком делать. Но тут мне самому интересно спроектировать такую систему, да и по ходу продумать требования к ней. Лучше бизнес-процессы выращивать, чем пересаживать - для второго нужно куда больше опыта. Так что напишем свой трекер (уже задачи отдела IT ведем в нем), а уж следующие проекты можно будет делать в чем-нибудь более мощном - как методология станет более знакомой и понятной.

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