Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

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

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

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

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

Новое время и неопределенность

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

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

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