Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 12
Текст из файла (страница 12)
Большинство систем создается для решения определенной проблемы. Чтобы правильно понять, в чем состоит проблема, мы будем использовать методы аналэза нрнблем. Однако не каждое приложение разрабатывается для решенин определенной проблемы, некоторые из ннх создаются для того, чтобы воспользоваться предоставляемыми рынком ннзможносншмн, даже если существование проблемы еще не очевидно.
Например, замечательные программные приложения, такие как рйтСйу и Музц оказались нужны тем, кто любит компьютерные игры и умственные упражнения, по-настоящему увлекается моделированием н имитацией. Поэтому, хотя и сложно сказать, какую проблему решали эти приложения — возможно, проблему "недостатка классных вещей, которые можно проделывать с компьютером" нлн " наличия слишком болыпого количества сво. бодного времени у некоторых" — очевидно, что этн продукты представляют реальную ценность для значительного числа пользователей. В некотором смысле проблемы и воэможности — это две стороны одной медали; ваша проблема является моей возможностью.
Все зависит от точки зрения. Но поскольку болынннство систем действительно предназначено для решения существующих проблем. можно упростить оосужденне и, нс вдаваясь в путаницу проблема/возмолоюсть, заняться только проблемной стороной. В конце концов, нам нравится представлять себя в роли "решателей проблем".
Аннлнз нрнблемы — змн процесс одззненнл реальных проблем н энжребннпней наназнвн тели и нредлнзнення решений сатя уднаинмнрения эжнл яоп~ребиопней. бб Часть 1. Анализ проблемы 11ри этом необходимо проанализировать и понять область проблемы и исследовать разнообразные области решений, Как правило, возлюжных решений множество, и нам необходимо найти то, которое наиболее соответствует решаемой проблеме, Чтобы иметь возможность провести анализ проблемы, полезно определить, что же ссюой представляет проблема. По определению Гауса и Вайнберга (Санзе, Ъте(пЬег8, 1989) п/лаулема — зшо )Зазиица жезсдт зкаласмым я еопфняичягмъси.
Это определение достаточно разумно, по крайней мере, оно устранит часто встречающееся среди разработчиков заблуждение, что подлинная проблема заключается в том, что пользователь не понимает, в чем состоит проблема! Согласно данному определению, если пользователь ощущает нечто как проблему, это и есть настоящая проблема, и она достойна внимания. Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Опираясь на приведенное выше определение, наш коллега Элмер Мэгззинер (Е1шег Ма8ах!пег) заметил, что существует множество путей решения проблемы.
Например, изменение желаний или восприятия пользователей может быть наиболее эффективным (в плане затрат) подходом. Это может осуществляться п)тем формирования ожиданий и управления имн, внесения предложений по организации работы или частичному ул)чь шению существующих систем, предложения альтернативных решений, не требующих разработки новой системы, илн проведения дополнительного обучения. 11рактика знает много примеров, когда именно изменение восприятия приводило к наилучшим, наискорейшнм и самым дешевым из возможных решений! 1ьсли мы взялись решать нроблелнл, то на нас возложена обязанность исследовать эти альтернативиыс решения прежде, чем приступать к решению с помощью новой системы.
Однако когда указанные альтернативные действия оказываются не в состоянии заметно )ыеньшить расхоящение между воспринимаемым н желаемым, перед нами встает наиболее сложная и дорогостоящая зада ~а: уменынить разницу между жешсммм и кося(ги иимаеиым путем определения и реализации новых снсяим. Цель анализа проблемы состоит в том, чтобгл добиться лучшего понилиния решаемой проолемы до начала разработки. 1(ак и всегда, начгишть следует с определения цели, Цель анализа проблемы состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов.
1. Достигнуть соглашения об определении проблемы. 2. Выделить основные причины — проблемы, стоягдис за проблемой. 3. Выявить заинтересованных лиц и пользователей. 4. Онрсдслиты раннцу системы ре~яспня, 5. Выявить ограничения, которые необходимо наложить иа решение. Давайте подробно рассмотрим каждый их этих этапоя. Глава 4, Пять этапов анализа проблемы 61 Этап 1. Достижение соглашения об определении проблемы Первый шаг состоит в достижении соглагяепия об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобгл гфосао заансапыфобееиу и выягнншь, всели согллсны с пикой гиктановкои В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клвентов/пользователей. Это обеспе. чнвает дополнительную содержательную основу для понимания реальной проблемы.
Рассматривая с точки зрения клиента эти преимущества, мы также достигаем лучшего понимания их взгляда на проблему в целом. Постановка проблемы Часто бывает полезно записать проблему в стандартной г[юрме (табл. 4.1). Создание подобной таблицы является простым, но действенным средством, чтобы удостовериться в том, что все участники проекта работают вместе пад осуществлением общей цели. Таблица 4Л. Стандартная форма постановки проблемы Элемент Описание [Описзннс проблемы] [Указание лин, на которых окззыазет влияние данная проблема] [Описание воздействия данной проблемы на заинтересованных лни н бизнес-деятельность] [Указание предлагаемого решения) [Список основных предоставляемых решением преимуществ) Проблема воздействует на результатом чего является Выигрыш от пожег состоять в следующем Может показаться, что достижение согласия относительно определения решаемой проблемы — шаг небольшой и малозначащий, и чаще всего так оио и есть.
Но не всегда. Например, один из наших клиентов, производитель оборудования, занялся усовершенствованием своей 1$гг1Т-системы, обсспсчиваюшеуе пересылку счетов и финансовых отчетов между компанией и ес дилераьпь Задачей новой программы было "улучшить средства коммуникации дилеров".
В свете этого команда приготовилась разрабатывать новую масштабную систему. Данный пример достижения соглашения о решаемой проблеме весьма показателен. Предложенное командой определение рспгснын предполагало создание мощной новой системы, предусматривающей улучшенную финансовую отчетность, усовершенствованные формы счетов и отчетов, возможность заказа запчастсн в интерактивном режиме и электронную почту. Помимо этого, команда надаьгась(сели полу штса) обеспечить возможность электронного перевода средств между компанией и дилером. Во время согласования постановки проблемы руководство колшапии имело возможность вносить свои предложения. Точка зрегша руководства оказалась совершенно иной. По его мнению, главная цель новой системы должна была состоять в том, чтобы одешпчижь элекнугоннык) воевод сРегств, копю[зый улучшим двнлгение наянчнык с)пдспп комполки.
После бурной дискуссии стало очевидно, что первостепенной проблемой, котор)чо прн- 62 масть 1. Анализ проблемы звана решить новая система, является электронный перевод средств; а электронная почта и другие средства коммуникации дилеров рассматривались только как "желательные". Нечего и говорить, налицо была значительная переориентация целей новой систе»зы, В новой постановке в качестве решаемой проблемы было указано обеспечение электронны го перевода средств. Эта переориентация также привела к разработке отличной от предложенной ранее системной архитектуры, дополненной средствами обеспечения безопасности, которые соответствуют присущим электронной банковской деятельности рискам.
Этап 2. Выделение основных причин — проблем, стоящих за проблемой Для понимания реальной проблемы и ее причин можно использовать множество методов. Одним из них является мг«юд «вал«за корневых «(гпчк«(гоог сапзе а«а1упз), представляющий собой семантический способ нахождения причин. лежащих в основе рассматриваемой проблемы или ее проявления. Рассмотрим реальный пример. Компания СоодзАге()з, занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных наименований. Решив заняться проблемой недостаточной прибыльности, компания использует рекомендуемую ее программой обеспечения качества методику "качество — во всем" (гога! с(иа1(гу шапаяещепг, Т(~М).
Применив данный подход, компания практически сразу обратила внимание на уягфб ош «есоотзеяктлзил (сон о)'«о«соп/тта«се), который представляет собой стоимость всего, что идет не так, как надо, и приводит к бесполезным затратам. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущеро от несоответствия, компания заподозрила, что наибольший вклад в него вносят "остатки". Следующим шагом должно стать определение того, какие факторы оказывают влияние на величину остатков. Т(1М советует для обнаружения проблем, стоящих за проблемой, использовать диаграмму в форме рыбного скелета (рис.
4.1), В нашем случае компания выявила много источников, вносящих свой вкаад в остатки. Каждый источник указан как одна из "косточек" на диаграмме. Рис. 4.1. Диаеранма в фе(змеймбяого скелета длл отобралсе«ил каР«евзп «Ричия Глава 4. Пять агапов анализа проблемы бб Способ выявления корневых причин зависит от конкретного случая.
Иногда просто яужпо спросить людей, непосредственно занимающихся этим делом, что они считают корневыми причинами. Даже удивительно, сколько людей на самом деле знают о проблемах, стоящих за проблемой, но никто — мы имеем в виду руководство — не находил преж. де времеви снросить их об этом. Итак, снроситгих, а затем снроситеих еце раз, Но если проблема более серьезна, простого опроса сотрудников недостаточно.
Может понадобиться произвести детальное исследование каждой иэ перечисленных проблем и количественно определить вклад каждой в отдельности. Этого можно добиться как пгь средством "мозгового штурма" с участием тех, кто знаком с данной областью, так и с пгь мощью небольшого проекта по сбору данных или, возможно, более строгого научного исследования. В любом случае цель состоит в том, чтобы количественно оценить вероятный вклад каждой корневой причины, Устранение корневых причин Качественные данные свидетельствуют, что многие корневые причины не стоят того, чтобы их устранять. Конечно, инженер в каждом иэ нас захочет устранить все корневые причины па "косточках" диаграммы.
Кажется, что это правильно. Но так ли атос Зачастую — нет. Качественные данные свидетельствуют, что многие корневые причины просто не снюят того, юлобьь их уьтнранлньь, поскольку затраты на их устранение превысят причиняемый про. блемой ущерб. Как же узнать, какие из них устранятьь Ответ: необходимо определить влияние каждой корневой причины. Результат этого исследования можно отобразить в виде Паретодиафаммы, визуально отралпзощей реальных "виновников". Вернемся к нашему примеру. Предположэпг, что в результате сбора данных получилась картина, изображенная на рис. 4.2. Как видно, команда обнаружила, что одна корневая причина — "неправильные заказы на покупку" — является источником половины всех остатков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
