Downloaded 25 times
Uploaded bySQALab
Формирование требований из хотелок заказчика
Документ обсуждает важность правильного формирования и понимания требований в проектах, подчеркивая, что 75% проектов могут быть обречены без чёткого понимания потребностей заказчика. В нем приводятся статистические данные о том, как недостаточная ясность требований ведет к переработкам и неудовлетворенности сторон. Также описывается процесс анализа и документирования требований с акцентом на роль заинтересованных сторон и важность тестируемости требований.
More Related Content
Similar to Формирование требований из хотелок заказчика
Формирование требований из хотелок заказчика
- 1. Формирование требований из хотелок заказчика Сарварова Руфина ICL Services, Казань
- 2. Требования не былиплохими.. Их просто не так поняли • 75% - наш проект "обречен с самого начала." • 80% - переделываем работу больше половины времени • 78% - бизнес-заинтересованные стороны должны принимать более активное участие • 55% - бизнес-цели проекта ясны • < 20% - требования проекта соответствуют потребностям бизнеса • 23% довольны по завершению проекта
- 3. Что такое требования? • Требования определяют цель • Требования определяют потребности (проблемы) • Требования определяют решение • Требования определяют ограничения связанные с решением или проектом по его реализации
- 4. Идеальные требования Дляаналитика Для программиста Для тестировщика
- 5. Роль требований «Анализируйтетребования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum. 04.07.2010
- 6.
- 7. Мы, не испытываемголовной боли, мы только её переносчики Область проблем - Пользовательские требования Область решений - Системные требования
- 8. Область проблем ирешений недостаточное понимание существующих проблем невозможность определить границы доминирование разработчиков и исполнителей в дискуссиях о системе, ограничения свободы в выборе решения.
- 9. Ошибки Недостаточночетко определенные группы пользователей продукта Не выделены представители, заинтересованные в продукте Излишняя детализация
- 10. Систематизация заинтересованных сторон Власть 5 4 Легитимность Срочность/ Интерес 1 7 3 2 6
- 11. Высокий уровень абстракции Потребности Возможности Функции системы Язык заказчика
- 12. Сформулировать требования 1.Определить ключевые заинтересованные лица 2. Сформулировать проблему 3. Сформулировать возможности продукта 4. Документирование (описать в виде диаграмм, UC).
- 13. Оценка и проверкатребований • Является ли требование полным? • Является ли требование ясным? • Является ли требование выполнимым? • Является ли план тестирования и тесты понятным и приемлемыми? • Требования могут быть измерены? • Требования могут быть протестированы? • Могут быть связаны с архитектурой системы?
- 14.
- 15. Кейс 1 требование1 от ЗЛ1 требование2 от ЗЛ2 требование3 от ЗЛ3
- 16. Кейс 2 “нужночтобы отчёты открывались быстрей!” “нужно отрефакторить функционал Х” “почему у нас всё так медленно?” “алгоритм не работает!”
- 17. Заключение Хорошая работанад требованиями – это правильно, ПОНЯТНЕНЬКО!
Editor's Notes
- #3 75% считают, что их проекты всегда или обычно "обречены с самого начала." 80% признают, что они переделывают работу половину своего времени 78% считают, что требования бизнеса не синхронизированы с требованиями проекта и бизнес-заинтересованные стороны должны принимать более активное участие и участие в процессе требования. Нечеткие бизнес-цели: только 55% считают, что бизнес-цели своих проектов ясны им. Менее 20% считают, что требования проекта соответствуют потребностям бизнеса. Только 23% заявляют, что все довольны по завершению проекта http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/
- #4 например - «получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши» – «получить прибыль от реализации проекта» Требования определяют потребности (проблемы) – Требования заинтересованных сторон, бизнес требования • Требования определяют решение: – Процедуры, регламенты, системные требования • Требования определяют ограничения связанные с решением или проектом по его реализации: – Сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т.д.
- #5 На каждом этапе необходим свой уровень детализации требований. Естественно, что на первом этапе аналитик должен выработать общее видение продукта, что хочет заказчик. Например, если приходит заказчик и просит сделать ему халат, то задача аналитика в том, чтобы понять его боль и определить конечную цель. Заказчику нужен халат потому что ему холодно? Что он не может ходить голышом? Чтобы поддерживать некий уровень своего социального положения? В зависимости от этого аналитик может продумать различные решения – шуба, утеплённый, длинный или с инкрустацией кристаллов сваровски.
- #6 CMMI в своём гайдлайне утверждает ..
- #7 http://mandenews.blogspot.ru/2010/08/test3.html http://moodle.unitec.ac.nz/pluginfile.php/163808/mod_resource/content/0/Agreement_Certainty_Matrix_1_.pdf Cynefin framework Теперь я бы хотела познакомить вас с Cynefin фреймворком – это классификация проблем и по нему же можно классифицировать проекты. На этом слайде немного видоизменённая матрица Стейси от Brenda Zimmerman. Вам необходимо действовать в зависимости от того, где на этой матрице вы в данный момент находитесь. Высокая определённость – когда причинно-следственные связи ясны, известны методы воздействия, результаты предсказуемы Слабая определённость – причинно-следственные связи непонятны, методы решения непроверенные, результаты непредсказуемы Высокий уровень соглашения – ценности, цели, перспективы и позиции ключевых заинтересованных сторон, которые вовлечены в процесс разработки и получения ценности продукта, достаточно близки, чтобы прийти к единому соглашению и готовые идти дальше. Низкий уровень соглашения – ценности, цели, перспективы и позиции ключевых заинтересованных сторон, которые вовлечены в процесс разработки и получения ценности продукта, очень далеки, трудно прийти к соглашению и найти общий язык. Зиммерман выделяет 5 видов ситуаций: Simple характеризуется простым контейстом, ясна причинно-следственная связь и решение является прямолинейным и либо уже известно либо его можно легко найти. Резульаты предсказуемы и все понимают что и почему они делают. Пример: приготовление торта по рецепту. Менеджеры и руководители в такой ситуации прямолинейны – они диагностируют проблему, проверяют, что решение является подходящим и сосредотачиваются на точной реализации. Complicated – сложный контекст, где ключевые стороны близки к соглашению, но причинно-следственная связь не очевидна, но может быть выяснена. Решение в таком случае основывается на экспертном мнении и опыте. Пример – отправить ракету на луну. Political – причинно-следственные связи ясны, но ключевые стороны далеки от согласия, лучшим решение признаётся, если все ключевые стороны согласны с ним. Пример – социальный проект по повышению уровня минимальной заработанной платы. Complex – причинно-следственные связи размыты, решения несовершенны и не могут быть выработаны заранее. Сложные проекты динамичны, согласия трудно достичь. Пример: восстановление торговли на оживлённной торговой улице Или – вырастить ребёнка. Хаотичный – существуют ситуации когда контекст является турбулентным, заинтересованные стороны сами по себе и возможно даже настроены против друг-друга. Выработанные решения могут решить проблему только сиеминутно. Пример – оказание помощи после землетрясения. В данном ситуации руководители должны стремиться вовлечь все заинтересованные стороны, создать коммуникационные каналы и собрать как можно больше информации, чтобы выбраться из кризиса. David Snowden и Mary Boone рекомендует в таком случае иметь 2 команды – одна которая будет выводить из текущего кризиса, а вторая будет продумывать меры, которые позволят избежать подобных проблем в будущем. Наверху (0, y) будет Agile гибкая методология разработки, где требования несогласованы Внизу будет Prototyped модель, где требования согласованы, но велика неопределённость Обобщая, Простые – следуйте рецепту, инструкциям, правилам. Сложные – поиск решения, накопление опыта Политические – создайте общий язык с заказчиком Комплексные – обучение на практике Хаотичные – стабилизировать, создать возможности для улучшения ситуации
- #8 Например, в системе управления автомобильным движением: • Заинтересованные стороны (stakeholders) могут выразить проблему следующим образом: максимизация транспортного потока, при минимизации риска возникновения дорожных происшествий на пересечении дорог при минимизации стоимости обслуживания решения. • Системные инженеры (system engineers) могут предложить различные решения этой проблемы: разного рода светофоры; организация кругового движения на определенных участках дороги; а может быть и мост в качестве наиболее подходящего решения в рамках существующих ограничений, стоимости разработки и последующего обслуживания. • Архитекторы (designers) будут разрабатывать проект моста с учетом существующих физических ограничений, налагаемых окружающей средой. Область решений, эта та область, в которой инженеры задействуют все свои способности и изобретательность, пытаясь решить обозначенные проблемы. Основное отличие области решений от области проблем состоит в том, что разработка требований в области решений начинается с набора четко определенных требований, а разработка требований в области проблем стартует с нечеткой цели или размытого списка общих пожеланий. Очень часто заинтересованные стороны выражают проблему уже в терминах предопределенного решения. Это привносит дополнительную работу аналитику, поскольку теперь ему необходимо анализировать является ли предлагаемое (а фактически, требуемое) решение наилучшим или это всего лишь лишнее ограничение (недоразумение). (как в случае с халатом) Например, заказчики, формулируя проблемы, начинают с того, что им необходимы светофоры. Исполнитель же, в свою очередь, задавая вопросы, лишь потом выясняет истинные цели - необходимо увеличение пропускной способности транспортного потока при минимизации риска для водителей и пешеходов, что и является формулировкой проблемы независимой от ее конкретной реализации. После получения такой формулировки проблемы становятся понятными причины выбора последующих решений, которые, возможно, будут подтверждены при помощи моделирования, которое, в свою очередь, будет являться основанием для более детальных спецификаций абстрактного описания решения. В случае покупки готовой системы необходимо принять решение, что использовать в качестве критерия оценки систем - область проблем (пользовательские требования) или область решения (системные требования). Зачастую решение известно заранее и тогда имеет смысл покупать систему, удовлетворяющую системным требованиям. Однако формулировка проблем в чистом виде дает большие преимущества, даже если основой для выбора приобретаемой системы являются системные требования.
- #9 Отсутствие четкого разделения между проблемами и решениями, может привести к следующим негативным последствиям:. • недостаточное понимание существующих проблем;. • невозможность определить границы (масштаб) системы и понять какой функционал должен в нее входить, а какой нет;. • доминирование разработчиков и исполнителей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации, а не в формулировках проблем;. • невозможность нахождения наилучшего решения из-за ограничений свободы в выборе решения.
- #10 Основными ошибками, допускаемыми на этапе первичного сбора требований, являются: Недостаточно четко определенные группы пользователей продукта Не выделены представители, заинтересованные в продукте Излишняя детализация Чтобы не допустить этих ошибок можно дать несколько рекомендаций: • Разделите пользователей продукта на категории в соответствии с их ролями • В каждой группе выберите одного - двух человек в качестве представителей интересов группы. Выбранные люди должны быть лидерами (пусть даже и неформальными) в своей группе, четко представлять бизнес процессы, в которых участвует группа и лояльно настроенных по отношению к проекту создания и внедрения разрабатываемой системы. • Не пытайтесь сразу и досконально описать все требования. Это приведет лишь к затягиванию работ. Требования должны прорабатываться и детализироваться в ходе проекта. • Каждому требованию присваивайте приоритетность. Это позволит реализовывать в первую очередь самые необходимые требования, откладывая реализацию второстепенных возможностей на более поздний срок.
- #11 Итак, давайте посмотрим, как выделять и классифицировать группы заинтересованных сторон. RONALD K. MITCHELL выделяет 7 типов заинтересованных сторон и разделяет их по степени влияния и наличия власти. Например, есть группа лиц, которые заинтересованы в том, чтобы уже скорей всё сделали и запустили. Но у них нет власти, не они выделяют бюджет и не они имеют право принимать решения. Это, как правило, внедренцы и те, кому отсутствие продукта доставляет боли. Итак, первая группа это те, кто платит, кто решает – да или нет. 2 - юристы\законники 3 – запросы этой группы отправлять «когда-нибудь потом обязательно» 4 – вовлекать, держать в курсе 5 – это дополнительная возможность. Договариваться о реализации их потребностей через спонсора. 6 – конечные пользователи 7 – нужно заинтересовать эту категорию тем, что интересует 6-ю Аналитик должен прислушиваться к группам 4,5,7 2,4,7,6,5 – проинтервьюировать Помните мы уже с вами обсуждали, что нужно найти истинную цель и желание. Так вот это лучше всего можно выяснять он-сайд, в курилках, в буфете с представителями групп 2, 4, 6, 5. Они вам могут рассказать много интересного. Например, Нонна Анатольевна может рассказать, что на самом деле проект провальный и просто текушего менеджера хотят подставить как мальчика для битья. Или, вы можете выяснить, что на самом деле цель – попилить по-лучше бюджет. Или – отчитаться перед другим руководством. Как ещё можно выявлять требования и проблемы заказчика? Семинары, опросы, брейн-штормы, командировки на место. R Mitchell, (B) and (D) Agle Wood, 1997, to the theory of stakeholder identification: define principle of who and what really matters. Academy of Management Review, 22 (4)
- #12 Итак, вот мы выделили и классифицировали ключевые стороны. Далее мы определяем проблемы заказчика и заинтересованных сторон и соотносим область проблем с областью решения. И тут важно на языке заказчика донести ему наше видение. Для того можно использовать UC диаграммы, схемы или просто описание текстом. Главное – чтобы заказчику было понятно. Возможности, которые мы описали мы можем в функциональных спецификациях для себя уже писать в любом удобном нам виде, но высокий уровень заказчика должен быть на языке заказчика.
- #13 2. Сформулировать проблему можно по результатам интервью, проверить её лучше всего в кулуарах и курилках. В формулировке проблемы должно быть: Проблема Затрагивает В результате чего Успешное решение должно Сформулировать всё на языке заинтересованных сторон
- #14 Является ли требование: полным? ясным? выполнимым? Является ли план тестирования и тесты понятным и приемлемыми? Требования могут быть измерены? Требования могут быть протестированы? Могут быть выделены (т.е. связаны) с архитектурой системы?
- #15 Побеждает тот, кто больше приспособлен. Удовлетворить заказчика Подготовиться к изменениям
- #17 Это не требование – это проблема. Описать её, сформулировать область решений. Сформулировать возможности продукта и реализовать соответствующие функции.