В качестве введение
Несмотря на опыт работы в проектном менеджменте более 10 лет, с продуктовой линейкой «atlassian» (Confluence и Jira) познакомился не так давно. Теперь же, после использования этих инструментов на «боевом» проекте, хочу поделиться своим опытом и видением их дальнейшего использования.
Для начала небольшая предыстория, без которой «картина», изложенная ниже, может быть не полной.
10 лет в проектном менеджменте, это в большей мере инфраструктурные «телеком» проекты. Возможно, по этой причине, долгое время не приходилось сталкиваться с линейкой «atlassian».
«Телеком» отрасль 10 лет назад жила в парадигме «эксель-менеджмента», и меняться не спешила.
Но все течет и изменяется, что в общем то хорошо.
Технологии становятся доступней, время меняет людей, кто-то учится, а кто-то уходит на покой (в смысле заслуженный, а не вечный).
В любом случае все отрасли подверглись «цифровой» трансформации, кто-то в большей, кто-то в меньшей степени. И сейчас Jira можно встретить в «телеком» проектах любой степени сложности, а бесплатную версию Confluence может установить себе студент любого учебного заведения.
Также стоит отметить, что нижеописанный опыт, это опыт применения стека методологий проектного менеджмента, в основе которых PMBoK.
Первое знакомство
По работе столкнулся с Confluence и Jira в крупной федеральной «телеком» компании в блоке инфраструктурных проектов, своих ИТ команд нет, при необходимости привлекаются отдельно.
Коллеги по отросли с неохотой используют «новые» ИТ инструменты. Основной «таск-трекер» это служебная почта.
В компании, где я работал, было много разных ИТ-инструментов. Мне повезло, под «флагом» цифровой трансформации получил «зелёный» свет от Руководства на любое применение (на своих проектах) Confluence и Jira, включая любые изменения, которые можно сделать с этими системами.
Проекты и команды о которых идет речь
Проектов было несколько, это и классические инфраструктурные проекты, а также несколько «комплексных» проектов.
Инфраструктурные проекты, это классика, к примеру построить или запустить узел связи. Команды проектов, это специалисты от инженерно-монтажных подразделений до планирования и R&D, это все телеком-команды.
В комплексных проектах решение включало в себя как ИТ, так и инфраструктурные компоненты. Команды «комплексных» проектов смешанные, привлеченные ИТ специалисты (ИТ-команды) и телеком-команды.
Забегая вперед, можно отметить, что ИТ-команды сразу подхватили «идеи» применения Confluence и Jira в наших проектах, телеком-команды были более сдержаны, но также оценили «наработки», и в последствии уже вошли в процесс постфактум.
О Confluence
За полтора года экспериментов и применения обе Системы показали себя крайне эффективными. Конечно, Confluence «влился» в проектный процесс сразу, с Jira пришлось «повозиться».
Основные достижения при использовании Confluence:
1. Единая точка хранения документов.
Все технические документы теперь были в едином доступе команд. Нет проблем с неактуальными версиями, или просьбами: «Пришли мне файл».
2. Интуитивно понятный и унифицированный дизайн «сайтов».
По проектам создал «зеркальные» разделы, с идентичным структурным наполнением. Это позволило снять часть нагрузки с меня как с РП при поиске информации, снизило количество точек принятия решений. Это важно, так как речь идет о крупном федеральном проекте с по фазовой структурой жизненного цикла и отдельной Программе проектов федерального масштаба (в составе 5 проектов).
3. Редактирование в Confluence
В последствии мы уже редактировали документы прямо в Confluence.
4. Страничку «Confluence» всегда можно скачать
Вы всегда можете скачать страничку Confluence себе в Word. Что в свою очередь будет расширять и укреплять персональную Базу знаний.
5. Передача проекта сводиться к переоформлению «прав доступа» и описании структуры «сайта» проекта.
Вся информация по проекту, все «Служебки», Протоколы, документы РП и документация по Решениям были на корпоративном ресурсе, что упростило передачу проекта новому РП в разы.
О Jira
Несколько доводов в пользу Jira даже для инфраструктурных проектов.
В первую очередь необходимо отметить, что использование Jira не отменяет создание структуры проекта (формирования ИСР) или использования MS Project (или его аналогов). Это просто инструменты, они не взаимозаменяемы, а дополняют друг друга.
Для справедливости нужно отметить, нижеописанное применимо и для других «таск-трекеров». Но так как «статья» о линейке «atlassian», то будем говорить все же про Jira.
Основные достижения при использовании Jira:
1. Трекинг, история изменений
Разгрузили почту за счет обсуждения в комментариях активностей по Пакетам работ и Задачам, в том числе декомпозированной структуры этих «сущностей» ИСР проекта (речь о подзадачах и/или поручениях в рамках отдельных Задач).
2. Использование эпиков
«Прикрутили» использование эпиков, что позволило существенно улучшить визуализацию структуры Задач Jira, и соответственно управляемость.
3. Единый онлайн-доступ к компонентам ИСР
Ссылками на Задачи Jira удобно обмениваться, добавляя их ко встречам или вставляя в сообщения корпоративной почты/мессенджера. Также ссылки на Задачи Jira добавлял в структуру MS Project.
4. Единый дашборд «задач» для РП
Единый инструмент аналитики для РП и команды на странице «статистики» Jira.
5. Гибкая кастомизация проекта
Сконфигурировали структуру Задач, Типы задач, статусы задач под проект, настроили отчетность нужного формата.
6. Доски KANBAN и Спринты
Управление проектом выполняли с применением, как подхода KANBAN, так и планирования работ по Спринтам. Платная версия Jira позволяет применять оба подхода в одном проекте параллельно.
7. Фильтры досок KANBAN.
С учетом использования подхода KANBAN гибкая настройка «фильтров» Доски, позволила отображать задачи в ножном разрезе.
Но, как всегда, есть нюансы.
Общие недостатки Confluence и Jira
В равной степени данные недостатки будут и в других аналогичных решениях.
Пришлось столкнуться со следующим:
1. Противодействие изменениям.
Многим «не молодым» сотрудникам сложно меняться и использовать всякие «новые» инструменты. И хорошо если это «рядовой» участник команды, а если речь идет о «Архитекторе» или другом «старшем» специалисте, то это прямо прроблема. В отдельных отраслях это еще встречается.
2. Излишняя кастомизация или запутанная структура «сайта».
Излишняя кастомизация может погубить любую идею, «сайтом» проекта просто никто не будет пользоваться. Что Jira, что Confluence позволяет сотворить многое, но это не говорит о том, что это все будет понятно не посвящённым в «ваши» замыслы. Команда «наше все», интерфейс сайта должен быть максимально понятный. Если кто-либо не очень в курсе термина «юзабилити», то рекомендую почитать легкое чтиво – «Не заставляйте меня думать» автор Стив Круг.
Извлеченные уроки или в качестве рекомендаций для внедрения.
1. Работа с командой
Нужно искать поддержку у отдельных участников команды, чем больше людей будут поддерживать нововведения, тем проще преодолеть противодействие изменениям.
2. Нужны формализованные «Соглашения».
Не важно, что мы внедряем, Confluence, Jira или аналоги, нужны простые и понятные правила, как это работает\должно работать.
Формализуйте в документе Word нужный минимум:
· Для Confluence, это понятная структура «сайта», правила именования файлов.
· Для Jira, это структура проекта, явная структура статусов (бизнес-процесс Задачи).
3. Используем ИСР
В качестве структуры проекта Jira подойдет ИСР проекта. Ясный и понятный артефакт.
4. Используем области знаний/управления проектом
+/- все РП знают PMBoK, структуру Confluence можно привязывать к областям знаний.
5. Минимизируйте уровни вложенности
Не важно, о чем речь, меньше вложенностей, 2-3 уровня это максимум. Про четвертый уровень вложенностей вы забудете через месяц.
6. MS Project (или аналоги).
Инструменты MS Project позволяют совместно применять веб-приложения как «таск-трекеры», если вам на проекте нужен MS Project, используйте его. Условие успеха в следующем, именование задач Jira и MS Project должно «+/-» совпадать (см. пункт про ИСР).
7. Доступу команде и пользователям
В идеале доступ к «сайту» проекта на Confluence должен быть у всех Пользователей Confluence вашей организации. Права на «изменение» у отдельных участников команды.
Доступ к проекту Jira, только для Команды.
8. Используйте макросы и шаблоны
Confluence имеет ряд встроенных инструментов, например это макросы и Шаблоны страниц. Используйте их и создавайте собственные Шаблоны «страниц».
Макросы Confluence предоставляют различные функциональные возможности, возможности для организации пространства на страничке или маппинга страниц. Почитайте отдельно про макросы, их возможности очень обширны, но это тема отдельной статьи.
9. Разделяйте пространство
Пространство странички нужно не просто разделять, а правильно организовывать. Но если на первом этапе не понятно, как и чем это сделать, то просто разделяйте – макрос «Разделитель».
10. Воля РП и личный пример
Пожалуй, это самая важная рекомендация. Заставьте себя полностью уйти в те Системы, которые внедряете. Используйте их каждый день, проводите статусы и рабочие встречи с применением Системы, при решении рабочих вопросов используйте возможность и отправляйте ссылки на обсуждаемую Задачу.
11. Обратная связь от команды
Собирайте обратную связь от команды, где и что можно улучшить, где и что упростить.
12. Бойтесь «улучшайзинга» или «золочения»
Помните, что не все советы/просьбы стоит реализовывать. В основе всех доработок должны стоять ваши принципы, которые отражены в «Соглашениях». «Соглашения» можно менять, но помним о правилах работы с изменениями.
Jira VS ASANA (кратко)
Несмотря на то, что сравнительного анализа «таск-трекеров» в статье не предполагалось, стоит отметить несколько нюансов про Jira в сравнении хотя бы с одним из популярных аналогов.
Как «таск-трекер» Jira интересней чем ASANA по нескольким объективным причинам:
1. Jira позволяет создавать собственную минимальную бизнес-логику.
2. Интеграция с Confluence и другими продуктами «atlassian» «из коробки» даже в бесплатной версии.
Ограничение бесплатной версии Jira как «таск-трекер» по сравнению с ASANA, это масштабируемость.
Но мой взгляд основным ограничением (что очень критично) бесплатной версии линейки «atlassian» это количество Пользователей (до 10 бесплатных пользователей).
Примеры структур
Чтобы визуализировать ваше описанное и предоставить несколько практических примеров, провожу ниже макеты структуры «сайта» Confluence.
К сожалению, в качестве примера, нет возможности полностью продемонстрировать структуры «сайтов» «боевых» проектов, NDA никто не отменял. Но макеты страниц разработаны с учетом конкретных наработок. На макете представлены пять базовых страниц и их схематичная структура.
Для Jira макетов нет, все же проекты Jira индивидуальны.
Подведем итог
Confluence и Jira подкупают своей гибкостью и интегрированностью друг в друга, мобильные версии приложений удобны и понятны. С учетом того, что «atlassian» сделало эту линейку с бесплатными версиями, возможности их применения возросли в разы.
Варианты использования:
1. Рабочие проекты. На рабочих проектах возможно применение Confluence как мета структуры проекта, в которой хранятся требуемые ссылки. ИМХО: КСУП не всегда понятны и «юзабильны», а их изменение может быть ограничено политиками Компании. В этой ситуации Confluence приходит на помощь в качестве весьма гибкого инструмента для личного «сайта» РП.
2. Личные проекты. Перспективы же для личных проектов масштабны и зависят только от вашей фантазии.
3. Обучение. В качестве «песочницы» для изучения продукта бесплатные версии Confluence и Jira не заменимы.
Из недостатков стоит отметить малый размер хранилища бесплатной версии, но при обдуманном подходе это ограничение легко можно обойти интеграцией с одним из облачных хранилищ.
На мой взгляд бесплатный Confluence имеет потенциал для применения Руководителями проектов как в рабочих, так и в личных проектах.
Основным ограничением при работе с бесплатной версии является обдуманное обращение с конфиденциальными данными.
P.S. Буду благодарен за обратную связь, положительную или отрицательную, и/или за советы/примеры применения Confluence и Jira.
