Кон Кенни - обладает 20-летним опытом консультирования и управления в области технологий и стратегии. До недавнего времени занимал должность ИТ-директора в компании Zerotime Labs. С ним можно связаться оп адресу cfkenney@comcast.net.

Фил Леггьер - профессиональный писатель, специализирующийся на технологиях. Его статьи публиковались в изданиях Upside, Market Makers и Wired. С ним можно связаться оп адресу philguy@prodigy.net.

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

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

Но нет смысла устраивать охоту на ведьм. Суть проблемы в том, что бизнес-пользователи и разработчики по-разному определяют цель ИТ. Слова, возможно, одинаковые, но вкладываемый в них смысл отличается. Подобное непонимание лежит в основе большинства неудач. Согласно известному отчету группы Standish Group за 1994 год "Хаос: рецепт успеха" (CHAOS: A Recipe for Success, www.standishgroup.com/chaos/toc.html), факты печальны: успешными оказываются всего лишь 25% всех ИТ-проектов, при этом достаточно поверхностного анализа, чтобы выяснить причину большинства неудачных проектов - отсутствие или неверно истолкованные требования. (По определению Standish, успешным считается проект, выполненный с соответствии с графиком, в рамках бюджета и предоставляющий всю изначально заявленную функциональность.) В своей книге Competitive Engineering (Addison-Wesley, 2003), эксперт по управлению разработкой ПО Том Гилб показывает, что около 40% ресурсов среднестатистического проекта затрачивается на переделку; а ведь специалисты отрасли прекрасно знают, что по оценками при переходе на каждый последующий этап разработки усилия на устранение ошибки возрастают десятикратно.

Почему не удается договориться

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

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

Этнографический диалог и смешение концепций

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

Антропология изучает поведение человека, оперируя различными данными, в числе которых - этнографическая информация, то есть описание особенностей разных народов. В методике, получившей название этнографического диалога, теории и основные положения создаются не в процессе формулировки и последующей проверки, а путем выяснения причин поведения людей. Задача этнографического диалога - заставить людей "раскрыться" и описать суть происходящего. Качественное описание объясняет сложную ситуацию намного лаконичнее и делает ее более запоминающейся, чем аналитическое представление. А подробное описание реалий бизнеса позволяет разработчикам лучше понять характер, побуждения, отношения и правила в процессе анализа компромиссов или принятия решений. Сначала разработчики используют этнографический диалог для выяснения, что происходит на "передовой линии" бизнес-процессов, и лишь затем переходят к четким количественным методам анализа.

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

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

Черновые вопросы

Эффективный открытый вопрос подталкивает людей к рассказу о себе и своих проблемах. И здесь на помощь приходит так называемая технология "черновых вопросов". Суть ее состоит в том, что команда организует мозговой штурм контекста приложения, задавая вслух такие, казалось бы, очевидные, но очень часто игнорируемые вопросы, как: каковы реальные преимущества и возможные проблемы бизнеса? кто заинтересованные лица? каковы уместные преимущества, риски и меры успеха? После этого команда может переходить к формулировке чернового варианта вопросов, выражающих саму суть приложения и рассчитанных на дополнительные уточнения для получения информации о деталях. Вот примеры черновых вопросов одного ERP-проекта: на чью работу успешное внедрение созданного решения окажет самое сильное влияние? Почему этот процесс так важен для вас с точки зрения бизнеса? Известен ли вам другой проект, который похож на данный?
Разработчики и их бизнес-партнеры, по возможности, должны совместно работать над правильной формулировкой вопросов. Опыт показывает, что на создание чернового варианта наиболее полной версии вопроса иногда уходит половина дня.

Как задавать "правильные" вопросы?

Когда в команде решают, что выбрали лучшие варианты вопросов, выбирается подмножество респондентов для интервью, представляющее репрезентативную выборку из всего множества бизнес-пользователей приложения. По опыту для проекта длительностью 1 год с бюджетом 1 млн. долларов достаточно 12-15 интервью.

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

Вопросы должны быть понятными и ориентироваться на чувства, впечатления, опыт и теорию. Ни опрашиваемый, ни интервьюер не должны заранее знать: первый - вопроса, а второй - ответа. Цель состоит в поощрении спонтанного поведения, поэтому опрашиваемый должен с удовольствием общаться на протяжении примерно часа плюс-минус 15 минут. Во многих командах разрабатывают стандартное введение, описывающее цель и характер интервью, чтобы облегчить начало собеседования и начать с простых открытых вопросов, на которые легко отвечать. Далее интервьюер направляет разговор в нужное для получения фактического материала русло. Важнее всего, чтобы интервьюеры не высказывали собственного мнения или не выражали свою позицию в отношении информации, излагаемой опрашиваемым. Мнение интервьюера очень важно, но только не во время интервью.

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

Контуры будущего приложения

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

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

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

Техника детализации положений

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

В смешанной схеме иногда выявляются новые моменты, например: перевод каждого десятка менеджеров по продажам на рельсы будущей автоматизированной CRM-системы позволит отказаться от должности аналитика и экономить каждый год по 75 тыс. долл.. Команда может сопоставить этот факт с основными положениями, оценить перекрытие между информацией "продавцов" и аналитиков по сбыту и проверить, готовы ли менеджеры по продажам вводить данные о клиентах в CRM-систему. Смешанная схема и первоначальные входные данные могут изменяться по мере проводимого командой сопоставления и создания связей между элементами в процессе создания новых смешанных схем.

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

В поиске точек соприкосновения

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

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

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

Ресурсы

Fauconnier, Gilles, and M. Turner. The Way We Think: Conceptual Blending and the Mind's Hidden Complexities, Basic Books, 2002.
Gilb, Tom. Competitive Engineering: A Handbook for Systems and Software Engineering Management Using Planguage, Addison-Wesley, 2003.
Список ресурсов по смешению и интеграции концепций на сайте Университета штата Мериленд: www.wam.umd.edu/~mturn/WWW/blending.html