Когда планируется построить здание или сложную инженерную конструкцию, например, мост, ни у кого не вызывает сомнений необходимость провести геодезические изыскания, выполнить проектирование и протестировать модели. Также никому не приходит в голову поручать эти задачи рабочим, которые будут заниматься строительством. Для предварительной проработки проекта привлекаются отдельные специалисты – проектировщики, архитекторы, исследователи, те, кто обладает профессиональными знаниями и опытом. Если мы говорим про жилой дом, то проработка внешнего вида вместе с дизайном его интерьера также будет поручена тем, кто специализируется на подобных задачах, равно как и обладает чувством стиля, соответствующим вкусам заказчика.
Цифровые продукты и сервисы – более сложные объекты. В отличие от зданий, они не статичны и являются динамическими системами с внутренней логикой поведения. Даже примитивный веб-сайт обладает атрибутами сложной системы: базой данных, программными механизмами для сохранения и обработки данных, интерфейсом, настроенным на прохождение сценариев, меняющимся в зависимости от действий пользователя. В более комплексных продуктах сложность и количество взаимодействующих между собой компонентов возрастает на несколько порядков.
Почему же проектирование в этой отрасли часто считается избыточным и ограничивается дизайном? Ведь если не уделять достаточного внимания проектированию, уровень неопределенности в проекте можно довести до максимума.
Мне кажется, у этой ситуации есть несколько причин. В проектах до определенной степени сложности проектирование – просто признак производственной культуры компаний, разрабатывающих цифровые продукты. Но если пересечь незримую границу сложности, создание продуктов без предварительного проектирования становится невозможным. Поскольку большинство проектов имеют низкую или среднюю сложность, даже в профессиональной среде нет статус-кво по этому поводу.
Помимо постоянных возражений в необходимости проектирования со стороны начинающих разработчиков или просто дилетантов в индустрии, ситуацию осложняет современная модель обучения. Она дает узкоспециализированные знания либо по программированию, либо по дизайну, но не общее представление о создании продуктов. Среди прочего это связано с непониманием, что же такое проектирование. В глазах клиентов в большинстве случаев проектирование воспринимается как «рисование дизайна», в лучшем случае – как UX-проектирование. Проектную документацию многие считают анахронизмом. В результате современные методы создания продуктов больше напоминают модные диеты, которые основаны на предрассудках, чем полноценные системы питания.
Существует заблуждение, что гибкие модели разработки, такие как Scrum, являются альтернативой проектированию. В пользу такой точки зрения приводится аргумент, что классический подход предполагает разделение проекта на два больших этапа – проектирование и разработка – без возможности вносить изменения или учитывать новые требования в процессе работы. Гибкие модели якобы позволяют сразу приступать к реализации и решать возникающие вопросы по ходу проекта, не откладывать встречу бизнеса с цифровым инструментарием на далекое будущее.
Ошибка такого взгляда в том, что даже при наличии интерактивных инструментов разработки нельзя обойтись без анализа функциональных требований и проработки концепции самого продукта, – на этом основывается вся дальнейшая проектная работа. Как можно браться за проект, набирать команду и начинать разработку, если непонятно, что нужно создать? Неудивительно, что большинство таких проектов проваливаются, поскольку такие задачи не решаются «на коленке».
Не существует универсальных «программистов», способных реализовать любой проект. Поэтому перед формированием команды необходимо сформулировать требования к ее участникам. Без предварительного анализа сделать это невозможно. К тому же создание цифровых продуктов – это не только программирование. Рассматривать его с точки зрения разработки и разработчиков – большая ошибка. У этого сложившегося стереотипа есть исторические причины, но пора отойти от подобного представления.
Негативная эволюция
Разобраться с тем, что произошло в IT-индустрии, мне помог Чак Паланик, автор книги «Бойцовский клуб». В подкасте Джо Роган спросил его о процессе написания книги и о том, когда он садится за компьютер, чтобы работать над текстом. Паланик ответил, что старается откладывать этот момент до тех пор, пока не останется другого выбора, например в самолете, и назвал это машинописью (typewriting). По его мнению, к созданию книги этот процесс относится в последнюю очередь. Основная работа состоит в поиске, сборе и анализе материалов, причем в случае с Палаником это происходит где угодно и с использованием любых подручных средств, включая клочки бумаги и салфетки.
Паланик объяснил, что относится к поколению, для которого набор текста был дорогим и утомительным. Пишущая машинка, лента и бумага для нее – все это было накладно и неудобно в использовании. С ручкой и листком бумаги, подслушав что-то за соседним столиком, можно тут же записать, не беспокоясь о форме. То же относится и к структуре будущей книги, которую можно продумывать до написания хотя бы одной строчки. В конечном счете важна история, которую хочет рассказать писатель. Такая подготовительная работа, по словам Паланика, позволяет ему садиться за компьютер уже с заготовленными идеями, материалами и концепциями.
Я увидел параллели между изменениями инструментов у писателей и программистов и тем, как это повлияло на профессиональные модели поведения. Как любой, кто занимается сочинением текстов, начинает работу с того, что открывает ноутбук, так и программист первым делом запускает среду разработки. Поэтому на развитие способов создания компьютерных систем можно смотреть с точки зрения упрощения процесса программирования.
Если вернуться на несколько десятилетий назад, можно увидеть нечто интересное. Раньше, чтобы поставить компьютеру задачу, нужно было долго готовиться. Процесс программирования был сложным, а из-за дороговизны компьютеров их время работы распределялось между разными специалистами. Обнаружив ошибку при выполнении программы, шансов оперативно исправить и загрузить ее на повторное исполнение было мало. Поэтому подготовительная работа была ответственным занятием и предполагала тщательное проектирование.
По мере того, как компьютеров становилось все больше и их возможности возрастали, они становились доступнее, появилась интерактивность процесса программирования. Можно было проверять результаты своей работы практически сразу, и возникало ощущение, что долгой подготовки к программированию можно избежать и перенести все непосредственно в процесс написания кода. К сожалению, при этом потерялась существенная часть того, что также происходило в процессе подготовки: исследование и осмысление задачи, чтобы логика ее реализации была цельной и непротиворечивой. Теперь процесс разработки больше напоминает шаманство, когда программист просто угадывает комбинацию компонентов и кода, которые будут работать.
Вместе с упрощением технических процедур программирования были упущены важные аспекты, которые раньше входили в подготовительную работу. На самотек пустили задачи проектирования архитектуры и интеграции с внешними сервисами, формализации функциональных требований и детальной проработки логики работы компонентов системы. Принятие столь важных решений случайно оказалось в руках программистов, а при создании сложных продуктов требуется комплексный взгляд на задачу и специальные навыки архитектора.
Новое время и неопределенность
Моя интерпретация событий может показаться неубедительной, ведь кажется, что проектированию уделяется больше внимания, чем когда-либо. По мере развития цифровых продуктов и увеличения их сложности необходимость в удобных интерфейсах и качественно проработанных пользовательских сценариях стала очевидной. Без проектирования взаимодействия и UX не обходится ни один серьезный проект. Но чем тщательнее интерфейсные проектировщики и дизайнеры подходят к этой задаче, тем чаще у них возникает вопрос, почему задумки не реализуются полностью.
Ответ заключается в том, что программисты по-прежнему предоставлены сами себе. Дизайн-сообщество и бизнес считают, что разработчики сами разберутся с тем, как реализовать цифровые продукты на основе функциональных требований и дизайн-макетов. Возможно, для многих станет сюрпризом, но комплексное проектирование, включающее все аспекты будущего продукта, обычно не выполняется. В этом и кроется важный, но незаметный источник неопределенности.
Проблемы могут возникать в самых очевидных местах. Например, дизайнер подготовил макеты интерфейса для мобильного приложения. От разработчика на их основе требуется реализовать логику работы каждого экрана, включая обработку ошибок, как системных, так и пользовательских. Поскольку ни функциональные требования, ни дизайн приложения «не опускаются до таких мелочей», то разработчик решает этот вопрос на свое усмотрение, и не всегда способом, который дизайнеру кажется очевидным. Если над проектом работает целая команда и распределяет задачи по созданию разных разделов приложения, то каждый программист решит вопрос с выводом ошибок в интерфейсе по-своему. Это влияет на то, как выглядит продукт и насколько предсказуемо выполняет функции.
Даже небольшой проект содержит в себе множество требующих решения вопросов, которым не было уделено внимание на этапе проектирования. Это может быть наличие актуальной документации на внешние сервисы, проверка технической возможности реализовать дизайн интерфейса, особенности архитектуры для работы под высокой нагрузкой и прочее. Неудивительно, что по мере приближения проекта к завершению в нем накапливаются неочевидные и неожиданные особенности, которые всплывают на этапе тестирования или, что хуже, у пользователей. Когда разработчики не могут найти решение и откладывают задачи, ситуация может стать критической.
Этим объясняется распространенная проблема, когда после активного периода разработки начинается долгая и непредсказуемая по срокам стабилизация продукта. Исправление одних ошибок приводит к появлению других, и иногда кажется невозможным привести все в работающее состояние. Так проявляется скрытая неопределенность из-за отсутствия проектирования и концептуальной целостности системы.
Документация
Я пишу эти строки в момент, когда мир ошарашенно пытается понять, что же происходит и какой образ жизни выбрать в условиях глобального карантина. В первую очередь это сказывается на бизнесе, ведь большинство процессов в компаниях остановились и не могут продолжаться в привычном режиме. То, что раньше казалось простым и легким, теперь практически недостижимо. Становится понятно, что методы управления компаниями строились на множестве неформальных действий, которые без возможности непрерывного личного общения не работают.
Простой пример – постановка и отслеживание задач. Если раньше руководитель мог пройти по офису, увидеть, насколько активно идет работа, и, глядя на конкретного человека, вспомнить о давно порученной задаче, то сейчас контроль утерян. Чтобы понимать, как продвигается работа, необходимо уделять больше внимания описанию задач, чтобы потом проверить качество их выполнения.
Подобный подход требует иной профессиональной культуры и другого формата взаимодействия. Постоянный присмотр за коллективом через веб-камеры точно не является кандидатом на роль нового способа работы. Это еще одна точка конфликта между административными методами управления и требованиями к высокой компетенции всех участников рабочих процессов, включая руководителей.
Аналогичные проблемы испытывают и команды, работающие над проектами. Если проектированию не уделяется достаточно внимания и у участников проекта нет общего видения продукта, основанного на документации, то знания обо всех принятых решениях фрагментарны и распределены между отдельными специалистами. Каждый из них, будучи обычным человеком, склонен их забывать или ошибочно интерпретировать. Если кто-то покидает проект, вместе с ним пропадают и уникальные знания, о которых больше никто не имеет ни малейшего представления. Сложно представить, как такой проект сможет нормально развиваться, поддерживая архитектурные принципы и сохраняя целостность в новых версиях.
Управление такими проектами – непростая задача. Без полного понимания всех частей будущего продукта менеджеры не могут оперативно отслеживать ход работ и быть уверенными в качестве результата. Такой проект напоминает коробку с котом Шредингера – ее нужно открыть, чтобы узнать, все ли в порядке с животным. Так и здесь, чтобы понять, что происходит в проекте, надо пообщаться с каждым участником, собрать всю информацию и на ее основе дать оценку. Затрудняюсь представить, как это делать на ежедневной основе и сколько усилий потребуется от всей команды.
Совсем иначе обстоят дела в проектах, где документация используется как средство общения. Можно сказать, что проектирование и созданные в результате артефакты являются способом коллективного мышления проектной группы. На практике это означает, что технический архитектор и интерфейсный проектировщик обсуждают вопросы, опираясь на конкретные части документации. В дальнейшем такое же взаимодействие строится между разработчиками и техническим руководителем проекта. Изначальные знания и история обсуждения отдельных задач накапливаются структурированно и могут быть использованы при работе над следующими версиями продукта.
Проектирование и бизнес
Проектирование в руках профессионалов – это инструмент, который позволяет точно целиться в бизнес-цели проекта и решительно действовать. Возможно, это кажется странным, но проектирование сокращает бюджет и сроки проекта. Вместо поиска в темноте наугад, проектирование, как фары автомобиля, освещает дорогу для проектной команды. Но важно помнить, что проектированию предшествует этап анализа бизнес-задачи клиента. Проектирование – это поиск наиболее подходящего способа реализации системы, которая решает задачи бизнеса. Если задачи не сформулированы, проектирование не даст результата.
Качественное проектирование включает в себя три аспекта: функциональный, интерфейсный и технический. В этой главе я только упоминаю их, в следующих главах рассмотрю подробнее.
Помимо того, что проектирование является методом создания продуктов, оно связывает разных участников экосистемы. Проектная документация становится языком общения между, например, «Психотерапевтом» (проджект-раннером) и «Фармацевтами» (командами разработки). В современном мире участники проектной команды могут находиться даже в разных странах, такое свойство проектирования дает преимущество тем, кто его использует. Проектирование уменьшает и неопределенность в проекте вместе с локализацией функций разных участников команды.