تعریف مسئله

بیان مسئله شرح مختصری از موضوعی است که باید به آن پرداخته شود یا شرایطی که باید بهبود یابد و شکاف بین وضعیت (فعلی) مسئله و وضعیت (مطالبه شده) یا هدف یک فرایند یا محصول را مشخص می‌کند. با تمرکز بر واقعیات، بیانیه مسئله باید به گونه‌ای طراحی شود که پنج پرسش را مورد پردازش قرار دهد. اولین شرط حل مسئله، درک مسئله است که می‌تواند از طریق بیان مسئله انجام شود.^[۱]

بیان مشکل در بیشتر مشاغل و سازمان‌ها برای اجرای پروژه‌های بهبود فرایند به‌طور گسترده مورد استفاده قرار می‌گیرد. برای درک مسئله و تلاش برای دستیابی به یک راه‌حل، تیم پروژه از عبارت یک بیان ساده و کاملاً تعریف شده مشخص استفاده خواهد کرد. این امر همچنین بینش خاصی را در مورد مشکل برای مدیریت فراهم خواهد کرد تا آن‌ها بتوانند تصمیمات مناسب تصویب پروژه را اتخاذ کنند. به همین ترتیب، روشن بودن و بدون ابهام بودن بیان مسئله بسیار مهم است.^[۲]

هدف[ویرایش]

هدف اصلی بیان مسئله، شناسایی و توضیح مسئله است. این شامل توصیف محیط موجود، محل بروز مشکل و تأثیرات آن بر کاربران، امور مالی و فعالیتهای فرعی/جانبی است. علاوه بر این، از عبارت بیان مسئله برای توضیح محیط مورد انتظار قرار داده شده استفاده می‌شود. تعریف شرایط مطلوب دید و بینش کلی ای برای فرایند یا محصول را فراهم می‌کند؛ که این هدف را که برای تحقق آن پروژه آغاز شده و بهبود پروژه و اهدافی مشخص شده شفاف می‌کند.^[۳]

یکی دیگر از عملکردهای مهم بیان مسئله استفاده از آن به عنوان یک وسیله ارتباطی است. بیان مشکل برای Buy-in یا هم‌آفرینی افرادی که در پروژه مشارکت دارند کمک می‌کند. قبل از شروع پروژه، ذینفعان مسئله را تأیید می‌کنند و اهداف به‌طور دقیق در بیانیه مسئله شرح داده می‌شوند. پس از دریافت این تأیید، تیم پروژه آن را بررسی می‌کند تا اطمینان حاصل شود که همه موضوع مورد بحث و آنچه را که می‌خواهند انجام دهند درک می‌کنند. این امر همچنین به تعریف دامنه پروژه کمک می‌کند تا پروژه را بر روی هدف کلی متمرکز نگه‌دارد.

برای ایجاد تمرکز در تیم پروژه و تأیید این‌که آن‌ها در مسیر خود قرار دارند، در طول پروژه به بیانیه مسئله مراجعه می‌شود. در پایان پروژه، دوباره مورد بررسی قرار می‌گیرد تا تأیید شود راه حل واقعاً مشکل را حل می‌کند. یک بیان مسئله به خوبی تعریف شده همچنین می‌تواند در انجام تجزیه و تحلیل علل ریشه ای برای درک علت بروز این مشکل کمک کند و اطمینان حاصل کند که می‌توان اقداماتی را برای جلوگیری از بروز آن در آینده انجام داد.^[۲]

باید توجه داشت که این بیانیه، تعریف راه حل مشکل یا روش‌های رسیدن به راه حل نیست. بیانیه مسئله به‌طور ساده‌ای شکاف بین وضعیت مسئله و هدف را تشخیص می‌دهد. می‌توان گفت که «مسئله/مشکلی که به خوبی بیان شد، نیمه حل شده‌است».^[۳] با این حال، اغلب چند راه حل با صرفه و مناسب برای یک مسئله وجود دارد. فقط پس از نوشتن و توافق بر سر مسئله، باید راه حل(ها) مورد بحث و بررسی قرار گیرد و روند حاصله تعیین شود.^[۴]

تعریف کردن مشکل[ویرایش]

قبل از این‌که بیانیه مسئله ساخته شود، باید مشکل تعریف شود. این طبیعت بشر است که می‌خواهد هرچه زودتر کار بر روی یک راه حل را شروع کند و از تعریف مسئله واقعی که باید حل شود، غافل شود. با این حال، یک مشکل کم تعریف شده، خطر اجرای یک راه حل را که به‌طور کامل با نتایج مورد انتظار مطابقت ندارد، افزایش می‌دهد. اگر یک مسئله کاملاً درک نشود، قابل حل نیست.^[۵]

روند تعریف مسئله اغلب یک کار گروهی است. این کار با ملاقات با ذی‌نفعان، مشتریان و / یا کاربران تحت تأثیر این مسئله (در صورت امکان) و اطلاع از نکات درد آن‌ها آغاز می‌شود.^[۶] از آن‌جا که افراد معمولاً با برقراری ارتباط مؤثر مسائل خود، به ویژه به شخصی خارج از روند، دست و پنجه نرم می‌کنند، پرسیدن یک سری سؤال "چراً تا مشخص شدن استدلال اساسی مفید است. این روش که به عنوان " ۵ چرا " شناخته می‌شود، کمک می‌کند تا هسته و مرکز مشکل core اصلی بررسی شود زیرا بسیاری از تجربیات ناامیدی می‌توانند صرفاً علائم مسئله اصلی باشند.^[۴] پرسیدن این سوالات اضافی و همچنین بیان جمله‌هایی که طرف ذی‌نفع گفته‌است، نشان دهنده میزان همدلی و درک مسئله است.

اطلاعات جمع‌آوری شده از این مصاحبه‌های اولیه تنها بخشی از تجزیه و تحلیل مسئله است. بسیاری از اوقات این مشکل به چندین منطقه یا کارکرد (دستگاه) گسترش می‌یابد که ذی‌نفعان، مشتریان و کاربران از آن‌ها بی‌اطلاع هستند. آن‌ها همچنین ممکن است با آنچه در واقعیت سطحی اتفاق می‌افتد آشنا باشند اما لزوماً علت ریشه‌ای اصلی آن نیست؛ بنابراین، جمع‌آوری دانش، اطلاعات و بینش از اعضای تیم پروژه و کارشناسان موضوعی در مورد مسئله به همان اندازه ضروری است.^[۶] همچنین ممکن است نیاز به مشاوره با مواد تحقیقاتی اضافی، از جمله دستورالعمل‌های کار، کتاب‌چه راهنمای کاربر، مشخصات محصول، نمودار گردش کار و برنامه‌های قبلی پروژه باشد. مانند اکثر مراحل دیگر در پروژه بهبود فرایند، تعریف مشکل اغلب تکراری است زیرا ممکن است چندین دور بحث برای به‌دست‌آوردن تصویر کامل مورد نیاز باشد.^[۲]

پس از فهم مشکل و روشن شدن شرایط دلیل آغاز پروژه، نوبت به نوشتن بیانیه مشکل می‌رسد.

نوشتن بیانیه مشکل[ویرایش]

از بیانیه مشکل برای جلب حمایت پروژه و تأیید ذی‌نفعان استفاده خواهد شد. به همین ترتیب، باید عمل محور باشد. از همه مهم‌تر، بیانیه مسئله باید به‌طور واضح و دقیق نوشته شود تا نتایج موفقیت‌آمیز حاصل شود. یک بیان مشکل بد ساخته شده یا نادرست به یک راه حل معیوب منجر می‌شود به اتلاف وقت، پول و منابع.^[۱]

چندین عنصر اساسی وجود دارد که می‌تواند در هر بیان مسئله برای کاهش خطر شکست پروژه تعبیه شود. ابتدا، عبارت بیان مسئله باید بر روی کاربر نهایی متمرکز باشد. یک اشتباه رایج تمرکز کردن روی «چگونه بودن» حل یک مسئله است تا شکاف فعلی. دوم، بیان مسئله نباید خیلی کلی/ گسترده باشد. فایده استفاده از رویکرد «۵ چرا» این است که با ارائه جزئیات لازم برای درک مسئله و ایجاد راه حل مناسب، از سادگی بیش از حد جلوگیری می‌کند. سرانجام، بیان مسئله نباید خیلی محدود باشد. تعصب در راه حل خلاقیتی را که هنگام طوفان فکری برای راه حل به وجود می‌آید خفه می‌کند، که ممکن است تجربه‌ای کمتر از بهینه را برای کاربر به همراه داشته باشد.^[۶]

هنگام نوشتن بیانیه مسئله، طراحی و دنبال کردن قالب خاص مفید است. اگرچه گزینه‌های مختلفی برای انجام این کار وجود دارد، اما در زیر یک الگوی ساده و میانبر وجود دارد که اغلب در تجزیه و تحلیل تجارت برای حفظ تمرکز بر تعریف مشکل استفاده می‌شود.

ایده‌آل IDEAL: این بخش برای توصیف حالت مطلوب یا «درآینده خواهد بود» فرایند یا محصول استفاده می‌شود؛ که اهداف ذی‌نفعان و مشتریان را شناسایی می‌کند و همچنین در تعیین دامنه کمک می‌کند. به‌طور کلی، این بخش باید نشان دهد که پس از اجرای راه‌حل، محیط مورد انتظار چگونه است.
واقعیت REALITY: این بخش برای توصیف وضعیت فعلی یا «همان‌طور که هست» از فرایند یا محصول استفاده می‌شود که نکات درد بیان شده توسط ذی‌نفعان و مشتریان را بیان می‌کند. همچنین باید شامل بینش و تخصص تیم پروژه و کارشناسان موضوعی ارائه شده در هنگام تجزیه و تحلیل مسئله باشد.
CONSEQUENCES عواقب: این بخش برای توصیف تأثیرات در مشاغل در صورت حل نشدن یا بهبود نیافتن مشکل مورد استفاده قرار می‌گیرد. این شامل هزینه‌های مرتبط با از دست دادن پول، زمان، بهره‌وری، مزیت رقابتی و غیره است. میزان این تأثیرات به تعیین اولویت پروژه نیز کمک خواهد کرد.
PROPOSAL پیشنهاد: این بخش برای توصیف راه‌حل‌های بالقوه استفاده می‌شود. پس از اتمام، درک و تأیید بخش ایده‌آل، واقعیت و عواقب، تیم پروژه می‌تواند گزینه‌هایی را برای حل مشکل ارائه دهد. همچنین می‌تواند شامل پیشنهادهایی از طرف ذی‌نفعان و مشتریان باشد، اگرچه قبل از تعیین یک اقدام خاص، به بحث و تحقیق بیشتری نیاز است.^[۵]

پیروی از این قالب و روش منجر به ایجاد یک سند قابل اجرا می‌شود که می‌تواند توسط همه طرفین برای درک مشکل مورد استفاده قرار گیرد و الزاماتی را بسازد که منجر به یک راه حل پیروز و موفق شود.

مثال[ویرایش]

بسته به پیچیدگی مسئله، طول بیانات مسئله می‌تواند متفاوت باشد. در زیر مثالی از بیان مسئله ساده برای ایجاد قابلیت رمز ورود یک‌پارچه کاربران یا به انگلیسی Single Sign On وجود دارد:

ایده‌آل[ویرایش]

در حالت ایده‌آل کاربران ما می‌توانند به لپ تاپ‌های خود وارد شوند و سپس به‌طور خودکار به همه برنامه‌های مورد نیاز برای استفاده دسترسی داشته باشند.

واقعیت[ویرایش]

در واقع ما هر روز حداقل از سه برنامه برای انجام کار خود استفاده می‌کنیم که هر برنامه توسط یک رمز عبور با شرایط مختلف نام کاربری و طول رمز عبور محافظت می‌شود. گذرواژه‌ها نیز در زمان‌های مختلف منقضی می‌شوند.

عواقب[ویرایش]

کاربران تقریباً هر روز ۲ دقیقه برای ورود به برنامه‌های مختلف هدر می‌دهند (اگر ۵۰۰ کاربر وجود داشته باشد ۵۰۰ کاربر استفاده کنیم * ۲ دقیقه در روز = ۱۰۰۰ دقیقه در بهره‌وری از دست رفته؛ ۱۰۰۰ دقیقه = ۱۶٫۶۷ ساعت در روز * ۷۵ دلار در ساعت = ۱۲۵۰ دلار در روز).
بخش پشتیبانی Helpdesk تقریباً ۶۰۰۰ تماس در سال را برای بازنشانی گذرواژه‌های فراموش شده و بازکردن قفل حساب‌ها حل می‌کند.
خطرات امنیتی در حالی که کاربران همچنان به نوشتن نام کاربری و گذرواژه بر روی یادداشتهای مهم روی میز خود ادامه می‌دهند وجود دارد.

پیشنهاد/پروپوزال[ویرایش]

ارزیابی کردن راه حل‌های بالقوه برای قابلیت یکپارچه کردن رمز ورودها Single Sign On بوسیله شرکت سازنده نرم‌افزار Soft Ware، شرکت مدیریت شبکه و سهامداران تجاری.

منابع[ویرایش]

↑ ^۱٫۰ ^۱٫۱ Kush, Max (June 2015). "The Statement Problem". Quality Progress. 48 (6).
↑ ^۲٫۰ ^۲٫۱ ^۲٫۲ Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (September 2013). "Importance of Problem Statement in Solving Industry Problems". Applied Mechanics and Materials. Zurich. 421 – via ProQuest.
↑ ^۳٫۰ ^۳٫۱ Lindstrom, Chris (2011-04-24). "How To Write A Problem Statement". www.ceptara.com (به انگلیسی). Archived from the original on 5 August 2020. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:3» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).
↑ ^۴٫۰ ^۴٫۱ Shaffer, Deb (2017-07-12). "How to Write a Problem Statement". ProProject Manager (به انگلیسی). Archived from the original on 20 June 2018. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:5» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).
↑ ^۵٫۰ ^۵٫۱ Shaffer, David (2015-12-21). "Cooking Up Business Analysis Success". BA Times (به انگلیسی). Archived from the original on 12 June 2018. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:6» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).
↑ ^۶٫۰ ^۶٫۱ ^۶٫۲ {{من خیلی مراعات زبان سیستم رو می‌کنم که فارسی نکنم. news|url=https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c%7Ctitle=Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes|last=Widen|first=Steven|date=2018-04-02|work=Forbes|accessdate=2018-04-10|archiveurl=https://web.archive.org/web/20200807221021/https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c%7Carchivedate=7 اوت 2020|language=en}} خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:7» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).

[:0-1] ۱٫۰ ^۱٫۱ Kush, Max (June 2015). "The Statement Problem". Quality Progress. 48 (6).

[:1-2] ۲٫۰ ^۲٫۱ ^۲٫۲ Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (September 2013). "Importance of Problem Statement in Solving Industry Problems". Applied Mechanics and Materials. Zurich. 421 – via ProQuest.

[:3-3] ۳٫۰ ^۳٫۱ Lindstrom, Chris (2011-04-24). "How To Write A Problem Statement". www.ceptara.com (به انگلیسی). Archived from the original on 5 August 2020. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:3» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).

[:5-4] ۴٫۰ ^۴٫۱ Shaffer, Deb (2017-07-12). "How to Write a Problem Statement". ProProject Manager (به انگلیسی). Archived from the original on 20 June 2018. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:5» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).

[:6-5] ۵٫۰ ^۵٫۱ Shaffer, David (2015-12-21). "Cooking Up Business Analysis Success". BA Times (به انگلیسی). Archived from the original on 12 June 2018. Retrieved 2018-04-10. خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:6» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).

[:7-6] ۶٫۰ ^۶٫۱ ^۶٫۲ {{من خیلی مراعات زبان سیستم رو می‌کنم که فارسی نکنم. news|url=https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c%7Ctitle=Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes|last=Widen|first=Steven|date=2018-04-02|work=Forbes|accessdate=2018-04-10|archiveurl=https://web.archive.org/web/20200807221021/https://www.forbes.com/sites/forbesagencycouncil/2018/04/02/take-these-steps-to-define-your-uiux-problem-and-avoid-haphazard-changes/#22f21cda7c6c%7Carchivedate=7 اوت 2020|language=en}} خطای یادکرد: برچسب <ref> نامعتبر؛ نام «:7» چندین بار با محتوای متفاوت تعریف شده است. (صفحهٔ راهنما را مطالعه کنید.).

[۱]

[۲]

[۳]

[۴]

[۵]

[۶]