Сроки

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

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

Тонкость состоит в том, чтобы сроки создания первой работающей версии не превышали определенных пределов. Например, для крупных веб-проектов это 4-5 месяцев разработки, для небольших и средних 1-2 месяца. Если проект делается большее время — можно считать, что сайт уже умер и начинать заново, это обойдется дешевле.

Почему? Потому что превышение средних сроков создания, возникает не из-за отличных результатов, не из-за успешных решений, а из-за проблем, допущенных в процессе: начиная от выбора исполнителя, излишнего энтузиазма заказчика и заканчивая ошибками в самой разработке. И большая часть времени будет уходить не на саму работу, а на исправление ошибок и на решение проблем. Это попытка строить дом на болоте, которое внезапно обнаружилось после закладки фундамента; это обед на палубе корабля за столом, с приборами, с бокалами вина, во время шторма.

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

Итак, средние сроки: 4-5 месяцев для крупных проектов (интернет-магазины, социальные сети, большие корпоративные сайты), 1-2 месяца для небольших и средних проектов (личные сайты, промо-сайты, сайты небольших компаний). Это не случайные цифры, а свой и чужой опыт разработки. В своей компании для крупных проектов мы ставим рамку: 4 месяца. В это время входит и проектирование, и дизайн, и программирование.

Как же избежать срыва сроков и выпустить работающую версию?

1. привлечь дополнительные рабочие ресурсы;
2. оптимизировать процессы разработки;
3. отсечь все лишнее.

Отсечение лишнего

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

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

Откуда появляются тысячи задач и все эти сложности? Это не понимание простого правила: «Больше совсем не значит лучше». Исполнитель предлагает реализовать новые функции, чтобы увеличить стоимость создания и стоимость поддержки, а клиент хочет добавить массу задач, чтобы оправдать свои вложения. И тот и другой ошибаются.

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

Для клиента успешность проекта не может измеряться количеством функционала. Успех и прибыльность зависит от других параметров.

Что нужно сделать, чтобы отсечь лишнее:

1. четкая и ясная концепция;
2. расстановка приоритетов: что важнее прямо сейчас, а что может подождать с реализацией. Какие функции (одна-две) будут ключевыми или продающими;
3. блокировка добавления функционала в процессе разработки;
4. понимание, что невозможно сделать все и сразу, разработка требует нескольких подходов.

Разработка в два захода

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

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

Еще раз: создание сайта это сложная работа, требующая больших и разносторонних знаний, вовлеченности нескольких высококвалифицированных специалистов.

Решение проблемы давно найдено. Это создание работающих прототипов сайта. Таким образом, оптимальный процесс создания проекта выглядит так:

1. составление документации;
2. разработка бумажных или нарисованных на компьютере эскизов;
3. создание дизайна;
4. программирование работающего прототипа;
5. тестирование с точки зрения удобства использования и сценариев работы;
6. анализ проделанной работы;
7. доработка документации;
8. внесение изменений в дизайн;
9. перепрограммирование прототипа до версии готовой к запуску сайта.

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

Итак:

• исполнитель должен пояснить клиенту процесс в два захода и выгоду от создания работающего прототипа;
• клиент обязан заплатить за такой подход большую сумму, тем самым сэкономив в дальнейшем на поддержке и на развитии.

Поэтапный запуск и масштаб

Не стоит делать проект с расчетом на миллион посетителей, если в реальности на сайт будет заходить тысяча человек в день. Технически нет особой разницы в том, чтобы разработать сайт для ста посетителей в день или для 20-30 тысяч. Существенное различие появляется, если необходимо обеспечивать сотни тысяч посещений в день, разрабатывая архитектуру проекта, который будет базироваться на нескольких серверах. Это на порядок увеличивает сроки работы, стоимость и сложность работы. Поэтому необходимо тщательно проанализировать возможное количество аудитории, особенно, в первые месяцы работы сайта.

Глупо рассчитывать, что в первый месяц работы сайта будет миллион посещений, если, конечно, не будет проведена невероятно масштабная акция по рекламе. Она естественно проведена не будет в 99% случаев. В итоге нужно задать вопрос, а стоит ли сейчас тратить суммы в несколько раз большие и увеличивать на несколько порядков сроки?

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

Даже такие сайты как twitter.com, в которых посещаемость росла и возможно до сих пор растет каждый день в два раза, все равно умудряются полностью перестраивать архитектуру, искать оптимальные решения, снижать нагрузки. И ничего смертельного не происходит. Если бы изначально twitter делали для миллиона посещений в сутки, он бы никогда не был запущен.

Запуск высоконагрузочных сайтов, да впрочем, и любых других, должен происходить поэтапно, например:

1. сначала только одна языковая версия;
2. для одного города;
3. для одной страны.

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

Поддержка и развитие

Абсолютно любой сайт нужно поддерживать. Это простая аксиома, но, тем не менее, в головах будущих владельцев проектов настолько глубоко сидит понятие о сайте, как о чем-то простом и сделанном на коленке студентом, что часто напрочь отсутствует вопрос: «А что собственно будет с сайтом после запуска?».

Есть три основных статьи расхода для существующего сайта:

1. поддержка (исправление и решение технических проблем на сайте, наполнение текстовой и графической информацией, анализ статистики сайта, взаимодействие с посетителями). Часто все это периодические платежи, без какой-либо фиксированной стоимости в месяц;
2. постоянные ежемесячные расходы (например, хостинг, рекламная поддержка);
3. вложения в развитие (создание нового функционала, изменение существующего функционала, расширение под увеличивающуюся аудиторию).

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

Сайт — это бизнес. Сайт может приносить прямой доход, может косвенный, но в любом случае владение им подчиняется таким же законам, как и в любом другом бизнесе. Если у вас есть продуктовый магазин: вы платите аренду за помещение, платите зарплату продавцам, платите за обслуживание помещения и в целом за обслуживание бизнеса.

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

Извлечение прибыли

Как было сказано выше: сайт — это бизнес. Бизнес должен быть эффективным и приносить пользу.

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

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

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

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

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