Конечно, бизнес не решает такие задачи самостоятельно, а привлекает IT-специалистов. В предыдущей главе я описал внутреннюю кухню цифровой отрасли: типы проектов, форматы работы, экономическую модель проектных команд и компаний, создающих цифровые продукты и сервисы. Независимо от того, работают ли IT-специалисты в штате или бизнес заказывает проект у сторонних технологических компаний, взаимодействие бизнеса и профессионалов – непростая задача. Многие проекты завершаются, либо значительно превышая ожидаемые сроки и стоимость, либо без требуемого результата. Но чаще всего происходит и то, и другое. Только в отдельных случаях бизнес получает то, на что изначально рассчитывал.
Вы, наверно, уже догадались, что эта глава посвящена проектной работе – процессу превращения бизнес-задач в действующие цифровые инструменты. Также эта глава о неочевидных причинах того, почему такие проекты не удается реализовать. Почему причины неочевидны? С точки зрения бизнеса все кажется просто: к проекту привлекли специалистов, которые не уложились в сроки или реализовали продукт плохого качества. С точки зрения профессионалов, создающих цифровые продукты, причина тоже не вызывает сомнений: бизнес нечетко поставил задачи, выделил мало времени на реализацию и сократил бюджет. Только вот речь может идти об одном и том же проекте. То, как вы смотрите на реальность, влияет на ваше представление о ней и открывает иную перспективу. Или ее отсутствие.
Бизнес часто настаивает на своей формальной правоте: раз продукт заказан, он должен быть получен в требуемом виде. Из-за непонимания природы проектной работы над цифровыми продуктами компания часто теряет время и деньги, а иногда рискует своим существованием. Цена слишком высока, чтобы настаивать на своем и не попытаться разобраться в истинных причинах проблем.
То же самое можно сказать и про профессионалов в сфере цифровых продуктов. Немногим из них посчастливилось поработать с обеих сторон проектных баррикад. Знание того, что происходит на противоположной стороне, дает более глубокое понимание проблем. В результате проекты, выполняемые такими людьми, с большей вероятностью достигают успеха. Ильяху Голдратт называл попытку поиска компромисса между разными точками зрения способом создания иллюзии. Люди с таким ясным взглядом лишены подобных иллюзий, и в этом их ценность. Многие проекты получили бы шанс, если бы в них учли такой уникальный опыт.
К сожалению, большинство из нас склонны к простым решениям. Поэтому так популярна идея, что использование определенной методологии или подхода к ведению проектов может решить все проблемы. Многие мои коллеги наверняка помнят огромные буквы AGILE на входе в центральный офис Сбера. Но следование нескольким простым правилам никогда не было панацеей – ни для того, чтобы за месяц стать стройным и красивым, ни для того, чтобы реализовать сложный проект в рамках запланированного бюджета и нужного качества.
Почему невозможно точно оценить проект
Одним из самых сложных аспектов работы над проектами является их оценка, включая стоимость и сроки. Это касается как начальной стадии, когда бизнес определяет предполагаемый бюджет, так и последующих этапов, когда расходы на проект непредсказуемо растут, а сроки сдвигаются. Из-за непонимания причин такой ситуации многие проекты обречены с самого начала, хотя попытки найти виновного продолжаются весь период работы и тем более – после. Мой опыт показывает, что не существует проекта, который избежал подобной участи.
Бизнес склонен видеть причину неверной оценки в низкой компетенции привлеченных специалистов. На первый взгляд это кажется обоснованным, ведь профессионалы часто дают повод для таких суждений. Но возможно ли спрогнозировать и рассчитать бюджет, спланировать работы в самом начале проекта, когда о нем известно очень мало? Не является ли ошибочным само требование сделать подобную оценку?
Начать нужно с объяснения уникального отличия процесса создания цифровых продуктов от обычных услуг, производства товаров и их продажи. Разница заключается в степени неопределенности. В цифровых проектах она крайне высока. Когда вы покупаете товар в магазине, неопределенности нет – вы платите деньги и получаете товар. Если вы занимаетесь производством, то у вас есть технология (карта), которая определяет характеристики будущего товара (территории), сроки его изготовления и требования к исходным материалам. Но когда вы создаете цифровой продукт, есть только ожидания того, как он повлияет на бизнес, и иногда смутные представления об интерфейсе. Техническое задание тоже редко вносит ясность, так как часто не является полноценным. Все, что произойдет дальше в проекте, будет зависеть от участников и их способности понять, что нужно получить в итоге. Создание нового продукта – это создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).
Вы можете возразить: раз все так плохо, то почему в принципе существуют цифровые технологии, а бизнес их использует? Вероятно, вы также скажете, что проектная команда после получения требований к будущему продукту может воспользоваться наработками из предыдущих проектов и опытом индустрии. Это верно. Но откуда вы знаете, какую цену заплатил бизнес за работающие продукты и сколько проектов не получилось? Действительно ли они получили то, что заказывали? Неявные различия даже в похожих между собой проектах могут быть очень большими, а способов решить одну и ту же задачу у программистов и дизайнеров еще больше.
Задумайтесь на минуту. При проектировании и разработке каждый специалист принимает тысячи решений. Это касается набора функций, интерфейса, технической архитектуры, выбора библиотек, стиля программирования, схем интеграции с внешними сервисами и сценариев взаимодействия с пользователями. Не существует единственного способа решения той или иной задачи. Кроме того, все решения взаимосвязаны и влияют друг на друга. По мере продвижения от первоначальных требований к готовому продукту возникают новые задачи и вопросы, их невозможно предсказать заранее. В результате каждый проект – уникальное сочетание навыков специалистов, случайностей и озарений, лени и личных проблем, влияния мнений и особенностей взаимоотношений в проектной команде, ограничений по времени, бюджету и требований со стороны бизнеса.
Вы все еще думаете, что можно точно спланировать проект, зафиксировать его стоимость и определить дату завершения? Я пришел к выводу, что не существует подхода или методологии, которые гарантируют получение нужного вам цифрового продукта. Миша Токовинин, основатель AmoCRM, сказал, что все споры о методологиях разработки программных продуктов сводятся к обсуждению оптимальной длины итераций в проектах. В одних случаях продукт реализуется в рамках одной длинной итерации, а в других, как в случае со Scrum, за несколько коротких и фиксированных по длительности. Я же утверждаю, что ключевой вопрос состоит в том, кто заплатит за риски проекта, которые вызваны высокой степенью неопределенности, присущей этой сфере.
Бизнес традиционно настаивает: IT-специалисты – эксперты в создании цифровых продуктов и должны отвечать за все параметры проекта. При таком подходе компания, которой заказали разработку, в случае возникновения проблем должна решать их за свой счет. Задача бизнеса – сформулировать требования к будущему продукту и оплатить работу по его созданию, но только если итоговый продукт будет соответствовать изначальной задаче. Единственным исключением, при котором бизнес готов увеличить бюджет, является изменение первоначальных требований. Хотя на практике это часто становится предметом споров, ведь любые изменения можно трактовать и как новые требования, и как уточнение существующих.
Поскольку никто на корпоративном и законодательном уровне не делает различий между традиционными услугами и созданием цифровых продуктов, то именно так строится модель привлечения подрядчиков через конкурсы и тендеры, когда от поставщика требуется дать оценку будущего проекта на основании предложенного задания. Ошибочной является сама идея о том, что возможно в самом начале проекта, в момент, когда в руках специалистов находится минимум информации, спрогнозировать параметры будущего проекта. Чтобы у них появилась ясность, нужно пройти достаточно долгий путь, и он точно не укладывается в рамки предпроектного обследования.
Здесь важно вспомнить закон Галла, утверждающий, что «любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».
Компании, занимающиеся разработкой цифровых продуктов на заказ, стараются избегать ответственности. То же относится к IT-специалистам, работающим внутри бизнеса. Наиболее популярный прием для переноса рисков на бизнес – продавать не результат, а процесс. Модель такова: специалисты с известными компетенциями в дизайне, проектировании и разработке продают свое рабочее время, а бизнес несет ответственность за то, как использует их время и профессиональные навыки. Если результат не соответствует ожиданиям, значит, бизнес неправильно управлял процессом или хотел чего-то заведомо ошибочного. Но счета за потраченное время должны быть оплачены в любом случае.
Когда на стороне заказчика есть специалисты по проектному управлению, подобная модель действительно позволяет бизнесу быстро сформировать команду из профессионалов, фактически арендовав их на время проекта. В остальных случаях подрядчики прибегают к различным ухищрениям, например, предлагают работать над проектом по гибкой методологии. При этом команда специалистов рассматривается как единый механизм с нужным набором компетенций (обычно неизменным от проекта к проекту), работающий в соответствии с текущими запросами бизнеса. Это подается как преимущество: клиент сам определяет направление развития продукта, уточняет требования и устанавливает приоритеты. Проект движется своим чередом, и «все будет готово, когда будет готово». Вам что-то не нравится, и вы хотите ясности? Похоже, вы ретроград и не следите за трендами, сейчас все agile!