Рішення

Libra Data Shelf

Тип послуги:
Prototyping
Тип продукту:
IoT система
Демонстраційна розгортка продукту:
oos.sandbox.daiquiri.team
libra-data-shelf main

Навіть невеликі компанії мають прагнути вирішувати глобальні проблеми

Харчові відходи – одна з найгостріших проблем довкілля нині. За оцінками багатьох досліджень, як мінімум, шоста частина їжі, що виробляється, ніколи не буде куплена й стане відходами, а для Америки цю частку оцінюють у 40%. Харчова продукція псується на фермах, на складах і у торгових залах. Наш клієнт побачив можливість розв'язання цієї проблеми для ринка ритейлу на етапі продажу у торгових залах. Товар, що знаходиться у торговому залі може зіпсуватися, якщо порушені температурні умови зберігання. Ще він може зіпсуватися на складі, якщо його не виклали на прилавок вчасно. Наш клієнт – компанія, що виробляє розумні ваги, винайшла спосіб вирішення цієї проблеми. Гіпотеза нашого клієнта полягала в наступному:

Daiquiri: Libra Data Shelf description Daiquiri: Libra Data Shelf description

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

Трохи подробиць про ринок клієнтів нашого клієнта

Поставлені цілі продукту

Independent real estate agent

Продукт має виконувати свою основну задачу: оптимізувати роботу мерчендайзерів у торговому залі. Результативність роботи мерчендайзера має оцінюватись за допомогою метрик всередині продукту.

Employee of a real estate agency

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

The owner of a real estate agency

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

Саме формалізація цілей допомогла нам знайти причинно-наслідкові зв'язки між інтересами нашого клієнта і описом вимог. Наприклад, в описі вимог клієнта були аналітичні модулі, призначення яких не було для нас вповні зрозумілим. В процесі уточнення цілей ми зрозуміли, яким чином аналітика може допомогти визначати проблеми на рівні торговельної мережі чи торговельної точки. Маючи цю інформацію ми перейшли на технічний рівень планування і почали працювати з прикладними задачами продукту.

Daiquiri: Libra Data Shelf test report

User flow та технічні нюанси продукту

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

В житті трапляється все що завгодно і ми не завжди можемо довіряти отриманим даним. Тому ми маємо продумати сценарії обробки неправдоподібних і некоректних даних.

Що ми робимо, якщо продавець чи покупець спирається рукою на полицю, як ігнорувати подібні ситуації?

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

Як перевірити, що полиця встановлена правильно?

Такі питання варто вирішувати заздалегідь, щоби під час проведення тесту на торговельній точці не виникло несподіванок.

Яка оптимальна структура оповіщення мерчендайзера, щоби він правильно зрозумів, що треба зробити?

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

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

Перше суттєве технічне питання – hardware розумних полиць. Ми узнали які це полиці, визначили як полиця буде ідентифікуватися у системі, у якому вигляді вони будуть доставляти інформацію. Полиці відправляють інформацію по HTTPS у форматі CSV, а ідентифікувати ми їх можемо за серійним номером. Ми продумали як забезпечити максимально простий процес встановлення нової полиці, не створюючи загрози безпеці системи. У кожну полицю вшивається безпечний ключ системи, що буде передаватися при кожному запиті від полиці.

Наступним кроком була формалізація вимог до інтерфейсів системи. Ми обрали набір рівнів доступу, зафіксували права для кожної ролі. Мерчендайзеру, наприклад, взагалі не потрібний доступ до веб-застосунку, достатньо дати йому доступ до боту у месенджері. Директор магазину бачить тільки свій магазин, адміністратор мережі магазинів має доступ до даних усіх магазинів, а адміністратор системи має доступ до всіх даних.

Independent real estate agent

Після цього ми визначили формули для обчислення кожної метрики. В ряді випадків це було не зовсім очевидно. Якщо «хибні тривоги» будуть приходити мерчендайзеру занадто часто, він почне залишати їх поза увагою. Кількість одиниць товару, що знято з полиці, має обраховуватись системою максимально точно, інакше на неї не можна буде покладатися. Те саме стосується відсотку часу, коли полиця перебувала в порушеному температурному режимі.

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

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

Найважливішим є те, що продукт дійсно зміг створити оптимальні умови для тестування гіпотези нашого клієнта. Ми отримали високу оцінку результату нашої роботи. Клієнт не мав проблем при роботі з продуктом протягом року після завершення робіт. В підсумку, ми переконались, що створили абсолютно viable продукт для тестування гіпотези. Підтримуючи контакт з клієнтом після завершення роботи ми узнали, що продукт успішно тестується у великому супермаркеті у Києві, показники ефективності виглядають багатообіцяючими. А ми будемо раді розвивати продукт у подальшому.

Daiquiri: want start project?

Ми втілимо ваші ідеї в життя!
Бажаєте почати проєкт?