Analyze IT
#03 Ноябрь 2010
Журнал об анализе в IT
ТЕМА НОМЕРА
Выявление требований Андрей Вербицкий
Анализ. Основы и философия Даниэль Новичков
Веб-доступность. Требования, которые не нужно анализировать. Часть 1 Александр Юняев
www.analyzeit-journal.ru
Выявление требований. Интервьюирование Марина Середа
Анализ документации
1
Содержание 5
Вводное слово
6
О журнале
7
Авторы
ШКОЛА АНАЛИЗА 8
Анализ. Основы и философия Андрей Вербицкий Когда произносится слово «аналитик», ассоциации сразу отсылают нас или в сторону экономики (финансов), или в сторону информационных технологий (ИТ) – в те две области, где это слово упоминается наиболее часто. Однако, несмотря на то, что сами по себе эти области достаточно молоды, профессия аналитика, как один из видов человеческой деятельности, существовала задолго до того, как аналитик стал именоваться так официально.
РАБОТА 12
Вопросы работодателя Modernanalyst.com | Перевод: Анастасия Шварц В настоящий момент многие компании от привычного разговора с кандидатом о его успехах и будущих целях переходят к использованию в ходе собеседования нестандартных вопросов и логических задач. Целью является выяснение того, как кандидат будет действовать в реальных рабочих ситуациях, и насколько успешно будет справляться с задачами в своей профессиональной области.
Analyze IT Осень 2010&
2/36
Содержание
ТЕМА НОМЕРА 15
Выявление требований. Интервьюирование Александр Юняев Интервьюирование по праву является одним из самых важных, понятных и распространенных методов выявления требований, который можно использовать практически в любой ситуации. Это относительно универсальный и простой метод, позволяющий глубоко вникнуть в потребности Заказчика.
23
Анализ документации Марина Середа Документы являются для аналитика одним из основных источников информации на этапе сбора требований. В проектах, где Представители Заказчика стремятся минимизировать свое общение с аналитиками, документы оказываются практически единственным источником требований. Поэтому умение с ними работать приобретает критическое значение.
СТАНДАРТЫ И МЕТОДОЛОГИИ 29
Веб-доступность, требования, которые не надо анализировать. Даниэль Новичков Веб-доступность (от англ. web accessibility) — это свойство веб-сайта быть использованным как можно большим количеством разных пользователей. Веб-доступность может рассматриваться, как «возможность использовать» и получать результаты от использования сайта или веб-приложения.
АНАЛИТИКИ ШУТЯТ 35
Анекдоты в тему
36
Подписка и написание статей Analyze IT Осень 2010&
3/36
Сообщество системных аналитиков
Между тем, что я думаю, тем, что я хочу сказать, тем, что я, как мне кажется, говорю, тем, что вы хотите услышать, тем, что, как вам кажется, вы слышите, тем, что вы слышите, тем, что вы хотите понять, тем, что вы понимаете, стоит десять вариантов возникновения непонимания. Но все-таки давайте попробуем. Бернард Вербер Дорогие читатели! Мы рады вновь приветствовать Вас на страницах нашего журнала. С момента выпуска последнего номера прошло уже больше года. Это очень долгий срок, но мы надеемся, что за это время журнал стал только интереснее, и что Вы с удовольствием потратите немного времени на прочтение нового выпуска – выпуска №3. В этот раз мы решили затронуть тему выявления требований – этапа, с которого в большинстве случаев начинается работа аналитика на проекте и который является одним из самых сложных и самых важных этапов, оказывающим непосредственное влияние на дальнейший ход всего проекта. На страницах этого номера Вы найдете некоторые советы и рекомендации по выявлению требований. Надеемся, что они помогут Вам выполнить свою работу более качественно и в более короткие сроки, что в конечном итоге позволит изменить в лучшую сторону статистику успешности ИТ проектов, собираемую Standish Group :-). Что касается будущего журнала, то мы рады сообщить Вам, что за этот год наш редакторский коллектив увеличился. Надеемся, что количественные изменения приведут к качественным, позволят выпускать журнал чаще и освещать еще больше интересных и животрепещущих тем. Если у Вас есть предложения по поводу содержимого будущих выпусков журнала, присылайте свои идеи по адресу analyzeit-journal@gmail.com На страницах журнала вы также встретите детективов, мы решили сделать их героями номера, так при выявлении требований, каждый аналитик хотя бы на минутку становится «великим сыщиком» Всего доброго и до новых встреч! С уважением, команда AnalyzeIT. Analyze IT Осень 2010&
Александр Никитин. Шарж "Peter Falk"
Вводное слово
5/36
Analyze IT
О журнале
Журнал об анализе в IT
AnalyzeIT — это первый в России электронный журнал для системных и бизнес-аналитиков. Погружаясь на целый рабочий день (а часто и больше) в задачи проекта, уделяя свободное время родным и близким, трудно найти время и силы на самообразование и развитие своих профессиональных навыков. В области же постоянно развивающихся информационных технологий необходимо всегда держать «руку на пульсе». Именно поэтому мы решили создать журнал, в котором будут публиковаться как основы
бизнес-анализа и разработки требований от зубров» этих областей, так и самые свежие новости, статьи и модные тенденции в нашей профессиональной деятельности. Вы можете обучаться, восполнять пробелы в теоретических знаниях и быть в курсе новостей в мире бизнесанализа, не затрачивая много времени на поиск и изучение материала. Наш журнал может стать достойным сопровождением вашей утренней (обеденной, вечерней) чашечки кофе.
Команда журнала
Виталий Григораш www.grigorash.ru vgrigorash.moikrug.ru
Анастасия Шварц http://anastasiyamartyinenko.moikrug.ru
Александр Юняев ayunyaev.moikrug.ru
Алексей Шемис http://shemis.moikrug.ru
Артем Казаков http://kzkv.moikrug.ru
Константин Марченко http://konstantinmarchenko.moikrug.ru
Идея журнала, подбор и написание статей, привлечение авторов, дизайн, верстка.
Перевод статей и корректировка переведенных материалов, редактура.
Подбор и корректировка материалов, написание статей
Подбор и корректировка материалов, написание статей.
Дизайн, верстка материалов
Подбор материалов, перевод и написание статей
Ведущий аналитик, Yota
Бизнес-аналитик, Epam Systems
Старший бизнесаналитик, Epam Systems
Системный аналитик, АНТ-информ
Analyze IT Осень 2010&
Руководитель отдела аналитики, Digital Zone
Консультант, Emergn
6/36
Авторы статей Даниэль Новичков
http://dnovichkov.moikrug.ru Координатор проекта WCAG 2.0 Информационного центра ООН в Москве. Автор проекта www.internetbezbarierov.ru Переводчик Руководства по обеспечению доступности веб-контента 2.0. Консультант по доступности вебконтента и удобству использования интерфейсов. Email: daniel.novichkov@gmail.com Тел.: +7 903 979 66 59
Андрей Вербицкий
http://andrey-verbitsky.moikrug.ru Старший продукт-менеджер, Net Cracker Аналитик, менеджер проектов. Докладчик многих конференций в области разработки программного обеспечения Тел.: +7 921 748 00 01
Александр Юняев
http://ayunyaev.moikrug.ru Старший бизнес-аналитик компании Epam Systems Email: Alexander.Yunyaev@gmail.com Skype: Alexander.Yunyaev
Марина Середа
http://www.moderatorsha.ru Частная практика Email: ms@analit.biz
Analyze IT Осень 2010&
7/36
Школа анализа
Андрей Вербицкий Когда произносится слово «аналитик», ассоциации сразу отсылают нас или в сторону экономики (финансов), или в сторону информационных технологий (ИТ) – в те две области, где это слово упоминается наиболее часто. Однако, несмотря на то, что сами по себе эти области достаточно молоды (особенно это касается области ИТ, о которой далее пойдет речь), профессия аналитика, как один из видов человеческой деятельности, существовала задолго до того, как аналитик стал именоваться так официально. Советники правителей и вождей, полководцы и офицеры штабов, философы, писатели и художники и многие другие люди – все они яркие представители профессиональных аналитиков, демонстрирующие свое мастерство в искусстве анализа на протяжении всей истории человечества. Начиная с самого первого в истории шамана, в плохо выделанной шкуре, и заканчивая современными аналитиками с Wall Street в дорогих костюмах – они решали очень разные, но вместе с тем похожие задачи, создавая и совершенствуя в течение тысячелетий философию, инструменты и техники того, что мы сейчас называем анализом. Более того, сфера применения самого анализа как инструмента поистине безгранична. Трудно представить себе вопрос, решение которого могло происходить без использования анализа хотя бы на одном из этапов. Так что каждый из нас, решая задачу, на какой-то момент времени сам становится аналитиком. Что же, раз все мы пользуемся анализом, значит – каждый из нас уже может назвать себя аналитиком и быть успешным в этой области?
Analyze IT Осень 2010
Теги:
ение, ик, обуч т и л а н а , Анализ офия , филос основы
Шаман в шкуре
Анализ. Основы и философия
8/36
Анализ. Основы и философия | Андрей Вербицкий
К сожалению, это не так. Как и естественное умение бегать или физическая сила обычного человека недостаточны для того, что бы быть профессиональным спортсменом - нужны тренировки и освоение специальных техник, так и профессиональный аналитик должен освоить целый ряд дисциплин и практик, чтобы быть успешным в своей деятельности. Стоит заметить, обучение любой другой науке или деятельности начинается с освоения ее базы, ключевых принципов, лежащих в ее основе, поэтому обучение хорошего аналитика должно начинаться с освоения того, что является такой базой и принципами для науки анализа. Позднее это позволит легко осваивать, улучшать и создавать новые практические техники, методы и приемы. Мой опыт и опыт коллег позволяет с уверенностью говорить о том, что технической базой для аналитика являются три ключевых навыка (пока не будем их описывать подробно): 1. умение общаться; 2. умение «смотреть на ситуацию чужими глазами»; 3. умение работать с информацией. Разумеется, этот список можно расширить, включив туда такие навыки, как умение прогнозировать, быстро разбираться в новом материале, навык синтеза и многое другое, но это уже следующие ступени развития, базирующиеся на первых трех. Однако, одной только технической базы еще не достаточно для того, что бы быть действительно хорошим аналитиком. Требуется нечто большее – определенная система взглядов или, если хотите - определенная философия. Analyze IT Осень 2010&
Настоящий аналитик – это искусный, внимательный наблюдатель. И не просто наблюдатель, а наблюдатель, который может рассуждать о явлении или объекте как в терминах их предметной области, так и в терминах любого другого явления или объекта. Он способен свободно менять «горизонт» и «позицию», «систему координат» и «сектор» своего наблюдения, при этом всегда оставаясь за границами наблюдаемого явления. Аналитик может описать наблюдаемую им картину в статике и динамике, с нужной степенью детализации или абстракции, он обладает интуицией, позволяющей ему видеть не только видимые части мозаики явления, но также скрытые или отсутствующие фрагменты и силы, может давать им оценку. Аналитик всегда может легко расширить предлагаемую ему систему координат, если она недостаточна для описания явления или наоборот – ограничить ее, если она слишком обширна. Аналитик видит объект или явле-ние как сами по себе, так и как часть системы, может понять и описать ее закономерности и правила. При этом, он – талантливый повествователь, который может легко и ярко передать свои наблюдения как устно, так и на бумаге для самой разной аудитории. Он – интересный собеседник и может расположить к себе людей, сделав так, чтобы они захотели с ним говорить. Для развития этих качеств, требуется много упорных и целенаправленных усилий, освоение новых знаний и специальных практик, их постоянная тренировка и поддержка.
Анализ (от древне-греческого ἀνάλυσις «разложение, расчленение») — операция мысленного или реального расчленения целого (вещи, свойства, процесса или отношения между предметами) на составные части, выполняемая в процессе познания или предметно-практической деятельности человека.
9/36
Анализ. Основы и философия | Андрей Вербицкий
Итак, как же можно стать аналитиком? Не существует одного универсального ответа на этот вопрос. Путей к цели существует всегда больше чем один. Наиболее традиционный вариант официальное обучение специальности аналитика. Несмотря на то, что сейчас профессия аналитика «включена в списки» многих учебных заведений, этот самый простой и естественный для многих путь не лишен подводных камней. Современная практика обучения аналитика совсем не рассматривает философию анализа. Она концентрируется на обучении техническим навыкам и даже в этом, сосредотачивается преимущественно на третьем навыке (умении работать с информацией) и упускает из виду два первых навыка. Основное внимание уделяется многочисленным инструментам обработки данных, и вместо того, что бы показать, как обработка данных помогает решить реальные задачи, обучение часто сводится к процессу сделать целью саму
обработку, то есть за "деревьями теряется из виду лес", а это отрицательно сказывается на результате. Таким образом, в ходе обучения происходит подмена цели. Методы становятся важнее задач, процесс заменяет собой результат. Часть школ в отрасли поддерживает несколько искусственное, но принятое сейчас деление на системных и бизнес аналитиков. В таких школах, для бизнес-аналитиков (что бы этот термин не означал) обычно вводят отдельные программы, тренирующие навыки общения. Правда даже в этом случае, эти программы являются копией с типовых курсов, использующихся для отработки переговорных или общекоммуникативных, презентационных навыков. Они не акцентируются на особенностях положения и специфике задач аналитика. Последний навык из трех (Умение «смотреть на ситуацию чужими глазами») совершенно не затрагивается в существующих учебных методиках. У аналитика больше шансов
Человеку, выбравшему себе путь аналитика и идущему учиться этой профессии в учебное заведение, надо быть готовым к тому, что многие необходимые знания и навыки ему прийдется искать и осваивать вне его стен. Analyze IT Осень 2010&
столкнуться с необходимостью его освоения при прохождении интервью в некоторых компаниях, нежели в процессе своего обучения. Так что человеку, выбравшему себе путь аналитика и идущему учиться этой профессии в учебное заведение, надо быть готовым к тому, что многие необходимые знания и навыки ему прийдется искать и осваивать вне его стен. К сожалению, трудности, связанные с подготовкой аналитика, не ограничиваются только плоскостью существующей системы обучения. Отрасль ИТ анализа сама по себе страдает рядом «детских болезней», с которыми предстоит столкнуться аналитику ИТ. Одна из таких «болезней» проявляется в том, что являясь наследником многовековой науки и культуры анализа, пусть и не имевшей формального названия, аналитика в области ИТ не проявляет должного внимания и интереса к своим корням, напротив, всячески стараясь выделиться в нечто совершенно новое и независимое. Это приводит к тому, что вместо продолжения движения с уже достигнутых до появления ИТ позиций, аналитика в информационных технологиях проходит весь путь становления заново, повторяя ошибки своих предшественников. Практически полностью игнорируя накопленный опыт, она формирует его повторно, с нуля. Это не только тормозит развитие отрасли ИТ в целом и снижает качество результата, но и заставляет дисциплины, давно использующие анализ в своем арсенале (и владеющие «старыми» методами), смотреть на специалистов ИТ снисходительно и с оправданной долей скептицизма. 10/36
Анализ. Основы и философия | Андрей Вербицкий
Более того, отказ от корней и зацикленность отрасли ИТ на себе порождает сложности во взаимодействии с другими областями знаний. Так, например – трудности понимания ИТаналитиками реальных задач и потребностей бизнеса является одной из глобальных мировых проблем отрасли, частым предметом дискуссий и обсуждений. В качестве завершения этой вводной статьи, хотелось бы порекомендовать аналитикам, как уже работающим, так и только обучающимся или еще только планирующим пойти учиться, уделять больше внимания обзору и освоению опыта анализа из других сфер деятельности. История, философия, военное дело, социология, математика, архитектура, живопись – каждая из этих (и многих других) дисциплин несет в себе частицы таких знаний и опыта, каждая может дать полезный инструмент или набор практик. Так, например, архитектура может дать навык выявления слабых точек решения на самом начальном этапе, живопись дает возможность освоить навык «чужого взгляда», социология учит пониманию мотивов людей, философия помогает видеть явления с разных сторон, военное дело помогает научиться оставаться вовне явления. При этом, вовсе не обязательно изучить каждую область знаний досконально – даже поверхностное знакомство с базой и основными процессами принятия решений могут дать бесценный материал.
Analyze IT Осень 2010&
Трудности понимания ИТ-аналитиками реальных задач и потребностей бизнеса является одной из глобальных мировых проблем отрасли Дмитрий Безуглый http://dbezuglyy.moikrug.ru Боюсь, что с пониманием реальных задач и потребностей есть проблемы у всех, в том числе у Бизнеса :-)
Андрей Вербицкий http://andrey-verbitsky.moikrug.ru Дима, с пониманием своих задач/целей у бизнеса проблем нет (разве что с вербализацией), а вот с методами и путями их достижения не так гладко
Галина Карабанова http://karabanovagalina.moikrug.ru Почему-то очень захотелось дополнить: отсутствие желания понимать реальные задачи и потребности бизнеса как представителями заказчика, так и представителями разработчика, как раз и порождает эти самые "трудности понимания"...
Читайте полное обсуждение на http://moikrug.ru/feed/560104366/
11/36
Работа
Вопросы работодателя Перевод: Анастасия Шварц
В настоящий момент многие компании от привычного разговора с кандидатом о его успехах и будущих целях переходят к использованию в ходе собеседования нестандартных вопросов и логических задач. Целью является выяснение того, как кандидат будет действовать в реальных рабочих ситуациях, и насколько успешно будет справляться с задачами в своей профессиональной области. Не обошла эта тенденция и область аналитики в ИТ. Так какие вопросы может задать потенциальный работодатель Вам на собеседовании в случае, если Вы претендуете на должность аналитика? Мы подобрали для вас пару примеров с портала www.modernanalyst.com уже с ответами
Q A
Как убедиться, что определены ключевые проблемы или требования? Решение проблем и их анализ – это неотъемлемая часть работы бизнес-аналитика. Но перед тем как потратить время на решение проблемы вы должны быть уверены, что вы решаете нужную проблему и обладаете достоверными требованиями. Одним из способов определения ключевой проблемы является так называемый «пересмотр проблемы». Вот основные приемы:
Перефразирование проблемы Измените формулировку проблемы, совсем немного, чтобы получить новую постановку очень близкую к исходной. Повторяйте этот процесс до тех пор, пока не прийдете к формулировке ключевой проблемы.
Analyze IT Осень 2010&
Вопросы работодателя и ответы аналитика взяты с сайта www.ModernAnalyst.com. Страницу с вопросами на английском языке можно найти пройдя по ссылке http://www.modernanalyst.com/ Careers/InterviewQuestions/tabid/ 128/Default.aspx
5W +1H Кто (Who), Что (What), Где (Where), Почему (Why) + Как (How). Сформулируйте вашу проблему различными способами, начиная каждый раз с приведенных выше вопросов. Еще раз спросите Почему? Начав с первоначальной постановки, задавайте этот вопрос до тех пор, пока не прийдете к простой и однозначной формулировке ключевой проблемы.
12/36
Вопросы работодателя | Modern Analyst | Перевод Анастасия Шварц
Q A
Что делать в ситуации, когда требования владельцев процесса противоречат друг другу? Для того чтобы понять, какие действия необходимо предпринять для решения этого конфликта, аналитик должен в первую очередь разобраться в причинах разногласий. А причины, как правило, повторяются. Вот несколько наиболее часто встречающихся причин возникновения конфликта и пути их устранения:
Один или несколько владельцев процесса не понимают высокоуровневых целей компании, из которых вытекают требования. Это и делает их источником информации, противоречащей «линии партии». В этом случае прийдется потратить некоторое время на то, чтобы вернуться на шаг назад и сформировать у всех единое понимание предпосылок проекта. Организуйте встречу всех заинтересованных сторон, но в ходе обсуждения постарайтесь избежать прямого описания целей и задач, лучше попросить сами конфликтующие стороны озвучить их. Это быстро выявит все расхождения, а затем открытый разговор поможет достичь консенсуса. Если необходимо, конфликтующие стороны могут обратиться к руководителю проекта или спонсору проекта для окончательного прояснения.
Analyze IT Осень 2010&
Все владельцы процесса одинаково понимают высокоуровневые цели компании, но каждый из них способствует достижению этих целей поразному. Обе стороны имеют обоснованные потребности, но не отдают себе отчет в том, что вклад одной из сторон в развитие компании в долгосрочной перспективе может быть меньше. Этим определяются различия при расстановке приоритетов потребностей каждой из сторон на уровне компании. Это тот случай, когда эскалация проблемы действительно необходима. Обе стороны имеют обоснованные требования и пытаются удовлетворить свои нужды. Тем не менее, одна из сторон может обладать большим приоритетом. Устранить проблему поможет привлечение независимого посредника, разбирающегося в высокоуровневых целях и приоритетах подразделений и компании.
Все владельцы процесса преследуют одну цель, но расходятся в понимании оптимального пути достижения этой цели. Они могут не соглашаться по поводу пересмотра бизнес-процессов или порядка действий пользователя в системе. В случае нового бизнес-процесса, запустите пилотный проект, задействовав небольшую группу участников процесса в течение короткого отрезка времени. Сравните результаты реализации нового процесса со старым. Кроме того, можно проверить несколько пилотных решений для определения лучшего варианта процесса для последующего внедрения. Продемонстрируйте результаты и выводы заинтересованным лицам. Для определения оптимального порядка действий пользователя в системе подготовьте макеты экранных форм или действующий прототип. Смоделируйте прохождение по системе вместе с конечными пользователями продукта. При этом на каждом шаге пользователи должны отвечать на следующие вопросы: 1) Что произойдет, когда вы нажмете эту кнопку? 2) Где вы окажитесь, если нажмете сюда? 3) Как вы думаете, какая форма будет следующей? Используя полученные таким образом данные, команда сможет достичь согласия по вопросу оптимального порядка действий пользователя или форм пользовательского интерфейса. Если конфликт сосредоточен лишь вокруг дизайна форм, положитесь на лучшие примеры и шаблоны юзабилити в разработке пользовательского интерфейса. Напомните, что они зарекомендовали себя в ходе работы во многих других компаниях и проектах и выдержали испытание пользователями и временем.
13/36
Analyze IT
Журнал об анализе в IT
∗
Тема номера
Выявление требований. Интервьюирование Александр Юняев
Теги: требования, интервью, бизнесаналитика, системный анализ, выявление требовании
1. Важность этапа выявления требований Еще 15 лет назад, в далеком 1994 году, группа Стендиша в своем исследовании пришла к выводу о важности этапа выявления требований. А опыт многих проектов с момента возникновения индустрии разработки программного обеспечения (ПО) и вплоть до нашего времени — лишь яркое тому подтверждение. Действительно, давайте рассуждать логически. Разработчик создает ПО под нужды конкретного Заказчика. Степень удовлетворения этих нужд зависит от многих факторов, среди которых можно назвать: квалификацию Разработчика, опыт Разработчика, тип разрабатываемого ПО и т.п. Но все эти факторы отходят на второй план, если мы не до конца понимаем, что же на самом деле хочет Заказчик. Можно обладать огромным опытом и наивысшей степенью квалификации в разработке, но при этом бесконечно долго доделывать и переделывать уже разработанное ПО. Конечно, удовлетворить раз и навсегда все потребности Заказчика не получится. Ведь мы живем в динамичном и постоянно изменяющемся мире. Но в наших силах сделать минимальным размер тех доработок, которые потребует Заказчик. А для этого необходимо на этапе выявления требований максимально полно понять истинные потребности Заказчика. Полагаю, не стоит объяснять, что исправление ошибок в требованиях на этапе разработки и, тем более, тестирования и ввода в эксплуатацию, стоит на порядок дороже, чем своевременное их устранение или недопущение. Думаю, после всего вышесказанного у читателя не осталось сомнений в исключительной важности этапа выявления требований. Но, наряду с важностью, данный этап является очень сложным, подверженным ошибкам и требующим интенсивного общения с Заказчиком. Поэтому предъявляет высокие требования к квалификации сотрудников Разработчика (бизнес-аналитиков), которые будут принимать в нем участие. Analyze IT Осень 2010&
15/36
∗ Выявление требований. Интервьюирование | Александр Юняев 2. Методы выявления требований За многолетнюю историю создания ПО было разработано много различных методов, позволяющих выявить нужды и потребности Заказчика. Вот перечень некоторых из них: — интервьюирование; — анкетирование; — совместное совещание; — мозговой штурм; — наблюдение за пользователями; — изучение документов; — создание прототипов. В рамках данной статьи я не буду описывать подробно каждый из перечисленных методов. Отмечу лишь, что все они имеют свои плюсы и минусы, а также область применения. Бизнес-аналитик должен выбирать тот или иной метод в зависимости от конкретной ситуации на конкретном проекте. Мне же хотелось бы остановиться и рассказать более подробно об одном из методов, который я наиболее часто использовал в своей практике — интервьюирование.
3. Интервьюирование Интервьюирование по праву является одним из самых важных, понятных и распространенных методов выявления требований, который можно использовать практически в любой ситуации. Это относительно универсальный и простой метод, позволяющий глубоко вникнуть в потребности Заказчика. К преимуществам этого метода можно отнести возможность задавать вопросы и получать на них ответы в реальном времени, одновременно управляя ходом беседы и направляя ее в требуемое русло. Но при всей кажущейся простоте этот метод предъявляет очень высокие требования к компетенции бизнес-аналитика, а также к его коммуникативным навыкам и умению управлять ходом беседы, что, к сожалению, приходит только с опытом. Хронологически интервьюирование состоит из нескольких этапов: — подготовка к интервью; — проведение интервью; — обработка результатов интервью. Рассмотрим каждый из этих этапов более подробно. Analyze IT Осень 2010&
Интервьюирование — это процесс диалогового общения двух и более людей, организованный в форме «вопрос-ответ», целью которого является извлечение интервьюером некоторой информации у интервьюируемого.
16/36
∗ Выявление требований. Интервьюирование | Александр Юняев 3.1. Подготовка к интервью Любое интервью должно начинаться с подготовки. Нельзя приходить на встречу к Заказчику неподготовленным. Как минимум, Вы будете выглядеть в его глазах непрофессионалом, незаинтересованным в получении желаемого результата. Поэтому в идеале проведению каждого интервью, как, в принципе, и любого важного мероприятия в Вашей жизни, должен предшествовать этап подготовки. Поэтому перед началом встречи бизнесаналитик, возможно прибегая к помощи руководителя проекта для решения организационных вопросов, должен проработать следующие обязательные моменты: — место, дату и время проведения встречи;
Analyze IT Осень 2010&
— состав участников встречи; — цель/тему встречи; — повестку встречи. Место, дата и время проведения встречи должны быть выбраны таким образом, чтобы это было максимально удобно для представителей Заказчика. Не будем забывать, что Заказчик делает свой основной бизнес, в котором ИТсоставляющая чаще всего играет отнюдь не ключевую роль. Очень часто сотрудники Заказчика приходят на встречу жертвуя своим личным временем, которое им потом прийдется отрабатывать. Так как в подавляющем большинстве случаев никто не снимает с них ответственности за выполнение того объема работ, который они делают ежедневно. Поэтому от удобства времени проведения встречи может зависеть ее продуктивность.
Обычно встречи проводятся на территории Заказчика, чтобы минимизировать затраты времени интервьюируемых. По поводу выбора времени проведения, на мой взгляд, особых предпочтений нет. Кому то удобнее проводить встречу утром, «на свежую голову». Кому то — во второй половине дня, когда все основные рабочие моменты уже решены. Но по опыту могу сказать, что не стоит назначать встречу в обеденный перерыв, так как это время предназначено для отдыха и восстановления сил, а также во второй половине дня в пятницу, так как к концу недели продуктивность любого сотрудника очень низкая. Состав участников встречи должен определяться исходя из ее цели. Необходимо тщательно проанализировать, кто из сотрудников Заказчика сможет наиболее полно
17/36
∗ Выявление требований. Интервьюирование | Александр Юняев и точно ответить на все поставленные вопросы. Не стоит приглашать на встречу сотрудников, которые будут просто сидеть и слушать, что говорят их коллеги — берегите свое время и время Заказчика. Число интервьюируемых может быть в общем случае любым. Но имейте в виду, что чем больше людей принимает участие во встрече, тем сложнее будет управлять ее ходом. Был в моей практике случай, когда на встрече присутствовало 3 сотрудника Заказчика. Причем, как выяснилось позже, только один из них мог компетентно ответить на большинство вопросов. А двое других большую часть встречи сидели и разговаривали между собой на отвлеченные темы, тем самым мешая мне общаться с основным интервьюируемым. На последующие встречи тех двоих мы не приглашали... Цель встречи должна быть четко определена и доведена до всех участников. Однозначное понимание цели всеми участниками позволит сократить продолжительность встречи, сделает ее более продуктивной, а также позволит бизнес-аналитику более эффективно управлять ходом беседы, не давая интервьюируемым выходить за рамки обсуждения. Как и в обычной жизни, цели могут быть разноуровневые. Может быть цель: «Определить контекст Системы», а может быть: «Определить варианты использования для подсистемы администрирования». Но какого бы уровня цель мы не заявили — она должны быть обязательно. Иначе интервью превращается в разговор ни о чем. Analyze IT Осень 2010&
Повестку встречи со списком обсуждаемых вопросов желательно заблаговременно разослать всем участникам интервью, для того чтобы они могли подготовиться. Правда, как показывает практика, малый процент сотрудников Заказчика знакомится с повесткой встречи до ее проведения. Очень часто возникает ситуация, когда интервьюируемый первый раз читает повестку непосредственно на встрече. Хорошо еще, если он принесет ее с собой, а не получит из рук бизнес-аналитика. Кстати, приносите на встречу столько копий необходимых материалов, сколько планируется участников встречи. Но вне зависимости от того, будет Заказчик читать повестку встречи или нет, бизнесаналитик обязан подготовить список вопросов, которые необходимо обсудить. Как минимум, это позволит структурировать свои мысли и продумать ход беседы. А это, в свою очередь, существенно поможет ориентироваться в ходе самой встречи и сократит ее продолжительность. Вопросы, в большинстве своем, должны быть открытыми, в которых интервьюируемый не получает каких-либо подсказок, или вариантов, ответа. Степень детализации вопросов должна зависеть от конкретной ситуации. В некоторых случаях вопросы должны быть очень высокоуровневые. Например, когда встреча с Заказчиком происходит впервые, и для начала необходимо понять его бизнес-потребности. В других случаях вопросы должны быть более детальными. Например, когда уже идет процесс разработки и Заказчик хочет добавить новую функциональность в Систему.
Кроме того надо понимать, что на обсуждение с Заказчиком необходимо выносить не все возникающие у бизнес-аналитика вопросы, а только те, на которые нельзя получить ответы другими способами (в ходе e-mail переписки, телефонных звонков и т. п.). В моей практике, например, был негативный опыт, когда Заказчик требовал обсуждать на встречах все технические моменты, которые прекрасно можно было бы обсудить в электронной почте. Причем это потребовало бы меньших затрат времени и сил как со стороны Заказчика, так и со стороны Разработчика.
...когда встреча с Заказчиком происходит впервые, для начала необходимо понять его бизнеспотребности
18/36
∗ Выявление требований. Интервьюирование | Александр Юняев 3.2. Проведение интервью Проведение интервью в большей степени находится в области коммуникации и межличностного общения. Интервью подразумевает наличие как минимум двух человек, беседующих на общую тему. И уже этот факт говорит о том, что эффективность его проведения существенно зависит от коммуникативных навыков участников встречи, а также от умения интервьюера управлять ходом беседы. Поэтому бизнес-аналитик должен не только хорошо разбираться в предметной области Заказчика, но и уметь грамотно и профессионально наладить процесс общения с его представителями. Последнее требует познаний и навыков в основах коммуникаций и психологии общения. Помнится, мое самое первое в жизни интервью было очень волнительным. В процессе той встречи было уничтожено огромное количество нервных клеток, которые до сих пор не восстановились. К счастью, несмотря на внутреннее напряжение, которое не покидало меня на протяжении всей встречи, тогда все завершилось благополучно. При проведении интервью очень важно создать непринужденную атмосферу, которая способствовала бы продуктивному общению и глубокому пониманию потребностей Заказчика. Однозначного рецепта создания такой атмосферы, к сожалению, не существует. К каждому человеку в каждой конкретной ситуации необходим свой подход. При этом необходимо понимать, что успешным интервью будет только в том случае, когда представители Заказчика действительно заинтересованы в получении конечного результата. А бизнес-аналитик может способствовать развитию этого интереса. Ведь большинство компаний принимают решение о создании той или иной Системы отнюдь не от хорошей жизни. И если решение уже принято, значит есть сторонники разрабатываемой Системы. Сосредоточьте свое основное внимание именно на них. Скорее всего, по их инициативе и создается Система. А противники, спросите Вы? Противники будут всегда. Нужно уметь грамотно лавировать среди айсбергов. Только тогда Вы сможете добиться ощутимого результата. Чаще всего Заказчик имеет довольно смутное представление о своих
Analyze IT Осень 2010&
...бизнес-аналитик должен уметь грамотно и профессионально наладить процесс общения с представителями Заказчика
истинных потребностях и не может выразить их в ясной и понятной форме. Во время беседы сотрудники Заказчика могут рассказывать Вам о каких-то своих пожеланиях, предлагать какие-то собственные варианты решения имеющихся проблем. При этом очень часто они рассказывают не о проблемах и потребностях, а о поведении Системы, которое, по их мнению, будет служить удовлетворению этих потребностей. Бизнесаналитик должен разобраться в потоке всей этой информации и понять, что же на самом деле хочет Заказчик, каковы его истинные потребности. Хотя это не всегда бывает просто. И, возможно, для прояснения всех этих вопросов может потребоваться еще несколько интервью, предварять которые будет глубокий анализ информации, полученной на более ранних встречах.
19/36
∗ Выявление требований. Интервьюирование | Александр Юняев Для того чтобы докопаться до сути, необходимо как можно чаще задавать вопрос: «Почему?». Также не стоит бояться задавать вопросы, которые могут показаться представителям Заказчика «глупыми». Ответы на эти вопросы позволят выявить требования, которые участники встречи считают само собой разумеющимися. Хорошей практикой во время проведения интервью является не только фиксация той информации, которую говорит Заказчик, но и предложение собственных вариантов, основанных на личном опыте. Ведь если бизнесаналитик достаточно опытен и участвовал во многих проектах, то применяемые ранее подходы и методы могут быть применимы и в данной ситуации. Кроме того, бизнес-аналитик не так глубоко знает предметную область, как сотрудник Заказчика, и может выйти за рамки, ограничивающие мышление. Как говорится, аппетит приходит во время еды. Поэтому очень часто сотрудники Заказчика во время интервью высказывают какие-то идеи, которые выходят за рамки проекта. В этом случае бизнес-аналитик должен корректно направить беседу в рамки обсуждения и объяснить участникам встречи, почему та или иная функциональность не может быть реализована в текущих рамках проекта. Причем эта особенность представителей Заказчика, как правило, чаще всего проявляется на первых этапах проекта, когда границы еще четко не определены. В этом случае бизнес-аналитику может потребоваться помощь менеджера проекта, который чаще всего присутствует вместе с аналитиком на таких встречах. В ходе встречи необходимо придерживаться определенного уровня детализации. Например, на начальных этапах проекта не нужно обсуждать мельчайшие подробности интерфейса. Хотя, как показывает личный опыт, будущим пользователям Системы уже на первой встрече очень хочется объяснить Вам, что логотип своей фирмы они хотели бы видеть в верхнем правом углу экранной формы. Во время встречи сотрудники Заказчика могут также упомянуть о некоторых важных вопросах, которые на данной встрече обсуждать не предполагалось, но которые потенциально могут стать отдельными темами для последующих встреч. Очень важно в такой ситуации обратить внимание на эти вопросы и в будущем проработать их более детально. Analyze IT Осень 2010&
В процессе интервью бизнес-аналитик должен каким-либо образом фиксировать получаемую от Заказчика информацию. Ведь пределы человеческой памяти ограничены. Самый простой способ — записывать основные моменты обсуждения на бумаге. В дальнейшем сделанные пометки можно использовать для того, чтобы восстановить в памяти ход встречи. Это наиболее часто применяемый способ, так как не требует никаких дополнительных затрат. Ведь ручка и листок бумаги есть в любом офисе.
Хорошей практикой во время проведения интервью является не только фиксация той информации, которую говорит Заказчик, но и предложение собственных вариантов, основанных на личном опыте. Тeма Казаков, Analyze IT http://kzkv.moikrug.ru Высказывать свое мнение и предлагать варианты решения задачи Заказчика прямо во время интервью — рискованная затея, ведь можно сбить «волну» интервьюируемого и переключить его на опровержение Вашего мнения. Бывает, что лучше работает легкая коррекция, подсказки Заказчику о том, что еще стоит рассказать, а предложение вариантов можно оставить на этап обработки результатов интервью.
20/36
∗ Выявление требований. Интервьюирование | Александр Юняев Более современный способ фиксации получаемой информации — использование диктофона. В этом случае после проведения встречи можно прослушать сделанную запись сколько угодно раз. Но не каждый человек согласится, чтобы его записывали на диктофон. Поэтому, если Вы решили использовать диктофон, получите у участников встречи согласие на запись. Какой способ фиксации информации выбрать, также зависит от конкретной ситуации: обсуждаемых вопросов, знаний бизнес- аналитика в данной предметной области, продолжительности встречи и т. п. У меня в практике бывали ситуации, когда хватало только тех заметок, которые я оставлял в процессе интервью на листке бумаги. А бывали случаи, когда приходилось по несколько раз прослушивать диктофонную запись, чтобы восстановить мельчайшие детали, которые, как оказалось, имеют очень важное значение. Как я уже говорил, едва ли не самым важным фактором, влияющим на успешность проведения интервью, является умение бизнес-аналитика вести беседу. Психологи и просто опытные люди могут дать Вам огромное количество рекомендаций по этому поводу: «не перебивайте»; «не пытайтесь показать свои знания»; «не возражайте»; «не иронизируйте»; «концентрируйтесь на наиболее сложных аспектах предметной области»; «уточняйте и подтверждайте информацию»; «отделяйте мнения от фактов» и т.п. Полагаю, каждый из Вас читал все эти фразы не один раз в разных источниках. Советы и рекомендации — это, конечно, хорошо. Но нужно понимать, что читая умные книжки и разнообразные статьи, реального практического опыта не наберешься. Для развития навыков и повышения квалификации нужна постоянная практика. Практикуйтесь. И в один прекрасный день, я уверен, Вы завершите свое очередное интервью с чувством выполненного долга, и скажете самому себе: «Это была прекрасная встреча. Я выяснил все, что хотел, и в этом мне помог мой богатейший опыт. И немного везения». Очень важно в процессе интервью придерживаться заранее определенных временных рамок. Оптимальным считается продолжительность встречи, составляющая полтора-два часа. Если встреча продолжается более двух часов, то ее эффективность снижается из-за усталости участников.
Analyze IT Осень 2010&
Хорошей практикой является подведение краткого резюме встречи и определение плана дальнейших действий
Но, хотя авторитетные авторы и приводят такую оценку, все зависит от конкретной ситуации. В моей практике бывали встречи, которые занимали около трех часов, но проходили буквально на одном дыхании. Потому что люди были реально заинтересованы, хотели рассказать, что же им на самом деле нужно, были готовы к тесному и плодотворному сотрудничеству. А бывали встречи продолжительностью около часа, после которых я выходил как выжатый лимон, имея только одно желание — побыстрее добраться до дома. После того, как Вы получили от представителей Заказчика необходимую информацию, встречу нужно завершать. При этом необходимо убедиться, что в ходе встречи удалось обсудить все заявленные вопросы. Хорошей практикой является подведение краткого резюме встречи и определение плана дальнейших действий.
21/36
∗ Выявление требований. Интервьюирование | Александр Юняев 3.3. Обработка результатов интервью После проведения интервью необходимо составить и согласовать с участниками интервью протокол встречи. По завершении интервью необходимо оформить протокол встречи, содержащий полученную от Заказчика информацию. На всех проектах, на которых я участвовал, в начале проекта разрабатывался шаблон протокола, который позволяет сократить время на его оформление, а также унифицировать формат протоколов встреч в рамках проекта.
Если в ходе встречи Вы получили от Заказчика какие-то материалы, советую указать их в протоколе. На будущее. Мало ли что может случиться. После составления протокола его необходимо согласовать со всеми участниками встречи. Только после того, как каждый участник подтвердил свое согласие с указанной в протоколе информацией, эту информацию можно использовать в проекте. Если в процессе согласования некоторые из участников не захотели подтверждать свои слова, возможно, необходимо провести повторные встреч для прояснения ситуации. Если же повторные встречи не помогают и на лицо конфликт — необходимо эскалировать данную проблему на более высокий уровень управления и решать ее уже на этом уровне. Но в моей практике такие ситуации встречались очень редко. Обычно все возникающие вопросы снимаются на уровне самих участников интервью.
4. Послесловие Подводя итог всему вышесказанному, хочется пожелать следующее: — готовьтесь к интервью; — учитывайте коммуникативные особенности собеседников; — выявляйте истинные потребности Заказчика; — составляйте протокол встреч. И практикуйтесь, практикуйтесь, практикуйтесь! Ничто не сможет заменить практики. Особенно, в области межличностного общения. Считаю, что это очень хорошая практика, которую необходимо взять на вооружение. Если вы ее еще не используете. Да и вообще — полезно разрабатывать шаблоны всех проектных документов перед их заполнением. Но это тема для отдельной статьи. Содержательная часть протокола зависит от конкретной ситуации. Иногда необходимо максимально подробно зафиксировать слова каждого участника встречи. Иногда достаточно вкратце отразить основные моменты обсуждения и принятые решения. Иногда необходимо «пропустить через себя и свои знания» полученную информацию, а в протоколе указать только сделанные выводы. Analyze IT Осень 2010&
P.S. Статья подготовлена с учетом собственного опыта автора на основе материалов признанных гуру в области разработки требований: — Карл И. Вигерс «Разработка требований к программному обеспечению»; — Дин Леффингуэл, Дон Уидриг «Принципы работы с требованиями к программному обеспечению. Унифицированный подход»; — Лешек А. Мацяшек «Анализ требований и проектирование систем»; — Э. Халл, К. Джексон, Д. Дик «Разработка и управление требованиями».
22/36
∗
Тема номера
Анализ документации Марина Середа
Введение Документы являются для аналитика одним из основных источников информации на этапе сбора требований. В проектах, где Представители Заказчика стремятся минимизировать свое общение с аналитиками, документы оказываются практически единственным источником требований. Поэтому умение с ними работать приобретает критическое значение. Чтобы яснее представлять себе смысл и ограничения этой работы, стоит вспомнить, что такое документ. «Документ (от лат. documentum — образец, свидетельство, доказательство) – материальный объект, содержащий информацию в зафиксированном виде и специально предназначенный для её передачи во времени и пространстве. Носителем информации может быть бумага, перфокарта, фотопленка, магнитофонная лента и т.п. Документы могут содержать тексты на естественном или формализованном языке, изображения, звуковую информацию и др. По содержанию документы делятся на научно-технические (статьи, книги, патенты, технические отчёты и описания), правовые (постановления, указы, договоры и др.), управленческие (приказы, директивы) и др. Документы могут быть первичными и вторичными (реферат, аннотация, обзор и т.д.). В узком смысле документ – деловая бумага, подтверждающая какой-либо факт или право на что-то» [Большая советская энциклопедия]. Согласно законодательству Российской Федерации: «документ - материальный носитель с зафиксированной на нем в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания, который имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения» [Федеральный закон «Об обязательном экземпляре документов» от 23.11.1994 N 77-ФЗ, ст.1 (в ред. Федерального закона от 26.03.2008 N 28-ФЗ)]. Исходя из определений следует, что основная характеристика документа – наличие зафиксированной информации. С этой точки зрения аудио- или видео-запись тоже является документом, сюда же относится все, что хранится и передается в электронном виде. Однако далеко не всё из перечисленного представляет собой хороший источник требований.
Analyze IT Осень 2010&
Теги: документ, источник информации, выявление
23/36
∗ Анализ документации | Марина Середа Подходящие и неподходящие источники В процессе работы у каждого аналитика формируется свое представление о том, какие источники более надежны, какие менее. Это представление зависит от специфики предметной области, от внутренних условий в компании-разработчике и от других факторов. Возможно, предлагаемый список подходящих источников не является идеальным, но он на это и не претендует, и может быть расширен.
1. Законодательство. Документы данной категории могут быть неполными и противоречивыми, но недостоверными они бывают редко – в таких случаях довольно быстро появляются соответствующие поправки. Это самый надежный из всех публичных источников.
2. Внутренние документы Заказчика. В каждой организации существуют свои правила, процессы, формы представления информации и т.д. Многое из перечисленного зафиксировано в документах, которые аналитик также может использовать в своей работе.
3. Деловая переписка.
4. Проектная документация.
Очень часто внимательный анализ содержимого своего почтового ящика открывает удивительные вещи, и не стоит пренебрегать этим источником даже в том случае, если вы полностью уверены, что ничего подходящего для решения вашей задачи там нет.
Если ваша компания когда-либо выполняла похожий проект, то вполне возможно, что в текущем проекте вы сможете использовать некоторые идеи и решения из предыдущего. Кроме того, в проектных документах иногда встречаются удачные примеры описания требований.
Можно упомянуть еще записи телефонных разговоров, интервью и совещаний с участием Заказчика или внутри компании. Такие источники не будут рассматриваться здесь, поскольку они относятся к сфере коммуникации, чему посвящена отдельная статья (для деловой переписки сделано исключение в силу ее особой документальной ценности). Неподходящими источниками являются: средства массовой информации; обращения клиентов и сотрудников Заказчика, не являющихся членами рабочей группы проекта; любые источники, информацию из которых трудно проверить и установить ее автора. На первый взгляд кажется, что подходящих источников значительно больше, чем неподходящих. Это объясняется тем, что при анализе любая информация полезна, так как позволяет максимально тщательно исследовать вопрос. Но, в силу временных ограничений, стоит сосредоточиться на нескольких основных источниках, к тому же все остальные будут во многом их повторять. Analyze IT Осень 2010&
24/36
∗ Анализ документации | Марина Середа Принципы отбора документов Мое глубокое убеждение, следующее из профессионального опыта и здравого смысла, состоит в том, что правильный отбор источников определяет не меньше половины успеха анализа документации. Качество остальной работы ограничено тем, насколько хорошо сформирован этот первичный объем информации, отвечает ли он требованиям достоверности, полноты, актуальности и т.д. Опытным путем выделены несколько принципов, которых лучше придерживаться, отбирая документы для анализа.
1. Понимание цели. От того, насколько четко вы поняли задачу, прямо зависит, сколько времени вы потратите на поиск решения. Если вы собираете требования для новой системы, то должны знать бизнес-цели Заказчика. Если требуется внести изменения в существующую систему, то знать, в чем эти изменения должны заключаться, или чем они вызваны, или какого эффекта хотят добиться с их помощью. В первом случае цель
Analyze IT Осень 2010&
может быть более абстрактной, для широты охвата, во втором – вполне конкретной, точечной, для сужения поиска. Разрешайте все свои сомнения в правильности понимания цели до того, как начинать анализ. В этом вам должен содействовать Заказчик, а если содействия добиться не удается, «тренируйте свои телепатические способности». Если разные источники дополняют или корректируют друг друга, установите, какие версии каких документов наиболее полно отвечают вашей цели, и работайте с ними. Это особенно справедливо в отношении правовых документов и внутренней документации Заказчика, которые регулярно изменяются.
2. Авторство. Любой документ кем-то создан, и его создатель, во-первых, несет определенную ответственность за содержание документа, во-вторых, сам является источником информации, которая может быть вам полезна. Если вы не можете установить автора, не пользуйтесь этим источником. Авторство может быть индивидуальным или коллективным, как в случае законодательных актов, главное, чтобы оно было зафиксировано. В
противном случае вам некуда будет обращаться с вопросами.
3. Первоисточники. Чем ближе к первоисточнику, тем меньше искажений, тем более достоверна информация. Переводы и пересказы иногда бывают столь своеобразны, что риск от их использования сопоставим с риском упустить важные требования, которые в них содержатся. Все документы, написанные на иностранном языке, лучше читать в первозданном виде.
означает следующее: если в документе нет глоссария, уточняйте смысл всех слов, обозначающих важные для данной задачи и часто встречающиеся в тексте понятия (даже если для вас они очевидны). Для того, чтобы это было возможно, нужно придерживаться принципов изложенных в п. 2 и 3. Чтобы правильно выбрать источники, с точки зрения всего перечисленного, можно пользоваться таблицей 1 (вариант таблицы не окончательный, открыт для дополнений и уточнений).
4. Терминология. Весьма заманчиво полагать, что люди, говорящие на одном языке, вкладывают одинаковый смысл в одни и те же слова. Существует и другое утверждение – смысл разных слов часто бывает одинаковым в понимании разных людей. И никто никогда не станет обсуждать с вами столь очевидные вещи, разделяя ваше заблуждение. Выход один – «взять паяльник и добраться до истины самому». Если правовая документация всегда содержит описание используемой терминологии, то управленческая и техническая может ее не содержать. На практике это 25/36
∗ Анализ документации | Марина Середа Таблица 1 – Достоинства и недостатки документов различных типов
Тип источника Законодательство
Достоинства
Недостатки
Типы требований
Содержат достоверную информацию Обязательны к исполнению
Двусмысленность формулировок Неполнота освещения некоторых вопросов
Бизнес-правила
Внутренние документы заказчика
Обязательны к исполнению в организации заказчика
Не всегда актуальны
Бизнес-правила
Возможны трудности с терминологией
Функциональные требования Ограничения
Деловая переписка
Содержат подробности по конкретным вопросам Отражают фактическую ситуацию
Субъективность
Бизнес-требования
Возможны трудности с терминологией
Бизнес-правила Функциональные требования Ограничения
Содержат варианты решения типичных проблем Содержат образцы описания требований
Ограниченная применимость
Бизнес-требования
Проектная документация
Таким образом, общая концепция следующая: использовать первые два типа как наиболее надежные источники бизнес-правил, третий – для получения более детальной информации по каждому конкретному случаю и четвертый – для поиска типичных примеров. «Минимальный пакет» для анализа должен включать первые два. Например, если вы разрабатываете систему учета продаж автомобилей в кредит для сети автосалонов, то вам, скорее всего, потребуются: i. правовые документы, регулирующие кредитные, страховые и бухгалтерские вопросы;
Analyze IT Осень 2010&
Ограничения
Функциональные требования Ограничения
ii.
внутренние документы Заказчика, касающиеся продаж – взаимодействие с клиентами, порядок расчетов, учет продаж и пр. Если вы создаете систему бронирования гостиниц через Интернет для туристического оператора, то минимальный пакет может быть таким: i. правовые документы, регулирующие предоставление туристических услуг и, возможно, миграционные вопросы; ii. внутренние документы Заказчика, описывающие взаимодействие с гостиницами, включая порядок расчетов, действия при отказе клиента и пр.
26/36
∗ Анализ документации | Марина Середа Сравнение источников Самые большие трудности возникают при сопоставлении информации из разных источников. В этом случае, если аналитик не обладает хорошим знанием предметной области, ему часто приходится обращаться за уточнениями к экспертам, лучшими из которых будут представители Заказчика, т.к. именно они чаще всего делают выбор в спорных ситуациях. В случае, когда источники повторяют друг друга, действия аналитика очевидны. Другие случаи стоит рассмотреть подробнее.
Analyze IT Осень 2010&
1. Дополнение. Когда один документ добавляет существенные факты (с точки зрения цели) к тому, что содержится в другом документе, это может быть признаком: i. неполноты первого документа; ii. описания частного случая. Если полнота и актуальность первого документа не вызывают сомнений, то наиболее вероятен второй вариант. В других случаях полезно поискать дополнительные источники. Часто эта ситуация встречается при сравнении правовых документов с внутренними документами Заказчика: первые содержат общие правила, вторые – их применение в конкретной организации.
2. Уточнение. Один документ может детализировать то, что описано в другом. В таких случаях нужно выяснить, существенна ли эта детализация для решаемой задачи. Например, взаимодействие с клиентом может быть разным в зависимости от того, является ли он физическим или юридическим лицом, резидентом или нерезидентом, безработным, студентом или владельцем собственного бизнеса. Но, если клиент чтото покупает, то вне зависимости от перечисленных факторов он должен оплатить покупку. Важно понять, в какой области различия существенны, то есть, порождают разные требования.
3. Противоречие. Бывает, и это не такая уж большая редкость, что источники противоречат друг другу. В таком случае предпочтительнее ориентироваться на правовые документы – нарушение требований, которые в них изложены, наиболее рискованно. Если внутренние документы Заказчика противоречат законодательству, это повод для обсуждения. Возможно, первые не успели актуализировать. Если внутренние документы противоречат друг другу, нужно совместно с Заказчиком определить, какие из них применять в текущей ситуации. В любом случае, обнаруженные противоречия стоит разрешать при участии Заказчика – это минимизирует риски.
27/36
∗ Анализ документации | Марина Середа Заключение В заключение пара слов о том, почему в этой статье не рассматриваются примеры извлечения требований из конкретных документов. Прежде всего, из перечисленного списка подходящих источников только один является публичным – законодательство. К остальным трем доступ ограничен, поэтому цитировать их здесь означало бы нарушать соглашение о неразглашении информации. Придумывать же примеры похожие на реальные, не вполне убедительно. Во-вторых, как верно замечено в одной хорошей книге (К.Вигерс «Разработка требований к программному обеспечению», Глава 7), требования не лежат, ожидая, когда их соберут, в одном месте – нужно
Analyze IT Осень 2010&
прочитать весь документ от начала до конца, чтобы их выделить, т.к. разные части одного требования могут находиться в разных частях документа. Такие объемы текста вряд ли уместны в статье, а упрощения не отразят реальную ситуацию. В-третьих, та же хорошая книга содержит некоторое количество примеров, к которым вряд ли можно добавить что-то принципиально новое. Если говорить о навыке, который заключается в способности понять, что в документе является требованием, а что нет, то он нарабатывается только опытным путем, и любые теоретические знания без практики будут бесполезны.
28/36
Стандарты и методологии
Веб-доступность. Требования, которые не надо анализировать
Часть I
Даниэль Новичков
Что такое веб-доступность?
anton khoff на Flickr
Веб-доступность (от англ. web accessibility) — это свойство веб-сайта быть использованным как можно большим количеством разных пользователей. Веб-доступность может рассматриваться, как «возможность использовать» и получать результаты от использования сайта или веб-приложения. Часто термин веб-доступность применяется в контексте инвалидов и людей с ограниченными возможностями здоровья, особенно пользователей с нарушениями зрения, слуха, моторики и психическими особенностями. Однако, ошибочно думать, что вебдоступность – это про инвалидов и про сайты для инвалидов. Давайте разберем пару мифов о вебдоступности, узнаем об особенных группах пользователей, и ознакомимся с требованиями международного Руководства по обеспечению доступности веб-контента 2.0 (WCAG 2.0) Analyze IT Осень 2010&
29/36
Веб-доступность. Требования, которые не надо анализировать. Часть 1 | Даниэль Новичков
Мифы о доступности Миф 1: “Веб-доступность – это для инвалидов” Те, кто наслышан о веб-доступности небезосновательно полагают, что доступность сайта – это его доступность для инвалидов. Отчасти, это так потому что инвалиды – наиболее уязвимая к ошибкам веб-доступности группа пользователей. Кроме того, привязка веб-доступности к этой категории пользователей во многих странах является инструментом влияния на разработчиков сайтов. В некоторых странах, в отличие от России, есть специальный закон, запрещающий любую дискриминацию людей на основании их физических и психических особенностей и ограничений. Таким образом недоступный для инвалидов интернет-магазин нарушает этот закон и может понести соответствующее наказание. Так, например, американская сеть магазинов Target по решению суда заплатила Национальной Ассоциации Незрячих 6 млн. долларов за то, что их интернет-магазин был недоступен для незрячих пользователей (http:// www.sitepoint.com/blogs/2008/08/29/target-settlesaccessibility-lawsuit-for-6-million/). В России пока рано говорить о таких возможных последствиях, однако, стоит иметь в виду, что наша страна в ближайшее время ратифицирует Конвенцию о правах инвалидов, которая предъявляет требования к доступности для инвалидов в том числе и веб-сайтов. Analyze IT Осень 2010&
Вернемся к мифу: “Веб-доступность – это для инвалидов”. Оказывается, оптимизация вебдоступности сайта сделает его доступным для пользователей со всеми видами ограничений, включая ограничения по здоровью, технические и контекстные ограничения: · пользователей в очках и линзах; · пользователей, кому за тридцать, с этого возраста начинаются необратимые процессы старения; · пожилых пользователей; · начинающих пользователей; · пользователей с низкоскоростным доступом в Интернет; · пользователей мобильного интернета; · пользователей разных операционных систем и браузеров; Вы можете продолжить список, вспомнив свои ограничения или ограничения своих близких. Например, это могут быть трудности с различением цветов, усталость глаз в конце рабочего дня, нестандартное разрешение нетбука, и т.д.
Миф 2: “Среди наших пользователей нет инвалидов...” Этот ответ я слышу от всех заказчиков, которым предлагаю провести оценку доступности сайта. По оценкам ООН, каждый десятый человек на планете имеет инвалидность. Согласно официальной статистике, в России проживает около 10 млн инвалидов, а по оценке Агентства социальной информации — не менее 15 млн. Говоря о том, что среди ваших пользователей нет инвалидов и вы ничего для них не собираетесь делать, вы отказываетесь от, соответственно, 15 млн пользователей и... покупателей. Однако даже если это правда, и среди ваших пользователей нет и никогда не будет ни одного инвалида, то вернитесь к описанию Мифа 1: “Веб-доступность – это для инвалидов” и задайте себе еще раз вопрос, стоит ли вкладываться в улучшение веб-доступности вашего сайта.
Американская сеть магазинов Target по решению суда заплатила Национальной Ассоциации Незрячих 6 млн. долларов за то, что их интернетмагазин был недоступен для незрячих пользователей 30/36
Веб-доступность. Требования, которые не надо анализировать. Часть 1 | Даниэль Новичков
Человеческие способности и их ограничения В целом человеческие способности безграничны. В контексте использования Интернета, нам, однако, приходится учитывать, что все пользователи разные, у некоторых из них есть ограничения или особенности. Среди пользователей Интернета есть такие, которые “разнее” других. Мы уже знаем, что ограничения бывают по здоровью, технические и контекстные. С техническими и контекстными вы, как аналитики, сможете разобраться самостоятельно, а вот про ограничения по здоровью я вам расскажу.
Незрячие пользователи
Слабовидящие пользователи
Среди незрячих людей многие активно пользуются Интернетом (только в России по оценкам экспертов их около 12 тысяч). Их особенность лишь в том, что они не видят картинок. Все остальное они “видят” при помощи специального программного обеспечения, которое зачитывает вслух весь контент страниц, или при помощи так называемого Брайлевского дисплея, который отображает шрифтом Брайля все содержимое сайта. То есть, для незрячих доступно все содержимое в текстовом или аудио виде.
Экран компьютера - не бумага. Он менее контрастный, с него сложнее читать, глаза быстрее устают, снижается работоспособность. Чем сложнее воспринимается сверстанный текст, тем хуже. Чем больше отвлекающих, ярких, движущихся элементов - тем сложнее работать в Интернете слабовидящим пользователям. К ним относятся все, кто уже носит очки или линзы, кто сделал операцию по коррекции зрения, а также все те, кому за 30, возраст, когда начинаются необратимые процессы старения. Полагаю, большинство читателей впервые посмотрели сейчас на себя, как на людей с ограниченными возможностями.
Пользователи с нарушениями двигательных функций
Tampaempire на Flickr
Эта группа пользователей все видит и все слышит, но не может в полной мере управлять контентом, поскольку часто не может справиться со сложнейшим манипулятором типа компьютерная мышь. Не смейтесь, это действительно довольно сложно. Посмотрите на человека, который только начинает осваивать компьютер, особенно, если этот человек в возрасте. Для людей с диагнозом ДЦП (Детский церебральный паралич) мышь не существует, как, впрочем, и для всех незрячих пользователей (они же не видят ни курсора, ни границ экрана). Для таких пользователей необходимо предусмотреть возможность полного управления всем контентом и его функциональностью лишь при помощи одной клавиатуры. Analyze IT Осень 2010&
31/36
Веб-доступность. Требования, которые не надо анализировать. Часть 1 | Даниэль Новичков
Пользователи с культурными и языковыми особенностями В России все больше появляется людей, у которых русский язык не родной. В США, например, многие сайты имеют отдельные испаноязычные версии, поскольку в стране проживает около 35 миллионов людей, чьим родным языком является испанский. В странах, где официальных государственных языков более одного, некоторые сайты, например, сайты госучереждений, обязаны быть переведены на все официальные языки.
Слабослышащие и глухие пользователи Для этих пользователей недоступным является аудиоконтент. Для них необходима текстовая версия аудиофайлов или видеофайлов с аудиорядом, или субтитры и сурдоперевод.
Кстати, использование манипулятора типа «мышь» замедляет работу на компьютере также и у людей «без ограничений». «Мышь» отвлекает от работы с текстом, вы постоянно перемещаете руку и свое внимание с экрана на «мышь», и обратно. Освойте «горячие клавиши» и «слепую печать» и ваша продуктивность повысится в разы
Пожилые пользователи Пожилые пользователи, как мы уже говорили, сложнее осваивают управление с помощью «мыши», медленнее осваивают новые технологии, теряются на обновленных сайтах, хуже видят и меньше времени могут работать за компьютером.
Пользователи с психическими и особенностями восприятия К пользователям с такими особенностями можно отнести в первую очередь людей, страдающих эпилепсией. Известны случаи приступов эпилепсии при просмотре анимированных изображений на экранах мониторов и телевизоров. Громким скандалом обернулся новый анимированный логотип Олимпиады 2012 в Лондоне. Организаторам даже пришлось внести в него изменения после того, как несколько человек обратилось за медицинской помощью по причине эпилептического приступа, вызванного этим логотипом. При разработке веб-контента необходимо учитывать и психические особенности потенциальных пользователей.
Комбинированные ограничения Ну и наконец, существуют разные комбинации перечисленных категорий пользователей, например, слепоглухие пользователи компьютера… Эти люди совершают подвиг каждый день и нам, людям условно без ограничений стоило бы у них поучиться в преодолении жизненных трудностей, постановке и выполнению задач таких, как улучшение доступности сайтов.
Analyze IT Осень 2010&
32/36
Веб-доступность. Требования, которые не надо анализировать. Часть 1 | Даниэль Новичков
Зачем бизнесу доступность? Полагаю, что не все в работе бизнес-аналитика зависит от него лично, а потому, если в предыдущих параграфах мне удалось убедить вас в правильности и полезности оптимизации доступности веб-сайта, то удасться ли вам убедить начальство в необходимости заниматься вопросами доступности? Для облегчения вашей задачи предложу свои соображения дополнительных выгод для бизнеса в улучшении доступности.
Увеличение аудитории покупателей Улучшив доступность своего сайта вы автоматически увеличиваете его аудиторию на минимум 15 000 000 человек. Считается, что инвалиды неинтересная с точки зрения покупательской способности категория. Однако, что-то же они покупают. И покупать будут все больше и больше по мере компьютеризации и интернетизации страны. Если ваш сайт или услуги недоступны, а у ваших конкурентов доступны, то 15 млн человек потратят свои небольшие пенсии у них, а не у вас. Например в Англии соообщество людей с ограничениями располагает совокупным доходом в 50 млрд фунтов стерлингов. У нас, посчитаем очень грубо, минимальная пенсия по инвалидности составляет 3000 рублей. Умножим на 15 млн, получаем 45 миллиардов рублей. Добавим сюда пенсионеров по старости около 30 млн человек, которые с 2010 года будут получать пенсию не меньше 10 000 рублей, что составит 300 миллиардов рублей в год. Итого, не предприняв минимальных усилий по улучшению доступности вашего сайта вы лишаете себя возможности побороться за приз в минимум 345 миллиардов рублей, которые будут потрачены в любом случае. Не у вас, потому что ваши услуги для них недоступны.
включая мобильные устройства и телефоны, ВебТВ, различные браузеры, включая такие нестандартные как голосовые и скринридеры.
Ускоренная загрузка страниц Опять же использование CSS оптимизирует скорость загрузки ваших страниц по сравнению с табличной версткой. Сократится вес файлов, что сократит расходы тех пользователей у кого платный трафик.
Положительный PR эффект К сожалению, делать бизнес с инвалидами и для инвалидов в нашей стране пока дело не то что не завидное, но даже в чем-то предосудительное. Однако вспомните о том, как поступили инвалиды с магазином Target и о скорой ратификации Конвенции о правах инвалидов, и вы поймете, что рано или поздно и в нашей стране будет выгодно работать с покупателями с ограниченными возможностями.
Кроссплатформенная и кроссбраузерная совместимость Улучшив доступность вашего сайта, вы оптимизируете его совместимость с различными технологиями доступа в Интернет. Использование CSS и семантической верстки, что является одним из основных условий вебдоступности, сделает ваш сайт доступным для различных систем
Analyze IT Осень 2010&
33/36
Веб-доступность. Требования, которые не надо анализировать. Часть 1 | Даниэль Новичков
Поисковая оптимизация Вы не поверите, но все сайты в мире стали сильно доступнее благодаря оптимизаторам. Поисковые системы любят CSS сайты и склонны их выводить повыше в выдаче. Вообще многие методы внутренней оптимизации сайтов являются автоматически методами улучшения доступности сайта.
Оптимизация поддержки сайта Внесение изменений в сайт построенный на CSS в разы проще и не требует много времени, в отличие от сайтов построенных на таблицах.
Оптимизация вывода страницы на печать Если пользователь захочет распечатать страницу вашего сайта, то будет вызван альтернативный CSS документ, который задаст специальные параметры для вывода на печать только логотипа и контента страницы, убрав все остальное ненужное, как то навигация и прочие элементы оформления. Мелочь, а пользователю приятно. А довольный пользователь – это готовый покупатель.
Соответствие нормам закона Еще раз напомню о скорой ратификации Конвенции о правах инвалидов, а также о ГОСТе Р 52872-2007 "Интернет-ресурсы. Требования доступности для инвалидов по зрению", и Приказе Министерства экономического развития РФ от 16 ноября 2009 г. N 470 "О Требованиях к технологическим, программным и лингвистическим средствам обеспечения пользования официальными сайтами федеральных органов исполнительной,власти", которые уже сегодня описывают требования веб-доступности Продолжение статьи о требованиях международного Руководства по обеспечению доступности веб-контента 2.0 (WCAG 2.0) читайте в следующем выпуске номера...
Analyze IT Осень 2010&
34/36
Аналитики шутят
Анекдоты в тему Шерлок Холмс и доктор Ватсон отправились в поход, установили палатку и уснули. Несколько часов спустя Холмс будит своего верного друга. - Ватсон, посмотрите на небо и скажите, что вы видите. - Я вижу миллионы звезд, - отвечает Ватсон. - О чем это Вам говорит? - Астрономически, это говорит мне, о том, что существуют миллионы галактик и, возможно, миллиарды планет. Астрологически, это говорит мне о том, что Сатурн находится в созвездии Льва. Приблизительное время сейчас 3:15. Теологически, очевидно, Господь всемогущ, и мы малы и незначительны. Метеорологически, кажется, завтра будет прекрасный день. - О чем это говорит Вам, Холмс? Холмс помолчал, потом говорит. - Ватсон, вы идиот, кто-то украл нашу палатку. Шерлок Холмс и доктор Ватсон путешествуют по пустыне на воздушном шаре. Вокруг не так много ориентиров, так что в конце концов, они заблудились. К счастью, пролетая на небольшой высоте, они видят человека. Холмс кричит: "Сэр, не могли бы вы мне сказать, где мы находимся?" Человек смотрит вверх, задумывается на мгновение, а потом отвечает: "Вы, господа, в воздушном шаре! " В этот момент порыв ветра поднимает шар и уносит его. Холмс поворачивается к Ватсону и спрашивает: - Мой друг, ты знаешь, кто этот человек? - Нет, Холмс, конечно, нет - Он математик! - Холмс, это невероятно! Но как вы догадались? - Это очень просто, Ватсон. Во-первых, человек думал, прежде чем дать нам ответ. Во-вторых, его ответ был абсолютно правильным. И втретьих, ответ который он дал нам не имеет никакого практического применения!
Analyze IT Осень 2010&
35/36
Аналитики шутят
Подписка и написание статей
Analyze IT
Журнал об анализе в IT
Друзья, вот и подошел к концу очередной выпуск нашего журнала. Надеемся, что он оправдал ваши ожидания, а время, потраченное на его прочтение, окупится с лихвой. Будем рады встретить вас на страницах следующих номеров. А если вы хотите первыми узнавать о новых выпусках, то можете подписаться на рассылку журнала, отправив письмо по адресу analyzeit.journal@gmail.com с темой Subscribe
Кроме того, если по прочтении журнала у вас возникло желание поделиться своими знаниями и опытом с коллегами, приглашаем вас к сотрудничеству в качестве авторов новых статей. Для этого вам необходимо отправить электронное письмо по адресу analyzeit.journal@gmail.com с темой Article. Мы будем рады каждому!
Подписаться
Отправить статью
В следующем номере: Алексей Шемис
Теоретические аспекты выявления требований Виталий Григораш
Рассказ о методах выявления требований из существующих систем Barbara Davis (Перевод: Эдуард Гелиаскаров)
5 критических шагов, которые пропускают при выявлении требований: Что не делают бизнес-аналитики? Ирина Векленко
Анкетирование vs. Интервьюирование
Analyze IT Осень 2010&
36/36