Решения Visure


Поддержка
Логин
Начните бесплатную пробную версию
Советы Управление требованиями
Список блогов

Советы и лучшие практики для лучшего управления требованиями

Блог | 17 мин чтения
Автор администратора

Содержание

Что означают «лучшие практики» в управлении требованиями?

Мне так интересно, что все говорят о желании пройти обучение в «лучшие практики». Этот термин часто используется для обозначения того типа консультаций, которые мы также можем предоставить. Что это на самом деле означает? Я считаю, что все мы питаемся мифом о том, что передовой опыт может быть основой для обучения людей. Лучшие практики не обучены, у них есть опыт.

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

Так что же нам делать? Лучшие практики начинаются с нашего личного опыта. Все книги, которые вы подбираете и читаете по лучшим практикам, рассказывают о личном опыте автора в какой-то области, будь то варианты использования, выявление требований, системная инженерия, тестирование и т. Д. В какой-то момент организация решает, что ей нужен последовательный процесс. по всей организации. Для этого есть много веских причин. Таким образом, формируется группа для разработки процесса, отражающего эти передовые практики. Поскольку в группе много лучших практик, угадайте, кто обычно побеждает? Самый сильный и самый плодовитый. И в результате передовой опыт обычно приводит к компромиссу между группой передового опыта и теми в организации, которые выполняют эту роль. Исследования показывают, что на то, чтобы отладить этот процесс во всей организации, требуется около пяти лет. Затем появляются консультанты, которые замечают эту практику. Они могут видеть возможности для бизнеса и поэтому отстаивают методы, которые приведут к большему бизнесу для них. Они начинают появляться на конференциях и торговых выставках, рекламируя эти методы и пишя книги. (Думать о Гибкий подход.) Поскольку они ищут бизнес, они сосредоточены на методах, которые принесут им наибольший доход. Мы всегда находимся в поиске передового опыта, поэтому нам не нужно знать, как часто он работает, просто нужно знать, что он CAN Работа. И поэтому мы продолжаем распространять эту практику по всей организации, надеясь реализовать все преимущества, о которых говорилось на протяжении многих лет.

Мы должны помнить, что лучшие практики основаны на ретроспективе. Лучшие практики для вашей работы разрабатываются по мере того, как вы узнали о ней. Мы, безусловно, можем учиться друг у друга. Дело не в этом. Дело в том, что нам нужно основывать свои лучшие практики в первую очередь на собственном практическом опыте. Мы должны разобраться в том, как применять передовой опыт к нашей работе и в наших организациях. Просто не принимайте передовой опыт, потому что кто-то написал об этом книгу или рассказал об этом на конференции. Изучите практику и определите среду, в которой они воспитывались. Сравнима ли эта среда с той, в которой вы находитесь сегодня? Часто между ними мало общего. Выберите лакомые кусочки из лучших практик, которые применимы к вам и вашей работе и принесут вам реальную пользу. Начните с небольших изменений и развивайте практику, применяемую в вашей организации. Знайте, где он преуспел, а где потерпел неудачу, и извлекайте уроки из этого. Помните, что если у вас есть сильные и многочисленные противники практики, вам понадобится кто-то с практическим пониманием этой практики, чтобы помочь противникам увидеть, как эта практика может им помочь. Слушайте их и решайте их проблемы. Не игнорируйте их и не надейтесь, что они уйдут. Они не будут.

Другими словами, просто произнесение слов «наилучшая практика» не означает, что это будет наилучшая практика для вас.

Как улучшить определение требований?

Каждый раз, когда вносятся изменения в процесс или инструменты которые используются для поддержки процесса, есть кривая обучения, которая повлияет на время, необходимое для выполнения этого процесса. Когда вы начнете думать об улучшении процесса определения требований, имейте в виду, что это изменение потребует усилий. В большинстве случаев производительность снижается по мере того, как работа начинает прогрессировать. Это уменьшение часто называют «J-кривой». Когда пользователи пытаются изменить способ выполнения конкретной задачи, они достигают точки, когда они чувствуют, что внести изменения просто слишком сложно. Здесь возникает соблазн вернуться к старому способу работы, просто чтобы выполнить задачу. Без плана преодоления этого препятствия многие организации не достигают своей цели - внести это изменение. Эта проблема актуальна как для процессов, так и для инструментов. Существуют две стратегии, которые могут ускорить внедрение навыков или инструментов.

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

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

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

Подумайте о простом изменении процесса определения требований. На каких экспертов вы можете положиться внутри компании? Вам нужна внешняя помощь для обучения и / или наставничества? Куда вы пойдете для обучения и наставничества? Хорошо ли документирован ваш процесс сегодня или вы начинаете с нуля? Каков ваш план для достижения успеха (глубина, широта, и то и другое)? Каковы сроки изменения?

«Безумие повторяет одно и то же снова и снова и ожидает другого результата». (Альберт Эйнштейн) Если вы так считаете, начните вносить изменения, которые принесут вам желаемые результаты.

Советы по сбору требований

Если вы берете интервью у пользователей и в основном говорите «Кошелек или жизнь - дайте мне несколько хороших требований», угадайте, что вы получите? Вы получите массу вещей, которые хотели бы видеть пользователи. Некоторые из них будут важны для вас, а некоторые - нет. Вам нужно будет отсортировать все эти потребности и отсортировать их по категориям. Обычно мы называем эти категории функциями. Некоторые из этих функций будут уместны для проекта, а некоторые нет. Итак, если вы начинаете собирать требования, почему бы не сосредоточиться на задаваемых вами вопросах? Проведите небольшое исследование и изучите любую доступную информацию, имеющую отношение к системе. Определите конечных пользователей (вам не нужно обманывать или угощать во всем подразделении, сосредоточьтесь на паре улиц, где получают действительно хорошие угощения) и назначьте встречи с ними. 

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

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

В конце проекта, вернемся к тому, что произошло. Мы могли бы спросить если мы пошли по правильным улицам, если мы следовали процессу или по какой-то причине отклонились, получили ли мы столько конфет, сколько ожидали? Что хорошо сработало? Какие изменения можно внести, чтобы улучшить процесс? Получили ли мы ожидаемые конечные результаты? Довольны ли пользователи продуктом?

3 совета по обучению вашей команды управлению требованиями

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

Предлагаю подумать о тренировке нашей команды. Давайте перестанем думать, что все мы просто «умеем делать свою работу». Это неправда. Мы можем научиться играть эту пьесу самостоятельно. Я бы посоветовал вместо пяти лет у меня ушло бы десять лет самостоятельно. То же самое и с нашими инженерами по требованиям и аналитиками. Мы можем позволить им учиться самостоятельно. Или мы можем дать им некоторое обучение, наставничество и время для практики.

Конечно, ключом к выполнению этой работы (без каламбура) является определение определенного процесса, который мы используем для обучения наших аналитиков. Раньше я ненавидел это слово «процесс», но оно важно. Вот несколько советов, как быстро превратить ваших новых аналитиков требований в экспертов-аналитиков.

  1. Проведите обучение ваших аналитиков по вашему конкретному процессу, используя ваши требования и результаты, чтобы обучение было более реальным. Общие классы, посвященные определению требований и управлению, хороши, но они должны соответствовать процессам, которым вы следуете в своей организации. Если вы работаете с внешним консультантом, ожидайте, что вам потребуются некоторые усилия по настройке обучения, но они окупятся.
  2. Назначьте наставника вашим новым аналитикам. Пусть кто-то, кто «там уже делал это» и имеет раны и шрамы, подтверждающие это, поможет новому аналитику и покажет ему веревки. Это поможет избавиться от мышления «племенного знания». Позвольте им помогать в сессиях сбора информации, просматривать документы с требованиями вместе с аналитиком и быть для них ресурсом. 
  3. Пусть аналитик практикует. Это может показаться не слишком практичным, но не начинайте нового аналитика в проекте, который имеет решающее значение для компании, или в проекте, вокруг которого так много разногласий и споров, что будет трудно двигаться вперед. Позвольте им «попрактиковаться» в простом и хорошо понятном проекте, чтобы они намочили ноги.
3 совета по обучению вашей команды управлению требованиями

7 советов по написанию лучших требований

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

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

Я считаю, что здесь нужно идти на компромисс. 

Вот несколько советов, которые помогут восполнить этот пробел.

  1. Пишите активным голосом, убедившись, что один из актеров является субъектом каждого предложения.
  2. Убедитесь, что каждое предложение является полным и грамматически правильным предложением с подлежащим, глаголом и сказуемым..
  3. Четко укажите, какая информация передается между участниками.
  4. Поддерживайте постоянный уровень детализации. Например, для требований пользователя конечный пользователь должен быть темой каждого предложения. Что касается системных требований, система должна быть предметом каждого предложения.
  5. Каждое требование должно описывать четкие критерии успеха. Например, «Пользователь должен иметь возможность просматривать отчет журнала аудита».
  6. В каждом требовании должно быть указано одно действие и цель. Остерегайтесь чрезмерного использования «и» и «или». Например, «Если последняя пятница месяца и платеж должен быть произведен 31-го числа, а 31-е - последняя пятница месяца, то отправка платежа в этот день после 6:XNUMX по восточному времени приведет к просрочке платежа» . Я призываю вас понять это!
  7. В требовании не должно быть исключения. Например, «Система должна определить количество попыток входа в систему, кроме случаев, когда пользователь явно ввел неправильное имя пользователя».

4 совета, которые помогут вам справиться со сложными требованиями клиентов

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

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

Итак, давайте рассмотрим этот простой запрос на удобную для пользователя систему. Вот некоторые из проблем.

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

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

  1.  У некоторых прототипирование экранов и показ их пользователю. Спросите их конкретно, считают ли они их удобными для пользователя. Затем запишите аспекты экранов в набор требований к пользовательскому интерфейсу.
  2. Создайте собственное определение удобного для пользователя. Определите критерии и используйте их для определения ваших пользовательских приемочных тестов. Предоставьте их клиенту для ознакомления.
  3. Продолжайте добиваться своего понимания проблемы.  Не бойтесь задавать вопросы и вникнуть в настоящую причину требований заказчика.
  4. Убедитесь, что у вас есть четкие критерии для измерения требований. Без него вы никогда не пройдете требование в глазах Заказчика. А без него требование вообще бесполезно.
Управляйте сложными требованиями благодаря моделям данных Visure

Использование кейсов в управлении требованиями

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

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

Система отображает информацию об учетной записи Заказчику.

Клиент просматривает информацию об учетной записи.

Клиент выбирает вариант оплаты.

Система отображает Заказчику варианты оплаты.

Из этого варианта использования довольно ясно, что есть два шага системы и два шага клиента (т. Е. Пользователя). Если мы извлечем два системных оператора и, если необходимо, добавим к ним «должен», мы получим следующие два системных требования:

Система должна отображать информацию об учетной записи Заказчику.

Система должна отображать варианты оплаты для Клиента.

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

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


Не забудьте поделиться этим постом!

Поделиться на Twitter
Поделиться на Facebook
Поделиться на LinkedIn
Поделиться на WhatsApp
Поделиться по электронной почте
На главную