10 шагов к провальному проекту

Во многих науках есть приём доказательства «от противного». Самым главным его преимуществом является наглядность демонстрирования ошибочного пути. Я попробую рассказать 10 шагов, которые гарантированно приведут к провалу вашего проекта.

1. Наш проект будет с максимальным функционалом

Универсальный швейцарский нож нужен меньшинству, которое часто и не умеет пользоваться всеми его функциями. Всегда помните, что ваш потребитель приходит на сайт для решения одной конкретной задачи. Не стоит пихать всевозможные левые сервисы. Хорошим примером в этом плане является программа Nero – несколько лет назад она представляла собой небольшую утилиту, которая позволяла записывать информацию на диск. Теперь же, Nero это громадный монстр, у которого есть свой видео- и аудиоредактор , программа по оформлению диска и много других «лишних» функций. Не удивительно, что многие отказались от его использования в пользу маленьких утилит, таких как Small CD Writer.

2. Мне не нужна большая команда, у нас есть универсальные знания

К сожалению, универсальные знания не значат полные. Да, конечно, есть люди, которые хорошо вертятся в 2-3 дисциплинах, но это исключение, которое только подтверждает правило. Программист вряд ли хорошо смыслить в технологиях продаж, а менеджер не знает всех особенностей работы с Photoshop или Adobe Illustrator . Поэтому стоит всегда искать профессионалов своего дела и уметь с ними договариваться – кому-то придётся дать денег, а кто-то будет готов работать за проценты или даже простое упоминание его в проекте.

3. Зачем проводить оценку? Всё равно на ходу можно всё исправить

Одно из главных заблуждений. На ходу исправить можно не всё, а только мелкие проблемы. Без хорошего анализа возможных проблем, запуск проекта может затянутся. Идеальным вариантом будет, если вы выберите самый пессимистичный сценарий развития событий и сумеете найти решения на все возникающие ситуации. Лучше потратить 1-2 дня на оценку рисков, чем 2-3 недели, а то и больше, на исправление всплывших проблем. Кстати, стоит подумать ещё раз прежде чем запускать проект, если минимальная планируемая прибыль будет меньше, чем максимальные планируемые расходы.

4. Отсутствие тестирования

Распространённая ошибка среди создателей различных сервисов. Многие предполагают, что сервера хостера могут выдержать 1 000 человек, а кто проверял? Меньшинство. И когда эта 1 000 человек идут на сервер одновременно, всё падает и люди понимают, что сервис не качественный. Я уже много раз видел, как молодые сервисы после их анонса на сайте habrahabr.ru уходили в даун. В итоге, удар по репутации команды разработчиков и вас, как проект-менеджера.

5. Мы будем трудится по 17 часов в сутки 7 дней в неделю, чтобы выложить релиз как можно скоре

Трудоголики ценились во времена Советского Союза, а к пенсии они были больны и их забывали. Самоотдача – это хорошо только в теории. На самом деле, работать без отдыха, нормального сна, питания и гигиены убийственно для мозга. За время работы вы 100% с кем-то из команды поругаетесь. Как показала практика, из меньше половины разработчиков, дизайнеров, копирайтеров и сеошников готовы работать сверхурочно, у остальных есть какие-то дела или просто они не могут перестроится на ваш ритм. В итоге, страдает ваш проект.

6. Экономия на резервном копировании

Сейчас многие вспомнят случаи когда умирали винты и была произнесена клятва о создании механизма резервного копирования. Только для большинства это осталось обычными словами и никакой механизм не был создан. А во всех блогах, книгах и форумах только и твердят – создавайте резервные копии. В пользе резервного копирования я убедился при работе над проектом AllLogin, когда уже созданная база была потеряна из-за маленького бага. Потратив на резервный жёсткий диск сегодня, вы завтра экономите время и свои нервы.

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

Отказ от помощи гарантирует, что срок запуска вашего проекта будет постоянно увеличиваться. Изобретение велосипедов затратно и по времени, и по качеству. С одной стороны, создавать полностью свой проект круто, а с другой – очень глупо не пользоваться тем, что уже создали для экономии времени и увеличения надёжности. Как говорил один успешный бизнесмен, «чтобы эффективно разделаться с проблемой, необходимо найти человека, который её уже решил, и купить у него это решение».

8. После запуска мы сразу включим платные функции и повесим контекстную рекламу

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

9. Раскрутка с помощью СПАМа самая эффективная, поэтому будем использовать её

Как только запустится СПАМ-машина будьте уверены, что ваша репутация будет подорвана, а ваш сервис будет переезжать с хоста на хост. СПАМ – это очень низкий уровень раскрутки. Попробуйте заинтересовать посетителей другими методами – пресс-релизами, PRом в блогах и форумах, интересными статьями. В конце концов, наймите человека, который профессионально займётся раскруткой вашего сервиса.

10. Мы не будем общаться с пользователями – у нас просто нет времени

Общение – самое ценное, что есть у человечества. Если вы будете игнорировать общение с пользователями, то они отплатят вам той же монетой. Создайте блог или форум проекта, которые помогут собирать идеи. Обратная связь отличный способ получатьбаг-репорты от пользователей, только не забудьте поблагодарить человека, который прислал вам сведения об ошибке – можно простым «Спасибо», а можно каким-то бонусом на сервисе.

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


firstVDS




Теги:

  • Про Неро хорошо сказано, меня удивляет, что он ещё до сих пор умеет записывать диски... Версии так к двадцатой глядишь и операционкой станет
  • Хорошая статья! У меня была 1я ошибка из-за нее, наверно, и загнулся проект=(
  • Tsdrive
    Сто раз натыкался на ситуацию, когда попытка универсализации приводила к краху. Ибо, как говорят в народе, нельзя "и рыбку сьесть и...".
    п.8 -на попытке заработать "сразу" даже в последние 3 "кризисных" месяца засыпались на моимх глазах тройка проектов, подававших надежды..
    А вобще -грамотно, спасибо.
  • Boogourerosap
    Интересный материал, спасибо!
  • 1. Кто будет покупать Nero 8 если она такая же маленькая писалка, как и Nero 7. Просто неро хотело продавать продукт уже купившим его. Но идея верна для вебовых проектов. Но я бы наверно сказал, что не стоит распылять акцент проекта.

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

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

    4. на ранних этапах вебового проекта - я бы решил статикой на первой странице. Толпа сервис не сожгет, но большая половина поймет - надо ей идти дальше или нет.

    5. сам когда то мочил по 14-15 часов в день. Качество существенно падает. На утро надо переписывать :)

    6. Есть отличная тема, прочитал у кого то на блоге. Заводим себе ящик на жмайле под проект, и шлем туда ежедневно письмо с бекапом.

    7. СТОПУДОВО!!! Часто вокруг своей идеи вы начинаете еще городить свои форумы, свои википедии, свои поисковики. Да возьмите уже готовое - не факт, что приживется, но вы хоть будите понимать, что вам не хватает. Кроме того, в 10 случаях из 10 — свой поисковик писать не надо :)

    8. Но маленькая кнопочка "Донейшон" в футоре никому не вредила.

    10. Только делать это лучше в оффлайн режиме. Есть время на работу а есть время на общение. И очень не приятно, когда вас отвлекают. А лучше, чтоб почта с вопросами по сервису равномерно распределялась по всей команде.

    А вообще статья клевая. Буду вашим постоянным читателем.
  • Shedar
    2admin, если посмотреть на ссылки Poomeodderbuh, Seetadeerce, wanyimank, Draharreste - с вероятностью 98% спаммеры (ссылки ведут не на личные блоги а на продвигаемые сайты), публикующие универсальные комменты ради той самой ссылки. Потому задавать им вопросы о частоте обновления блога и названии ридера смысла нет =)
  • Спасибо за замечание. Буду более внимательно смотреть (:
  • Кодировка UTF-8. Можно узнать название вашего RSS риадера?
  • А как часто для вас хотелось бы видеть обновления?
  • Потому что приходится работать над текущими проектами. Да и хочется писать интересную и качественную информацию, чтобы не создавать дублей с другими блогами.
  • junqed
    1,2 пункт - очень походит на unix-way: "Программа должна выполнять одну функцию, но очень хорошо"
    6 - ага, тоже сталкивался, тут даже форс-мажор надо учитывать и делать бэкапы бэкапов.
    7. сколько раз видел, что люди отказываются от инвесторов в плане того, что "меньше народу - больше кислороду". Только не верно всё это.
    10 - это наверное самый важный пункт, если хочешь завоевать сердце клиентов.
  • 1erika
    Отличная статья! Идет в избранное. Надеюсь, что в будущем мне очень пригодится. Спасибо автору!
  • Jeje
    Превосходно, ты все правильно заметил. Особенно про монетизацию и швейцарский нож.
blog comments powered by Disqus