Redmine для управления ИТ: практический опыт обширного внедрения opensource-системы

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

Что значит хаос в наших системах? Это значит, что от пользователей поступают неупорядоченные, не подлежащие аналитике и структурированию запросы, и отсутствует проектное управление, как таковое. Запросы зависают где-то в почте, в Word, в голове у аналитиков, программистов, руководителей отделов – в зависимости от того, какая структура используется в организации.

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

 

 

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

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

• Во-первых, нам нужна была система отслеживания ошибок, инцидентов и поступающих запросов, т.е. нам надо было автоматизировать Bug Tracker;
• Во-вторых, мы хотели в какой-то мере выделить управление проектами. Не с полной отслеживаемой автоматизацией, которая подразумевает под собой применение методологий, а в той мере, как это необходимо было сделать на том этапе развития и с неким заделом на будущее. Далее вы увидите, каким образом мы используем для этого Redmine, и куда мы собираемся его развивать дальше;
• В-третьих, мы выделили блок управления ИТ-услугами (ITSM) в отдельную систему, правда, тоже не в полном объеме. Наш отдел предоставляет разные ИТ-услуги, которыми также необходимо управлять.

Дополнительно мы выделили наши частные проблемы:

• Это, повторюсь, разноплановые ИТ-службы, потому что программисты живут своей жизнью, системные администраторы своей, есть еще отдел интернет-маркетинга и другие;
• У каждого своя структура и свои пожелания по управлению отделом. Во всех отделах разные методологии, подходы, руководители и психотипы – это накладывает свой отпечаток на выбор системы. Но двигаться надо всем одновременно, причем, достигая одной цели – определенного порядка в организации, доступности информации и прогнозируемости;
• Кроме этого есть еще KPI, который у всех рассчитывается по разным показателям;
• Чтобы развиваться дальше, нам нужен дополнительный анализ поступающей информации, того, что происходит в отделах и как это отражается на организации в целом;
• Мы должны контролировать внутренние бюджеты, в рамки которых мы входим или, чаще всего, не входим. Их тоже надо как-то анализировать и ими управлять. Лучше все это делать в единой системе – в частности, это удобно для руководства.

 

 

Таким образом, мы выделили три системы, которые хотелось бы объединить в одну.

 

 

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

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

 

 

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

 

 

В результате анализа и выбора, а также с подачи Алексея Лустина, к нам пришел продукт Redmine, покрывающий собой определенную область. Давайте выясним, какую область он покрывает?

Он полностью покрывает Bug Tracker, который мы хотели запустить в компании. Это централизация поступления заявок от пользователей и заказчиков любого уровня. Это была самая основная болевая точка, которую необходимо было быстро автоматизировать. Я думаю, что эта проблема есть у всех, потому что, как я уже говорила, информация поступает неупорядоченно и оседает в разных местах – в почте, в Word, в Excel или в головах. Такая информация не подлежит анализу и получению выводов и итогов. В результате получается, что:

• • Информационная составляющая базы знаний, которую можно проанализировать и понять, что делать дальше, отсутствует. Это замедляет скорость реакции и влияет на бесперебойность и качество работы, от которых напрямую зависит прибыль;
  • Увеличивается время «погружения» новых сотрудников в работу с корпоративными системами;
  • Отказоустойчивость также у каждого своя – кто-то без работающей системы не может прожить и двух минут. Поэтому Bug Tracker играет большую роль, и на тот момент проблематика встала очень остро.

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

И покрывается совсем небольшой блок ITSM. Система Redmine не предназначается для управления ИТ-услугами, поэтому там есть некоторые огрехи в ведении и структурировании данных. Мы вышли и из этой ситуации, выбрав свой вариант системы для ITSM.

Итак, наш выбор – это Redmine. Он довольно кастомизируемый, масштабируемый, гибкий и с удобными настройками.

 

Почему Redmine?

• Это сладкое слово «халява». Redmine бесплатен, правда, с оговоркой, что к нему есть платные плагины, которые вы сами для себя выбираете. В любом случае у вас появляется какое-то прогнозирование затрат, потому что если вы купили плагин и не меняете платформу Redmine, то какое-то время этим плагином можно пользоваться без дополнительных вложений. А если вам, например, нужно его обновить, то вы платите за это обновление и используете его дальше. Обновление платформы Redmine происходит раз или два в год, а обновляться или нет – это уже по вашему желанию.
• У Redmine интуитивно понятный интерфейс. Мы у себя внедрили Redmine не только как продукт для управления ИТ, но и как продукт, куда поступают заявки от пользователей для различных отделов. Например, выделена отдельная ветка для заявок административно-хозяйственного отдела.
• Есть возможность управления приоритетами в различных аналитических формах, в том числе и индивидуально по задачам.
• Управление временем и ресурсами. Я думаю, что это – основной блок для руководителя. Он позволяет понимать, насколько загружен его отдел, с какими задачами какие затраты связаны и как можно классифицировать затраты, но об этом ниже.
• Аналитика и отчеты в Redmine выражены слабо, но есть обширный API. Можно взять данные из базы по API, выгрузить их в свою систему и получить любые отчеты.
• Гибкие настройки, кастомизация и автоматизация ручных операций с помощью плагинов.
• Интеграция с Git – это один из важных показателей. Хранилище нашей базы подключено к GitLab, и в любой задаче Redmine можно посмотреть логи (связанные редакции): кто, когда и что изменил по этой задаче, с переходом в GitLab.

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

Вот так выглядит список связанных редакций:

 

• Управление задачами и отслеживанием ошибок. Это стандартный Bug Tracker, который мы будем использовать.
• Управление инцидентами, проектами, бюджетами. У всех формирование бюджетов осуществляется по-своему. Я покажу, как мы автоматизировали это у себя, а вы можете потом попробовать автоматизировать управление бюджетом у себя – я думаю, это будет несложно, потому что трудозатраты в Redmine есть, и на деньги их переложить тоже можно.
• Wiki в Redmine реализована не очень удачно, поэтому для цели создания базы знаний и совместной работы лучше использовать другой продукт. Для себя мы выбрали систему Confluence от компании Atlassian, которая является одной из самых распространенных и удобных в работе. Также можно рассмотреть системы: DokuWiki, MediaWiki и другие.

 

Что же у Redmine под капотом?

• Redmine очень быстро и просто разворачивается.
• Он работает на большинстве ОС.
• Платформа, на которой он реализован – это Ruby on Rails. Если вы хотите кастомизировать Redmine под себя, нужно иметь компетенцию по Ruby on Rails, иначе будет не очень удобно, т.к. не все можно сделать готовыми плагинами.
• Поддержка различных СУБД говорит сама за себя.
• С помощью RSS или e-mail можно организовать оповещения по любым событиям.
• Доступна аутентификация по AD.
• Интеграция с системами управления версиями SCM (SVN, CVS, Git, Mercurial, Bazaar и Darcs).

 

Знакомство с Redmine

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

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

• https://www.redmine.org/projects/redmine/wiki/RusRedmineInstall

 

Так выглядит список задач в Redmine.

Есть стандартный и несколько дополнительных интерфейсов. Правда, при смене интерфейсов некоторые функции могут перестать работать, т.к. кастомные интерфейсы не учитывают плагины, с которыми вы будете работать – все-таки это продукт Open Source. Но это не мешает ему быть удобным инструментом даже с использованием стандартного интерфейса.

 

 

Администрирование выделено в отдельную и довольно понятную структуру.

 

 

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

У нас не «чистый» Redmine, т.к. установлено около 35-ти плагинов. Несколько из них мы покупали.

Информацию по плагинам можно найти в поисковике по ключевым словам «плагины для Redmine». Для примера есть два сайта, на которых можно скачать или приобрести хорошие плагины для начала работы с Redmine:

• Первый – www.rmplus.pro;
• Второй – www.redmineup.com.

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

 

Немного об автоматизации наших потребностей

Структура «Проектов»

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

Примерно так выглядят части дерева:

 

 

В отделе системного администрирования также используется свой подход иерархии «Проектов». Работа выстроена на основе классификации предоставляемых сервисов – это помогло решить проблему с сервисным управлением. Поэтому в ветке ITSM иерархия «Проектов» – это каталог бизнес-сервисов. Для удобства они пронумерованы.

 

Поступление заявок в Redmine

На примере расскажу, как мы организовали поступление заявок в Redmine.

Наш отдел КИС делится на 3 группы:

• Группа разработки;
• Группа аналитики и сопровождения – сюда входят сотрудники, которые производят уровень поддержки «два с половиной». Они консультируют, анализируют проблему, в случае необходимости «читают» код, могут написать запросы для анализа данных, а также исправить ошибки в коде. В итоге нам удается исключить отвлечение программистов от мелких проблем, а также с помощью аналитиков мы отделяем программистов от заказчиков и обратно, т.к. все, наверное, сталкивались с проблемами взаимоотношений между ними.
• И группа администраторов БД 1С.

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

 

 

Для каждого из «Проектов» мы в плагине HelpDesk настроили свой почтовый ящик. На скриншоте показаны настройки плагина HelpDesk для одного из «Проектов»:

 

 

Письма, поступающие на привязанный к «Проекту» почтовый ящик, попадают в нашу систему в качестве заявок с видом трекера «Запрос пользователя». Все это приводит к уменьшению трудозатрат сотрудников на первичную классификацию поступающих запросов. (Пример на скриншоте: 1.2 Администраторы 1С, 1.4 Ticket Confluence, 1.5 Поддержка Юрайт-ДПП)

Если же такое выделение структуры произвести нельзя, тогда вполне возможно выделить один почтовый ящик, а в дереве создать подчиненные ветки, куда будет распределять заявки первая линия поддержки после первичной классификации (пример на скриншоте: 1.3 поддержка пользователей).

В итоге заявка проходит цикл:

• Сначала происходит первичное автоматическое поступление в ветку проекта;
• Потом аналитик распределяет заявку, т.е. классифицирует, категоризирует и приоритезирует ее;
• После чего аналитик переносит заявку в нужную ветку.

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

• Приоритет;
• Категория;
• Департамент-заказчик;
• Кастомные поля различных типов.

Т.е. при возникновении инцидента можно быть уверенным, что он не пройдет незамеченным.

Пример поступившей заявки и используемых полей:

 

 

Настройки «Проекта»

 

Внутри «Проекта» может вестись несколько видов трекеров. У нас, например, часто используемые трекеры:

• Запрос пользователя;
• Задача;
• Ошибка;
• Предложение;
• Бизнес-проект;
• Программа бизнес-проектов и др.

Трекеров может быть неограниченное количество – их можно добавлять вручную. Каждый трекер гибко настраивается.

В настройках «Проекта» мы можем указать, какие трекеры в нем применяются, а также какие кастомные поля можно подключить.

 

 

Также к каждой ветке индивидуально подключаются/отключаются необходимые модули и другие настройки. Это вы можете найти в стандартной документации по Redmine.

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

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

На обзорной странице «Проекта» вы можете увидеть все виды трекеров и статистику по ним. А также, когда «проваливаетесь» в трекер, вы видите подчиненные этому «Проекту» Issues – назовем их «карточки».

 

 

Ведение бизнес-проектов

Немного повторюсь. Поскольку в понятиях Redmine «Проект» – это ветка дерева структуры, то для ведения реальных проектов мы выделили отдельную ветку с трекерами «Бизнес-проект» и «Программа бизнес-проектов». Это позволяет нам вести статус-отчеты по нашим бизнес-проектам и формировать затраты в разрезе баз распределения.

Структура этой ветки также поделена на подветки по специфике: отдел, заказчик, система, подсистема.

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

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

• База распределение/получатель затрат;
• Бонус за проект;
• Оценка трудозатрат;
• Даты начала/завершения плановые;
• День статус-отчета и другие.

Все задачи, которые созданы в рамках проекта, подчиняются основной карточке бизнес-проекта.

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

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

• Статус проекта;
• Оцененные трудозатраты по проекту;
• Фактические трудозатраты на текущий момент в разрезе процессов исполнения и сотрудников;
• Готовность проекта;
• Постановку бизнес-проекта;
• Всю историю переписки;
• Плановую дату начала проекта, если он был отложен в связи с приоритезацией;
• Плановую дату завершения проекта.

Фактические трудозатраты собираются из подчиненных бизнес-проекту задач по времени, затраченному сотрудниками отделов.

На основании сформированных задач можно построить диаграмму Ганта, но только в информативном варианте. Дополнительно настраивать и интерактивно использовать ее нельзя.

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

 

 

Мы используем доски задач, для распределения задач в рамках недельного планирования.

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

Как пример:

• https://www.redmineup.com/pages/plugins/agile (используется на текущий момент у нас);
• http://rmplus.pro/ru/redmine/plugins/clear_plan или подобные.

 

С учетом особенностей плагина получается похоже на канбан-доску. В ней можно интерактивно перекидывать тикеты –  как между статусами, так и между исполнителями. На трех интерфейсах проверяли – работает только на двух. На стандартном интерфейсе точно работает. Очень удобно выводить на большой телевизор/экран для проведения планерок/митингов.

Также планирование можно осуществлять с помощью версий и потом преобразовывать версии в выпуск релизов.

Как результативность работы отдела мы формируем отчеты в разрезе баз распределения затрат и фактических трудозатрат сотрудников отделов.

Стандартные отчеты по трудозатратам могут выводиться в разрезе:

 

 

Мы используем разрезы отчета по трудозатратам:

• База распределения затрат — наше кастомное поле;
• Получатель затрат — наше кастомное поле;
• Пользователь — стандартное поле.

Формирование может происходить в разрезе периодов:

Для нашего бюджетирования мы используем только «Месяц». Пример отчета:

 

На скриншоте представлен пример с фактическими трудозатратами в разрезе баз распределения за август.

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

И, конечно, как истинные 1С-ники, мы можем написать выгрузку информации из Redmine в 1С, чтобы формировать свой отчет в 1С с нужными группировками и сведениями.

Пример одного из отчетов по затратам:

 

 

Еще немного о функциях Redmine

Из дополнительных полезных функций в Redmine хотелось бы выделить:

• Режим аутентификации – либо по ad, либо по логину и паролю;

• Система оповещений. Пользователю будут приходит уведомления об изменениях в задаче. Можно настроить оповещения по email и по RSS;

• Объединение пользователей в группы. С помощью этого инструмента можно сформировать внутри Redmine иерархическую структуру предприятия. Существуют плагины по интеграции с учетной системой и клонированием ее структуры в группы;
• Ролевая модель прав, с множественной разноуровневой настройкой;

• Настройка Workflow (жизненного цикла) каждого трекера для каждой роли;

• Наличие плагинов интеграции с MS Outlook. Например, довольно удобный плагин с множеством функций, таких как создание заявки в Redmine прямо из письма, комментирование, отслеживание и т.д.; Официальный сайт:

https://ru.ahausoftware.com/

• Также существуют плагины для интеграции с системами мгновенного обмена сообщениями, такими как Telegram, и SMS-шлюзами. По любому каналу связи можно присылать оповещения, например по возникшим инцидентам, мониторинговые сведения и т.д.;
• При наличии компетенции есть возможность просто самим сделать любые плагины.

 

Вопросы — ответы:

Вопрос из зала: Допустим, мы предоставили доступ заказчику, и у нас для него есть определенный перечень поддерживаемых услуг. Например, как в вашем примере – есть услуги сисадминов и услуги кодеров. С каким-то заказчиком мы работаем по обоим типам услуг, а с каким-то – только один тип. Можно ли на уровне прав ограничить, какой тип услуги доступен заказчику?

Ответ: Это варьируется только отдельной выделенной под заказчика веткой – «Проектом», где будут создаваться задачи по выбранным услугам индивидуально для этого заказчика. Или же придется предоставлять доступ ко всем задачам в ветке – «Проекте» поддержки данной услуги. Стандартной возможности ограничить права по признаку услуги и заказчику в «Проекте» в Redmine «из коробки» нет. Можно поискать такой плагин или написать его самому. У нас такой сложной структуры нет, но есть задачи, которые должны быть доступны только отдельным крупным подразделениям, поэтому для них созданы свои ветки.

 

Вопрос из зала: Получается, что каждый заказчик – это «Проект». А внутри одного «Проекта» можно подпроекты делать?

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

 

Вопрос из зала: А проставленные на каждом статусе трудозатраты суммируются? Например, на статусе «В работе» я поставил трудозатраты 0.3, а потом на статусе «Анализ» я поставил еще какие-то трудозатраты.

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

 

 

Без указания вида деятельности отчет можно будет сформировать только по общему времени в разрезе сотрудник + день.

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

 

 

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

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

 

Вопрос из зала: Как организовано взаимодействие с пользователем? Через e-mail?

Ответ: Отправка идет на e-mail стандартным письмом – либо написанным пользователем, либо автоматической отбивкой Redmine, если он является наблюдателем по данной задаче. Также, если он является пользователем Redmine, то на верхней панели отображается, сколько ему задач назначено, сколько новых и сколько измененных. Я сейчас вижу, что на мне 20 задач, одна из которых новая и одна измененная. Со стороны пользователя – только e-mail.

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

 

 

Вопрос из зала: А веб-интерфейс для подачи заявок есть?

Ответ: Нет. Redmine работает на смартфонах и планшетах, т.е. имеет адаптированный интерфейс. Но заявки можно подавать либо через e-mail, либо дать доступ пользователю непосредственно в систему, ограничив его в правах только на создание. В качестве дополнительной возможности можно поставить плагин в Outlook на создание задач в Redmine.

На текущий момент существует плагин Tracker Hider, с помощью которого можно ограничить доступ к трекерам в разрезе пользователей или ролей.

Пример: Любому пользователю с ролью «Наблюдатель» в «Проекте» доступны только карточки с трекером «Запрос пользователя».

 

 

Вопрос из зала: А функциональность по работе с электронной почтой – это из коробки или из плагинов?

Ответ: Да, это есть «из коробки». С помощью плагинов она просто приобретает дополнительные удобства и настройки.

 

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

Ответ: Мы решили эту ситуацию следующим образом.

1. Первым делом мы отключили для пользователей-заказчиков стандартные уведомления Redmine в настройках пользователей. Эта настройка глобальная для всего Redmine по текущему пользователю.

 

2. Далее, для необходимой ветки («Проекта») подключили возможность отправки писем.

3. Аналитик, либо РП-шник может отправить письмо, используя стандартный механизм: нажав признак «Отправить заметку» в режиме редактирования карточки. При необходимости можно указать дополнительных получателей.

 

 

4. Отправитель может написать любой текст и добавить необходимые вложения. Или же использовать ранее настроенные шаблоны.

 

 

Для этого выбирается готовый шаблон, подставляется в тело письма и остается только заполнить при необходимости дополнительные сведения.

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

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

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

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

 

Вопрос из зала: А возможна ли привязка контрагента к поступившей задаче? Например, у меня идет телефонный звонок с АТС, куда забит номер контрагента, и Redmine берет поступивший номер из АТС, создает задачу и подвязывает ее к контрагенту. Решили ли вы задачу иерархии контрагентов?

Ответ: Нет, мы не интегрировали Redmine с IP-телефонией, это не было нашей целью. Идея хорошая, но в нашей специфике она не нужна. На просторах интернета можно найти интеграцию Redmine с Asterisk.

 

Вопрос из зала: У нас вопрос не по IP-телефонии, а по иерархии контрагентов. У нас менеджеры хотят видеть в Redmine такую же иерархию контрагентов, как в 1С.

Ответ: Нет, структура контактов плоская. Единственное, что мы добавили – это ссылку на департамент. Максимум, что мы используем – это собираем контакты по департаментам, мы же делаем Bug Tracker для внутреннего обслуживания, а не для внешних клиентов. В самом Redmine нельзя организовать иерархию по контрагентам, но вы можете связать подразделения в Redmine и 1С, и формировать этот отчет из 1С.

 

Вопрос из зала: А где здесь задается глубина Scrum’а? У нас условно спринт – 7 календарных дней (5 рабочих дней). Где я могу видеть, какая это итерация спринта? Какая это календарная неделя, какой это номер спринта?

Ответ: Глубину Scrum’а можно контролировать версиями. Здесь есть функция формирования версий.

Для этого есть специальный раздел «Оперативный план» (или «Версии» в зависимости от интерфейса).

У меня для примера создано три версии.

 

 

 

Каждая версия может иметь свое наименование, статус и ограничиваться датой завершения.

 

 

По каждой версии видны списки задач при их наличии, а также количество незавершенных.

 

 

Для визуализации можно сформировать диаграммы

 

 

По версиям можно группировать, разбивать задачи, по ним можно строить доски. Можно переносить задачи между спринтами – такая возможность есть в отчете «Планирование версий».

Фактически, Redmine может быть инструментом для организации работы по скраму или канбану. Однако надо учесть, что иногда для удобства не хватает каких-то сортировок и других мелочей. Возможно, есть плагины, которые это поддерживают. В необходимом нам объеме текущей функциональности хватает. Здесь можно делать назначение задач, перемещение между спринтами, видеть, что не успели сделать за плановое время и т.д.

 

Вопрос из зала: Каким образом мы учитываем задачи, которые в текущем спринте были не выполнены? Я должен это видеть по статусу? Или они каким-то автоматическим образом у меня высветится, что их теперь нужно на новую версию забронировать?

Ответ: Можно отобрать задачи по версии. Например, посмотреть в «Оперативном плане», на сколько процентов он выполнен и насколько не выполнен. Т.е., сколько закрыто задач из спринта и сколько еще не закрыто – здесь будет написано. При нажатии на соответствующий пункт откроется список задач, которые не закрылись. Далее, как я уже говорила, их можно проанализировать и перенести на другой спринт.

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

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

 

Вопрос из зала: Как можно перенести задачу на другой спринт – я должен открыть список задач на одной вкладке, канбан-доску на другой и перекинуть?

Ответ: Можно и так. Но удобнее воспользоваться инструментом «Планирование версий». Выбираем из списка неназначенных задач или незавершенных задач конкретной версии нужную задачу и перекидываем ее в следующую версию мышкой – показываем, что мы эту задачу берем в спринт.

 

 

Вопрос из зала: А каким образом можно суммарно увидеть все незакрытые задачи? Может быть, три-четыре версии назад у меня там была какая-то не особо важная задача. Я ее записал, она там висит. Как мне ее не потерять, чтобы она у меня постоянно висела? Насколько я понял, сейчас вы здесь видите только нераспределенные задачи или задачи из выбранного спринта. А как увидеть все незакрытые задачи с накопительным итогом, чтобы понять, брать их в текущий спринт или не брать?

Ответ: Это можно реализовать с помощью фильтрации в задачах. Можно сделать настройки отборов в статусе «открыто» с необходимыми параметрами и сохранить.

 

 

 

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

 

 

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

 

 

Новое поле – указываем тип объекта, куда добавляем, чаще всего используются «Задачи».

 

 

Указываем формат поля – варианты, которые есть, покрывают где-то 90% потребностей.

Указываем имя, каким ролям будет доступно.

 

 

Указываем, для каких проектов, для каких трекеров применяется.

 

Вопрос из зала: А настраиваемые поля можно сделать обязательными?

Ответ: Конечно, по аналогии с дополнительными реквизитами в 1С.

 

 

Обязательные поля отмечены красной звездочкой справа от наименования.

 

 

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

Ответ: Правильно, если меняется поле – кому назначено, то в отчете он возвращает конечное значение.

Давайте я расскажу, как у нас все это устроено. Частично повторюсь.

• Самый главный трекер для Service Desk – это «Запрос пользователя», при котором почта разбирается автоматически и письма превращаются в «Запросы пользователей». Если пользователь направил ответное письмо на уведомление из Redmine или направил уточняющее письмо с такой же темой, то он по теме или ID в теме автоматически прикрепляет текст из такого письма в существующий запрос  – используется классическая функция склейки.
• Далее – когда, например, пришел запрос на консультирование в отдел КИС, консультанты-аналитики разбирают заявку и производят ее первичную классификацию. Определяют, что это – инцидент, ошибка или задача. Бывает даже – идея на новый проект. Соответственно, это тоже часть Service Desk. После классификации все «Запросы пользователей» распределяются по подпроектам ветки iTask, где с ними уже производится дальнейшая работа.
• Если эта работа вырождается в задачу для разработчика, то на основании запроса пользователя создается связанная подчиненная «Задача». То есть, трекер «Запрос пользователя» живет сам по себе, а трекер «Задача» также отдельно. Это мы говорим о мелких доработках и исправлениях ошибок, которые у нас идут отдельным потоком – они появляются из «Запросов пользователя».
• Если задача касается конкретного бизнес-проекта и разработчик сделал ее не на основе «Запроса пользователя», она привязывается к подчиненным бизнес-проекту блокам функциональности КИСа, чтобы потом по задаче можно было увидеть – по какому блоку и в связи с чем мы ее делали – был это «Запрос пользователя» или бизнес-проект.
• Отдельно живет трекер «Бизнес-проект», с помощью которого мы коммуницируем с бизнесом – не с пользователями по запросам и мелким доработкам, а уже с реальными проектами, которые несут бизнес-ценность. В «Бизнес-проекте» в качестве подчиненных задач также могут быть свои подзадачи и даже пачки задач – большие, с подчинением и связями. Это такой мини-проджект. Все эти подзадачи мы опять же привязываем к блокам функциональности КИСа.
• Неважно, откуда появилась задача – из сервис-деска или из бизнес-проекта. Но мы их всех привязываем к блокам функциональности.

Исходя из вышеперечисленного, повторюсь, мы можем увидеть трудозатраты  в разрезе:

• Блоков функциональности КИСа;
• Проектов;
• Исполнителей;
• Связи «Запрос – Задачи/Бизнес-Проект – Подчиненные трекеры».

 

На скриншоте представлен пример с фактическими трудозатратами в разрезе проектов за август месяц. Сотрудники должны распределять свое фактически отработанное время на задачи, которые они выполняли. Это называется Time Sheet. У нас разработчики ежедневно заходят в спецконтур «Рабочие отчеты» и распределяют свое время – формируется факт трудозатрат. Тем самым, мы хотя бы примерно, по факту управляем бюджетом проекта.

 

 

У наших проектов есть предварительный план трудозатрат. И в каждом проекте мы видим, превысили мы его или нет. Redmine автоматически суммирует списанные трудозатраты всех задач, подчиненных проекту. Соответственно, мы знаем, что на этот проект выделено 700 часов. Видим факт – уже отработано 617 часов. Это один из элементов проектного управления.

Процесс деятельности отдела КИС по инцидентам можно представить следующим образом:

 

• Консультант-аналитик проводит анализ поступившего запроса, при необходимости формирует задачу на разработку;
• Разработчик реализует задачу и возвращает ее консультанту-аналитику для проверки и дальнейшей коммуникации;
• Консультант-аналитик уже коммуницирует по запросу пользователя с описанием результатов;
• Если все в порядке, аналитик закрывает задачу – разработчику запрещено закрывать задачи.

По более крупным задачам, в т.ч. проектным, процесс выстроен более расширенно:

 

 

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

Если представить это в более удобном варианте, то у нас существует своя «Восьмерка».

 

 

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

 

Вопрос из зала: Есть ли возможность получить информацию о том, какие задачи выполнил конкретный разработчик?

Ответ: Есть. Существует инструмент «Рабочий отчет», по которому можно посмотреть какой сотрудник на какую задачу сколько времени и в какой день потратил.

 

 

Или это можно посмотреть стандартным отчетом «Трудозатраты» – его тоже можно формировать в разрезе пользователей с расшифровками.

 

 

Вопрос из зала: А как пользователю отслеживать свои трудозатраты?

Ответ: Свои трудозатраты сотрудник тоже контролирует через «Рабочий отчет». А фиксация трудозатрат в задаче производится вручную – либо непосредственно в задаче, либо в «Рабочем отчете». Есть плагины, позволяющие вести учет времени. Например, плагин Redmine Issue Timer выглядит следующим образом:

 

 

При начале работы над задачей сотрудник нажимает кнопку «Play», а при завершении – кнопку «Pause». При сохранении задачи трудозатраты в ней фиксируются.

 

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

Ответ: Возможность планировать есть, но она не идеальная – бесплатный продукт вносит свои нюансы. Есть поле «Плановое время», есть возможность задать свое кастомное поле, если вам не хватает стандартного поля по плановому времени – сколько часов/минут он затратит. Есть возможность указать плановое время и потом сравнить плановое и фактическое время. И, конечно, можно использовать стандартное поле Story Points для покер-планирования.

 

Вопрос из зала: Вы говорили, что Wiki в Redmine неудобный.

Ответ: Wiki в Redmine выглядит недружелюбно.

 

 

 

Для форматирования статей и задач используется язык разметки Markdown. Форматирование происходит не «на лету», а с указанием символов разметки.

 

 

Поиск есть – по слову внутри текста и по заголовкам. Если ввести в поиск «exchange» – он выдаст и темы, и трекеры. Присутствует отбор по виду трекера.

Оглавление не является основной страницей и при входе в Wiki выводится просто список созданных статей.

 

 

Оглавление выглядит следующим образом:

 

 

И, конечно, Wiki в Redmine предназначено только для хранения статей. Ее нельзя использовать для совместной работы.

История изменения статей ведется и можно посмотреть когда, кто и какие изменение произвел.

 

Вопрос из зала: Каким образом происходит наполнение Wiki?

Ответ: У нас процесс построен следующим образом. Производится анализ Service Desk с определенной периодичностью за прошедший период. С помощью первоначальной классификации, которая была произведена аналитиками при поступлении запроса, мы пытаемся обобщить тематики и выявить наиболее проблемные зоны. Дальше – внедряем самообслуживание, т.е. документирование того, каким образом пользователь сам может решить свою проблему или возникший вопрос. Помимо этого, во время текущей работы, аналитик может создавать статьи по своему усмотрению, при возникновении потребности, не дожидаясь общего анализа. Также подготовка wiki-инструкции проходит в рамках разработанных бизнес-проектов или специально выделенных проектов по документированию. Это не Confluence, не Collaboration. Это сверху вниз административными методами. Пользователи в этом не участвуют.

 

Вопрос из зала: У одного из коллег применяется очень интересная система. Мне очень понравилось, я хочу ее себе внедрить. Первая линия техподдержки всегда обязана закрыть задачу из Wiki. И если она не находит статью в Wiki, она обращается на вторую линию техподдержки. И уже вторая линия создает статью, которую обязательно нужно приаттачить к задаче.

Ответ: Мы тоже так стараемся, но мы действуем итерационно – сели, проанализировали, сделали ряд мероприятий. Но это занимает месяцы. Потом опять – сели, проанализировали, выделили необходимые блоки, сделали еще ряд мероприятий.

 

Вопрос из зала: Не очень понятно – как происходит интеграция Git с Redmine?

Ответ: При сохранении изменений в хранилище 1С (при коммите) в описании указывается номер задачи с тегом «#», например «#74516». Тем самым мы получаем сквозной учет – можем посмотреть, какой коммит в хранилище Git привязан к задаче. Нам было важно, что это – desktop-решение, чтобы мы могли удобно им управлять, и, в случае необходимости, перейти на другое решение, потому что все равно потребности растут, и не все потребности Redmine может покрыть. Поэтому я еще раз прошу – если вы будете выбирать продукт, сначала проанализируйте, что вы хотите автоматизировать и какие блоки «покрыть».

 

Вопрос из зала: А мобильное приложение у Redmine вы использовали?

Ответ: Мобильное приложение есть, но оно не совсем удобное. В нашей организации потребности в нем нет. Мы в основном работаем на стационарном компьютере или ноутбуке. Также можно воспользоваться плагинами с возможностями информирования – например, с помощью SMS либо по Telegram.

 

Вопрос из зала: Вы сказали, что выгружаете хранилище в Git, а что вы там в Git видите?

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

 

 

Что мы имеем в итоге:

Исходя из всего вышеописанного, подведем краткие итоги.

 

Плюсы:

• Redmine – OpenSource-продукт с большим и активным сообществом;
• Он прогнозируемый по затратам, недорогой, гибкий, кастомизируемый, легко интегрируемый и масштабируемый;
• Полностью покрывает Bug Tracker, наполовину – управление проектами, совсем немного – ITSM;
• Имеет интеграцию с Git;
• Кастомизируется «на лету»;
• Имеет довольно широкий спектр плагинов. Кроме того, несложно найти специалистов для автоматизации своих процессов;
• Удобный учет фактических трудозатрат. Возможность планирования трудозатрат и бюджетов.

Минусы:

• Неудобный Wiki;
• При необходимости автоматизации своих процессов и при отсутствии компетенции по Ruby on Rails возможно только использование плагинов или поиск сторонних разработчиков;
• Небольшое количество аналитических отчетов;
• Не всегда «дружественный» интерфейс;
• Неудобные массовые классификаторы, которые хотелось бы хранить в виде иерархии.

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

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

В части Redmine будут дополнительные шаги по выстраиванию более четких и контролируемых бизнес-процессов.

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

 

 

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.