Booklet
Estate

Перший досвід розробки власного продукту

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

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

Booklet Estate став нашим першим власним продуктом. Ми обрали в якості ніші нерухомість, бо у цій сфері мали доменну експертизу завдяки нашій попередній співпраці у цій царині. Кращий спосіб зрозуміти проблеми наших клієнтів – поставити себе на їх місце. Як кожний підприємець, ми сформували першу концепцію продукту і спробували визначити чи дійсно він розв'яже проблему користувачів. Ми зробили орієнтовний P&L й переконались, що продукт буде рентабельним. Моделлю монетизації була вибрана передплата з тріал-періодом.

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

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

Приклади питань, відповіді на які ми шукали.

Цілі продукту

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

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

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

• 

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

• 

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

• 

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

• 

  В тріал-період користувач звикає до продукту і може вбудувати його в свій бізнес-процес.

• 

  Продукт є стійким до помилок користувача і проблем на джерелах даних. Посилання на сторінку об'єкта на публічному сайті можна скопіювати неправильно, а самі сайти можуть бути недоступними або сторінка може бути видалена.

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

Приклади проблем з прийняттям рішень

Розгляньмо сторінку з даними об'єкту нерухомості, отриманими з сайту. Ось наші міркування після визначення списку полів об'єкту нерухомості:

Структура презентації передбачає кілька відображень фото з приблизно однаковим співвідношенням сторін усіх зображень. Користувацькі фото часто бувають різними у цьому сенсі.

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

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

• Чи повідомляти користувача, що його опис є занадто довгим? А що йому порадити, якщо скоротити описання не можна?
• Чи можна вирізати якийсь малозмістовний текст з даних джерел? Наприклад, інформацію про автора оголошення на сайті?
• Можливо, варто змінювати у презентації розмір шрифту на дрібніший у цьому місці? Наскільки зручно тоді буде його читати, і якщо так, то до якого кегля можна зменшувати? І як обраховувати з тексту розмір кегля для PDF?

Валідація даних

• Чи варто повідомляти користувача, якщо у полі «Ціна» опинилося не число? Чи треба нам мати ці дані у числовому форматі для якоїсь аналітики?
• Деякі поля за дизайном презентації можуть містити довгий текст. Чи варто повідомляти користувачеві про це, чи проблемних випадків буде мало?
• Заголовок презентації: можна брати з заголовку сторінки (але прийдеться вирізати префікси на кшталт «Здам квартиру»), можна синтезувати самостійно, об'єднуючи важливі характеристики (тип об'єкту, площа, вулиця), можна для кожного джерела шукати потрібні дані. Як переконатися в якості для цільового користувача?

User flow головної сторінки

Технічні питання ми вирішили більш успішно. Стек для back-end був обраний звичним – Python в якості мови програмування, django для API, asyncio для збирання даних. Тоді ми не мали досвіду у сучасних фреймворках, тому задачі front-end ми вирішили на jQuery з кількома open-source рішеннями. Деякі задачі дали нам новий досвід. Наприклад, тестуючи платіжний агрегатор, ми зрозуміли, що варто одразу підключити ще один, адже деякі платіжні інструменти можуть бути недоступними навіть у перших гравців цього ринку. Таким чином ми надали нашим користувачам максимальну кількість способів здійснити передплату.

Нарешті, головна сторінка пройшла тестування цільовою аудиторією (fake landing page), тур по сервісу протестований до дрібниць на всіх браузерах і пристроях, що підтримуються. Отримання даних по усіх сайтах працює стабільно, дизайн презентації оцінений нашими клієнтами як достойний. Платіжні системи прив'язані, юридичні питання вирішені, ліди зібрані і ми готові відкривати сервіс у публічний доступ.

Завдяки досвіду BookletEstate ми стали набагато краще розуміти власників бізнесів та C-level компаній наших клієнтів. Ми продовжуємо розвивати BookletEstate. Через два роки після запуску ми плануємо новий реліз з розширенням функціоналу та новим дизайном. Ми плануємо створювати свої продукти і в подальшому.