|
||||
|
|
Выбор функций Наполовину, но закончено Создайте половину продукта, но законченный продукт Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное. С Basecamp, мы начали только с секции сообщений. Мы знали, что это сердце приложения, так мы до поры до времени пренебрегли milestones, списками to-do, и другими элементами. Это позволило нам создать будущую основу при реальном использовании. Начните быстро создавать приложение и позвольте ему приобретать инерцию. Затем вы можете начать добавлять функции и возможности твердой основе, которую вы построили. Это не имеет значения Только суть Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения». Когда мы запустили Campfire, мы слышали некоторые из этих вопросов от людей, впервые проверяющих продукт: «Почему время показывается только каждые 5 минут? Почему нет времени в каждой линии чата?» Ответ: Это не имеет значения. Как часто вам нужно отслеживать беседу с секундной или даже с минутной точностью? Конечно, не 95% времени. 5 минут вполне достаточно, поскольку какие-то меньшие промежутки времени — не имеют значения. «Почему вы не позволяете форматирование текста жирным шрифтом, курсивным или выделение цветом в чатах?» Ответ: Это не имеет значения. Если вам нужно сделать ударение на чем-нибудь используйте буквы верхнего регистра или поставьте несколько * (звездочек) вокруг слова или фразы. Эти решения не требуют дополнительного программного обеспечения, технической поддержки, дополнительной мощности обработки, и им не надо обучаться. Кроме того, форматирование в простом тексте чата не так важно. «Почему вы не показываете общее число людей в комнате чата?» Ответ: Это не имеет значения. Все имена внесены в список, так что вы знаете, кто есть в чате, но, какая разница, если это 12 или 16 человек? Если это не меняет ваше поведение, то это не имеет значения. Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения. Большинство времени, которое вы тратите, расточается на том, что фактически бесполезно в работе. Если вы сможете сфокусировать работу и взгляд, на том, что имеет значение, вы достигнете производительности, которую никогда не воображали. Начните ни с чем Сделайте добавление новых функций, трудно осуществимой задачей Секрет создания законченной половины продукта вместо недоделанной половины — снизить количество функций. Каждый раз, когда вы решаете добавить новую особенность или возможность, вы принимаете ребенка. Вам приходится заставлять вашего малыша делать целую цепь событий (например, проект, выполнение, испытание, и т.п.). И каждый раз вы натыкаетесь на это. Не будьте подпевалой Сделайте добавление функций, трудно осуществимой задачей. Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально. Если запрос на функцию постоянен, мы слушаем, но не действуем. Мы только знаем, что настало время взглянуть на это глубже. И только затем мы начинаем рассмотрение особенности в реальном окружении. И что вы говорите людям, которые жалуются, когда вы не принимаете их идею функции? Напоминаем им, почему им нравится приложение в первоначальном виде: «Вам нравится это, потому что не делает 100 других вещей». Скрытые затраты Учитывайте скрытую цену новых функций и особенностей Даже если функция уже работает, вам все еще нужно учитывать ее скрытые затраты. Например, у нас есть запрос на то, чтобы добавить к Basecamp таблицу встреч. Это кажется достаточно простым, пока вы не рассмотрите это ближе. Подумайте обо всех различных элементах. Таблица встреч могла бы содержать: место, время, список людей, приглашения по электронной почте, календарь, интеграцию, документацию, поддержку, и т.п. Ради этого придется изменить соответствующие скриншоты, страницы тура, faq/помощь, условия обслуживания, интегрировать с другими возможностями и многое другое. Перед тем как добавить функцию, задумайтесь, сколько это с виду простое решение может принести головной боли. Для каждой новой функции от вас потребуется: 1. Сказать «нет». 2. Вынудить функцию доказать свое значение. 3. Если снова «нет», уже конец. Если, «да», продолжайте… 4. Сделайте эскиз экрана/интерфейса. 5. Спроектируйте экран/интерфейс. 6. Закодируйте. 7-15. Испытание, испытание, испытание, испытание… 16. Проверка текста помощи, возможно, его нужно изменить. 17. Обновите ознакомительный тур продукта (если необходимо). 18. Обновите маркетинговую копию (если необходимо). 19. Обновите условия обслуживания (если необходимо). 20. Проверка, на то, какие предыдущие обещания были затронуты. 21. Проверка, на то, как это воздействует на общую структуру. 22. Запустите. 23. Затаите дыхание. Можете ли управлять этим? Создавайте то, чем можете управлять Если вы запускаете партнерскую программу, должны ли вы управлять системой учета и выплат? Возможно, вы должны просто позволять людям зарабатывать без членских взносов, сообщений и отправке по почте проверок каждый месяц. В состоянии ли вы отдать 1 гигабайт пространства бесплатно только потому, что Google это делает? Возможно, вы должны начать со 100 МБ, или только обеспечить место для платежных счетов. Практичный совет: Создавайте конструкции и услуги, которыми вы можете управлять. Легко давать обещания. Намного сложнее сдержать их. Сделайте то, что вы можете подтвердить фактически, организационно, стратегически, и материально. Решение задач пользователей Создавайте программное обеспечение для общих решений и поощряйте то, когда люди ищут собственные решения Не навязывайте людям решения. Вместо этого пусть каждый будет генералом над программным обеспечением и сможет найти собственное решение проблемы. Предоставьте людям то, с помощью чего достаточно просто разрешить их собственные проблемы и найти собственный путь. Когда мы создавали Ta-da List, мы намеренно пренебрегли многим. Нет никакой возможности отметить точно дату, нет никакой возможности, чтобы категоризировать элементы, и т.п. Мы создавали инструмент, чистым и упорядоченным, позволяя людям творчески подходить к решению задач. Люди, выясняли, как решить проблемы самостоятельно. Если они хотели добавить дату к элементу to-do, они могли добавить ее (точно так: April 7, 2006) непосредственно в сам элемент. Если они хотели добавить категорию, они могли добавить так [Книги], тоже непосредственно в сам элемент. Идеально? Бесконечно гибко? Да. Если бы мы пробовали построить программное обеспечение, для того чтобы управлять этими сценариями, мы сделали бы менее полезный продукт для всех этих случаев. Сделайте лучшую работу над основой проблемы. Люди найдут свои собственные решения и соглашения в пределах вашей общей структуры. Забудьте о запросах функций Пусть клиенты напоминают вам, что важно Клиенты хотят, чтобы все было. Они будут присылать вам лавину запросов на новые функции. Просто проверьте форумы наших продуктов. «Мы знаем, что это легко добавить» или «это можно сделать чуть лучше» или «это добавление займет всего несколько секунд» или «если вы добавите это, я заплачу в два раза больше» и так далее. Конечно, мы не придираемся к этим людям. Мы поощряем их и слушаем. Любую свою продукцию мы начинаем делать с запроса клиента. Но, мы упомянули, что ваш первый ответ на любой запрос должен быть — «нет». А что вы делаете со всеми этими запросами, которые к вам поступают? Где вы их храните? Как вы управляете ими? Вы этого не делаете. Просто читаете их, а затем отбрасываете. Да, читайте их, отбросьте, и забудьте. Это звучит богохульно, но то, что важно будет продолжать поступать и дальше. То, что вам нужно помнить. То, что действительно является сутью. Не волнуйтесь об отслеживании и сохранении каждого запроса. Пусть ваши клиенты будут вашей памятью. Если это действительно стоящая функция, они будут напоминать вам, пока вы не сможете не забыть. Как мы пришли к такому выводу? Когда мы запустили Basecamp мы отслеживали каждый запрос на функцию или особенности Basecamp, составляя to-do лист. Когда запрос был повторным, но от кого-то другого, мы обновляли список и ставили приоритет (II или III или IIII, и т.п.). Мы полагали, что наступит день, когда мы рассмотрим этот список и возьмемся за работу, за те запросы, у которых самый высокий приоритет. Но, правда в том, что мы никогда не смотрели на эти списки снова. Мы уже знали, что нужно сделать, потому что наши клиенты постоянно напоминали нам об этом, повторяя одинаковые запросы снова и снова. Не было никакой потребности в списках или в уйме анализа, потому что это все происходило в реальном времени. Вы не можете забыть то, что важно, когда вы сталкиваетесь с этим каждый день. И еще одна вещь: Просто, потому что несколько людей запрашивают что-нибудь, не означает, что вам придется это включать в разработку. Иногда нет ничего лучше того, чтобы промолчать лишний раз и поддерживать собственное виденье продукта. Чего не хотят Спросите людей, чего они не хотят Большинство обзоров программного обеспечения и вопросов исследований сосредоточено вокруг того, что люди хотят от продукта. «Какая особенность отсутствует?» «Если вы могли добавить только одну вещь, чем это должно быть?» «Что сделало бы этот продукт, более полезным для вас?» Что на обратной стороне монеты? Почему не спрашивают людей, чего они не хотят? «Если вы могли убрать одну особенность, что это было бы?» «Что вы не используете?» «Что делаете дольше всего?» Больше «не» в вопросах. Иногда лучшее, что вы можете сделать для клиентов — опустить какую-нибудь функцию. Новшества приходят из сказанного «нет» |
|
||
