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

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

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

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

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

Basecamp: Управление проектом — это коммуникация

Backpack: Соединить детали вместе

Campfire: Чат группы против IM

Ta-da List: Конкуренция post-it запискам

Writeboard: Слово — массовое оружие (Word is overkill)

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

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

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

Философия Whiteboard

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

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

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

(— Dave Thomas, The Pragmatic Programmers)

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

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

(— Guy Kawasaki, author ( from Make Mantra))

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

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

* Пространство между объектами

* Совершенный цвет

* Совершенные слова

* Четыре линии кода вместо семи[10]

* 90% vs 89%

* 760px vs 750px

* $39/month против $49/month

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(— David Greiner, founder, Campaign Monitor)

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

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

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

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

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

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

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

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

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

(— Dare Obasanjo, Microsoft)

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

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

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

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

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

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

Примечания:

1

http://www.bartleby.com/141/strunk5.html

9

Более правильно, наверное, «мы сходим с ума от деталей» (прим. выполнившего форматирование)

10

Судя по всему, должно быть «четыре строки кода вместо семи» (прим. выполнившего форматирование)