Pull to refresh

Как мы создали технологичный продукт и провалились на дно

Reading time6 min
Views40K


Хочу поделиться с вами историей хорошей жизни и долгой, медленной и мучительной смерти одного, некогда крупного, портала недвижимости. Который не был готов меняться и делать резкие движения для того, чтобы подстроится под меняющийся рынок. Продукт, который за 10 лет прошел путь от ТОП-10 до дна. Это история о важном значении той нити, которая соединяет разработчиков, с их пониманием и сладом ума, и руководителей/директоров/менеджеров со своим подходом к управлению проектом.

Начало


Я пришел на эту работу в 2014 году, простым junior .net. ПН(далее портал недвижимости) был агрегатором недвижимости, на котором помимо базы объявлений присутствовал качественный тематический новостной раздел. Новости, статьи, законы и множество различных материалов по недвижимости. Большой отдел классных журналистов писал очень крутые статьи, интерес к которым был очень высок у пользователей.

Сама площадка была бесплатной для размещения объявлений, чем привлекала пользователей (частных продавцов, агентств недвижимости). Весь доход формировался за счёт привычного в этой сфере рекламного размещения текстово-графических блоков (ТГБ) от застройщиков, продвигающих свои новостройки и ЖК.

В годы расцвета (2008 — 2012) сайт имел траффик в свыше 1 000 000 уникальных посетителей в месяц. И он давал хорошую конверсию для рекламодателей. Это были отличные показатели, учитывая, что ПН работал только на Москву и Санкт-Петербург. В штате было 2 программиста и много журналистов и редакторов. По сути все техническое обслуживание, поддержку и доработку ПН осуществляло всего 2 сотрудника (Сколько человек проектировало и разрабатывало изначально ПН история умалчивает).

На этом позитивная часть истории заканчивается.

Падение


После первой волны кризиса у сайта стали появляться проблемы с трафиком и очень серьёзные. Он просто стал падать. Рынок стал меняться и достаточно быстро. Конкуренты стали поддавливать, т.к. пока наш ПН почивал на лаврах и никуда не развивался, другие делали свои продукты более современными и отвечающими ожиданиям пользователей.

Помимо этого, поисковики стали все меньше любить наш сайт, который к слову был практически без какого либо СЕО. Да, были какие-то шаблоны для h1, title, description, небольшая перелинковка, да в целом и все (после начала падения и до самого конца руководитель ПН начал СЕО битву, которой мы занимались почти 5 лет).

При второй волне кризиса в 2014 показатели упали ниже 300 000 уникальных посетителей в месяц. Приблизительно в это время я устроился на работу.

Вот тут и начинается моя техническая часть истории.

Погружение


Первые 2 года я работал младшим разработчиком. Делал все, что мне давали. Приходилось многое узнавать с нуля. Однако мне повезло с моим руководителем разработки. Ему было чуть за 40 лет, программист старой школы, много чего знал и умел. Наверно главное его кредо, было — работает и хорошо (я очень благодарен ему, т.к. перенял много знаний и различных подходов к разработке).

Наш стек технологий был таков: MS SQL Server 2012 + ASP.NET MVC 3. База хранила в себе вообще все. Даже фотографии в бинарном виде, для 3 установленных размеров(big, large, small).

Бекэнд включал в себя несколько модулей:

  • Сайт ПН
  • Админка общего назначения
  • Админка SEO
  • Робот парсер КЛАДР
  • Робот импорта XML-фидов

Все это время я просто делал задачи, чтобы код работал и не было ошибок. Особо не вникая и не думая о дальнейшем развитии. Но пришло время и это стало необходимо.

На втором году работы, мой руководитель ушел с проекта. И я остался один на один с этой древней махиной, в которой было от силы 3% моего кода.

Это был дикий стресс. Генеральный директор спрашивал все с меня, а я иногда понятия не имел, что и как работает. Естественно жизнь заставила и постепено я вник во все процессы и понял, что тот подход “работает — хорошо” не для меня. В это время я много читал материалы по проектированию, просвещался в сфере популярных технлогий и фреймворков. Я ехал с работы домой и думал о том, что и как буду делать завтра. А когда ехал на работу думал о том, правильно ли то, что я решил вчера. Я хотел понять, как сделать все правильно и удобно. Чтобы не нужно было делать костыли, дублировать код, тестировать все на живую, деплоить все вручную и отказываться от хороших идей из-за каких-то ошибок в проектировании в прошлом.

К этому времени мы очень много сделали по SEO, забросив задачи ориентированные на улучшение UI. Однако трафик падал все ниже и ниже. И в какой-то момент проект был заморожен. Я стал занимался только поддержкой и исправлением багов… Так это звучало официально.

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

Мнимый подъем


Так, засучив рукава, я начал задуманное. Я выбрал классическую трехуровневую архитектуру. Бекэнд .Net Core+SQL+Mongo, фронтэнд — Bootstrap+JQuery+KnockoutJS.

Организовал Data-слой. Интерфейсы, абстракции, репозитории все как положено. Работал слой на хранимых процедурах (благо я довольно неплохо стал разбираться в SQL). Для маппинга выбрал Dapper. Он простой и понятный. Отказался от InMemoryCache в пользу Redis, чтобы вывести кэш на отдельный сервер. Дальше был уровень бизнес-логики. Все те же интерфейсы, сервисы, DI. Так появилась основа в виде Data-Layer (Stored Procedures+Dapper+Redis) и Logic-Layer. На все ушло около 3 месяцев.

И тут спустя почти год работы одному я добился, чтобы мне взяли помощника, настаивая на том, что задач много (а их было очень много). Вдвоем все пошло гораздо быстрее и качественнее, а главное еще более рационально.

  1. Первым делом разработали API для фотографий. Это был простой WebApi, который по Get-запросу отдавал картинку нужного качества и размера с диска. Мы перешли на SSD и забыли про базу картинок как страшный сон. Трудно описать насколько быстрее стала грузиться среднестатистическая страница сайта после выделения отдельного пула под это.
  2. Мы отказались от КЛАДРА в пользу ФИАСА. Написали качественный сервис по парсингу данных из ФИАСА к нам в базу, с учетом наших особенностей. Прикрутили к нему сервис для геокодирования домов. Все работало почти как часы. Лишь иногда возникали баги, связанные с дублями локаций или улиц в базе ФИАСА.
  3. Дальше долго писали новый личный кабинет, оделив его от сайта. Долго проектировали и планировали его, чтобы он был user-friendly. А также быстрым и функциональным. Прикрутили к нему оплату, а потом и фискализацию чеков (да, использовать готовые интегрированные решения нам были не по карману). В целом сделали хороший пользовательский сервис. И были им довольны.
  4. Наконец добрались до робота импорта XML-фидов. Сделали удобный валидатор и хорошее логгирование для клиентов. Новый сервис оказался настолько оптимизированным, что если старый (используя EF) работал около 6-8 часов, то новый обрабатывал те же объемы данных за 2-3 часа.
  5. После всего подняли домен с документацией для всего, что только есть. Разложили по полочкам все моменты для пользователей и клиентов портала, а также описали часть документации, которая пригодится и разработчикам. И это действительно важно!
  6. Последним шагом была оптимизация базы. Мы ее полностью переработали. Вычистили все лишнее. Добились ускорения скорости поиска с 4-5 секунд до ~300 мс. Создавали индексы, писали сложные запросы, использовали хинты и даже делали партиции статистических таблиц.

К сожалению, до самого сайта руки добраться не успели. Т.к. практически все задачи с сайтом были связаны с SEO, на которые уходило прилично времени. Новые страницы, новые подборки, новые правила. Больше, больше, больше страниц. Приходилось постоянно что-то править в движке сайта, что не позволяло параллельно перенести его на созданную основу.

Здесь техническая история заканчивается и начинается грустный эпилог.


Стоит начать с того, что генеральный директор сайта не был связан с IT-сферой. Поэтому очень много решений принималось им неверно и единолично. Очень часто обсуждения заходили в тупик, т.к. наши новые идеи не принимались, по причине
«Это не надо, я вам как эксперт по недвижимости говорю»
или
«Так никто не ищет, это низкочастотный запрос, я уверен»
А спустя какое-то время, когда он сам доходил до этого, наши идеи предлагались им с претензией, почему мы раньше не сказали, либо с искренним удивлением
«Я не мог так сказать, это же абсурд»
Мы никак не могли прийти к консенсусу, в результате чего, мы (разработчики) просто уступали. И делали как нас просили. Программистская боль — делать никому не нужные «фичи».



Хочется упомянуть, что и по финансам всегда были проблемы. Никаких вложений, кроме как в SEO не было. Даже держать 2 программистов это оказалось дорого. Конкурировать с новыми порталами из ТОП-10 с таким уровнем финансирования и управления, очевидно, оказалось нереально.

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

Однако никакого положительного результата это не дало. На момент моего последнего рабочего дня, несмотря на наличие 4 млн уникальных страниц в поисковиках, трафик портала колебался около 1400 уников в день. А это, как мне кажется, констатирует смерть.

P.S.: Из всей этой истории смог лично я сделал один главный вывод. Можно сделать хороший продукт с точки зрения разработчика, но он будет абсолютно не востребован, т.к. не имеет должного управления. Если та нить между сотрудниками, которая удерживает бизнес на плаву, порвана, то ваш продукт непременно пойдет ко дну.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
Total votes 67: ↑60 and ↓7+53
Comments109

Articles