Например, у нас был запущен Basecamp на одном сервере в первый год. Поскольку мы шли с такой простой установкой, это потребовало всего неделю на осуществление планов. Мы не начинали с кластера в 15 боксов и не тратили месяцы на волнения о вычислениях и на подсчеты.
У нас были проблемы? Нисколько. Но мы также осознали, что большинство проблем, которых мы боялись, действительно не существовало, с чем были согласны и наши клиенты. Будьте честны с ними, они поймут. Вспоминая прошлое, мы рады тому, что не стали делать «совершенную установку» с задержкой во многие месяцы.
В начале, сделайте основу продукта, вместо масштабируемости. Создайте большое приложение, а затем тревожьтесь о том, что делать, как только оно стало успешным. Иначе вы, возможно, расточаете энергию, время, и деньги, фокусируетесь на том, что может никогда не случиться.
Поверьте, это не большая проблема расширяться, когда в этом есть необходимость.
Дело в том, что всегда есть проблемы масштабируемости, никто не может сделать сразу с нуля то, что будут использовать миллионы потребителей. Снова придется переделывать почти каждый пункт проекта и архитектуры, чтобы обеспечивать масштабируемость.
Делайте идейное программное обеспечение
Ваше приложение должно лавировать между потребностями
Некоторые люди считают, что программное обеспечение должно быть агностическим. Они говорят, что самоуверенно для разработчиков ограничивать особенности или пренебрегать запросами потребителей. Они говорят, что программное обеспечение должно всегда быть гибким, как только это возможно.
Мы думаем, что это ерунда. Лучшее программное обеспечение имеет свое виденье. Лучшее программное обеспечение лавирует между потребностями. Когда кто-нибудь использует программное обеспечение, они не только, ищут особенности, они ищут подход. Они ищут видение для решения своих задач. Решите, что такое — ваше виденье и идите с этим.
И помните, если им не нравится ваше виденье, есть масса других видений для других людей. Не преследуйте людей, так вы не сделаете их счастливыми.
Хороший пример — оригинальный wiki проект. Ward Cunningham и друзья сознательно раздели wiki на многие сущности, которые считались раньше целым документом. Вместо отнесения каждого изменения к определенному человеку или документу, они переместили многое в визуальное представления. Они сделали содержимое. Им было не важно, кто пишет содержимое или когда это было написано. И это сделало свое дело. Это решение поощряет общий смысл общества, и оно стало ключевым ингредиентом в успехе Wikipedia.
Наши приложения шли подобным путем. Они не пробуют охватить все для всех. У них есть свое отношение. Они ищут клиентов, которые являются фактически партнерами. Они обращаются к людям, которые разделили наше виденье. Вы или на автобусе, или от автобуса.
Выбор функций
Наполовину, но закончено
Создайте половину продукта, но законченный продукт
Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное.
С Basecamp, мы начали только с секции сообщений. Мы знали, что это сердце приложения, так мы до поры до времени пренебрегли milestones, списками to-do, и другими элементами. Это позволило нам создать будущую основу при реальном использовании.
Начните быстро создавать приложение и позвольте ему приобретать инерцию. Затем вы можете начать добавлять функции и возможности твердой основе, которую вы построили.
Это не имеет значения
Только суть
Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».
Когда мы запустили Campfire, мы слышали некоторые из этих вопросов от людей, впервые проверяющих продукт:
«Почему время показывается только каждые 5 минут? Почему нет времени в каждой линии чата?»
Ответ: Это не имеет значения. Как часто вам нужно отслеживать беседу с секундной или даже с минутной точностью? Конечно, не 95% времени. 5 минут вполне достаточно, поскольку какие-то меньшие промежутки времени — не имеют значения.
«Почему вы не позволяете форматирование текста жирным шрифтом, курсивным или выделение цветом в чатах?»
Ответ: Это не имеет значения. Если вам нужно сделать ударение на чем-нибудь используйте буквы верхнего регистра или поставьте несколько * (звездочек) вокруг слова или фразы. Эти решения не требуют дополнительного программного обеспечения, технической поддержки, дополнительной мощности обработки, и им не надо обучаться. Кроме того, форматирование в простом тексте чата не так важно.
«Почему вы не показываете общее число людей в комнате чата?»
Ответ: Это не имеет значения. Все имена внесены в список, так что вы знаете, кто есть в чате, но, какая разница, если это 12 или 16 человек? Если это не меняет ваше поведение, то это не имеет значения.
Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.
Большинство времени, которое вы тратите, расточается на том, что фактически бесполезно в работе. Если вы сможете сфокусировать работу и взгляд, на том, что имеет значение, вы достигнете производительности, которую никогда не воображали.
Начните ни с чем
Сделайте добавление новых функций, трудно осуществимой задачей
Секрет создания законченной половины продукта вместо недоделанной половины — снизить количество функций.
Каждый раз, когда вы решаете добавить новую особенность или возможность, вы принимаете ребенка. Вам приходится заставлять вашего малыша делать целую цепь событий (например, проект, выполнение, испытание, и т.п.). И каждый раз вы натыкаетесь на это.
Не будьте подпевалой
Сделайте добавление функций, трудно осуществимой задачей. Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.