Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…
Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили. У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит.
Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).
В начале вы пришли в организацию где 50+ проектов, где внедрен трекер с острым желанием наладить системное управление проектами, обеспечив в том числе прозрачную объективную отчетность.
Объективность — это понимание состояния проекта, не опирающееся на мнение РП проекта.
Зачем так? РП как большинство людей, привыкли к тому, что за ошибки их бьют. Что делает РП? Скрывает свои ошибки до момента, пока не становится слишком поздно.
Часть отчетов дает финансовое и юридическое управление. Оплаты, договоры, расходы, акты и пр. Но эти средства мало годятся для ранней диагностики проблем, если проблемы возникают в самом рабочем процессе. Если рабочий процесс управляется через трекер задач, то возможно получать информацию из него.
(Но разумеется это работает, если кто-то над РП будет эти отчеты читать, делать выводы и принимать решения, за которые нести ответственность).
Зачем нужны отчеты
Отчет не нужен для отчета
Кадр из фильма “Войны Пентагона”. Аудитору принесли отчеты. ВСЕ отчеты.
Руководитель, сталкивающийся с массой данных в массе отчетов может впасть в ступор. (Форма забастовки: хотите отчеты — получите отчеты).
Компания получает деньги выполняя задачи.
Отчеты должны показывать прежде всего входящий поток будущих денег, связанный капитал, скорость генерации прибыли и операционные расходы. Если трекинг используется для управления изменениями, то это еще и скорость изменений.
Есть разные виды деятельности (проходящие совместно и дополняющие друг друга): проектная, процессная, организационная и исследовательская, анализ которых несколько различается.
Проектная деятельность
В проектах с фиксированной стоимостью важно отслеживать скорость сгорания работы. Если работы заведены в виде задач в 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 по доработкам с трудозатратами. Все доработки с значимыми трудозатратами должны коррелировать с изменениями статей.
Благодарности
Спасибо активным членам КиФБ за подготовленные материалы и организацию дискуссии, и всем участвовавшим в обсуждении людям.
Автор: Евгений Скориков
