проектах, видимые с большого расстояния. Вместе, те предположения, и несколько другие, служили нам основой.
Эта стадия состоит из вопросов. Что приложению нужно делать? Как мы будем знать когда это полезно? Что точно мы собираемся сделать? Это высокоуровневые идеи, а не обсуждение деталей, таких как расстояния в пикселях от кнопки до чего-то еще. На этой стадии видны только значимые детали.
Бумажные эскизы
Быстрые, простые эскизы — это самый экономичный способ начать проектирование. Выводите свои идеи на бумагу, пусть и небрежным почерком. Цель этой стадии превратить мысли и понятия в набросок интерфейса проекта. Этот шаг — экспериментирование, в котором нет ошибок или неправильных ответов.
HTML макеты
Делайте html версии того, что изображено на эскизах. Получите то, что уже будет отдаленно напоминать программу на экране.
Для Basecamp мы сначала сделали макет написания сообщения и макет редактирования сообщения. И дальше отталкивались от этих макетов.
Не пишите никакого программного кода. Просто стройте макеты с использованием html и css.
Закодируйте это
Когда макет демонстрирует достаточное количество необходимой функциональности, можно приступать к программированию.
В процессе этого, помните, что вас ждут многократные повторения и оставляйте проект гибким. Не стесняйтесь отбрасывать специфические шаги и начинать их потом. Главное сразу исключить плохой и не продуманный код.
Избегайте настроек
Примите решение о деталях
Вы сталкиваетесь с ограничением: сколько сообщений должно быть на странице? Ваша первая мысль сделать выбор 25, 50 или 100. Это легкий выход. Просто примите решение, как сделать лучше. И выберите одно число.
Настройки — уход от пути принятия жестких решений
Чтобы выбрать в программе лучшие решения — для этого есть вы. Не перекладывайте принятие решений на плечи клиентов. Для клиентов экраны настроек с бесконечным количеством выбора — головная боль. Клиенты не должны думать о каждой мелочи, за это ответственны вы.
Настройки — зло, потому что они раздувают программное обеспечение и требуют больше кода. А в реальности очень часто настройками никто даже не пользуется. Настройки подразумевают, что вы мало знаете о том, как должны быть расположены блоки на странице, сколько сообщений должно быть выведено на страницу и т.п.
Сделайте выбор
Примите простые решения. Это — то, что мы сделали в Basecamp. Число сообщений на страницу составляет 25. На странице краткого обзора показаны последние 25 элементов. Сообщения сортируются в хронологическом порядке. Пять, последних проектов показываются в dashboard. Нет вариантов выбора.
Да, возможно, сделали плохой выбор. Но если это так, то люди будут жаловаться и всегда можно будет выбор подкорректировать. Getting Real — это возможность измениться на лету.
«Сделано!»
Решения временны
Сделано! Это волшебное слово. Когда вы уже сделали — вы получили опыт и можете идти дальше.
Но подождите, а что если вы сделали что-то неправильно? Это плохо. Но это не нейрохирургия, это — сетевое приложение. Нет ничего страшного. Не нужно только замедлять процесс анализом ошибок. Вместо этого оцените важность и идите дальше.
Признайте, что это решение было временным. Признайте, что ошибки будут и дальше. Реализуйте только возможность быстро исправлять свои ошибки.
Тестируйте в диких условиях
Испытывайте ваше приложение в реальных условиях
Нет никакой замены реальных людей, использующих ваше приложение в действительности. Получите реальные данные. Получите реальную обратную связь. Затем улучшайте, основываясь на этой информации.
Тесты в лабораториях не отражают действительность. Если вы стоите над кем-то и проверяете, вы не получите точного отражения работы. Когда действия человека записываются на камеру, он все равно осторожен. Когда кто-нибудь другой наблюдает, люди особенно осторожны в том, чтобы не наделать ошибок.
Вместо этого, тестируйте в реальной работе, в реальном технологическом процессе, где реальные люди подвергнут функционал нагрузкам и заполнят приложение реальными данными. Только так вы получите реальные результаты.
Не нужно никаких бета-версий. Версия должна быть одной. Бета-версия допускает поверхностное использование, а реальная версия получает полное и реальное использование.
Сокращайте время
Разделяйте
Сокращайте время разработки, разбивая месяцы на недели. Если проект требует 12 недель работы, разбейте его на 12 небольших кусков;. Если проект требует 30 часов работы, разбейте на куски по 6-10 часов и делайте каждый шаг за один раз, за один день.
Вы сталкиваетесь с большой проблемой, которую уже не в состоянии держать в голове. Разделите ее на кусочки, каждый из которых сможете обдумать с легкостью и решить за один шаг.
