Сегодня мы поразмышляем о результатах проектирования.
Проектная документация
В процессе проектирования мы решаем, как должен работать будущий продукт, и документируем решения. Чем детальнее наши документы, тем лучше:
- Заказчик видит, что получит через несколько месяцев разработки, и может оценить, правильно ли его понял исполнитель;
- Исполнитель точнее оценивает объём работ;
- Документы становятся частью договора. Отклонение от изначальных проектных решений со стороны заказчика или исполнителя приведёт к изменению стоимости и сроков проекта.
Всё это повышает шансы проекта на реализацию.
Карл Вигерс, автор книги «Разработка требований к программному обеспечению» подсчитал, что на американском рынке разработки 40% бюджета проекта уходит на переделки из-за того, что заказчик и исполнитель плохо сформулировали требования к продукту и вообще не поняли друг друга.
По мнению Алексея Бородкина, директора по продукту в Notamedia, на российском рынке эта цифра доходит до 60%.
Как ещё можно использовать артефакты проектирования? На примере прототипа:
- Показать потенциальным инвесторам для получения финансирования. Шесть слайдов презентации и прототип выглядят лучше, чем просто шесть слайдов;
- Протестировать на потенциальных пользователях и внести правки тогда, когда это ещё не требует подключения всей команды разработки и стоит относительно дёшево.
Прототип
Прототип — самый понятный артефакт. Если вы создали или получили от заказчика документ, в котором состав и компоновка страниц продукта описаны текстом, сделайте прототип. Прототипирование (визуализация уже придуманного решения) стоит в разы дешевле проектирования. Вот отрывок из реального технического задания:
«При нажатии на кнопку (ячейку с заголовком) появляется новая табличка с перечислением регионов (на новой странице), оформленная также в виде кубиков. На заднем фоне каждого кубика — картинка местного специалитета.
Наводя на регион, появляется краткая цифровая информация: Event-компании — 100 (заявок из региона); Отели 5* — 3; Отели 4* — 15… Количество услуг будет зависеть от того, сколько оставят заявок».
И так почти десять страниц. Уверен, если 5 человек визуализируют это, получится 5 разных вариантов и столько же разных оценок сложности проекта. А имелось в виду следующее:
Шаг первый
Шаг второй
Кстати, после получения интерактивного прототипа заказчик прокликал будущий продукт и внёс значительные правки в ТЗ: упростил структуру и убрал дублирующиеся функции.
Текстовая документация
Иногда прототипа недостаточно. Например:
- Планируется нетривиальная работа «под капотом»: агрегация данных, хитрая их обработка, взаимодействие с внешними системами;
- Автоматизируется бизнес-процесс, в котором задействованы разные специалисты и департаменты со своими задачами, формами и отчётами;
- Документируются технические решения: требования к кроссбраузерности, резиновая или фиксированная адаптивность, ограничения по нагрузкам и объему данных и тому подобное. (Обычно это уточняет уже компания-разработчик.)
И тогда создаются диаграммы и текстовые документы: функциональные спецификации, технические задания, технические требования, сценарии и так далее.
Заказчик знакомится с документацией. Если у него есть видение проекта, он хочет убедиться, что исполнитель видит то же самое. В остальных случаях он пытается понять, как исполнитель решит поставленную задачу. Для таких клиентов справедливо определение проектирования, сформулированное Егором Камелевым:
«Проектирование — это процесс визуализации хотелок заказчика с учётом переменных, о которых он узнает лишь во время этого процесса».
При этом важно понимать, что люди не любят читать. А если это сложный для понимания текст (как в примере выше) и если его надо согласовать, то миссия становится трудновыполнимой.
У военных такой проблемы нет. Офицер говорит: «Установить орудие на десять». Солдат подтверждает, что правильно услышал приказ: «Есть установить орудие на десять».
Но военные действуют в материальном мире, а у офицеров всегда есть видение. Сложно представить такой диалог:
— Увеличить через месяц конверсию сайта на 10%.
— Для увеличения конверсии я выделю ЦА, сформулирую УТП и создам для каждой целевой группы специализированный лендинг. (На самом деле солдат не понимает, сработает это или нет.)
— Выполняйте. (На самом деле офицер вообще не понял, что будет сделано.)
Понимание
Когда Алексей Ёжиков работал директором по развитию Kelnik, он написал:
«Проектирование сайта — консультационная услуга по созданию образа будущего сайта, конечным результатом которой является одинаковое уточнение назначения, задач, структуры, функциональности, сценариев использования и тектоники сайта в сознании всей проектной команды».
В некоторых ситуациях можно отказаться от документов. Результат проектирования можно просто объяснить на встрече, если команда продукта не страдает от склероза и не собирается привлекать новых участников, которых потребуется ввести в курс дела. Но надо именно объяснить, а не просто рассказать. Чтобы образ продукта действительно попал в сознание.
Выше описан редкий крайний случай. Тоже крайний, но не такой редкий — пересылка артефакта без презентации и обсуждения комментариев с заказчиком. Так часто поступают начинающие проектировщики и в результате:
- Мучаются с длинным списком правок, тратят время на защиту решения по почте или просто вносят изменения, нанося вред продукту (если заказчик не прав) и не обучаясь (если заказчик прав);
- Долго ждут заказчика, который ушёл думать;
- Получают согласование без комментариев, что не так хорошо, как кажется на первый взгляд.
Если заказчик не вникнет, проблемы просто перенесутся на этап разработки. Это особенно важно компаниям полного цикла, которые проектируют и разрабатывают. Но и чистые проектировщики бывают заинтересованы в сохранении репутации и субподряда от компаний полного цикла.
Эд Кэтмелл, президент Pixar и Walt Disney Animation Studios в книге «Корпорация гениев» писал, что все люди ошибаются, и это нормально. Ваш процесс должен учитывать это и содержать механизм отлова и исправления ошибок.
Не бывает идеальных документов, в более-менее крупном прототипе всегда найдётся битая ссылка. Изучение документации заказчиком и обсуждение — важная часть процесса.
Вывод
В процессе проектирования важны и создаваемые документы, и понимание. Вопрос в том, как заставить заказчика участвовать в обсуждении и читать документы.
«Мы ни разу не видели заказчика, который был бы заинтересован в результате, но отказывался бы обсуждать происходящее в проекте. Может, он просто избегает ответственности, которую вы хотите на него повесить? Так не вешайте. Например, забудьте слово "согласование". Только обсуждения, максимум презентации», — Ольга Павлова, «Как решать UX-задачи в ситуации незнания и самообмана».
Насчёт чтения документов есть одна забавная идея, о которой я напишу в следующий раз.
Читайте также
- Без ТЗ: почему клиент не хочет его — о причинах, по которым некоторые заказчики пытаются начать работу без проектной документации, и о том, что может предпринять исполнитель.