ОБЩИМ ВЗГЛЯДОМ
Каждый раз, проезжая мимо потерпевших дорожную аварию, думаешь: "Слава Богу, что это не со мной!". То же самое происходит и в жизни профессионалов ИТ, когда те узнают об очередной катастрофе в какой-то организации. Казалось бы, любой из таких примеров должен был бы послужить наукой для других. Но почему же мы вновь и вновь узнаем об авариях с системами ИТ?
Я отнюдь не претендую на звание гуру управления ИТ-проектами и не обещаю дать на этот вопрос исчерпывающий ответ, который гарантировал бы стопроцентный успех любой работы. Однако, руководя фирмой и оказывая консультационные услуги, я добился кое-каких результатов при развертывании систем и решении сложных проектных проблем. Опыт деятельности в этой области, дополненный выводами моих собственных расследований широко известных катастроф с развертыванием систем, позволил выработать несколько правил, и я неукоснительно придерживаюсь их при реализации любого проекта ИТ - без каких-либо исключений.
Во-первых, огромное значение имеет поддержка идеи со стороны конечных пользователей и наличие энтузиастов. Если проект не по душе сотрудникам, если среди них не окажется хотя бы одного приверженца, то все ваши усилия пропадут втуне.
Во-вторых, нужны опытные ведущие. В идеале на эту роль больше всего подходит хорошо знакомый сотрудникам специалист ИТ, обладающий даром лидера и сохраняющий полное самообладание при любом развитии событий. Такой человек должен уметь внушать другим чувство уверенности и увлекать коллег, но при этом не быть диктатором.
В-третьих, необходимо постоянно оценивать ход реализации проекта. Сначала выполните пилотную программу и по ней определите, стоит ли вообще приступать к нему. Когда же реализация началась, наметьте четкие вехи, наглядно показывающие, как движется дело.
В-четвертых, найдите или воспитайте гуру из числа опытных пользователей. Сотрудникам нужен коллега, к которому всегда можно обратиться за советом и помощью. К тому же у них вполне может появиться мысль: "Если такой-то стал настоящим экспертом, то и я могу!".
В-пятых, убедитесь, что ваши проблемы известны производителям. Заранее предупредите их, что вы рассчитываете на помощь. Постройте свой контракт с ними так, чтобы он содержал намеченные вами вехи. А сделать плановые сроки более реальными зачастую помогают предусмотренные в контракте штрафные санкции.
В-шестых, нужно четко знать, когда стоит выделять на проект корпоративные ресурсы, а когда лучше прервать его. Принимать решение нужно до того, как будет затрачено слишком много времени или денег, чтобы отказаться от проекта. Если показатели, намеченные какой-то вехой, не достигнуты, значит, не исключено, что работы придется свернуть. Высшее руководство должно при этом понимать, что произошедшее - отнюдь не признак провала.
Наметив заранее контрольную точку и задав для нее четкие параметры, вы сможете избежать ситуации, когда решение принимается на основе эмоций или неполной информации, тем более что обосновать такое решение перед руководством будет сложно.
Возьмите на вооружение эти правила, и шансов на успешное завершение проекта ИТ у вас станет намного больше. 4 Связаться со Скоттом Лангдоком можно по адресу: slangdoc@attbi.com. Свои комментарии шлите на адрес: free_spectrum@ziffdavis.com.
