Заметки консультанта

Шамрай Александр Владимирович

Правильные требования: Топ 10 ловушек

Posted by Шамрай Александр на Август 15, 2013

Перевод: Шамрай А.В.

Источник: Getting requirements right: avoiding the top 10 traps

Содержание

Не попадайтесь

Ловушка 1: расползание границ

Ловушка 2: спрашивать заказчиков, чего они хотят

Ловушка 3: неспособность адаптироваться к изменениям

Ловушка 4: неспособность эффективно общаться

Ловушка 5: нечастое общение

Ловушка 6: громоздкие документы и слишком много информации

Ловушка 7: скрытые артефакты проекта

Ловушка 8: неоднозначные требования

Ловушка 9: неспособность измерить и оценить процесс требований

Ловушка 10: изоляция ваших требований

Заключение

Не попадайтесь

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

К сожалению, ловушки требований являются общими и их влияние является значительным. В исследованиях State of the IT Union Survey изучали методы управления разработкой, которые команды применяют во избежание неприятностей или используют для решения проблемы после их обнаружения. Онлайн-опрос респондентов показывает, как часто команды разработчиков предвидят, что они могут попасть в ловушки. Они дополняют бюджеты и планы. Они изменяют первоначальную смету, чтобы соответствовать фактическим результатам. И они запрашивают дополнительные ресурсы. Рисунок 1 показывает, как команды и руководители групп будут бороться с этими ловушками…

Основные моменты

Слабое Управление требованиями приводит к несогласованным результатам проекта.

Рисунок 1. Команды разработчиков ожидают ловушки управления требованиями и преднамеренно избегают создание точных бюджетов и планов.

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

В этом документе представлены 10 общих и разрушительных ошибок, которые делают проектные команды при определении и управлении требованиями. Что более важно, он описывает, как избежать эти ловушки, чтобы получить правильные требования и разрабатывать правильный продукт вовремя и в рамках бюджета.

Основные моменты

Фиксирование бизнес-требований может контролировать расползание границ.

Ловушка 1: расползание границ

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

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

Избегание ловушки

  • Устанавливайте связи от подробных, реальных бизнес требований к возможностям продукта, которые удовлетворяют этим требованиям и обеспечивают значимость.
  • Внося изменения, фокусируйтесь на бизнес-требованиях и изменениях приоритетов.
  • Определяйте и работайте с заинтересованными сторонами заранее и часто, чтобы понять бизнес-требования, приоритеты заинтересованных сторон и воздействие на заинтересованные стороны, когда происходят изменения.

Выигрыш

Избегание расползания границ делает планирование легче, помогает сохранить нетронутыми бюджеты и помогает выдерживать проекты в соответствии с графиком. Что наиболее важно из всего этого, оно помогает получить желаемый возврат на инвестиции (ROI).

Основные моменты

Уводите обсуждение подальше от возможностей.

Спрашивайте заказчиков, какие результаты они ожидают, это поможет вам определить требования.

Ловушка 2: спрашивать заказчиков, чего они хотят

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

Избегание ловушки

  • Спросите заказчиков, почему они нуждаются в конкретном решении. Это может привести к лучшему пониманию их ожиданий и улучшить дискуссию об определенных требованиях.
  • Уводите обсуждение подальше от возможностей — спрашивайте заказчиков, что они хотят, чтобы делало программное обеспечение. Создайте отдельное обсуждение от том, как конечный продукт будет использоваться.
  • Определите правильные заинтересованные лица. Целевая аудитория или конечный пользователь могут быть не теми, кто несет ответственность за проект или инвестирует в результат. Найдите — и выслушайте — правильных пользователей, заказчиков, руководителей, которые финансируют проект, представителей правления, которые накладывают правила, проектных команд, групп поддержки и др.

Выигрыш

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

Основные моменты

Неопределенности и внешние факторы могут повлиять на требования.

Планируйте изменений для уменьшения риска.

Ловушка 3: неспособность адаптироваться к изменениям

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

Избегание ловушки

  • Ожидайте и планируйте требования, которые изменятся в процессе разработки.
  • Изменяйте приоритеты требований, основываясь на сдвиге обстоятельств таких, как бизнес потребности, значение для заказчика, оценки трудозатрат и стоимости.
  • Имейте детальный план, который вы будете дорабатывать регулярными интервалами.
  • Держите ваши заинтересованные стороны информированными о возникновении изменений — привлекайте их для определения приоритетов и обоснования.

Выигрыш

Приспосабливание и планирование изменений в требованиях проекта помогает снизить риск и снижает дорогостоящие переделки.

Основные моменты

Общайтесь с заинтересованными лицами методами, которые они могут легко понять.

Эффективная коммуникация помогает оптимизировать время и трудозатраты.

Ловушка 4: неспособность эффективно общаться

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

Избегание ловушки

  • Знайте вашу аудиторию и связывайтесь методами, которые помогут ей понять информацию. Используйте диаграммы, описания функциональности пользователей, зарисовки и раскадровки.
  • Создавайте глоссарии, шаблоны документов и формы обратной связи, которые являются четкими, краткими и просты в использовании.
  • Используйте прототипы, чтобы помочь заинтересованным сторонам визуализировать решение. Они могут дополнить текст или полностью заменить его в зависимости от необходимой степени детализации.
  • Получайте обратную связь от всех представителей заинтересованных сторон и помните, что один или два человека, как правило, наиболее активны. Не делайте ошибку, упуская обратную связь от других.
  • Всегда отвечайте на обратною связь, желательно с некоторым четким заявлением о состоянии, например, «Будет включено», «Добавить это в список пожеланий» или «Не удается выполнить это сейчас». Если вы просите мнение, признавайте его.

Выигрыш

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

Основные моменты

Заинтересованные лица часто имеют разные приоритеты.

Регулярные общение помогает поставить ценный продукт.

Ловушка 5: нечастое общение

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Когда речь заходит о документации, думайте качественно, а не количественно.

Предоставьте пользователям глоссарий, чтобы избежать путаницы.

Сфокусированная документация и обратная связь помогает повысить эффективность и точность.

Ловушка 6: громоздкие документы и слишком много информации

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

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

Избегание ловушки

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

Выигрыш

Сфокусированная документация и циклы обратной связи повысят эффективность для всех заинтересованных сторон. Снижение посторонней детализации в требованиях и трассировки увеличивает качество, сосредоточив внимание на более важной информации — отложив подробности до тех пор, пока это не станет необходимым.

Основные моменты

Создайте центральное хранилище для артефактов проекта.

Централизованное управление информацией может способствовать сотрудничеству.

Ловушка 7: скрытые артефакты проекта

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Неопределенность создает риски на следующем этапе проекта.

Отложите первый черновик и вернитесь к нему позже со свежим взглядом.

Ловушка 8: неоднозначные требования

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

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

Что вызывает неопределенность? Бедное описание, неточная информация и предположение, что аудитория понимает так же, как вы и делаете.

Избегание ловушки

  • Используйте руководство по написанию, например, Элементы Стиля Вильяма Странка Младшего и Е.Б. Уайта, которое уже давно считается авторитетным справочным материалом для четкого, понятного текста — до и во время создания требований.
  • Создайте глоссарий и убедитесь, что включен каждый акроним и технический термин.
  • Представьте, что вы пишете для студента, который только что закончил колледж, или для тех, кто недавно присоединился к компании. Не ожидайте, что аудитория будет знать каждый термин и понимать каждое понятие.
  • Дополняйте текст визуальными эффектами. Это отличный способ выразить и простую, и сложную концепцию.
  • Шагните назад. После написания любого проектного документа, закройте его на некоторое время и прочитайте позже. Свежий взгляд может выявить неоднозначности.

Выигрыш

Четкие, понятные требования являются основой вашего программного проекта.

Основные моменты

Измерения результатов позволяют непрерывно улучшать процесс.

Ловушка 9: неспособность измерить и оценить процесс требований

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

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

Избегание ловушки

  • Проводите сессии обратной связи «извлеченные уроки» в конце каждой итерации разработки или выпуска как часть процесса.
  • Также выполняйте сессии «запомненных уроков» до начала нового проекта. Поощряйте непрерывное совершенствование, вам нужно не только обобщать накопленный опыт в конце итерации или выпуска, но также усиливать эти уроки перед движением вперед.
  • Определяйте и собирайте метрики, что гарантирует ваш успех. Например, измеряйте влияние изменений на требования, покрытие тестового сценария, приоритет, стоимость и трудозатраты бизнес и требований к продукту. По мере совершенствования опыта в измерениях, вы сможете найти нужное сочетание метрик, которые позволят постоянно улучшать ваш процесс требований.

Выигрыш

Постоянные измерения выполнения проекта покажут небольшие проблемы, прежде чем они станут большими проблемами.

Основные моменты

Изменения в одном требовании могут иметь значительное влияние на артефакты ниже.

Определение и управление связями между требованиями помогает снизить риск.

Ловушка 10: изоляция ваших требований

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

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

Избегание ловушки

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

Выигрыш

Выявление и управление связями между требованиями и другими артефактами снижает риск проекта; помогает обеспечить соответствие между бизнес-требованиями, требованиями к продукту и дальнейшими результатами; и результаты будут меньше стоить в разработке.

Основные моменты

Решения IBM Rational для требований могут помочь вам избежать общих ловушек в разработке программного обеспечения.

Заключение

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

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

IBM Rational Requirements Composer, к примеру, содействует совместной работе. Это решение для определения и управления требованиями, которое идеально подходит для групп, которые хотят сосредоточиться на определении бизнес и требований к продукту и хотят иметь только основы для управления требованиями. Программное обеспечение поддерживает текстовые и визуальные методы, предназначенные для получения, выработки и проверки требований на основе сотрудничества с заинтересованными сторонами. Он также предоставляет возможности для управления сложной информацией к требованиям, а также некоторые руководства по процессу.

Программное обеспечение IBM Rational RequisitePro ® в сфере ИТ и программное обеспечение IBM Rational Doors ® в системной сфере обеспечивают трассировку и анализ влияния, который держит аналитиков, архитекторов, разработчиков и тестировщиков в соответствии потребностям бизнеса и требованиям на протяжении всего жизненного цикла поставки программного обеспечения.

Знакомство с ловушками, указанными здесь, распознавание их в вашей организации и избегание их — предпочтительно в начале проекта программного обеспечения —поможет вам не только выжить в бизнесе, но также увеличить свою долю на рынке и ROI, т.к. вы обеспечите потребности ваших заказчиков и других заинтересованных сторон; поможете группам поставки проекта увеличить их производительность, качество и повторное использование; и привлечете инновации.

Дополнительная информация

Чтобы узнать больше о решениях для требований IBM Rational для разработки программного обеспечения, обратитесь к представителю IBM или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Rational Requirements Composer software:

ibm.com/software/awdtools/rrc/

Бесплатная загрузка Rational Requirements Composer:

https://jazz.net/projects/rational-requirements-composer/

Электронный пакет лучший практик поставки программного обеспечения: Сделать больше с меньшими затратами:

ibm.com/services/forms/preLogin.do?lang=en_US&source=swg-rtl_sdekit

Топ 10 секретов поставки программного обеспечения выполняя больше с меньшими затратами:

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14139usen/RAW14139USEN.PDF

Калькулятор ROI:

ibm.com/software/rational/offerings/testing/roi/

Читайте наш блог RDM:

rationalrdm.wordpress.com

Следуйте за нами на Twitter: @RationalRDM

Стань фаном Rational Requirements Composer на Facebook:

http://www.facebook.com/home.php?#/pages/Rational-Requirements-Composer/47378244431?ref=ts

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: