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

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

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

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

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

Кто и как делает проекты

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

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

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

Самая распространённая область – это левый нижний квадрант. Задачи отличаются простотой и стандартизированным процессом, а коммуникации минимальны. Например, требуется разработать сайт или мобильное приложение. В этом случае клиент формулирует задачу и передаёт исполнителю. Исполнитель над ней какое-то время работает и возвращается с уже готовым результатом. По сути, похоже на то, как вы приходите с рецептом в аптеку и вам продают либо готовое лекарство, либо сделанное по вашему рецепту. Поэтому квадрант называется «Фармацевт» (Pharmacist). Это классический аутсорсинг.