Getting Real, избранное. Часть 1
Getting Real, избранное. Часть 2
У вас пока нет проблемы расширения
«Каким будет мое приложение, когда им будут пользоваться миллионы людей?»
Что? Ждите, пока это фактически не случится. Если вы достигли того, что огромное число людей, перегружают вашу систему — тогда ура! Это очень красивая проблема. Правда — подавляющее большинство сетевых приложений никогда не достигают этой стадии. И даже, когда вы достигните этого — обычно ничего страшного не происходит. У вас будет достаточно времени, чтобы приспособиться к проблеме. Плюс, вы будете иметь более реальные данные и эталонные тесты, чтобы выяснить к каким конкретно областям приложения требуются улучшения.
Большинство проблем, которых мы боялись, действительно не существовало, с чем были согласны и наши клиенты. Будьте честны с ними, они поймут. Вспоминая прошлое, мы рады тому, что не стали делать «совершенную установку» с задержкой во многие месяцы.
В начале, сделайте основу продукта, вместо масштабируемости. Создайте большое приложение, а затем тревожьтесь о том, что делать, как только оно стало успешным. Иначе вы, возможно, расточаете энергию, время, и деньги, фокусируетесь на том, что может никогда не случиться.
Поверьте, это не большая проблема расширяться, когда в этом есть необходимость.
Вам придется снова все переделать, так или иначе.
Дело в том, что всегда есть проблемы масштабируемости, никто не может сделать сразу с нуля то, что будут использовать миллионы потребителей. Снова придется переделывать почти каждый пункт проекта и архитектуры, чтобы обеспечивать масштабируемость.
— Dare Obasanjo, Microsoft
Делайте идейное программное обеспечение
Некоторые люди считают, что программное обеспечение должно быть агностическим. Они говорят, что самоуверенно для разработчиков ограничивать особенности или пренебрегать запросами потребителей. Они говорят, что программное обеспечение должно всегда быть гибким, как только это возможно.
Мы думаем, что это ерунда. Лучшее программное обеспечение имеет свое виденье. Лучшее программное обеспечение лавирует между потребностями. Когда кто-нибудь использует программное обеспечение, они не только, ищут особенности, они ищут подход. Они ищут видение для решения своих задач. Решите, что такое — ваше виденье и идите с этим.
Хороший пример — оригинальный wiki проект. Ward Cunningham и друзья сознательно разделили wiki на многие сущности, которые считались раньше целым документом. Вместо отнесения каждого изменения к определенному человеку или документу, они переместили многое в визуальное представления. Они сделали содержимое. Им было не важно, кто пишет содержимое или когда это было написано. И это сделало свое дело. Это решение поощряет общий смысл общества, и оно стало ключевым ингредиентом в успехе Wikipedia.
Наполовину, но закончено
Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное.
Начните быстро создавать приложение и позвольте ему приобретать инерцию. Затем вы можете начать добавлять функции и возможности твердой основе, которую вы построили.
Это не имеет значения
Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».
Когда мы запустили Campfire, мы слышали некоторые из этих вопросов от людей, впервые проверяющих продукт:
«Почему время показывается только каждые 5 минут? Почему нет времени в каждой линии чата?»
Ответ: Это не имеет значения. Как часто вам нужно отслеживать беседу с секундной или даже с минутной точностью? Конечно, не 95% времени. 5 минут вполне достаточно, поскольку какие-то меньшие промежутки времени — не имеют значения.
«Почему вы не позволяете форматирование текста жирным шрифтом, курсивным или выделение цветом в чатах?»
Ответ: Это не имеет значения. Если вам нужно сделать ударение на чем-нибудь используйте буквы верхнего регистра или поставьте несколько * (звездочек) вокруг слова или фразы. Эти решения не требуют дополнительного программного обеспечения, технической поддержки, дополнительной мощности обработки, и им не надо обучаться. Кроме того, форматирование в простом тексте чата не так важно.
И т.д.
Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.
Большинство времени, которое вы тратите, расточается на том, что фактически бесполезно в работе. Если вы сможете сфокусировать работу и взгляд, на том, что имеет значение, вы достигнете производительности, которую никогда не воображали.
Сделайте добавление новых функций, трудно осуществимой задачей
Секрет создания законченной половины продукта вместо недоделанной половины — снизить количество функций.
Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.
Если запрос на функцию постоянен, мы слушаем, но не действуем. Мы только знаем, что настало время взглянуть на это глубже. И только затем мы начинаем рассмотрение особенности в реальном окружении.
И что вы говорите людям, которые жалуются, когда вы не принимаете их идею функции? Напоминаем им, почему им нравится приложение в первоначальном виде: «Вам нравится это, потому что не делает 100 других вещей».
Учитывайте скрытую цену новых функций и особенностей
Даже если функция уже работает, вам все еще нужно учитывать ее скрытые затраты.
Для каждой новой функции от вас потребуется:
- Сказать «нет».
- Вынудить функцию доказать свое значение.
- Если снова «нет», уже конец. Если, «да», продолжайте…
- Сделайте эскиз экрана/интерфейса.
- Спроектируйте экран/интерфейс.
- Закодируйте.
- Испытание
- Испытание
- Испытание
- Испытание
- Испытание
- Испытание
- Испытание
- Испытание
- Испытание
- Проверка текста помощи, возможно, его нужно изменить.
- Обновите ознакомительный тур продукта (если необходимо).
- Обновите маркетинговую копию (если необходимо).
- Обновите условия обслуживания (если необходимо).
- Проверка, на то, какие предыдущие обещания были затронуты.
- Проверка, на то, как это воздействует на общую структуру.
- Запустите.
- Затаите дыхание.
Создавайте то, чем можете управлять
Если вы запускаете партнерскую программу, должны ли вы управлять системой учета и выплат? Возможно, вы должны просто позволять людям зарабатывать без членских взносов, сообщений и отправке по почте проверок каждый месяц.
В состоянии ли вы отдать 1 гигабайт пространства бесплатно только потому, что Google это делает? Возможно, вы должны начать со 100 МБ, или только обеспечить место для платежных счетов.
Практичный совет: Создавайте конструкции и услуги, которыми вы можете управлять. Легко давать обещания. Намного сложнее сдержать их. Сделайте то, что вы можете подтвердить фактически, организационно, стратегически, и материально.
Создавайте программное обеспечение для общих решений и поощряйте то, когда люди ищут собственные решения
Не навязывайте людям решения. Вместо этого пусть каждый будет генералом над программным обеспечением и сможет найти собственное решение проблемы. Предоставьте людям то, с помощью чего достаточно просто разрешить их собственные проблемы и найти собственный путь.
Когда мы создавали Ta-da List, мы намеренно пренебрегли многим. Нет никакой возможности отметить точно дату, нет никакой возможности, чтобы категоризировать элементы, и т.п.
Мы создавали инструмент, чистым и упорядоченным, позволяя людям творчески подходить к решению задач. Люди, выясняли, как решить проблемы самостоятельно. Если они хотели добавить дату к элементу to-do, они могли добавить ее (точно так: April 7, 2006) непосредственно в сам элемент. Если они хотели добавить категорию, они могли добавить так [Книги], тоже непосредственно в сам элемент. Идеально? Бесконечно гибко? Да.
Если бы мы пробовали построить программное обеспечение, для того чтобы управлять этими сценариями, мы сделали бы менее полезный продукт для всех этих случаев.
Сделайте лучшую работу над основой проблемы. Люди найдут свои собственные решения и соглашения в пределах вашей общей структуры.
