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

Если на стадии концепции целью было найти решение как таковое, не затратив лишних средств, то дальше, убедившись в его работоспособности, можно готовить почву непосредственно для разработки цифрового продукта. Фактически теперь начинается проектирование в том виде, как об этом все привыкли думать. Я имею в виду проработку системы на уровне UX, дизайна и технического устройства. Но, учитывая принцип выпуска продукта подобно череде эпизодов сериала, лучше проявить предусмотрительность и сначала выполнить ту часть проектирования, которая относится не к конкретным функциям, а к продукту в целом. Согласитесь, экономически выгодно сделать один раз то, что можно использовать в дальнейшем, не затрачивая каждый раз средства и время.

Для такой подготовительной работы в «Методе параноика» предусмотрена стадия высокоуровневого проектирования. Ее цель – выстроить архитектуру системы и создать инструменты, с помощью которых можно сделать продукт более надежным, а работу над отдельными версиями быстрой и недорогой. Только так можно получить настоящий эффект от гибкого подхода к разработке. В противном случае что толку от того, что участники проекта договорились не ограничивать бизнес в его желании произвольно менять список задач для каждой итерации, если за это они вынуждены копить технический долг и подолгу стабилизировать систему?

Чтобы этого добиться, нужно выполнить несколько требований. Во-первых, не брать за основу техническую реализацию, полученную на стадии концепции продукта. Архитектура продукта не должна содержать компромиссные решения, которые были оправданы на коротком отрезке проверки гипотез, но не подойдут при масштабировании системы. Вспомним легендарного Алана Купера и его историю продажи стартапа компании Майкрософт, из которого возник один из первых инструментов визуальной разработки – Visual Basic. После того, как сделка была завершена и началась работа внутри корпорации, он принял решение выкинуть весь старый код и начать проектирование с нуля. Это привело к внутреннему конфликту с руководством Майкрософт, но в результате Купер и команда отстояли свою позицию и смогли подойти к разработке с учетом иного масштаба требований, что в дальнейшем хорошо сказалось на качестве продукта.

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

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

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

Требования к участникам