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