О проектном подходе

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

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

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

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

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

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

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

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

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

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

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

Деление проектной деятельности на все более мелкие проекты рано или поздно приведет к выявлению проекта, который сам не зарабатывает, но без которого не работает всё остальное. А потом раздаются гневные вопросы «Кто сэкономил на спеллчекере/native редакторе?». Поэтому не надо так делать.

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

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

Не надо так делать.