SmartFlow | Аудит и автоматизация бизнеса

Сначала была идея. Потом — МФТИ. А сегодня — договор на разработку ПО.

Вчера у меня был выпускной в МФТИ. 🎓

Получила удостоверение о повышении квалификации по направлению «Бизнес-аналитик».
Но эта история началась гораздо раньше.

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

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

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

Потому что обучение, на которое я пришла с идеей собственного продукта, теперь напрямую связано с реальным коммерческим проектом.
Я училась не ради удостоверения. Я училась, чтобы мы могли создавать системы, которые задумали.

А удостоверение из МФТИ стало приятным подтверждением ещё одного пройденного этапа. 💙

#SmartFlow_Будни #SmartFlow_Аналитика

Третья версия ТЗ: от вопросов к дорожной карте

Сегодня отправляем нашему первому коммерческому заказчику третью редакцию технического задания.

За ней — несколько раундов обсуждений, подробный опросник по функциональным требованиям, ответы заказчика и lополнительные уточнения.
Почему уже третья версия?

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

Такие детали влияют не только на интерфейс, но и на структуру данных, права доступа и логику работы системы.

В новой редакции появился ещё один важный элемент — дорожная карта разработки.

Теперь мы не просто описываем, что должна уметь система, но и определяем последовательность реализации.

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

Дорожная карта связывает требования с будущими этапами разработки и помогает обеим сторонам понимать объём предстоящих работ.

При этом документ ещё не утверждён. Мы направляем его заказчику на очередной этап согласования.

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

И сегодня мы сделали ещё один шаг к этому результату.

#SmartFlow_Аналитика #SmartFlow_Практика

Простой бот или полноценная система? Разница — в требованиях

Продолжаем согласование технических заданий по двум проектам.

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

Функциональность стала компактнее. Но это по-прежнему информационная система.

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

И здесь возник интересный вопрос.

А можно ли всё это собрать на готовом конструкторе чат-ботов?

Мы проанализировали требования и подготовили для заказчика пояснительную записку.

Наш вывод: типовой конструктор сам по себе не гарантирует реализацию всего необходимого функционала.

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

А это не только стоимость разработки, но и подписки, лицензии и регулярные расходы на сопровождение.

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

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

Параллельно продолжаем согласование ТЗ с первым коммерческим заказчиком.
Получили ответы на опросник по функциональным требованиям, разбираем бизнес-правила и направили дополнительные вопросы для уточнения пользовательских сценариев.

В одном проекте пересматриваем архитектурный подход. В другом — детализируем поведение системы.

Бизнес-анализ помогает не просто определить, что нужно разработать, но и обосновать, почему выбранное решение подходит для задачи.