37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real


Введение глава 1

Что такое Getting Real?

Хотите создать успешное веб-приложение? Тогда пришло время для подхода "Getting Real", легковесного, быстрого и в целом лучшего пути создания программного обеспечения.

Выгоды Getting Real

Getting Real дает лучшие результаты из-за того, что заставляет вас решать именно существующие проблемы, а не фантазировать на тему этих проблем. Другими словами, он заставляет вас иметь дело с реальностью. Getting Real отказывается от функциональных спецификаций и подобных эфемерных документов в пользу реальных экранов. Функциональная спецификация -- это притворство, иллюзия договоренности, тогда как действительная веб-страница -- это реальность, то, что будут видеть и использовать ваши клиенты. Только это и имеет значение и с помошью Getting Real вы достигнете этого гораздо быстрей, принимая решения на основе действительных вещей, а не абстрактных понятий. Наконец, Getting Real -- это подход, идеальный для веб-приложений. Дедовский способ поставки коробочных приложений вкупе с последующим двухгодичным ожиданием обновления уже изживает себя. В отличие от устанавливаемых у клиента приложений, их веб-аналоги могут развиваться и улучшаться каждый день. И Getting Real использует этот факт на полную катушку.

How To Write Vigorous Software

Предложение не должно содержать ненужных слов, абзац не должен содержать ненужных предложений. Точно так же рисунок не должен содержать ненужных линий и машина не должна содержать ненужных частей. Но это не значит, что писатель должен делать каждое предложение коротким или опускать все детали и лишь поверхностно описывать героев. Нет. Это значит, что каждое слово должно быть необходимым.

—"The Elements of Style", Вильям Дж


Больше никаких тяжёлых программ

Типичный подход: длительный бюрократический процесс, направленный в основном на прикрывание задниц. Типичный результат: раздутое, посредственное и быстрозабывающееся программное обеспечение.

Getting Real избавляется от…

Вам не нужна куча денег, огромная команда или длительный цикл разработки для создания классного программного обеспечения. Всё это для медленных, неясных и неизменных приложений. У Getting Real другой подход.

Здесь вы узнаете...

Фокусируемся на крупных масштабах идеи. Мы не хотим нагружать вас кусками кода и CSS-трюками. Будем придерживаться главных идей и философии, которая управляет процессом Getting Real.

Эта книга написана для вас?

Вы предприниматель, дизайнер, программист или маркетолог, работающий над большой идеей.

Вы понимаете, что старые правила уже не нужны. Выпускаете свои программы на CD каждый год? Как 2002. Номенклатура версий? В мусорку. Вы должны создавать, начинать и достигать.

Или, может быть, вы еще не знакомы с быстрой разработкой и бизнес-структурами, но хотите узнать об этом.

Если вы подходите под эти описания, значит эта книга для вас.

Замечание: Хоть внимание и акцентируется на разработке веб-приложений, идеи применимы к действиям вне этой сферы. Предложения маленьких групп, быстром создании макетов, ожидание итераций и многие другие могут служить руководством, запускаете ли вы бизнес, пишете ли книгу, проектируете ли веб-сайт, записываете ли альбом или делаете что-то другое. Как только вы начнёте следовать принципам Getting Real в одной области жизни, вы поймёте, как это можно использовать в других областях.


О 37signals

Что мы делаем

37signals — небольшая команда, создающая простое и фокусированое программное обеспечение. Наши продукты помогут вам организовать совместную работу и быть более организоваными. На данный момент, больше 350 тысяч пользователей используют наши веб-приложения для реализации своих целей. Наши приложения никогда вас не подведут.

Наш принцип работы

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

Наши продукты

На момент публикации этой книги мы имеем пять коммерческих продуктов и один OpenSource-фреймворк для веб-приложений.

Basecamp управляет проектами. Вместо диаграмм Гантта, причудливых графиков и тяжёлых таблиц статистики Basecamp предоставляет форумы для общения, todo-листы, простое планирование, совместную работу. Пока многие согласны с тем, что это—лучший путь.

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

Backpack — альтернатива для тех, кому надо управлять своей жизнью. «Организация вашей жизни в 25 простых шагов». Персональный управляющий вашей информацией. Backpack — это просто страницы, заметки, задачи, напоминания по телефону и электронной почте. Это инновация в категории продуктов, которая страдает от status-quo-itis. Томас Вебер из Wall Street Journal назвал это лучшим продуктом в своём классе и Дэвид Погу из New York Times назвал это «очень крутым» организационным инструментом.

Writeboard позволяет вам писать и совместно использовать тексты. Это альтернатива «раздутым» текстовым процессорам, которые убивают около 95-ти процентов того, что вы пишете.

Ta-da List сохраняет списки задач и организует вас онлайн. Создайте списки для себя или совместно используйте их с другими. Нет способа проще, чтобы добиться своей цели. На данный момент создано более ста тысяч списков почти с миллионом задач.

Ruby on Rails, для раз40;аботчиков то, что надо. Открытый фрейморк на Ruby для быстрого и лёгкого написания реальных приложений. Rails занимается всей рутиной в то время, как вы сосредоточены на своей идее.


Протесты и оговорки

Некоторые ответы на ваши письма:

«У меня это не работает»

Getting Real — это система, которая работала именно для нас. То есть, идеи этой книги не применимы к каждому проекту на этой земле. Если вы разрабатываете оружейные системы, системы управления ядерными разработками, банковские системы или другие жизненно и финансово критичные системы, вам надо хорошенько подумать, перед тем как использовать эту методику.

И не надо выбирать: всё или ничего, даже если вы не можете использовать Getting Real полностью, здесь есть по крайней мере несколько идей, полезных для вас.

«Эту идею изобрели не вы»

Мы и не утверждаем, что изобрели эти методы. Многие из наших подходов, в той или иной форме, применяются давно. Не раздражайтесь, если вы нашли нечто такое, что уже читали на каком-то блоге или в книге, изданной лет 20 назад. Определённо, это возможно. Эти методы не принадлежат 37signals. Мы просто рассказываем вам, как мы работаем и что нам помогло.

«Вы всё видите в чёрно-белых цветах»

Потерпите нас. Мы считаем — лучше представить идеи резко, чем тихо шептать об этом на ухо. Если это кажется дерзким и высокомерным, пусть так и будет. Мы предпочитаем быть «провокаторами», чем постоянно ныть «может быть, если…». Конечно, будут времена, когда эти правила должны будут измениться или исчезнуть. И некоторые из этих тактик, возможно, не подходят к вашей ситуации. У вас есть своя голова на плечах, решайте сами.

«В моей компании это не будет работать»

Наверное вы слишком большие для Getting Real? Даже Microsoft использует Getting Real, сомневаемся, что ваша компания больше них.

Даже если ваша компания всё ещё создаёт долгосрочные цели с большими командами, способы достигнуть Getting Real всё ещё есть. Только надо это делать по-тихоньку. Когда слишком много вовлечённых людей, ничего не получится. Чем вас меньше, тем быстрее и лучше можно сделать всё.

Естественно, это может потребовать некоторых продаж. Предоставьте Getting Real вашей компании. Покажите им эту книгу. Покажите им реальные результаты, которых вы можете достигнуть быстрее и с меньшей командой.

Объясните, что Getting Real — ничтожные риски, требует мало инвестиций, чтобы проверить его в деле. Посмотрите, сможете ли вы отказаться от «фундаментальных» понятий, чтобы доказать возможности Getting Real на маленьком проекте. Продемонстрируйте результаты.

Или, если вы действительно хотите быть напористым, идите на хитрость. Сделайте всё тихо и продемонстрируйте реальные результаты. Этот подход использовала команда Start.com, используя Getting Real в Microsoft.

Свободное плавание Start.com (проект Microsoft):

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

Это может быть правильным подходом для коробочного ПО, но в интернете мы имеем невероятное преимущество. Просто попробуйте это! Позвольте пользователю говорить вам, правильно это или нет. Вы можете исправить и обновить это хоть сразу! Нет ничего важнее слов клиента — сопротивление убеждению участвовать на долгих встречах.

Легче сказать, чем сделать:

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

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

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

Как только вы начнёте всё делать быстро и реагировать на обратную связь с клиентом, вы установите прочную связь с клиентом. Помните, что цель состоит именно в том, чтобы получить постоянного клиента, создавая то, что они хотят.

— Саназ Ахари, менеджер Start.com, Microsoft.

Начало глава 2

Делайте меньше

Меньше соревнуйтесь

Народная мудрость гласит: чтобы подавить своих конкурентов, вы должны переиграть их. Если у них четыре возможности, у вас их должно быть пять, пятнадцать, двадцать… Если они тратят N, то вы должны потратить NN. Если у них есть 20, то у вас должно быть 30.

Это — тупик. Дорогой и параноидальный путь создания продуктов. Защищающиеся, параноидальные компании не могут предположить, что остаются позади. Они не лидеры, а последователи.

Если вы хотите сделать свою компанию ведомой, а не ведущей, вы можете прекратить читать эту книгу прямо сейчас.

Так что же делать тогда? Ответ: меньше. Сделайте меньше чем ваши конкуренты, чтобы ударить по ним. Решайте простые проблемы и оставьте сложные, противные проблемы всем остальным. Вместо превосходства попробуйте делать недостаточно.

Мы будем раскрывать понятие «меньше» в этой книге, но для начинающих это:


В чём ваша проблема?

Разрабатывайте ПО для себя

При создании программ большую часть времени будет занимать решение ваших собственных проблем. Вы и будете тем самым потенциальным клиентом, соответственно и знание о необходимом у вас уже есть. Это даёт вам отличное начало для последующего распространения продукта.

Главное здесь — понять, что вы не одни. Если у вас есть проблема, вероятно сотни тысяч других людей находятся в том же положении. Это ваш рынок. Это ведь не сложно?

Basecamp был создан при решении проблемы: как студия дизайна, мы нуждались в простом способе общения с нашими клиентами о проектах. Мы начали это делать через экстранет, который мы обновляли вручную. Но изменение HTML каждый раз при обновлении проекта — не самое приятное занятие. Эти проектные сайты всегда казались устаревшими и, в конечном счёте, были заброшены. Это расстроило нас, потому что оставили нашу работу неорганизованной и без общения с клиентами.

Таким образом, мы пришли к рассмотрению других вариантов. Каждый продукт либо не предоставлял возможностей, в которых мы нуждались либо был сложен, имел кучу возможностей, которые не представляли для нас интереса: составление счетов, жёсткое управление доступом, диаграммы, графики… Мы знали, что есть лучший путь. Итак, мы решили создать собственное приложение.

Если вы решаете собственную проблему, вы создаёте инструмент с душой. И это является ключевым. Это означает, что вы сделаете всё отлично. И это является лучшим вариантом.


Финансируйте себя сами

Деньги извне — план »B«

Целью многих стартапов является привлечение денежных средств инвесторов. Но помните, если вы принимаете помощь инвесторов, вы несёте ответственность перед ними. Ожидания от стартапа вырастут. Инвесторы довольно быстро потребуют свои деньги обратно. Они (деньги) будут превыше качества разрабатываемого продукта.

Сейчас, чтобы начать, не требуется многого. Аппаратные средства дешевы и большое количество ПО бесплатно и имеет открытые исходные коды. И страсть не приходит с ценником.

Так что сделайте всё, что вы можете с теми деньгами, что уже у вас есть. Усиленно думайте и расставьте приоритеты. Что вы можете сделать с тремя людьми вместо десяти? Что вы сделаете с 20 тысячами долларов вместо 100 тысяч? Что вы сделаете за три месяца вместо шести? Что, если вы продолжите выполнять вашу ежедневную работу и одновременно будете создавать ваше приложение на стороне?

Ограничения заставляют думать творчески

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

Ограничения также вынуждают развивать идею как можно скорее — ещё одна хорошая вещь. Месяц или два обдумывайте идею и поймите, стоит ли она того. Если «да», и вы будете быстры и жизнестойки, вам не понадобятся инвесторы. Если ваша идея еще «не созрела», вам придётся вернуться к чертежам. По крайней мере, теперь вы узнаете какие будут препятствия, не потратив на это много времени. И сможете легко отступить.

Если вы будете создавать ПО лишь ради быстрых денег — увидите, что быстрая прибыль маловероятна. Так что сосредоточьтесь на создании качественного инструмента, с которым ваши клиенты захотят работать в течении долгого времени.

Два пути

Джейк Уолкер создал одну компанию при помощи инвестора (Disclive) и другую — без его помощи (The Show). Он делится различиями между этими путями:

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

С The Show мы поняли, что можем создать намного лучший продукт с меньшими затратами. Только на это понадобится больше времени. Мы рисковали небольшим количеством собственных денег и ожидали, что люди на энтузиазме будут стремиться к качеству и скорости работы. И компания осталась (и, вероятно, продолжит быть) с небольшим оборотом. Начиная с первого проекта мы полностью были на самообеспечении. Из-за маленьких сроков работы с клиентами у нас вообще не было необходимости вкладывать действительно немаленькие средства в бизнес. И мы хотели не вырастить бизнес и продать его, а развивать его и продолжать извлекать из этого прибыль.

— Комментарий на блоге Signals vs. Noise.

Фиксируйте время и бюджет, делайте возможности гибче

Запускайте вовремя и согласно смете

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

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

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

В начале лучше будет меньше запланированных возможностей, чем посредственным, громоздким и с кучей дыр безопасности. Оставьте волшебство Копперфильду. У вас реальный бизнес и реальный продукт.

Вот выгоды гибких возможностей и фиксированных времени и бюджета.

Расставление приоритетов

Выясните, что действительно важно. Что сподвигло на создание продукта? Это вызовет ограничения, которые сподвигнут вас на принятие быстрого, точного и жёсткого решения вместо тупого «мямления».

Действительность

Фиксация ожиданий — ключевой момент. Если вы фиксируете время, бюджет и возможности, вы не поставите их выше качества. Несомненно вы можете поставить что-то, но что именно?

Гибкость

Способность изменяться является ключевой. Жёсткие рамки не позволят изменяться. Добавление гибких возможностей приведёт к альтернативам, основанным на вашем опыте разработке продуктов. Гибкость — ваш друг.

Рекомендуем сократить возможности. Лучше сделать половину продукта, но качественно, чем недоделку.

Раз, два, три...

Возможно ли выполнить проект за год до намеченной даты? Когда-нибудь, наверное.

—Фред Брукс, инженер ПО и программист.

Заведите себе врага

Боритесь

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

Когда мы решили создать систему управления проектами, мы знали, что MS Project был гориллой в комнате. Боясь горилл, мы использовали это для мотивации. Мы решили, что Basecamp будет ему полной противоположностью, анти-Project.

Мы поняли, что управление проектом — это не диаграммы и графики, отчёты и статистика; это общение. Это также не менеджер проектов, сидящий высоко и раздающий проектные планы. А тот, кто несёт ответственность и делает проектную работу.

Нашими врагами были Диктаторы Управления Проектами, которые имели обыкновение «бить кнутом». Мы хотели демократизировать управление проектом, сделать так, чтобы каждый был его частью (включая клиента). Проекты становятся лучше, когда у каждого есть интересы в нём.

Когда начали работу над Writeboard, мы знали, что есть конкуренты этому продукту с гораздо большим количеством возможностей. Таким образом мы решили выделить «простоту» вместо этого. Мы создали приложение, которое позволило людям легко делиться идеями и сотрудничать, без увязания в несущественных особенностях. Если что-то было несущественным, мы отказывались от этого. А через три месяца после запуска было создано более чем 100 тыс. Writeboard-ов.

Когда мы начали работу над Backpack, нашими врагами были структура и твёрдые правила. Люди должны организовывать информацию как им удобно, не основываясь на всеобщих убеждениях «как надо».

Бонус, который вы получаете при наличии врага — весьма ясное маркетинговое сообщение. Людей топит конфликт. И они также сравнивают продукт с другими продуктами. Выбирая врага, вы даёте людям то, что они хотят увидеть. И они не только будут понимать ваш продукт лучше и быстрее, они встанут на вашу сторону. Это безошибочный способ получить внимание и зажечь страсть.

Исходя из всего сказанного — важно быть не слишком одержимым борьбой с врагом. Тщательно анализируйте другие продукты и вы будете ставить ограничения своим идеям. Наблюдайте, и только потом двигайтесь к собственному видению и к собственным идеям.

Не следуйте за лидером

Специалисты по маркетингу (и все люди) хорошо «обучаются» следовать за лидером. Естественный иснтинкт должен выяснить, что работает для борьбы, а затем пробуйти превзойти это — чтобы быть дешевле своего конкурента, который конкурирует ценой, или быстрее, если он конкурирует скоростью. Проблема в том, что как только потребитель купил чью-либо неверную историю и верит этой лжи, убеждать его переключиться — то же самое, что убеждение его в том, что он был неправ. А люди очень не любят признавать свою неправоту.

Вместо это расскажите другую историю и убедите его, что эта ваша история важнее, чем история, которой он сейчас верит. Если ваше соревнование в том, кто быстрее — вы должны стать более дешёвым. Если кто-то продаёт историю здоровья, вы должны продать историю удобства. Не только говоря «мы более дешёвые», но и предоставляя реальную историю, отличающуюся от существующих.

— Сет Годин, автор/предприниматель, Be a Better Liar.

В чём ключевая проблема?

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

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

— Майкл Рейнинг, соучредитель MindValley & Blinklist.

Никакой рутины

Ваша страсть или её нехватка будет ясно видна

Чем меньше в вашем приложении рутины — тем лучше.

Если рутинной работы немного и она управляема — вы можете наслаждаться.

Если ваше приложение не волнует — это плохо. Если вы делаете это только из-за денег — это проявится. И если вы обожаете свое приложение — это проникнет в конечный продукт. Люди умеют читать между строк.

Присутствие страсти

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

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

— Кой-Вин, Subtraction.com и соучредитель Behavior LCC.

Пекарня

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

— Ян Маккэй, член Fugazi и совладелец Dischord Records.

Оставайтесь небольшими глава 3

Меньше размеры

Чем вы беднее, тем проще это изменить

Чем больше объект, тем больше нужно энергии для его изменения. Это так же верно в деловом мире, как и в обычном.

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

Размеры увеличивают:

Уменьшить размеры позволяют:

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

К примеру, давайте представим одну маленькую компанию, которая выпустила продукт с небольшим набором функций, и компанию, у которой есть продукт с обширным функционалом. Далее возникает новая технология, например, AJAX, или новая идея, как, например, теги. Кто из них в состоянии быстрее приспособить эти технологии к своему продукту? Команда с огромным проектом, кучей функций и планом на год, или команда с маленьким продуктом и более органичным подходом, который гласит «давайте будем делать то, что нам нужно сделать прямо сейчас»?

Очевидно, что небольшая компания находится в лучшем положении и лучше приспосабливается к реальным требованиям рынка. Более крупная компания будет, вероятно, будет обсуждать изменения или проталкивать их через бюрократическую машину еще долго после того, как маленькая компания уже все сделает. Небольшая компания на два шага впереди, в то время как большая компания все еще думает куда идти.

Ловкие, проворные и легковесные компании могут быстро менять свою бизнес-модель, продукт, его функции и маркетинг. Они могут делать ошибки и быстро их исправлять. Они могут менять приоритеты, и что самое важное — у них есть право передумать.


Снизьте стоимость перемен

Будьте гибкими, снижая препятствия для перемен

Перемены — ваш лучший друг. Чем выше их цена, тем меньше их вероятность. И если ваши конкуренты могут меняться быстрее вас, вы в крайне невыгодном положении. Если цена перемен становится слишком высока — вам конец.

Вот где бедность действительно поможет вам. Копеечная стоимость перемен — это то, что есть у маленьких команд по умолчанию, у больших команд этого не будет никогда. Вот тут большие ребята действительно завидуют маленьким ребятам. В большой организации на какое-то изменения потребуется неделя, а в малой — это займет всего один день. Это преимущество бесценно. Дешевые и быстрые перемены — секретное оружие малого бизнеса.

И помните: все деньги, весь маркетинг, все люди в мире не могут купить проворство, которое вы получаете уже от того, что вы невелики.

Непредсказуемость

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

«Непредсказуемость» происходит с середины 17-го столетия из латинского словосочетания «непредвиденный случай». Вы не можете спланировать это, но вы можете культивировать окружающую среду, в которой позволите этому случиться и извлечь из этого выгоду.

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

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

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

Чем больше жестких установок мы применяем, тем меньше места для творческих и необычных решений. Разрабатываете требования прежде чем как следует в них разберетесь, слишком рано оптимизируете код или изобретаете сложную навигацию и схемы действий до того, как пользователи увидят систему — результат один: усложненная, неразумная система вместо простой и элегантной, взявшей на вооружение неожиданность.

Будьте небольшими. Будьте проще. Позвольте вмешаться динамике и непредсказуемости.

— Эндрю Хант, The Pragmatic Programmers

Три Мушкетера

Используйте команду из трех человек для версии 1.0

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

Конечно, это вызов — создать продукт, имея лишь нескольких человек. Но если у вас правильная команда, это того стоит. Талантливым людям не нужны бесконечные ресурсы. У них есть энтузиазм. Их творческий потенциал можно использовать для решения проблем. Недостаток человеческого ресурса означает, что вам придется идти на компромиссы сразу — и это правильно. Это заставит вас раньше задуматься над приоритетами. И вы сможете сразу же наладить связь в команде, не беспокоясь о том, что кто-то останется за бортом.

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

Закон Меткалфа и проектные команды

Удерживайте команду насколько возможно маленькой. Закон Меткалфа, который гласит «полезность сети приблизительно равна квадрату численности пользователей этой сети», применительно к участникам команды обретает иной смысл: эффективность команды обратно пропорциональна квадрату количества ее участников. Я начинаю думать, что три человека — оптимально для версии 1.0… Начните с сокращения списка людей, которых вы хотите пригласить в команду, а затем сократите его снова.

— Марк Хедлунд, предприниматель-консультант в O'Reilly Media

Пути взаимоотношений

Пути взаимоотношений в маленьких командах проще, чем в больших. Если вы — единственный человек в проекте, взаимодействие происходит только между вами и клиентом. Если число людей в проекте увеличивается, возрастает и количество путей взаимоотношений. Их количество не возрастает последовательно, как увеличение численности людей, поток увеличивается многократно, пропорционально квадрату числа людей.

— Стив МакКоннелл, ведущий проектировщик ПО в Construx Software Builders Inc. (из статьи Less is More: Jumpstarting Productivity with Small Teams)

Принимайте ограничения

Пусть ограничения ведут вас к творческим решениям.

Многого недостаточно, чтобы не идти кругами. Мало времени. Недостаточно денег. Мало людей.

Это хорошо.

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

Когда в 37signals строили Basecamp, у нас было много ограничений:

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

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

Ограничения — часто замаскированы. Забудьте о вкладе капиталов с риском, длинном цикле релизов, и быстром найме людей. Вместо этого, работайте с тем, что у вас есть.


Будьте собой

Дифференцируйте себя от больших компаний, будьте дружественнее и доступнее

Много маленьких компаний делают ошибку в попытках действовать как большие. Как будто бы они не замечают свой размер. Это как слабость, комплекс, который нужно скрывать, и это слишком плохо. Быть маленьким фактически обладать огромным преимуществом, особенно, когда это касается коммуникации.

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

Есть также преимущества во внутренних коммуникациях. Нет никакой потребности в куче формальностей и многоразовых отчетах на все. Каждый в процессе может говорить открыто и честно. Это снимает оковы с потока идей — одно из самых больших преимуществ небольшой компании.

Будьте с гордостью, вызывающе правдивы

Вы, возможно, думаете, что клиента могут дурачить преувеличения числа штатных сотрудников в вашей компании или широта ваших предложений. Те, клиенты, которых вы действительно хотите, будут всегда искать правду — через интуицию или вычисления. Потом останется только смущение морально неоправданной лжи в прошлом, и ни одна из тех ситуаций не приведет к тому, что в бизнесе имеет значение: к взаимовыгодным отношениям с людьми, с теми, кто имел реальную потребность в предложенных услугах. Лучший курс — быть с гордостью, вызывающе правдивым и сообщать о точном размере компании и широте предложений.

— Khoi Vinh, Subtraction.com and co-founder of Behavior LLC

Всегда в любое время

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

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

— Edward Knittel, Director of Sales and Marketing, KennelSource

Приоритеты глава 4

В чем идея

Явно и точечно определите видение для вашего приложения.

Что ваше приложение должно делать? Это действительно все?

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

Это видение будет вести вас, и ваши решения держать на последовательном пути. Каждый раз, когда есть сомнения в решении, можно спросить себя: «Мы остаемся верными видению?»

Ваше видение должно быть кратким и содержать идею. Вот — виденье для каждого нашего продукта:

С Basecamp, например, виденье было таким: «Управление проектом — это коммуникация». Мы считаем, что эффективная коммуникация втягивает по инерции собственные инвестиции и силы в проект. Каждый получает работу в направлении общей цели. Мы знали, что Basecamp достигнет этого, все другие линии провалились бы.

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

Найдите свою большую идею и примите решение о видении, все маленькие решения в будущем станут проще и легче.

Философия Whiteboard

Andy Hunt и я делали debit card transaction switch. Главным требованием было, что потребитель дебетовой карты не должен иметь одну и ту же сделку, совершенную дважды. Другими словами, такая проблема считалась бы ошибкой и обрабатывалась бы только одна сделка.

Так что, мы написали об этом на нашем общем whiteboard: «Ошибка на пользу потребителей».

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

— Dave Thomas, The Pragmatic Programmers

Создавайте молитвы

Организациям нужны указательные столбы. Им нужен план; работникам каждый день нужно знать, когда они просыпаются, почему они собираются идти на работу. Этот план должен быть кратким и сладким, и затрагивать все: Почему вы существуете? Как это мотивируете? Я называю это молитвой — описание в трех-четырех словах причин, по которым вы существуете.

— Guy Kawasaki, author ( from Make Mantra)

Пренебрегайте деталями в начале

Работайте от большего к меньшему

Мы сумасшедшие до деталей.

Успех и удовлетворение находится в деталях.

Однако, успех не единственная вещь, которую вы найдете в деталях. Вы также найдете — застой, разногласие, встречи, и задержки. Эти вещи могут убить моральное состояние и снизить вероятность успеха.

Как часто вы сидите над одной строчкой кода в течение целого дня? Как часто ваша работа сделанная за один день не дала никакого прогресса? Это случается, когда вы сосредоточиваетесь на деталях, слишком рано. У взыскательного человека будет еще много времени на детали. Просто отложите это.

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

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

Дьявол в деталях

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

Вы должны получить пропорции для целого. А затем делать эскиз наибольших объектов, переходя к самым маленьким. Эскиз должен быть простым вплоть до этого пункта. Затем вы можете возобновить штриховку, которая приведет объем в чувство.

Вы начинаете только с трех тонов (светлый, средний, темный). Это будет тональный эскиз. Затем для каждой части вашего рисунка оцените три тональных тени и примените их. Сделайте это, пока объемов нет (требует многоразового повторения)…

Работайте от большего к меньшему. Всегда.

— Patrick Lafleur, Creation Objet Inc. (from Signal vs. Noise)

Проблема тогда, когда это проблема

Не тратьте бесцельно время на проблемы, которых у вас еще нет

Вам действительно нужно волноваться о вычислениях для 100 000 потребителей сегодня, если это будет у вас через два года?

Действительно вам нужно нанять восемь программистов, если сегодня нужно только три?

Действительно сейчас нужны 12 первоклассных серверов, если вы можете обойтись двумя на протяжении года?

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

Это было простым C8; отличным решением, без ненужных смет и усилий.

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

Совет: Принимайте решения вовремя, когда у вас есть доступ к реальной информации, которая необходима. Тем временем, вы сможете сосредоточить внимание на вещах, которые требуют непосредственной заботы.


Работайте с правильными клиентами

Найдите основной рынок для вашего приложения и сосредоточьтесь исключительно на нем

Клиент не всегда прав. Правда в том, что вам придется определять кто прав, а кто ошибается — в рамках вашего приложения. Хорошая новость в том, что интернет делает поиск правильных людей легче, чем когда-либо.

Если вы ориентируетесь на всех, вы не удовлетворите никого

Когда мы построили Basecamp, мы сконцентрировали свой маркетинг на дизайн студиях. Сузив рынок, мы увеличили вероятность привлечения страстных клиентов, которые, в свою очередь, проповедовали продукт как Евангелие (evangelize the product). Знайте, для кого ваше приложение действительно предназначается, и сконцентрируйтесь на их удовлетворении.

Лучший вызов, который когда-либо мы сделали

Решение нацелить Campaign Monitor строго на рынок сетевого проектирования был лучшим вызовом, который мы когда-либо сделали. Это позволило нам легко выделить особенности, которые были действительно полезны и важны. Мы привлекли больше клиентов, нацеливаясь только на тех, у которых есть подобные потребности. Они делают нашу работу, намного легче. Есть масса особенностей в Campaign Monitor, которые бесполезны для всех, кроме сетевого проектировщика.

Фокусировка на основном рынке также помогает намного легче распространить информацию о&;nbsp;вашем программном обеспечении. Теперь, когда у нас есть определенная аудитория, мы можем рекламироваться, в тех местах, где они часто бывают онлайн, издаем статьи, которые возможно, найдут интерес, и в общем строем сообщество вокруг нашего продукта.

— David Greiner, founder, Campaign Monitor

Расширяйтесь позже

У вас пока нет проблемы расширения

«Каким будет мое приложение, когда им будут пользоваться миллионы людей?»

Что? Ждите, пока это фактически не случится. Если вы достигли того, что огромное число людей, перегружают вашу систему — тогда ура! Это очень красивая проблема. Правда — подавляющее большинство сетевых приложений никогда не достигают этой стадии. И даже, когда вы достигните этого — обычно ничего страшного не происходит. У вас будет достаточно времени, чтобы приспособиться к проблеме. Плюс, вы будете иметь более реальные данные и эталонные тесты, чтобы выяснить к каким конкретно областям приложения требуются улучшения.

Например, у нас был запущен Basecamp на одном сервере в первый год. Поскольку мы шли с такой простой установкой, это потребовало всего неделю на осуществление планов. Мы не начинали с кластера в 15 боксов и не тратили месяцы на волнения о вычислениях и на подсчеты.

У нас были проблемы? Нисколько. Но мы также осознали, что большинство проблем, которых мы боялись, действительно не существовало, с чем были согласны и наши клиенты. Будьте честны с ними, они поймут. Вспоминая прошлое, мы рады тому, что не стали делать «совершенную установку» с задержкой во многие месяцы.

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

Поверьте, это не большая проблема расширяться, когда в этом есть необходимость.

Вам придется снова все переделать, так или иначе

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

— Dare Obasanjo, Microsoft

Делайте идейное программное обеспечение

Ваше приложение должно лавировать между потребностями

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

Мы думаем, что это ерунда. Лучшее программное обеспечение имеет свое виденье. Лучшее программное обеспечение лавирует между потребностями. Когда кто-нибудь использует программное обеспечение, они не только, ищут особенности, они ищут подход. Они ищут видение для решения своих задач. Решите, что такое — ваше виденье и идите с этим.

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

Хороший пример — оригинальный wiki проект. Ward Cunningham и друзья сознательно раздели wiki на многие сущности, которые считались раньше целым документом. Вместо отнесения каждого изменения к определенному человеку или документу, они переместили многое в визуальное представления. Они сделали содержимое. Им было не важно, кто пишет содержимое или когда это было написано. И это сделало свое дело. Это решение поощряет общий смысл общества, и оно стало ключевым ингредиентом в успехе Wikipedia.

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


Выбор функций глава 5

Наполовину, но закончено

Создайте половину продукта, но законченный продукт

Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное.

С Basecamp, мы начали только с секции сообщений. Мы знали, что это сердце приложения, так мы до поры до времени пренебрегли milestones, списками to-do, и другими элементами. Это позволило нам создать будущую основу при реальном использовании.

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


Это не имеет значения

Только суть

Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».

Когда мы запустили Campfire, мы слышали некоторые из этих вопросов от людей, впервые проверяющих продукт:

«Почему время показывается только каждые 5 минут? Почему нет времени в каждой линии чата?»

Ответ: Это не имеет значения. Как часто вам нужно отслеживать беседу с секундной или даже с минутной точностью? Конечно, не 95% времени. 5 минут вполне достаточно, поскольку какие-то меньшие промежутки времени — не имеют значения.

«Почему вы не позволяете форматирование текста жирным шрифтом, курсивным или выделение цветом в чатах?»

Ответ: Это не имеет значения. Если вам нужно сделать ударение на чем-нибудь используйте буквы верхнего регистра или поставьте несколько * (звездочек) вокруг слова или фразы. Эти решения не требуют дополнительного программного обеспечения, технической поддержки, дополнительной мощности обработки, и им не надо обучаться. Кроме того, форматирование в простом тексте чата не так важно.

«Почему вы не показываете общее число людей в комнате чата?»

Ответ: Это не имеет значения. Все имена внесены в список, так что вы знаете, кто есть в чате, но, какая разница, если это 12 или 16 человек? Если это не меняет ваше поведение, то это не имеет значения.

Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.

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


Начните ни с чем

Сделайте добавление новых функций, трудно осуществимой задачей

Секрет создания законченной половины продукта вместо недоделанной половины — снизить количество функций.

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

Не будьте подпевалой

Сделайте добавление функций, трудно осуществимой задачей. Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.

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

И что вы говорите людям, которые жалуются, когда вы не принимаете их идею функции? Напоминаем им, почему им нравится приложение в первоначальном виде: «Вам нравится это, потому что не делает 100 других вещей».


Скрытые затраты

Учитывайте скрытую цену новых функций и особенностей

Даже если функция уже работает, вам все еще нужно учитывать ее скрытые затраты.

Например, у нас есть запрос на то, чтобы добавить к Basecamp таблицу встреч. Это кажется достаточно простым, пока вы не рассмотрите это ближе. Подумайте обо всех различных элементах. Таблица встреч могла бы содержать: место, время, список людей, приглашения по электронной почте, календарь, интеграцию, документацию, поддержку, и т.п. Ради этого придется изменить соответствующие скриншоты, страницы тура, faq/помощь, условия обслуживания, интегрировать с другими возможностями и многое другое. Перед тем как добавить функцию, задумайтесь, сколько это с виду простое решение может принести головной боли.

Для каждой новой функции от вас потребуется:


Можете ли управлять этим?

Создавайте то, чем можете управлять

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

В состоянии ли вы отдать 1 гигабайт пространства бесплатно только потому, что Google это делает? Возможно, вы должны начать со 100 МБ, или только обеспечить место для платежных счетов.

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


Решение задач пользователей

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

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

Когда мы создавали Ta-da List, мы намеренно пренебрегли многим. Нет никакой возможности отметить точно дату, нет никакой возможности, чтобы категоризировать элементы, и т.п.

Мы создавали инструмент, чистым и упорядоченным, позволяя людям творчески подходить к решению задач. Люди, выясняли, как решить проблемы самостоятельно. Если они хотели добавить дату к элементу to-do, они могли добавить ее (точно так: April 7, 2006) непосредственно в сам элемент. Если они хотели добавить категорию, они могли добавить так [Книги], тоже непосредственно в сам элемент. Идеально? Бесконечно гибко? Да.

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

Сделайте лучшую работу над основой проблемы. Люди найдут свои собственные решения и соглашения в пределах вашей общей структуры.


Забудьте о запросах функций

Пусть клиенты напоминают вам, что важно

Клиенты хотят, чтобы все было. Они будут присылать вам лавину запросов на новые функции. Просто проверьте форумы наших продуктов.

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

Конечно, мы не придираемся к этим людям. Мы поощряем их и слушаем. Любую свою продукцию мы начинаем делать с запроса клиента.

Но, мы упомянули, что ваш первый ответ на любой запрос должен быть — «нет». А что вы делаете со всеми этими запросами, которые к вам поступают? Где вы их храните? Как вы управляете ими? Вы этого не делаете. Просто читаете их, а затем отбрасываете.

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

Как мы пришли к такому выводу? Когда мы запустили Basecamp мы отслеживали каждый запрос на функцию или особенности Basecamp, составляя to-do лист. Когда запрос был повторным, но от кого-то другого, мы обновляли список и ставили приоритет (II или III или IIII, и т.п.). Мы полагали, что будет один день, когда мы рассмотрим этот список и возьмемся за работу, за те запросы, у которых самый высокий приоритет.

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

И еще одна вещь: Просто, потому что несколько людей запрашивают что-нибудь, не означает, что вам придется это включать в разработку. Иногда нет ничего лучше того, чтобы промолчать лишний раз и поддерживать собственное виденье продукта.


Чего не хотят

Спросите людей, чего они не хотят

Большинство обзоров программных обеспечений и вопросов исследований сосредоточено вокруг того, что люди хотят от продукта. «Какая особенность отсутствует?» «Если вы могли добавить только одну вещь, чем это должно быть?» «Что сделало бы этот продукт, более полезным для вас?»

Что на обратной стороне монеты? Почему не спрашивают людей, чего они не хотят? «Если вы могли убрать одну особенность, что это было бы?» «Что вы не используете?» «Что делаете дольше всего?»

Больше «не» в вопросах. Иногда лучшее, что вы можете сделать для клиентов — опустить какую-нибудь функцию.

Новшества приходят из сказанного «нет»

Новшества приходят из сказанного «нет» тысячи вещам, чтобы убедиться в том, что мы не пойдем неправильным путем или не сделаем слишком много. Мы всегда смотрим на новые рынки, в которые могли бы войти, но, только говоря «нет», можем сосредоточиться на вещах, которые действительно важны.

— Steve Jobs, CEO, Apple ( from The Seed of Apple's Innovation)

Процесс глава 6

Гонка в запуске программного обеспечения

Сделайте что-нибудь и идите быстро

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

Хорошо сделать меньше, опустить детали, и сократить процесс так, чтобы выпустить программное обеспечение быстрее.

Как только вы выпустили программу, вы будете вознаграждены тем, что будете знать более точную перспективу как дальше продолжать развитие. Описания, каркас, даже html макеты, только приближают вас к этому. Запустите программное обеспечение в реальную работу.

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


Повторение и свобода

Работайте итерационно

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

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

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

Повторения приводят к свободе

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


От идеи к реализации

Перейдите от мозговых штурмов — к эскизам — к HTML — к кодированию

Вот процесс Get Real, который мы используем:

Мозговой штурм

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

Эта стадия состоит из вопросов. Что приложению нужно делать? Как мы будем знать когда это полезно? Что точно мы собираемся сделать? Это высокоуровневые идеи, а не обсуждение деталей, таких как расстояния в пикселях от кнопки до чего-то еще. На этой стадии видны только значимые детали.

Бумажные эскизы

Быстрые, простые эскизы — это самый экономичный способ начать проектирование. Выводите свои идеи на бумагу, пусть и небрежным почерком. Цель этой стадии превратить мысли и понятия в набросок интерфейса проекта. Этот шаг — экспериментирование, в котором нет ошибок или неправильных ответов.

HTML макеты

Делайте html версии того, что изображено на эскизах. Получите то, что уже будет отдаленно напоминать программу на экране.

Для Basecamp мы сначала сделали макет написания сообщения и макет редактирования сообщения. И дальше отталкивались от этих макетов.

Не пишите никакого программного кода. Просто стройте макеты с использованием html и css.

Закодируйте это

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

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


Избегайте настроек

Примите решение о деталях

Вы сталкиваетесь с ограничением: сколько сообщений должно быть на странице? Ваша первая мысль сделать выбор 25, 50 или 100. Это легкий выход. Просто примите решение, как сделать лучше. И выберите одно число.

Настройки — уход от пути принятия жестких решений

Чтобы выбрать в программе лучшие решения — для этого есть вы. Не перекладывайте принятие решений на плечи клиентов. Для клиентов экраны настроек с бесконечным количеством выбора — головная боль. Клиенты не должны думать о каждой мело