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