Разработка приложений

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

Обычный сайт одинаков для всех посетителей: та же страница, тот же текст. В сервисе у человека есть свой вход — логин и пароль, — и после входа он видит то, что касается только его: свои заказы, свой остаток, свои документы. Это и есть «личный кабинет».

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

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

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

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

Маркетплейс отличается от магазина главным: товар продаёте не вы, а сторонние продавцы, а ваша задача — правила площадки и расчёты между всеми.

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

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

• кабинет продавца: товары, остатки, свои заказы
• проверка новых товаров перед публикацией
• подсчёт комиссии и отчёт о выплатах продавцам
• отзывы и рейтинг, чтобы покупатель видел, кому доверять

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

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

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

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

В программе та же заявка существует один раз. У неё есть статус, ответственный и вся история: кто принял, кто передал дальше, когда закрыли. Данные вводятся один раз и сразу видны всем, кому нужно, — каждый видит свою часть работы.

• один общий список заявок вместо файлов у каждого
• статус и ответственный на каждом этапе
• напоминания о сроках, которые приходят сами
• отчёт за период без ручного сведения таблиц

Автоматизировать всё сразу не стоит. Берём один процесс — тот, из-за которого чаще всего возникают накладки, — и переносим в программу его. Дальше становится видно, что делать следующим, и каждый шаг окупается отдельно, а не в конце большого проекта.

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

Это программа не для клиентов, а для своих, и оценивают её не по красоте, а по тому, сколько действий занимает ежедневная операция.

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

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

• учёт того, что не помещается в готовую CRM
• права доступа по должностям: кто что видит и меняет
• журнал изменений — видно, кто и когда правил запись
• выгрузка данных в файл для бухгалтерии или отчёта

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

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

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

У большинства программ есть служебное окно для обмена данными — его называют API. Простыми словами: одна программа обращается к другой и спрашивает «дай остатки по этому товару» или говорит «прими новый заказ», а та отвечает. Человек в этом обмене не участвует вообще.

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

• заказ из приложения сразу попадает в CRM
• цены и остатки подтягиваются из программы учёта
• оплата картой и автоматический статус платежа
• накладная службы доставки и отслеживание посылки

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

Внешние сервисы время от времени меняют правила обмена, поэтому интеграции требуют присмотра. Перед оценкой спросите у поставщиков ваших систем, есть ли у них API и документация, — от этого зависит объём работы.

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

Здесь главное отличие от автоматизации действующего бизнеса. Там процесс уже существует, и надо лишь перенести его в программу. В новом продукте всё наоборот: есть предположение, что люди захотят этим пользоваться, и пока им не воспользовались — это лишь предположение.

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

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

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

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