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