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

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

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

Откуда берется НЧН?

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

Мода

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

При выборе той же ERP-системы главенствующим фактором может являться количество шума, производимого тем или иным поставщиком, а не предназначение или функциональность самой системы. И руководитель в этом случае соглашается заплатить, прежде всего, за удовольствие на очередной конференции гордо произнести: "А мы внедряем систему Икс!".

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

Вспоминается случай из практики. Одна компания, пойдя на поводу у веяний моды и рекламных заверений, стала готовиться к внедрению достаточно популярного на тот момент решения по автоматизации. Для поддержания боеготовности был нанят специалист, имеющий большой опыт работы с внедряемой системой. Проработав неделю, он обратился к руководству и попытался объяснить, что в рамках существующего бизнеса от ИТ-системы потребуются сценарии работы, которые в выбранном решении не реализованы и не реализуемы по определению. С другой стороны, без этих сценариев внедрение теряет всякий смысл. Однако результат этого обращения оказался плачевным. Руководство с интонацией, полной священного пафоса, провозгласило: "Да вы что!! Это же ТАКАЯ система!!!", и смутьян был уволен в течение двух часов. Все последующие многомесячные усилия проектной команды оказались тщетными в силу возникшей НЧН-неопределенности: а что, собственно, должна делать эта система, если она не делает того, что надо?

"Эффект сороконожки"

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

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

Собственные вопросы

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

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

Серьезным же людям, не желающим тратить собственные капиталы на кибернетическое разбитое корыто, можно дать несколько советов:

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

Раскрытие НЧН-неопределенностей

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

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

Аксиому номер два лучше всего выразить словами основателя школы объектного проектирования Грейди Буча: "Только собачьи будки строятся без чертежей". Иными словами, если в проектной команде трудятся несколько человек, нужно найти такой способ изложения мыслей, при котором информация понимается совершенно однозначно, и ее двоякое толкование невозможно в принципе. По аналогии, если на строительстве дома заняты архитектор и каменщик, то чертежи должны быть таковы, чтобы каменщик сложил стены именно там, где их задумал архитектор. Роль такого чертежа в ИТ-проектах выполняет модель информационной системы. Существует множество нотаций, в которых строятся модели (IDEF, UML и другие), но все они выполняют одну и ту же функцию единой информационной шины в рамках проекта. И если кого-либо в проекте посетит мысль пренебречь моделированием, стоит напомнить ему, что ошибка, исправленная в модели системы, обходится в десятки, если не в сотни раз дешевле, чем последующая переделка некорректно написанного кода.

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

В качестве резюме несколько советов по ликвидации НЧН-неопределенностей:

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

И последнее. Помните, что НЧН-неопределенности сводят результат любого проекта к нулю. При времени, стремящемся к бесконечности.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам