В этой статье рассмотрим реальную историю внедрения приложения для управления проектами OpenProject. После быстрого гугления и поиска по Хабру не удалось найти ни короткого русскоязычного мануала по нему, ни задокументированного опыта его применения на реальных кейсах. Будем исправлять ситуацию!
Для нетерпеливых: OpenProject спустя несколько месяцев прижился, и все к нему привыкли. Хотя, процесс был не из простых. Гнев, торг, затем принятие. Но, давайте по порядку.
Вместо вступления
Итак, исходные данные. В компании мигрируем с продуктовой модели разработки на проектную. Пытаемся зайти в долгосрочное планирование ресурсов, построить диаграмму Ганта по всей компании на год, и в целом немного структурировать довольно хаотичную работу продуктовых команд. Нужен инструмент, где будем записывать работы по каждому проекту, оценки трудозатрат, дедлайны. На выходе должна получаться красивая диаграмма загрузки команд разработки и продактов.
Самое очевидное из быстрых решений - накидать это всё в общем документе ГуглДокс или Эксель Онлайн. Шаблон для типового документа управления проектами есть и там и там. Для небольшого списка из условно пяти параллельно идущих проектов и несложной детализации работ это идальный инструмент.
Нам требуется масштаб сильно больше, поэтому поиграв немного в эксель, отметаем эту опцию. Следующие кандидаты - MS Project и плагин для Джиры BigPicture. Здесь имеем очевидные проблемы с покупкой лицензий, поэтому продолжаем поиск.
Яндекс.Трекер - очень неплохой вариант. В документации зацепило использование понятной корпоративной терминологии. Кажется, мелочь - назвать список проектов “портфелем”, но от подобных мелочей и складывается приятное впечатление. Если хочется стабильного готового решения, берите не раздумывая. Но мы любим приключения и продолжим поиск в self-hosted опциях.
От приложения хотим следующего:
Оно должно быть open-source. Вдруг потребуется допилить свои микрокостыли.
Оно должно не требовать сложных в оплате лицензий.
Оно должно удобно интегрироваться с Active Directory.
Установка и поддержка не должны вызывать бурю эмоций у IT-отдела.
OpenProject отвечает всем этим требованиям. Он открытый и имеет возможность расширения функциональности плагинами. В бесплатной версии есть LDAP-авторизация. Есть образы в докере, т.е. при наличии в компании инфраструктуры с контейнерами и PostgreSQL сервера - поднимается на раз-два-три.
Остановимся на нём.
Почему OpenProject, а не {AppName}?
Что насчет альтернатив? Если загуглить по запросу “open-source project management software”, увидим множество вариантов. Но, “всё не то, всё не так”. Нам нужна тулза для верхнеуровневого, стратегического планирования проектов, чтобы смотреть на происходящее с высоты птичьего полёта. Почти все варианты из быстрого поиска в гугле типа Plane, Taiga, WeKan - про более лоу-левел тактическое планирование задач с канбан-досками, спринтами. У OpenProject к слову тоже есть режим досок с карточками уровня Trello, но видно, что это скорее приятный бонус, а не основная функциональность.
Итак, приложение OpenProject подняли, настроили аутентификацию. Пора уже завести наш первый проект. К чему мы сейчас и приступим.
DISCLAIMER: Всё что будет описано ниже - чистая субъективщина. Вполне возможно, что те же проблемы можно решить гораздо более удобным и понятным способом. Очень вероятно, что это самое более простое решение описано в обширном англоязычном мануале OpenProject. Его, впрочем, лень читать.
Заводим основу проекта
Вложенные проекты
По умолчанию в OpenProject заведены два демо-проекта. Можно продолжить и создать свой рядом с ними, но не будем торопиться. В OpenProject придумана очень удобная система вложенных проектов. Проект X, в который вложены проекты A и B, будет показывать внутри себя все работы из A и B. На практике оказалось очень удобно сделать один корневой проект с именем компании, в него вложить еще несколько виртуальных проектов по направлениям, например “IT-Инфраструктура”, “Внешний маркетинг”, “Внутренние продукты”. Так в раздел “IT-Инфраструктура” пойдет, например, проект миграции SQL базы на PostgreSQL, а во “Внешний маркетинг” - проект подготовки к выставке. При заходе в проект с именем компании мы видим Ганта по всему-всему, при заходе в виртуальные подпроекты - только по проектам из соответствующей категории.
Отмечу момент, изрядно взорвавший мне мозг. Кажется, что вложенность проектов на уровне UI автоматически подразумевает “наследование” их данных. Но, нет. Так не работает. Если у нас тридцать проектов, то, чтобы глобально отключить страницу вики, нужно зайти в настройки тридцати проектов, а не в настройки корневого. Если загуглить по запросу “openproject project inheritance” будут ссылки на страницы тикетов, где авторам намекают про странность такого поведения. Но авторы упорно не намекаются.
В разделе администрирования есть страница с шаблоном проекта. В ней для новых проектов можно настроить дефолтное поведение. Стоит предварительно заглянуть сюда, прежде чем бодро начать заводить все десятки проектов в свежеустановленный OpenProject.
Пользовательские поля
Изначально у проекта есть поля Название, Статус и Описание. Негусто. Фантазия подсказывает, что нам нужно больше полей. Например:
Затрагиваемые продукты компании
Даты начала и окончания всех работ
Задействованные команды
Сложность проекта в человекочасах или каких-либо других единицах
Еще не лишними будут всякие метаданные вида:
Ссылки на типовые документы (документация в конфлюенсе, презентации)
Ссылка на эпик джиры с задачами программистов
Таким образом, заглавная страница проекта будет порталом во все остальные места хранения информации. В самом простом случае всё это легко записывается в поле “Описание”, но есть способ поинтереснее - пользовательские поля.
В разделе Администрирование -> Пользовательские поля -> Проект мы можем настроить свои дополнительные поля для сущности “Проект”. На скриншоте видно, что авторы OpenProject не ограничились обычными текстовыми полями. Есть и типизированные текстовые поля, и выпадающие списки с фиксированным набором значений. Выпадающими списками удобно вводить информаци про сложность проекта, масштаб затрат ресурсов или приоритет проекта на уровне компании.
Участники проекта
Нам надо заранее позаботиться о добавлении в проект всех пользователей, кто будет с ним взаимодействовать. Можно раздавать роли для тех, “кому только посмотреть” и тех, кто может редактировать данные проекта. Подробно останавливаться на этом не будем, тут все достаточно очевидно и не выходит за рамки здравого смысла.
Из неинтуитивного. Если пользователя не добавить в проект, его нельзя будет выбрать, например, исполнителем задачи. Привыкнем, и не такое видели. Ситуация усложняется, когда проектов много. Помним, что наследования у данных проектов нет. Поэтому, если в отделе дизайнеров появляется новый сотрудник, его надо руками добавлять участником в каждый проект, где участвует отдел дизайнеров.
Немного спасают ситуацию группы пользователей. В разделе Администрирование - Пользователи - Группы можно завести группы пользователей на все нужные случаи. Например “Команда разработки продукта AAA”, “Дизайнеры”, “Тестировщики”, “Программисты Команда 1”, “Программисты Команда 2”. Группы могут пересекаться по участникам, так что ограничивать себя в их количестве не стоит. Так как группы может создавать только администратор OpenProject про их структуру и участников стоит позаботиться заранее.
По опыту, стоит всегда оперировать группами участников, а не напрямую добавлять логины пользователй в проект.
Портфель проектов
Имея заполненные пользовательские поля у проекта мы, наверняка, захотим вывести общую плоскую таблицу с данными по всем активным проектам (“портфель”). Данная функция есть только в платной версии OpenProject. Нехитрыми умениями запросов к БД или API опенпроджекта можно самостоятельно организовать себе такую таблицу, например, регулярной выгрузкой в эксель.
Комплекс работ
Заполнив основу шаблона проекта переходим на вкладку “Комплекс работ” и заполняем таблицу с плановыми работами по проекту.
Минимальная единица, с которой придется взаимодействовать называется “Пакет работ”. Слово “пакет” здесь в очередной раз намекает, что мы взаимодействуем не с микрозадачами уровня карточек джиры, а с группами задач.
По аналогии с проектами пакеты работ могут быть вложены друг в друга. Например пакет работ “Разработка фронтенда” может иметь вложенные пакеты работ “Подготовка дизайна в Фигме” и “Программирование MVP на React”. Последний в свою очередь может биться на более детальные пакеты работ “Frontend MVP Главного сайта”, “Frontend MVP Технической админки”. Ну и так далее.
У пакета работ можно задать поле “Тип”. По умолчанию используется тип “Задача”. Тип “Этап” обычно используют для корневой задачи. Ниже мы увидим, что на диаграмме Ганта этапы визуализируются оранжевыми полосками, а задачи - синими. Других принципиальных отличий нет. У пакета работ этих типов можно задать даты начала и завершения, исполнителя (“тот, кто будет руками это делать”), подотчетного (“тот, кого будут пинать, если руки исполнителя не сделают работу в срок”).
Тип работ “Веха” на Ганте визуализируется в виде зеленых точек. Веха не имеет длительности, а только отмечает ключевые моменты проекта.
Журналирование времени
В редактировании задачи рядом с полем “Затраченное время” есть неприметная иконка часов. Клик по ней открывает интерфейс журналирования времени.
Если вы пользовались Work Log в джире, то сразу заметите возможность выбора категории типа работ. Очень удобно для анализа. Shame on you, разработчики Atlassian, отказывающиеся добавить эту очевидную функцию уже 21 год.
Связи между пакетами работ
На странице редактирования пакета работ есть возможность указать связи между задачами.
Тут очевидная ассоциация - связи между полями таблиц в SQL базе данных. Каскадное удаление, внешние ключи и всё вот это. Здесь суть примерно та же самая. При изменении одной задачи, данные других связанных задач подстраиваются под это изменение.
Две самые очевидные связи: “Предшествует” - текущая задача должна быть выполнена до привязываемой задачи и ее антипод “Следует” - текущая задача должна быть выполнена после привязываемой задачи.
Если пакеты работ в проекте должны обязательно делаться последовательно их стоит связать друг с другом. В этом случае при изменении сроков одного из пакетов работ автоматически сдвинутся сроки всех связанных пакетов работ. Удобно? Да! Удобный UI? Не очень.
На странице “Комплекс работ” удобно накидать список работ и завести базовую информацию. Дальше перейти на вкладку “Диаграмма Ганта” и продолжить делать более сложные операции уже на ней. Что мы с вами и сделаем.
Диаграмма Ганта
Здесь видим ту же самую таблицу с пакетами работ, но сбоку показывается диаграмма Ганта. Ну, или пока еще не показывается, если вы не успели заполнить сроки работ. На диаграмме полоски с работами можно нарисовать мышкой, что заметно удобнее интерфейса “Комплекса работ”. Также по клику правой кнопкой на пакет работ в меню есть пункты “Добавить предшественника” и “Добавить подписчика”. Воспользуемся ими для создания связей между пакетами работ и на выходе получаем вот такую красоту.
Ура! Это победа. Результат получился действительно лучше варианта с раскрашиванием ячеек экселя. Со связями между пакетами работ он еще и удобнее в поддержке при появлении изменений. Приключения с self-hosted приложением были оправданы.
Напоследок, вот еще пачка неочевидных странностей и, наоборот, приятных мелочей, связанных со вкладкой Диаграмма Ганта.
Полноэкранный режим
На панели инструментов есть неприметная кнопка включения полноэкранного режима.
Спасибо, разработчики! Это гениально. Вам надо презентовать текущий статус по проектам аудитории. Шэрим экран, включаем на полноэкранный режим и вуаля, все лишние элементы управления спрятаны, остаётся только Гант. Мегалайк за такое.
Фильтры и группировки
Фильтровать список работ проекта можно по любому полю, делать сложные комбинации условий. На практике я нашел применение только фильтру по исполнителям.
Для диаграммы Ганта в корневом проекте для просмотра всех работ по всем проектам компании очень удобно сделать отображение с группировкой по проектам.
В этом случае все работы визуально объединяются в группы. Читабельность такого графика возрастает в разы. Дополнительным бонусом такого отображения является возможность схлопнуть один или даже все проекты. В этом случае у проекта на графиге остаются только точки с вехами. Очень удобно на годовом масштабе смотреть даты релизов проектов.
Из совсем неочевидного UX. Изменение настроек фильтра автоматически создаёт новое “Представление”, т.е. некую конфигурацию, как отображается график и таблица работ. По уровню интутивности это примерно как фильтрация по колонке в экселе создавала бы новую вкладку с копией таблицы, но отфильтрованную по указанным параметрам.
Окей, попробуем не страдать. Представим, что мы не фильтруем, а задаем настройки дашборда. Всё сконфигурировали, сохранили его под понятным всем именем. Он появился в списке в боковой панели. Из очередного неочевидного - дополнительно его нужно сделать публичным. В такой интерпретации UX становится понятным. Например, я в корневом проекте компании с огромной диаграммой Ганта по всем проектам нагенерил такие дашборды для каждой команды разработки. Теперь всем удобно смотреть загрузку по командам и план задач на ближайшие кварталы.
Финал
Как я уже говорил, у нас в компании OpenProject прижился. Интуитивность интерфейса оставляет желать лучшего, иначе бы эта статья никогда не появилась. Плюс, есть удобные SaaS альтернативы. Но если у вас цель - иметь весь софт на своих серверах, то OpenProject будет среди первых кандидатов на установку. И, надеюсь, с подсказками из этой статьи его внедрение пройдет легче и приятнее.
Всем добра и успехов.