Статья подготовлена в рамках спецпроекта MAC-16 — крупнейшей конференции Рунета для веб-студий и digital-агентств, которая пройдёт 29 сентября в Москве.
Я хотел бы дать вам простой, но парадоксальный совет: не верьте всему, что говорят про проектирование.
Всё дело в том, что проектирование в веб-разработке в силу многих исторических причин развивалось через пень-колоду и до сих пор представляет собой размытое, плохо описанное и мало кем понятое определение. Ситуация потихоньку выправляется в последние годы, но разъяснительной работы предстоит много — а потому любому, кто хочет разобраться в проектировании, нужно включать свою голову и не бояться подвергать сомнению каждую прописную, казалось бы, истину.
Таких «прописных» истин много, и они вместе рождают страшный и ужасный набор мифов про проектирование — о самых главных из них я бы и хотел сегодня поговорить.
Миф № 1. Проектирование — это дополнительная услуга
Проектировщик, занятый важным общественно-полезным делом
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Многие считают, что этап проектирования — это дополнительная услуга, которой можно пренебречь. Это не так.
Ради чего мы создаем IT-продукты? Если мы находимся в своём уме и доброй памяти, мы создаем их ради решения бизнес-задач (своих собственных или своих клиентов — не так важно); решение этих бизнес-задач, в свою очередь, опирается на выполнение создаваемым продуктом задач пользователей с учётом условий рынка, технологических ограничений и всего прочего.
Чтобы продукт отвечал всем условиям, необходимо собрать воедино много противоречивой, неконкретной и труднодоступной информации — поговорить со всеми действующими лицами, изучить сопутствующие бизнес-процессы, ознакомиться с внешними системами, посмотреть на конкурентов и так далее, причём собранную информацию хорошо бы зафиксировать и свести воедино, чтобы у всех членов команды было одинаково хорошее представление о вводных данных.
Далее на основе собранной информации нужно придумать продукт, причём придумать его так, чтобы он не противоречил условиям задачи, а, наоборот, способствовал бы их выполнению — и такой продукт представляет собой сложный организм, где все части взаимосвязаны друг с другом. Придуманный продукт, опять-таки, нужно правильным образом зафиксировать, чтобы и заказчик, и разработчик понимали, что они получат в итоге (и в будущем могли бы этот продукт дорабатывать).
Можно ли сделать сколь-нибудь сложный и полезный продукт, миновав все эти этапы? Согласитесь: вряд ли. А между тем все описанные процессы и составляют то, что принято называть проектированием — анализ (разбор условий задачи), синтез (формирование продукта) и фиксация (составление правильной проектной документации).
Проектирование не может быть дополнительной услугой, коль скоро это плоть от плоти веб-разработки и нацелено на понятный результат, а не на освоение бюджетов или борьбу за всё хорошее против всего плохого.
Миф № 2. Проектирование стоит дорого
Бытует мнение, что этап проектирования только удорожает продукт.
В этой связи я обожаю цитировать Карла Вигерса — патриарха системного проектирования, автора чудесной книги «Разработка требований к программному обеспечению» и просто умного человека.
Карл Вигерс как-то провел исследование американского рынка IT-разработки и подсчитал, что в среднем 40% бюджетов разработки тратится впустую, причём эти деньги теряются не по вине криворуких разработчиков или плохих заказчиков, а всего лишь потому, что две стороны — заказчик и разработчик — просто не смогли договориться между собой.
Сорок процентов — и это для Америки, где царят совершенно иные отношения между заказчиком и разработчиком! Для России, мне кажется, эта цифра ещё выше — раза эдак в полтора.
При этом правильное системное проектирование, по подсчётам того же Вигерса, отнимает 15-20% бюджетов на разработку (и эта цифра полностью подтверждается нашим опытом).
Получается интересный эффект: мы тратим фиксированные 15-20% на проектирование, но при этом сводим к минимуму «пустые» траты (те самые 40% бюджета), которые потенциально могут похоронить проект и, к тому же, чрезвычайно затягивают сроки получения работоспособного продукта.
Таким образом, стоимость правильного проектирования парадоксальным образом влияет на стоимость всего проекта в целом: с одной стороны, этап проектирования не бесплатен и отнимает определённое количество бюджета, но с другой — снижает стоимость всего проекта в целом за счёт снятия рисков, связанных с плохо продуманным и потому непредсказуемым продуктом.
Миф № 3. Проектирование — это написание ТЗ
Слон, сделанный по ТЗ
Часто приходится слышать, что проектирование — это процесс написания ТЗ, который можно приложить к договору. Это не так.
Как мы выяснили в ходе разбора предыдущего мифа, проектирование минимизирует риски разработки. Вы будете смеяться, но это и является единственным и главным его назначением — всё остальное гармонично проистекает из этого факта:
- проектирование позволяет учесть интересы пользователей (и тем самым минимизировать риски разработки);
- проектирование позволяет учесть интересы заказчика (и тем самым минимизировать риски разработки);
- проектирование позволяет учесть все значимые внешние факторы (и тем самым минимизировать риски разработки);
- проектирование позволяет сторонам получить единое видение продукта (и тем самым минимизировать риски разработки);
- проектирование позволяет точно спрогнозировать сроки и стоимость разработки (и тем самым… ну, вы поняли).
Написание ТЗ — это всего лишь один из инструментов, который позволяет однозначно, достаточно, системно и отчуждаемо зафиксировать требования к продукту в формате, понятном для разработчика. Да, этот инструмент можно назвать важнейшим, но этап проектирования несёт куда более важную задачу — и это нужно помнить.
Миф № 4. Проектирование — это про пользовательские интерфейсы
Продукт с продуманным дружественным интерфейсом
В силу множества причин проектирование на нашем (да и не только на нашем) рынке веб-разработки прочно ассоциируется с интерфейсами.
Действительно, интерфейсы — это самая заметная часть продукта: именно с ней будут контактировать пользователи, которые будут выполнять при помощи продукта свои задачи и тем самым способствовать выполнению задач заказчика.
Можно ли на этом основании считать интерфейсы единственной достойной целью для проектирования? Конечно же, нет: интерфейс является лишь надводной частью айсберга продукта, и если мы говорим о правильном проектировании, которое действительно минимизирует риски разработки, то мы должны заниматься и тем, что происходит внутри продукта: структурой его данных, логикой его поведения, связями с внешними системами, административными интерфейсами и многим другим.
Пользовательский интерфейс — это всего лишь один из компонентов продукта, служащий для доступа пользователей к функциям и данным продукта. Проектировать его важно, но ограничиваться только им — вредно.
Миф № 5. Проектировать может и менеджер
Менеджер, занятый профильной активностью
Как мы уже выяснили, проектирование — сложный процесс, связанный с кропотливой, тонкой работой. Чтобы проектирование выполняло свои задачи, эта работа должна быть выполнена максимально качественно и вдумчиво. Проектирование, иными словами, требует от исполнителя наличия очень специфической системы ценностей, где качество работы и персональная ответственность будут превыше всего.
При этом проектирование часто отдают в руки менеджерам как людям, которые сводят воедино все процессы и нити разработки. Казалось бы, всё логично и правильно, но не учитывается один важный момент: у хороших менеджеров совершенно иная система ценностей, где во главе всего стоят сроки проекта и его бюджет.
В больших проектах и, в частности, в заказной разработке это играет с менеджерами очень злую шутку: если менеджер встаёт перед дилеммой решить проблему, связанную с проектом в целом (например, вытащить дизайнера из запоя — совершенно реальная история, кстати), либо решить проблему, связанную с проектированием (более детально прописать протокол данных в ТЗ), то любой менеджер выберет решение, которое потушит пожары, бушующие здесь и сейчас. В самом деле — недоработанное ТЗ скажется где-то на дальней перспективе, а вот вовремя не потушенный проектный пожар приведет к потере проекта прямо в текущий момент. Да и, в конце концов, как можно спокойно писать ТЗ, когда тебя постоянно отвлекают клиенты по мелочам?
И так будет на всем протяжении разработки. Если к этому ценностному аспекту прибавить аспект профессиональный (всё-таки проектировщик должен уметь многое из того, что не обязан знать менеджер), то легко понять, почему проектированием должен заниматься отдельный, специально обученный человек со своей системой ценностей.
Единственное исключение из этого правила — внутренняя разработка. В условиях, когда у менеджера один-единственный проект, а проблема сроков и бюджетов стоит не столь остро, менеджер может брать на себя функции проектировщика. Правда, в этом случае он становится менеджером по продукту — а это отдельная история, заслуживающая своей статьи.
Миф № 6. Проектированием должны заниматься психологи
Техническое содержание продукта по версии психолога
Некоторые компании — вплоть до самых крупных — полагают, что проектированием должны заниматься люди с психологическим образованием. Этот миф вырастает из убеждения, что проектировщик должен отстаивать исключительно интересы пользователей. Как мы уже выяснили, это не так — проектировщик занимается всем продуктом в целом и учитывает интересы как пользователей, так и заказчика, не говоря уже о специфике системы. Всё это требует технических навыков, которых психологи в большинстве своём лишены.
Другое дело, что психологов можно привлекать на узкую часть проектирования — работу с интерфейсами или анализ пользовательских предпочтений, — но всё это должно происходить под присмотром проектировщика продукта, который будет учитывать все технические тонкости и нюансы.
Миф № 7. Проектирование должны заниматься инженеры
Удобный пользовательский интерфейс по версии безымянного программиста
В противовес мифу про психологов существует миф про инженеров — дескать, проектировщик должен быть программистом. Как вы, я думаю, уже догадались, это тоже плохой вариант — сферический программист в вакууме способен продумать общую архитектуру продукта, но вряд ли сможет достаточно точно почувствовать пользователей и понять требования заказчика. Вообще-то такие разработчики мне попадались, но по своему складу ума это были, скорее, проектировщики, которые по недоразумению стали разработчиками.
Как и в случае с прошлым мифом, разработчиков можно привлекать к проектированию — но только на структуру данных и функциональные описания продукта под присмотром проектировщика (хотя при необходимости проектировщик это должен делать сам).
Кто же такой проектировщик?
Кем же должны быть проектировщики? Это очень сложный вопрос, на который я вкратце могу ответить так.
- Стоит смириться, что на «правильных» системных проектировщиков нигде пока не учат.
- Чаще всего правильный проектировщик рождается на стыке между условными гуманитарными и техническими науками.
- Чаще всего хороший проектировщик не знает, что он — хороший проектировщик, и работает по левой специальности, которая его не радует.
- У такого «неактивированного» хорошего проектировщика шизофренический послужной список, околотехническое образование, широкий кругозор и склад ума хорошего классического инженера.
- Проектировщик должен понимать дизайнеров, разработчиков, заказчиков и пользователей.
- Проектировщик должен уметь общаться с людьми.
Лично мой опыт показывает, что проектировщик — понятие скорее врожднное: обучить проектировщика нужным инструментам и приёмам можно относительно быстро (серьёзно, от трёх месяцев до полугода), а вот вложить в него нужную систему ценностей и склад ума практически невозможно.
Но такие люди есть — и именно для их поиска и формирования я создал в свое время Гильдию вольных проектировщиков, и это тоже отдельная тема для разговора.
Единого подхода к проектированию не существует
Проектировщик не выдерживает накала страстей на проекте
Подходов к проектированию много, и неискушенный читатель может запросто сойти с ума от обилия приемов, подходов и аббревиатур, щедро сдобренных терминологическим бардаком (всеми этими UX, UI, CX, HCD и прочими IDDQD с кривыми русскоязычными аналогами).
Некоторые, впрочем, пытаются вывести универсальные модели проектирования, но в итоге получается так, что в попытке объединить существующие 20 (условно) подходов к проектированию мы получаем в итоге 21 подход — и методологии, как кажется, начинают плодить самих себя.
Специалисты выводят на этом основании, что единого подхода к проектированию не существует и быть не может — дескать, всё строго индивидуально, а потому и систематизировать тут нечего.
Это тоже миф, который лично меня категорически не устраивает. Единый подход к проектированию существует, но требует отдельного, большого и очень личного разговора; так что, с вашего позволения, этот миф мы опровергнем чуть позже — ближе к концу сентября, когда на Cossa выйдет моя большая статья на эту тему.
Вместо заключения
Итак, что мы с вами сегодня выяснили?
- Проектирование стоит своих денег и позволяет уменьшить бюджет на разработку.
- Проектирование минимизирует риски разработки.
- Проектирование отстаивает интересы продукта в целом.
- Проектированием должны заниматься проектировщики (вот так истина, а?).
- Проектирование — это большой и сложный процесс, у которого есть свои закономерности и единые подходы.
- Не верьте тому, что пишут про проектирование — не бойтесь думать сами, предлагать свои взгляды и отстаивать своё ви́дение.
И последняя просьба: не верьте на слово даже мне — я буду только рад, если вы не будете не соглашаться со мной и отстаивать свою точку зрения: это будет поводом для полезного и большого разговора, в ходе которого может появиться очередная истина — и это ли не здорово?
COSSA приглашает посетить двухчасовой мастер-класс Алексея «Проектирование продукта в агентстве: всё, что вы должны знать», который пройдет 29 сентября в рамках MAC-16. Вот о чём пойдет речь:
|
Алексей Бородкин Директор по продукту Notamedia |
На мастер-классе вы станете свидетелем повседневного проектировочного чуда: из дурацкого описания в письме клиента вырастет полноценный, детально документированный продукт.
В программе мастер-класса:
- Что является конечной целью проектирования.
- Контакт с клиентом на пресейле и работа с ожиданиями.
- Сбор требований и предварительные исследования.
- Составление архитектуры.
- Работа с интерфейсами.
- Работа с внутренней частью продукта.
- Согласование продукта с клиентом.
- Какая последовательность действий при проектировании является идеальной, почему её не существует и как с этим жить.
До встречи на MAC!
Читать по теме:
- Кто такие проектировщики и как ими становятся?
- Чем проектирование отличается от шарлатанства
Источник:
