red main что это
Redmine
Latest releases¶
Resources¶
Redmine¶
Redmine is a flexible project management web application. Written using the Ruby on Rails framework, it is cross-platform and cross-database.
Redmine is open source and released under the terms of the GNU General Public License v2 (GPL).
Features¶
Some of the main features of Redmine are:
Documentation¶
You can read the Redmine guide.
Online demo¶
A shared online demo can be found at http://demo.redmine.org/. It’s been setup to give registered users the ability to create their own projects. This means once you register, you can create your own project on there and try out the project administration features.
Alternatively, you can get your own Redmine demo environment at http://m.redmine.org with full administrator privileges after filling a simple form.
Support & getting help¶
Before submitting a bug report, a patch or a feature request here, please read the Submission guidelines.
Contributing and helping out¶
Redmine is built and maintained by community volunteers. If you enjoy using it and would like to give back to the community, the Contribute page has several ideas. Software development experience is not required. Check out the Teams Page if you are interested in a specific area to contribute regularly.
You can also make a donation and get listed on the Redmine Donors page.
Who uses Redmine?¶
This page lists some companies and projects using Redmine.
Оперативное планирование в Redmine
В прошлой статье я рассказывал, как мы в Redmine настроили жизненный цикл задач для программистов, сейчас хочу рассказать о том, как мы планируем задачки в Redmine в разрезе месяца (про стратегическое планирование, наверное, напишу в отдельной статье).
Как мы планируем
Вкратце расскажу о процессе оперативного планирования, которое работает в нашем IT-отделе.
Любой сотрудник компании может написать заявку в ИТ-отдел на разработку какой-то функции в ПО или на другую работу (некоторые заявки требуют согласования руководителя, другие — нет).
Заявка попадает в тех. поддержку, которая затем спускает заявку на руководителя направления, ответственного за выполнение данного вида работ.
Руководитель направления, в том случае, если видит необходимость в выполнении данной работы, создает задачу на основе заявки и ставит ее в план на определенный месяц или в очередь (на потом), уведомляя заказчика, написавшего заявку, о смещении сроков.
Также, руководитель направления ставит задания на основе своего собственного виденья, наполняя план следующего месяца задачами, и распределяет задачи по исполнителям.
В последнюю пятницу месяца происходит нечто похожее на планирование спринта Scrum (я как-то переболел этой методологией). Принципиальная разница в том, что у нас много заказчиков присутствует на согласование плана, а в Scrum со стороны заказчика только Product owner.
На собрание по планированию приходит руководитель направления и ключевые заказчики (ключевые заказчики определяются приказом и привязываются к направлению разработки), так же на согласование планов могут прийти другие заказчики, заинтересованные в том, чтобы их задачи попали в обсуждаемый план.
На этом междусобойчике решается, какие задачи нужно выкинуть из составленного руководителем плана, а какие нужно включить. Руководитель корректирует план и утверждает его версию, согласованную ранее на собрании.
В процессе исполнения плана, руководителю могут прилетать срочные заявки, и он может включать их в текущий план на основе собственного виденья.
К этому процессу мы пришли опытным путем, не сразу, и он живет в компании, достаточно давно.
Что мы сделали в Redmine
Стандартный Redmine позволяет объединять задания в версии, проставлять сроки исполнения и оценочные часы. Наверное, на этом стандартные возможности планирования заканчиваются.
Кому-то может хватить этих возможностей, но нам не хватило: нет возможности распределять ресурсы, нет возможности контролировать отставания и еще много чего нет, как выяснилось в процессе внедрения.
В свободном доступе имеется ряд плагинов для более глубокого планирования. Большинство из них заточено под гибкие методологии разработки (Scrum, Kanban и т.д.). Но гибкие методологии не всегда подходят для большой компании. Тем более, у нас есть разные программистские отделы со своей спецификой, есть куча заказчиков и нет желающих становиться Product owner-ом, нужно было внедрять оперативное планирование и не в программистских отделах.
Мы пользовались около квартала плагином «Advanced roadmap», а затем мы стали делать свой и вот что сделали.
Постановка в план
Первое, что мы сделали — ввели понятие исполнителя (я немного рассказывал об этом в прошлой статье). Исполнитель — это тот на кого назначается задача однажды, и он отвечает за ее конечное исполнение. Поле «Назначено» сразу же переименовали в «На ком», в процессе исполнения задачки это поле может меняться несколько раз от автора до заказчика.
Для руководителей проектов сделали кнопку «Назначить», которая ставит задачу в план.
Ввели понятие самого плана, в который может входить несколько версий. Т.е. в плане октября, например, может быть две версии самой программы. При этом в сторонних не программистских отделах, для прозрачности работы с планом, сделали автоматическую привязку задачи к плану по дате завершения. А также, сделали автоматическое создание плана и версии, если их не существовало. Это сделало планирование более прозрачным для специалистов далеких от ИТ.
По исполнителю и по версии (с возможностью переключения в интерфейсе) стали формировать план. Последнюю, кстати, переименовали в этап. Это было понятнее пользователям.
Приоритезация
Довольно быстро возникла проблема приоритезации. У руководителей была необходимость показывать исполнителю в каком порядке необходимо выполнять задачки.
Стандартные текстовые приоритеты Redmine не очень подходили, поскольку не задавали четкой последовательности выполнения задач.
Еще в Redmine есть возможность связывать задачки в последовательные цепочки. Это тоже не подошло, так как смена приоритетов превращается в нетривиальную задачу. Действие иногда блокировались, и скрытое автоматическое изменение сроков во всей цепочке не всегда было к месту.
Сделали запись числового приоритета в настраиваемое поле, а изменение приоритета в плане реализовали с помощью обычного перетаскивания, как во всем плане, так и по конкретному исполнителю. Теперь, если ситуация изменилась, то в любой момент можно перестроить порядок исполнения. Строковые приоритеты, впрочем, оставили, чтобы визуально отражать важность задачек.
Распределение задач
Для того, чтобы эффективно распределять задачи по исполнителям, мы прикрутили несколько счетчиков, которые показывали насколько заполнен план по сотруднику, на сколько исполнитель его выполнил и т.д.
Если сотрудник участвовал в нескольких проектах, то просчитывать его загруженность по проектному плану было проблематично, поэтому мы сделали общий план по исполнителям, который показывал общую картину по исполнителям в разрезе месяца. В него собирались задачки из всех проектов, и он давал более полную картину по загруженности исполнителей.
Согласование плана
Поначалу, план согласовывался только на словах на собрании раз в месяц. Со временем у заказчиков стали возникать вопросы, почему согласованные задачи вылетели из плана и мы прикрутили функцию согласования плана в Redmine.
Теперь, руководитель просто нажимает ссылку «Согласовать план». После этого делается слепок плана и можно смотреть все изменения, которые с ним происходят: как меняется оценка часов, какие задачи вылетают из плана, а какие появляются в нем и даже то, как меняются заголовки задач. Это дает удивительную гибкость руководителю проекта, а контроль над планом остается высоким.
Где зависают задачки и почему
У нас есть как большие, так и маленькие отделы по разработке ПО. В больших отделах есть полный набор должностей, связанных с разработкой ПО: аналитики, программисты, тестировщики и руководитель. Бывало так, что аналитики писали требования «в ящик», а программисты не успевали писать код. Это не очень хорошо, чтобы контролировать такие ситуации мы придумали аналог Scrum-доски (мой руководитель называет ее WIP(Work in progress)-доской). Каждую колонку этой доски можно гибко настроить на основе стандартных запросов задач Redmine. Т.е можно сказать, что задачи этого запроса попадают вот в эту колонку, а запросы этого — в другую.
Доска помогает визуализировать то, на какой стадии жизненного цикла копятся задачи.
Иногда задачи копятся не на должностях, а на конкретных людях или в конкретных статусах. Поэтому мы сделали подробную статистику по тому, сколько времени проводили задачи в определенных статусах и на определенных людях. Этой статистикой удобно пользоваться для анализа жизненного цикла задач, например, или для оценки загруженности определенных людей. Статистика доступна как в рамках всего плана, так и в рамках конкретной задачи.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Redmine
Внешний вид Redmine похож на Trac, приложение, обладающее похожими функциями.
Redmine написан на Ruby on Rails. Приложение является кросс-платформенным и поддерживает 34 языка.
Содержание
Возможности
Redmine предоставляет следующие возможности:
Распространение
По данным разработчика Redmine, веб-приложение используют более 80 известных компаний. Среди пользователей Redmine есть и Ruby. Redmine является самым популярным планировщиком с открытым кодом.
Структура
Пользователи системы
Пользователи являются одним из центральных понятий предметной области. Модель пользователя является основой для идентификации и аутентификации работающего с системой персонала и клиентов, а также для авторизации их в разных ролях, проектах и т. п.
Роли пользователей определяются гибкой моделью определения прав доступа пользователей. Роли включают в себя набор привилегий, позволяющих разграничивать доступ к различным функциям системы.
Пользователям назначается роль в каждом проекте, в котором он участвует, например, «менеджер в проекте по разработке сайта А», «разработчик в проекте по поддержанию интранета компании» или «клиент в проекте по рефакторингу информационной системы компании Б». Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.
Проекты
Проект является одним из основных понятий в предметной области систем управления проектами. Благодаря этой сущности возможно организовать совместную работу и планирование нескольких проектов одновременно с разграничением доступа различным пользователям (см. выше). Проекты допускают иерархическую вложенность.
Трекеры
Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool ), представлявшим каждая в отдельности один проект.
По сути, в «Redmine» трекеры представляют собой аналог подклассов класса «Задача» и являются основой для полиморфизма разного рода задач, позволяя определять для каждого их типа различные поля. Примерами трекеров являются «Улучшение», «Ошибка», «Документирование», «Поддержка»,
Задачи
Задачи являются центральным понятием всей системы, описывающим некую задачу, которую необходимо выполнить. У каждой задачи в обязательном порядке есть описание и автор, в обязательном порядке задача привязана к трекеру.
Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» — актуальные, а «закрыт», «отклонен» — нет).
Для каждого проекта отдельно определяются набор этапов разработки и набор категорий задач. Среди других полей интересны также «оцененное время», служащее основой для построения управленческих диаграмм, а также поле выбора наблюдателей за задачей (см. «Получение уведомлений»). К задачам имеется возможность прикреплять файлы (имеется отдельная сущность «Приложение»).
Значения других перечислимых свойств (например, приоритетность) хранятся в отдельной общей таблице.
Отслеживание изменения параметров задач
За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Измененный параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.
Сущность «Измененный параметр» привязана к отдельной записи журнала и предназначена для хранения старого и нового значения измененного пользователем параметра.
Связи между задачами
Задачи могут быть взаимосвязаны: например, одна задача является подзадачей для другой или предшествовать ей. Эта информация может быть полезна в ходе планирования разработки программы, за её хранение в Redmine отвечает отдельная сущность.
Учёт затраченного на проект времени
Система поддерживает учёт затраченного времени благодаря сущности «Затраченное время», связанной с пользователями и задачей. Сущность позволяет хранить затраченное время, вид деятельности пользователя (разработка, проектирование, поддержка) и краткий комментарий к работе. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоемкости и стоимости разработки.
Привязка репозиториев
Redmine предоставляет возможность интеграции с различными системами управления версиями (репозиториями). Интеграция заключается в отслеживании изменений во внешнем репозитории, их фиксации в базе данных, анализе изменений с целью их привязки к определенным задачам.
В инфологической структуре системы за интеграцию с внешними репозиториями отвечают три сущности: Репозиторий, Редакция и Изменение.
Получение уведомлений
Уведомления пользователей об изменениях, происходящих на сайте, осуществляется с помощью сущности «Наблюдатели», связывающей пользователей с объектами различных классов (проекты, задачи, форумы и др.). В базе данных хранятся также ключи доступа к подписке RSS, позволяющие получать уведомления посредством этой технологии, также уведомления рассылаются с помощью электронной почты.
Некоторые недостатки Redmine
Установка
Необходимые компоненты для установки Redmine
Шаг 1: Распаковка
Шаг 2: Установка devkit
Шаг 3:Установка необходимых gem’ов
Шаг 4: Настройка Redmine
Шаг 5: Создание БД и первый запуск Redmine
Шаг 6: Создание сервиса для Redmine:
Ответвления
Система управления проектами Redmine + Mercurial на Ubuntu 16.04
По мере увеличения числа вовлечённых в проект людей возникает необходимость как-то более эффективно организовывать и управлять их деятельностью. На начальном этапе для этой цели использовались Google-таблицы, но их возможности ограничены, и появилось желание перейти на новый уровень. Изучение доступных систем управления проектами показало, что из систем с открытым кодом Redmine наиболее продвинутая и по некоторым показателям обгоняет даже проприетарные системы.
Redmine, действительно, обладает большими возможностями: управление несколькими проектами, отслеживание ошибок, интеграция с репозиториями, перекрёстные ссылки на исправленные баги в коммитах и на коммиты в баг-репортах, назначение разных ролей пользователей в каждом проекте и т.д. Однако процедура установки довольна сложна, а для некоторых очень полезных функций требуется небольшая доработка или использование плагинов. Надеюсь, что предлагаемое ниже руководство поможет желающим использовать Redmine в своих проектах.
Компоненты
Система управления проектами Redmine
Система контроля версий Mercurial
Кросс-платформенная распределённая система управления версиями.
Также понадобится
Web-сервер и система управления базами данных. Использованы Mysql и Apache.
Установка
Также использовалась официальная инструкция по установке
Redmine Installation Guide.
Предполагаем что у нас уже есть сервер с предустановленным на нём Ubuntu Server 16.04. Дальнейшие инструкции описывают установку системы управления и вспомогательного ПО.
Итак, начнём. Сначала устанавливаем LAMP server:
Во время установки понадобится ввести пароль root-пользователя базы данных MySQL (не путать с паролем root операционной системы).
Создаём базу данных MySQL и пользователя redmine для работы с ней. Вместо [password] вставляем желаемый пароль пользователя.
Распаковываем Redmine в каталог /usr/share/redmine. Находим подкаталог config и копируем config/database.yml.example в config/database.yml. После этого редактируем файл, для того чтобы установить «production» режим базы данных:
Вводим текст и сохраняем файл (ctrl+x):
Устанавливаем необходимые пакеты:
Теперь можно установить gems, необходимые для Redmine:
Создаём случайный ключ, который Rails будет использовать для шифрования данных в cookie:
Дальше создаём структуру базы данных (выполняем в /usr/share/redmine):
Устанавливаем необходимые права доступа:
При желании можно протестировать установку Redmine с помощью веб-сервера WEBrick:
После запуска WEBrick стартовая страница Redmine должна быть доступна в браузере по адресу http://localhost:3000/
Интеграция с Apache
Добавить символьную ссылку на public каталог Redmine:
Необходимо настроить пользователя Passenger по умолчанию, для этого редактируем файл:
Нужно добавить следующую строчку и сохранить (ctrl+x):
В итоге файл должен выглядеть так:
Далее создать конфигурационный файл redmine.conf для apache:
Добавить следующий текст и сохранить (ctrl+x):
Подключить модули Passenger и Rewite:
Отключить default вебсайт и подключить redmine:
Установить права доступа на /tmp/cache Redmine:
Установка Mercurial
Необходимо установить пакеты:
Создать директорию, в которой будут храниться репозитории проектов:
Теперь мы хотим сделать репозитории доступными по http протоколу. Для этого необходимо создать cgi-скрипт:
Добавить следующий текст и сохранить:
Теперь нужно создать файл hgweb.config:
Добавить следующее содержимое и сохранить:
Установить разрешения для файлов:
Теперь надо создать conf файл для Apache:
Добавить следующее содержимое и сохранить:
Ещё необходимо создать ссылки:
Включить CGI модуль и перезапустить Apache:
Чтобы клонировать репозиторий надо будет выполнить:
Если клонируемый проект не публичный (устанавливается в настройках проекта через веб-интерфейс системы Redmine), то потребуется ввести имя пользователя и пароль.
Авторизация осуществляется по проектам, т.е. доступ будет возможен только для участников проекта (менеджеры и разработчики).
При создании репозитория в веб-интерфейсе Redmine необходимо указать путь к нему, например /var/hg/projectname. Репозитории в /var/hg необходимо создать вручную для каждого проекта и инициализировать командой ( hg init ).
После создания нового репозитория надо убедиться, что у него установлены нужные права доступа:
В принципе, есть возможность автоматизировать создание репозиториев. Информация об этом есть в руководстве по ссылке HowTo Install Redmine 1.2.x with Mercurial and Subversion on Ubuntu Server 10.04
Уведомления о фиксации изменений по email
Redmine поддерживает уведомления о разных событиях (изменениях в жизни баг/фич и т.п.). Для того чтобы пользоваться этим функционалом достаточно настроить способ отправки email-сообщений. Делается это в файле /usr/share/redmine/config/configuration.yml В файле имеются шаблоны для разных конфигураций. Нужно разкомментировать и отредактировать нужный.
Обратите внимание, что каждая секция в файле configuration.yml сдвинута на два пробела. Это важно.
Базовые уведомления должны быть доступны после указания способа рассылки электронных писем. Однако для уведомлений об изменениях в репозитории необходимо использовать внешний плагин. Скачать его можно с сайта github.com/lpirl/redmine_diff_email.
Установим этот плагин. Для этого скопируем содержимое плагина в каталог /usr/share/redmine/plugins/redmine_diff_email. В соответствии с инструкцией по установке плагина изменяем файл /usr/share/redmine/app/views/repositories/_form.html.erb:
Оригинальный плагин работает с устаревшей версией redmine. Для redmine-3.3 нужно внести изменения в файл
/usr/share/redmine/plugins/redmine_diff_email/db/migrate/002_add_repositories_is_diff_email_attached.rb. Содержимое файла должно быть таким:
После этого в каталоге /usr/share/redmine выполнить команду для обновления базы данных:
Если плагин установлен правильно, то в списке плагинов Administration → Plugins появится Redmine Diff Email Plugin, а также в веб-интерфейсе Redmine SomeProject → «Settings» Tab → «Repositories» Tab → «Edit» появятся настройки уведомлений.
Кроме того, чтобы информация об изменениях в репозиториях автоматически отслеживалась Redmine, необходимо выполнить дополнительные действия. Сначала нужно включить WS для управления репозиториями и сгенерировать API key. Как это делается:
* В web-интерфейсе Redmine в меню Administration выбрать Settings
* Перейти на вкладку Repositories
* Включить ‘Enable WS for repository management’
* Кликнуть на ссылку ‘Generate a key’
* Сохранить изменения кнопкой ‘Save’
Далее создаём скрипт:
Добавляем следующий текст и сохраняем: (необходимо заменить [your API key] сгенерированным в API-ключом)
Устанавливаем права доступа для созданного файла:
Остаётся добавить в /var/hg/hgweb.config секцию [hooks], чтобы скрипт fetch_changes выполнялся после каждого коммита:
Теперь при изменениях в репозитории Redmine будет автоматически отсылать уведомления участникам проекта.
H Redmine, который вы захотите попробовать в черновиках
Лет 8 тому назад я, начинающий менеджер проектов, начал работать в Redmine. Перед друзьями я хвалился, что все мои проекты хранятся в интернете! И это было круто!
Произошло это благодаря тому, что мой руководитель не на шутку увлекся Redmine, настроил всем доступ, раздал права, а сам принялся докручивать его всеми днями и ночами. Он постоянно спрашивал: «Чего тебе не хватает?», выслушивал, а на следующее утро презентовал «фичу» как «новый айфон» со словами «Really amazing».
Задачи, которые я решаю с помощью Redmine, характерны для многих продуктовых команд. Поэтому я хочу показать вам Redmine таким, каким вы его еще не видели!
Так как я в работаю в коворкинге и часто обедаю с «соседними проектами», то знаю кто чем трекает задачи и проекты, как выбирают систему, почему переходят в облако и так далее. Поэтому я покажу, как можно использовать Redmine для решения актуальных и смежных с разработкой задач.
Те из вас, кто хорошо знаком и уже используют Redmine для разработки, смогут увидеть преимущества от интеграции и использования дополнительных плагинов. Ну а для всех остальных — это обзор и, конечно, возможность увидеть Redmine в деле. В конце концов, это же самая популярная open-sourсe система управления проектами, пусть и с уклоном в разработку.
Содержание:
Разработка продукта, продажи, клиенты, поддержка, ресурсы, команда — как вы уже поняли, далее речь пойдет о том, как продуктовые команды или стартапы могут использовать Redmine для успешной реализации проектов.
1. Выбор темы для Redmine
Это для разогрева… Сколько времени вы проводите в таск менеджере? От того, как организовано ваше рабочее пространство, зависит ваша продуктивность, да и вообще настроение. «Тема» (оформление интерфейса) рабочей системы — это не просто “цвет поменяли”, это прежде всего удобство пользования.
Не знаю как вы, а я частенько встречаю нелестные отзывы об интерфейсе Redmine, а его создатели не торопятся презентовать новый концепт. Итак, вот как большинство пользователей привыкли видеть Redmine:
А вот как выглядит та же страница с «другой» темой для Redmine:
Ну как вам? Разницу видите? Если нет, то обратить внимание на:
2. Как использовать Redmine Agile командам?
Менеджер в Москве, разработчики в Самаре, дизайнер в декрете работает из дома, маркетолог в Берлине, саппорт менеджер в Софии — вот реалии сегодняшнего дня. Собраться за кофе и обсудить проект, перетаскивая стикеры на доске, не всегда получается. Вы пробовали утренний stand-up митинг по Skype?
С появлением новых методологий управления разработкой старый добрый Гант отошел на второй план. Миру нужен был новый визуальный образ, и он появился. Пользователям Redmine не пришлось долго ждать. Быстрые операции по добавлению задач, назначению ответственных, смена статуса задач прямо на доске (где видна картина в целом) стали реальностью. Вы можете разрабатывать продукты по гибкой методологии на Redmine. И, собственно, вот как это выглядит:
Agile команды смогут в Redmine:
Кому интересно подробнее, советую посмотреть весь функционал по Agile методикам в Redmine.
Для наглядности приведу пример из текущего проекта.
В одном из проектов у меня три зоны ответственности:
1. Постановка задач, связанных с развитием продукта.
2. Выявление и отслеживание багов на платформе.
3. Поддержка пользователей через e-mail.
Я работаю недельными спринтами, но каждый день мне важно видеть состояние дел в каждой зоне и реагировать на изменения в соответствии с приоритетом. Соответственно, мне нужно настроить доску задач таким образом, чтобы быстро понять, что происходит и где включиться.
Отфильтровав по типу трекера, одну из досок я настроил таким образом, чтобы считывать и реагировать на новые тиккеты от клиентов (задачи в колонке «Not answered»). Я берусь за задачи, которые в работе, контролирую баги и отвечаю клиентам на саппорт тиккеты. По поводу обработки саппорт тиккетов мы поговорим чуть ниже в разделе «Helpdesk или как автоматизировать поддержку клиентов».
Цвет задачи указывает на категорию задач, и когда недельный спринт направлен на проверку гипотезы рекламного канала, все задачи, связанные с рекламой, видны и ждут меня. Текущие баги выделены красным цветом, что является дополнительным раздражителем именно для меня.
Вуаля! моя доска на этот проект готова!:
3. Управление клиентами и продажами в Redmine
Класический функционал CRM системы может быть полезен вам, если у вас есть клиенты или внешние контакты. Это мой любимый модуль сразу по двум причинам.
Во-первых, для меня клиент и особенно информация о нем выходит на первое место. Чем больше информации я о нем собираю и анализирую, тем больше у меня шансов продать продукт. Обращение в поддержку, скачивание бесплатной версии, заходы на сайт, участие в вебинаре, покупки — все это шаги моей воронки, и мне крайне важно отслеживать все эти касания.
Ну а во-вторых, хоть это и e-commerce проект, мне все-таки нравится видеть, с кем имеешь дело (фото), когда ты знаешь, из какой он страны (часовой пояс), и всю историю отношений с ним. Приятнее, если хотите.
Что вы можете делать в Redmine с помощью модуля CRM:
В одном из SaaS проектов пользователи триальной версии не конвертировались в платную, поэтому мне нужно было:
1. Найти узкое место в воронке продаж
2. Выявить и отработать основные причины отказа
3. Провести Customer development текущих клиентов
Для того, чтобы определить узкое место, мне пришлось построить отдельно воронку по продвижению через триальную версию. Были проблемы с авторизацией и вовлечением клиентов. Мне нужно было понять, почему было 20 регистраций в неделю, и только одна из них становилась платной подпиской.
По каждому клиенту нужно было собирать всю информацию, чтобы выявить причинно-следственные связи.
Чтобы найти узкое место на этапе пользования бесплатной версией, мне пришлось добавить точки касания с клиентом, анализировать поведение внутри триала и фиксировать обратную связь по каждому клиенту. Мы добавили новые этапы взаимодействия с клиентом: онлайн презентация и обучающий тренинг и стали анализировать. Параллельно нужно было вести текущих клиентов, выявлять собирательный образ и улучшать ценностное предложение.
В итоге я настроил для каждого типа клиентов свои «доски» и организовал работу как с лидами, так и текущими клиентами. С помощью фильтров я выстроил нужные мне отчеты и по ответственным исполнителям я мог видеть кто как работает, а визуализация воронки по стадиям продаж давала мне пищу для размышления.
В итоге мне удалось организовать работу сразу пятерых сотрудников, выявить и ликвидировать узкое место (миграция данных из других систем) и, как следствие, повысить средний чек и доход.
4. Helpdesk или как автоматизировать поддержку клиентов в Redmine
Ну а коль уж вы имеете дело с клиентами, то и обращения от них вам нужно обрабатывать! И если поначалу вам удобнее просто отвечать из почтового клиента, то по мере увеличения писем вам придется превратить обращения в тиккеты и организовать работу с ними.
Каждое обращение от клиента имеет свой статус, автора (контакт), ответственного исполнителя. Все действия по обращению хранятся в истории, и всегда можно отследить, кто и что делал, в отличии от почтового клиента.
Чем вам может быть полезен Helpdesk в Redmine:
Входящие тиккеты в Helpdesk модуле можно привязать как к клиенту, так и к сделке или задаче. По каждому клиенту можно отследить историю отношений. Сегментация пользователей внутри CRM ведется с помощью тегов, различных фильтров и кастомных полей.
Пришло обращение от клиента. По ссылке из письма-нотификации переходим на карточку клиента и видим: во-первых, этот клиент пробовал триал версию, во-вторых, у него есть скачанные бесплатные версии продукта, по нему ведется сделка ну и есть вся контактная информация. Не покидая карточки контакта, вы сможете ответить на его обращение, имея под рукой всю историю взаимоотношений с этим клиентом. Это важно для выстраивания персональных и доверительных отношений.
Все мы любим внимание к своей персоне, и если вы упоминаете а-ля :«Я вижу, что вы в прошлом году попробовали нашу триал версию облачного решения, однако вам не хватило поддержки по миграции данных из Trello», то для клиента это будет звучать примерно так: «Вы для нас очень важный клиент, и мы все как один понимаем ответственность и очень хотим помочь вам и вашему бизнесу!»
Даже если мы отвечаем на тиккет из своего почтового клиента, наше сообщение попадает в историю переписки с клиентом. Вы сможете быстро ответить с мобильного телефона и не терять при этом информацию.
5. Управление командой
Продуктовые команды состоят из людей разной квалификации, профессии, и далее по списку. Если у вас под рукой вся информация о предыдущем опыте работы, проектах и компетенциях — вы легко сможете подобрать нужного человека. Особенно актуально для удаленных команд и проектов, в которых часто прибегают к услугам фрилансеров. По каждому фрилансеру есть «карточка», в которой, по сути, хранится вся история взаимоотношений.
Вы сможете планировать отпуска и праздничные мероприятия, заранее предупреждая об этом всю команду проекта. Более того, вы можете оплачивать рабочие часы на основе затраченного времени по разным проектам и задачам. В конце концов, вы не забудете сделать сюрприз и поздравить человека с днем рождения.
На этапе планирования проекта мы подбираем команду. Нам потребуется IOS разработчик, Ux-Ui дизайнер и аналитик. Заказчик — госструктура с хорошим бюджетом. А вы-то, как опытный менеджер, знаете, что это чревато тем, что:
— сроки будут «завтра нужно»
— стиль будет «а можно вместо красного — зеленый»
— концепт поменяется 5 раз
— ответственный исполнитель со стороны заказчика поменяется 3 раза
Итак, открываем список контактов (сотрудники) в Redmine и по тегу «Ux-Ui» смотрим потенциальных дизайнеров. Нам предстоит выбрать из 15 человек. Смотрим портфолио и последние работы на наличие IOS проектов — осталось 5.
Отбрасываем капризных, и дизайнеров-хипстеров, потому как если их вариант не примут с первого раза — расстроятся и будут унывать. Отбрасываем тех, кто работает на фул тайме в компании, так как сроки не позволят работать по выходным и когда муза придет. У оставшихся 2-х кандидатов есть все шансы — отправляем им детали проекта и запрашиваем ценник. В итоге выбираем одного.
По итогам работ на основании затраченного времени выставляем счет, который тут же можно отправить по почте.
6. Управление расходами в Redmine. Финансы
Не пугайтесь, тут не будет интеграции с 1С или другими системами. Я покажу, как можно вести простейшие операции по расходам и доходам внутри проекта. Давайте возьмем реальный кейс: у вас есть представительство в Москве, и на его содержание вы выделяете определенную сумму денег. У вас есть банковские карты, и вам нужно понимать состояние текущего счета — на что были потрачены деньги.
Для этого в Redmine заводим счета, которые привязаны к банковской карте. Каждый раз, совершая ту или иную операцию, вы или ваш сотрудник указывает счет, сумму и категорию операции (заводится из справочника). После создания операции вам на почту приходит уведомление, и вы как менеджер можете подтвердить операцию или нет. Таким образом, у вас под рукой инструмент учета и мониторинга всех расходов по проекту.
7. Redmine в облаке — сфокусируйтесь на проектах!
Jira, Basecamp и другие лидеры рынка на базе своих продуктов создали облачные сервисы (Atlassian, Wrike) и взяли на себя вопросы, связанные c установкой, настройкой, поддержкой и обновлением ПО.
Redmine сыскал славу прежде всего как гибкий инструмент! За его способность настройки под разные задачи его любят миллионы людей по всему миру. Так почему же не использовать это? Почему не доверить Redmine новые задачи? Тем более, что все эти модули появились в результате кропотливой, совместной работы с пользователями Redmine по всему миру.
Именно так и появились SaaS решения для управления проектами и на базe Redmine. Я пользуюсь RedmineUP так как там есть необходимые мне модули, все готово к проектной работе и есть техподдержка, которой нет в бесплатном базовом Redmine.
Так что самое время оглянуться и посмотреть на Redmine по-новому. Удачных проектов вам!