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

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

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

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

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

Проектирование проектных команд

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

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