Пример: клиенты в проектах

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

• Доступ клиентов. До появления этой функции модель доступа Basecamp работала по принципу «всё или ничего». Нам нужен был способ приглашать людей так, чтобы они видели лишь некоторые части проекта. Это существенно влияло на бэкенд и кеширование.
• Управление клиентами. Нам нужен был способ добавлять клиентов в проекты и возможность управлять ими отдельно от участников команды.

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

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

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

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

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

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

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

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

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