Формулировка проблемы - Википедия - Problem statement

А постановка задачи - это краткое описание проблемы, которую необходимо решить, или условия, которое необходимо улучшить. Он определяет разрыв между текущим (проблемным) состоянием и желаемым (целевым) состоянием процесса или продукта. Сосредоточившись на фактах, формулировка проблемы должна быть разработана таким образом, чтобы Пять Вт. Первым условием решения проблемы является понимание проблемы, что может быть сделано путем ее постановки.[1]

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

Цель

Основная цель постановки проблемы - выявить и объяснить проблему. Это включает в себя описание существующей среды, где возникает проблема и какое влияние она оказывает на пользователей, финансы и вспомогательную деятельность.[3] Кроме того, формулировка проблемы используется для объяснения того, как выглядит ожидаемая среда. Определение желаемого состояния дает общее представление о процессе или продукте. Он проясняет цель запуска проекта улучшения и цели, которые он призван достичь.[4]

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

На формулировку проблемы ссылаются на протяжении всего проекта, чтобы сосредоточить внимание проектной группы и убедиться, что они не сбиваются с пути. В конце проекта его повторно посещают, чтобы подтвердить, что внедренное решение действительно решает проблему. Четко сформулированная постановка задачи также может помочь в выполнении анализ причин чтобы понять, почему возникла проблема, и принять меры для предотвращения ее возникновения в будущем.[2]

Важно отметить, что постановка задачи нет определить решение или методы достижения решения. Постановка проблемы просто признает разрыв между состоянием проблемы и цели. Можно сказать, что «хорошо сформулированная проблема решена наполовину».[4] Однако часто существует несколько жизнеспособных решений проблемы. Только после того, как формулировка проблемы написана и согласована, следует обсудить решение (я) и определить итоговый курс действий.[6]

Определение проблемы

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

Процесс определения проблемы часто является коллективным. Он начинается со встречи с заинтересованными сторонами, клиентами и / или пользователями, затронутыми проблемой (если возможно), и изучения их болевых точек.[8] Поскольку люди часто борются с эффективным сообщением о своих проблемах, особенно кому-то вне процесса, полезно задавать серию вопросов «почему» до тех пор, пока не будет выявлена ​​основная причина. Этот метод, известный как «5 Почему ”, Помогает разобраться в основной проблеме, поскольку многие пережитые разочарования могут быть просто симптомами реальной проблемы.[6] Задавая эти дополнительные вопросы, а также перефразируя сказанное заинтересованной стороной, вы демонстрируете определенную степень сочувствия и понимания проблемы.[5]

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

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

Написание постановки задачи

Формулировка проблемы будет использована для получения поддержки проекта и одобрения заинтересованных сторон. По сути, он должен быть ориентирован на действия.[3] Что еще более важно, формулировка проблемы должна быть написана четко и точно, чтобы обеспечить успешные результаты. Плохо составленная или неправильная формулировка проблемы приведет к ошибочному решению, а также к потере времени, денег и ресурсов.[1]

Есть несколько основных элементов, которые можно встроить в каждую постановку проблемы, чтобы снизить риск неудачи проекта. Во-первых, постановка проблемы должна быть сосредоточена на конечный пользователь. Распространенная ошибка - сосредоточение внимания на том, «как» проблема будет решена, а не на текущем пробеле. Во-вторых, формулировка проблемы не должна быть слишком широкой. Преимущество использования подхода «5 причин» состоит в том, что он позволяет избежать чрезмерной простоты, предоставляя детали, необходимые для понимания проблемы и разработки соответствующего решения. Наконец, формулировка проблемы не должна быть слишком узкой. Предвзятость решения подавляет творческий потенциал, возникающий при мозговой штурм решение, которое может привести к неоптимальным результатам для пользователя.[8]

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

  1. ИДЕАЛ: Этот раздел используется для описания желаемого или «будущего» состояния процесса или продукта. Он определяет цели заинтересованных сторон и клиентов, а также помогает в определении объема. В целом этот раздел должен проиллюстрировать, как будет выглядеть ожидаемая среда после реализации решения.
  2. РЕАЛЬНОСТЬ: Этот раздел используется для описания текущего или «как есть» состояния процесса или продукта. Он объясняет болевые точки, выраженные заинтересованными сторонами и клиентами. Он также должен включать понимание и опыт команды проекта и экспертов в предметной области, предоставленные в ходе анализа проблемы.
  3. ПОСЛЕДСТВИЯ: Этот раздел используется для описания воздействия на бизнес, если проблема не будет устранена или улучшена. Сюда входят затраты, связанные с потерей денег, времени, производительности, конкурентного преимущества и т. Д. Величина этих эффектов также поможет определить приоритетность проекта.
  4. ПРЕДЛОЖЕНИЕ: Этот раздел используется для описания возможных решений. После того, как разделы «идеал», «реальность» и «последствия» будут завершены, поняты и утверждены, команда проекта может начать предлагать варианты решения проблемы. Он также может включать предложения заинтересованных сторон и клиентов, хотя потребуются дальнейшие обсуждения и исследования, прежде чем можно будет определить конкретный курс действий.[7]

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

Пример

Формулировки проблемы могут различаться по длине в зависимости от сложности проблемы. Ниже приводится пример простой постановки задачи для создания возможности единого входа:

ИДЕАЛ:

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

РЕАЛЬНОСТЬ:

На самом деле мы используем как минимум три приложения каждый день для выполнения своей работы. Каждое приложение защищено паролем с разными требованиями к имени пользователя и длине пароля. Срок действия паролей также истекает в разное время.

ПОСЛЕДСТВИЯ :

  • Пользователи тратят примерно 2 минуты в день на вход в несколько приложений (допустим, если есть 500 пользователей, то 500 пользователей * 2 минуты в день = 1000 минут потери производительности; 1000 минут = 16,67 часа в день * 75 долларов в час = 1250 долларов в день) .
  • Служба поддержки принимает около 6000 звонков в год для сброса забытых паролей и разблокировки учетных записей.
  • Угроза безопасности, поскольку пользователи будут продолжать писать имена пользователей и пароли на стикерах на своих столах.

ПРЕДЛОЖЕНИЕ

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

Рекомендации

  1. ^ а б Куш, Макс (июнь 2015). «Проблема постановки». Прогресс качества. 48 (6).
  2. ^ а б c Аннамалай, Нагаппан; Камаруддин, Шахрул; Азид, Исхак Абдул; Йео, Т.С. (сентябрь 2013 г.). «Важность постановки задачи в решении проблем отрасли». Прикладная механика и материалы. Цюрих. 421: 857–863. Дои:10.4028 / www.scientific.net / AMM.421.857. S2CID  60791623.
  3. ^ а б c Гайги, Крейг; ДеКарло, Нил; Уильямс, Брюс (2015). Шесть сигм для чайников. Хобокен, Нью-Джерси: Джон Уайли и сыновья. С. 76–78.
  4. ^ а б Линдстрем, Крис (2011-04-24). «Как написать описание проблемы». www.ceptara.com. Получено 2018-04-10.
  5. ^ а б Перри, Рэнди; Бэкон, Дэвид (2010). Коммерциализация отличных продуктов с дизайном для Шесть Сигм. Прентис Холл. п. 18.
  6. ^ а б Шаффер, Деб (12.07.2017). «Как написать описание проблемы». ProProject Manager. Получено 2018-04-10.
  7. ^ а б Шаффер, Дэвид (21 декабря 2015 г.). «Готовим успех бизнес-анализа». BA Times. Получено 2018-04-10.
  8. ^ а б c Уайден, Стивен (2018-04-02). «Примите следующие меры, чтобы определить проблему пользовательского интерфейса / пользовательского интерфейса и избежать случайных изменений». Forbes. Получено 2018-04-10.