Як бізнес-аналітик у команді з 8 осіб економить 40 годин на місяць завдяки автоматизації звітності

Минулого місяця я витратив понад 45 годин на ручне структурування хаотичних вимог від трьох замовників з ЄС. Мені довелося самостійно переписувати 12 технічних завдань, оскільки розробники не розуміли специфіку бізнес-логіки. Кожен звіт для клієнта в рамках Diia City вимагав деталізації кожної витраченої години, що займало ще близько 15 годин на тиждень. Я використовував Excel та Google Docs, намагаючись звести дані з Jira вручну, але постійно виникали помилки в розрахунках. Це призвело до затримки релізу на 4 дні через неточності в документації.

Найскладнішим було підтримувати актуальність документації, коли клієнт вносить зміни тричі на тиждень. У команді всього 8 людей, тому будь-яка моя помилка в аналітиці миттєво зупиняє роботу двох розробників. Мені доводилося паралельно вести опис API та бізнес-процесів, постійно перемикаючись між контекстами. Відсутність єдиного джерела істини призводила до того, що версії ТЗ у мене та у техліда розходилися. Це створювало величезний когнітивний тиск і вимагало постійних нічних перевірок описів.

Складність полягала в тому, що європейські клієнти вимагають високої деталізації за стандартами ISO, а ми — маленька гнучка команда. У нас немає окремого технічного письменника, тому роль «універсального солдата» повністю лягла на мене. Кожне уточнення від стейкхолдерів потрібно було валідувати з обмеженими ресурсами розробки, щоб не вийти за рамки бюджету. Крім того, податковий режим Diia City вимагає специфічного обліку роботи фахівців, що додає бюрократії в мої аналітичні таблиці. Будь-яка неточність у звіті могла коштувати нам лояльності великого замовника.

Я спробував впровадити напів автоматизовану систему збору даних через Notion та інтеграційні скрипти на Python. Ми витратили близько $1,200 на розробку внутрішнього плагіна, який мав би підтягувати дані з Jira прямо в наші звіти. Я особисто витратив 2 тижні на налаштування цих зв'язків та написання шаблонів для документації. Це рішення дозволило скоротити час на формування тижневого звіту з 6 годин до 2 годин. Проте система виявилася крихкою і потребувала постійної підтримки з боку наших розробників, що відволікало їх від основних задач.

Це рішення було не крутим, бо воно все одно потребувало мого постійного ручного контролю та «підчищання» даних. Скрипти часто ламалися після оновлень Jira, і мені доводилося знову повертатися до Excel у екстреному режимі. Вартість підтримки цього самописного інструменту виявилася вищою, ніж користь, яку він приносив у довгостроковій перспективі. Крім того, він не вмів генерувати якісні тексти або аналізувати складні логічні зв’язки у вимогах. Мені все одно довелося перевіряти кожне речення, щоб уникнути галюцинацій у звітах для клієнтів.