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

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

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

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

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

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

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

Не всегда знаешь, чего хочешь

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

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

Важные требования к системе зачастую непредсказуемы. Этому высказыванию предлагается альтернативное: всегда можно заранее предвидеть все основные требования, не зависимо от размера, сложности системы и скорости изменений в сфере технологий и бизнеса. Когда в начале 90-х компания Cisco удачно установила систему ERP, никто не подозревал, что потребуется добавить систему поддержки продаж, до тех пор, пока продавцы не осознали, чего недостает системе ERP. В результате адаптация, произведенная в середине внедрения и значительно расширившая масштаб проекта, оказалась решающей для успеха. Сторонники альтернативного мнения могут продолжать упорствовать в том, что теоретически Cisco могла предвидеть эту сложность. Однако в процессе осуществления проекта, как правило, возникают непредвиденные проблемы (и возможности). Любой управленческий подход, основанный на противоположной точке зрения, нереалистичен.

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

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

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

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

Управление новым стилем работы

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

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

Если принять эту философию, изменения, необходимые в управлении ИТ-проектами, распадаются на две обширные категории: финансирование и управление проектами.

Финансирование

ИТ-проект нельзя финансировать так же, как завод по производству запчастей. Модель, которой пользуются при покупке завода или оборудования, не является единственно верной. Венчурные капиталисты следуют другой модели. Согласно бытующей в их среде мудрости, нужно поэтапно ассигновать средства на неопределенную деятельность (такую, как ИТ-проекты или новые деловые риски). Венчурный капиталист рассуждает так: «Если предприниматель хочет 10 млн. долл., пусть для начала возьмет 300 тыс. долл., а когда дело заработает, вернется ко мне? Когда будет что показать, тогда можно обсуждать последующие инвестирования». Осуществляя ассигнование подобным образом, венчурный капиталист сохраняет за собой право продолжать инвестирование или нет, и контролирует риски. Если все пойдет хорошо, следующее инвестирование может составить 800 тыс. долл., а затем и 3 млн. долл. Конечная сумма может оказаться даже больше первоначальных 10 млн. долл., но риск будет гораздо ниже, чем при единовременном инвестировании.

Управление проектами

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

Как избежать нокаута

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

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

Роб Остин, профессор Гарвардской бизнес-школы и председатель программы обучения директоров информационных служб. Соавтор книги «Искусство управления: что нужно знать менеджерам о работе мастеров» (Rob Austin. Artful Making: What Managers Need to Know About How Artists Work). С ним можно связаться по адресу: raustin@hbs.edu.

Rob Austin. No Crystal Ball For I.T. CIO Magazine. July 1, 2005