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

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

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

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

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

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

Традиционно при формировании проектных команд роли участников связаны с их специализацией. Это могут быть разработчики, дизайнеры, аналитики и другие. Их опыт и профессиональные качества определяют уровень, на котором они рассматривают создаваемый продукт. Например, IT-архитектор видит систему целиком, но исключительно с технической точки зрения. За более детальный уровень отвечают выделенные разработчики с компетенциями в отдельных технологиях, таких как базы данных, нейросети, серверные компоненты, мобильные приложения, веб-сайты. Но бизнес-задачи, сценарии взаимодействия, пользовательский интерфейс – при данном подходе все это для него внешние требования по отношению к технической реализации.

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

Бизнес-администрирование тоже можно считать проектной специализацией, потому что его представители, как и участники команды, отвечающие за технические аспекты, традиционно не выходят за границы своих организационных задач. Руководитель компании или подразделения рассматривает цифровой продукт на верхнем уровне абстракции и редко погружается в детали, учитывает только его общее назначение, бюджет и сроки разработки. Уровнем ниже менеджеры компании детализируют это в функциональные требования, не учитывая остальные аспекты. Фактически они смотрят на то, что продукт «должен делать», и оставляют вопрос «как» на исполнителей – менеджера проекта, IT-архитектора, продуктового дизайнера и остальных участников команды.