Почему для админ панели достаточно концепта на старте?

Администратор • 28 Мая 2023в16:59

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

  • Интерфейсное представление
  • Сервер с базой данных
  • Административная панель

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

Запихните туда побольше статистики, графиков и цифр

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

Личная рекомендация заключается в том, что на старте достаточно вполне общих таблиц:

  • Пользователи системы
  • Роли
  • Продукт (который продается)
  • Финансовые метрики (если у вас есть продажи)
  • Разделы для тех. специалистов (логи, настройки, прочее)

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

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

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

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

Приведу свежий пример из недавнего: 

Из платежной системы Stripe синхронизируются продукты для оплаты подписок пользователями. При этом, в самой админ панели, есть внутренний список подписок, который привязывается к существующим из Stripe (сложность внутренней архитектуры требует такого решения). Это работает так. Директор создает продукт из панели платежки, а после кто-то из персонала должен зайти в админку, чтобы подвязать ее к продукту. Но его менеджера игнорировали это требование. В итоге, приходит покупатель, приобретает полный комплект за 50$, а у себя в приложении не видит изменений (ему не открывается доступ к приватному функционалу, так как не видит платежа). 

Нами была выявлена эта проблема и предложено решение - создание системы оповещения, для принятия важных решений в подобных ситуациях. После ее внедрения, проблема не повторялась. 

В рамках отдельной публикации я опишут опыт запуска успешных приложений (речь о тех, что выполнялись нашей командой под заказ). Но в общих чертах - быстрый старт и постепенное масштабирование, с улавливанием потребностей, в десятки раз эффективнее, чем подход “все и сразу”. 

Считаете пост полезным? Поделитесь им в соц сетях:

Читайте также:

Глобальный сбой Яндекс.Метрики - пропала вся статистика Обязательные инструменты для вашего сайта в 2023 году Планы по развитию CyFe на 2023 год