Процедура формирования требований - буквально, определение функций и возможностей, которые следует включить в программное обеспечение - нередко разрушает проект.
Процедура формирования требований — буквально, определение функций и возможностей, которые следует включить в программное обеспечение — нередко разрушает проект. Причем явные признаки бедствия могут проявиться в тот момент, когда спасти положение почти невозможно. Могут ли руководители ИТ-служб вовремя взять ситуацию в свои руки?
Перед Хью Каммингом стояла крайне непростая задача. Перечень расхождений между возможностями его еще не внедренного приложения управления call-центром крупной европейской компании и списком требований, составленным четырьмя десятками представителей бизнес-подразделений, жаждущих получить в свое распоряжение новое ПО, занимал 3 тыс. страниц. Назревала реальная угроза, что и без того уже просроченный проект по консолидации call-центра будет введен в действие с опозданием на 4-5 лет. «В тот момент я был уверен, что у проекта нет ни малейшего шанса на успех», — вспоминает Камминг, выполняющий сегодня обязанности директора ИТ-службы компании ADP Employer Services Canada.
Любой руководитель ИТ-службы знает, что список требований порождает определенные сложности, но мало кто представляет, насколько серьезными могут быть последствия. Аналитики утверждают, что до 71 % неудач при разработке программного обеспечения связано именно с плохой организацией управления требованиями. Это основная причина провала проектов, порождающая несоизмеримо большую головную боль, нежели неверно выбранная технология, несоблюдение сроков и промахи при управлении изменениями. Хотя директора ИТ-служб не всегда напрямую отвечают за управление требованиями, но ответственность за конечный результат уж точно лежит на их плечах. Невыполнение требований приводит к задержкам при реализации проекта, к созданию приложений, не оправдывающих возлагаемые на них надежды, наконец, к внедрению ПО, которое не способно обеспечить корректного выполнения операций и подвергает опасности весь бизнес.
В этой ситуации директор ИТ-службы действительно рискует лишиться своей должности.
|
| Хью Камминг, выполняющий сегодня обязанности директора ИТ-службы компании ADP Employer Services Canada. |
При плохом управлении требованиями проект может пойти ко дну как на начальном этапе, так и в ходе внедрения. Выбрав неправильную дорогу, вы придете к неверной цели. Но даже при движении вперед в нужном направлении неуклюжее управление изменениями в середине пути нередко приводит к столь же фатальным результатам. Отсутствие интеграции требований с тестовыми процедурами отбрасывает вас далеко назад, а ведь многие недостатки можно было выявить гораздо раньше и устранить их с гораздо меньшими затратами.
Именно на плечах директора ИТ-службы лежит задача организации процесса управления требованиями в целом, и он просто обязан использовать все свое влияние, чтобы заручиться поддержкой как представителей бизнеса, так и разработчиков. Директор ИТ-службы должен выстроить организационную структуру, необходимую для удержания переменчивых процессов управления требованиями в правильном русле.
Решить эти вопросы непросто. Представители бизнес-подразделений зачастую сами не знают точно, чего хотят, вдобавок не в состоянии определить приоритеты и описать свои пожелания в терминах, обеспечивающих их однозначный перевод на язык кода. В свою очередь аналитики, архитекторы и программисты ИТ-службы слишком часто пытаются угодить клиентам, забывая о необходимости формировать реалистичные ожидания от проекта. Они не всегда используют все возможные средства, способные обеспечить соответствие проекта объективным потребностям сотрудников компании. А иногда даже не удосуживаются убедиться в том, что какие-то вопросы обсуждаются с нужными людьми.
Уже притчей во языцех стало постоянное нарушение традиционных правил определения требований. Конечно, многие руководители ИТ-служб делают все от них зависящее, чтобы исправить ситуацию. Все как один полагают, что процессу должна отводиться ключевая роль. Но какому именно процессу? Тут-то у каждого обнаруживается своя точка зрения. Одни предпочитают просто ужесточать правила, которые уже давно следовало ужесточить. Другие полностью переписывают их. А некоторые вообще отказываются от старого свода правил, отдавая предпочтение подходу, ориентированному на бизнес-процессы, или же прибегая к итерационному методу построения приложений, отвергающему долгую процедуру составления документов с описанием требований. Но как бы то ни было, все признают необходимость выбрать какой-то способ формализации требований и в дальнейшем придерживаться его.
Сформулировать сами требования не так-то легко. Впрочем, эти действия всегда были сопряжены с определенными сложностями. Верно одно: приняв ряд грамотных решений, вы сможете создать процедуру описания требований, которая в дальнейшем принесет немало пользы и уменьшит вероятность того, что следующий ваш проект пополнит списки печальной статистики.
Сорок — это много
Камминг решил покончить со своими ночными кошмарами радикальным хирургическим способом. Сначала при поддержке генерального директора ADP он уменьшил масштабы проекта консолидации, исключив из него существующие процессы, которые продолжали работать, как есть. Встраивать их в новое приложение не было необходимости. Кроме того, он ограничил группу из сорока заинтересованных лиц пятью сотрудниками, которые по-прежнему активно участвовали в реализации проекта. Остальным отводилась пассивная роль. Они следили за планом внедрения и спецификациями функций, но были лишены права вносить собственные предложения о добавлении тех или иных возможностей. Камминг же обсуждал положение дел с оставшимися пятью сотрудниками, выясняя у них, действительно ли та или иная функция должна быть реализована в обязательном порядке, или же ее включение носит рекомендательный характер. Спустя два месяца после ужесточения правил новый список требований содержал менее 10 % от первоначального объема, а с начала внедрения в проект пришлось внести лишь одно серьезное изменение, после чего система была развернута в 12 различных местах.
По словам Камминга, проблема обычно заключается в том, что ИТ-служба в процессе формирования требований находится не на ведущих ролях, а занимает соглашательскую позицию, предпочитая отдать все на откуп представителям основного бизнеса и прислушиваться к их запросам. Но у каждой медали есть оборотная сторона: в этом случае список требований разрастается до таких размеров, что становится неуправляемым и невыполнимым. Сотрудникам ИТ-службы необходимо вырабатывать в себе умение отказывать с улыбкой на лице. «Идеальный ответ неуместным просителям: ?Возможно, но не сейчас?», — рекомендует Камминг. Перефразируя афоризм Даниэля Варе, можно сказать, что управление требованиями, подобно дипломатии, являет собой искусство каждому предоставить возможность идти своим путем.
Когда Камминг сократил армию активных участников процесса с сорока до пяти человек, возник интересный вопрос: кто же все-таки должен оставаться на ведущих ролях? Люди опасались, что лишатся функций, которые считали жизненно важными для своих бизнес-подразделений. Чтобы успокоить их, Камминг вместе с членами вновь сформированного ядра подготовил обобщенный перечень наиболее важных функций, дающий наглядное представление о том, как проект будет выглядеть в своем окончательном виде. Все заинтересованные лица, даже не собиравшиеся глубоко вдаваться в детали, смогли увидеть, какие преимущества получат от внедрения проекта.
Многие пассивные участники начали играть в проекте более активную роль с внедрением системы call-центра. Когда система переместилась в подразделения, на них была возложена прямая ответственность за финансирование всех изменений, которые требовалось внести в приложение для более эффективной работы подразделения. Все названные события вызывали повышенное внимание со стороны высшего руководства, явно заинтересованного в успешной реализации проекта. Камминг почувствовал, что настала пора выяснить, кто в компании обладает реальной властью (независимо от положения в организационной иерархии), а заодно и выявить сотрудников, которые имеют хорошую техническую подготовку и могут внести реальный вклад в дело формирования требований. «Мой опыт позволяет утверждать, что список людей, вносящих основную лепту в формирование перечня требований, должен быть весьма ограниченным», — подытоживает Камминг.
Правила распределения ролей
Устав от неразберихи, сопровождавшей мероприятия по определению требований, Джесси Хэнспал, директор по технологиям разработки компании Bank of Montreal Financial Group, решил создать свой собственный процесс, который объединил бы существующие технологии описания требований с процедурой гарантии качества. После пяти лет работы в этом направлении руководство банка признало, что процесс определения требований уже на достаточно высоком уровне абстракции и вполне применим к реализации любого проекта и решению любой задачи. Итогом долгого рассмотрения было решение распределить ответственность и роли, чтобы все заинтересованные лица имели возможность высказаться.
«Важно усадить всех участников процесса за стол, для того чтобы получить перечень требований из первых уст, — отметил Хэнспал. — Определив роли заинтересованных лиц, вы сможете составить себе более точную картину. Применительно к нынешнему проекту нам понадобятся, естественно, исполнители ролей конечных пользователей, а также роли администратора приложений, не говоря уже о ролях, связанных с безопасностью и выполнением требований нормативных актов».
Хэнспал указал, что в прошлом сотрудники ИТ-службы тратили на определение требований от 10 % до 20 % своего рабочего времени. «Мы хорошо усвоили, что как только процесс определен, на него нужно получить сертификат ISO 9000, — отметил он. — Наличие сертификата помогает людям понять, что от них требуется. Кроме того, у банка появляется возможность оценить эффективность процесса и улучшить его. Новый процесс принес результаты. К примеру, с момента введения новых правил количество программных ошибок, связанных с управлением требованиями, сократилось на 50 %».
Руководство Банка Монреаля хотело убедиться в том, что аналитики обладают достаточным уровнем подготовки, позволяющим справиться с новым процессом. К сожалению, хотя поиск внешних органов сертификации для управления проектами (Project Management Institute) и функционального тестирования (Quality Assurance Institute) не вызвал никаких затруднений, оказалось, что аналогичной структуры для бизнес-анализа просто не существует.
Поэтому банку пришлось создавать свою собственную. По словам Хэнспала, сегодня организация International Institute of Business Analysis насчитывает уже 800 членов в различных странах мира, и любая компания может направить своих аналитиков для изучения подхода, использовавшегося Банком Монреаля.
Повышение гибкости
Управление требованиями по-прежнему вызывает у компаний немало затруднений. Некоторые специалисты предлагают очередную панацею от этих бед. Они полагают, что необходимо придать процессу больше динамичности.
Директор ИТ-службы компании Capital One Грегор Байлар совсем недавно влился в ряды сторонников философии гибкой разработки (agile development), выпадающей из общего течения. Поклонники гибкой разработки утверждают, что старомодные процедуры управления требованиями слишком жесткие. Они воздвигают барьеры между пользователями и разработчиками и, мало соответствуя постоянно меняющейся природе программного обеспечения и бизнеса, в конечном счете, обречены на провал. По их мнению, разработчикам и пользователям следует сесть рядом и дружно приступить к написанию кода, время от времени прерываясь, чтобы оценить достигнутые результаты и внести необходимые коррективы на основе замечаний пользователей. Никаких громоздких документов с описанием требований составлять не нужно.
|
| Директор ИТ-службы компании Capital One Грегор Байлар |
«Надо не совершенствовать процедуры, а получать выигрыш от проекта», — подчеркнул Байлар. Опробовав новую концепцию в 2004 году, Байлар приступил к формированию сверхмалых, связанных друг с другом групп, составляющих основу метода гибкой разработки. Динамичные команды в Capital One обычно включают трех представителей бизнес-подразделений, двух операционистов и пять-семь сотрудников ИТ-службы, в том числе специалиста, поддерживающего контакты с бизнес-подразделениями (обычно он выступает в роли переводчика с языка бизнеса на язык ИТ), плюс менеджер проекта. Также присутствует, по крайней мере, один из 80 разработчиков, официально отправленных Байларом на курсы обучения динамичной технологии. По мере необходимости архитекторы и специалисты по безопасности тоже занимаются повышением своего уровня квалификации. В каждой из групп есть свой куратор гибкого подхода (Байлар пригласил для этой цели 20 человек), который следит за ходом работ, дает советы и оказывает прочую поддержку. Члены команд собираются в специально предназначенном для этих целей помещении. Первоначальные требования ограничены перечнем целей проекта, набором карточек с описанием конкретных потребностей и моделями или прототипами для получения справочной информации. Группы работают над проектом в непосредственной близости друг от друга. Реализация проекта регулярно приостанавливается (обычно три-четыре раза в течение типичного цикла разработки, состоящего из девяти недель), чтобы оценить результаты и определить, нужно ли вносить изменения. Крупные проекты разбиваются на более мелкие задачи. Каждая из них поручается определенной динамичной группе — этот метод в кругах сторонников гибкой разработки называют «роением» («swarming») — в то время как общий прогресс контролируется менеджером проекта.
В ходе тестирования эффективности системы Байлар брал несколько находящихся в разработке проектов и в середине процесса их реализации переключался со старой последовательной методики в стиле «водопада» к методу «коротких циклов» («scrum») — технологии гибкого проектирования. Последняя предполагает формирование из числа разработчиков и пользователей небольших, гибких групп и разбиение всего проекта на череду 30-дневных отрезков («sprints»). Каждый из таких отрезков начинается с совещания, посвященного планированию, и заканчивается подведением итогов тестирования перед стартом очередного отрезка.
Байлар сравнил результаты, достигнутые с помощью двух различных методов, и остался весьма доволен. Благодаря использованию методики гибкого проектирования обычные сроки разработки удалось сократить в среднем на 30-40 % (в некоторых случаях экономия времени достигала и 50 %) и одновременно улучшить качество конечного продукта. Правда, пришлось признать, что у гибкой разработки имеются и свои ограничения.
«Есть масса задач, для решения которых этот метод использовать нецелесообразно, — указал Байлар. — Он отлично подходит в тех ситуациях, когда требования неоднозначны, а приоритеты расплывчаты либо вы вынуждены действовать в рамках трех ограничений, именуемых ?быстрее, дешевле и лучше?, и не можете позволить себе отказаться ни от одного из этих пунктов. Что касается очень крупных проектов или таких, где превалируют четкие и упорядоченные требования, то здесь, по-видимому, все-таки лучше применять традиционные подходы».
Каждой строке кода по бизнес-процессу
У Роберта Шермана своя точка зрения. Руководителя направления стратегических методов ИТ-службы компании Procter & Gamble Pharmaceuticals нельзя назвать страстным поклонником традиционных подходов к определению требований. Последние он считает лишь одной из нитей в гобелене, вобравшем в себя все, начиная от бизнес-процессов и заканчивая готовым программным приложением. И пока руководители ИТ-служб не осознают важность этого переплетения, бесчисленные проекты будут по-прежнему терпеть крах. Так же как и Каммингу, в конце 1990-х годов Шерману пришлось на собственной шкуре испытать все особенности процесса управления требованиями. В то время он принимал участие в реализации проекта стандартизации функционирования 150 фабрик P&G на базе единой информационной системы управления. Вместе с девятью другими экспертами Шерман сопоставлял 70-страничные спецификации поставщика с 200-страничным документом, в котором определялись требования, сформулированные специалистами P&G. Эксперты и представители поставщика пришли к единодушному заключению, что документ содержит все необходимое для успешной реализации проекта. Он был краток. Он был полон. «Но он-то и утянул нас в пропасть», — вспоминает Шерман.
Столкнувшись с трудностями, он поначалу не мог понять, что же сделано неправильно. Почему казавшиеся идеальными спецификации так и не превратились в эффективное приложение? Шерман специально пригласил консультанта, который на протяжении двух месяцев сравнивал каждое из требований с тезисом, соответствовавшим ему в спецификациях. Выяснилось, что 30 % компонентов доставлялось не по адресу. Теперь Шерману стало ясно, что осечка вызвана чрезмерной зависимостью от проведенного членами команды сопоставления. Поставщик искал общие шаблоны, которые можно было бы дублировать, уменьшая тем самым сложность кода. Эксперты же оценивали спецификации достаточно поверхностно, исходя из того, что шаблоны точно соответствуют требованиям. Но это было не так. Причина неудач, как впоследствии понял Шерман, заключалась в том, что участники процесса «вышли за рамки своей способности» разобраться в очень сложной ситуации. Использовавшиеся инструментальные средства управления также не позволяли установить четкие связи между отдельными компонентами и поддерживаемыми ими бизнес-процессами, те связи, которые позволили бы распознать тонкие отличия. Совокупность обстоятельств привела к тому, что успешный проект в итоге стал провальным.
|
| Роберт Шерман, руководитель направления стратегических методов ИТ-службы компании Procter & Gamble Pharmaceuticals |
Срывы, обусловленные неспособностью производителей программного обеспечения управления требованиями выявлять подобные нарушения связей, лежат в основе многих неудачных проектов. Принимая во внимание этот факт, Шерман решил создать собственную схему и набор инструментальных средств, к числу которых сейчас относится ПО Visio и Telelogic Doors. Исходная посылка очень проста: обеспечение контроля на различных этапах. Идея заключалась в том, чтобы иметь возможность взять любую часть кода и быстро вернуть ее назад, к процедуре разработки, которую, в свою очередь, сопоставить с требованиями, а затем, не останавливаясь на этом этапе, спроецировать все на затронутые бизнес-процессы для лучшего понимания влияния приложений на бизнес и выявления скрытых заинтересованных лиц.
Реализация этих планов заняла пять лет и потребовала от сотрудников ИТ-службы энциклопедических знаний бизнес-процессов, но полученные результаты того стоили. Используя в качестве тестовой платформы инструментальные средства управления жизненным циклом сложного фармацевтического проекта, Шерман сумел создать приложение, потратив на него всего четверть выделенных средств. При этом число ожидаемых дефектов оказалось на порядок меньше количества ошибок, которые пришлось бы устранять в случае передачи разработки внешнему исполнителю. Кроме того, он помог другой группе в P&G применить эту технологию для спасения проекта построения системы ERP, находившегося под угрозой срыва из-за нескончаемой процедуры определения требований. Перейдя в середине реализации проекта на новую схему, разработчики вновь получили контроль над ходом его исполнения, и теперь, судя по всему, их начинания должны завершиться успешно.
Схема P&G породила и массу побочных преимуществ. К примеру, подход, названный «сценариями инициатив», помог сотрудникам ИТ-службы выявлять потенциальных заинтересованных лиц в масштабе всей компании и заручаться их поддержкой еще до начала реализации проекта. Поскольку каждое требование связано с бизнес-процессом, заинтересованные лица из числа представителей бизнес-подразделений, разработчики, архитекторы и аналитики имеют возможность проследить весь путь проекта в организации и выделить группы, на которые новое приложение окажет непосредственное влияние, даже если их члены и не относятся к конечным пользователям. В качестве примера Шерман привел приложение Electronic Lab Notebooking (ELN) — инструментальное средство сбора цифровых данных для исследователей, которое в P&G ранее внедрить не удалось. При попытках обосновать целесообразность и провести внедрение системы ELN анализ требований ограничивался сферой лабораторных испытаний и группой научных сотрудников, использовавших в своей работе ноутбуки. Однако Шерман сумел продемонстрировать последствия «эффекта домино» и показать, какое влияние информация, размещенная на ноутбуках, оказывает на проведение компанией приобретений, на отток капитала, на регистрацию патентов и т. д.
В результате ИТ-группа смогла найти внутри организации дополнительных спонсоров и проектом охвачено уже 4 тыс. пользователей. «Если у вас определены отношения с рабочими процессами, и вам понятно, как формируются обратные связи с ролями, можно получить досрочное разрешение на реализацию проекта или же ликвидировать его, не сумев заручиться поддержкой спонсоров», — отметил Шерман.
Новая схема оказывает существенное влияние и на соблюдение требований нормативных актов. Чрезмерные ограничения негативно отражаются на проектах в фармацевтической отрасли. Слишком вольная интерпретация законодательства может повлечь за собой юридические осложнения. Ранее методологии определения требований в компании базировались на инстинктивных поисках нужного баланса. Теперь же, по словам Шермана, эксперты могут проследить выполнение требований на всем пути от бизнес-процессов к окончательному коду, сделав выводы относительно соблюдения предписаний нормативных актов. При этом графический формат схемы и стандартизированная структура предложений позволяет фактически каждому проследить весь маршрут. Таким образом, пользователям и разработчикам легче определить приоритеты требований, исходя из их влияния на бизнес-процессы.
Впрочем, даже и при таком раскладе для успешного использования схемы необходимо соблюдать некоторые правила. Проекты необходимо разбивать на части. Более сложные приложения можно создавать, объединяя эти компоненты, однако Шерман убежден, что вывод документации за определенные рамки ведет лишь к увеличению ее объема и дальнейшему повышению сложности, но никак не к ускорению реализации проекта.
Перемены в сознании
Практика показывают, что процессы определения требований должны меняться, и немалую ответственность необходимо взять на себя руководителям ИТ-служб. Оперативно воссоздать разрушенную процедуру непросто, поэтому действовать нужно незамедлительно. «Сегодня выживание во многом зависит от умения быстро изменять правила игры. Во всяком случае, в сфере ИТ это именно так, — утверждает Шерман. — А для того чтобы изменить правила разработки, сотрудникам ИТ-службы необходимо понимать взаимные связи между требованиями и процессами. Отсутствие такого понимания может иметь катастрофические последствия. Руководитель, ничего не предпринимающий для изменения правил игры, вполне заслуживает того, чтобы его обязанности передали кому-нибудь другому».
Ограждения для хорошего процесса
«Инструментальные средства никогда не устраняли всех трудностей, связанных с проектированием программного обеспечения», — заметил архитектор корпоративных систем компании Kaiser Permanente Ричард Шенно. Однако в деле управления процессом формирования требований эти средства способны оказать определенную помощь при условии, что хорошие процедуры уже существуют.
Независимо от того, оформляете ли вы подписку на услуги Rational Unified Process, являетесь полноправным владельцем полного пакета приложений Rational или же просто формируете свой собственный набор инструментов на основе предложений поставщиков рангом поменьше (например, Borland или iRise), в любом случае инструментальные средства выступают в качестве опор и ограждений, помогающих направить процедуру формирования требований в нужное русло. Приведем ряд примеров:
- Инструмент Framework for Integrated Test (FIT), разработанный Уордом Каннингемом (он прославился изобретением «Википедии» — энциклопедии, редактируемой Internet-сообществом), представляет собой платформу, предполагающую запись требований в виде тестов. Требование считается выполненным, если тест успешно пройден. ПО FitNesse, снабжающее методологию FIT wiki-подобным интерфейсом, позволяет бизнес-пользователям (а точнее, бизнес-аналитикам) вводить требования в электронную таблицу, которая автоматически формирует условия испытаний для последующего проведения тестирования.
- Sofea?s Prophesy (используется сотрудниками Банка Монреаля). Позволяет клиентам и бизнес-аналитикам проводить имитационное моделирование и тестирование до написания кода.
- SteelTrace Catalyze (применяется в компании ADP). Инструментальное средство управления требованиями, с помощью которого они делятся на функциональные и нефункциональные (качественные), создаются графические последовательности требований и генерируется тестовая документация.
- Telelogic Doors (используется специалистами Банка Монреаля и Procter & Gamble). Интегрировано с программным обеспечением TestDirector компании Mercury Interactive для проведения автоматического тестирования.
- iRise Studio. Помогает компаниям создавать разнообразные прототипы приложений, позволяя если и не сформировать функциональные тесты, то получать визуальное подтверждение, что требования точно смоделированы. «У вас будет все необходимое для перехода к этапу тестирования за исключением имитации, и вы сможете выявить неверно сформулированные требования», — отметил вице-президент компании Suntrust (одного из клиентов iRise) по электронным банковским услугам Дэвид Никс.
- Borland CaliberRM. Упрощает процесс моделирования требований.
«Эти продукты способны упростить управление требованиями, но в первую очередь необходимо сосредоточиться на процедурах, — подчеркнул Шенно. — Если процесс у вас отлично организован, все то же самое можно проделать с помощью карандаша и блокнота».
CHRISTOPHER LINDQUIST. Fixing the Requirements Mess. CIO MAGAZINE. NOVEMBER 15, 2005