Тоже самое, по смыслу, время от времени говорил мне мой руководитель. Он не мог понять чем конкретно занимается мой депортамент, в какой последовательности и для чего. Оспаривать то, что работы делается много он не мог, но при этом и имел полное право не понимать, что же всё-таки делается.
На картинке выше четыре стиля отчета, использовавшиеся в разные промежутки времени (с 2006 года по начало 2009). Красная черта – это отметка страницы А4.

Первый отчет был предельно краток: “на проекте таком то сделали это и это, движемся в таком то направлении”. При этом текст основного отчета составлялся из того, что писали подчиненные (та еще каторга, сколько не напоминай, кто-нибудь да забудет. Да и литературным даром никто не обладал).

Название проекта

Что было сделано и какие проблемы встретились. Обычным человеческим языком.

Имена участников

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

Имя

Задача 1 (под назавание ссылка)

Задача 2 (ссылка)

Он получился длиннее первого в несколько раз и хотя теперь можно было получить представление о том, что делал человек, понять, что происходит на проекте было сложнее, по самому отчету, нужно было идти в Jira и делать выборку. Так же он дополнялся страницами в Wiki (Confluence) по каждому проекту. Такие страницы описывали, как раз что происходит с проектом и конкретное участие сотрудников. Но на них надо было заходить специально. Лень руководства победила формат отчета, за год так и не получилось приучить сначала смотреть к Confluence, а потом спрашивать.

Путь от такого отчета к автоматической сборке занял больше года и все недовольства удавалось отбивать предложением указать формат отчета четко. Удачное решение пришло в голову после обнаружений RPC сервиса в трекинговой системе. За несколько дней была написана программа и придумана реструктуризация, которая позволила бы генерировать любые отчеты по существующим данным. В Jira было задействовано всё от компонент, до кастомных полей. Третий отчет был огромен. На картинке лишь пятая часть. Он вытаскивал из задачи название, описание и worklog, складывал всё вместе и сортировал по людям. Страницы в Confluence по прежнему были, но теперь состояние проектов и информацию о работе людей можно было получить прямо из отчета. Да и моё участие в написании отчета сократилось до финального ревью и выкидывания лишниго. И того, за место 2 часов отчет готовился за 10 – 15 минут.

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

На первый лист идёт информация по проектам, дальше по людям.

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

Причины этого бага, скорее всего, в том, что сначала обрабатывается синтаксис wiki, а потом вызывается обработка URL в тексте, соответственно и все ссылки с “++”, “__”, также могут быть обработаны неправильно, либо искажены.