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