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

Джордж Хилмейр, бывший директор DARPA, финансировавшего разработку лежащих в основе Internet технологий, выдвинул набор критериев, называемых иногда катехизисом (наставлением) Хилмейра, по которым оценивались соискатели грантов DARPA. ИТ-менеджерам стоит воспользоваться этой методикой при сборе данных, анализе и обосновании предлагаемых проектов, а также для оценки проекта с точки зрения его эффективности для компании. Этот набор критериев поможет подготовить необходимые данные для защиты проекта перед высшим руководством. В данной статье катехизис Хилмейра представлен в виде восьми наборов вопросов. Ответы на эти вопросы помогут подготовить полноценное предложение проекта.

1. Какую проблему вы пытаетесь решить?

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

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

2. Как проблема решается сейчас? Какие ограничения присущитекущему решению?

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

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

3. В чем заключается новизна предложенной идеи?

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

4. Какую пользу принесет проект?

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

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

5. Каким образом будут достигаться ближайшие, среднесрочные и долговременные результаты?

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

6. Как определить продвижение в реализации проекта? Как измерить эффективность реализации проекта?

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

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

7. Как определить, что проект завершен?

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

8. Какова стоимость проекта?

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

Не полагайтесь на случай

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

Бен Смит - Специалист по безопасности в компании Microsoft. bensmi@microsoft.com