Любое статус-совещание превращается в театр. Спросите своего CTO о результатах, и вы получите героев: кто бился, кто сидел допоздна, что мешало. А спрашивали вы про деньги, сроки и обязательства.

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

Где живут факты

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

Решения, которые что-то значат, никогда не принимаются в Jira или GitLab. Их принимают в чатах, на созвонах, на встречах. Именно там меняется скоуп, сдвигается дата, переворачивается приоритет. Трекер узнает об этом позже, если узнает вообще. Дашборд, который читает только трекер, показывает в ярких цветах мир, которого уже нет.

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

Архитектура

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

От источников до отчета руководству без человека в цепочке
От источников до отчета руководству без человека в цепочке

Источники. Все, где работа оставляет след: трекер и CI, мониторинг, отчеты о тестах, чаты команд, чаты с клиентами и поддержкой, записи встреч, таблица численности, описания и статусы проектов, бюджеты и финансовые модели. Следующие на очереди комплаенс и казначейство. Важнее всего человеческие источники. Решения принимаются именно там.

Два ритма. У информации две скорости, и система работает с ними по-разному. Быстрый ритм ежечасный: новые сообщения попадают в ленту дня, а каждое утро сканер читает каналы эскалаций и сигналы мониторинга и заводит кандидатов в инциденты с цитатами и уровнем уверенности. Медленный ритм ежедневный: трекер, CI, тесты, мониторинг и таблица людей попадают в ежедневный журнал по каждому из 70 проектов вместе с цитатами, из которых он собран. Недельные и двухнедельные отчеты строятся поверх ежедневных данных.

Реестры с источником у каждой записи. Реестры составляют центр системы, отчеты только показывают их срезы. Запись в реестре инцидентов или проектов содержит цитату, из которой она собрана, уровень уверенности и список того, о чем источник не сказал. Проект, который в этот день не оставил следа ни в одном источнике, получает явную запись «тишина» с датой. Молчание тоже факт, и он записан. Одно ведется руками: список проектов вместе с чатами, ключами Jira и папкой расшифровок встреч, которые относятся к каждому. Когда такой список есть, машины знают, где искать.

Свод правил. В инженерном хендбуке компания записана: оргструктура и кто чем владеет, процессы, релизный поезд, дежурства и инциденты, и сама система: что где фиксируется, что где хранится, как с этим работать. Это git-репозиторий на 56 страниц, открытый всем, от линейного инженера до верха. Правила живут в документе, поэтому никому не нужно держать их в голове или узнавать от человека, который ушел в прошлом месяце. Новый сотрудник читает хендбук и в первый же день знает, как работает компания. Тот же документ кормит машины: ежедневные аудиты написаны по нему, и каждая находка называет страницу, которую она проверяет. Проектный менеджер, несогласный с находкой, спорит с документом, а когда документ меняется, вместе с ним меняется и аудит. Метрики считает обычный код с тестами, и они молчат, если в периоде меньше восьми задач или два периода нельзя сравнить.

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

Ограждение. Код пишут и запускают агенты. Доступов они получают меньше, чем просят. Когда языковая модель читает текст, написанный другими людьми, она работает без инструментов с выходом в интернет. Запись в учетные системы по умолчанию выключена. Исходящий текст проходит через линтер на машинные формулировки. Каждую существенную работу атакует второй агент с чистым контекстом, и его задача в том, чтобы ее сломать.

Два месяца чистого времени от пустой папки до системы, которая работает каждый день.

Что изменилось

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

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

Еще становится видно, к чему приводят собственные приоритеты. Когда команду снимают на второй проект, первый встает, и простой появляется на таймлайне с датой и причиной. Мы проследили через GitLab каждый отрезок простоя в наших эпиках. Простой занимает треть жизни каждого эпика. Там, где разработчиков удалось определить по коммитам, в 57% дней простоя они коммитили в другую работу. Они переключились. Объяснять это владельцам больше не нужно. Это результат чьего-то решения, у него есть цена, и люди, которые его приняли, видят это сами.

И стала видна тишина. В сентябре и начале октября 60% дней по проектам не оставили следа ни в одном источнике. Часть из них приходится на проекты, которые ждут партнера. Часть приходится на проекты, где команда назначена, а над проектом никто не работает. Раньше тишина читалась как хорошая новость. Теперь это список, и этот список становится повесткой.

Цифры

  • Отчеты, которые раньше писали руками для трех уровней управления: ноль. Все собираются по расписанию.
  • Возраст данных в отчете для руководства: меньше 24 часов. Раньше: от нескольких дней до недель, смотря у кого было время написать.
  • Источники ответа о статусе: 8 систем, каждый факт по инциденту и проекту прослеживается до цитаты. Раньше: память и несколько чатов.
  • Проекты с ежедневным журналом: 70. Раньше: статус примерно по 10 главным, по памяти.
  • Из 8 самых приоритетных проектов прошлого периода 6 закрыли хотя бы одну задачу. Оставшиеся 2 ушли владельцам в виде вопроса.
  • Поставка: ожидание занимает 55% жизни задачи, очередь в QA 30% времени цикла. Раньше не было видно ни того, ни другого.
  • Простой: треть жизни каждого эпика. Там, где разработчиков удалось определить, 57% дней простоя ушли на другую работу. Это переключения, и у каждой остановки есть дата и причина.
  • Разработка системы: два месяца чистого времени, один человек плюс агенты.

Чем мы заплатили

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

Система ошибается, и мы ее проверяем. Эту статью она тоже проверила: агент-ревьюер сравнил первый черновик с сырыми данными и нашел 14 утверждений, которые не подтвердились. Второе ревью нашло еще семь. Все исправлено.

Есть открытый вопрос, над которым мы еще работаем: кто что видит. В тех же реестрах теперь лежат хронологии инцидентов, журналы проектов, данные о людях и, шаг за шагом, комплаенс и казначейство. Часть данных должна быть видна всем, часть узкому кругу, часть одному человеку. Сегодня разделение грубое: встречи один на один хранятся отдельно от проектных материалов, сырые чаты никогда не покидают ноутбук, сервер отображения работает только на чтение. Более тонкие правила пишутся по мере подключения каждого нового источника. Мы добавляем источники по одному, и каждый приносит свои правила доступа. Это цена того, что мы видим больше компании, и мы платим ее сознательно.

И одно правило появилось из моей ошибки. Несколько недель система сама вносила правки в Jira, 642 изменения в 322 задачах, и проектные менеджеры попросили меня это остановить. Они планировали по этим датам и узнавали о правках задним числом. Половина изменений касалась спринтов, а наш собственный хендбук говорит, что решения по спринтам принимает человек. Я выключил запись. Теперь правило звучит так: агенты находят, люди решают. Те же находки уходят людям, которые владеют планом, и действуют уже они.

Что дальше

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

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

Если ваши статус-совещания похожи на театр

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