Почему для админ панели достаточно концепта на старте?
Современный интернет все активнее отходит от шаблонных решений, в пользу индивидуальных продуктов построенных на модульной основе. Данная статья не про минусы дешевых сайтов на конструкторах, а про то, что делать с акцентами при создании нового веб- или моб- приложения. Чаще всего, работа разбивается на три больших блока:
- Интерфейсное представление
- Сервер с базой данных
- Административная панель
Многим, поначалу кажется, что нужно сделать как можно больше функционала, в том числе для последнего, управляющего блока. И, если совместно с опытными специалистами действительно удается подобрать хорошие решения на пользовательской части, то вот для администрации и менеджеров, это часто превращается в подход:
Запихните туда побольше статистики, графиков и цифр
Как итог, ни клиент, ни его персонал практически туда не заходят, ведь обширный функционал требует серьезного погружения. Более того, из этого вытекает следующая проблема: отслеживающая система перестает развиваться. Для любого цифрового продукта, важно работать эффективно. Если на сам сайт или приложение, начинают жаловаться покупатели, то обратную связь легко применить на практике. Но, что делать с тем фрагментом, который с годами деградирует. Можно продолжать пичкать тех. поддержку заданиями выводить еще больше сводок, а можно поступить иначе.
Личная рекомендация заключается в том, что на старте достаточно вполне общих таблиц:
- Пользователи системы
- Роли
- Продукт (который продается)
- Финансовые метрики (если у вас есть продажи)
- Разделы для тех. специалистов (логи, настройки, прочее)
Всего этого более чем хватит на первый этап работы с ПО. Далее, система должна поработать. Она должна показать себя на реальной практике, отразить слабые места и потребности. Если этого не замечает сам клиент, это быстро заметит саппорт, что будет работать с админкой.
Куда проще добавить какой-то новый функционал, чем перебирать старый, оптимизируя его или вообще отказываясь от каких-то решений. Порой, они бывают громоздкими и недостаточно просто “скрыть блок”, ведь за ним тянется целая цепочка нагрузки.
Качественное исполнение административного инструмента, ничуть не менее, а порой и куда важнее, чем приятная обертка вашего продукта.
Приведу свежий пример из недавнего:
Из платежной системы Stripe синхронизируются продукты для оплаты подписок пользователями. При этом, в самой админ панели, есть внутренний список подписок, который привязывается к существующим из Stripe (сложность внутренней архитектуры требует такого решения). Это работает так. Директор создает продукт из панели платежки, а после кто-то из персонала должен зайти в админку, чтобы подвязать ее к продукту. Но его менеджера игнорировали это требование. В итоге, приходит покупатель, приобретает полный комплект за 50$, а у себя в приложении не видит изменений (ему не открывается доступ к приватному функционалу, так как не видит платежа).
Нами была выявлена эта проблема и предложено решение - создание системы оповещения, для принятия важных решений в подобных ситуациях. После ее внедрения, проблема не повторялась.
В рамках отдельной публикации я опишут опыт запуска успешных приложений (речь о тех, что выполнялись нашей командой под заказ). Но в общих чертах - быстрый старт и постепенное масштабирование, с улавливанием потребностей, в десятки раз эффективнее, чем подход “все и сразу”.
Считаете пост полезным? Поделитесь им в соц сетях:
Читайте также:
