نوآوری در مدیریت برای توسعه پایدار

Kolnegar Private Media (Management Innovation for Sustainable Development)

8 اردیبهشت 1403 2:11 ب.ظ

نوآوری و روشهای نوین در طراحی محصول

الف : مقدمه

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

ب : کشف محصول چیست؟

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

تاریخچه کشف محصول چیست؟

پیدایش کشف محصول در اوایل دهه 2000 به عنوان واکنشی به روش استاندارد آن زمان از فرآیند توسعه محصول که گاهاً چندین سال طول می کشد و نیازمند اطلاعات نیاز های مشتری بود، آغاز شد.

در سال 2001، مانیفست چابک منتشر شد و یک جایگزین بسیار مورد نیاز برای توسعه محصول کند ، اغلب نادقیق و مستند محور ارائه کرد. رویکرد چابک انقلابی بود زیرا تیم‌های محصول را تشویق می‌کرد تا در اندازه‌های دسته‌ای بسیار کوچک‌تر توسعه یابند. در نهایت، این امر به آنها آموزش داد تا محصولاتی بسازند که مشتریان بتوانند از آن استفاده کنند. درهمین زمان، طراحی UX و تفکر طراحی شتاب بیشتری به دست می‌آورد که توسعه محصول را به جای ذینفعان داخلی کسب‌وکار متمرکز می‌کند و تیم‌های محصول را بر آن می‌دارد تا یک سوال جسورانه و جدید بپرسند: مشتریان واقعاً چه می‌خواهند؟

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

چرا کشف محصول برای تیم های محصول ضروری است؟

ایجاد درک عمیق تر از مشتریان به تیم های محصول کمک می کند تا محصولاتی را ایجاد کنند که مشتریان می خواهند و به آنها نیاز دارند. این فرآیند به تیم‌ها امکان می‌دهد تا فراتر از ویژگی‌ها و محصولات «خوب داشتن» به سمت ساخت محصولاتی حرکت کنند که یک مشکل را حل می‌کنند و به یک نیاز واقعی برای مشتریان تبدیل می‌شوند.

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

مراحل کلیدی در فرآیند کشف چیست؟

  1. با درک نیازها و احساسات مشتریان، همدلی مشتری خود را تقویت کنید.
  2. با جمع سپاری دیدگاه های مختلف در تیم خود تصویر کاملی از مشتری خود ایجاد کنید.
  3. گوش کنید – واقعاً گوش کنید. میل طبیعی خود را برای عجله به راه حل سرکوب کنید و در عوض، در مورد مشکل اصلی مشتری فکر کنید.

ترزا تورس، مربی کشف محصول می گوید :

اغلب اوقات، ما به اولین راه حلی که به ذهن می رسد می چسبیم. مغز ما به طرز چشمگیری در بستن حلقه ،  مهارت دارد – وقتی در مورد مشکلی می شنویم، برای حل آن می پریم. اما اگر می‌خواهیم راه‌حل‌های خوبی پیدا کنیم، باید زمان بگذاریم تا مطمئن شویم که راه‌حل‌های ما متناسب با نیازهای خاص مشتریانمان است.»

  • برای وضوح، نقشه برداری بصری را امتحان کنید.
  • جمع آوری و سازماندهی بازخورد مشتری از کانال های ورودی مختلف را انجام دهید (به عنوان مثال، رسانه های اجتماعی، ایمیل، خدمات مشتری، تحقیقات کاربر، هیئت مشاوره مشتری، و غیره).
  • عینی باشید. آیا راه‌حل‌های بالقوه با مشکلات همسو هستند یا سوگیرانه هستید؟ به یاد داشته باشید: هر ایده ای باقی نمی ماند.
  • فرضیات خود را آزمایش کنید.

پس از کشف محصول، مرحله بعدی توسعه محصول است که شامل شناسایی نیاز بازار، تحقیق در مورد چشم انداز رقابتی، مفهوم سازی راه حل، توسعه نقشه راه محصول و ساخت حداقل محصول قابل دوام است.

ج – راهنمای گام به گام برای انجام بهتر کشف محصول

داتی شروک-02/22/22

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

خوشبختانه، راه بهتری وجود دارد.روند استاندارد برای اولویت بندی آنچه که تیم تحویل بر روی آن کار می کند به صورت زیر است:

اقتباس از Kevin on Code: http://bit.ly/2hOGtDI

اگر قبل از اینکه ایده‌ها را برای تحویل بفرستیم، سرمایه‌گذاری بیشتری روی تحقیق و اعتبارسنجی از قبل انجام دهیم، چه؟

فرآیند کشف محصول

ما این مسیر دوم را “کشف محصول” می نامیم و مکمل و قبل از تحویل محصول است.

مارتی کیگان افسانه ای چگونه آن را توصیف می کند:

     “اول، شما باید کشف کنید که آیا کاربران واقعی وجود دارند که این محصول را می خواهند یا نه… دوم، باید یک راه حل محصول برای این مشکل پیدا کنید که قابل استفاده، مفید و امکان پذیر باشد.”

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

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

مارتی کیگان چهار خطر بزرگ را در مدیریت محصول شناسایی می کند:

  • ریسک ارزش (خواه مشتریان آن را بخرند یا کاربران استفاده از آن را انتخاب کنند)
  • خطر قابلیت استفاده (این که آیا کاربران می توانند نحوه استفاده از آن را بفهمند)
  • ریسک امکان‌سنجی (این که آیا مهندسان ما می‌توانند آنچه را که ما نیاز داریم با زمان، مهارت‌ها و فناوری ما بسازند)
  • ریسک دوام کسب و کار (این که آیا این راه حل برای جنبه های مختلف کسب و کار ما نیز کار می کند)

فرآیند کشف محصول – 4 خطر

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

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

راهنمای گام به گام برای انجام کشف محصول

Productboard از رویکرد Double Diamond برای انجام کشف محصول استفاده می کند که ساختار آن به شرح زیر است:

     نیاز اساسی کاربر را کشف کنید

  • فهمیدن
    • تعريف كردن

     راه حل بهینه را شناسایی کنید

         ایده پردازی کنید

         نمونه اولیه بسازید

         تست کنید

بیایید هر قطعه را مرحله به مرحله تجزیه کنیم.

نیاز اساسی کاربر را کشف کنید

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

در مورد Productboard، یک چالش می تواند به شکل زیر باشد:

     چگونه می‌توانیم شرکت‌های بازار متوسط را قادر به استفاده بهتر از Productboard کنیم؟

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

در مرحله شناسایی چالش، آنچه را که می‌خواهید حل کنید را درک و تعریف می‌کنید.

فهمیدن و درک

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

تعريف كردن

پس از درک نیازهای کاربر که می‌خواهید به آنها رسیدگی کنید، باید آنها را به وضوح تعریف کنید. برای انجام این کار چند مرحله وجود دارد:

  • مشکل را حل کنید

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

  • مشکل را تأیید کنید:

مطمئن شوید که واقعاً روی مشکلاتی کار می کنید که باید حل شوند. دردی که کاربران شما تجربه می کنند چقدر است؟ واقعاً مقابله با درد چقدر ارزش اضافه می کند؟

  • اولویت بندی:

اساساً باید بفهمید که کدام یک از مشکلات شناسایی شده را ابتدا باید حل کنید. چندین فریمورک محبوب وجود دارد که توسط تیم های محصول برای انجام این کار استفاده می شود. در Productboard ما ارزش را در مقابل پیچیدگی ترجیح می دهیم، اما موارد دیگری مانند روش RICE، ICE و موارد دیگر وجود دارد.

فرآیند کشف محصول – ماتریس اولویت بندی

ماتریس اولویت‌بندی Productboard که بر اساس چارچوب اولویت‌بندی ارزش در مقابل پیچیدگی ساخته شده است.

برای تعریف واضح مشکلات، بسیاری از تیم های محصول از نقشه برداری سفر استفاده می کنند، به پنج چرا یا سایر تکنیک های مشابه می پردازند، یا تجزیه و تحلیل SWOT را انجام می دهند.

  • راه حل بهینه را شناسایی کنید

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

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

     شرکت‌های بازار متوسط محدودیت‌هایی را با پورتال عمومی Productboard تجربه می‌کنند، زیرا می‌خواهند با چندین مخاطب به طور همزمان ارتباط برقرار کنند.

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

  • ایده پردازی کنید

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

پس از ارائه ایده‌ها، تیم شما می‌تواند تأثیر بالقوه و امکان‌سنجی آن‌ها را بسنجد، سپس اولویت بندی کند که نمونه اولیه و ارائه آن به مشتریان.

  • نمونه اولیه

نمونه های اولیه تیم ها را قادر می سازد تا ایده های خود را به نمایش بگذارند و آنها را زنده کنند.

انواع مختلفی از نمونه‌های اولیه وجود دارد، از جمله طرح‌ها، مدل‌ها، نمونه‌های اولیه قابل کلیک، MVP یا حتی استفاده از محصولات رقابتی/مشابه.

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

  • تست

آزمایش تعیین می کند که آیا راه حل های پیشنهادی واقعاً قادر به حل مشکل هستند یا خیر. ابزارها و تکنیک‌های رایج در اینجا شامل تست A/B، مصاحبه با مشتری، تست کاربر، توزیع نظرسنجی و آزمایش بتا محصول است.

  • ارائه راهکارها

هنوز هیچ چیزی در مرحله راه حل ساخته نشده است، اما شما آماده ارائه ایده به ذینفعان و کاربران هستید. توجه داشته باشید که راه حل ها لزوماً با ویژگی ها برابر نیستند.

با بازگشت به مثال از Productboard، در اینجا یک راه حل قابل اجرا وجود دارد:

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

رسیدن به یک راه حل می تواند چندین بار تکرار شود. به هر حال، تیم محصول می‌خواهد مطمئن باشد که چیز درستی را به کاربران ارائه می‌کند. ارائه راه حل به ذینفعان در مورد Productboard، رهبری محصول، تیم های تحویل، و تیم های متقابل برای کسب درآمد و همسویی بسیار مهم خواهد بود.

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

نکته مفید

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

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

در فرآیند کشف محصول خود تعالی ایجاد کنید

در اینجا خلاصه ای از چگونگی تکامل Productboard از طریق این فرآیند کشف محصول آورده شده است:

     چالش: چگونه می‌توانیم شرکت‌های بازار متوسط را قادر به استفاده بهتر از Productboard کنیم؟

  • مشکل را دوباره طرح کنید:

شرکت‌های بازار میانی محدودیت‌هایی را با پورتال عمومی Productboard تجربه می‌کنند، زیرا می‌خواهند ایده‌های خود را همزمان با چند مخاطب به اشتراک بگذارند/تأیید کنند.

  • یک راه حل قابل اجرا را شناسایی کنید:

اجازه دهید مشتریان را قادر به ایجاد پورتال های متعددی کنیم تا بتوانند ایده های خود را با هر یک از مخاطبان خود به طور متفاوت به اشتراک بگذارند/ تایید کنند.

ما می‌خواستیم این چارچوب را به اشتراک بگذاریم زیرا بسیاری از تیم‌های محصول بیشتر وقت خود را صرف کار بر روی راه‌حل‌ها می‌کنند تا اینکه روی مشکلات کار کنند. و منطقی است. وسوسه انگیز است

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

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

https://www.productboard.com

د : ارزش های چابک

Agile Values به مجموعه ای از 4 ارزش اشاره دارد که توسط Agile Alliance در مانیفست چابک مشخص شده است. این مجموعه ارزش‌ها را تشویق می‌کند تا افراد را بر فرآیندها مقدم بدارند، نرم‌افزار را به سرعت ازیک مدار بسته خارج کنند، با مشتریان همکاری کنند و برنامه‌ها را در صورت نیاز تنظیم کنند.

 در زیر هر یک از 4 ارزش چابک را تجزیه و تحلیل می کنیم و توضیح می دهیم که چگونه ممکن است از دید مدیر محصول یا صاحب محصول تفسیر شوند.

افراد و تعاملات بر فرآيندها و ابزارها

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

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

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

نرم افزار کار بیش از مستندات جامع

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

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

همکاری مشتری بر سر قرارداد

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

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

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

پاسخ به تغییر پس از یک طرح گرافیکی که چرخه ساخت، اندازه گیری، یادگیری و تنظیم را به صورت پیوسته نشان می دهد.

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

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

به یاد داشته باشید: ارزش های چابک قوانین نیستند

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

آیا این نوشته برایتان مفید بود؟

مطالب مرتبط

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *