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

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

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

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

Мы применяем принципы «бэкенд вперёд» и «спецификации для фронтенда».

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

Коля Митин о разработке бэкенда:

Спецификации — инструмент постановки задачи. Они появляются в момент передачи макетов в работу и детализируют дизайнерские решения. Критически важно, чтобы спецификации написали сами разработчики, так будет соблюдён принцип «исполнитель понимает задачу».

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