زمینه راه حل

زمینه راه حل جنبه های حیاتی محیطی را که یک راه حل در آن عمل می کند، شناسایی می کند.
بسیاری از ابتکارات توسعه راه حل ناموفق هستند – نه به دلیل ناتوانی در ایجاد راه حل – بلکه به این دلیل که راه حل توسعه یافته مطابق انتظار در محیط عملیاتی واقعی خود عمل نمی کند. نمونه ها فراوان است:

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

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

درک زمینه ای که یک راه حل در آن عمل می کند برای هر سازنده راه حل بسیار مهم است. اغلب به همان درجه ای از نظم و انضباط نیاز دارد که در ساخت خود راه حل وجود دارد. این تلاش را می توان با این واقعیت ترکیب کرد که برای یک سازنده راه حل ساده تر (و شاید جالب تر) است که بر توسعه راه حل تمرکز کند تا درک مکان و نحوه عملکرد آن. این منجر به مفروضات طراحی می شود که ممکن است تنها پس از انتشار راه حل آزمایش شوند. در حالی که شرکت‌ها به طور فزاینده‌ای از روش‌های تکراری برای ایجاد عملکرد راه‌حل استفاده می‌کنند، افشای آن عملکرد در محیط عملیاتی اغلب تنها در زمان انتشار اتفاق می‌افتد. و برای پاسخ دادن به آموخته های جدید بدون تأخیر یا دوباره کاری بسیار دیر است. در عوض، سازندگان راه حل باید محیط عملیاتی راه حل را درک کنند و برای موفقیت در آن محیط طراحی و آزمایش کنند. این بدان معنی است که تیم ها و قطارهای چابک باید:

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

هر یک از این فعالیت‌ها در بخش‌های بعدی توضیح داده می‌شوند.

 

جنبه های حیاتی زمینه راه حل را بشناسید

محیطی که یک راه حل در آن عمل می کند بر همه عناصر توسعه راه حل، از جمله هدف و طراحی راه حل، NFR ها، اولویت های توسعه، پیاده سازی و آزمایش راه حل، حاکمیت انتشار و غیره تأثیر می گذارد. این جنبه های حیاتی به طور کلی به هفت دسته تقسیم می شوند، همانطور که در شکل ۱ نشان داده شده است:

شکل ۱. جنبه های اصلی زمینه راه حل

استفاده از مشتری

تجربیات مشتری می تواند به شدت به مکان، در دسترس بودن و راحتی راه حل بستگی داشته باشد. نحوه استفاده از یک راه حل اغلب بهتر از آن که مستقیماً از مشتری استخراج شود مشاهده می شود. برای مثال، اولین پاسخ دهنده ممکن است از یک قالب جمله سختگیرانه برای سیستم فرمان صوتی در طول یک موقعیت بحرانی پیروی نکند. همچنین، یک نماینده خدمات مشتری ممکن است نتواند شکایتی را در سیستم ( CRM ) در زمان اوج بار ثبت کند. هیچ جایگزین خوبی برای آموخته های به دست آمده در مشاهده واقعی وجود ندارد.

محیط فیزیکی

شرایط فیزیکی محیط نیز بر طراحی راه حل تأثیر می گذارد. این شرایط اغلب به تأثیر دما، رطوبت، ارتعاش، وزن، حجم، توان، سرعت، پهنای باند و عوامل مشابه بر محلول مربوط می شود. به عنوان مثال، تجمع یخ ممکن است مانع از تشخیص اجسام روبرو توسط حسگر خودرو شود. یک کولاک ممکن است سیستم کنترل ترافیک را از شناسایی یک تقاطع مسدود جلوگیری کند. قرار گرفتن طولانی مدت در معرض نور مستقیم خورشید ممکن است از برقراری تماس اضطراری توسط تلفن همراه جلوگیری کند. و بادهای شدید ممکن است از تفسیر دستورات توسط نرم افزار تشخیص صدا جلوگیری کند.

 

استانداردها و مقررات

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

تعمیر و نگهداری و پشتیبانی عملیاتی

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

اینها شامل بسیاری از توابع “روتین” هستند، مانند:

پیکربندی تنظیمات سیستم و قوانین تجاری

حفظ حساب های کاربری و دسترسی مدیریت

عیب یابی و عیب زدایی

اعمال تعمیرات فوری و امنیتی

مقیاس‌گذاری نرم‌افزار، سخت‌افزار و زیرساخت برای عملکرد درک تعمیر و نگهداری و پشتیبانی مورد نیاز یک راه‌حل می‌تواند برای موفقیت آن حیاتی باشد.

برای مثال، یک سیستم برنامه‌ریزی منابع سازمانی (ERP) که به شدت سفارشی‌سازی شده است ممکن است روش‌های نگهداری و عملیاتی متفاوتی نسبت به سیستمی که «خارج از قفسه» استفاده می‌شود، داشته باشد.

زیرساخت های حمایتی

راه حل ها معمولاً به زیرساخت های پشتیبانی مانند سرورها، مراکز داده، برق، شبکه های فیبر نوری، ماهواره های ارتباطی و غیره نیاز دارند. علاوه بر درک نیازهای زیرساختی فعلی یک راه حل، انعطاف پذیری، مقیاس پذیری و انعطاف پذیری آینده نیز باید در نظر گرفته شود. به عنوان مثال، یک راه حل هوش مصنوعی (AI) ممکن است با افزایش پیچیدگی به قدرت محاسباتی بیشتری نیاز داشته باشد. همچنین، یک سرویس پخش فیلم ممکن است نیاز به تنظیم الگوریتم های فشرده سازی خود با تکامل پهنای باند شبکه تلفن همراه داشته باشد.

قابلیت همکاری با سایر راه حل ها

در دنیای بسیار متصل امروزی، راه حل ها به ندرت به صورت مجزا عمل می کنند. در عوض، آنها احتمالاً با بسیاری از راه حل های دیگر تعامل دارند. تعداد چنین اتصالاتی بسته به پیچیدگی راه حل از چند تا صدها یا هزاران متغیر است. یک راه حل متصل الزاماتی را بر راه حل های دیگر تحمیل می کند در حالی که نیاز به رعایت الزامات آن راه حل ها نیز دارد. این به این دلیل است که هر راه حلی در تعامل با محیط خود، هم اطلاعات مصرف می کند و هم ارائه می دهد. در نتیجه، اکوسیستم راه حل ها می تواند حاوی شبکه پیچیده ای از وابستگی های متقابل باشد که باید با دقت مدیریت شوند. به عنوان مثال، یک پورتال کارمند ممکن است دچار نقص شود زیرا APIهای مربوط به سیستم های حقوق و دستمزد و مزایای مرتبط آن تغییر کرده است.

 

سیستم-سیستم ها

اغلب، یک راه حل یک عملکرد را به عنوان بخشی از یک سیستم بزرگتر انجام می دهد. یک راه حل ممکن است یک زیرسیستم در یک راه حل فیزیکی-سایبری پیچیده (مثلاً یک سیستم سرگرمی وسیله نقلیه) باشد. یا ممکن است مجموعه‌ای از راه‌حل‌ها باشد که عملکردهای مجاور را انجام می‌دهند و به شدت با پلتفرم‌ها و منابع داده رایج همراه هستند. در این موارد، زمینه راه حل سیستم از سیستم، زمینه زیرسیستم ها را مطلع می کند. برای مثال، فناوری استفاده شده توسط یک ارائه‌دهنده ابری، فناوری مورد استفاده برنامه‌های کاربردی را که میزبان آن است، نشان می‌دهد. همچنین، نحوه طراحی کمباین برداشت مواد غذایی بر نحوه طراحی زیرسیستم‌های اندازه‌گیری ناوبری و اینرسی تعبیه‌شده آن تأثیر می‌گذارد.

 

راه حل را زود و اغلب در معرض محیط مربوطه قرار دهید

ممکن است تأثیر محیط زیست یک راه حل در طراحی آن مورد توجه قرار نگیرد. بنابراین، بسیار مهم است که زمینه راه حل را زودتر بررسی کنیم و در طول توسعه آن را به طور مکررمرور کنیم. همانطور که قبلا گفته شد، انتظار تا زمان انتشار می تواند اشتباهات پرهزینه ای ایجاد کند. قرار دادن راه حل در معرض جنبه های مختلف محیط عملیاتی آن، مفروضات طراحی را زودتر آزمایش می کند و تأثیر تغییرات لازم را کاهش می دهد (شکل ۲).

سازندگان راه حل Lean-Agile این مفهوم را درک کرده و از آن استقبال می کنند: زمینه یک راه حل تقریباً همیشه حاوی مجهولاتی است که تنها از طریق کاوش مستقیم، فشرده و واقعی راه حل در محیط عملیاتی مورد نظر آن قابل آشکار شدن است.

اگرچه مشتریان می توانند بینش ارزشمندی در زمینه راه حل ارائه دهند، تیم های Agile و ART ها با دریافت بازخورد منظم مستقیماً از محیط راه حل، درک خود را ارتقا می دهند. به عنوان مثال، همانطور که شکل ۳ نشان می دهد، سازندگان یک سیستم بازرسی تجهیزات برای یک دکل حفاری ممکن است تنها بخشی از زمینه راه حل را با قرار دادن راه حل در محیط آن کشف کنند.

یک رویکرد اصولی برای افشای اولیه یک راه حل در محیط آن و اغلب ممکن است شامل فعالیت هایی مانند مواردی باشد که در زیر توضیح داده شده است.

شکل ۲. قرار گرفتن زودهنگام در محیط راه حل، یادگیری را تسریع می کند و خطر را کاهش می دهد

 

مشاهده مستقیم

هیچ جایگزینی برای مشاهده مستقیم کاربران در محیط راه حل وجود ندارد. این امر ممکن است جنبه هایی از زمینه راه حل را نشان دهد، مانند:

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

نمونه هایی از مشاهده مستقیم می تواند شامل موارد زیر باشد:

• یک مالک محصول در محل سفر می کند تا محیط راه حل را بررسی کند.
• یک معمار سیستم در حال بررسی گزارش های دقیق محیط تولید
• تیمی از سازندگان راه حل که داده ها را از راه حل های مجاور در جریان ارزش عملیاتی جمع آوری می کنن

 

شبیه سازی محیط راه حل در طول توسعه

برای درک اینکه چگونه زمینه راه حل بر راه حل در دست توسعه تأثیر می گذارد، معمولاً لازم است که محیط راه حل را تقریب یا تقلید کنید. همانطور که شکل ۴ نشان می دهد، این شامل انتخاب و شبیه سازی جنبه های کلیدی محیط است به طوری که آزمایش را می توان به دفعات بیشتری انجام داد. این نیاز به سرمایه‌گذاری در فناوری شبیه‌سازی دارد، اما ارزش راه‌حل این هزینه‌های نشان‌داده‌شده به‌صورت تدریجی و تجربی را جبران می‌کند. نمونه‌هایی از روش‌های شبیه‌سازی عبارتند از مهارهای آزمایشی، آزمایشگاه‌ها، تونل‌های باد، دوقلوهای دیجیتال و وسایل نقلیه قاطر.سازندگان راه حل های فیزیکی سایبری از مهندسی سیستم های مبتنی بر مدل (MBSE) برای تقلید از جنبه های نرم افزاری و سخت افزاری محیط راه حل استفاده می کنند.

برای نرم‌افزار، محیط‌های شبیه‌سازی یک پیش‌نیاز ضروری برای یک خط لوله استقرار مداوم قابل اعتماد هستند تا آزمایش در طول توسعه و در نقطه استقرار انجام شود. (به تحویل مداوم و DevOps مراجعه کنید).

شبیه سازی زمینه راه حل ها در محیط توسعه به طور قابل توجهی هزینه قرار گرفتن آن در محیط واقعی خود را کاهش می دهد و حلقه بازخورد را تسریع می کند. با این حال، هر تقریبی تنها بخشی از زمینه راه حل را نمونه و شبیه سازی می کند. تیم های چابک باید به این محدودیت توجه داشته باشند و قدردانی کنند که “نقشه منطقه نیست”. آنها نباید صرفاً بر این شبیه‌سازی‌ها تکیه کنند، بلکه از آنها در ارتباط با قرار گرفتن در معرض محیط عملیاتی واقعی استفاده کنند.

شکل ۴. تیم چابک جنبه هایی از محیط راه حل را در طول توسعه شبیه سازی می کند

 

 

آزمایش پر ریسک ویژگی های راه حل در زمینه

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

رای مثال، در مورد یک راه حل نرم افزاری، آزمایش یک الگوریتم اصلی، یک ویژگی متمایز، سرعت بارگذاری صفحه یا تجربه کاربر نهایی در محیط عملیاتی ممکن است حیاتی باشد. برای مثال، در مورد یک راه حل نرم افزاری، آزمایش یک الگوریتم اصلی، یک ویژگی متمایز، سرعت بارگذاری صفحه یا تجربه کاربر نهایی در محیط عملیاتی ممکن است حیاتی باشد. سازندگان سیستم های فیزیکی سایبری ممکن است نیاز داشته باشند قبل از ایجاد یک راه حل کامل و یکپارچه، آزمایش های اولیه را با استفاده از زیرمجموعه ای از حسگرها، محرک ها یا مجموعه داده های کاهش یافته انجام دهند. سازندگان سیستم های فیزیکی سایبری ممکن است نیاز داشته باشند قبل از ایجاد یک راه حل کامل و یکپارچه، آزمایش های اولیه را با استفاده از زیرمجموعه ای از حسگرها، محرک ها یا مجموعه داده های کاهش یافته انجام دهند.

 

تست راه حل کامل در زمینه

در برخی موارد، راه حل یکپارچه باید در معرض محیط واقعی خود قرار گیرد. با این حال، حتی در آن زمان نیز، لازم نیست این یک امر همه یا هیچ باشد، و جنبه های مختلف راه حل ممکن است به تدریج در برابر جنبه های مختلف زمینه آن آزمایش شوند. به عنوان مثال، در مورد سیستم‌های نرم‌افزاری، دو رویکرد متداول مورد استفاده «آزمایش سایه» و «رهاسازی قناری» هستند. آزمایش سایه شامل ایجاد یک “جعبه ماسه ای” (منطقه کاری ایزوله) در محیط راه حل واقعی و استقرار و آزمایش نسخه جدید قبل از انتشار رسمی آن است (شکل ۵).

یک «رهاسازی قناری» یک راه حل کاملاً کاربردی را در اختیار زیرمجموعه کوچکی از کاربران قرار می دهد. این اجازه می دهد تا راه حل در محیط تولید اعتبار داشته باشد و در عین حال تأثیر مسائل پیش بینی نشده را به حداقل برساند. ساخت‌های قناری و انتشار سایه‌ها نیز در توسعه سخت‌افزار و سیستم فیزیکی سایبری استفاده می‌شوند. با این حال، آنها معمولا نام های متفاوتی دارند. علاوه بر این، آزمایش یک سیستم فیزیکی-سایبری در زمینه نیاز به تولید واقعی سیستم دارد. یک نمونه اولیه کاملاً کاربردی و یکپارچه یا “اول مقاله” باید در محیط عملیاتی خود قبل از ساخت واحدهای اضافی آزمایش شود.

شکل ۵. آزمایش سایه یک راه حل را در “حالت تاریک” در محیط تولید آن تایید می کند

به زمینه راه حل در حال تحول بپردازید

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

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