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

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

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

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

Третье правило: все решения должны быть связаны

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

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

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