صبح یک روز کاری را تصور کنید. جلسه یکی از والدین عقب افتاده، کلاس فرزندشان زودتر تعطیل می‌شود و هیچ‌کدام مطمئن نیستند چه کسی باید دنبال بچه برود. هر دو تقویم دارند، پیام‌رسان دارند و احتمالا چند برنامه یادآوری هم روی گوشی‌شان نصب کرده‌اند.
پس چرا هنوز هماهنگی کارهای روزمره دشوار است؟
شاید مسئله اصلا کمبود ابزار برنامه‌ریزی نباشد. شاید مشکل این باشد که اطلاعات بین چند نفر و چند ابزار پراکنده شده و هیچ‌کس تصویر روشنی از مسئولیت‌ها و تغییرات روز ندارد.
همین تفاوت ظاهرا ساده، نقطه شروع یک تصمیم مهم در مدیریت محصول است: آیا باید ابزار جدیدی برای ثبت برنامه‌ها بسازیم یا راهی پیدا کنیم که اعضای خانواده بتوانند با تلاش کمتر، کارهایشان را هماهنگ کنند؟
سوال سوم مصاحبه مدیر محصول
اگر قرار باشد محصولی برای کمک به والدین شاغل در برنامه‌ریزی روزانه طراحی کنید، از کجا شروع می‌کنید و چه محصولی پیشنهاد می‌دهید؟
این سوال در دسته Product Sense & Design قرار می‌گیرد و بیشتر از آنکه توانایی طراحی یک اپلیکیشن را بسنجد، قدرت تشخیص مسئله و تصمیم‌گیری محصولی را ارزیابی می‌کند.
مصاحبه‌کننده می‌خواهد ببیند آیا می‌توانیم:
- کاربران مشخصی انتخاب کنیم و نیازهای متفاوتشان را بشناسیم.
- میان مشکل واقعی و راه‌حل پیشنهادی تفاوت بگذاریم.
- راه‌حل‌های مختلف را با توجه به ارزش، هزینه و ریسک مقایسه کنیم.
- نسخه اولیه‌ای پیشنهاد بدهیم که بتوان با آن یاد گرفت.
- موفقیت را با تغییر رفتار و نتیجه واقعی بسنجیم، نه تعداد قابلیت‌های محصول.
پاسخ ضعیف معمولا با فهرستی از قابلیت‌ها شروع می‌شود: تقویم خانوادگی، هوش مصنوعی، یادآوری، مدیریت وظایف و اتصال به ابزارهای دیگر.
اما هنوز مشخص نیست این قابلیت‌ها دقیقا کدام مشکل را حل می‌کنند.
۱. ابتدا مسئله را محدود کنیم
«والدین شاغل» یک گروه کاربری یکدست نیست.
والدی که به‌تنهایی از فرزندش مراقبت می‌کند، با خانواده‌ای که هر دو والد برنامه کاری ثابت دارند، یا خانواده‌ای که یکی از والدین شیفت شب کار می‌کند، نیازهای متفاوتی دارد.
حتی سن فرزند، میزان کمک اطرافیان، امکان دورکاری و دسترسی به اینترنت می‌تواند شکل مسئله را تغییر دهد.
بنابراین در مصاحبه، قبل از طراحی محصول چند سوال می‌پرسم:
- محصول برای کدام گروه از والدین است؟
- مهم‌ترین مشکلشان مدیریت زمان شخصی است یا هماهنگی مسئولیت‌های خانوادگی؟
- امروز برای برنامه‌ریزی از چه ابزارهایی استفاده می‌کنند؟
- کدام اتفاقات بیشترین اختلال را در برنامه روزانه ایجاد می‌کنند؟
- آیا هدف کاهش زمان برنامه‌ریزی است، جلوگیری از فراموشی کارها یا کاهش فشار ذهنی هماهنگی؟
اگر مصاحبه‌کننده محدودیت مشخصی ندهد، یک فرض کاری انتخاب می‌کنم.
فرض مسئله: خانواده‌هایی که دو والد شاغل و حداقل یک فرزند دبستانی دارند، برای هماهنگی کارهای مشترک و مدیریت تغییرات روزانه با مشکل روبه‌رو هستند.
این فرض به معنی بی‌اهمیت بودن سایر خانواده‌ها نیست. فقط کمک می‌کند نخستین نسخه محصول را برای گروهی مشخص طراحی کنیم و بعد درباره گسترش آن تصمیم بگیریم.
۲. نیاز واقعی را از رفتار کاربران کشف کنیم
به‌جای اینکه بپرسیم «دوست دارید اپلیکیشن شما چه امکاناتی داشته باشد؟»، بهتر است سراغ آخرین تجربه واقعی کاربران برویم.
مثلا:
- آخرین بار چه زمانی برنامه خانوادگی‌تان به هم خورد؟
- چطور متوجه شدید چه کاری انجام نشده است؟
- چه کسی مسئول هماهنگی بود؟
- برای اصلاح برنامه چند بار تماس گرفتید یا پیام فرستادید؟
- کدام بخش از هماهنگی بیشترین انرژی را از شما گرفت؟
اینجا فقط دنبال کارهای فراموش‌شده نیستیم. باید بار ذهنی برنامه‌ریزی را هم بشناسیم؛ یعنی تلاش لازم برای به خاطر سپردن کارها، پیگیری دیگران، پیش‌بینی تغییرات و اطمینان از انجام مسئولیت‌ها.
ممکن است یک کار به‌موقع انجام شده باشد، اما یکی از والدین برای اطمینان از انجام آن چندین بار پیگیری کرده باشد.
پس صرفا ثبت نتیجه نهایی، تمام مسئله را نشان نمی‌دهد.
راهنمای پژوهش کاربر GOV.UK نیز بر شناخت رفتار فعلی کاربران، مشکلات واقعی و شرایط استفاده پیش از انتخاب راه‌حل تاکید می‌کند.
چطور تحقیق کنیم؟
برای شروع، ترکیبی از مصاحبه و مطالعه روزنگار (Diary Study) انتخاب می‌کنم.
در یک پژوهش اکتشافی پیشنهادی، می‌توان با حدود ۸ تا ۱۲ خانواده از گروه هدف گفت‌وگو کرد و از تعدادی از آن‌ها خواست طی یک هفته، مشکلات هماهنگی روزانه را به شکلی کوتاه ثبت کنند.
این تعداد و مدت، پیشنهاد اولیه برای یادگیری است، نه نمونه آماری نماینده همه والدین.
مطالعه روزنگار کمک می‌کند رفتارهایی را ببینیم که ممکن است در یک مصاحبه به خاطر آورده نشوند: تغییر ناگهانی برنامه، هماهنگی میان چند نفر و راه‌حل‌های موقتی که خانواده‌ها برای عبور از مشکلات پیدا می‌کنند.
همزمان باید بررسی کنیم آیا ابزارهای موجود، مانند تقویم مشترک، پیام‌رسان یا حتی یک یادداشت کاغذی، بخش عمده نیاز را برطرف می‌کنند یا نه.
اگر کاربران با ابزارهای فعلی مسئله را خوب حل می‌کنند، ساخت یک اپلیکیشن مستقل احتمالا توجیه کافی ندارد.
۳. چه محصولی طراحی کنیم؟
فرض کنیم پژوهش اولیه نشان دهد مسئله اصلی، ثبت رویدادها نیست؛ بلکه ناهماهنگی درباره مسئولیت‌ها و تغییرات لحظه آخری است.
در این شرایط سه مسیر قابل بررسی داریم.
گزینه اول: تقویم خانوادگی کامل
هر عضو خانواده برنامه‌هایش را ثبت می‌کند و همه می‌توانند رویدادهای مشترک را ببینند.
مزیت آن، آشنایی کاربران با مفهوم تقویم است.
اما مشکل اینجاست که خانواده ممکن است همین حالا هم از تقویم استفاده کند. محصول جدید فقط یک محل دیگر برای ثبت اطلاعات ایجاد می‌کند، بدون اینکه مسئولیت انجام کارها روشن‌تر شود.
گزینه دوم: دستیار هوشمند برنامه‌ریزی
سیستم می‌تواند رویدادها را تحلیل کند، تداخل‌ها را تشخیص دهد و پیشنهادهایی برای تقسیم کار ارائه بدهد.
چنین قابلیتی در صورت داشتن داده کافی می‌تواند ارزشمند باشد، اما برای نسخه اول با چند مسئله روبه‌رو است: دسترسی به داده‌های شخصی، احتمال پیشنهاد اشتباه، پیچیدگی فنی و نیاز به اعتماد کاربران.
ضمن اینکه هنوز نمی‌دانیم خانواده‌ها برای حل مشکلشان واقعا به پیشنهاد هوشمند نیاز دارند یا صرفا یک روش شفاف برای هماهنگی.
گزینه سوم: برنامه روزانه مشترک با مسئولیت‌های مشخص
در این مدل، تمرکز محصول روی سه سوال است:
امروز چه کاری باید انجام شود؟ مسئول آن کیست؟ اگر برنامه تغییر کرد، چه کسی باید مطلع شود؟
به نظرم این گزینه، برای فرض مسئله‌ای که انتخاب کرده‌ایم، نقطه شروع مناسب‌تری است.
زیرا به‌جای رقابت مستقیم با همه ابزارهای تقویم و مدیریت وظایف، روی یک مشکل مشخص تمرکز می‌کند: هماهنگی عملی میان اعضای خانواده.
البته این انتخاب مشروط به شواهد تحقیق است. اگر مشکل اصلی کاربران چیز دیگری باشد، راه‌حل نیز باید تغییر کند.
۴. نسخه اولیه محصول چه قابلیت‌هایی داشته باشد؟
برای MVP یا حداقل محصول پذیرفتنی، سراغ قابلیت‌های محدودی می‌روم که مهم‌ترین فرضیه را آزمایش کنند.
نمای مشترک امروز: اعضای خانواده بتوانند کارهای ضروری امروز را همراه با زمان و فرد مسئول ببینند.
تعیین و پذیرش مسئولیت: انجام یک کار به فردی مشخص سپرده شود و او بتواند مسئولیتش را تایید یا درخواست تغییر کند.
ثبت سریع تغییرات: اگر زمان کلاس، جلسه یا مسئول انجام کاری تغییر کرد، اطلاعات مشترک به‌روزرسانی شود.
اطلاع‌رسانی هدفمند: فقط تغییراتی که نیاز به آگاهی یا اقدام دارند، اعلان ایجاد کنند.
هماهنگی کوتاه ابتدای روز: خانواده بتواند بدون طی کردن مراحل طولانی، مهم‌ترین برنامه‌های روز را مرور کند.
در نسخه اول، عمدا سراغ امکاناتی مثل پیشنهادهای پیشرفته هوش مصنوعی، اتصال به همه تقویم‌ها، مدیریت مالی خانواده یا ردیابی دائمی موقعیت اعضا نمی‌روم.
هر کدام ممکن است بعدها ارزشمند باشند، اما اضافه کردنشان پیش از اثبات نیاز، هزینه توسعه و پیچیدگی محصول را بیشتر می‌کند.
یک محدودیت مهم: محصول نباید کار اضافه ایجاد کند
فرض کنیم والدین برای ثبت هر فعالیت مجبور باشند چند فرم تکمیل کنند.
در این صورت محصولی که قرار بوده فشار برنامه‌ریزی را کاهش دهد، خودش به وظیفه جدیدی تبدیل می‌شود.
بنابراین سرعت ثبت کار، امکان ویرایش آسان و نیاز نداشتن به ورود اطلاعات تکراری، بخشی از ارزش اصلی محصول هستند؛ نه صرفا جزئیات رابط کاربری.
همچنین باید امکان استفاده ساده برای خانواده‌هایی وجود داشته باشد که فقط یکی از والدین مدیریت برنامه را بر عهده دارد. در عین حال نباید طراحی محصول باعث شود تمام مسئولیت هماهنگی به همان فرد منتقل شود.
۵. یک مثال عملی از طراحی محصول نرم‌افزاری
سناریوی فرضی:
یک تیم محصول در حال طراحی سرویس هماهنگی روزانه برای خانواده‌های دارای فرزند دبستانی است.
در مصاحبه‌های اکتشافی، فرض می‌کنیم والدین توضیح می‌دهند که بیشتر مشکلاتشان هنگام تغییر برنامه‌های مدرسه یا جلسات کاری اتفاق می‌افتد.
برای مثال، یکی از والدین مسئول بردن فرزند به کلاس است، اما جلسه کاری‌اش طول می‌کشد. او از طریق پیام‌رسان اطلاع می‌دهد، ولی پیام میان گفت‌وگوهای دیگر دیده نمی‌شود.
تیم طراحی دو نمونه اولیه آماده می‌کند:
- نمونه A: تقویم مشترک با نمایش رویدادهای خانوادگی.
- نمونه B: برنامه روزانه مشترک با مسئول مشخص و امکان درخواست تغییر مسئولیت.
در آزمایش کاربردپذیری، از کاربران می‌خواهیم موقعیتی مشابه تغییر ناگهانی برنامه را مدیریت کنند.
بررسی می‌کنیم آیا هر دو نفر می‌توانند بفهمند مسئول جدید چه کسی است، آیا تغییر را تایید کرده‌اند و برای رسیدن به توافق چقدر تلاش کرده‌اند.
این آزمایش هنوز نشان نمی‌دهد محصول در زندگی روزمره موفق خواهد بود. فقط کمک می‌کند بفهمیم کدام الگو در انجام یک وظیفه مشخص، قابل‌فهم‌تر و کاربردی‌تر است.
برای سنجش ارزش واقعی باید نمونه منتخب را در استفاده روزانه نیز آزمایش کنیم.
اگر نتیجه نشان دهد خانواده‌ها همچنان ترجیح می‌دهند با پیام‌رسان هماهنگ کنند، باید دلیل آن را بفهمیم؛ نه اینکه صرفا کاربران را به استفاده بیشتر از اپلیکیشن تشویق کنیم.
۶. موفقیت محصول را چطور اندازه بگیریم؟
تعداد نصب یا تعداد کارهای ثبت‌شده، به‌تنهایی معیار موفقیت مناسبی نیست.
ممکن است خانواده‌ای ده‌ها فعالیت در محصول ثبت کند، اما هنوز برای هماهنگی روزانه دچار مشکل باشد.
بهتر است یک معیار اصلی و چند معیار تشخیصی و محافظتی داشته باشیم.
معیار اصلی: هماهنگی موفق
نرخ هماهنگی موفق = تعداد مسئولیت‌های برنامه‌ریزی‌شده‌ای که در زمان مورد انتظار و بدون ناهماهنگی حل‌نشده انجام شده‌اند ÷ کل مسئولیت‌های مشترک برنامه‌ریزی‌شده
برای اعتبار این معیار، ابتدا باید تعریف دقیقی از مسئولیت مشترک، انجام موفق و ناهماهنگی حل‌نشده داشته باشیم.
در یک آزمایش چهار‌هفته‌ای پیشنهادی، می‌توان با ترکیبی از ثبت رویدادهای محصول و گزارش کوتاه خانواده‌ها وضعیت را بررسی کرد؛ البته ثبت درون‌برنامه‌ای به‌تنهایی انجام واقعی یک کار در خارج از محصول را ثابت نمی‌کند.
معیارهای مکمل عبارت‌اند از:
- زمان لازم برای آماده کردن برنامه روز.
- سهم خانواده‌هایی که بیش از یک عضو در هماهنگی مشارکت می‌کند.
- تعداد تغییراتی که بدون تماس یا پیگیری مجدد مدیریت می‌شوند.
- میزان احساس فشار ذهنی و رضایت از هماهنگی، بر اساس گزارش کاربران.
معیارهای محافظتی
باید مراقب باشیم بهبود یک عدد، آسیب دیگری ایجاد نکند.
مثلا تعداد زیاد اعلان‌ها ممکن است مشارکت ظاهری را بیشتر کند، اما تجربه کاربری را خراب کند.
همچنین باید نرخ قطع استفاده، زمان صرف‌شده برای ورود اطلاعات، احساس نابرابری در تقسیم مسئولیت‌ها و مشکلات مربوط به دسترسی غیرمجاز به اطلاعات را زیر نظر بگیریم.
بدون سنجش این موارد، ممکن است محصولی بسازیم که از نظر گزارش‌های تحلیلی موفق است، ولی در زندگی واقعی کمک چندانی نمی‌کند.
۷. ریسک‌ها و محدودیت‌های تصمیم
یکی از مهم‌ترین ریسک‌ها، نیاز به مشارکت چند نفر برای ایجاد ارزش است.
اگر فقط یکی از والدین از محصول استفاده کند، ممکن است هماهنگی مشترک شکل نگیرد و ثبت اطلاعات بیشتر شود.
برای کاهش این ریسک، باید دعوت عضو دیگر ساده باشد و امکان مشارکت محدود، بدون تنظیمات پیچیده، فراهم شود.
ریسک دوم، حریم خصوصی است.
برنامه روزانه خانواده می‌تواند شامل اطلاعات حساسی درباره زمان حضور در خانه، محل فعالیت و برنامه فرزندان باشد.
پیشنهاد من این است که محصول در نسخه اول به حساب مستقل کودک یا ردیابی موقعیت نیازی نداشته باشد. اعضای بزرگسال باید بدانند چه اطلاعاتی با چه کسانی به اشتراک گذاشته می‌شود و بتوانند دسترسی‌ها را مدیریت کنند.
این انتخاب با اصل کمینه‌سازی داده در راهنمای نهاد حفاظت از داده بریتانیا (ICO) همسو است؛ هرچند الزامات حقوقی هر بازار باید جداگانه بررسی شود.
ریسک سوم، رقابت با عادت‌های موجود کاربران است. اگر خانواده با پیام‌رسان و تقویم فعلی راحت باشد، نصب یک ابزار جدید باید ارزشی مشخص و قابل لمس ایجاد کند.
۸. تفاوت نقش‌ها در اجرای این تصمیم
در چنین مسئله‌ای، مدیر محصول مسئول روشن کردن مسئله، انتخاب گروه هدف، تعیین اولویت‌ها و ارزیابی نتیجه محصول است.
مدیر پروژه، اگر این نقش در تیم وجود داشته باشد، بیشتر روی برنامه اجرا، هماهنگی فعالیت‌ها، زمان‌بندی و محدودیت‌های تحویل تمرکز می‌کند.
در تیمی که از Scrum استفاده می‌کند، Product Owner طبق Scrum Guide مسئول بیشینه‌سازی ارزش محصول و مدیریت موثر Product Backlog است.
این نقش‌ها ممکن است در یک سازمان بر عهده یک نفر باشند، اما نوع پاسخ‌گویی آن‌ها یکسان نیست.
در مصاحبه مدیر محصول، صرفا گفتن اینکه «نسخه اول را طی چند اسپرینت تحویل می‌دهیم» کافی نیست. باید توضیح بدهیم چرا این نسخه ارزش ساختن دارد.
۹. پاسخ پیشنهادی در جلسه مصاحبه
اگر بخواهم همین مسئله را شفاهی پاسخ بدهم، می‌گویم:
«من قبل از طراحی محصول مشخص می‌کنم دقیقا برای کدام گروه از والدین و کدام مشکل برنامه‌ریزی می‌خواهیم راه‌حل بسازیم.
برای شروع فرض می‌کنم خانواده‌هایی را هدف گرفته‌ایم که هر دو والد شاغل هستند و برای هماهنگی کارهای مربوط به فرزندشان مشکل دارند.
ابتدا بررسی می‌کنم امروز چطور این هماهنگی را انجام می‌دهند و بیشتر کجا برنامه‌هایشان به هم می‌ریزد. برای این کار از مصاحبه و ثبت چندروزه تجربه‌های واقعی استفاده می‌کنم.
اگر متوجه شویم مشکل اصلی، مبهم بودن مسئولیت‌ها و تغییرات لحظه آخری است، یک برنامه روزانه مشترک ساده پیشنهاد می‌دهم؛ جایی که هر کار مسئول مشخصی داشته باشد و تغییرات مهم به فرد مرتبط اطلاع داده شود.
برای نسخه اول، هوش مصنوعی و امکانات پیچیده را کنار می‌گذارم. با یک نمونه ساده و آزمایش محدود شروع می‌کنم.
موفقیت را هم با تعداد کارهای ثبت‌شده نمی‌سنجم؛ بررسی می‌کنم آیا ناهماهنگی کمتر شده، زمان برنامه‌ریزی پایین آمده و محصول بدون ایجاد فشار اضافی واقعا به خانواده کمک کرده است.
اگر شواهد نشان بدهند خانواده‌ها با ابزار فعلی بهتر کار می‌کنند یا استفاده از محصول برایشان زحمت بیشتری دارد، راه‌حل را تغییر می‌دهم و حتی ممکن است به‌جای اپلیکیشن مستقل، یک قابلیت مکمل برای ابزارهای موجود پیشنهاد کنم.»
۱۰. دو سوال تکمیلی مهم مصاحبه
اگر فقط دو هفته برای بررسی مسئله فرصت داشته باشید، چه می‌کنید؟
هدفم ساخت محصول کامل نیست؛ می‌خواهم مهم‌ترین فرضیه را سریع بررسی کنم.
در چند روز اول با گروه محدودی از والدین مصاحبه می‌کنم و نمونه‌هایی از ناهماهنگی‌های واقعی را جمع‌آوری می‌کنم.
بعد دو راه‌حل ساده را با نمونه اولیه قابل‌کلیک یا حتی یک فرایند هماهنگی دستی آزمایش می‌کنم.
در روزهای پایانی، واکنش کاربران، میزان تلاش لازم و قابلیت استفاده در موقعیت واقعی را بررسی می‌کنم.
خروجی دو هفته باید یک تصمیم مستند باشد: ادامه همین مسیر، اصلاح فرضیه یا کنار گذاشتن آن. این بازه برای اثبات ماندگاری محصول کافی نیست.
چه شواهدی باعث می‌شوند راه‌حل پیشنهادی را رد کنید؟
اگر تحقیق نشان دهد ناهماهنگی مسئله پرتکرار یا پرهزینه‌ای نیست، فرض اولیه زیر سوال می‌رود.
اگر کاربران حاضر نباشند اطلاعات مشترک را ثبت کنند، هر دو والد به محصول نپیوندند یا زمان لازم برای استفاده از آن بیشتر از منفعتش باشد، طراحی فعلی مناسب نیست.
همچنین اگر نمونه اولیه در آزمایش وظیفه‌ای خوب عمل کند اما در استفاده واقعی، هماهنگی یا فشار ذهنی را بهتر نکند، باید آن را بازنگری کنم.
تغییر تصمیم در برابر شواهد جدید نشانه ضعف مدیر محصول نیست؛ بخشی از مسئولیت اوست.
۱۱. اشتباهات رایج در پاسخ به این سوال
طراحی برای همه خانواده‌ها: چنین پاسخی تفاوت نیازها را نادیده می‌گیرد و باعث می‌شود محصول اولیه بیش از حد گسترده شود.
شروع با فهرست امکانات: اگر هنوز مشکل اصلی مشخص نشده، قابلیت‌هایی مثل دستیار هوشمند و تقویم خودکار بیشتر حدس هستند تا راه‌حل.
تمرکز صرف بر تعداد کاربران فعال: استفاده زیاد لزوما به معنی کاهش ناهماهنگی یا فشار ذهنی نیست.
نادیده گرفتن عادت‌های فعلی: اگر محصول به ثبت دوباره اطلاعات نیاز داشته باشد، ممکن است هیچ‌گاه جایگزین ابزارهای موجود نشود.
قطعیت بیش از حد: گفتن اینکه «این بهترین راه‌حل است» بدون داده و آزمایش، توان تصمیم‌گیری را نشان نمی‌دهد. پاسخ قوی توضیح می‌دهد در چه شرایطی این انتخاب مناسب است و چه شواهدی آن را تغییر می‌دهند.
جمع‌بندی
برای طراحی محصولی که به والدین شاغل در برنامه‌ریزی روزانه کمک کند، پیشنهاد من شروع با یک گروه مشخص از خانواده‌ها و بررسی مشکلات واقعی هماهنگی آن‌هاست؛ نه ساخت یک تقویم جدید با امکانات بیشتر.
اگر تحقیق نشان دهد مسئله اصلی، ابهام در مسئولیت‌ها و تغییرات روزانه است، یک برنامه مشترک ساده با تعیین مسئولیت و اطلاع‌رسانی هدفمند می‌تواند نسخه اولیه مناسبی باشد.
اما ارزش این محصول زمانی ثابت می‌شود که ناهماهنگی را کاهش دهد، وقت و انرژی خانواده را کمتر مصرف کند و خودش به یک وظیفه اضافی تبدیل نشود. اگر شواهد این فرض را تایید نکنند، تصمیم درست بازنگری راه‌حل است، نه دفاع از محصولی که ساخته‌ایم.
مدیریت محصول یعنی قبل از ساختن ابزار، مطمئن شویم مسئله‌ای را حل می‌کنیم که واقعا ارزش حل کردن دارد.
