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

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

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

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

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

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

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

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