17 октября 2019 г.
«Следовательно, разруха не в клозетах, а в головах». (Профессор Преображенский, «Собачье Сердце»)
В 1995 г. компания The Standish Group опубликовала первые итоги исследования CHAOS Report, посвященного внедрению ИТ-проектов по всему миру. Данные этого отчёта и построенные на них выводы привели ИТ-индустрию в замешательство, а предсказание того, что в недалёком будущем перерасходы бюджетов ИТ-проектов в среднем будут составлять 189%, вызвало шок. Последующие исследования ещё больше его укрепили.
Результаты
Картину регулярных катастроф дополняет портрет среднестатистического ИТ-проекта, который, кстати, мало изменился с 1998 г.
В 52% случаев он не укладывается в запланированный бюджет. 75% проектов были сданы позже оговоренного срока. А в 68% созданных систем функции, заявленные в требованиях, либо «криво» реализованы, либо вообще отсутствуют.
За всеми этими цифрами стоят убытки ИТ-индустрии в сотни миллиардов долларов, штрафы за проваленные проекты и судьбы миллионов людей.
Так, по данным отчета за 2014 г., только в США ежегодно реализуется около 175 тыс. проектов по разработке и внедрению ПО, на которые тратится около 250 млрд долл. При этом исследование 8380 проектов из указанного выше отчета показало, что:
- около 83% из них закончились провалом или спорно;
- только 15,5 % проектов уложились или не превысили бюджет более чем на 20%;
- в 25,2% проектов бюджет был превышен более чем в 2 раза;
- только 13,9 % проектов уложились или не превысили сроки более чем на 20%;
- в 47,8% проектов сроки были превышены более чем в 2 раза;
- только в 7,3% проектов был реализован весь запланированный функционал;
- в 49% проектов функционал был реализован в пределах
25-74%.
«Легче идти вперед, чем в нужном направлении» (Михаил Генин)
У каждого сегмента рынка есть свои критерии оценки успешности, которые, как маяки для корабля, позволяют бизнесу выбрать нужное направление и в соответствии с ним корректировать курс своего развития.
В 1994 г. The Standish Group предложила формулу успешности и для ИТ-проектов c 3 переменными. С тех пор, на протяжении 20 лет, ИТ-проект считался успешным, если он: уложился в согласованные заказчиком и исполнителем срок И не перерасходовал первоначальный бюджет, И в нем были реализованы согласованные с заказчиком требования к характеристикам и функциям системы. Почему я выделила именно эти слова, объясню чуть позже. Пока же стоит отметить, что расшифровка формулы, согласно которой определялся успех ИТ-проекта, во многом объясняет такой высокий процент неудачных внедрений. Ведь если с «неуспешными» все понятно — к ним аналитики относили проекты, которые были выполнены, но так и не введены в эксплуатацию или отменены еще до их завершения, то с «проблемными» все не так просто. В их число попадали проекты, которые были завершены и работали, но были выполнены с перерасходом времени или бюджета или с меньшей, чем было указано в требованиях, функциональностью.
Таким образом, основным недостатком данной методики было то, что она игнорировала факт прямой зависимости времени и бюджета от требований заказчика и от внесения в них изменений. В результате проекты, полностью реализовавшие требования и достигшие результата, который устраивал заказчика, но выполненные даже с небольшим перерасходом времени или бюджета, попадали в разряд проблемных.
Более чем убедительным доказательством несовершенства методики стали итоги проведенного The Standish Group (в 2014 г.) повторного исследования проектов, признанных ранее «успешными». Оказалось, что в результате реализации успешных (согласно методике 1994 г.) проектов, при подготовке которых были плохо проработаны цели заказчика (а требования к проекту записаны формально и не соответствуют реальным потребностям бизнеса), были созданы системы, которые не дали (да и не могли дать) клиенту нужных результатов. Поэтому к моменту проведения повторного исследования эти системы просто перестали существовать. Т.е. заказчики заплатили за то, чем они в результате не смогли пользоваться. А ведь, напомним, эти проекты полностью соответствовали формуле успеха The Standish Group: были завершены в плановый срок, уложились в плановый бюджет и достигли определенных для проекта целей (см. рис. 2).
Вот почему чуть выше и были выделены слова «требования к проекту, согласованные с заказчиком». Т.е. начиная с 1994 г. успешность проекта оценивалась по соответствию не реальным целям бизнеса (с которыми, судя по всему, мало кто мог, да и хотел разбираться), а тому, что исполнитель и клиент договорились записать как «цели».
«Кто не знает, в какую гавань он плывет, для того нет попутного ветра». (Сенека)
Несмотря на то, что критерий «достижение целей бизнеса» не входил в первоначальную формулу, все 20 лет The Standish Group отмечала, что для успеха любого ИТ-проекта в нем должны сойтись 3 взаимозависимых фактора:
- поддержка от высшего руководства компании-заказчика;
- вовлечение пользователей в проект;
- ясные цели бизнеса.
И все эти годы аналитики обращали внимание на то, что успешными будут только те «...проекты, которые поддерживаются высшим руководством заказчика, ясно понимающим цели бизнеса. Это обеспечивает своевременное выявление и вовлечение ключевых сотрудников в процесс создания ИТ-системы и в итоге приводит к ясным и чётким требованиям к функциям и характеристикам ИТ-системы, необходимым для достижения именно этих целей бизнеса».
С этим выводом соглашались и другие исследователи. По их общему мнению, основа успеха проекта — это не время и не бюджет, а вовремя и правильно определенные цели заказчика. Именно они должны стать основополагающими при написании требований к ИТ-проектам: ИТ-проект создаётся и требования к нему формируются ради достижения этих целей.
The Standish Group не могла игнорировать полученные результаты и в 2015 г. предложила ориентироваться на новую формулу успеха, в которую уже вошли 6 переменных: «on Time, on Budget, on Target, on Goal, Value and Satisfaction». Новая формула учитывала необходимость достижения проектами не просто установленных требований, а тех, которые соответствуют целям заказчика. Теперь проект считается успешным, если заказчик не только получает от созданной системы необходимые ценности, но и выражает удовлетворённость организацией и выполнением работ, а также их результатами.
С введением этой формулы картина кризиса стала точнее. Но, увы, не радостнее. При перерасчёте результатов исследований за
Хотя сложно было ожидать другого. Ведь изменить реальное положение дел в ИТ-индустрии можно только изменив подход к работе с проектами, а не введя новые переменные в формулы.
«Бессмысленно продолжать делать то же самое и ждать других результатов». (Альберт Эйнштейн)
Вернемся к тому, о чем 20 лет говорили аналитики. Чтобы проект был успешным, необходимо, чтобы он был поддержан высшим руководством заказчика, в его реализацию были вовлечены реальные пользователи его результатов и были обозначены ясные цели. На первый взгляд, в реализации каждого из этих 3 условий нет ничего сложного. Ведь ИТ-зация бизнеса — это прихоть заказчика, а значит он в первую голову и должен быть заинтересован в соблюдении этих условий. Но если бы все было так просто. Работая над ИТ-проектами, каждый системный интегратор накапливает не только богатый опыт внедрения ИТ-решений, но и понимание проблем клиента, которые их тормозят. И чаще всего эти проблемы не лежат на поверхности, более того, по разным причинам заказчики стараются их замаскировать и спрятать от глаз «внешнего человека», в данном случае — от исполнителя проекта.
Но нет ничего тайного, что не стало бы явным, и рано или поздно, а чаще всего в самый неподходящий момент проблемы проявляются и начинают тормозить процесс внедрения.
И при этом мало кто в ходе реализации проекта задается вопросом: а как именно должен вести себя заказчик, чтобы не мешать реализации, а повысить ее качество. А зря. Ведь это, пожалуй, самый главный вопрос просто потому, что, еще раз повторю, ИТ-проект должен стать отражением бизнес-потребностей заказчика.
«Если у вас в компании бардак, и вы думаете, что внедрение ИТ поможет вам стать более эффективными, то вы очень сильно ошибаетесь. После реализации ИТ-проекта вы получите все тот же бардак, только оцифрованный». (кто-то из великих)
Выявить истинные цели клиента, формализовать их и сформулировать требования к системе, которые затем позволят достичь этих целей, может далеко не каждый бизнес-аналитик, работающий в проекте. Все знают, что с клиентами надо разговаривать на понятном им, а не на «птичьем ИТ-ишном» языке. И кажется, эту аксиому игроки ИТ-рынка уже усвоили. Но, как оказалось, проблема взаимопонимания между людьми вообще, и на нашем рынке в частности гораздо глубже. Она берет начало в уверенности большинства из нас в том, что «я» от рождения обладаю даром ясно объяснять и понимать других людей. И это при том, что порой мы и себя-то не всегда понимаем, что уж говорить о понимании других...
Давно доказано, что люди исходно имеют когнитивные ограничения, которые исключают полное взаимопонимание между индивидуумами. У каждого человека есть своё представление об окружающем мире, которое формируется в процессе взаимодействия его уникальной психики с окружением. Одно и то же событие они воспринимают по-разному. В каждом конкретном случае интерпретация произошедшего разными людьми зависит от многих факторов: физического и психического состояния в момент события, от багажа знаний, культурного бэкграунда, предыдущего жизненного опыта, убеждений и т.д.
Кроме того, взаимоотношения человека с окружающим миром находятся под контролем эмоционального интеллекта, который стоит на страже его безопасности. И готовность человека к общению во многом зависит от реакций именно этой составляющей его «я», так как по скорости реакции эмоции всегда опережают рациональное мышление. Поэтому реальный контакт между людьми начинается намного раньше, чем произнесено первое слово.
Не стоит забывать и о том, что общение по необходимости сильно отличается от общения для удовольствия. Для человека нет ничего хуже навязанного общения. Поэтому и реакции при «обязательных» контактах отличаются от его реакций в условиях свободной дружеской беседы.
Во время переговоров часто забывают, что используемые нами слова часто абстрактны. За «хорошо», «плохо», «красиво» стоят разные представления людей о доброте, зле и красоте. До тех пор, пока не будут определены точные значения, фразы, построенные на этих словах, не несут никакого смысла. Но несмотря на это, люди в своей речи склонны пропускать определение «что такое хорошо и что такое плохо», так как считают, что всем всё и так понятно.
Ну и, конечно, стоит всегда делать поправку на то, что цели конкретного человека в конкретных обстоятельствах могут как совпадать с целями других членов команды, так и противоречить им. Например, для одних сотрудников компании автоматизация, задуманная боссами — это покушение на привычный образ жизни, потеря власти или даже работы. Другим она безразлична. А третьи понимают, что она может принести серьёзные карьерные выгоды и иные бонусы. Поэтому конфликты интересов сопровождают любую совместную деятельность.
«Слово психотерапевт почему-то пугает людей, поэтому нас лучше называть „менеджер по связям с реальностью“» (анекдот)
Вы спросите, к чему весь этот экскурс в психологию. К тому, что психологически безграмотный бизнес-аналитик, работающий в ИТ-проекте, не только не помогает реализации проекта, но и может разрушить его, причем в самом начале реализации.
Современная роль бизнес-аналитика в ИТ-проектах весьма схожа с ролью профессионального психотерапевта, выслушивающего в одно ухо жалобы пациентов на проблемы со здоровьем и на врачей, а в другое — жалобы коллег по больнице на жизнь и проблемы с пациентами.
Как утверждается в одной из статей, посвященной роли современного бизнес-аналитика: «Извлечение неявных ожиданий из голов стейкхолдеров требует навыков, которыми, как правило, обладают психологи, а именно: внимательное и полное выявление, сопереживание, понимание и выслушивание. Бизнес-аналитики, по крайней мере, должны быть немного психологами в своём деле, чтобы делать свою работу успешно».
Таким образом, современная ИТ-индустрия остро нуждается в профессиональных бизнес-аналитиках, которые еще и мастерски владеют инструментами психологии. По данным исследования «Всемирного банка», дефицит социальных и поведенческих компетенций среди сотрудников — один из самых серьёзных факторов, ограничивающих развитие и рост этих компаний.
А анализ, проведенный The Standish Group, позволяет сделать вывод о прямой связи между недостатком подобных компетенций у исполнительного руководства со стороны заказчиков и неудачами в реализации проектов.
Таким образом, в ближайшем будущем конкурентные преимущества будут у тех компаний, кто раньше начнёт вкладываться в психологическую подготовку кадров. Уже сегодня это становится необходимым условием успеха проектов и серьёзным конкурентным преимуществом как самого специалиста, так и компании, в которой он работает.
«Это только в дурацких романах пишут, будто дух сломить нельзя... Почти всякое сопротивление можно сломить, нужно только время и подходящие инструменты». (Эрих Мария Ремарк. «Искра жизни»)
Ну и, конечно же, говоря о человеческом факторе при реализации ИТ-проектов, нельзя не затронуть тему сопротивления сотрудников изменениям, которые последуют вслед за внедрением новых систем. Долгое время считалось, что проект будет успешным, если тщательно расписать все задачи и шаги по их реализации. Однако практически во всех неудачных проектах подготовительная работа была проведена тщательнейшим образом. А, значит, главная причина проблем — НЕ в плохом планировании.
Подавляющее большинство проектов проваливаются, так как исполнители недооценивают сопротивление изменениям. То есть то, что при разборе полетов называют «человеческим фактором».
Особенность ИТ-проектов в том, что в ходе их реализации возникает некая нематериальная идея: создается новый продукт, выстраивается уникальный бизнес-процесс. Но самое главное, что до завершения проекта точные параметры конечного продукта никому не известны. И это создает высокую степень неопределенности.
Вторая особенность в том, что ИТ-проекты всегда влекут за собой изменение способа, порядка или условий работы людей, а, значит, приводят к необходимости проведения организационных изменений.
И именно эти 2 фактора (высокая неопределенность и неизбежность организационных изменений) и становятся основой для формирования сопротивления изменениям. Таким образом, сопротивление проекту возникает всегда: в любом ИТ-проекте, в любой компании. А если учесть тот факт, что современные ИТ-проекты затрагивают большое число сотрудников компании, то и сила сопротивления оказывается очень большой, и для ее преодоления нужно приложить много усилий.
Начиная любой проект, необходимо помнить, что:
- в основе сопротивления изменениям лежит психология, а не злой умысел, поэтому сопротивление неизбежно;
- нельзя приказать жить по-новому; преодолеть сопротивление можно, лишь создав правильную мотивацию для быстрого прохождения этапов кривой изменений.
Поэтому, чтобы проект не провалился, на момент начала реальных организационных изменений у него уже должны быть сторонники, которые послужат примером для других сотрудников компании, что позволит снизить общее сопротивление коллектива. Сторонники — это не только команда внедрения из ИТ-подразделения заказчика. Круг сторонников должен быть шире, в него должны входить представители тех отделов, которые реально «пострадают» от реализации проекта. И заниматься формированием этого круга нужно на самом старте проекта.
Идея создания круга сторонников достаточно проста. Ключевые сотрудники должны прожить основные негативные последствия изменений заранее, еще в ходе подготовки проекта, на «бумаге». Тогда в активной фазе проекта, когда изменения начнут происходить на самом деле, они будут более подготовленными и вместо сопротивления дадут дополнительную поддержку.
Резкий провал (см. рис. 3) после объявления об изменениях вызван низкой информированностью о том, что произойдет после внедрения проекта с каждым сотрудником. Это приводит к рефлексии и снижению производительности. Если же в момент старта реальных изменений человек уже подготовлен и имеет какое-то представление о будущем, которое его ждет, если понимает свою роль в этом процессе, то он начнет приспосабливаться к изменениям, превратившись из балласта в паровоз процесса.
В процессе подготовки проекта каждый участник рабочей группы, занимающейся его подготовкой, моделирует и примеряет на себя грядущие изменения: отрицает предложения коллег, держится за собственный опыт, спорит и тем самым переживает все стадии процесса принятия изменений еще до того, как эти изменения начали происходить. Поэтому к моменту начала реальных преобразований он уже готов к негативным реакциям других менее информированных коллег. Ведь он сам их уже пережил и нашел для себя аргументы в пользу изменений. И такой, казалось бы, незначительный шаг как расширение рабочей группы за счет ключевых сотрудников, «страдающих» от ИТ-изации подразделений, может позволить вам в значительной степени снизить сопротивление изменениям.
Источник: Светлана Белова, crn.ru
