Хочу поделиться с вами историей хорошей жизни и долгой, медленной и мучительной смерти одного, некогда крупного, портала недвижимости. Который не был готов меняться и делать резкие движения для того, чтобы подстроится под меняющийся рынок. Продукт, который за 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 месяцев.
И тут спустя почти год работы одному я добился, чтобы мне взяли помощника, настаивая на том, что задач много (а их было очень много). Вдвоем все пошло гораздо быстрее и качественнее, а главное еще более рационально.
- Первым делом разработали API для фотографий. Это был простой WebApi, который по Get-запросу отдавал картинку нужного качества и размера с диска. Мы перешли на SSD и забыли про базу картинок как страшный сон. Трудно описать насколько быстрее стала грузиться среднестатистическая страница сайта после выделения отдельного пула под это.
- Мы отказались от КЛАДРА в пользу ФИАСА. Написали качественный сервис по парсингу данных из ФИАСА к нам в базу, с учетом наших особенностей. Прикрутили к нему сервис для геокодирования домов. Все работало почти как часы. Лишь иногда возникали баги, связанные с дублями локаций или улиц в базе ФИАСА.
- Дальше долго писали новый личный кабинет, оделив его от сайта. Долго проектировали и планировали его, чтобы он был user-friendly. А также быстрым и функциональным. Прикрутили к нему оплату, а потом и фискализацию чеков (да, использовать готовые интегрированные решения нам были не по карману). В целом сделали хороший пользовательский сервис. И были им довольны.
- Наконец добрались до робота импорта XML-фидов. Сделали удобный валидатор и хорошее логгирование для клиентов. Новый сервис оказался настолько оптимизированным, что если старый (используя EF) работал около 6-8 часов, то новый обрабатывал те же объемы данных за 2-3 часа.
- После всего подняли домен с документацией для всего, что только есть. Разложили по полочкам все моменты для пользователей и клиентов портала, а также описали часть документации, которая пригодится и разработчикам. И это действительно важно!
- Последним шагом была оптимизация базы. Мы ее полностью переработали. Вычистили все лишнее. Добились ускорения скорости поиска с 4-5 секунд до ~300 мс. Создавали индексы, писали сложные запросы, использовали хинты и даже делали партиции статистических таблиц.
К сожалению, до самого сайта руки добраться не успели. Т.к. практически все задачи с сайтом были связаны с SEO, на которые уходило прилично времени. Новые страницы, новые подборки, новые правила. Больше, больше, больше страниц. Приходилось постоянно что-то править в движке сайта, что не позволяло параллельно перенести его на созданную основу.
Здесь техническая история заканчивается и начинается грустный эпилог.
Стоит начать с того, что генеральный директор сайта не был связан с IT-сферой. Поэтому очень много решений принималось им неверно и единолично. Очень часто обсуждения заходили в тупик, т.к. наши новые идеи не принимались, по причине
«Это не надо, я вам как эксперт по недвижимости говорю»или
«Так никто не ищет, это низкочастотный запрос, я уверен»А спустя какое-то время, когда он сам доходил до этого, наши идеи предлагались им с претензией, почему мы раньше не сказали, либо с искренним удивлением
«Я не мог так сказать, это же абсурд»Мы никак не могли прийти к консенсусу, в результате чего, мы (разработчики) просто уступали. И делали как нас просили. Программистская боль — делать никому не нужные «фичи».
Хочется упомянуть, что и по финансам всегда были проблемы. Никаких вложений, кроме как в SEO не было. Даже держать 2 программистов это оказалось дорого. Конкурировать с новыми порталами из ТОП-10 с таким уровнем финансирования и управления, очевидно, оказалось нереально.
Как итог у нас есть платформа портала агрегатора недвижимости. Масштабируемая, расширяемая, работающая быстро и технически готовая к любым катаклизмам. С большим потенциалом. Хорошый код, минимум костылей и мало узких мест.
Однако никакого положительного результата это не дало. На момент моего последнего рабочего дня, несмотря на наличие 4 млн уникальных страниц в поисковиках, трафик портала колебался около 1400 уников в день. А это, как мне кажется, констатирует смерть.
P.S.: Из всей этой истории смог лично я сделал один главный вывод. Можно сделать хороший продукт с точки зрения разработчика, но он будет абсолютно не востребован, т.к. не имеет должного управления. Если та нить между сотрудниками, которая удерживает бизнес на плаву, порвана, то ваш продукт непременно пойдет ко дну.
Комментарии (99)
BlessYourHeart
21.09.2018 02:05Ну да, когда куча агентов под видом физ. лиц сдают-снимают-продают-покупают, то такой бизнес загнется в какой то момент времени. Хотя судя по наличию объявлений «русская семья снимет квартиру в вашем районе» кто то еще ведется на это.
Я бы на вашем месте сделал бы другой главный вывод: надо смотреть не только на то, как ты делаешь, но и на то, что ты делаешь, для кого и какие перспективы.
redfenix
21.09.2018 02:23Я правильно понял — вместо того что бы делать фичи, которые могли быть жизненно необходимы в проекте, два разработчика в течении года тайком от руководства переписывало проект?
Я наверное выскажу очевидные вещи — всем пользователям все равно на чем написан проект, как он работает внутри, используется ли там perl образца 2001 года или новомодный фреймворк. Главное что бы сервис быстро, интуитивно и удобно выполнял задачи пользователей.
Тут встает такой вопрос — а пробовали ли Вы донести до руководства, что перенос картинок из БД ускорит загрузку сайта, тем самым повысив удобство пользователей? И например можно потратить неделю и переписать только эту часть, не трогая другие костыли.tcapb1
21.09.2018 04:03Насколько я понял, профит таки был: страницы стали отдаваться быстрее, парсинг XML стал занимать меньше времени.
Другое дело, что дефицитный ресурс (рабочее время разработчиков) возможно использовалось не для того, что действительно приоритетно. Какой смысл в удобном личном кабинете например, если твои объекты по недвижимости с каждым годом смотрит всё меньше посетителей? Вероятен сценарий, что разработчики вместо оптимизации того, что есть, поигрались с интересными им технологиями и приложили руку к падению проекта на дно.
Но возможно это просто естественный процесс. С появлением и ростом Авито, ЦИАНа (вот они кстати молодцы, из чего-то абсолютно неюзабельного они сделали удобный и популярный портал) и Яндекс Недвижимости многие очень популярные порталы из прошлого стали неактуальны. Некоторые ещё держатся на старых технологиях (EMLS например), но это скорее исключение. Так что возможно с такими ресурсами просто объективно было нельзя ничего сделать, и жизненный цикл портала закончился сам по себе.
riky
21.09.2018 02:52+1Жизненно.
Ошибка босса в том что он вас не контролировал, и вы с ним разговаривали на разных языках.
Кто-то в компании должен объединять все отделы в единый организм. Если не босс, то какой то менеджер, который разбирается и в том что вы творите и в сео и текстах и тд.
Иначе получается лебедь, рак и щука.
Если кто-то не дирижирует этим оркестром, то провал — вопрос только времени. Если каждый в оркестре будет думать что он сам отдельно от дирижера сейчас сыграет супер развязочку, пусть не по нотам, но зато от души, от всего сердца, то в результате получится какофония. Вы же сами признаете что было много сео задач, но время вы тратили на переписывание как в вашем понимании должно быть лучше.
Успех компании это слаженная работа всего организма, каждый орган должен быть здоров и работать поддерживая всех остальных. Тогда на выходе получается лучший продукт, а не продукт где лучший дизайн, но плохое сео, или идеальный движок, но опять же низкое сео и тд.
Rudolfo
21.09.2018 03:00А мне не ясно, почему у вас что-то тормозило из-за картинок в базе. Сколько я не измерял — всегда разница была незначительной между хранением в БД и в файловой системе. Поэтому предпочитал и предпочитаю хранить в БД, ибо целостность.
alexs0ff
21.09.2018 07:44На прошлой работе пошли путем хранения БД, потом столкнулись с тем, что такие размеры SSD для базы очень и очень дорогие. Просто для файлов есть специальные распределенные файловые системы, а для связанных данных есть СУБД. Когда файлов не так можно — быстрее и надежней использовать базу, а вот когда размер зашкаливает за сотни терабайт — тут уже нужно пользоваться специализированными инструментами.
mayorovp
21.09.2018 08:08Так файлы можно и на HDD хранить, MS SQL Server так умеет же.
firedragon
22.09.2018 07:59Не верьте маркетологам из Microsoft. Файл есть файл: туп, понятен и отказо-устойчив.
mayorovp
22.09.2018 11:49При чем тут маркетологи?
firedragon
22.09.2018 12:46Потому что всунули в БД функционал который паршиво работает, под видом крутой фичи. Причем собезьянничали Oracle.
И сами крайне редко используют эту фишку в своих продуктах.
Причем казалось бы в продукте как шарепоинт или проджект, это решение напрашивается, однако нет. Сменилось уже 3 поколения платформ, а использование filestream до сих пор не включили в рекомендуемый набор по развертыванию.
Хотя шарепоинт это и есть файлопомойка++ (утрирую конечно, но у многих именно так)mayorovp
22.09.2018 12:52Шарик и SQL Server делают разные команды. Не виду каким образом решения принятые разработчиками шарика говорят что-то о качестве фич SQL Server. Это во-первых.
А во-вторых, надо плясать не от крутости фишек, а от задачи. И если есть задача хранить файлы на HDD, а основную часть данных — на SSD, то в SQL Server есть простое решение. Которое куда проще чем альтернативы с раздельным хранением файлов и их описаний.
Вот если файлов становится так много что их надо начинать хранить распределенно — это уже другая задача, и SQL Server ее не решает. Но тут-то обсуждается совсем не такая ситуация.firedragon
22.09.2018 19:3895% данных в шарепоинте это Word, Excel, PDF.
И задачи собственно те-же. Положить файл в хранилище, обеспечить его индексацию, совместную работу с ним, права доступа и относительно компактное хранение.
Что же до команд, то это 2 команды которые работают над флагманскими продуктами для бизнеса.
И в этом разрезе видно что команда шарепоинта просто забила, а команда сиквела согласилась.
И общепринятая практика на сегодняшний момент хранить всякий «стафф» в файловой системе, обеспечивая индексацию средствами шарепоинта, а права доступа средствами файловой системы. Серьезные же документы хранятся в базе данных, где обеспечена версионность, ролевая модель IRM и всякие другие плюшки.
JekaMas
21.09.2018 10:00или тогда уж не хранить размеры, а сделать ресайз on-fly и добавить слой кэширующего прокси.
isden
21.09.2018 10:53Разница тут вот в чем. Чтобы отдать картинку посетителю, вам нужно:
1. Сервер получает запрос.
2. Передает его на бэк.
3. Бэк лезет в базу и делает там выборку.
4. Бэк передает извлеченную картинку серверу.
5. Сервер отдает её посетителю.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
На сайтах с небольшой нагрузкой разница не очень заметна. Но вот когда база разрастается на гигабайты и сайт начинают посещать уже не полтора пользователя в день, все становится очень грустно.lair
21.09.2018 11:35+1Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
Это если у вас картинки лежат прямо на сервере, выставленном во внешний мир по HTTP.
isden
21.09.2018 11:45А где им лежать? CDN?
Могут лежать и на другом сервере, но и в этом случае хранение картинок в базе добавляет заметный оверхед без получения особого профита от этого. И, по моему мнению, этого лучше избегать и использовать специализированные решения, заточенные на работу с файлами/объектами.lair
21.09.2018 11:48CDN. S3/GCP/ABS. Просто другой сервер из соображений безопасности.
isden
21.09.2018 12:05В случае с CDN делать вообще ничего не надо. Просто заменяем ссылки на картинки в коде.
Про S3/GCP и прочее —
proxy_pass http://my_bucket.s3.amazonaws.com/...
не?
С другого сервера аналогично, s3-compatible например (minio etc), или даже монтировать через nfs.lair
21.09.2018 12:07В случае с CDN делать вообще ничего не надо.
Если у вас CDN как услуга, то да.
Про S3/GCP и прочее
Если у вас открыт доступ к хранилищу по HTTP.
даже монтировать через nfs.
Это если между ними есть такая сеть.
И согласитесь, да, что кроме случая с CDN, это уже далеко не "Сервер получает запрос — Сервер отдает её посетителю."
isden
21.09.2018 12:12> Если у вас открыт доступ к хранилищу по HTTP.
Ну например — github.com/bsc-s2/lua-resty-s3-client
Lua в nginx очень быстрое.
А еще можно наколхозить горячий in memory кэш на сервере.
> Это если между ними есть такая сеть.
И что же мешает поднять приватную подсеть?
> И согласитесь, да, что кроме случая с CDN, это уже далеко не «Сервер получает запрос — Сервер отдает её посетителю.»
Ну да, кое-какие телодвижения для настройки нужно сделать.
Но это таки не тот адок, когда для выдергивания картинки, скажем, 1х1 или 5000х5000 нужно отдавать запрос бэку, ждать пока он там прожует и пошуршит по базе и отдаст результат, и только уже потом его можно отдавать посетителю.lair
21.09.2018 12:16Ну например — github.com/bsc-s2/lua-resty-s3-client
Это все равно больше не сингл-хоп.
И что же мешает поднять приватную подсеть?
Разные ситуации бывают.
Ну да, кое-какие телодвижения для настройки нужно сделать.
Здесь вопрос не в том, какие телодвижения надо сделать для настройки, а в том, где случается ботлнек в производительности.
Но это таки не тот адок
В обмен на адок вида "как бы нам обеспечить консистентность хранилища в БД и на файловой системе". А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш...
isden
21.09.2018 12:19> Здесь вопрос не в том, какие телодвижения надо сделать для настройки, а в том, где случается ботлнек в производительности.
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
> В обмен на адок вида «как бы нам обеспечить консистентность хранилища в БД и на файловой системе». А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш…
И в чем проблема с консистентностью?
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.lair
21.09.2018 12:24Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
У каждого своя ситуация.
И в чем проблема с консистентностью?
Каждая операция записи, связанная с картиной — распределенная транзакция.
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
… а проблем с бэкапом файлового хранилища такого объема вы не видите?
isden
21.09.2018 12:28> Каждая операция записи, связанная с картиной — распределенная транзакция.
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
> … а проблем с бэкапом файлового хранилища такого объема вы не видите?
Эти проблемы решается сильно проще. Инкрементальные бэкапы, дедупликация, распределенные файловые системы — вот это вот все.
Я говорил, есть же специальные решения, придуманные и отточенные для работы с файлами. База данных к этому относится очень с натяжкой.lair
21.09.2018 12:30Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
… пока она не ломается.
Впрочем, мой пойнт был не в этом. Мой пойнт был в том, что ваше "Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5" верно только в примитивном случае.
isden
21.09.2018 12:31Ну вот в большинстве случаев (опять таки по нашему опыту) как раз такой подход (т.е. CDN и подобное, с отдачей картинок сразу по http) и оказывается самым эффективным.
lair
21.09.2018 12:53Беда в том, что CDN, и все остальное, что отдает картинки сразу по HTTP — это не просто "выкати свой сервер с файловой системой", это интеграционная задача.
isden
21.09.2018 13:01Если нет ресурсов на интеграцию (что тоже, кстати, не запредельной сложности таск), то можно взять вариант со своим хранилищем по nfs. Вариантов вообще много. Правильный CDN, кроме того, хорош еще тем, что умеет отдавать статику с ближайшего к посетителю сервера.
D01
22.09.2018 08:341. Запрос
2. Если нет в кэше нужного размера, то передает его на бэк. (а где оно там реально хранится — все равно должно быть)
…
5. Сервер отдает её посетителю и если ответ не из кэша, то записывает в кэш.
И все проблемы)isden
22.09.2018 09:22Я там где-то писал про горячий in-memory кэш. Хотя, как мне кажется, прогревать его через бэк — как-то не очень идея.
Ну и тут свои заморочки есть, как же без этого :)
В программировании существует лишь два характерных затруднения: инвалидация кеша, наименование сущностей и ошибка на единицу
D01
22.09.2018 11:01прогревать его через бэк — как-то не очень идея.
In-memory — согласен, а когда там просто папка с файлами в качестве кэша, а картинки содержат в своем наименовании свой размер и тип и измененная картинка — это однозначно новое название, то особо и прогревать нечего)
Все от конкретной ситуации зависит…
electronus
21.09.2018 05:04Почему ушел предыдущий разработчик?
Jarashow Автор
21.09.2018 07:32+1По совокупности причин. Наелся за 5 лет. Он ещё застал успешные времена и наверно ему было понятно но к чему всё идёт.
Saymon
21.09.2018 07:44История о том, что перестановка кроватей в борделе ни привела к росту его прибыли.
Конечно обидно, что труд нескольких лет остался не востребованным, но с другой стороны лично вы прокачали скилы и этот ваш опыт сам по себе ценность. Теперь можете рассчитывать на трудоустройство в более интересном и ИТ -ориентированном месте, где успешно будете применять эти навыки.
Shadlance
21.09.2018 07:49Я пришел на эту работу в 2014 году, простым junior .net.
На втором году работы, мой руководитель ушел с проекта. И я остался один на один с этой древней махиной, в которой было от силы 3% моего кода.
Если руководитель не стал ни чего предпринимать и просто слился — тут или он сам по себе такого склада (инфантильный с позиции тех. эксперта), или попросту понимал что уже ни чего нельзя было исправить (руководство не принимало информацию к сведению). В любом случае весь рассказ больше о всё об одном — ошибке управления и адаптации на рынке, технические аспекты могли иметь место быть, но как уже упомянули ранее — их роль была далеко не основополагающей.
Если та нить между сотрудниками, которая удерживает бизнес на плаву, порвана, то ваш продукт непременно пойдет ко дну.
Вероятен сценарий, что каждый со своей колокольни думает что знает рынок и свой продукт, но на самом деле не видит целостной картины.Stas911
21.09.2018 16:17Или просто банально человек устал и решил сменить поле деятельности (лучше условия, выше зп)
asheee
21.09.2018 08:47+1Спасибо за еще одно подтверждение того, что стоит избегать разработчиков с парой лет опыта. Практически всегда повторяется одна и та же история. я называю это проблемой «самого важного человека в команде». Из этой ситуации нужно сделать один важный вывод: код не имеет большого значения. вангую что будь все написано на вордпрессе, результат был бы такой же. учитесь на своей ошибке, а не вините своего сео.
Jarashow Автор
21.09.2018 09:07-1Во-первых никто не винит нашего СЕО. К слову у нас сменилось 4-5 СЕО за это время и каждый переделывал все после предшественников. Кстати последний СЕО делал и делает правильные вещи.
Я старался никогда не обвинять. Мы тоже где-то действовали в своих интересах, но на это у нас были причины.
Про избегание начинающих разрабов… Попахивает дискриминацией по признаку отработанных лет. Каждый джуниор должен иметь возможность получить опыт, чтобы стать кем то большим.
Эта компания оказалась одной из таких, за что ей надо отдать должное.asheee
21.09.2018 09:52-1вы путаете seo и сео. странно что вы гтворите о том, что попахивает дискриминацией. Я говорил об этом прямо, чем больше человек имеет опыта, тем более хорошо он осознает происэодящее. Если ваща цель была поучиться за счет компании, все отлично, я ни в коем случае не осуждаю, но если ваша цель была сделать продукт который победит конкурентов, то это, увы, не ваша проблема, и идеалтность кода на нее влияет мало. по поводу обвинения, по-моему очевидно, что это статья про обиду. если вы хотите развиваться — расслабьтесь, это не ваше время. кмк это и есть главная проблема маленького опыта — ты думаешь, что каждый проект — место для геройства и обижаешься, если тебя не оценили. на самом деле важнее просто делать хорошо ту работу, которую от тебя ждут.
Jarashow Автор
21.09.2018 09:57Пардон, с утра попутал сео/seo. Насчет обиды это правда. Действительно, очень обидно что так все вышло. Мы старались, боролись, но иногда этого мало(
JekaMas
21.09.2018 10:03поддержу. со временем приходит понимание, что проекты разные. есть те, где надо сделать без дополнительного энтузиазма, но шустро, а есть и места, где нужно исследование и много личное инициативы.
SvSh123
21.09.2018 10:00что стоит избегать разработчиков с парой лет опыта
Избегайте, ваше право. Вот только опытных, как показывает практика, с каждым годом всё меньше, а запросы у них всё выше… :)
ggo
21.09.2018 09:36Вполне может быть, что печальный итог никак не связан с деятельностью ни директора, ни автора.
Мир меняется. Глобализируется. Некоторые услуги просто пропадают (уменьшаются на порядки), другие появляются. Остаются только крупные игроки, которым принадлежит большая часть глобального рынка. Остальные делят крохи.
ErnestMiller
21.09.2018 09:51Это просто классика. Когда технологический проект делает человек (руководитель), далекий от технологий, то в итоге получается такое. Сам регулярно с таким сталкивался, даже прямо сейчас есть такой проект. Владелец проекта при выборе технологической платформы слушает друзей-предпринимателей, а не программистов и devops.
D01
22.09.2018 08:55Если слушать только программистов и devops, то получится офигительный технологичный проект, который никому не нужен.
А вот цель любого бизнеса совсем не в самореализации программистов, а в банальном получении денег от конечных пользователей.
vs74
21.09.2018 10:40Всегда попадалось, почему-то, такое же начальство, которое всё делает против ИТ-отдела. Наверное это правда жизни: управлять и быть тупым)
roscomtheend
21.09.2018 10:47При наличии кучи всего — начиная от БН/БСН/ЕМЛС до Авито обращаться к кому-то новому… не уверен что оно может выстрелить и жить долго (по моему мнению бизнес недвижимости с одной стороны подорвало авито, а с другой реклама «агентства наживаются на вас», от чего агентствам стало хуже (и лучше маклерам, которые вернулись из 90х со всеми своими приёмами и киданиями клиентов, но зато у клиента иллюзия личного менеджера и почему-то безопасности, да ещё появились «информагентства», просто берущие деньги).
Vlad_fox
21.09.2018 10:53У Вас много внимания в статье, и наверное в работе, уделено внутренней кухне сайта.
Но сайт умер, вероятно, по другим причинам — его вытеснили в естественном отборе другие сайты, предлагающие подобную информацию в более удобном виде.
Не увидел в обзоре сравнения вашего сайта с конкурентами на рынке, набора ключевых показателей этого сравнения, и попыток их улучшить.
копание внутри сайта без оглядки на рынок — позиция страуса, который копает червячка в песке, оставив жопу беззащитной
hasalex
21.09.2018 11:02«Так никто не ищет, это низкочастотный запрос, я уверен»
до боли знакомо)) три мульона доводов, сценариев рассказываешь, а он — не, у нас же специфика)) а ты ему опять — да никто не ищет товар по коду в официальном каталоге производителя, потому что никто его не знает, ищут по модели и тому, что увидели на бумажке, перебирая все варианты. А он тебе — нифига, это все неправильные коды))batment
21.09.2018 12:34Потому что такие слова нужно подтверждать данными из аналитики, а то выглядит что программист просто решил поумничать.
ianzag
21.09.2018 13:43> да никто не ищет товар по коду в официальном каталоге производителя, потому что никто его не знает, ищут по модели и тому, что увидели на бумажке
Не факт. Я например когда ищу запчасть к машине вбиваю в гугл её partnumber найденный под картинкой, скажем, hondapartsnow и гугл выкидывает мне список конкретных продавцов (в моем регионе). На порядки удобнее и быстрее, чем попытка сформировать запрос «вон ту хреновину от коробки передач на такой то пепелац».
D01
22.09.2018 09:02Если автозапчасти искать по наименованию, то есть очень большая вероятность купить не то. Поэтому всегда нужны данные аналитики, как пользователи используют ваш продукт.
DancingBanana
21.09.2018 11:09Вот есть такой предприниматель — Олег Тиньков. К нему можно относиться по разному. Отрицательно, положительно или просто равнодушно. Но то что он довольно талантливый и успешный бизнесмен сделавший себя сам наверное никто спорить не будет.
В одном из своих интервью он дал дельный совет как найти себя в бизнесе. Этот совет просто до идиотизма простой.
Точную цитату сейчас лень искать. Но все что он тогда наговорил можно вынести тезисом в одно слово: улучшайте.
Хамят продавцы в магазине у дома? Откройте по соседству такой же, только с вежливым и внимательным персоналом.
Роскосмос дорого запускает спутники? Придумайте технологию возврата ступеней и снижайте стоимость пуска с каждым запуском (уже).
В общем щупайте слабые места конкурентов и аккуратно туда давите.
В связи с этим я не понимаю автора статьи. Если вы, автор, со своим техническим напарником были настолько подкованы во всем бизнес-процессе фирмы и постоянно фейс-палмили от нелогичных решений руководителя, что вам мешало запустить свой сервис с домами и риелторами?
Запустили бы и показали как надо. А дядю бывшего начальника на вертушку охранником посадить.roscomtheend
21.09.2018 11:32Улучшая, можно во-первых провалиться, т.к. зачастую лучше — дороже (или просто позже — дороже), а ещё можно не улучшить (как тот же Тиньков со страховой, который не смог предложить сервис даже на уровне конкурентов). Поэтому не магазин надо открывать, а делать хорошо что умеешь.
> Запустили бы и показали как надо
«Станьте ёжиками». Это же так просто и не требует вложений.DancingBanana
21.09.2018 11:49Улучшая, можно во-первых провалиться
Можно. Но как показала практика вперед вырываются только те кто постоянно находятся в развитии и поиске нового. Стагнация это один шаг до смерти любого дела (что мы и видим на примере данной статьи).
как тот же Тиньков со страховой, который не смог предложить сервис даже на уровне конкурентов
Подробности не знаю. Возможно это была его ошибка. Но как говорится не ошибается тот кто ничего не делает. И не стоит забывать, что Тиньков начинал как фарцовщик одежды, а на данный момент является долларовым миллиардером и владельцем банка. Прошел бы он этот путь, если бы являлся любителем стабильности и стагнации? Общий знаменатель его успешности более чем впечатляет.«Станьте ёжиками». Это же так просто и не требует вложений.
Любое дело требует вложений.
Даже для того чтобы выиграть в лотерее нужно купить билет.
Адекватному человеку это изначально понятно и не требует никакого скудоумного обстебывания с неуместным сарказмом.akrikkit
21.09.2018 19:39Любое дело требует вложений. Но далеко не в любое дело есть смысл вкладываться.
И это не «скудоумное обстёбывание с неуместным сарказмом», а правда жизни.
Jenix
21.09.2018 11:18-1Удивляют люди, которые напрочь игнорят окружающий мир (как автор поста). Они думают, что если они тщательно (с использованием хайтека) выполнят свою работу и быстрее всех, то это и принесёт им прибыль. ))
Нет! Прибыль приносят люди. Внешние и посторонние.
А за вашу красивую работу для самого себя, вас может похвалить только мама (она в любом случае вас похвалит, даже если вы красиво написали в подгузник).
Не бывает так, чтобы вы работали в замкнутом мире. Прибыль — это деньги, которые несут люди со стороны. За красивую работу никто денег просто так не будет давать, если на неё нет спроса. Спрос — вот ключевое слово в бизнесе.
Есть спрос — есть сбыт (если конечно к этому моменту вы уже подсуетились — т.е. сделали продукт, наняли продавцов, помещение, подвезли к покупателю, и громко о продукте рассказали всем).
ну и как говорят сейчас украинцы )) «вот как-то так»!
пруф — ролики экономиста Хазина о падении спроса с 2008 года (почему тухнет экономика и почему «в США разбрасывали деньги с вертолёта для поднятия спроса») и как устроен бизнес.
Perlovich
21.09.2018 11:28В действительности, я начал полностью переписывать систему практически с 0. Пришлось это делать тайно от руководства.
Не надо так делать.
Я искренне уважаю стремление автора вытянуть проект, его полную погруженность в работу и неиссякаемый энтузиазм. Но в тайне переписывать систему — это, я считаю, ошибка.
Разработчик не должен думать за бизнес и принимать решение за бизнес. Да, он может высказать свое мнение, предоставить свою экспертизу, выразить сомнение, проявить инициативу. Но без одобрения менеджмента делать крупный кусок работы — за это никто спасибо не скажет. Более того, это не очень-то и этично. Это как сказать прямым текстом: «Товарищ менеджер, ты сам не понимаешь, что ты делаешь. Поэтому я буду принимать решения за тебя, с тобой не посоветовавшись». Не надо решать за менеджмент, что делать.
К тому же, из текста для меня совсем не очевидно, почему проект провалился. Может, при текущем маркетинге, дизайне и фичах, даже если бы все летало, проект бы это не спасло.Jarashow Автор
21.09.2018 11:55Почему не надо?
Все-таки мы переписывали скорее для себя и будущих разработчиков, чтобы нам же было легче модернизировать и поддерживать продукт дальше, другими сотрудниками. Простые задачи больше не занимали много времени.
И эту задачу мы выполнили. Это был фундамент на будущее, которое мб когда-нибудь там и наступит.tcapb1
21.09.2018 12:06А сколько процентов от рабочего времени вы тратили на переписывание? Насколько переписывание тормозило внедрение задач от руководства?
Мне это немного напомнило известную притчу про Васю, который наговнокодил и выпустил свой продукт на рынок быстро, и Петю, который долго вылизывал свой код, но закончил уже тогда, когда его продукт перестал быть актуальным.
Рефакторинг — это конечно хорошо, но если проект умирает, то может вместо закладывания фундамента на будущее лучше делать что-то другое?
Perlovich
21.09.2018 12:20Почему не надо?
Потому что это не нормальные деловые отношения. Не надо брать на себя чужие зоны ответственности. Если руководство забраковало идею, нужно принять это решение. Не надо решать за других людей. Да, возможно, это неправильное решение. Но делать «благую работу» вопреки ему — это неправильно.
В командах приходится работать с большим количеством людей. Многие из которых не всегда принимают корректные решения. Везде всегда кажется, что кто-то что-то решил не так. Но нужно с этим жить, а не делать по своему. Максимум, что можно сделать — это выразить свое мнение. Или сменить работу. Но игнорировать чужие решения в их зоне ответственности — это не тру.
Далее, это просто неблагодарная работа. Премию за это вряд ли выпишут. Более того, если это всплывет, руководство вообще может отреагировать весьма негативно. Потому что в их глазах вы делаете не то, что должны.
Ну, и конечно, такая деятельность — она вызывает большое чувство обиды и неудовлетворенности. Если пытаться сделать все что возможно, но в рамках рабочих нормальных отношений, — то чувства обиды не будет.
Нужно кооперироваться и уважать чужие решения. Даже если кажется, что они неверны.algotrader2013
21.09.2018 19:09+1К сожалению, такая ситуация очень частая в IT. Мало кому из руководителей удается зажечь глаза у своих девов, и при этом зажечь и в пользу интересов дела. Это скорее исключение и искусство. И очевидно, что владелец сайта был полной противоположностью таких людей.
Кооперироваться банально невыгодно. Да, люди не хотят быть плохими, но шаг за шагом, сами того не замечая, начинают. В данном конкретном случае «уважать чужие решения» == «искать баги в чужом коде целыми днями» && «изучать устаревшие технологии». Зачем? За это не будут больше платить, и не дадут долю в бизнесе.
Есть совсем упоротые, которые подвызываются на фриланс либо удаленку параллельно с основной работой, и две, а то и три ЗП одновременно получают (и при этом ловят намного больший кайф от того, как поимели систему и дебилов менеджеров, чем от процесса траты трех ЗП), но большинство просто начинает подменять нужные задачи интересными, поучивать технологии в рабочее время, продавать ненужные усложнения бизнесу. Это повсеместная проблема, и лично для себя я сделал вывод, что системно она не решаема. Или нужен маг, который зажгет глаза (но на поток ты хантинг магов не поставишь, а чаще появляются зажигатели глаз, но в невыгодном для бизнеса направлении — приходит главный архитектор, и говорит «сейчас есть мегатренд — новая технология. Давайте разбираться, и перепишем все на ней»), или просто бизнес должен признать, что производство кода имеет запредельный % брака, и вбрасывать больше ресурсов.
redfenix
21.09.2018 22:56+1Я уже написал постом ниже — второй разработчик обошелся компании в 2400000 рублей минимум, Вы уверены что это было оптимальное расходование средств?
Любой бизнес это стратегия — как при ограниченных ресурсах достигать максимальных результатов. Переписывание проекта — это ставка на долгосрочный результат, может быть лучше было бы решать коротко срочные задачи?
Jenix
22.09.2018 10:55-1среди IT необычайно большой процент откровенно дурачков, работающих за идею. И бизнес этим часто пользуется. Пользует дурачков.
Особенно кричаще это было в 90-е.
Гигантские прибыли у директора конторы, в которой половина бизнеса держится на IT, и нищенские зарплаты у IT-компьютерщиков, которых в то время было днём с огнём сыскать.
Вот такой парадокс — спецов нет — конкуренции никакой, а зарплаты мизерные, ниже любого продавана и тем более глав.буха. И при этом при всём — презрительное отношение всей организации к компьютерщику и программисту как к «нахлебнику».))
А сейчас другой перекос — неоправданно высокие зарплаты у людей (IT шники), от которых бизнес зависит, ну «почти никак». Ну да, без компьютерных систем будет труднее, медленнее, но в основном бизнес никак не остановится. Магазины не встанут, трактора не зависнут, сталь — не застынет в ковше. Здесь есть компьютеры, но это не IT. )
Jef239
21.09.2018 11:31Интересно, что о самом важном автор и не написал. Что мне (пользователю) нужно от сайта недвижимости? Нужна база. Если я уверен, что все предложения в городе есть на одном сайте — я буду постоянно пользоваться только этим сайтом. И всем остальным советовать. И агенты будут ориентироваться именно на этот сайт.
Иными словами, вместо SEO и оптимизации сайта надо было заниматься привлечением клиентов. Одна точка подачи объявлений на город? Вы не понимаете, насколько это неудобно. Нет преимуществ подавшим объявление в поиске на сайте? Опять неудобно. Нет оплаты через инет? Опять неудобно.
Вот потихоньку ваших клиентов и переманили те, где было удобно.roscomtheend
21.09.2018 11:35Агентствами объявления в БН подаются в электронном виде более 20 лет. Может, они в основном на них ориентировались?
Jef239
21.09.2018 11:41+1Вот в этом и ошибка. Я, как просто пользователь, ищу там, где есть всё. Агентству нетрудно подать и на 5 и на 10 сайтов. А частник — подает в 1-2 места, при этом цена у частника ниже (нет или мал агентский процент). Так что искать я буду там, куда ушли частники. И агентства уходят туда, куда идут частники.
roscomtheend
21.09.2018 15:08Это если бесплатно, в том же БН оплата за строчку. Но БН был самым известным, даже их убогий формат многие приняли для обмена (потому как в него большинство умеет).
Jarashow Автор
21.09.2018 11:48Никогда не слышал про БН, если честно.
Мы — разработчики и могли только отпимизировать сайт. У нас были и плюшки для ручного размещения, и оплата через интернет, и бонусы для клиентов. А вот привлечением занимались периодически и малоуспешно.
algotrader2013
21.09.2018 12:34А проблемы ведь куда глубже. К примеру, в Украине лидер рынка аггрегаторов недвижимости — lun.ua. Посмотрите, как там все устроено, как групируются дубликаты квартир, которые риэлторы тщательно плодят, специально находя дыры в алгоритмах, и стараясь таки создать дубликат (там серьезные матмодели, специально разработанные математиками для этого сайта, ML/AI на видеокартах), как определяется владелец/риэлтор, как работает мобильная версия сайта, сколько сайтов парсится (и не факт, что все они по воле владельца сайта). Как работает поиск — вы смогли бы на своем стеке технологий с такой же скоростью находить все квартиры в видимой части карты?
Я это все к тому, что увы, при всем уважении к автору, ну не сделать даже имея полную поддержку бизнеса и дрим тим из 5 фулл-стек синиор разрабов, захват рынка. Пользователи привыкают к массе мелких плюшек. Пользователи хотят актуальную базу данных с мгновенным парсингом даже тех агенств, которые активно защищаются от ботов-парсеров. Пользователи хотят того, на что надо масса человекочасов, даже если все писать с первого раза и без багов.
Hlaford
21.09.2018 12:47Все понятно. Владелец решил заняться SEO-магией. Надо было еще святой водой кропить серверА и прокалывать волосяные куклы конкурентов.
AllexIn
21.09.2018 13:56Это генально. Вместо решения актуальных задач — тайком переписывали проект, сил не хватало и наняли второго, ведь очень много работы и не получается тайком в одни руки переписывать проект.
А потом оказалось, что нужные задачи не решены, зато есть сверкающая отполированная платформа, которая не способна вытащзить компанию, потому что владельцу нужен не переписанный проект, а проект соответствующий его требованиям, которого нет, потому что вместо решения поставленных задач перепиливалась платформа тайком. Да, да, виноват конечно руководитель.
Это генально…tcapb1
21.09.2018 14:31Зато автор набрался опыта, изучил технологии и теперь будет использовать этот опыт (а возможно и какие-то нараборки со старого портала) на своём новом проекте по недвижимости.
Stas911
21.09.2018 16:21+1Но это все же не совсем этично — во время оплаченное работодателем пилить свой проект
tcapb1
21.09.2018 16:33Я не говорил, что я такое поддерживаю. Просто для проекта результат оказался печальным, а для автора — относительно неплохим. Впрочем, по имеющимся данным сложно сказать насколько действительно действия автора сказались на судьбе портала.
algotrader2013
21.09.2018 17:12Тоже есть вопросы к качеству такого опыта. По сути, это «обучение без учителя» — так, как не было человека, который бы смотрел на код и архитектурные решения, и говорил бы хорошо/плохо. Такие люди (которые могут в одиночку создать продукт без лидов и архитектов) реально круты, но есть много но, которые связаны с работой в команде и руководством командами)
ArsenAbakarov
21.09.2018 14:29Ну теперь… накодили, /ИМХО не верю что за год вдвоем можно создать реально современный, конкурирующий с топовыми продуктами проект, с как вы сказали «Масштабируемая, расширяемая, работающая быстро и технически готовая к любым катаклизмам. С большим потенциалом. Хорошый код, минимум костылей и мало узких мест», ревью кода никто не проводил, и уверен что и масштабироваться в разные стороны никто не пробовал /ИМХО
А так, теперь, раз есть такая платформа, идите на рынок, либо сами ведите бизнес, либо продавайте свою платформуtcapb1
21.09.2018 14:33Плюс при таком падении посещаемости (старая кривая платформа, напомню, держала миллион уников в месяц) узкие места сами собой должны становиться не узкими.
anonymous
21.09.2018 16:07Красивая упаковка = 45% успеха
Бабло в рекламу = 45% успеха
Архитектура и код = 10% успеха
Как то так
olehrif
21.09.2018 19:03Моё мнение — для своего роста выбрали не ту компанию. Если Вы разрабатывали продукт тайно от руководства, значит, компании это было не нужно. Компания тупо загибалась. Ваша точка зрения, что загибалась из-за низкого качества продукта — оказалось не совсем верное.
Я видел, как в одной крупной корпорации не приветствовали собственные разработки. Все централизовано закупалось. Так вот, разработчиков с треском уволили, с трудовыми комиссиями, с фабрикованием ложных трудовых характеристик, с подставами с опозданиями, и т.д., потому что вдруг выяснилось, что разработанное условно бесплатное ПО по функционалу и качеству на голову превышало возможности дорогостоящего закупаемого ПО, с которого начальники имели профит в виде отката.
iig
21.09.2018 19:10В 2008 древнем году старая платформа на костылях вытягивала 1М посетителей.
В 2014 году посетителей стало меньше в 3 раза, но старая платформа все равно перестала справляться с нагрузкой. Сервер устал? ;)
Программистов понять легко, они старались сделать как лучше. Но если бы они и не ударились в тайное причинение добра, а смирно выполняли все хотелки руководства — результат был бы тот же.redfenix
21.09.2018 22:48+1Не совсем согласен, можно было бы сэкономить на ЗП одного из программистов даже при ЗП в 60к (хотя думаю что выше) — это затраты минимум 100к в месяц для фирмы. Второй программист работал насколько я понимаю 2 года — следовательно можно было сэкономить 2 400 000 рублей, деньги не очень большие — но все же.
То есть если предположить, что исход был бы такой же — самореализация автора как клевого программиста переписавшего всё в идеальный не кому не нужный код обошлась фирме которая и так загибается в 2400000 рублей.
sordid
21.09.2018 22:52Всегда улыбало, когда люди, пришедшие в бизнес из комсомола или программирования видят в SEO волшебную палочку, которая прям завтра сделает их проект мегапопулярным, а их миллионерами стоит только SEO оптимизироваться и клиент попрет и оптом и в розницу… За 20 лет, что я занимаюсь маркетингом, ни разу еще не видел, чтобы SEO хоть кому-то помогло. Если в команде от босса и до последний уборщицы люди не понимают, кто их клиент и какую ценность они создают для клиентов своим продуктом/сервисом, то, как бы, это все пустая трата времени и сил. Помимо поисковиков есть еще миллион способов продвижения интернет ресурсов, используя другие каналы, которые для многих проектов/ресурсов даже более эффективны, чем весь бюджет на SEO, включая зарплаты специалистов. Все ведь можно в деньгах посчитать. Обидно за профессию, никто клиентской аналитикой не занимается, SEO и А/B тестирование заменило здравый смысл… Печально :(
tcapb1
22.09.2018 02:13В золотые времена этого портала SEO действительно работало. Возможно, оно не способно удержать посетителя и заставлять возвращаться снова и снова, но в качестве средства первичного нагона трафика оно было очень даже неплохо. А что ещё надо порталу, который живёт продажей своего трафика? Потом мир стал меняться, но владелец ресурса предпочёл действовать по-старинке.
visoVV
23.09.2018 00:01Да дружище ты прав в выводах.
Я заметил такую вещь, что у программистов своеобразный склад ума и взглядов, и им в команду всегда требуются специалисты другого уровня, как стратегический менеджмент, маркетинг и т.п.
Читал твою статью чуть ли не со слезами на глазах. Очень печально что такой труд умер. К сожалению, а может и к радости — множество проектов умирает по этой причине.
Создавая портал — нужно понимать такую вещь в первую очередь — сайт (любой «полезный» кстати) — это не кусочек кода с «техником» — это такая же функциональная фирма как и любая другая офисная, так же требует «техничку», директора, менеджера, маркетолога, и «водителя» — вот многие об этом забывают.
В твоей статье меня порадовал твой профессионализм и усидчивость — это высокая ценность в твоей среде, береги ее и развивай. И ради бога не трать себя на «пустые» компании.
Желаю тебе найти перспективный проект с перспективной командой.
DrPass
Ребята, на самом деле, не умаляя важности хорошей архитектуры с точки зрения легкости сопровождения, но для коммерческого успеха сайта она находится далеко не на первом месте. Я не знаю, каким был руководителем тот босс, но в одном он прав. На первом месте — SEO. Совсем недалеко за ним идут быстродействие и стабильность сайта, поддержка мобильных устройств, простота и понятность поиска, фильтрации. Всё остальное, различные API для интеграции, документация для разработчиков и тем более для пользователей, это не важно для сайта, продающего товары/услуги. Если сайт продает ИТ-сервисы, то да, ему нужна документация для разработчиков. Документация пользователям обычно не нужна от слова «вообще». Потому что если какие-то действия на сайте портала не интуитивно понятны, а требуют прочтения документации, 99% пользователей его закроют и пойдут на другой портал, а не будут разбираться.
Mox
По моему нужен был нормальный маркетолог, а не заштыриваться в SEO.
Jarashow Автор
Конечно, СЕО важно, но надо не зацикливаться на нем. Толку иметь сайт в топе выдачи, если при переходе на него люди не могут удовлетворить свои потребности. Они уйдут и больше не вернутся.
kaljan
Вы сейчас говорите прямо как генеральный директор сайта
DrPass
Вы верно говорите, но по статье ведь нет никаких предпосылок предполагать, что люди не могут удовлетворить свои потребности. В конце-концов, если сайт несколько лет подряд был «миллионником», значит, свои задачи он выполнял.
tcapb1
Потребности меняются.
В 2000-х годах например крупный сайт BN.ru размещал строчки с предложениями (без фото, без описаний, просто дублировал журнал Бюллетень Недвижимости) и кучу баннеров. Тогда вообще все сайты по недвижимости пестрели баннерами, и монетизация шла в основном через них. Фоток квартир было мало потому что на смартфонах ещё не было камер со сносным качеством.
Затем появились новые сайты с фотками, описаниями, удобными поиском и картой, а BN попал в западню: даже после ввода более подробных страниц объекта, большинство агентств всё равно слали им данные в привычном виде (только строчки).
Плюс само пользовательское поведение стало меняться. Если раньше для решения проблемы в основном шли в Яндекс, то теперь недвижимость ищется через сайты, которые на слуху (тот же Авито). Зоопарк порталов стал сжиматься, и такое идёт не только в сфере недвижимости, а вообще во всех сферах. На каждом направлении появляется 2-3 крупных портала-агрегатора, они тянут на себя значительный трафик, а остальным приходится выживать.
Другое дело, что часть порталов из прошлого и сейчас хорошо себя чувствует, и если бы владельцы этого портала вместо сео занимались бы удобством работы с ним в новых реалиях, а разработчики вместо тайного переписывания движка занимались бы обеспечением этого удобства — глядишь не было бы схлопывания посещаемости в 1000 раз.