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