Лучше пойти живое с сайтом, который не полностью разрабатывается, или ожидайте, пока это не полностью функционально?

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

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

Сегодняшняя мудрость гласит: «Выпустите, отпустите, отпустите». Я думаю, что это был Дхармеш Шах ( www.onstartups.com ), который сказал: «Если вас не смущает ваше программное обеспечение, вы слишком долго ждали, чтобы выпустить его!»

Распространите его, заставить людей использовать это и заставить людей говорить об этом. Вы получите бесценную обратную связь (особенно если вы можете взимать плату). Кроме того, с первого дня ведите блог, чтобы вы могли взаимодействовать со своими пользователями.

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

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

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

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

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

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

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

You '

Нет единого ответа. Зависит от деловой ситуации. Я занимаюсь Agile / XP-разработкой и приношу программное обеспечение в стабильное и пригодное для использования состояние как можно раньше.

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

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

Я все еще твердо верю в ранние выпуски, даже если они защищены паролем. Они снижают риск проекта и стресс. Мы знаем, что с выпуском в продакшн нет никаких скрытых проблем, так как делаем это с первого дня. И это также помогает держать разработчиков подальше от проблем, поскольку у нас всегда что-то работает. Демонстрации и PR-моменты не такие стрессовые, поскольку они - обычная часть процесса.

Так что с точки зрения разработки программного обеспечения я рекомендую это. С точки зрения маркетинга ... ну, это ТАК, и мы не должны вдаваться в подробности. : ->

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

Так что с точки зрения разработки программного обеспечения я рекомендую это. С точки зрения маркетинга ... ну, это ТАК, и мы не должны вдаваться в подробности. : ->

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

Так что с точки зрения разработки программного обеспечения я рекомендую это. С точки зрения маркетинга ... ну, это ТАК, и мы не должны вдаваться в подробности. : ->

Запустить как бета-версию. Вот список из 100 лучших 100 бета-сайтов . Только приглашение может быть хорошим способом ограничить количество пользователей, которые могут его использовать.

The real question here is, how do you know that it's fully functional already?

When StackOverflow was released in public beta there were a bunch of features that weren't here yet. If I recall correctly comment upvotes (if not comments altogether), indication of duplicate question on closing for "exact duplicate", Recent Activity, and a bunch of other stuff were not available at the time.

The only way that some of these functionality came about was because the public asked for it.

Until you come out with a public site, it's nothing but vaporware, and you wouldn't know how the take up would be. Releasing it in public beta would allow you to get valuable feedback piecemeal, and build word-of-mouth promotion.

It's also a lot safer. Remember Cuil? They were hyped to be some sort of Google killer and released their site live, fully functional, in a single day. Their servers crashed catastrophically -- not because their search software sucked (it might have been better after all) but because their infrastructure couldn't handle it.

Public betas on the other hand allow for slower, more gradual take-up until you have a better idea how your site performs (CPU/memory/bandwidth wise) and will allow you to respond accordingly.

So by all means, release that site (make sure that it's clearly marked beta) and start mining for that valuable user feedback that you need to make your site awesome.