Це один з найбільших проєктів у моїй практиці. На старті він виглядав як збір оголошень по парі міст, а виріс у систему по всіх великих містах країни з фото і моніторингом новинок по районах. Розповім, як вона влаштована, і про те, як правильно оцінювати такі задачі, щоб масштаб не став сюрпризом ні для замовника, ні для виконавця.
Задача
Клієнту потрібен був збір даних про нерухомість з великого українського порталу оголошень по кількох містах. Дані потрібні регулярно, з щоденним оновленням, з віддачею окремого файлу по кожному місту.
На старті йшлося про пару міст. Потім список розширився на всі великі міста України. Далі додалися фото, потім – постійний моніторинг нових оголошень.
Що найчастіше недооцінюють у таких проєктах
Масштаб. Одне місто і двадцять міст – це не різниця в двадцять разів за часом розробки, але це принципово інша задача за інфраструктурою: обсяг даних, час обходу, зберігання, паралельність, відновлення після збоїв.
Складність за першою сторінкою. Видача виглядає простою, дані дістаються. Але складність не у видачі, а в обсязі, у різноманітті типів оголошень і в тому, що дані треба тримати консистентними день у день.
Зміни джерела. Портал живий, він міняється. Довга робота з ним означає кілька суттєвих переробок, і це треба закладати з самого початку.
Поступове розширення. Міста додаються по одному, кожне окремо здається дрібницею. У сумі виходить зовсім інший проєкт.
Як правильно оцінювати такі задачі
- Оцінювати інфраструктуру, а не парсинг. Витягнути поля зі сторінки – найпростіша частина. Складне – зберігання, розклад, консистентність і відновлення.
- Питати про плани зростання до старту. Питання “а скільки міст може стати через пів року” коштує нуль, а економить тижні.
- Фіксувати обсяг у домовленості. Не для того щоб відмовляти в розширенні, а щоб розширення було приводом переглянути умови.
- Доводити до стабільної роботи. Система, яка працює щодня роками, важливіша за швидкий старт.
Саме так і цей проєкт доведений до стабільної роботи і розвивається далі.
Як влаштована система
Збір по містах
Кожне місто обробляється окремо. Це дозволяє додавати нові міста без переробки, паралелити роботу і не втрачати все, якщо на одному місті стався збій.
Щоденне оновлення
Раз на добу дані оновлюються повністю. Оголошення про нерухомість живуть довше за автомобільні, але й тут щоденний зріз – розумний мінімум.
Віддача файлами по кожному місту
Результат – окремий файл на місто, за постійним посиланням. Клієнт забирає те, що йому потрібно, і не тягне зайве.
Фото
Фото додалися пізніше і помітно ускладнили задачу: це вже не текст, а великий обсяг файлів, які треба скачати, перевірити, зберегти і віддати. Обробка зображень майже завжди недооцінюється при оцінці проєкту.
Продовження: моніторинг по районах
Згодом до збору додався моніторинг нових оголошень з поділом по районах. Під кожен район створена окрема група в Telegram, і туди додані ріелтори, які працюють саме з цим районом.
Логіка ринку тут проста і жорстка: хто перший зателефонував за новим оголошенням, той і працює з об’єктом. Різниця в п’ятнадцять хвилин вирішує, чиїм буде клієнт.
Чому поділ саме по районах:
- ріелтор працює зі своєю територією, чужі оголошення для нього шум;
- у загальному чаті на сотні повідомлень на день своє знайти неможливо;
- керівник сам розподіляє людей по групах;
- кількість повідомлень у групі лишається такою, що їх реально читають.
Це той самий принцип, що і в моніторингу постачальників: сповіщення має бути релевантним конкретній людині, інакше його вимкнуть.
Технічні особливості нерухомості
Дублі
Один об’єкт виставляють кілька агентств одночасно, іноді з різними фото і цінами. Без дедублікації ріелтори отримають п’ять сповіщень про одну квартиру.
Оновлення замість нових
Знижена ціна в старому оголошенні – це подія не менш важлива за нове оголошення. Систему треба вчити відрізняти справді нове від відредагованого.
Обсяг
Усі великі міста разом – це серйозний обсяг щодня. Тут потрібне не тільки зберігання, а й акуратна робота з джерелом: рівний темп, без піків.
Кому це підійде
- агентствам нерухомості, які працюють з первинним потоком оголошень;
- інвесторам, що шукають об’єкти за критеріями;
- аналітикам ринку, яким потрібна історія цін по районах;
- сервісам, що агрегують оголошення.
Якщо вам потрібні дані з порталів нерухомості, найважливіше питання на старті – обсяг і плани зростання. Скажіть чесно, скільки міст або районів може знадобитися через рік. Це головна річ, яка визначає і конструкцію, і ціну.
Що спитати у виконавця до старту
Щоб масштаб і вартість не стали сюрпризом, ось список питань, які варто поставити виконавцю до старту.
- Де це працюватиме. Свій сервер, ваш сервер, чийсь комп’ютер. Від відповіді залежить, чи переживе проєкт відпустку виконавця.
- Що станеться, коли сайт зміниться. Це не “якщо”, а “коли”. У відповіді має бути порядок дій і строк реакції.
- Як ви дізнаєтеся про збій. Якщо ніяк – значить дізнаєтеся від співробітників через тиждень.
- Чи зберігається історія. Дані, які не зберігали з початку, потім не відновити.
- Що входить у щомісячний платіж. Тільки робота сервера чи ще й адаптація парсера під зміни джерела.
Якщо на ці п’ять питань є прямі відповіді, проєкт із великою ймовірністю проживе роки. Якщо відповіді розмиті, це буде разова робота незалежно від того, як її назвали в домовленості.