Читать книгу: «Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности», страница 6

Почему невозможно точно оценить проект

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

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

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

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

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

Вы все еще думаете, что можно точно спланировать проект, зафиксировать его стоимость и определить дату завершения? Я пришел к выводу, что не существует подхода или методологии, которые гарантируют получение нужного вам цифрового продукта. Миша Токовинин, основатель AmoCRM, сказал, что все споры о методологиях разработки программных продуктов сводятся к обсуждению оптимальной длины итераций в проектах. В одних случаях продукт реализуется в рамках одной длинной итерации, а в других, как в случае со Scrum, за несколько коротких и фиксированных по длительности. Я же утверждаю, что ключевой вопрос состоит в том, кто заплатит за риски проекта, которые вызваны высокой степенью неопределенности, присущей этой сфере.

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

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

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

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

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

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

Независимо от используемого в проекте подхода, источник риска – неопределенность – не исчезает. Компромисс между сторонами тоже не решает проблему, в конечном счете кто-то все равно должен заплатить за возникающие издержки: либо одна сторона, либо другая, либо обе.

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

Что делать с неопределенностью в проектах

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

Локализация неопределеннос

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

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

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

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

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

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

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

Тип проекта как индикатор уровня неопределенности

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

Вряд ли вы будете лечить простуду экспериментальными лекарствами, которые могут быстро помочь, но имеют непроверенные побочные эффекты, способные вас убить. С другой стороны, когда стоит вопрос жизни и смерти, такой выбор вполне оправдан. Как сказал Дональд Трамп, лекарство не должно быть опаснее болезни. С этим утверждением трудно не согласиться.

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

Типы проектов помогают оценить возможные риски и выявить степень неопределенности. Я описывал типы во второй главе, напомню кратко:

«Мозги» – проекты, в которых нужно придумать что-то новое, выходящее за рамки существующих решений.

«Седина» – использование готовых технологий и продуктовых наработок для решения уже известных задач.

«Процедуры» – проекты, в которых важна эффективность выполнения стандартных задач и возможность настроить типовой рабочий процесс с привлечением взаимозаменяемых специалистов, компетентных в проектировании, дизайне, разработке, тестировании и т. п.

Неопределенность возрастает от проектов типа «Процедуры» к «Седине» и достигает своего максимума в «Мозгах». Коротко это можно описать следующим образом.

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

Цель проектов типа «Седина» – внедрить существующие продукты либо создать новые, опираясь на отработанные технологии и процессы. Тем самым исключить внутреннюю неопределенность проектов. Используемые решения уже многократно проверены, специалисты участвовали в аналогичных проектах. План работ, сроки и бюджет рассчитываются на основе прошлого опыта. Однако 100 % гарантии это не дает, т. к. источником неопределенности здесь выступает новая внешняя среда, под которую реализуются проекты.

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

На примерах компаний в разных ситуациях я хочу показать возможные варианты развития событий и способы работы над проектами разных типов. Рассмотрим случаи:

а) бизнес, который стоит перед необходимостью кардинальных изменений;

б) открытие нового бизнес-направления или стартапа;

в) успешный бизнес, развивающий свои цифровые сервисы.

Бизнес на пороге кардинальных изменений

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

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

Какие пути есть у компании в подобной ситуации? Варианты «оставить все как есть» или закрыть бизнес рассматривать не будем. Они всегда доступны и легко реализуемы. Рассмотрим другие пути, каждый из которых соответствует определенному типу проекта с разной степенью неопределенности.

Вариант радикального изменения бизнеса при удачном стечении обстоятельств может дать колоссальный результат. Но в таких проектах (тип «Мозги») степень неопределенности будет максимальной. Специалисты на проекте не могут спрогнозировать его параметры. Дело в том, что задача в данном случае выходит за рамки создания технологического продукта. Требуется найти решение на стыке бизнеса и цифровых инструментов, чтобы создать новую бизнес-модель. Ни то, ни другое не является константой: бизнес должен ориентироваться на технологические возможности, а проектная команда – на видение бизнеса.

Никто заранее не может сказать, что получится в результате проекта. Будет ли это онлайн-сервис, исключающий агентов и позволяющий клиентам самим искать недвижимость, или интеллектуальная система, помогающая агентам проводить сделки, или мобильные приложения для 3D-сканирования помещений с виртуальными показами. Возможно, получится и то, и другое. Такой проект представляет собой серию исследований и экспериментов. От результатов одного шага зависит то, каким будет следующий. Возможно в какой-то момент станет понятно, что решение не может быть найдено либо его поиск займет непрогнозируемое время. Границы проекта определяются возможностями бизнеса и пониманием того, где, по мнению владельцев, лежит предел разумного риска ради новых возможностей.

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

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

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

Неопределенность при оценке в таких проектах можно держать на относительно низком уровне. Горизонт планирования короткий – один – два месяца, объем работ обозримый и прогнозируемый, что снижает цену возможных ошибок. В то же время задачи локальные, не связанные общей стратегией, выполняются без серьезной предварительной проработки и опираются на гипотезы и недостоверную либо отсутствующую документацию по существующей системе. Результат подобных проектов больше напоминает «письмо из Простоквашино», чем нечто цельное и логически увязанное.

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