Розробка додатків

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

Звичайний сайт однаковий для всіх відвідувачів: та сама сторінка, той самий текст. У сервісі в людини є свій вхід — логін і пароль, — і після входу вона бачить те, що стосується тільки її: свої замовлення, свій залишок, свої документи. Це і є «особистий кабінет».

Приклад із життя: прокат інструменту. Клієнт заходить у кабінет, бачить, що в нього на руках перфоратор, до якої дати оплачено, коли повертати, і продовжує оренду сам — без дзвінка менеджеру. Компанія при цьому бачить усі видачі в одному списку, а не в зошиті.

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

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

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

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

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

Найбільше питань не в каталозі, а в грошах. Треба заздалегідь вирішити: комісія береться з кожного замовлення чи за розміщення, коли продавець отримує виплату й хто повертає гроші за брак. Ці правила ми фіксуємо до початку роботи — переробляти їх потім найдорожче.

• кабінет продавця: товари, залишки, свої замовлення
• перевірка нових товарів перед публікацією
• підрахунок комісії та звіт про виплати продавцям
• відгуки й рейтинг, щоб покупець бачив, кому довіряти

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

Перед розробкою випишіть на одному аркуші, за що саме ви берете гроші й у який момент. Якщо це вкладається в кілька рядків — модель робоча; якщо ні, її варто додумати.

Коли процес живе в таблицях і переписці, програма робить те саме, але без ручного перенесення даних і без загублених повідомлень.

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

У програмі та сама заявка існує один раз. У неї є статус, відповідальний і вся історія: хто прийняв, хто передав далі, коли закрили. Дані вводяться один раз і одразу видно всім, кому треба, — кожен бачить свою частину роботи.

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

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

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

Це програма не для клієнтів, а для своїх, і оцінюють її не за красою, а за тим, скільки дій займає щоденна операція.

Різниця з публічним сервісом суттєва. Користувачів мало, вони відомі поіменно, їх можна навчити особисто — тому не треба вилизувати кожен екран. Зате вони працюють у програмі щодня по кілька годин, і будь-яка дрібна незручність множиться на сотні повторів.

Готова CRM підходить, поки ваш процес схожий на всі інші: дзвінок, угода, оплата. Своя система потрібна там, де є специфіка, яку нікуди вписати: розкрій матеріалу з залишками, облік змін на виробництві, партії з різними термінами придатності. Замість того щоб ламати процес під чужу програму, робимо програму під процес.

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

Часта помилка — замовляти такий інструмент за описом з кабінету керівника. Виходить логічно на папері й незручно в роботі. Тому ми питаємо саме тих, хто робитиме це щодня: як зараз виглядає їхній день і на що йде найбільше часу.

Перед тим як замовляти, посидьте годину поруч із людиною, яка веде цей облік руками, і запишіть кожну її дію. Цей аркуш і стане основою технічного завдання.

Інтеграція — це коли дві програми домовляються між собою самі, без людини, яка переносить цифри з одного вікна в інше.

У більшості програм є службове вікно для обміну даними — його називають API. Простими словами: одна програма звертається до іншої й питає «дай залишки по цьому товару» або каже «прийми нове замовлення», а та відповідає. Людина в цьому обміні не бере участі взагалі.

Виглядає це так: клієнт оформив замовлення в додатку — воно за секунду з’явилось у CRM менеджера, товар зарезервувався в обліку, після оплати картка списала гроші, а служба доставки віддала номер накладної, і клієнт бачить його в себе в кабінеті. Раніше кожен із цих кроків хтось робив руками.

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

Чесно про межі можливого: ми обмежені тим, що чужий сервіс дозволяє віддавати. Якщо в системи такого службового вікна немає взагалі, обмін доводиться робити через файли за розкладом: дані оновлюються не миттєво, а раз на годину або на день.

Зовнішні сервіси час від часу змінюють правила обміну, тому інтеграції потребують догляду. Перед оцінкою запитайте у постачальників ваших систем, чи є в них API і документація, — від цього залежить обсяг роботи.

Коли продукту ще немає на ринку, завдання першої версії — не вразити функціями, а перевірити, чи потрібне це людям узагалі.

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

Тому першою робимо найпростішу працездатну версію: одна головна дія, доведена до кінця, і нічого зайвого навколо. Її показують реальним людям і дивляться, чи повертаються вони вдруге. Це набагато дешевше, ніж рік розробки за повним списком побажань.

• одна головна дія в першій версії, решта — потім
• частину операцій на старті можна робити руками
• збір відгуків перших користувачів із самого початку
• логіка, яку можна швидко змінити після перевірки

Приклад: сервіс доставки домашніх обідів. У першій версії достатньо, щоб людина обрала меню й залишила замовлення, а маршрути кур’єрів диспетчер поки складає вручну. Якщо замовлення пішли — маршрути автоматизуємо. Якщо ні — ви не заплатили за складну логістику, яка нікому не знадобилась.

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