Павел!
По сравнению с домами и космическими шаттлами, программное обесечение изменять легко и недорого. Если не использовать это преимущество, конкуренты вас обойдут. Так что, конечно, разработка и дизайн должны идти параллельно, постоянно взаимодействуя друг с другом и улучшая финальный продукт.
Важен настрой команды. Когда я прошу разработчиков подготовить техническую часть плана проекта, мне часто говорят, что без макетов этого сделать невозможно. Понятно, почему так происходит — люди не любят нарушать обещаний, а последовательная организация этапов проекта даёт ощущение безопасности: разработка начинается, когда макеты готовы и можно оценить трудоёмкость.
Однако «готовность» макетов — это самообман. Макеты — это всего лишь промежуточные документы, которые после завершения проекта идут в мусор, в лучшем случае оседая в портфолио дизайнеров. Цель проекта — продукт, и если выяснится, что для продукта полезно что‑то изменить, макеты, описания, спецификации и любые другие договорённости должны быть безжалостно пересмотрены. В этом нет ничего дурного. Это не нарушение обещаний. Наоборот — это ответственный подход, просто не всем легко признать ничтожность процесса в сравнении с результатом.
Правда в том, что разработчикам всегда приходится оценивать работу, исходя из примерного описания задачи. Макеты уточняют описание, но дожидаться их убыточно для бизнеса. Текстовое описание задачи позволяет сделать приемлемую оценку и не ждать дизайнеров несколько недель.
Мы применяем принципы «бэкенд вперёд»
Некоторые части программного обеспечения трудно модифицировать. Обычно это сложные механизмы и алгоритмы (нарисовать Гугль проще, чем реализовать) или фундаментальные архитектурные решения. Поэтому работа над бэкендом начинается с опережением — по текстовому описанию задачи разработать прототип «без дизайна» и проверить на нём основные идеи.
Коля Митин о разработке бэкенда:
Я подхожу к разработке бэкенда как к разработке АПИ. То есть как к набору функций, который отдаёт данные для построения страниц. В какой‑то степени это похоже на МВЦ. Само АПИ абстрактно, а от него наследуется АПИ для веб‑сайта. В будущем от абстрактного АПИ можно быстро унаследовать, скажем, мобильное. В парадигме АПИ легче поддерживать версионность и постепенно вводить новые функции на новых страницах, не ломая весь сайт.
Спецификации — инструмент постановки задачи. Они появляются в момент передачи макетов в работу и детализируют дизайнерские решения. Критически важно, чтобы спецификации написали сами разработчики, так будет соблюдён принцип «исполнитель понимает задачу».
Дизайнеры готовят статические слепки будущей системы, а разработчики видят всю картину в динамике, поэтому хорошо представляют сценарии, частные случаи. Так что, если при согласовании спецификаций разработчики задают трудные вопросы, а фичи упрощаются и исчезают, значит вы всё делаете правильно.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
