Что такое идеальная система отчетности. Реально ли понять что происходит в компании?

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

    Меня эти вопросы волнуют особенно. Я последние два года работаю над системой управления YouGile.

    Ключевая проблема отчетности в том, что информация в любом одном срезе данных всегда будет неполной, как бы ни старалась компания все отмечать и фиксировать. Самый простой пример — смотрим на список выполненных задач по людям, а это правда в лучшем случае только на 80%. Не все задачи фиксируются, не все отмечаются выполненными, некоторые метрики системно искажаются.

    При этом требование к отчетам из неполной информации очень высокое — отчеты должны формировать объективное понимание того, что происходит.

    То, что мы в итоге сделали после изучения этого вопроса — ниже в коротком ролике. А под катом описание процесса, как к этому пришли.


    Реальность


    Реальность в компаниях несколько хуже, чем просто 20% неполноты в каждом конкретном отчете. Обычно ситуация такова, что вообще “хоть где-то” фиксируется только половина задач, и при этом в разных местах: в мессенджерах, в почте, в устных разговорах…

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

    Как же быть компании, которая разрабатывает систему управления? Как создать объективную картину происходящего без условия, что вся информация будет зафиксирована?

    Наша история отношения к отчетностям


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

    1.5 года назад — регулярно получаем некоторое количество запросов по отчетам. Чаще всего встречается запрос на список задач по людям. Начинаем изучать, как используются отчёты нашими клиентами, которые переходят из других систем. Понимаем, что отчёты там есть. В самых популярных системах можно получить по несколько разных сводок: по людям, по времени, по завершенности, по проектам. НО, разговаривая с пользователями, оказывается, что этим никто особенно не пользуется. Исключения составляют только случаи изначально строго регламентированных процессов, таких как HelpDesk или BugTracker.

    1 год назад — выпускаем такую функцию как конфигуратор, который позволяет писать свои скрипты внутри системы. В том числе выгружать какие-либо данные. Время от времени крупным клиентам настраиваем выгрузки непосредственно под их запросы. И происходит немного странная ситуация — иногда компаниям удается извлечь из этого реальную пользу — они сообщают нам, что выгружают кучу данных, анализируют их и принимают какие-либо решения. А иногда это становится балластом, которым никто не пользуется.

    8 месяцев назад — идем на поводу запросов от клиентов и делаем несколько сводок как в большинстве других систем: ленту всех событий и специальную доску с задачами по сотрудникам. Функция используется редко, но те, кто использует — довольны и хотят больше подобной информации. Объясняют, что хотели бы видеть большее количество деталей по тем или иным процессам.

    5 месяцев назад — всем крупным заказчикам начинаем сразу поставлять систему с всевозможными отчётами на скриптах, которые были разработаны ранее. Их много, они самые разные, но не очень удобно, так как нет нормальных интерфейсов. Но при этом заказчиков такой подход вполне устраивает. Замечаем очень простую истину: когда отчетов много, они по какой-то причине начинают работать. Компании сообщают, что им удается извлечь информацию, на основании которой можно принимать те или иные решения. Появляются запросы на отчеты по просмотрам проектов со стороны сотрудников и распределению внимания команды.

    3 недели назад — ещё раз говорим с клиентами и приходим к простому выводу: количество отчетов с разных сторон обосновано именно тем, что какое-либо понимание можно создать только в том случае, если картина просматривается с множества разных сторон. При этом эти стороны в разных ситуациях могут быть самыми разными.

    Выпускаем конструктор отчетов. Стараемся сделать так, чтобы можно было получить всё что угодно, но при этом сохранить простоту интерфейса.

    Какую систему отчетов и сводок построили мы в YouGile


    Начнем с простого. Всё, что есть системе, можно отфильтровать, отсортировать и вывести в виде таблицы. Скачать в формате Excel или настроить регулярное получение на почту. Вся информация, конечно, динамически меняется с изменениями в проектах.

    Интерфейс формирования отчетов выглядит так:



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

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



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

    Сводки

    Сводки — это всё то же самое, что и отчёты, но задачи выводятся не в виде таблицы с множеством параметров, а в виде столбца на доске. То есть, наряду с обычными столбиками, на доске можно создать специальный столбик, куда выводятся задачи по заданным принципам фильтрации из других проектов и досок за произвольные промежутки времени. Задачи в сводках доступны только для чтения, их нельзя поменять, но можно участвовать в общении в чате.

    Вот самый простой пример из нескольких таких столбиков:



    У такого инструмента вместе с системой отчётности оказалось много вариантов применения для создания понимания того, что происходит в компании. Можно делать отдельные доски для наблюдения, можно добавлять на рабочую доску список актуальных задач из соседнего отдела, можно вывести все важные для себя задачи по одному столбцу на каждый проект и тд.

    Несколько примеров из практики


    1. Хотим узнать, чем занимается команда

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

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



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

    2. Как понять, кто чем занят

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

    Сейчас можно сделать под каждого человека отдельный столбик, вывести туда все его открытые задачи и поставить сортировку по дате последнего сообщения. Наверху окажутся те карточки, в которых идет активное обсуждение. Если вы, например, фото-студия и во всех задачах есть сообщения или файлы, то такой подход будет хорошо работать.



    3. Как понять что команда решила не делать
    В первую колонку выводим все открытые задачи по проекту и наверх поднимаем самые старые. Во вторую выводим архивированные, но не отмеченные как выполненные.



    Это самые простые примеры, которые применимы даже в малых командах. Когда речь идет о компании хотя бы в 100 человек, то интересных срезов по разным подразделениям гораздо больше, но картину при этом удается создать по-прежнему достаточно четкую. И самое главное — всё это без дополнительных усилий по сбору данных. Команда может работать так, как это ей привычно, и при этом остается возможность создать понимание того, что происходит, не находясь непосредственно в процессах.

    Практический вывод


    Для того, чтобы создать объективную картину о том, что происходило в компании, куда тратить ресурсы, оценить риски, которые ожидают компанию впереди, необходимо формировать много разных отчетов с нескольких сторон. Внимательно анализировать, делать выводы и если информации не хватает — формировать новые отчёты и наблюдать за ними. Это всегда занимает время. Например, неделю можно наблюдать за столбиком с задачами из всех проектов по приоритетам. Но после этого формируется волшебное ощущение, что ты понимаешь, что происходит с компанией без непосредственного участия в процессе.

    В больших командах это сложнее, в маленьких попроще, но так или иначе система отчетов действительно может является инструментом принятия решений.

    P.S. На 8.00 небольшой фрагмент обсуждения отчетов на заводе по производству строительных кранов.

    • +11
    • 2.7k
    • 6
    YouGile
    48.29
    Company
    Share post

    Comments 6

      0
      Коллеги, мне вот интересно. Вот у вас программисты когда в код вносят изменения в рамках какой-то карточки-задачи, они как ссылку на эту карточку вставляют? Пряммо вот длинную портянку вида ru.yougile.com/team/xxxxxxxxxx/Текучка/Разработка#chat:yyyyyyyyyyyy или мы застряли в прошлом?
      И вообще, вот как появилась внизу инфа что у нас Free версия — сразу желание что-то писать по багам исчезло, ибо такое ощущение (по некоторым косвенным признакам) что такие как мы, фришники, нафиг не нужны и не интересно (что можно понять, в самом деле). Это так, или можно завалвать вас багрепортами?
        0
        Заваливать багрепортами можно и нам это реально полезно. Все тикеты просматриваются командой и обсуждаются.
        Иногда случается, что ответ от тех. поддержки суховат, особенно если баг минорный и нам известен. Тариф Free может влиять на активность по багу пришедшему от вас, но не сильно.
        Ссылки у нас длинные и это не слишком красиво, но мы не торопимся это править. Когда кто-то вносит изменения в рамках какой-то карточки, он просто пишет в чат этой карточки и ставит в нотификацию нужных людей. Ссылки чаще всего используются вне системы.
          0
          Ясно, спасибо.
          Когда кто-то вносит изменения в рамках какой-то карточки, он просто пишет в чат этой карточки

          Я не про это. Я про исходный код которые пишут программисты. В исходном коде обычно если что-то меняют то в комменте пишут причину изменения. Ну и неплохо нужно по правилам компании ссылку оставить на тикет по которому произведены изменения. Я вот про такое, как раз про внешнюю систему. У вас программисты не YouGile пользуются что ли? Или не документируют так тщательно изменения? Или кодобаза маленькая? У меня такое ощущение что я что-то не понимаю, может YouGile вообще не про программирование?
            0
            Ссылки в комменте кода ставятся далеко не всегда, чаще просто словами описывается что и зачем сделано.
            В YouGile для разработки используется YouGile. Среди активных клиентов, компаний разработчиков мало. Мы скорее для офисов, производств, стройки, связи отделов (в том числе разработки и продаж), веб-студий, банков с процессными задачами на много людей.
              +1
              Понятно, мы так и подозревали, что нацеленность немного не та.
              Это да, рядом с кодом пишешь что делаешь, просто в той же багзиле было удобно — написал в коменте помимо сути происходящего еще и #9744 и сразу понятно что если хочешь кровавых подробностей с описанием не просто «что» а еще и «почему именно так» — беги в багзилу и читай. У нас кодобаза большая, продукт старый зрелый, такие ссылки очень полезны.
        0
        Самый простой пример — смотрим на список выполненных задач по людям, а это правда в лучшем случае только на 80%. Не все задачи фиксируются, не все отмечаются выполненными, некоторые метрики системно искажаются.
        Хм. Вообще-то, насколько мне известно, никакой отчёт и не должен включать в себя ВСЮ информацию. Наоборот, это ВРЕДНО — он станет нечитабельным, непонятным и даже опасным. Любой маркетинг, что внешний, что внутренний — это, перво-наперво, выделение ЗНАЧИМОЙ информации. Можно, конечно, проанализировать, сколько каких операторов Вася Пупкин вставляет в код в течение рабочего дня, сколько вдохов-выдохов делает, сколько минут проводит в туалете, сколько раз моргает и сколько у него было коммуникаций с другими сотрудниками — но зачем? Как это всё (и многое другое) поможет коммерческому процессу?

        Only users with full accounts can post comments. Log in, please.