Когда ИТ-проекты идут ко дну, эмоции нарастают
Эксперты Computerworld выяснили, что чувствуют специалисты, когда крупные технические проекты идут насмарку, и как бороться с этими чувствами.
Дан Харрис, работающий сейчас в Computer Sciences руководителем отдела всемирной программы United Technology, до сих пор помнит то ощущение потери, когда его проект заморозили, хотя произошло это целых 20 лет назад. Тогда Харрис работал над ПО для акустических локаторов, управляемых ракетными эсминцами. Это было высокоразвитое, математически сложное программное обеспечение, и он "с головой ушел в эту работу, которая ему действительно приносила удовольствие". Но 1990-й стал неудачным годом для военной промышленности. Холодная война подходила к концу, и снижение угрозы означало сокращение бюджетов, и, в конечном итоге, урезание проектов. Неожиданно ту часть работы, которую выполнял Харрис, отложили в долгий ящик.
"Да, состояние было довольное депрессивное, - вспоминает Харрис. - Не испытывая больше волнения от разработки, у меня было такое чувство, будто я что-то потерял. Я очень хорошо это помню". Особенно болезненно Харрис воспринимал тот факт, что вся работа и усилия его команды были просто выброшены за ненадобностью на свалку. Отмена проекта и состояние отрасли в то время заставили Харриса совсем уйти из военной промышленности, после чего он занялся разработкой софта для использования в коммерческих целях.
Очень трудно оставаться бесстрастным, если длительные, серьезные технические проекты несправедливо уничтожаются, или они внедряются, имея технологические дефекты. "Особое удовлетворение от работы возникает, когда ты видишь, что твой продукт работает, что его используют твои заказчики и компания, - считает Кен Корлесс, директор компании Accenture по разработке приложений для предприятий. - А как вы будете себя чувствовать, если вы работали над проектом в течение 19 месяцев, а последние полгода вообще по 80 часов в неделю, и вы знаете, что через 6 недель проект будет запущен, и тут у вас выбивают почву из-под ног?".
Не забывайте о чувствах
Проблема заключается в том, что когда ИТ-специалистам плохо, они не говорят о своих чувствах. Билл Хагерап, старший консультант компании Ouellette & Associates по человеческим аспектам ИТ-управления, считает, что "технари" довольно скоры на расправу с чувствами. "Скажу банальную вещь, но наша сила - в разуме. Мы великие решатели задач, которые стремятся забывать о своих чувствах".
Хагерап, несколько лет проработавший в корпоративном ИТ-отделе, прекрасно помнит, в какой депрессии он был после провала одного проекта. Он целыми днями без выходных работал ведущим аналитиком на проекте в медицинской страховой компании. Несмотря на все усилия, выделенного времени было явно недостаточно, и то, что его команда сумела представить к сроку подачи проекта, составляло всего 60% от ожидаемых результатов. Ситуация в ИТ-отделе была безрадостной, рассказывает Хагерап. Конечно, всеобщего уныния, связанного с плохими результатами проекта, было не избежать, но если бы команде немного посочувствовали, справиться с ситуацией было бы гораздо проще, считает он. ИТ-руководителям нужно было поговорить со своими сотрудниками о необоснованном окончании проекта, дать им высказаться о наболевшем. Даже несколько простых слов благодарности за приложенные усилия могли бы оказать команде неоценимую поддержку, уверен Хагерап.
В конечном итоге его группа доказала: объем проекта был слишком велик для того, чтобы успеть уложиться в назначенные сроки. Если бы об этом говорилось в открытую, то можно было бы избежать такой депрессии, из-за которой в результате пострадала производительность труда. Конечно, неформальные беседы за обедом и за кружкой пива по пятницам постепенно вывели его команду из этого состояния. "Мы заняли своего рода круговую оборону, набирались друг от друга смелости и все время напоминали себе, что это была не наша вина". Через какое-то время команда Хагерапа даже смогла завершить проект и достигнуть поставленных целей, хотя они никогда не ставили себе это в заслугу. Но он убежден, что его команда справилась бы с хандрой гораздо быстрее, если бы менеджеры поговорили с ними о том, что произошло. Но такая реакция, очевидно, не "входит в сценарий поведения рядового CIO".
Неумение общаться
У каждого замороженного проекта есть своя печальная история. Какие-то из них страдают от непредвиденных событий - конец холодной войны, экономический кризис, слияние компаний или смещение бизнес-приоритетов. Другие идут ко дну из-за неудачного сочетания технологий, амбиций и умений. Но вне зависимости, почему проект "завис", он так или иначе связан с одной из самых постоянных человеческих проблем - неумением общаться.
Майкл Кригсмен, CEO консалтинговой компании по управлению ИТ-проектами Asuret Inc., рисует типичную цепочку отсутствия коммуникации, которая частенько сопровождает проблемные ИТ-проекты. Команда - менеджеру по проектам: "Вы видели сроки? Мы не сможем закончить проект к этому времени, даже если будем работать без сна и отдыха". Менеджер по проекту - CIO: "В связи с проектом возникли некоторые проблемы. Нам нужно немного больше времени". CIO: "Нужно, чтобы проект заработал". CIO – руководству: "Я говорил с менеджером по проекту, и его команда в курсе, что они должны закончить этот проект". "А подтекст здесь такой. Мол, если вы не закончите проект, мы вас быстренько всех уволим", - объясняет Кригсмен. Как только топ-менеджер отказывается отодвинуть сроки выполнения проекта, далее все события развиваются как в сериале. ИТ-отделу приходится трудиться, как ни в чем не бывало, пока неминуемый провал проекта уже невозможно игнорировать.
В некоторых компаниях отделы вынуждены играть в игру "Кто виноват?", где все состязаются за право не признаться первым, что они не могут выполнить проект к обозначенному сроку. Там, где несколько отделов не могут обеспечить выполнение целей проекта, первому "моргнувшему" зачастую приходится всю вину за неудачу проекта брать на себя. "В результате, одни несчастны, другие тайно злорадствуют", - говорит Кригсмен.
По словам Харриса, эмоциональное перекладывание вины на другого - это "непрофессиональное и ненужное занятие". Самым приемлемым решением здесь будет разумное "вскрытие" проблемы. Например, в его компания используется причинно-следственный анализ, который помогает определить, в каком месте проект потерпел неудачу, и какие шаги необходимо предпринять, чтобы избежать подобных ошибок в будущем.
Близко к сердцу
Когда бизнесу необходимы перемены, "зарубаемые" проекты, возможно, оказываются самым простым балластом, от которого членам команды надо избавиться, если это, конечно, не произошло по чьей-то вине.
Но в реальности, считает бывший CIO Джон Фишер, "очень сложно адекватно воспринимать ситуацию", когда проект, развивавшийся удачно, закрывают. "Все задают себе вопросы: "Мог бы я сделать это лучше? Как мы могли бы заставить этот проект работать на бизнес?" Да никак. И это подрывает веру в свои силы многих специалистов. Эмоции больше бушуют на тех проектах, которые считаются ключевыми, отмечает Фишер, и перспектива быть от них отстраненным лишь усиливает тревогу.
В середине 80-х годов Фишер сам участвовал в закрытии проекта по разработке международной банковской системы для одного из американских банков. Он пришел в компанию, когда двухлетний проект уже находился в разработке. Несмотря на то, что проект выглядел многообещающим, было понятно, что даже команда из 45 человек не может эффективно и экономно разрешить проблемы, связанные с отсутствием некоторых важных характеристик. Тогда Фишер посоветовал закрыть проект. Было много разговоров о том, как его спасти, но, в конце концов, все пришли к выводу, что это невозможно. "Это было непростое решение, оно повлияло на многих людей, которые участвовали в проекте", - говорит он. Ему пришлось уволить десяток контрактников в Лондоне и закрыть за ненадобностью центр обработки данных, поскольку оборудование для него было специально закуплено под этот проект. Никто из ИТ-персонала банка тогда не потерял свою работу, да и сам Фишер "прекрасно себя чувствовал", ведь он сэкономил средства и время компании.
Но лишь позднее он понял, что и на него самого, и на членов его команды провал проекта повлиял очень сильно. Какое-то время его сотрудники были вынуждены выполнять низкопрофильные и менее интересные задания, несмотря на приобретенный в ходе выполнения проекта опыт.
Признать свою вину
Когда Шерон Джитл руководила ИТ-отделом в юридической конторе, она одобрила апгрейд LAN, хотя он включал некоторые новые технологии из Cabletron. Ее сетевому администратору безумно понравилась технология, и он с энтузиазмом поддерживал проект. Но оборудование не работало, и сеть продолжала отказывать. "Через месяц попыток заставить ее работать, и после того, как юристы были готовы выбросить ИТ-сотрудников из окна, мы решили покончить с этим предприятием", - рассказывает Джитл. Тогда ей пришлось "заколоть себя своим собственным мечом". Она призналась руководству, что ИТ-отдел совершил ошибку, занявшись непроверенной технологией, и вкратце обрисовала новый подход, включая Ethernet. Компания Cabletron предоставила новое оборудование без дополнительных затрат и помогла его установить. Джитл также понизила в должности сетевого администратора, который позднее совсем ушел из компании.
Хотя моральное состояние в ИТ-отделе во время проекта был ужасным, она отметила, что особенной депрессии после его отмены не наблюдалось. Сотрудники были рады тому, что у них есть сеть, которая работает! Ее открытость ослабила напряжение, и хотя юристы какое-то время и шутили что-то насчет "пятниц без компьютеров", но работающая сеть оказалось лучшим лекарством после неудавшегося проекта.
Метод "отдирания лейкопластыря"
Корлесс из компании Accenture двумя руками поддерживает прямой подход в решении проблем, который использовала Джитл. ИТ-менеджмент поможет своим сотрудникам лучше всего, если быстро и напрямую разберется с "мертвыми" проектами. "Снимите пластырь - скажите людям напрямую все, как есть, - советует он. Не перекладывайте вину на других, говоря что-то вроде: "Я бы не отменил проекта, но так захотел главный инженер". Это будет означать, что вы не относитесь к команде управленцев". Такие менеджеры могут запросто упустить свой шанс наладить доверительные отношения и контакты со своей командой.
С другой стороны, руководителям необходимо внимательно относиться к чувствам сотрудников после того, как проект потерпел неудачу. "Можно получить целую волну возмущений, ведь в первое время люди не могут рассуждать объективно", - предупреждает Джим Джонсон, председатель The Standish Group, выпускающей ежегодные исследования CHAOS о провалившихся ИТ-проектах. Он рекомендует ИТ-менеджерам подождать пару недель, а потом поговорить с сотрудниками и оценить, почему проект развивался не должным образом. Но не следует выжидать слишком долго, иначе, сотрудники либо уже найдут рациональное объяснение случившемуся, либо вообще забудут, что было не так.
В конце концов, ИТ-руководителям следует помнить, что именно возможность изучить что-то новое и развить новые умения заставляет людей двигаться вперед. Поэтому лучшим средством восстановления для сотрудников, расстроенных из-за "заглохшего" проекта, будет новое содержательное и интересное занятие.
Мудрые менеджеры должны мягко напомнить своим работникам, что будут и другие проекты, и что даже из несостоявшихся проектов можно извлечь много ценных уроков. "Эти проекты должны научить вас адаптироваться, справляться с разочарованием, нехваткой ресурсов и т.д.", - считает Корлесс. Неудача проекта, возможно, и не совсем радостное событие, но она не должна препятствовать профессиональному росту ИТ-сотрудника.
© @Astera
