Применительно к описанной ситуации, сочетание с первой идеей об уменьшении неопределенности приводит к интересному выводу. Если человек с нужным уровнем ответственности появится в проекте только в конце, это значит, что работа строилась на неподтвержденных гипотезах. Когда после запуска начнется их проверка, многие решения будут пересмотрены, а вместе с ними и результаты всей работы. Например, в случае с онлайн-магазином проектировщики могли предположить, что компания не будет использовать собственный склад и будет заказывать товары у поставщиков непосредственно под каждый заказ. Если коммерческий директор решит, что выгоднее иметь запас самых популярных товаров у себя, то процессы, на которые рассчитана система, стадии обработки заказа и роли пользователей придется пересмотреть, а вместе с этим повторно перепроектировать и выполнить разработку.
Отказываясь от привлечения будущего руководителя бизнеса в качестве заказчика на стадии проектирования, инвесторы руководствуются понятным правилом «зачем сейчас тратить время и деньги, пока идет разработка?», но в итоге общие затраты растут. Такова цена отложенных решений. Поэтому в своей практике я избегаю проектов, где бизнес не имеет достаточного уровня, соответствующего задачам, и не готов отвечать на базовые вопросы проекта.
Требования к уровню ответственности одинаково применимы и к техническим решениям, хотя вопрос ответственности не столь очевиден. Все склонны оценивать специалистов по профессиональным навыкам, забывая о мотивах. Если вы считаете, что для управления проектом достаточно подобрать людей в соответствии с ролями выбранной методологии, определить их обязанности и поставить задачи, то, скорее всего, вам еще не приходилось управлять командами.
Читая очередную книгу о подходах к организации проектной работы или методах проектирования, я, как мистер Томпкинс из романа «Дэдлайн», недоумеваю: где же во всех этих схемах, процессах и ролях люди с их личными качествами и желаниями? Если бы все было так просто, то методических наработок середины XX века было бы достаточно для выполнения проектов любой сложности. Вопрос правильного принятия решений при проектировании лежит не в плоскости технологий, а в особенностях человеческой природы.
В обычной ситуации разработчики понимают, что проектировщик не несет ответственности за решения и что это влияет на их качество. Так как за результат проекта спрашивают с разработчиков, они делают единственно верный в данном случае выбор – игнорировать то, что предлагают проектировщики и искать решения самим. Так, по крайней мере, у них будет уверенность в их адекватности задачам и технической реализуемости. Проблемы начинаются уже на этапе знакомства с проектной документацией, которую, как правило, никто не читает внимательно. Дальше все становится хуже, в итоге готовый продукт сильно отличается от первоначального представления, что сказывается на его качестве и способности решать задачи бизнеса.
Например, при создании банковского мобильного приложения проектировщик, продумывая логику взаимодействия с пользователями, представляет интерфейс в модном и актуальном, на его взгляд, виде. Это могут быть функции для просмотра счетов и операций, заказа банковских продуктов и общения с поддержкой. Стараюсь быть в тренде и думать о личном портфолио, проектировщик упускает из вида соответствие интерфейса и функций возможностям внутренней АБС (автоматизированной банковской системы), которая непосредственно их реализует, а заодно и правовым документам, на основании которых банк оказывает услуги. После получения такой постановки задач разработчики возвращаются за уточнениями к проектировщикам, что приводит к непредсказуемым по длительности циклам согласований, либо стараются самостоятельно решить проблему. В первом случае увеличиваются сроки и бюджет проекта, а во втором страдает качество продукта, ведь решения принимаются не на том уровне абстракции и компетенции.
Если возложить на проектировщиков ответственность за конечный результат проекта, ситуация становится другой. На вопрос о том, как именно это сделать, отвечает третий принцип «Метода параноика» – продюсирование. Этот абзац я пишу от лица проектировщиков и должен сказать, что в свое время был поражен, как меняется работа над проектом при внесении в него элемента личной ответственности за результат. Разработчики с нетерпением ждут обновления спецификаций и обсуждают с вами ее отдельные фрагменты на предмет нюансов описываемой логики. В ряде случаев может даже произойти совсем немыслимое: на устную просьбу внести изменения в программный код вас попросят вначале обновить документацию, чтобы она не расходилась с конечной реализацией. Но, как известно, ничего не бывает бесплатно, и ценой такой чуткости команды разработки к вашей проектировочной деятельности будет то, что вам действительно придется держать документацию в актуальном состоянии.
Третье правило: все решения должны быть связаны
Осталось рассказать о третьем правиле, на котором основывается принцип проектирования. Оно звучит так: все решения в проекте должны быть связаны между собой. Без этого первых двух правил было бы недостаточно для того, чтобы принцип проектирования стал полноценным инструментом для создания цифровых продуктов. Вместе они создают устойчивую конструкцию и дают друг другу возможность раскрыть потенциал без отрицательных последствий. Почему третье правило так важно? Дело в том, что оно задает границы для первых двух.
Работая над большим проектом, легко забыть, с чего все началось. Да, перед командой были поставлены цели, и формально задача заключается в их достижении. Но по дороге приходится принимать тысячи решений, и, как это часто бывает с людьми, они могут увлечься и заняться тем, что к исходным целям проекта не относится. Винить в этом довольно сложно, учитывая, что поиск удачных решений обычно идет по непредсказуемому пути. Мысли состоят из хрупкой материи, поэтому лучше дать себе больше пространства для фантазии, чем лишать возможности получить нужный результат.
Поэтому я предпочитаю смотреть на границы следующим образом: работая над проектом, вы можете делать все что угодно, но есть контрольные точки, которые обязательно должны быть пройдены. Чтобы подтвердить их прохождение, у вас должны быть критерии оценки, например требования к набору артефактов и документации. Идея связанности всех решений между собой для этого и нужна. Забегая вперед, скажу, что искусство управления проектом состоит в том, чтобы найти нужный баланс в плотности расположения контрольных точек проекта. Если поставить их слишком часто, для появления интересных, но нестандартных решений может не хватить времени, но, если раздвинуть окно, в течение которого можно действовать без проверки, ошибочное направление поиска может выявиться слишком поздно, за что придется заплатить.
Вернемся к сути идеи и рассмотрим, как она работает. Когда я говорю, что решения в проекте должны быть связаны между собой, это значит, что мы можем взять любое из них и проследить цепочку предшествующих решений вплоть до первоначальных целей проекта. Помимо своеобразной хронологической истории принятия решений, назовем ее горизонтальной, есть вертикальная система координат. Дело в том, что система проектируется на нескольких уровнях, а именно функциональном, интерфейсном и техническом, представляющим модель продукта. Они также должны быть связаны между собой. Существуют и другие уровни, о которых я расскажу в следующих главах. Вот схема, которая это иллюстрирует.
Отправных точек, то есть первоначальных решений, лежащих в основе проекта, может быть несколько. В банковском примере – это решение ограничить функциональный уровень сценариями обслуживания клиентов. Далее следует решение создать мобильное приложение и голосового ассистента, которое относится к интерфейсному уровню; и решение использовать для реализации конкретные платформы, например, iOS и «Алису», которое относится к техническому уровню. Все это так или иначе обусловлено бизнес-требованиями, дополненными рыночной конъюнктурой, требующей от банков иметь обязательный набор каналов взаимодействия с клиентами, и договоренностями о совместных маркетинговых акциях по продвижению вместе с поставщиками платформ. При этом, как мы видим, на организационном уровне проекта у нас нет определенности.
Связь первоначальных решений с первыми двумя правилами принципа проектирования уменьшает неопределенность в проекте. Решения должны исходить от компетентных и ответственных людей. Но этих решений недостаточно для определения границ проекта. Требуется проделать работу, чтобы появились решения на всех уровнях, и проверить их на первой контрольной точке. В «Методе параноика» есть фирменный проектный процесс и первая стадия в нем – это разработка концепции. На этом этапе требуется развить обозначенные решения до полного понимания образа будущего продукта и принять решения на организационном уровне.
Посмотрим, как происходит проверка по итогу работы над концепцией продукта. Это первая контрольная точка, через которую обязательно должен пройти проект. Ее цель – убедиться, что в проекте на всех уровнях найдены решения, и они соответствуют трем правилам: 1) уменьшают неопределенность; 2) приняты на нужном уровне абстракции, компетенции и ответственности; 3) связаны с первоначальными целями проекта.
На каждой стадии проекта есть свои критерии детализации решений. Например, концепция не должна отвечать на вопросы о полном наборе функций продукта, достаточно понимать, какие задачи пользователи могут решать с его помощью и как они увязаны с целями бизнеса. Также не требуется формировать список всех компонентов технической архитектуры, важно убедиться, что выбранное продуктовое решение реализуемо. То же относится и к интерфейсному уровню. Помимо трех уровней существуют и другие, например, организационный, где принимаются решения о бюджете, сроках, требованиях к составу проектной команды.