Заметки от The end — читать вебмастерам!

Так уж получается, что подавляющее большинство стартапов в рунете (ua-нете, байнете) появляются на свет очень похоже. И создатели часто наступают на одни и те же грабли. Оно и понятно — необходимый-то опыт есть у единиц, большинству приходится все постигать самостоятельно. Достаточные инвестици на этапе созревания проекта привлечь получается очень редко — лишь в единичных случаях. Чаще всего стартап организуется на свои средства либо в условиях жестких финансовых ограничений. А иногда бюджет урезается намеренно — создатели стремятся прощупать перспективность проекта и отделаться при этом малой кровью. Но даже когда недостатка в финансировании вроде бы не ощущается, все равно стартаперы, осознанно или нет, но экономят. Что само по себе совсем не плохо. Загвоздка лишь в том, что нужно точно знать, на чем  можно сэкономить, а на чем не стоит ни в коем случае.

Изучение конкурентов в частности и направления в целом. Нет, я не об уникальности проекта как такового. Хотя если вовремя осознать, что подобных проектов куча и ничего нового мы миру не подарим — это и правда сэкономит деньги. Но я о другом. Буквально неделю назад я стал свидетелем того, как в принципе хорошая команда разработчиков потратила целый день на изобретение велосипеда, в то время как достаточно было подсмотреть, как реализовано на уже существующих аналогах. Ведь сами разработчики — совсем не блогеры, им многие нюансы незнакомы, а сам автор проекта должного внимания всем аспектам не уделил.
Изучение конкурентов полезно и в другом плане — изучая уже работающий проект, можно оценить, какой функционал востребован, а какой практически не используется. Отказ от бесполезного функционала сокращает время разработки и затраченные средства. Особенно чувствительно это на крупных проектах, где мелких малополезных фишечек-примочек обычно набирается вагон и маленькая тележка. Более того, буквально месяца полтора-два назад в достаточно объемном проекте, к которому я причастен, была на непределенный срок отложена реализация целого направления — после изучения конкурентов мы пришли к неожиданному выводу, что хорошо продуманный и почти полностью спроектированный нами сервис личных органайзеров лучше реализовывать как отдельный проект, а для аудитории разрабатываемого проекта он будет мало интересен. Неожиданная экономия составила около $14000.
 Между прочим, тот же Яндекс обсчитывает, что и как часто используют пользователи и учитывают эти показатели в работе над развитием своих сервисов. Но я пока ни разу не видел, чтобы в каком-нибудь стартапе использовали, к примеру, клик-каунтеры для определения приоритных направлений.

Составление документации. Все знают, что для разработки проекта необходимо ТЗ — Техническое Задание. Но даже среди разработчиков далеко не все знают, что из себя должно представлять ТЗ — жестких канонов-то не существует, каждый оформляет так, как ему удобно. Что уж говорить про автора идеи — ему составление внятного ТЗ однозначно не под силу. Знаю, звучит, мягко говоря, странно. Но увы, таковы реалии.
В идеале ТЗ должны составлять разработчики вместе с заказчиком. Однако такой вариант обходится дороговато. К примеру, на проект объемом в полгода работы команды из 5-6 человек (это только работа программистов, без проектирования интерфейсов, дизайна и верстки) составление ТЗ вряд ли займет меньше месяца. И в течение этого месяца заказчик должен работать вместе с разработчиками полный рабочий день. Такой подход на практике я наблюдал только 2 раза.
Другой, более экономный вариант — заказать ТЗ специалисту, «на пальцах» объяснив ему суть проекта. Выгода очевидна, а вот недостатки проявят себя в процессе разработки.
Сложность номер раз — найти специалиста, на которого можно положиться. Я видел ТЗ, написанные на заказ. Чаще всего это были схематичные эскизы нескольких основных страниц и в разной степени подробное перечисление функционала. Это, скорее, можно назвать видением проекта. В принципе, для разработки небольшого проекта (уровня того же news2.ru) такой документации может и хватить. Но при создании чего-то более серьезного (например, несложного блогхостинга) разработчикам значительную часть проекта придется придумывать самим.
Сложность номер два — и обойти ее вряд ли как-то удастся — лишнее промежуточное звено, «сломанный телефон». Я пока еще не видел написанных под заказ ТЗ, в которых не было бы чего-то упущено или в которых разработчикам все до последней буквы было понятно и не требовало постоянных уточнений-разъяснений со стороны автора ТЗ.
Что касается стоимости, то с одной стороны — дешевле $500 даже на мелкий проект ничего толкового однозначно ждать не приходится. С другой — 2-4 тысячи за ТЗ — это все равно существенно дешевле, чем совместная разработка документации заказчиком и разработчиками.
Ну и третий вариант — ТЗ пишет сам заказчик. Приемлемо лишь в случае с мелким проектом или если заказчик — профессионал в области разработок. В большинстве случаев такие творения пестрят фразами типа «вот эту фичу сделать как здесь(указывается урл), только с перламутровыми кнопочками». Можете сами представить цвет лица программиста, читающего подобную документацию на проект объемом хотя бы в пару месяцев.

Команда. Когда финансирование не ограничено, все сводится лишь к поиску специалистов. Что, между прочим, тоже далеко не просто. Однако, как я уже говорил, достаточное финансирование — это редкость. Наивные начинающие стартаперы (или стартапщики? хотя, пока норма в русском языке не устоялась, можно обзываться как заблагорассудится) подряжают фрилансеров. Потому-то значительная часть проектов так никогда и не запускается. Фриланс хорош для написания статьи или отрисовки баннера, но никак не для работы сроком больше пары недель.
Заказывать в веб-студии у стартаперов не принято. Для крупного проекта целесообразнее собрать/купить команду. Для проектов попроще чаще всего подряжают знакомую команду (кстати, еще один тупиковый вариант — работа на энтузиазме). Или обращаются к специалисту, имеющему репутацию человека, разбирающегося в теме. Последний, как правило, сам в меру способностей пишет ТЗ, сам занимается подбором команды (фрилансер-дизайнер, фрилансер-верстальщик и пара программистов, с которыми есть договоренности о сотрудничестве). Возможны варианты —  руководитель команды сам может быть техническим специалистом. Или просто неплохим организатором. В таком случае для подготовки ТЗ привлекается еще один фрилансер. В плане эффективности такой подход неплох — до стадии запуска доходят от половины до 2/3 проектов. Остальные замораживаются на неопределенный срок. В первую очередь, из-за организационных моментов. Подвел дизайнер/верстальщик… В спешке схалтурили программисты… Недовольный срывающимися сроками стартапер стал применять финансовые санкции. Или просто замучил команду упреками… Неоговоренные нюансы, раньше казавшиеся мелкими, стартапер либо представлял себе по-другому, либо вообще не представлял, но принятое исполнителем решение ему пришлось не по душе. Требуется переделка, в то время как бюджет уже давно оговорен и утвержден… Все это накапливается, и постоянно появляющиеся нестыковки становятся причиами все больших и больших пауз в разработке. Пока проект не остановится окончательно.

Разработка. Об этом можно рассказывать долго. А можно ограничиться одной фразой — экономят на всем. Отказ от коммерческой CMS (чаще — от набора полусырых модулей) в пользу разработки собственной платформы — это уже большой шаг, на который идут единицы. Разработка некоторых «убийц рунета» просто сводится к заточке  бесплатного Drupal’а под нужды стартапера. Ни про какие инновационные технологии и говорить не приходится.

Продвижение, PR-акции. Задумывая стартап, лишь единицы в планируемый бюджет вносят статью расходов на продвижение. Большинство считает, что для успеха хватит гениальности их проекта как такового. Достаточно лишь поисковой оптимизации (специалистом в этом деле считает себя каждый первый вебмастер) и нескольких нехитрых фокусов. Для начала — рассылка пресс-релизов. Поскольку не так много проектов запускается, более-менее внятно подготовленный материал принимается к публикации большинством сайтов. А дальше — бюджетные PR-акции. Конкурс «Пригласи друзей и выиграй айпод/айфон», требование обьязательной регистрации для просмотра контента, email-рассылка от имени псевдо-юзера всевозвожных приглашений вступить в группу/добавить в друзья/обсудить тему… Или совсем уж хитрый трюк — спамерская рассылка писем с логином и паролем. Дескать, вы зарегистрировались, вот ваши данные, заходите, милости просим. Подобное очень даже неплохо увеличивает количество зарегистрированных пользователей… единожды побывавших на сайте и забывших о его существовании. Пузомерка для инвесторов или потенциальных покупателей.

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