Система управления проектами. Пример реализации.

Продолжим…

Итак, что мы имеем. Есть проблема, варианты решения. Выбран продукт на базе которого планируется решать проблемы.  Дело за малым: настроить его под нас и начать использовать. Об этом и пойдет речь в этом посте.

Напомню, что в качестве системы планирования работы отдела и ведения технической документации мы выбрали redmine. На тот момент (а это уже более 6-7 месяцев назад) Redmine 0.8.7.stable (PostgreSQL). В настоящее время у нас стоит в задачах переход на версию 0.9, но поскольку пока нас все устраивает, то у этой задачи низкий приоритет 🙂

Поскольку redmine в первую очередь позиционируется приложение для управления проектами, то ключевым понятием является проект.

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

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

  • ИТ — проект первого уровня
    • Postgresql (СУБД);
    • Redmine;
    • АТС;
    • Антивирусная защита;
    • Базовые сетевые сервисы;
    • Видеонаблюдение;
    • Виртуализация;
    • Инфраструктура xxx.lc;
    • Инфраструктура xxx.lc;
    • Мониторинг Zabbix;
    • 1С;
    • Сайт xxx;
    • Сайт xxx;

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

Следующим элементом системы являются трекеры

Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учета ошибок (англ. Bug tracking tool), представшим каждая в отдельности один проект.

По сути, в Redmine трекеры представляют собой аналог подклассов класса «Задача» и являются основой для полиморфизма разного рода задач, позволяя определять для каждого их типа различные поля. Примерами трекеров являются «Улучшение», «Ошибка», «Документирование», «Поддержка»,

Сейчас мы используем 3 трекера:  Проблема, Пожелание, Поддержка.

Еще один элемент и пожалуй самый главный задачи

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

Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» — актуальные, а «закрыт», «отклонен» — нет).

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

Прокомментирую по статусам. Статусов у нас сейчас 4, а именно:

  • Открыт — задача актуальна, ответственный занимается её решением (я надеюсь 🙂 )
  • Закрыт — задача считается выполненной;
  • Отказ — до/во время или после выполнения задача потеря свою актуальность;
  • Обратная связь — ответственный за выполнение ожидает корректирующего воздействия от автора задачи;

Теперь, что касается схемы изменения статусов. Схема в системе полностью настраиваемая. Подробно это описывается тут. Мы не стали усложнять этим работу, тк все коллеги и все взрослые люди все всё понимают. Другими словами у нас полная демократия. Любой сотрудник (нашего отдела) может изменить любой статус на любой.  Скажем так — это не запрещается, но в 80% случаев задачи закрываю я, тк контролирую их выполнение и результат.

Отдельно стоит отметить такой удобный элемент в redmine как оперативный план (roadmap). Понятие, как я понимаю, появилось из agile методологии. Простыми словами это «подпроект» который имеет фиксированные сроки и любая задача может «прикрепляться» к нему. Очень удобно для формирования версий и оценки готовности текущего состояния дел по нему. Наверное, сумбурно. Проще посмотреть на самом сайте redmine тут. Сами авторы redmine используют оперативный план для формирования версий системы.

Wiki. Вики у каждого проекта свой. Ну тут все понятно. Синтаксис подробно описывается в документации.

Структура wiki головного проекта:

  • Справочная информация отдела;
  • Контакты;
  • Регламенты;
  • Технические задания;
  • ИТ стратегия/ИТ аудит;
  • Памятка сотрудника;
  • Инструкции и HowTo;
  • Различная информация.
Документы. В рамках проекта можно организовать хранилище файлов любых типов. Вот пример структуры хранилища для головного проекта:
  • Пользовательская документация (pdf файлы, инструкции к программам и тд)
  • Регламенты
  • Служебные записки, заявки, приказы
  • Внутренний документооборот отдела
  • Должностные инструкции ( а вдруг сотрудник забудет!?)
  • Договора (сканы договоров с поставщиками)

    Так, что еще… Связи между задачами есть, но, скажу честно, реализация крайне не user-френдли.

    Задачи могут быть взаимосвязаны: например, одна задача является подзадачей для другой или предшествовать ей. Эта информация может быть полезна в ходе планирования разработки программы, за ее хранение в Redmine отвечает отдельная сущность.

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

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

    Если Вам нужна программа для планирования работы отдела или личного планирования, то redmine — Ваш выбор! 🙂

    Если есть вопросы — прошу в комментарии. Нужна живая презентация — приходите в гости 🙂

    Система управления проектами. Пример реализации.: 3 комментария

    1. Я может и ошибаюсь (тогда простите), но мне кажется все вышеперечисленное в списке проектов не является проектами. Насколько я понял, речь идет о процессах и задачах поддержки. Так ли это?

    2. Поймите меня правильно. В силу определенных причин я не могу выкладывать здесь точное описание наших рабочих проектов. Хотя большинство проектов реализуемых нами не сильно отличаются по названиям. Поясню на примере:

      Проект: Мониторинг Zabbix;
      Развернутое наименование проекта: Внедрение системы мониторинга ИТ инфраструктуры предприятия на базе программного продукта Zabbix.

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

      PS
      Вообще… Проект понятие относительное..

      Прое́кт (от лат. projectus — брошенный вперед, выступающий, выдающийся вперёд, торчащий) — это уникальная (в отличие от операций) деятельность, имеющая начало и конец во времени, направленная на достижение заранее определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска. [1] wikipedia

    3. Ясно. Смутили названия. Просто «Мониторинг Zabbix» я расценивал как выполнение действия мониторинг чего-либо 🙂

    Добавить комментарий

    Ваш e-mail не будет опубликован. Обязательные поля помечены *