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

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



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

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

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

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

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

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