Чтение онлайн

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

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

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

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

Не обманывайтесь. Этой истории уже несколько десятков лет. Борьба идёт с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря ей на свет регулярно появляются новые методологии и подходы. Дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и т.д. Каждая новая модель предполагает радикальное улучшение процесса и возможность наконец-таки получать по итогу проекта именно то, что требуется. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули как не было, так и нет. И вряд ли она когда-нибудь появится. Методологии в основном служат не снижению неопределённости, а только лишь обосновывают перенос рисков со специалистов на бизнес.

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

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

Вы уже догадываетесь, к чему я веду? Если неопределённость является корневой причиной невозможности точного планирования, вероятно, есть смысл сконцентрироваться на поиске способов её уменьшения. Конечно, в силу описанных выше особенностей проектной работы устранить её полностью невозможно. Но это и не нужно. Большое значение имеет само знание о наличии неопределённости и её локализация в отдельных частях проектах. Как писал Нассим Талеб уже после выхода «Чёрного лебедя», объясняя ключевую идею книги, причиной неожиданности события может быть как сама природа такого события (например, метеорит), так и слепота наблюдателя (как экономический кризис 2008 года). И если с первой категорией мы ничего поделать не можем, то со второй такая возможность есть.

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

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

Кажущейся альтернативой могут служить открытые (читай, бесконечные) сроки и бюджет, что, конечно же, невозможно представить, по крайней мере в нашей Вселенной. Хотя на таком варианте прямо или косвенно настаивает достаточно большое количество представителей ИТ-отрасли. Конечно, есть вероятность того, что команда специалистов, подобно природе, за бесконечное количество итераций сможет создать совершенный продукт. Но вряд ли такое расходование ресурсов оставит бизнес в живых.

Как видите, мы все равно неизбежно приходим к тому, что поиск способов снижения или локализации неопределённости – необходимый путь к снижению проектных рисков и в конечном счёте к получению бизнесом именно того результата, на который он изначально рассчитывает. Это один из базовых принципов «Метода параноика».

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