Причины провала сайтов. Почему закрываются сайты. Фатальные ошибки владельцев сайтов

Сейчас везде полно историй об успешном запуске крупных стартапов с нуля. Возникает такое ощущение, что для запуска надо просто начать, и все получится само собой. Может быть, именно поэтому 90% стартапов проваливаются. Но о неудачах писать не принято, и пишут только "выжившие".

По роду своей деятельности (разработка веб-приложений) приходилось наблюдать успешные и провальные проекты. Большинство - провальные. И это никак не связано с техническим фактором. В этой статье мы разберем главные факторы, приводящие к неудачному завершению проекта.

Мы нисколько не претендуем на объективность, мы просто анализируем результаты проектов, делаем ретроспективу и получаем некие выводы.

Это главная и самая частая причина. Вы что-то придумали, вам показалось, что это круто и обязательно будет востребовано. Вы вложились в разработку и продвижение, а потом оказывается, что нет такого покупателя, которому это было бы нужно и, который мог бы за это платить. мало посетителей на сайте или совсем нет.

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

Чтобы избежать этого необходимо, как можно раньше столкнуть ваше предложение с рынком.

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

Представьте, что у вас футбольная команда, все очень хорошо играют, кроме вратаря. Любой удар в ворота - гол. Как бы вы ни старались, вам не выиграть с таким вратарем в команде. Парадоксально, но в некоторых веб-проектах, вообще нет "вратаря"!

Затрачиваются довольно большие деньги на проект, строятся какие-то планы, но при этом большие части проекта вообще остаются неохваченными. На своем опыте я видел ситуации, когда серьезный веб-проект начинает продвигать родственник заказчика без опыта в продвижении. Раскрутка сайта визитки - это непросто, но раскрутка большой площадки - это же легко, вон Вася за неделю все сделает. Очевидно, что такой подход сводит на нет все остальные усилия в проекте.

Особо больная тема - это слабый владелец продукта, т.к. это тот человек, кто двигает продукт, кто вкладывает в него свое время и деньги и принимает все ключевые решения.

Некоторые надеются, что все эти вопросы решит за них какой-нибудь нанятый специалист. В 99% это не так. Никому нет дела до вашего продукта. Они выполняют свою работу, получают за это вознаграждение и все. У них свой продукт (услуга), и они сосредоточены на нем, а не на вашем продукте.

И еще момент, слабый владелец продукта найдет таких же слабых (или хитрых) членов команды.

Вывод - учиться, учиться и еще раз учиться. Только повышая свои компетенции, вы сможете дифференцировать исполнителей и видеть разницу в их работе, а не надеяться на их порядочность и профессионализм.

Есть такое дурацкое убеждение "Ну как я могу показать людям недострой, надо сначала все-все сделать, а потом уже запускать клиентов на него". Это самое вредное убеждение для IT проекта.

В реальном мире доработки физического объекта действительно затруднены. Сложно представить, что музей решили запустить в недостроенном здании: посетители смотрят картины, и параллельно идет ремонт, кладется ламинат и т.д. Но в виртуальном мире все изменяемо и может развиваться по ходу эксплуатации. Это очень важный момент.

В чем плюс такого подхода - в снижении рисков. Есть риск не угадать, что нужно пользователю. Как его избежать? Сделать гипотезу, реализовать прототип и дать клиенту. Затем получить обратную связь и доработать функции в нужном направлении. Тем самым вы создаете свое решение более осознанно с привязкой к требованиям рынка.

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

В любом случае забудьте о подходе "делаем фарш, и пока не сделаем, не запустимся". Этот подход обычно ведет к разочарованию: деньги заканчиваются, клиенты говорят, что хотели других функций, решение делается очень долго и очень оторвано от рынка.

Опять же это ошибка на уровне лидера проекта (на уровне принципов работы владельца продукта). Никакие супер специалисты по разработке, дизайну и продвижению не могут решить эту проблему.

Бывает так, что заказчик просто неадекватно ставит цели проекта. Говорит о гигантских целях (конкуренция с Авито), при это не имея даже минимальных ресурсов и компетенций на проект такого масштаба. Для меня это всегда является стоп-фактором участия в проекте, даже если есть первичное финансирование проекта. Все это сразу говорит о несерьезности заказчика и глубинном непонимании сложности проекта.

Ведь в итоге при полном провале проекта такой заказчик будет считать себя непогрешимым (он-то придумал гениальную идею - клон Авито для собак), а вот исполнители у него подобрались не те.

Также встречаются заказчики, которые просто ищут, где можно по-легкому срубить бабла. Они чем-то похожи на мотыльков, летящих на огонь, который опаляет их крылья. В итоге срубить по-быстрому не получается (оказывается, что все не так просто, как в историях успешных стартапов в сети, о которых рассказывается в видео на Youtube). Плюс они увязли в проекте, т.к. уже понесли некоторые затраты, и вот выходит, что проект зависает в воздухе.

Такой заказчик приходит не за быстрыми деньгами, а за созданием важного бизнес-актива, который в долгосрочной перспективе даст ощутимые преимущества его бизнесу.

Не будьте профаном, который где-то услышал об онлайн Эльдорадо (золотой прииск) и бежит сюда в надежде быстрой и легкой наживы, но который в итоге становится кормом для тех, кто продает лопаты, сито и кирки.

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

Это тоже плохая история для проекта. Почему? Чем больше срок, тем больше затрат, тем выше вероятность ухода членов команды (им ведь надо что-то кушать, пока заказчик занимается другими проектами).

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

Причина подобного затягивания - смена приоритетов заказчика. Если же идейный вдохновитель проекта начинает забивать на него, то глупо ожидать, что другие члены команды будут относиться к проекту с прежним рвением.

Чтобы не допускать этого, необходимо так спланировать проект, чтобы в итоге получить промежуточный результат. Т.е. если вы запланировали что-то получить, вы должны это получить, несмотря ни на какие изменения своих хотелок по ходу проекта.

Это субъективный анализ причин провала проектов. И из него можно сделать вывод, что главная опасность для проекта - это его лидер, владелец продукта. Именно он задает канву движения продукта.

Сильный владелец продукта может сделать продукт и со слабой командой разработки, плохим дизайном и посредственным продвижением.

У слабого владельца продукта практически нет шансов на успех ни при каких обстоятельствах - он все равно его загубит своими управленческими решениями (с учетом того, что бюджет не резиновый).

P.S. Мы ранее записывали серию видео на Ютуб #провалпроекта. Там мы более подробно рассматриваем факторы, которые приводят к негативному развитию проекта.

Источник: