Рэдмайн мо министерство образования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше статей можно прочитать здесь.

Redmine — это уникальное приложение с открытым исходным кодом в области управления проектами, и, честно говоря, это не для всех. Хотя многие из лучших приложений для управления проектами работают в режиме онлайн, облачные платформы, которые может установить и использовать любой владелец бизнеса или руководитель проекта, Redmine не так проста. Это требует, чтобы вы установили и поддерживали его, поэтому вам понадобится кто-то из персонала, который сможет это сделать. Приложение является веб-кроссплатформенным и написано с использованием среды Ruby on Rails. Вы можете настроить его как угодно, если кто-то в вашей команде знает, как это сделать. Кроме того, его набор функций делает его более подходящим для отслеживания проблем и ошибок, чем для управления проектами всех уровней. Redmine — отличная платформа для такого использования, особенно потому, что вы можете настроить его под свои нужды. Однако, если ваша команда не настолько технически настроена, вам будет лучше с приложением, которое более дружелюбно из коробки.

Если Redmine не подходит для вас, мы рекомендуем Zoho Projects и Teamwork Projects в качестве выбора для редакторов в категории управления проектами для малого и среднего бизнеса. Более крупные организации, которые управляют десятками проектов одновременно, а также ресурсы для их обеспечения, должны проверить LiquidPlanner, еще один выбор редакции.

Redmine свободен

Redmine с открытым исходным кодом и 100 процентов бесплатно. Сообщество добровольцев поддерживает проект, который был начат в середине 2000-х годов. Там нет платных вариантов для этого.

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

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

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

Redmine — не единственное бесплатное приложение для управления проектами. Вы можете получить бесплатный аккаунт в Zoho Projects, Wrike, Teamwork Projects, TeamGantt и многих других. Большинство бесплатных аккаунтов имеют некоторые ограничения, такие как ограничение количества проектов, которыми вы можете управлять.

Если вы готовы платить за приложение для управления проектами, то сколько вы будете тратить, зависит от размера вашей команды и того, какой уровень обслуживания вам нужен. Большие команды, которым нужен продукт высокого класса, могут планировать платить от 30 до 45 долларов на человека в месяц за отличное приложение. Это примерно то, что стоит LiquidPlanner. Малые предприятия, которые управляют лишь несколькими людьми и проектами, могут легко платить около 4–9 долларов на человека в месяц и получать все, что им нужно.

Redmine Setup

Большинство приложений для управления проектами являются онлайн и облачными. Другими словами, вы заходите на веб-сайт и создаете учетную запись, а затем приглашаете своих товарищей по команде присоединиться к вам по специальному URL. Это то же самое, что и любая другая веб-учетная запись.

Redmine так не работает. Скорее всего, вам сначала нужно установить его, и это не так просто, как загрузить приложение из магазина приложений или с веб-сайта и дважды щелкнуть по нему. Есть пятистраничный документ с инструкциями по настройке Redmine. Чтобы понять инструкции, вам нужно немного ознакомиться с Debian, MySQL, Apache и Linux. Если вы чувствуете тошноту от этих последних слов, Redmine не для вас.

Если вы все еще со мной, то вы должны знать, что Redmine написан с использованием среды Ruby on Rails. Это веб-кросс-платформенное приложение и приложение для работы с базами данных. На момент написания этой статьи вы можете настроить ее на 49 различных языках, включая различные диалекты английского и испанского языков.

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

Если команда, которая будет использовать Redmine, полностью состоит из программистов, они, вероятно, будут в порядке, следуя документации. Тем не менее, поскольку это поддерживается сообществом, инструкции Redmine имеют некоторые пробелы. Например, на момент написания этой статьи в пятиступенчатом руководстве по началу работы написано «TBD» для шагов три, четыре и пять. Так было давно. Будьте готовы катиться с ударами.

Redmine Особенности и интерфейс

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

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

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

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

Интерфейс Redmine не имеет особой индивидуальности или расцвета, еще один аспект, который вы можете настроить. Это разреженный и почти полностью текстовый, но, по крайней мере, аккуратный.

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

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

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

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

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

Только пользовательские интеграции и нет мобильных приложений

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

Другие приложения обычно предлагают как минимум несколько параметров интеграции, которые можно настроить в несколько кликов, будь то подключение приложения к Google Drive, чтобы упростить доступ к общим документам, или добавление способа отправки уведомления в Slack на основе активности в приложении для управления проектами.

Мобильные приложения также не включены в Redmine. Если вашей команде нужно приложение для управления проектами с мобильными приложениями, в Zoho Projects и Teamwork Project они есть для iOS и Android.

Отлично подходит для нишевых групп

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

Однако все это требует времени и усилий, и это не идеальный инструмент для команд, у которых нет кого-то в штате для администрирования приложения с технической точки зрения. Лучшим подходом для компаний, у которых нет ресурсов для работы с Redmine, было бы платить за приложение для управления проектами, которое работает точно так, как вы хотите, чтобы оно продавалось с полки по несколько долларов на человека в месяц. Zoho Projects и Teamwork Projects — это выбор наших редакторов в отношении малых и средних команд. Большие команды, управляющие многими проектами, вероятно, обнаружат, что стоит инвестировать в высококлассное приложение, а LiquidPlanner — это лучший продукт.

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

Функциональные возможностиПравить

Данный продукт предоставляет следующие возможности:

• ведение нескольких проектов;
• гибкая система доступа, основанная на ролях;
• система отслеживания ошибок;
• диаграммы Ганта и календарь;
• ведение новостей проекта, документов и управление файлами;
• оповещение об изменениях с помощью RSS-потоков и электронной почты;
• форумы для каждого проекта;
• учёт временных затрат;
• настраиваемые произвольные поля для инцидентов, временных затрат, проектов и пользователей;
• лёгкая интеграция с системами управления версиями (SVN, CVS, Git, Mercurial, Bazaar и Darcs);
• создание записей об ошибках на основе полученных писем;
• поддержка множественной аутентификации LDAP;
• возможность самостоятельной регистрации новых пользователей;
• многоязычный интерфейс (в том числе русский);