Что такое redmine и как в нем работать
RedmineUP — платформа для продуктовых команд
Redmine сыскал славу прежде всего как гибкий инструмент. За его способность настройки под разные задачи его любят миллионы людей по всему миру. Так почему же не использовать это? Почему не доверить Redmine новые задачи?
Задачи, которые я решаю с помощью RedmineUP, характерны для многих продуктовых команд и стартапов. Управление проектами, продажами, клиентами, поддержкой, финансами, командой — все это можно делать на базе Redmine.
Что вам это даст? Те из вас, кто хорошо знакомы и уже используют Redmine для разработки, смогут увидеть преимущества от интеграции и использования дополнительных модулей. Ну а для всех остальных — это возможность попробовать Redmine в деле.
RedmineUp — SaaS платформа для продуктовых команд. Мы взяли базовый функционал Redmine, улучшили интерфейс, добавили самые популярные модули (Agile, Helpdesk, CRM, People) и развернули в облаке, обеспечив техподдержку, скорость работы и безопасность данных.
Преимущества и возможности RedmineUP:
1. Простой и удобный интерфейс
От качества интерфейса зависит ваша продуктивность и настроение. Итак, вот как большинство пользователей привыкли видеть Redmine:
А что если мы сделаем интерфейс удобнее, а именно:
В итоге эта же страница будет выглядеть так:
Теперь, после того как мы продумали и улучшили интерфейсы Redmine, добавим функционал.
2. Управление взаимоотношениями с клиентами. CRM
Информация о клиенте выходит на первое место в конкурентной борьбе. Чем больше информации вы собираете и анализируете, тем больше у вас шансов продать продукт. Обращение в поддержку, скачивание бесплатной версии, заходы на сайт, участие в вебинаре, покупки — все это шаги воронки продаж и крайне важно отслеживать все эти касания.
Что вы можете делать в Redmine с помощью модуля CRM:
Стоит отметить, что благодаря настройкам доступа пользователей, вы можете организовать настоящий личный кабинет для ваших клиентов, где могут видеть все свои обращения, скачивать продукты, оплачивать лицензии.
Для того, чтобы определить узкое место, мне пришлось построить отдельно воронку по продвижению пользователей триальной версии. Были выявлены проблемы на этапе авторизации и вовлечения клиентов. Мне нужно было понять, почему было 20 регистраций в неделю, и только одна становилась платной подпиской.
Чтобы найти узкое место на этапе пользования бесплатной версией, мне пришлось добавить точки касания с клиентом, анализировать поведение внутри триала и фиксировать обратную связь по каждому клиенту. В итоге мы добавили новые этапы взаимодействия с клиентом: онлайн презентация и обучающий тренинг и стали анализировать. Параллельно нужно было вести текущих клиентов, выявлять собирательный образ клиента и улучшать ценностное предложение.
В итоге я настроил для каждого типа клиентов свои «доски» и организовал работу как с лидами, так и текущими клиентами. С помощью фильтров я выстроил нужные мне отчеты, и по ответственным исполнителям я мог видеть кто как работает, а визуализация воронки по стадиям продаж давала мне пищу для размышлений.
Мне удалось организовать работу сразу пятерых сотрудников, выявить и ликвидировать узкое место (миграция данных из других систем), и, как следствие, повысить средний чек и доход.
3. Организация службы поддержки клиентов. Helpdesk
Если для вас общение по почте с клиентами стало приносить неудобства (потеря информации, срыв срока, нет ответственного), то пришло время организовать работу службы поддержки.
Каждое обращение от клиента имеет свой статус, автора и ответственного исполнителя. Все действия по тиккету хранятся в истории, и всегда можно отследить текущий статус обращения в отличии от почтового клиента.
Что вы можете делать в Redmine с помощью модуля Helpdesk:
Пришло обращение от клиента. По ссылке из письма-нотификации переходим на карточку клиента и видим: ну, во-первых, этот клиент пробовал триал версию, во-вторых, у него есть скачанные бесплатные версии продукта, по нему ведется сделка, и есть контактная информация.
Не покидая карточки контакта, мы отвечаем на его обращение, имея под рукой нужную информацию о нем. Это важно для выстраивания персональных и доверительных отношений.
Все мы любим внимание к своей персоне, и если вы упоминаете, а-ля: «Я вижу, что вы в прошлом году попробовали нашу триал версию облачного решения, однако вам не хватило поддержки по миграции данных из Trello», то для клиента это будет звучать примерно так: «Вы для нас очень важный клиент, и мы все как один понимаем ответственность и очень хотим помочь вам и вашему бизнесу!»
Интеграция данных из CRM и Helpdesk играет очень важную роль в организации взаимодейсвия с клиентами. А теперь посмотрим, как организуется работа команды.
4. Управление командой
Продуктовые команды состоят из людей с разной квалификацией, опытом и разными навыками. Если у вас под рукой вся информация о предыдущем опыте работы, проектах и компетенциях — вы легко сможете подобрать нужного человека. Особенно актуально для удаленных команд и проектов, в которых часто прибегают к услугам фрилансеров. По каждому фрилансеру есть «карточка», в которой хранится вся история взаимоотношений.
Что вы можете делать в Redmine с помощью модуля People:
Итак, открываем список контактов (сотрудники) в Redmine и по тегу «Ux-Ui» отбираем потенциальных дизайнеров. Нам предстоит выбрать из 15 человек. Смотрим портфолио и последние работы на наличие IOS проектов — осталось 5.
Отбрасываем капризных и дизайнеров-хипстеров, потому как если их вариант не примут с первого раза — расстроятся и раскиснут. Как мы это узнали? Из истории прошлых проектов — комментарии менеджеров и коллег.
Отбрасываем тех, кто работает в настоящий момент в компании на фул тайме, так как сроки не позволят работать по выходным и когда муза придет. У оставшихся 2-х кандидатов есть все шансы — отправляем им детали проекта и запрашиваем ценник. В итоге выбираем одного.
По итогам работ, на основании затраченного времени выставляем счет, который тут же можно отправить по почте.
5. Управление разработкой по гибким методологиям. Agile.
Менеджер в Москве, разработчики в Самаре, дизайнер в декрете работает из дома, маркетолог в Варшаве, саппорт менеджер в Софии — вот реалии сегодняшнего дня. Agile команды оценят возможность работы по гибким методологиям.
Что вы можете делать в Redmine с помощью модуля Agile?:
Более подробный обзор модуля Agile:
6. Хостинг, обновление и поддержка от экпертов Redmine.
Jira, Basecamp и другие лидеры рынка систем управления проектами на базе своих продуктов создали облачные сервисы (Atlassian, Wrike) и взяли на себя вопросы, связанные c установкой, настройкой и обновлением ПО.
RedmineUP — это готовая для использования платформа в облаке на базе Redmine. Вам не придется заниматься вопросами настройки и конфигурации сервера, поддержкой и обновлением ПО, следить за скоростью работы и обеспечивать безопасность данных. Мы это уже сделали, чтобы вы могли сфокусироваться на главном — ваших проектах.
Попробуйте RedmineUP в деле и поделитесь впечатлениями. Удачных проектов!
Жизненный цикл задач в Redmine для небольшой группы разработки. Наш опыт и полезные советы
Думаю, эта статья должна помочь людям, которые впервые решили автоматизировать процесс трекания задач на базе Redmine в группе разработки программного обеспечения. В статье я расскажу о том, как этот процесс устроен у нас, какие новые поля для задачи мы завели и какие проблемы решают эти поля. Думаю, статья будет полезна широкому кругу лиц, на мой взгляд, настройка жизненного цикла задач эта работа под лозунгом «Очевидное — не очевидно».
Еще! Мы работаем в большой корпоративной среде, в основном, для внутренних клиентов (причем их несколько) и эта ситуация нашла отражение в нашем жизненном цикле.
Начнем.
Все начинается с того, что в один прекрасный момент появляется задача и после своего появления, задача логично должна упасть на автора. Почему?! Потому что у задачи всегда должен быть сотрудник, который отвечает за дальнейшее ее исполнение, тот, кто в данный момент тормозит задачу, тот на чей стороне «мячик», и он должен этот мячик «передать другому», сделать что-то вроде футбольного паса. Иногда этого человека быть не должно. Например, когда больше нет необходимости выполнять действия по задаче, когда она закрыта.
Какую информацию мы просим обязательно заполнить пользователя, создающего задачу?
Ну понятно, это тип задания, заголовок и описание, но еще:
Например, цель может быть такой:
«Реализовать возможность расчёта базовой части ЗП на основе произвольной математической формулы».
А в описании будут более детальные ключевые шаги и требования для достижения цели. Например, «подключение библиотеки MathML, возможность связывания формулы с расчетным периодом» и т.д.
В общем случае, описание вообще может зависеть от квалификации исполнителя и в некоторых случаях может быть всего в пару строк (если у вас хорошая коммуникация с исполнителем, вы сработались и хорошо друг друга понимаете).
Куда может отправиться новая задача?
Чаще всего она отправляется в план, поскольку у нас часто возникают приоритетные задачи (ну вот такая вот клиент ориентированность и нежелание заказчиков думать о будущем).
Но бывает так, что задача не приоритетна и тогда она может отправиться в очередь (или Backlog, кому как больше нравится).
Если задача отправляется в план, то мы обязательно просим заполнить у нее следующие поля:
В момент постановки в план в поле задачи «Исполнитель» всегда копируется значение из поля «На ком». Задача рано или поздно уйдет с сотрудника ответственного за исполнение, но ответственность за исполнение уйти не должна, поэтому у каждой выполненной задачи всегда сохраняется исполнитель.
Что исполнитель может сделать с задачей?
Две спорные, но имеющие право на жизнь функции: «приступить» и «приостановить», которые соответственно меняют статус задачи из «Назначено» в «В работе» и наоборот. В малых группах эта функция не особо прижилась, а в некоторых больших прижилась. Если программистов много и они помечают задачи, которые исполняют в текущий момент, то можно строить срез по тем задачам, которые в текущий момент в работе у исполнителей (своего рода «Work in Progress»).
Почти в любом статусе сотрудник, на котором в текущий момент задача может запросить информацию у автора, руководителя, заказчика и т.д. Конечно, исполнитель не исключение.
Конечно главная функция для исполнителя это возможность отправки задачи на проверку и одноимённая кнопка «На проверку». Кнопка отправляет задачу тестировщику, что должен заполнить программист:
После отправки задачи на проверку, ее статус логично изменяется на «На проверке». Теперь за дальнейшее исполнение задачи отвечает тестировщик.
Что тестировщик может сделать с задачей?
Ну, понятно: отправить задачку на доработку (кнопка «Вернуть обратно») или пропустить дальше на production-сервер (кнопка «Проверено»).
Еще он может изменить проверяющего (и одноименная кнопка), и в нашей группе административно закреплено, что задачи должны проходить вторую проверку через руководителя (в других группах нет).
Что может сделать с задачей администратор Redmine?
Он может выложить ее на рабочий сервер, тем самым переведя задачу из статуса «На проверки» в статус «В эксплуатации». Задача назначается на заказчика.
Что может сделать с задачей заказчик?
Заказчик может принять работу или не принять. Если не принял, то он отправляет задачу на перепроверку тестеровщику, написав комментарий. Если принял, то жмет кнопочку «Выполнено» и проставляет оценку выполнения и пояснение к оценке. Эти оценки влияют на ЗП исполнителя и руководителя.
В совокупности получается вот такая вот схема жизненного цикла задачи.
На ней переходов между статусами гораздо больше, чем описано в статье. В большинстве своем это привилегированные переходы для руководителя, когда ему административно нужно перевести задачу в следующее состояние не дожидаясь тестеровщика или программиста.
Конечно это не все, что у нас есть в жизненном цикле задач, но если бы я писал про все, то наверное маленькая книжечка получилась бы.
Буду рад, если вы поделитесь информацией о том, какой жизненный цикл используется у вас? Какие поля вы просите заполнить сотрудников когда трекаете задачу и почему?
Развертывание и сопровождение Redmine, правильный путь
Дисклеймер: это не обычное руководство вида «Как установить Redmine». В нем я не буду погружаться в настройку базы данных или установку веб-сервера. Я также не буду рассказывать о настройке Redmine. Документация по Redmine в этом плане является достаточно полной. А для того, что не упоминается в официальной документации, есть общая процедура запуска Rails-приложений, которую можно легко найти в Интернете.
Вместо этого речь пойдет о сопровождении собственной, более или менее кастомизированной версии Redmine, которая может быть развернута с помощью одной команды оболочки, когда это необходимо.
Готовы? Тогда начнём.
Отложите сборки типа «все-в-одном» и готовые к запуску виртуальные машины
Установочные пакеты Bitnami или предварительно установленные виртуальные машины хороши для быстрой пробы Redmine, но не подходят для продуктивного использования. Почему? Потому что у них нет обновления. Ой, секундочку, у Bitnami есть. Правда, оно больше похоже на шутку. «Установите новую версию всего стека в другой каталог и переместите туда свои данные» — это не обновление. Ни слова о настройке, кастомизации и плагинах, которые, вероятно, также нужно сохранить и переустановить. Желаю удачи с таким «обновлением».
Релизы патчей Redmine выходят один или два раза в месяц. Исправления ошибок, связанных с безопасностью, выпускаются по мере необходимости — вы же не хотите пропустить их?
Факт, о котором люди часто забывают: время обновления не всегда зависит от вас. Конечно, можно отложить обновление до выхода следующей младшей версии Redmine — на несколько недель (наверное, даже и на более длительный срок). Но вы же не хотите при обнаружении новых проблем безопасности в Redmine или Rails сидеть с непатченной системой, пока не получится освободить время для установки и настройки нового стека Bitnami и вручную переместить все данные?
Установка — это только верхушка айсберга. Обновление — вот что придется делать регулярно.
Поиск простейшего способа установки определенно перестает быть актуальным, как только принимается решение использовать Redmine в производстве. Простое сопровождение и возможность модернизации — вот на чем нужно заострять внимание, чтобы минимизировать затраты и риски, связанные с использованием собственного Redmine.
Ниже я расскажу, как просто поддерживать Redmine в актуальном состоянии.
Используйте Git
Даже если вы намереваетесь запустить стоковый Redmine без каких-либо настроек или плагинов, всё равно используйте репозиторий Git для хранения копии Redmine. По крайней мере, наличие специализированного репозитория даст вам место хранения всего необходимого для развертывания (позже это будет рассмотрено подробнее). Рано или поздно вы (или ваши пользователи) захотите установить какой-нибудь плагин или настраиваемую тему, и для этого уже будет готова инфраструктура. Эксперименты с изменениями и тестирование плагинов и тем в локальных ветвях без нарушений в производственном коде становятся очень простыми при наличии собственного репозитория git c Redmine. Так что сейчас мы начнем с настройки репозитория.
Хотя основной репозиторий Redmine является экземпляром Subversion, на Github есть полуофициальный репозиторий, который поддерживается основным коммиттером и постоянно обновляется. Используйте его для настройки собственного репозитория:
Настройка локального клона Redmine
Измените номер версии 3.2-stable на номер последней стабильной версии Redmine.
Удаленный репозиторий git@yourserver.com должен быть частным, так как в нем будет храниться конфигурация развертывания (а возможно, и прочая информация, публиковать которую не стоит). Поскольку описанный ниже процесс развертывания будет извлекать из этого репозитория код, то репозиторий должен быть доступен во время развертываний, поэтому не размещайте его на настольных компьютерах. Идеальной будет ситуация, когда репозиторий также будет доступен с веб-сервера, на котором происходит развертывание. Но это при необходимости можно обойти.
Пропатчите обновления версий
Время от времени эта восходящая ветвь будет получать некоторые новые коммиты. Ваша задача — включить новые коммиты в локальную ветвь local/3.2-stable для развертывания.
Хотя возможно и просто регулярно дополнять восходящую ветвь, я предлагаю использовать git rebase для поддержки собственного набора изменений поверх стокового кода Redmine:
Перебазирование локальных изменений поверх «голого» Redmine:
Итогом будет являться чистая история, в которой ваши (локальные) коммиты всегда находятся поверх последних (восходящих) коммитов Redmine.
Младшие и старшие обновления
Теперь, когда есть новая стабильная ветвь (скажем, 3.3-stable ), делайте то же самое — перебазируйте ваши изменения поверх неё. Команды git будут немного отличаться из-за изменения восходящей ветви:
Перенос локальных изменений в новую стабильную ветвь
Для новой старшей версии требуется сделать то же самое.
Бог ты мой, у меня конфликты!
Рано или поздно (вероятно, уже во время первого обновления до новой младшей версии) вы столкнетесь с конфликтами слияния. Во время ребазирования Git применяет коммиты один за другим и останавливается каждый раз, когда применение коммита происходит с ошибками. В этом случае команда git status покажет проблемные файлы.
Что дальше?
Теперь, когда рабочий процесс Git настроен должным образом, пришло время автоматизировать развертывание, о котором я расскажу во второй части этого руководства (примечание: перевод второй части будет доступен в течение нескольких дней).
Национальная библиотека им. Н. Э. Баумана
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: