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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTML макеты

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

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

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

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

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

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

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

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

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

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

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

Сделайте выбор

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

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

Решения временны

Сделано! Это волшебное слово. Когда вы уже сделали — вы получили опыт и можете идти дальше.

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

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

Испытывайте ваше приложение в реальных условиях

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

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

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

Не нужно никаких бета-версий. Версия должна быть одной. Бета-версия допускает поверхностное использование, а реальная версия получает полное и реальное использование.

Разделяйте

Сокращайте время разработки, разбивая месяцы на недели. Если проект требует 12 недель работы, разбейте его на 12 небольших кусков;. Если проект требует 30 часов работы, разбейте на куски по 6-10 часов и делайте каждый шаг за один раз, за один день.

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