Как мы читали мысли клиента и делали сервис бизнес-отчетов с chatGPT почти без ТЗ

Мы в Purrweb любим непростые задачи. Даже если дедлайны поджимают с самого старта, а бизнес-логику нужно продумывать на свое усмотрение. Рассказываем, как мы для клиента создали с нуля сервис, который сильно облегчит жизнь крупным компаниям.

В ноябре 2022 к нам пришел постоянный клиент — он создает инновационные бизнесы в IT. С ним мы делали уже четыре проекта. Один из них — эко-приложение, которое рассчитывает углеродный след компаний и помогает его компенсировать.

Идея для нового проекта — приложение для крупного бизнеса. Оно помогает заполнять ежегодные нефинансовые отчеты. С их помощью компании показывают, что не вредят природе, берут на работу достаточно женщин и не обижают сотрудников. В Европе и многих других странах мира это нужно делать, чтобы получить очки репутации и привлечь инвесторов. Отчеты бывают разного стандарта, но для старта проекта заказчик выбрал один из самых популярных — GRI (Global Reporting Initiative), или Глобальную инициативу отчётности. После релиза договорились реализовать и другие стандарты.

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

Решение от клиента — создать сервис, который поможет писать отчеты проще, быстрее и в веб-формате. Вот почему это круто:

Как мы читали мысли клиента и делали сервис бизнес-отчетов с chatGPT почти без ТЗ

Это значит, что нам в Purrweb нужно было:

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

Закончить работу нужно было до марта 2023 — за 4 месяца. Мы провели оценку и поняли, что уложимся только к маю — за 6 месяцев.

Это плохо: в марте компании уже начинают заполнять отчеты, поэтому к концу весны сервис может не выстрелить.
Чтобы ускориться, предложили заказчику увеличить команду и бюджет — он согласился. Но это было только начало.

Обычно мы в Purrweb работаем по гибкой методологии SCRUM, то есть короткими спринтами по 2 недели. На каждом этапе реализуем кусочек проекта, показываем заказчику, согласовываем и двигаемся дальше.

Мы выбрали SCRUM, потому что он выгоден и для заказчика, и для команды:

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

В 90% случаев этот подход — идеальное решение для работы на проектах. Но бывают ситуации, когда SCRUM не получается применить полностью. Так было в этот раз.

Из-за сжатых сроков и абстрактных задач мы не могли создавать проект по кусочкам. Чтобы успеть, делали всё разом: дизайн, фронтенд и бэкенд. Из-за этого к концу спринта, через 2 недели, поначалу было нечего показать — всё было в процессе, тестировалось, дорабатывалось.

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

Чтобы успевать в срок и по возможности оставаться гибкими, мы внедрили принцип contract first. Так называется подход, когда бэкендеры заранее описывают фронтендерам структуру данных, которая будет передаваться между фронтендом и бэкендом. В итоге разработчикам не нужно ждать друг друга, прежде чем приступить к своей части работы.

<p>Когда бэкендеры не общаются с фронтендерами и работают автономно</p>

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

Мы увидели в прототипе клиента основной флоу: отчет состоит из нескольких частей с вопросами, с каждой из них можно работать отдельно. Все блоки имеют свой статус: например, «отвеченный», «не отвеченный» или «одобренный». Благодаря этому удобно двигаться по отчету, не боясь, что пропустишь и не ответишь на какой-нибудь вопрос — и в итоге весь отчет будет недействительным.

<p>Так выглядел прототип от клиента. Дизайн максимально упрощенный, но с ходу понятно, какие основные функции должны быть в сервисе</p>

Дальше работали над дизайном самостоятельно, практически не задавая вопросов заказчику. Мы были его автономной командой, с большой свободой действий и минимумом звонков и согласований. На презентации результатов получали не критику, а ёмкое и доброжелательное: «Красиво, полетели дальше!».

Единственное, чтобы попасть в ожидания клиента и не тратить время на переделывание, попросили у него побольше референсов — что нравится, что не очень. Клиент привел в примеры такие сайты, как Metrio и Vanta: у них чистый, простой и не перегруженный интерфейс. Мы учли их в работе.

<p>Один из референсов — сайт Metrio. Клиенту понравился чистый интерфейс в стиле Google, выдержанные цвета и современные элементы</p>

Добавили акцентные цвета для навигации по сервису. В основе дизайна — оттенки серого, которые занимают 60% от всей палитры в проекте. Ими мы подчеркнули разные области на странице. Акценты выделили контрастными оттенками, которые поддерживают друг друга визуально: 30% синего, по 10% желтого, зеленого, красного и оранжевого в интерфейсе.

<p>Это инфопанель в проекте. Мы добавили контрастную цветовую навигацию, чтобы было легче с ходу разобраться, что к чему. Синим отмечены черновики ответов, желтым — ждущие подтверждения, зеленым — одобренные. Серым цветом указали на вопросы без ответа.</p>

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

Мы знаем, что дизайн по визуалу не выглядит вау — оттенками серого трудно кого-то впечатлить. Но такой задачи перед нами и не стояло.

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

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

<p>Слева — вся необходимая информация об отчете, справа — история изменений. Внизу — стрелки, чтобы перемещаться между отчетами</p>

Важно, чтобы заполнять отчеты в сервисе было намного удобнее, чем вручную в PDF — иначе теряется весь смысл проекта. Заказчик попросил, чтобы мы создали несколько ролей в интерфейсе — это дает полный контроль в работе над отчетами, по сравнению с вариантом «по старинке».

Мы докрутили идею и выделили следующие роли:

администратор — пользователь с полным доступом к сервису. Например, это может быть гендиректор компании. Он назначает ответственных на другие роли, приглашает их присоединиться по ссылке и следит за общим процессом.
контрибьютер (contributor) — пишет ответы на вопросы в отчете, оставляет комментарии, редактирует текст. Эта роль — для тех, кто непосредственно работает над отчетом.
вьюер (viewer) — может просматривать ответы на вопросы, но не имеет права их изменять. Роль хорошо подходит для сотрудников, которые не пишут отчеты, но должны быть в курсе дела.

Заказчик сначала захотел, чтобы была роль аппрувера (approver). Этот человек должен был принимать решение, одобрить ответ на вопрос или отправить на доработку. Но мы проработали вопрос с нашим системным аналитиком и отговорили от этого решения. По сути, модерация — это единственная функция аппрувера. Вместо этого было достаточно дать такому человеку доступ к роли администратора, чтобы он мог также комментировать и редактировать отчеты.

Так мы сэкономили клиенту часы на разработку и дизайн четвертой роли.

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

<p>Так выглядит разделение на роли внутри приложения. По кнопке Invite teammate можно получить специальную ссылку для приглашения нового сотрудника</p>

Когда мы приступили к разработке, задачи от заказчика стали еще более абстрактными.

Клиенту было достаточно сказать: «Хочу вкладку с подсказками по заполнению отчетов» — а мы уже решали, как именно это реализовать. Мы как-то рассказывали про заказчиков-микроменеджеров — так вот, здесь всё было ровно наоборот. Нам дали полную свободу действий и оценивали только результат, без погружения в процесс.

Чтобы процесс шел быстрее, мы сами определили, в каком порядке будем пилить функции, что самое срочное и важное. Затем только согласовали этот план с заказчиком — и полетели в разработку.

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

Кроме того, мы отговорили заказчика от сомнительного решения — давать ссылку на скачивание всех официальных рекомендаций по заполнению отчета в pdf-формате. Мы пообщались с нашим системным аналитиком и нашли более удобное и нативное решение.

Вместо скачивания предложили, чтобы справа прямо в интерфейсе был образец ответа на вопрос из отчета. Это оказалось непросто: пришлось найти примеры под каждый случай в документации GRI на 800 страниц. Наш системный аналитик собирал все эти данные в .csf файл, а затем мы написали скрипт — чтобы все образцы ответов автоматически попадали в базу данных к нужным вопросам.

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

Суть интеграции с chatGPT — в том, что нейросеть помогает заполнять ответы на вопросы в отчете. Прямо в окне с отчетом есть чат, куда можно написать любой запрос. Например: «Напиши информацию для этого блока, вот данные нашей компании, которые нужно туда подставить». Нейросеть проанализирует запрос и выдаст информацию — останется только отредактировать ее и вставить в поле с ответом.

<p>Так выглядит чат с chatGPT в сервисе для нефинансовых отчетов</p>

Мы интегрировали модель GPT-4, так как она работает быстрее и генерирует ответы лучше, чем, например, Davinchi, который мы использовали ранее. Помимо очевидной интеграции, добавили свою фишку — вместе с запросом от пользователя chatGPT получает дополнительную информацию. Это помогает нейросети отвечать на вопрос точнее, даже если клиент сервиса дал мало деталей.

Лучше всего объяснить это на схеме:

Проект ушел в продакшн четко в срок — в начале марта 2023. Всего мы потратили на дизайн и разработку 4 месяца, как и обещали. Сейчас заказчик показывает проект своим клиентам на продажу, а мы параллельно реализуем побочные функции.

Получилось создать простое приложение на очень сложную тему — проработать флоу нефинансовых отчетов, создать простой дизайн и понятный интерфейс. Формат работы был для нас не самым привычным: мы привыкли работать по спринтам и закрывать задачи каждые 2 недели, а не одну глобальную — за 4 месяца. Тем не менее, смогли адаптироваться под требования заказчика и соблюсти все договоренности.

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

Недавно мы рассказывали про разработку IPTV-приложения, а чуть раньше — о разработке крипто-кошелька. В этих проектах мы использовали SCRUM и Agile, чтобы быть гибкими, успевать по срокам и адаптироваться к любым изменениям прямо в полете.

Подписывайтесь на наш ТГ-канал — там много полезного контента для стартаперов.