– Владимир Иосифович, каким образом возникла идея создания Вашего продукта, каковы были предпосылки её появления?

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

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

Тогда на основании наших алгоритмов мы разработали программу, которая фактически не имела никакого интерфейса – он был DOS-овским. В 1990-м году я поехал в Англию с надеждой найти партнёров для совместного предприятия и выхода с продуктом на мировой рынок. Я посетил ряд известных компаний в области проектного менеджмента, уже имеющих пакеты (Open Plan, PlanTrack, Pertmaster), с предложением сделать совместную разработку. Сейчас ни одна из этих компаний уже не существует, но в то время они были одними из лидеров рынка. Я продемонстрировал им нашу разработку, и оказалось, что за счёт оптимизации наши алгоритмы составляют более короткие расписания тех же самых проектов. Но понятно, что успешным на рынке компаниям неинтересно входить во что-то новое, не полностью владея разработкой. Они предложили нам продать алгоритмы где-то за 200 тысяч долларов, сопроводив предложение фразой: «Для вас же это большие деньги!». Это была действительно колоссальная сумма – в самый пик разрухи моя месячная зарплата в НИИ превратилась в какие-то 8 долларов. Но меня обидела эта фраза, задела самолюбие, стала стимулом сделать свой пакет – да так, чтобы он утёр им нос.

В конце 1992-го свет увидела первая версия Spider’а. Первыми клиентами были московское отделение Лейпцигской ярмарки, «Газпром», ряд небольших строительных компаний. Понятно, что спрос на пакет был совсем низким, но зато был интерес к проектному менеджменту, и чтобы развиваться дальше, мы стали зарабатывать деньги на консалтинге и обучении. В 1996 году наступил перелом. В Москве шла большая стройка – на улице Вернадского строили новую олимпийскую деревню. Ещё в начале строительства там начались серьёзные проблемы, и чтобы наладить управление стройкой, привлекли нас. С помощью Spider’а нам удалось кардинально выправить ситуацию – проект был завершён даже на 2 месяца раньше первоначального графика. Наш пакет оценили: в стройке участвовало 17 основных подрядчиков и большая их часть стала использовать Spider. Тогда же, параллельно, мы запустили планирование в рамках другого очень крупного проекта – строительства Каспийского трубопровода. Здесь тоже появились заинтересованные люди. Волна пошла дальше – пакет стали покупать и внедрять.

В 1998 году, с кризисом, большая часть наших клиентов разорилась. Резкий подъём обернулся резким падением. Но после 1999 года пошло восстановление, а дальше – последовал непрерывный рост. Сейчас Spider используется в 32 странах мира, у нас появились отделения в Бразилии, Румынии, Малайзии, Голландии, кое-где ещё. Что касается России, то здесь пакет настолько общепризнан, что используется при реализации практически всех крупных госпрограмм. Универсиада в Казани, подготовка саммита АТЭС во Владивостоке, Олимпиада в Сочи, подготовка к Чемпионату мира по футболу-2018 в 11 городах – всё это делалось или делается на Spider’е. В 2000-м году на Spider’е даже просчитывалась программа реформирования российской армии.

Ракетная система «Триумф» (С-400).

Важный момент: пакет мы никогда не рекламировали и не предлагали его купить – люди должны дозреть до этого сами. У нас в компании даже нет sales-менеджеров. Новых интересантов нам приводят наши же клиенты.

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

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

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

– Функционал Spider’a во многом аналогичен западным продуктам (что, в общем, естественно), но предположу, что имеет и свои особенности. Если это так, то эти особенности – результат глубокой теоретической проработки, о чём Вы говорили ранее, либо же следствие того, что продукт разрабатывался в нашей стране, где подходы к деятельности изначально были отличны от западных?

Есть ряд функций, которые были даже в самых первых версиях Spider, но до сих пор отсутствуют в американских системах. Например, они так и не умеют оптимизировать расписание. График реализации проекта при одинаковых исходных данных, составленный Spider’ом, будет короче, чем тот, что построен Microsoft Project, Primavera или любым другим западным пакетом. Когда мы выводили пакет на рынок, считали, что оптимизация расписания будет нашей фишкой. Ведь что такое построить завод на пару месяцев раньше? Это огромные прибыли. Но оказалось, что профессионалов, которые действительно понимают, что такое оптимизация, не так много.

Другой важный момент – Spider действительно разрабатывался, учитывая наш опыт, наши знания и наши технологии. Поэтому, например, график составляется исходя из оценок объёмов работ на операциях проекта и производительности назначенных ресурсов. Отсюда возникают возможности использовать нормативные базы. То есть в Spider’е вы можете создавать справочники – нормы расходов, единичные расценки, производительности ресурсов. Это то, к чему мы все привыкли, работая на наших предприятиях. В западной же практике исходная информация – длительность. Соответственно, объёмов нет и вводить нормы нельзя. Но чтобы оценить длительность, приходится сначала посчитать её в каком-нибудь стороннем продукте, используя нормирование, а затем результат подставить в пакет. При любых изменениях во внешней программе всё приходится пересчитывать. В Spider’е всё это заложено внутри пакета – вы оперируете кубами, тоннами, и получаете графики. Если изменился объём работ – изменится и график.

Вообще, особенностей у Spider’а много, и если я буду перечислять их все – это займёт достаточно много времени.

Богучанская ГЭС.

– Какие требования предъявляются к системе управления проектами, о которой Вы говорите, и «умелым рукам», на которых она должна держаться?

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

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

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

Мост «Миллениум» в г. Казань.

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

На планировщика проще всего обучить прораба или сотрудника ПТО, это не потребует больших усилий. Частая ошибка – сажать за планирование проекта студента. Но ему сначала по стройплощадке в сапогах походить надо и разобраться, почему здесь так, а не иначе. На это может уйти 2-3 года.

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

– Каковы требования системы для разных позиций: «заказчика», «генподрядчика», «подрядчика», «субподрядчика», «EPC-контрактора»?

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

Контрактный график готовит для заказчика генподрядчик. При этом ему нужно проанализировать риски и заложить в этот график резервы, необходимые для надёжного выполнения контракта. Фактически получается, что в проекте соседствуют 3 графика: контрактный, по которому идёт взаимодействие заказчика с генподрядчиком; более жёсткий внутренний график генподрядчика (включает резервы на риски); ещё более жёсткий внутренний график субподрядчика. Генподрядчик должен очень жёстко требовать от субподрядчика выполнения сроков, понимая, что тот может отстать.

Принципиальное отличие между управлением со стороны заказчика и со стороны подрядчика заключается в том, что заказчик управляет контрактным графиком, а подрядчик управляет ресурсами. Грамотный заказчик может потребовать от подрядчика представить, например, численность рабочей силы: вот на этой работе нужно столько, на этой – столько. Тогда он будет видеть плановое движение рабочей силы и сможет среагировать (предъявить обоснованные претензии), если на площадке будет, допустим, 30 человек вместо запланированных 70-ти. Если у генподрядчика этой информации нет, он теряет всяческую возможность оценки.

Трубопровод Urucu-Manaus, Бразилия.

– Планирование с учётом резервов… Насколько оно принципиально?

Очень! Я же должен понимать, что без проблем могу задержаться на одной операции, в то время как задержка на другой приведёт к срыву всего проекта. Резерв – это то, что вы можете контролировать, но в данном случае не по каждой работе, а по проекту в целом. Допустим, вы даёте подрядчикам жёсткие графики со сроком выполнения до 1 сентября. В действительности же ваш директивный срок – 15 ноября. Вы понимаете, что исполнители будут отставать и съедать этот резерв, и, оценивая текущую вероятность выхода на запланированные показатели, вы понимаете – этот резерв съедается быстрее, чем вы ожидали, или медленнее. Тренд вероятности успешного завершения негативный – значит резерв расходуется слишком быстро, тренд позитивный – значит в резерв вы заложили больше, чем до текущего момента истрачено. Значит всё хорошо. Отчёты по трендам – это ещё одна очень полезная для принятия решений штука. Представьте, что вы получаете информацию, что проект отстаёт от графика на 10 дней. Наверное, это плохо. Но если вы знаете, что месяц назад отставание составляло 25 дней, а 2 месяца назад – 40, то отставание на 10 дней – это хорошо. Если же у меня идёт ухудшение, даже с опережением графика, – мне нужно принимать меры. Поэтому информация о статусе проекта без информации о тренде недостаточна для принятия решений.

Автотрасса Амур (Чита – Хабаровск).

– Ваше понимание критического пути чем-то отличается от того, что заложено в западных практиках?

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

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

Мост на остров Русский.

– И последний вопрос… Мне известно о Вашем спортивном увлечении – альпинизме. Опыт, связанный с этим видом спорта, как-то повлиял на логику работы вашего продукта?

Знаете, познакомившись со стандартами управления проектами, я обнаружил, что они соответствуют той практике, которая в советском альпинизме была общепринятой. Наверное, подсознательно я использовал этот свой опыт. Сейчас, оглядываясь назад, вижу, что всё было поставлено очень грамотно. Если группа выходит на восхождение, она должна представить план: какой участок и за какое время она преодолеет, где у неё будут остановки, какое снаряжение будет использоваться на каждом этапе. Затем по этому плану нужно представить анализ рисков: что и где может случиться, какие предупредительные действия группа будет предпринимать. Допустим, обычно восхождение занимает 17 часов, но может настигнуть неустойчивая погода, поэтому необходимо взять палатку. В случае наступления рисковых событий должны быть заранее определены пути отхода, должно быть продумано, как будет организована связь с базовым лагерем, каким будет сигнал тревоги. Тогда сеансы связи осуществлялись по рации каждые 2 часа, пропуск второго подряд сеанса означал выход спасательного отряда. Если Вам нужно вызвать спасотряд – вот вам ракетница и красные ракеты; если у вас всё в порядке, но вы почему-то застряли и не вызываете спасотряд – зелёная ракета. Т.е. все случаи жизни оговаривались заранее. Перед выходом выпускающий проверял, всё ли у вас есть в соответствии с планом. Изменение маршрута – это ЧП. По окончании восхождения – отчёт: как всё прошло, соответствовало ли это графику, как сработали люди, и т.п. – всё в соответствии со стандартами управления проектами. Поэтому альпинизм можно смело использовать как живой пример применения технологий управления проектами для решения конкретных задач. И это во всех смыслах очень полезный опыт.

PS: на фотографиях изображены объекты, при создании которых использовался пакет Spider.

Подпишитесь на eRazvitie.org в Фейсбуке и ВКонтакте, чтобы не пропустить наши новые материалы.