Запускаем проекты. Представление сырого продукта в бета-режиме

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

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

Для выпуска первой версии сервиса было необходимо:

1. Расставить приоритеты у оставшихся задач. Какие из оставшихся функций нужно кровь-из-носу сделать или отшлифовать до запуска продукта? Было сделано несколько ревью и списков требований от клиента, проектировщиков и тестировщиков. После этого мы смогли определить, чем можно заняться уже после выпуска бета-версии и сконцентрироваться на главном.
2. Извиниться перед пользователями за то, что кое-где может сыпаться штукатурка. Во-первых, мы поставили несколько заметных баннеров, рассказывающих о непрерывном улучшении портала после запуска. Во-вторых, создали несколько страничек с рассказом о светлом будущем и формой обратной связи, которая поможет покритиковать или предложить идеи.
3. Подготовить инструменты сбора статистики. Во-первых, важно знать, где и что на свежезапущенном ресурсе сломалось или не сработало. Но еще более важно понять, какими именно сервисами посетители пользуются, а какие не особо востребованы. Это здорово поможет нам не только при доведении продукта до финального релиза, но и при планировании его дальнейшего развития.

Еще один важный момент — придумать, как сообщать пользователям о нововведениях после запуска портала. Классический вариант — email-рассылка с перечислением свежих возможностей — не очень вписывается в концепцию. Лента новостей самого сервиса тоже будет засорять пространство. Зато другая важная сторона продукта — его гибкая настраиваемость — как раз отлично сработает. На главной странице есть блок, который ненавязчиво, но заметно рекомендует пользователю дополнения к базовой версии. Он и расскажет обо всех обновлениях.

Так что через неделю в блоге будут не только обещанные материалы, но и рассказы о двух свежезапущенных проектах. Главное не забыть написать на логотипе “BETA”.