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

16.07.18

Бизнес-анализ

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

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

Что значит хаос в наших системах? Это значит, что от пользователей поступают неупорядоченные, не подлежащие аналитике и структурированию запросы, и отсутствует проектное управление, как таковое. Запросы зависают где-то в почте, в 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, который обычно входит в услугу хостинга.

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

 

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

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

 

 

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

 

 

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

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

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

Все плагины русифицированы, можно покупать и пользоваться. Главное – выбрать под себя удобные. Только обращайте внимание, какую версию 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.

Как пример:

 

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

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

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

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

 

 

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

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

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

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

 

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

Помимо этого можно сформировать подробный отчет по каждому списанному значению времени. При необходимости все отчеты конвертируются в 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 2017 COMMUNITY.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Фаза пресейла: насколько глубоко нужно погружаться в бизнес-домен?

Анализ предметной области Анализ потребностей и поиск решений Бесплатно (free)

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

25.03.2024    234    0    alenkaiva    0    

3

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

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

14.02.2024    558    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    454    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

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

30.01.2024    6707    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

Переход на свободное программное обеспечение – серьезное испытание и для бизнес-пользователей, и для ИТ-подразделения. Нужно учесть много факторов, найти компромиссы и поменять привычки. О «пяти стадиях принятия неизбежного» и успешном преодолении трудностей при переводе ИТ-инфраструктуры автодилерских центров на Linux расскажем в статье.

29.01.2024    2419    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

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

18.01.2024    1592    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

В седьмом выпуске второго сезона подкаста Радио “Аналитик“ поговорили о том, что такое бизнес-компетенции, для чего они нужны аналитику, к чему может привести их отсутствие и как их развивать.

28.11.2023    416    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3033 17.07.18 11:46 Сейчас в теме
2. awk 741 17.07.18 11:47 Сейчас в теме
5. Hissin 178 18.07.18 14:39 Сейчас в теме
(2) По этой ссылке надо быть тоже аккуратным. Всегда проверять версию, на которой работает, а также сначала проверять будет ли она конфликтовать с другими плагинами. И лучше это проводить на тестовом контуре ;)
8. awk 741 18.07.18 15:16 Сейчас в теме
(5) Как много лишних слов. Короче:


Надо проверять на тестовом контуре.


:)
DissideNtAGiTatoR; +1 Ответить
3. olegtymko 889 17.07.18 14:48 Сейчас в теме
Спасибо большое за статью!
6. Hissin 178 18.07.18 14:39 Сейчас в теме
(3) Пожалуйста, рада что она оказалась полезной.
4. rbsoft 208 17.07.18 18:04 Сейчас в теме
ITSM хорошо закрывает GLPI
Мы используем redmine для управления проектами и как багтрекер.
glpi - служба техподдержки.
7. Hissin 178 18.07.18 14:40 Сейчас в теме
(4) Спасибо, обязательно ознакомлюсь.
9. ImHunter 312 18.07.18 15:39 Сейчас в теме
А что насчет code review? В обсуждениях какой-то статьи на ИС мелькал плагин для RM и Git. Если кто его использует - неплохо бы и сюда ссылку.
10. Mythterious 18.07.18 22:38 Сейчас в теме
Екатерина, а можете поделится списком плагинов?
11. Hissin 178 18.07.18 22:45 Сейчас в теме
(10) Какой категории необходимы плагины?
12. Mythterious 19.07.18 06:37 Сейчас в теме
(11) Тоже на пути внедрения редмайна, думаю будет интересно посмотреть что вы используете можете в личку скинуть
13. DO_WHILE_LOOP 358 19.07.18 17:49 Сейчас в теме
14. handscenter 59 06.08.18 17:47 Сейчас в теме
15. real_MaxA 248 17.10.18 09:55 Сейчас в теме
Добрый день.
У меня возник вопрос по картинке "Линнейные процессы КИС".
Как такое организуется в редмайн?
Допустим есть один проект, в нём два трекера "Запрос" и "Задача" (я правильно понял картнку?)
Как, опять же, я понял, изначально имеется issue в трекере "Запрос", который меняет статус до статуса "Анализ и проектирование" (или статусы здесь в сиреневых "квадратиках"? Тогда статус "Анализ Оценка Обратная связь"). Дальше аналитик заводит новый issue в трекере "Задача"?
Дальше. Обе задачи ведут независимую жизнь. Как они сливаются в статус "Релиз" ("В релиз")? Этот статус в каком трекере? И, если этот статус имеется в обоих трекерах, то как обеспечивается (и обеспечивается ли) синхронный перевод этих issue в статус "Релиз" ("В релиз")? Если не обеспечивается синхронный перевод, то, получается, исполнители должны как-то вне системы "синхронизироваться" и проставить этот статус самостоятельно?
DissideNtAGiTatoR; +1 Ответить
16. user1300554 25.10.19 07:51 Сейчас в теме
Как реализовать механизм, чтоб при установке в задаче статуса "В работе" подставлялся назначенным тот сотрудник, который сменил статус?
19. Hissin 178 12.12.19 13:55 Сейчас в теме
(16) Вариантов несколько. Либо использовать плагин, либо написать скрипт по подписке на событие. Третий вариант в настройках раздела, но сейчас уже не помню точно каким способом там была настройка. Уже некоторое время не работаю с Редмайном.
17. пользователь 06.11.19 20:38
Сообщение было скрыто модератором.
...
18. user1295761 29.11.19 12:55 Сейчас в теме
Добрый день!
Подскажите пожалуйста, реализована в плагине ServiceDesk отслеживание SLA, отчет по просроченным задачам ?
Как это вопрос решили Вы ?
20. Hissin 178 12.12.19 14:02 Сейчас в теме
(18) Все зависит от того, на какие этапы у вас SLA. На сайтах с этими плагинами данная возможность заявлена, мы ставили SLA по времени только на классификацию заявки, в зависимости от классификации они уже разбирались. К сожалению, более подробно не подскажу, т.к. у нас не было жестких требований по SLA на решение, т.к. была большая градация критичных, но они разбирались быстро :) . Можете почитать на сайтах с плагинами полную информацию.
21. VKuser201575263 28.01.20 19:29 Сейчас в теме
Добрый день!
Подскажите пожалуйста, где можно прочитать про интеграцию входящей почты c Redmine.
Имеющиеся в системе инструкция не помогла.
Задача в зависимости от домена входящей почты разложить по проектам
24. user1455275 26.08.20 16:08 Сейчас в теме
(21) Советую обратиться к INOUT Corp, они оф. дистрибьюторы EasyRedmine со своими русско говорящими технарями. (21)
26. 3soft 8 17.05.21 15:25 Сейчас в теме
(21) У себя решили это так:
1) почтовый сервер в зависимости от домена входящей почты раскладывает по папкам,
2) написали сколько нужно скриптов (согласно инструкции Remine) по разбору почты, каждый скрипт привязан к просмотру конкретной папки и помещает письмо в конкретный проект.
22. пользователь 16.06.20 15:03
Сообщение было скрыто модератором.
...
23. user1424052 16.06.20 15:15 Сейчас в теме
Добрый день.
Меня всегда отпугивало в редмайне отсутствие хорошей и качественной темы.
Хочу поделиться ссылкой на очень хорошую тему для редмайн - redmine-evolution.com.

Использую у себя в команде.
Прикрепленные файлы:
25. 3soft 8 17.05.21 15:24 Сейчас в теме
Добрый день! На IS'21 Иван Тягунов в своем докладе "Жизнь под прицелом" говорил, что в WiseAdvice отказались от Redmine в пользу Jira. Интересно почему?
27. johntokarev 05.01.22 00:08 Сейчас в теме
Здравствуйте

Подскажите, как можно импортировать проекты из csv например. Не задачи, это есть, а именно список проектов.
Сейчас мы их ведем в Excel, хотели бы перейти на Redmine, но старые проекты и задачи для истории хотим завести в redmine.
Не нашел ни одного плагина или инструмента для этого.
И второй вопрос - как делать backup и restore базы данных?
28. dorot3333 14.03.22 16:41 Сейчас в теме
Подскажите, пожалуйста какой плагин позволяет строить подробный отчет по трудозатратам? https://infostart.ru/upload/iblock/851/8511843096b1e984f28b397049770e4e.jpg
Оставьте свое сообщение