Хабрахабр

Вывод Jira из состояния помойки, с чего начать

Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…

У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит. Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили.

Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).
В начале вы пришли в организацию где 50+ проектов, где внедрен трекер с острым желанием наладить системное управление проектами, обеспечив в том числе прозрачную объективную отчетность.

РП как большинство людей, привыкли к тому, что за ошибки их бьют. Объективность — это понимание состояния проекта, не опирающееся на мнение РП проекта.
Зачем так? Скрывает свои ошибки до момента, пока не становится слишком поздно. Что делает РП?

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

(Но разумеется это работает, если кто-то над РП будет эти отчеты читать, делать выводы и принимать решения, за которые нести ответственность).

Зачем нужны отчеты

Отчет не нужен для отчета

image

Аудитору принесли отчеты. Кадр из фильма “Войны Пентагона”. ВСЕ отчеты.

(Форма забастовки: хотите отчеты — получите отчеты). Руководитель, сталкивающийся с массой данных в массе отчетов может впасть в ступор.

Компания получает деньги выполняя задачи.

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

Есть разные виды деятельности (проходящие совместно и дополняющие друг друга): проектная, процессная, организационная и исследовательская, анализ которых несколько различается.

Проектная деятельность

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

Исследования

Исследовательская деятельность не требует решения всех поставленных задач с одной стороны, с другой стороны решенные задачи как правило не создают дохода. Организации для которых это не основная деятельность проводят исследования небольшими командами и коротке циклами, управление в которых происходит “на пальцах” по полученному результату. Jira отчетность мало помогает в управлении.

Процессная деятельность

Рассмотрим процессную деятельность — это выполнение входящего потока задач с оплатой, привязанной к их выполнению, при этом задачи поступают постоянно с некоторой регулярностью (иными словами нет фиксированного scope). К примеру, доработки ИТ системы. В этом случае отчеты могут напрямую отражать состояние процесса.

Зависшая задача = зависшие деньги. Входящая задача — это будущие деньги. Задача, по которой выполнялись работы, но которая не закрыта = связанный капитал, который может быть выкинут если задача протухнет. Задача, которая протухла (больше не нужна) = потеря денег.

Это новые задачи, с согласованной оценкой с заказчиком. Сколько у вас заложено будущего оборота? Но чтобы увидеть это, нужны вычистить шлак — устаревшие не актуальные задачи.

В ценах продажи — это задачи, которые были взяты в работу и не завершенные. Какой связанный капитал? За вычетом шлака. В ценах себестоимости — это трудозатраты по таким задачам в часах или в стоимости ФОТ.

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

Успеваете меняться? Организационная деятельность это прежде всего деятельность по изменению.
Насколько быстро вы меняетесь? И отчетность по зависшим на сотрудниках задачи, позволяющим не забывать выполнять принятые решения. Это скорость выполнения организационных задач и скорость накопления новых.

Дальнейший путь в Lean поддерживается более сложными отчетами (которые мало затрагивались на посиделках, и подробно не расписываются).

Какие идеи приходят на ум:

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

Но перед эти нужно вычистить трекер от шлака.

Вычищаем Jira

Шаг 1. Ничего не настраиваем

Не меняем workflow, статусы, резолюции. Хотя непривычно разбиратся с непривычными статусами, но это данные, в которые люди вкладывали какой-то смысл.

Шаг 2. Убираем старые проекты

Отчет в формате (Проект, Последняя дата последнего изменения статуса задачи).

Проекты, по которым не было движений — кандидаты на перевод в архив.

Если ответственный по проекту еще работает, он скажет статус, если нет — начинается квест поиска концов.

Встречаются замороженные проекты. Задачи архивных проектов переводим в финальный статус с won’t fix. Статус таких задач переводит в заморожено.

Шаг 3. Убираем старые задачи

Отчет по незакрытым задачам с последним изменением статуса менее Х (два года более чем достаточно. Но обычно, если задача висит 90 дней — она “протухла”) дней, сгруппированный по assignee. Скорее всего они протухли, ответственный скажет (если он назначен и не уволен).

Шаг 4. Убираем лишние типы задач

Отчет распределения незакрытых задач по типам задач для отсева ненужных типов.

Шаг 6. Разбираем задачи уволенных

Выделяем задачи с уволенными исполнителями.

Начальник сотрудника допустил “слив” связанного капитала потраченного на задачу времени и не организовал доведение задачи до конца. Особенно интересно смотреть за задачами уволенных сотрудников в разрезе их начальников.

Вписываем в регламент по увольнению обязательство перевесить/закрыть неактуальные задачи.

Шаг 5. Поиск и разбор самой большой кучи

Отчет по статусам незакрытых задач. Выявляем в каком статусе больше всего задач.

Выделяем задачи без назначенного исполнителя, смотрим задачи по “живым” исполнителям. Если статус — задача в работе, то строим отчет по распределению задач в этом статусе по исполнителям. Хм…. На каком-то исполнителе накопилось 2000 задач.

Шаг 7. Стандартизируем статусы, резолюции, жизненные циклы

Возможность взглянуть одинаково на любой проект. Встречаемся и ломаем сопротивление РП. Увы, люди не любят думать о своей заменимости, типичный аргумент: “Я уникально умею вести проект, мне нужен уникальный жизненный цикл.”

Шаг 8. Ищем самые проблемные проекты. Смотрим на отчеты сгорания

Jira — проектов может быть два типа

  • Проекты с известным объемом задач (такое бывает), где применимы отчеты по сгоранию. Иногда так бывает.
  • Процессы: обработка постоянно поступающих задач

Проекты

Если пул задач заведен, то смотрим на прогноз завершения и принимаем меры если прогноз не утешительный.

Процессы

Смотрим решенные задачи против входящих задач.

Решенные задачи делим на внешние и внутренние (обучение, рефакторинг и пр), отображаем на графике только внешние.

Как читать графики

Есть три условных графика:

Реальность ИТ такова, что трудозатраты на релизацию задач имеют значительный статистический разброс (если это конечно не задачи типа выдачи прав).

Люди будут не всегда загружены входящими задачами, занимаясь в перерывах обучением или другой не основной работой. Как следствие, для обеспечения нужного SLA по поддержке нужно планировать ресурсы с запасом, иначе это будет приводить к накоплению задач в буферах входящих задач что сделает сроки выполнения недопустимыми.

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

Вариант А

Нормально, если это реализация фич. На вход поступает больше фич, чем может переварить команда.

Чем больше ошибок, тем медленнее их исправление. Если это поддержка (администрирование и багфиксинг), то ситуация хреновая. Под бочкой с порохом что-то тикает. Чем медленнее исправление, тем больше накапливается ошибок. Тик-так-тик-так….

Вариант В

Если команда делает ровно столько задач, сколько приходит в беклог, то это означает, что

  • либо беклог ведется в другом проекте/месте и, как следствие, вы не видите в отчетах будущего оборота и не можете принять решение на основании отчетов о важности увеличения размера команды,
  • либо люди выдумывают для себя задачи в момент простоя, (на ощущениях и интуиции, без custdev, анализа рынка и пр.); сколько таких задач — неясно и это вызывает тревогу (что если их уже 90%),
  • либо отчеты подделывают.

Вариант С

Нормально, если это поддержка. Команда должна иметь простои, чтобы можно было быстро и оперативно решать проблемы и задачи.

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

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

Шаг по безопасности доступа к постановкам

Ловим задачи со ссылками в интернет на гугл докс. Все документы должны быть внутри периметра, ставим задачу на перенос материалов внутрь

Шаг контроля аналитиков

Постановки делаются где?

Прямо в жире.
Вариант Б. Вариант А. В личном гугл доксе сотрудника.

Как это контролировать? Правильный вариант: Изменение функционала чаще всего должно сопровождаться изменением техно-рабочей документации в Confluence.

Связываем страницу постановки с задачей в жире (достаточно вставить ссылку, это автоматом приведет к созданию двунаправленных связей).

Все доработки с значимыми трудозатратами должны коррелировать с изменениями статей. Строим отчет по изменениям страниц в confluence и сводим его по аналитику с отчетами Jira по доработкам с трудозатратами.

Благодарности

Спасибо активным членам КиФБ за подготовленные материалы и организацию дискуссии, и всем участвовавшим в обсуждении людям.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть