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

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

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

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

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

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

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