Павел Гук
27 февраля 2014

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



Павел!

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

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

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

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

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

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

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

Я подхожу к разработке бэкенда как к разработке АПИ. То есть как к набору функций, который отдаёт данные для построения страниц. В какой-то степени это похоже на МВЦ. Само АПИ абстрактно, а от него наследуется АПИ для веб-сайта. В будущем от абстрактного АПИ можно быстро унаследовать, скажем, мобильное. В парадигме АПИ легче поддерживать версионность и постепенно вводить новые функции на новых страницах, не ломая весь сайт.

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

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

P. S.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
P. P. S.

Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии

Евгений Ширин
27 февраля 2014

Перед началом создания сайта мы пишем подробное техническое задание (ТЗ), которое состоит из следующих частей: структура (перечень всех разделов и подразделов с кратким описанием функционала); ТЗ дизайнера (описание главной, типовых страниц и функциональных элементов); ТЗ верстальщика (основные требования); ТЗ программиста (детальное описание работы всех сервисов и функций плюс структура полей базы данных); ТЗ контент-менеджера (перечень и объём текстовой и графической информации для каждого раздела или страницы). При таком подходе все участники проекта могут работать параллельно.

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

Самый главный подводный камень — если в ТЗ не всё учтено или допущена ошибка.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

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




Недавно всплыло

4 Начальник считает, что перед встречей нужно обязательно разработать несколько вариантов предложений 6 4 Как сделать плавный переход от общения с администратором к директору? 1