Оценка проектов, планирование и неопределённость

Части главы:
Кто прав, бизнес или специалисты — Почему невозможно точно оценить проект — Что делать с неопределённостью в проектах — Тип проекта как индикатор уровня неопределённости — Бизнес и цели проекта — Живое воплощение неопределённости или выбор специалистов для работы над проектом — Традиционные подходы к управлению проектами как источники неопределённости — О роли проектирования — Итог

Кто прав, бизнес или специалисты?

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

Чаще всего это обновление заключается в совершенствовании уже существующих инструментов. Компания может менять ассортимент продаваемых

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

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

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

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

слишком мало времени и сократил бюджет. Ключевым моментом для понимания является то, что речь может идти об одном и том же проекте. Точка, с которой вы смотрите на реальность, влияет на ваше представление о ней и открывает иную перспективу. Или её отсутствие.

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

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

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

К сожалению, большинство из нас склонны к простым решениям, это в нашей природе. Именно поэтому так популярна идея, что использование определённой методологии или подхода к ведению проектов может решить все возникающие в них проблемы. Многие из моих коллег наверняка помнят огромные буквы AGILE на входе в центральный офис Сбербанка. Но следование нескольким простым правилам никогда не являлось панацеей, ни в том, чтобы за месяц стать стройным и красивым, ни в том, чтобы реализовать сложный проект в рамках запланированного бюджета и с нужным качеством.

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

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

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

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

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

является. Все, что произойдёт дальше в проекте, будет зависеть от людей, в нем участвующих, и от их способности разобраться, что же нужно получить в итоге. Создание нового продукта — это создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).

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

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

Вы все ещё думаете, что можно точно спланировать

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

Бизнес традиционно настаивает на том, что раз уж ИТ-специалисты лучше разбираются в вопросах создания цифровых продуктов, то они и должны отвечать за все параметры проекта. При таком подходе компания, которой заказали разработку продукта, в случае возникновения каких-либо проблем должна решить их за свой счёт. Задача же бизнеса — описать требования к

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

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

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

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

вы неправильно нами управляли или хотели чего-то заведомо ошибочного. Но счета за потраченное нами время должны быть оплачены в любом случае.

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

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

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

счёте кто-то все равно должен заплатить за возникающие издержки, хоть одна, хоть другая, хоть обе стороны.

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

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

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

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

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

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

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

Для начала нам нужно понимать, существуют ли в принципе в проекте неопределённые вопросы. Как я описал выше, для многих участников, особенно со стороны

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

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

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

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

Бизнес на пороге кардинальных изменений. Новое направление в бизнесе или стартап. Работающий бизнес, развивающий свои цифровые сервисы. Типы проектов в жизненном цикле развития бизнеса.

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

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

убить. С другой стороны, когда стоит вопрос жизни и смерти, такой выбор вполне оправдан. Как сказал некоторое время назад Дональд Трамп, лекарство не должно быть опаснее болезни. С ним можно во многом не соглашаться, но тут он прав на 100%.

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

кажется странным, как ИТ-проект может быть столь опасным, но разве неработающий сайт онлайн-магазина не означает остановки бизнеса? А бывают ситуации гораздо серьёзнее.

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

Неопределённость растёт от «Седины» к «Процедурам» и достигает своего максимума в «Мозгах». Коротко это можно объяснить следующим образом. Цель проектов «Седина» как раз и состоит в том, чтобы избежать неопределённости. Используемые решения уже многократно проверены, специалисты участвовали в аналогичных проектах. План работ, сроки и бюджет рассчитываются исходя из прошлого опыта. Все это тем не менее не даёт 100% гарантии, т.к. существуют и другие причины неопределённости, о которых я дальше рассказываю в этой главе.

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

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

Дальше на примерах компаний, находящихся в разных ситуациях, я хочу показать возможные варианты развития событий и способов работы над проектами разных типов. Речь пойдёт о случаях а) бизнеса, который стоит перед необходимостью кардинальных изменений; б) открытия нового бизнес-направления или стартапа; в) успешного бизнеса, развивающего свои цифровые сервисы.

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

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

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

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

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

Вариант радикального изменения бизнеса при удачном стечении обстоятельств может дать колоссальный результат. Но в таких проектах (тип «Мозги») степень

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

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

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

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

спроектированные и опробованные решения и программные компоненты, а их набор и возможная конфигурация ограничены.

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

Есть и третий путь — оставаться в рамках существующей бизнес-модели, последовательно развивая существующий цифровой инструментарий. Такой подход вряд ли спасёт

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

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

на что-то цельное и логически увязанное.

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

Новое направление в бизнесе или стартап

Теперь рассмотрим, как проявляется неопределённость в разных типах проектов на примере запуска стартапа либо создания нового направления в существующем бизнесе. Это частая практика, и в качестве примера можно привести производственную компанию, открывающую

направление онлайн-продаж под заказы с индивидуальными параметрами. Действующую производственную часть компании можно рассматривать как внешнего поставщика для нового направления, и в таком случае искомая бизнес-модель подойдёт и для отдельной компании.

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

бизнеса кажется относительно простой задачей, то после детализации требований все оказывается несколько сложнее.

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

Ошибка может оказаться не на уровне системы, а в предположениях о мотивах покупателей или возможностях производства.

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

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

Работающий бизнес, развивающий свои цифровые сервисы

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

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

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

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

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

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

Уровень неопределённости в таких проектах ниже первого варианта, и основной риск исходит из возможных проблем совместимости предлагаемого продукта с существующей банковской цифровой инфраструктурой. Если внешние и собственные специалисты смогут построить хорошие рабочие отношения, то это позволит им ещё на начальном этапе выяснить все необходимые параметры рабочей среды для интеграции. Как я уже многократно обращал внимание, категорически не стоит при реализации такого проекта выходить за границы заложенных пользовательских сценариев и наработанного опыта, т.к. в таком случае теряются все преимущества проектов типа «Седина».

С учётом вышесказанного я хочу перейти к третьему варианту (тип «Мозги») — самостоятельному поиску моделей коммуникаций с клиентами через новые технологические каналы. По сути, это исследовательская работа с высоким уровнем неопределённости. Руководители должны ясно представлять цели проекта и быть активными его участниками, взаимодействуя с командой специалистов, работающих над новым продуктом. В конечном счёте только они в полной степени понимают бизнес-модель и ключевые особенности банка. Возможных причин выбора такого варианта развития я вижу две.

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

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

Другая причина, и тут я хотел бы отдать должное таким руководителям, заключается в стратегии постоянного поиска новых точек роста и нахождения ниш для развития. Для стабильного и успешного бизнеса нужны регулярные эксперименты по типу «Мозги», чтобы иметь наготове набор возможных вариантов решений. Лучше не оказываться в ситуации, когда становится слишком поздно для вдумчивой подготовительной работы. При таком подходе банк может запустить исследовательский проект задолго до того, как наличие мобильного приложения или голосового ассистента станет де-факто обязательным требованием со стороны клиентов. Возможные неудачи в этом случае будут рассматриваться не как провал всего проекта, а как неподтверждённые гипотезы.

Конечно же, после того как инновационный проект завершён и получен новый работающий цифровой сервис, есть смысл проводить его дальнейшее развитие в формате

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

Типы проектов в жизненном цикле развития бизнеса

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

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

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

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

Бизнес и цели проекта

Думаю, теперь становится понятно, что далеко не всегда можно спрогнозировать параметры будущего проекта, более того, иногда невозможно предсказать даже то, что получится в результате. Бюджет проекта, сроки исполнения — это производные от работ, которые предстоит выполнить. А они в свою очередь зависят от того, какова изначальная цель.

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

Чтобы это сделать, нужно пройти определённый путь. И здесь бизнес находится ровно в той же ситуации, что и специалисты, работающие над проектом. Часто проблема

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

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

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

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

Как видите, путь к пониманию истинной цели может быть

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

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

Прежде всего, отличается причина, по которой люди заходят в обычный магазин и на сайт. Если в первом случае это может быть немотивированный поступок («увидел и просто зашёл посмотреть»), то для того, чтобы

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

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

обслуживания, места и объёмы хранения товара, ну и, конечно же, состав и роли сотрудников, обслуживающих новую схему работы. Если вам кажется, что подобные вопросы способны решить разработчики веб-сайта, то вы явно не на том пути. Как видите, поставив изначально ложную цель — разработать и запустить интернет-магазин, компания оказывается в тупиковой ситуации, т.к. специалисты не способны ответить на вопросы бизнеса, в свою очередь бизнес не может полноценно воспользоваться технологическим продуктом.

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

Живое воплощение неопределённости или выбор специалистов для работы над проектом

Тендерные процедуры. Критерии выбора исполнителей для управления неопределенностью.

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

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

Однако бизнес при запуске проектов и выборе для него специалистов в основном ориентируется на количественные параметры, такие как планируемые сроки, бюджет, количество людей определённых компетенций, которые может предоставить подрядчик, и оставляет за скобками не менее важные, просто не столь понятные, качественные характеристики кандидатов для реализации их проектов. Когда я говорю про кандидатов, то не имею в виду только выбор конкретных людей, но и, конечно же, команд в целом, как единых проектных организмов. И люди, и команды обладают уникальными личными и профессиональными качествами, которые тоже нужно принимать в расчёт. А после запуска проекта уметь использовать эти качества для получения нужного

результата. Такое умение — это тоже компетенция. Его отсутствие со стороны бизнеса делает процесс работы над проектом непредсказуемым.

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

Просто удивительно, как часто компании игнорируют

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

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

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

В идеале на стороне бизнеса должны быть люди, понимающие задачи, которые ставятся перед проектом, и одновременно разбирающиеся в ИТ-индустрии. Конечно, такие навыки и опыт — большая редкость, поэтому бизнес идёт более простым путём и делегирует поиск тех, кто сможет реализовать проект, в отдел закупок или тендерный комитет.

Тендерные процедуры

Несколько лет назад мы с Дмитрием «Goblin» Пучковым записывали ролик, посвящённый тендеру Почты России на

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

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

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

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

возможностей способна действительно сформулировать требования к будущему продукту, т.к. в конечном счёте речь идёт об уравнении с несколькими переменными, где с одной стороны лежит бизнес-модель, с другой — технологические инструменты. Делать одно в отрыве от другого совершенно бессмысленно. Поэтому, не вовлекая ИТ-специалистов в процесс формулирования требований в формате отдельного проекта, бизнес рискует получить результат, которым не сможет воспользоваться.

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

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

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

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

Критерии выбора исполнителей для управления неопределённостью

Какими же тогда критериями должен руководствоваться бизнес при выборе специалистов для проекта? Прежде всего необходимо перестать считать всех, кто работает в ИТ-отрасли «программистами». Это все равно, что считать всех, кто занимается возведением зданий «строителями». Также необходимо отказаться от мысли, что «программисты» отличаются друг от друга «сообразительностью» и при её достаточном уровне способны решить любые задачи. И наконец, не стоит

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

Если перевести этот список для чайников на более предметный язык, то можно сказать, что для разных типов проектов процедура выбора исполнителей должна отличаться, и отличия будут носить принципиальный характер. Обратите внимание, не критерии, а сама процедура выбора. Заодно это затрагивает и то, каким образом будет запускаться проект. В одних случаях специалисты подбираются под проект, а в других — сам проект зависит от привлечённых профессионалов.

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

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

Именно поэтому нельзя поставить на поток работу, например, креативного дизайнера или талантливого архитектора. Пока им интересно, они действуют, и их увлекает сложность задач как таковая. Но периоды творческой активности сменяют моменты поиска вдохновения и переключения внимания на что-то другое. Работа движется неравномерно, а разброс уровня качества результатов может быть очень большой. Все это приводит к тому, что степень неопределённости в проектах, где

требуются нестандартные решения, крайне высока. За смелые идеи приходится платить высокую цену.

Все, что я только что описал, свойственно проектам типа «Мозги». Их удивительная особенность состоит в том, что, вопреки ожиданиям бизнеса, здесь не клиенты выбирают исполнителей, а профессионалы, специализирующиеся на таких проектах, ищут интересные для себя задачи. Бизнесу, чтобы запустить такой проект, нужно его «продать» потенциальным исполнителям. Как вы понимаете, это точно не укладывается в формат классического тендера.

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

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

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

Сильные качества таких людей лучше всего проявляются в ситуациях, когда задачи ставятся ясно и детализировано, а проектная и технологическая среда предсказуема

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

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

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

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

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

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

Теперь можно вспомнить жизненный цикл, по которому движется бизнес, создавая и обновляя свои цифровые

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

Традиционные подходы к управлению проектами в роли источников неопределённости

Слабая вовлеченность бизнеса в проектную работу. Навязываемые сроки. Большие релизы в стиле «все и сразу». Проект без капитана.

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

Впрочем, не стоит ошибаться. Если вы просто опишете правила и предложите участникам инструменты,

например систему управления задачами или средства планирования проекта, то вряд ли все заработает так, как задумано. В вопросах организации проектных команд технократические подходы не работают, одних только инструментов недостаточно, должны быть причины, по которым люди захотят ими пользоваться. ИТ — не та среда, где работают директивные методы.

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

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

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

Дальше я хочу рассказать, каким именно образом создаётся неопределённость при разных подходах

к организации работы над цифровыми продуктами и сервисами компаний.

Слабая вовлеченность бизнеса в проектную работу

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

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

Стоит задать вопрос, а кто заплатит эту цену? Бизнес традиционно считает, что ответственность лежит на исполнителях, не заметивших «очевидные ошибки», на которые ему приходится указывать. Исполнители в свою очередь апеллируют к тому, что обсуждаемые замечания не были описаны в изначальных требованиях. Для меня же очевидно, что ошибочна сама схема работы. Ведь, даже если замечания будут устранены за счёт исполнителей

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

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

Навязываемые сроки

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

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

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

Как следствие, по ходу проекта накапливается неопределённость, которая возникает по мере того, как ожидания со стороны руководства постепенно расходятся с реальной ситуацией. Что происходит в итоге, нетрудно догадаться. Ближе к дате, когда продукт должен был быть готов, выясняется отставание от плана, либо представляется результат, из которого были исключены существенные части, на которые рассчитывал бизнес. И в том, и в другом случае у компании возникают проблемы, аналогичные ситуации с тем, когда нет достаточной

вовлеченности в проект, т.к. для исправления ситуации потребуется дополнительное время и бюджет.

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

Большие релизы в стиле «все и сразу»

В начале главы я привёл закон Галла, утверждающий, что невозможно сразу создать сложную работоспособную систему. Самое время снова к нему вернуться. Хитрость заключается в том, что комплексный продукт подобен растению, которое необходимо вырастить в той среде, где оно будет в дальнейшем жить. Повторюсь, бизнес работает

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

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

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

Компаниям стоит смотреть на цифровые сервисы как на истории, которые они рассказывают своим клиентам и сотрудникам. А хорошие истории невозможно быстро придумать, к тому же, не узнав поближе тех, кому они адресованы. Для этого нужно время, внимательное отношение и диалог друг с другом.

Проект без капитана

Есть старое правило, которое гласит, что на корабле должен быть один капитан. Так и при работе над проектом

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

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

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

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

Может показаться, что в роли такого капитана должен выступать представитель бизнеса. Проблема с этим подходом состоит в том, что часто полномочия у такого человека есть, особенно в силу формата отношения заказчик-исполнитель, но готовности нести ответственность за свои решения — нет. Кроме того, большая часть вопросов связана с технической стороной проекта, поэтому их невозможно разрешить, не обладая

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

В следующих главах, описывающих ключевые принципы «Метода параноика», я собираюсь дать своё видение того, кто и как должен выполнять описанную роль. Пока же предлагаю вспомнить четыре формата работы специалистов из второй главы — «Фармацевт», «Сиделка», «Нейрохирург» и «Психотерапевт». Напомню, идея такого разделения состоит в уровне коммуникаций между бизнесом и специалистами и в степени сложности самих задач. Каждому из них присущ свой способ планирования работ и управления проектной работой. Совмещая формат работы и тип конкретного проекта, можно понять, кто лучшего всего сможет выступить в качестве капитана.

О роли проектирования

Негативная эволюция. Новое время и неопределённость. Документация. Проектирование и бизнес.

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

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

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

можно довести до максимума. У описанной ситуации, как мне кажется, есть несколько причин, и о них я расскажу ниже.

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

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

Особенно в глазах клиентов, для которых в большинстве случаев проектирование — это «рисование дизайна», в лучшем случае они знают термин UX-проектирование. А проектная документация вообще рассматривается многими просто как анахронизм прошлого века. В результате современные методы создания продуктов больше напоминают модные диеты, основанные на предрассудках, чем полноценные системы питания.

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

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

Как я уже писал выше, не существует универсальных «программистов», способных реализовать любой проект. Поэтому перед тем, как формировать проектную команду, необходимо сформулировать требования к её участникам. Без предварительного анализа сделать это невозможно. К тому же создание цифровых продуктов — это не только программирование, и рассматривать его с точки зрения разработки и разработчиков большая ошибка. У этого сложившегося стереотипа есть понятные исторические причины, но пора бы уже уйти от подобного представления.

Негативная эволюция

Разобраться с тем, что же произошло в ИТ-индустрии, мне помог автор книги «Бойцовский клуб» Чак Паланик. В подкасте на вопрос Джо Рогана о том, как устроен процесс написания книги и когда именно он садится за компьютер, чтобы работать над текстом, Паланик ответил, что старается отложить этот момент на время, когда ему больше ничего не остаётся, например в самолёте, и назвал это занятие машинописью (typewriting). К созданию книги этот процесс, по его мнению, относится в последнюю очередь. Основная же работа состоит в поиске, сборе и анализе материалов, причём в случае с Палаником это может происходить где и когда угодно, с использованием любых подручных средств, включая клочки бумаги и салфетки.

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

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

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

Если мы посмотрим на несколько десятилетий назад, то можно будет увидеть кое-что интересное. Раньше нужно было долго готовиться к тому, чтобы передать компьютеру

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

По мере того, как компьютеров становилось все больше и их возможности возрастали, они становились доступнее, и появлялась интерактивность процесса программирования. Можно было проверять результаты своей работы практически сразу, возникало ощущение, что долгой подготовки к программированию можно избежать и перенести все непосредственно в процесс написания кода. К сожалению, при этом потерялась существенная часть того, что также происходило в процессе подготовки — исследование и осмысление задачи, чтобы логика её реализации была цельной и непротиворечивой. Теперь процесс разработки больше напоминает шаманство, когда

программист просто угадывает комбинацию компонентов и кода, которые будут более-менее работать.

Как говорится, ребёнка выплеснули вместе с водой. Упростив технические процедуры программирования, одновременно были упущены действительно важные аспекты, которые раньше входили в подготовительную работу. Были пущены на самотёк и где-то растворились внутри процесса разработки задачи проектирования архитектуры и интеграции с внешними сервисами, формализация функциональных требований и детальная проработка логики работы компонентов системы. Принятие столь важных решений случайно оказалось в руках программистов. А как должно быть понятно из примера со строительством, при создании сложных продуктов требуется комплексный взгляд на задачу и специальные навыки архитектора.

Новое время и неопределённость

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

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

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

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

Даже небольшой проект содержит в себе бесчисленное количество требующих решения вопросов, которым при описанном подходе не было уделено внимание на этапе проектирования. Это может быть наличие актуальной документации на внешние сервисы, проверка технической

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

Кстати, именно этим объясняется довольно распространённая ситуация, когда по итогу активного периода разработки начинается долгая и непредсказуемая по срокам стабилизация продукта. Исправление одних ошибок приводит к появлению других, и иногда кажется совершенно невозможным привести одновременно все в работающее состояние. Так себя проявляет скрытая неопределённость, возникающая из-за отсутствия проектирования и концептуальной целостности системы.

Документация

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

Самый простой пример — постановка и отслеживание задач. Если раньше руководитель, проходя через офис, мог вживую увидеть, насколько активно идёт работа, и, глядя на конкретного человека, вспомнить о давно порученной задаче, то сейчас контроль утерян. Чтобы понимать, как продвигается работа, необходимо уделять больше внимания описанию задач, чтобы в дальнейшем иметь возможность проверить качество их выполнения.

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

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

в него архитектурные принципы и сохраняя целостность.

Управление такими проектами также представляет собой непростую задачу. Не имея полного понимания обо всех частях будущего продукта, менеджеры не могут оперативно отслеживать ход работ и быть уверенными в качестве результата. Такой проект в некотором смысле напоминает коробку с котом Шредингера, которую нужно открыть, чтобы узнать, все ли в порядке с животным. Так и здесь, чтобы понять, что происходит в проекте, нужно заглянуть в каждый его уголок, пообщаться с каждым из участников, собрать всю информацию вместе и на её основе дать ему оценку. Затрудняюсь представить, как это можно делать, например, на ежедневной основе и сколько усилий для этого потребуется от всей команды.

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

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

Проектирование и бизнес

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

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

Качественное проектирование включает в себя как минимум три аспекта — функциональное, интерфейсное и техническое. В этой главе я только упоминаю их, в следующих частях книги я рассмотрю эту тему подробнее.

Помимо того, что проектирование является методом создания продуктов, оно связывает разных участников экосистемы. Проектная документация выступает языком общения между компаниями, например «Психотерапевтом» (продюсер) и «Фармацевтами» (команды разработки), участвующими в одном проекте. С учётом того, что в современном мире участники проектной команды могут находиться даже в разных странах, такое свойство проектирования даёт преимущество тем, кто его использует.

Вместе с локализацией функций разных участников распределённой команды проектирование локализует и неопределённость в проекте.

Итог

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

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

с качеством получаемых результатов, а кроме того, потребует непредсказуемых трат на создание цифровых продуктов.

Напротив, если принять неопределённость как неотъемлемое качество процесса работы над проектами, то логично задаться целью обрести инструменты её контроля. Собственно, эту цель и преследует «Метод параноика». Этому посвящена оставшаяся часть книги. Здесь же в завершении главы я хочу в нескольких тезисах сказать, как в принципе стоит подходить к неопределённости.

Во-первых, от всех, кто участвует в проекте, требуется понимание и принятие фундаментальных причин возникновения неопределённости, вытекающих из самого характера этого рода деятельности.

Во-вторых, нужно знать источники возникновения неопределённости, которые находятся как на организационной стороне, так и технической.

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

В-четвертых, исходя из вышеописанного, уметь структурировать работу над проектом так, чтобы ограничивать влияние разных источников неопределённости в пределах отдельных этапов работ или компонентов системы, не давая перейти всему проекту в состояние полной непредсказуемости.

Предыдущая глава

Как устроена индустрия создания цифровых продуктов

Нетривиальный взгляд на устройство индустрии с точки зрения денег, типов проектов и исполнителей.

Следующая глава

Введение в «Метод параноика»

Введение в «Метод параноика» как инструмент для контроля неопределенности в проектной работе. Определение границ применимости метода.

Книга

Заказать в бумажном формате, загрузить электронную копию, послушать аудиокнигу или почитать онлайн на сайте

Автор

Вадим Митякин — консультант и автор метода, действующий ИТ-предприниматель с более чем 25-летним опытом создания цифровых продуктов для разных компаний, среди которых Сбербанк, Visa, Афиша, Коммерсант, Ведомости, Литрес, Майкрософт, Яндекс, Связной и многие другие. В роли консультанта работает с такими компаниями, например, как автопроизводитель электромобилей Атом и частная космическая компания SR Data.

Консалтинг

Внедрение методологии продуктовой разработки, построение проектных офисов и настройка команд, проектирование и анализ бизнес-моделей для компаний и цифровых продуктов.

Подкаст

Подкаст об устройстве компаний и продуктов, в который я приглашаю их создателей. Это совершенно разные люди, но всех их объединяет одно — любовь к делу, которым они занимаются.