НовостиСобытияКонференцииФорумыIT@Work
ИТ-бизнес:

Блог

Главная задача менеджера ИТ-проекта – вовремя смыться?

Владимир Митин
27.01.2012 15:58:59

В комментариях к недавней заметке “Какие критерии оценки качества ИТ-проектов вы используете?” я уже отмечал, что неуспешность ИТ-проекта может быть обусловлена не только непрофессионализмом исполнителя (системного интегратора или ИТ-отдела), но и тем, что заказчик на стадии cоставления техзадания не смог правильно сформулировать задачу ИТ-проекта и определить перечень параметров, достижение которых является критерием качественного решения поставленной задачи.

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

Грамотные менеджеры ИТ-проектов всегда в дефиците и на них всегда есть спрос, превышающий предложение. Главный капитал менеджера ИТ-проектов – надлежащее образование и опыт успешной работы. То есть чем меньше в его послужном списке (резюме) упоминаний об “историях неуспеха”, тем лучше.

Но как сделать так, чтобы этих упоминаний было как можно меньше? Вот что рекомендует на этот счет Сборник вредных советов “Управление ITSM-проектами от лукавого” (авторы – Пол Вилкинсон и Брайан Джонсон, пер. с англ., М., Лайвбук, 2012 г., 166 c.): “Главное — вовремя соскочить. Самое важное здесь — поймать тот момент, когда проект вот-вот начнёт дурно попахивать, но остальные этого ещё не замечают. Самые опытные менеджеры очень тонко чувствуют этот момент и вежливо уходят непосредственно перед провалом. Рекомендуемая формулировка для описания этого бегства — “передал бразды правления”. Обычно это происходит в третьей четверти плана проекта. Разумеется, если вы не успели передать их на этой стадии, то вам понадобится план аварийного покидания проекта -- как правило, при этом назначается козёл отпущения. Однако настоящие профессионалы уходят красиво и до того, как все поймут, какой пустышкой был этот проект”.



Вы согласны с тем, что главная задача менеджера ИТ-проекта – вовремя смыться?
А какие ещё задачи, на ваш взгляд, должен решать менеджер ИТ-проекта?

Комментариев: 8

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Наблюдательрс
27.01.2012 23:39:14

Вовремя смыться - главная задача любого уважающего себя руководителя!
N

Igor
28.01.2012 09:10:34

ГОСТ 34.602-89, Приложение 1, п. 1 "Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки; тактико-технического задания и т. п.)"(http://www.internet-law.ru/law/gosts/34-602-89.htm)

Так что некачественное ТЗ - вина в первую очередь исполнителя, а не заказчика. Во всяком случае, ТЗ - это не плод творчества одного заказчика. Вот такие парадоксы. Так что, когда Вам на подпись принесут готовое ТЗ, составленное под единственного исполнителя с целью, к примеру, обхода закона 94-ФЗ и распила бюджетных средств, то все по закону.

Теперь о вопросе, поставленном в статье. Есть руководители (мне встречались, и они считались почти идеальными руководителями), которые успех проекта всегда приписывают исключительно себе, а в случае провала проекта всю вину за это относят на счет подчиненных. Вот эта точка зрения вернее. А то - смыться, смыться.

Igor
28.01.2012 09:26:17

Дополнение. Последнее предложение 2- абзаца читать как

Так что, когда Вам на подпись принесут готовое ТЗ, составленное под единственного исполнителя самим исполнителем исключительно под себя с целью, к примеру, обхода закона 94-ФЗ и распила бюджетных средств, то все по закону.

Skynin
28.01.2012 11:59:21

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

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

Веру же в ТЗ давно считаю не только наивной но и вредной. Для судебного разбирательства может оно и сгодится. Но в жизни, заказчик сам его пытается изменить, потому что в процессе реализации четче понимает что ему нужно и за сколько. И видит, что то что казалось ему важным - неважно, а стоит - дорого. Конечно, ТЗ например для разработки аппартно-программного комплекса вполне можно сделать и конкретным и неизменным. Хотя и в этом случае, всего лишь уменьшив на 5% требования по надежности можно добиться 10-15% сокращения расходов денег и времени.
Как пример большого проекта для которого можно создать ТЗ - оснащение вебкамеры избирательных участков.

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

Skynin
28.01.2012 12:07:32

P.S.
А если менеджер ИТ проекта досидел до провала, то возникает пара вопросов:
1. Он что, не видел что дело идет к провалу? Значит слепой менеджер. Будет ли он зрячим на следующем проекте?
2. Если видел - почему не смог избежать провала? значит идеалист, мечтатель, излишне амбициозен или бездельник. "Авось пронесет"
3. Если он видел что и исправить уже ничего нельзя - ради чего он сидел до конца? Глуп? Труслив? Или какая-то закулисная корысть?

Олег Скрынник
31.01.2012 11:05:01

Распознать беду совсем несложно. Вот отрывок из той же книжки:

Для того чтобы понять, насколько плохо идут дела, используйте следующие проверенные методы:
• Если вы выглядываете в коридор, сколько людей кричат вам в лицо обидные слова?
• Насколько регулярно вас бьёт ваш босс?
• Вашу должность активно рекламируют?
• На заседаниях комитета проекта присутствуют те, кто даёт деньги?
• Спонсоры, поддержавшие проект на этапе инициации, ещё живы и не на пенсии?
• Как реагируют члены комитета проекта на слова «всё идёт хорошо»: краснеют и потеют? Рычат? Трясутся? Пена изо рта идёт? (способ работает в случаях, когда члены комитета трезвы)
• Часто ли упоминается аутсорсинг?

SpcMjnky
30.01.2012 10:28:56

Получается, ИТ-проекты завершают не менеджеры проектов, а кто тогда?

30.01.2012 11:26:46

Цитата
Получается, ИТ-проекты завершают не менеджеры проектов, а кто тогда?


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

Тут логика проста: если руководство не назначит козла отпущения среди своих подчиненных, то таким козлом станет оно само (в глазах ещё более высокого руководства). Этот принцип справедлив не только для ИТ-проектов. Как вариант – козел отпущения ищется на стороне (в виде происков конкурентов, форс-мажора и т. д.).

Однако быть козлом отпущения (с огромным опытом практической работы) в ряде случаев не так уж плохо – ведь за одного битого, как известно, дают двух небитых. Возможны и другие варианты -- помните, у Владимира Высоцкого (25 января ему исполнилось бы 74 года): “А козел себе все скакал козлом, но пошаливать он стал втихомолочку – как-то бороду завязал узлом и назвал из-за кустов волка сволочью …”.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии