<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های HamidReza Ireh</title>
        <link>https://virgool.io/feed/@ireh</link>
        <description>http://ireh.ir (Software Developer)</description>
        <language>fa</language>
        <pubDate>2026-06-19 06:25:11</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/159017/avatar/rXrfYT.jpeg?height=120&amp;width=120</url>
            <title>HamidReza Ireh</title>
            <link>https://virgool.io/@ireh</link>
        </image>

                    <item>
                <title>تجربه اولین مشارکت در یک پروژه open source (متن‌باز)</title>
                <link>https://virgool.io/@ireh/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%A7%D9%88%D9%84%DB%8C%D9%86-%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA-%D8%AF%D8%B1-%DB%8C%DA%A9-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%A7%D9%88%D9%BE%D9%86-%D8%B3%D9%88%D8%B1%D8%B3-utq7k23fgmfp</link>
                <description>داستان از جایی شروع شد که نیاز داشتیم مدیر سیستم بتونه بر اساس تمام فیلدها جستجو بکنه برای همین یک بررسی کردم و به یک پروژه روی گیت هاب رسیدم، به نظر جالب بود و نیاز ما رو پوشش می داد برای همین یک fork ازش گرفت و شروع کردم به بررسی که مشکل امنیتی نداشته باشه، در نهایت یک lib ازش گرفتم و به پروژه خودمون اضافه کردم، کمی که پیش رفتیم از طرف تیم نیازمندی هایی برای جستجو گزارش شد که نداشتیم، رفتم روی گیت هاب و دیدم یک issue هم دقیقا مشابه نیازمندی ما ایجاد شده، تصمیم گرفتم که شروع کنم انجام بدم تا هم نیاز تیم ما برطرف بشه و هم نیاز دیگران، ولی یک موضوعی بود، پروژه به زبان kotlin بود و تا حالا با این زبان کد نزده بودم.خیلی سخت نبود و همون روز اول کد رو زدم و با تست های ساده یک lib گرفتم و به پروژه خودمون اضافه کردم ولی داستان این بود که برای پذیرش کد جهت merge شدن شرایطی داشت که باعث شد با چندتا چیز آشنا بشم.مهمترین اتفاق برای من تعامل با یک فرد غیر ایرانی در خصوص یک پروژه بود، اینکه کد من رو بررسی می کرد و مواردی رو می گفت حس جالبی بود.موضوع بعدی قوانینی بود که باید از نظر syntax رعایت می شد و این باعث می شد کدها یک دست باشه چیزی که تا حالا من تو شرکت های ایرانی که کار کردم ندیده ام.موضوع آخر قوانین تعریف شده برای تعداد تست ها جهت پوشش تمام شرایط بود، یعنی اگر کدی اضافه بشه باید تست هاش حداقل شرایط تعریف شده رو پوشش بده، برای این منظور از jacoco استفاده کرده بودن.کلام آخراگر یک توسعه دهنده نرم افزار هستین پیشنهاد می کنم حتما مشارکت روی پروژه های اوپن سورس که مدیریت اون با یک فرد غیر ایرانی هست رو تجربه کنید اگر وابسته به یک شرکت خارجی باشه چه بهتر، این کار باعث میشه به شیوه کد زدن و کار در تیم های خارجی تا حدودی آشنا بشین.از ابزارهای تست و آنالیز کد استفاده کنید و سعی کنید کد زدن اصولی رو یاد بگیرین و یادگیری اصول کد نویسی تمیز، الگوهای طراحی و ... رو فراموش نکنید.</description>
                <category>HamidReza Ireh</category>
                <author>HamidReza Ireh</author>
                <pubDate>Fri, 12 Mar 2021 22:42:51 +0330</pubDate>
            </item>
                    <item>
                <title>پیامدهای بدهی فنی</title>
                <link>https://virgool.io/@ireh/%D9%BE%DB%8C%D8%A7%D9%85%D8%AF%D9%87%D8%A7%DB%8C-%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-dwvb4giunfif</link>
                <description>با افزایش سطح بدهی فنی، شدت پیامدهای آن نیز افزایش می‌یاید. در ادامه تعدادی از برجسته‌ترین پیامدهای سطوح بالای بدهی فنی را بررسی می‌کنیم.پیشنهاد میکنم ابتدا پست بدهی‌فنی را مطالعه کنید.نقطه‌ی اوج غیرقابل پیش‌بینیاز خصوصیات مهم بدهی فنی، افزایش غیر قابل پیش‌بینی و غیر خطی آن است. اضافه شدن هر بدهی فنیِ کوچک به مجموعه‌ی بدهی‌های فنی موجود معمولاً منجر به خسارت قابل توجهی می‌شود که با اندازه‌ی این بدهی جدید قابل مقایسه نیست. در برخی موارد بدهی فنی باعث ایجاد نوعی «جِرم بحرانی» می‌شود تا جایی که محصول به نقطه‌ی اوجی می‌رسد که در آن نقطه، بی‌نظم و غیرقابل مدیریت می‌شود. غیرخطی بودن، ریسک مهمی در کسب‌وکار به شمار می‌رود؛ چون معلوم نیست که کدام اتفاق بدِ بعدی همه چیز را نابود خواهد کرد، اما اگر این اتفاق روی دهد، همه چیز با هم و یکجا خراب خواهد شد.افزایش زمان تحویلبدهی فنی مانند وامی است که امروز دریافت می‌کنید و در ازای آن باید کاری را در آینده انجام دهید. هر چه امروز بدهی بیشتری داشته باشید، فردا سرعت کمتری خواهید داشت. زمانی که سرعت کاهش می‌یابد، تحویل ویژگی‌های جدید و خطاهای رفع شده به مشتری نیز بیشتر طول می‌کشد و در نتیجه، با داشتن بدهی فنی زیاد عملاً زمان تحویل‌ها به جای کاهش، افزایش می‌یابد. اگر بازار فروش محصول، بازاری رقابتی باشد، بدهی فنی دقیقاً نقش رقیب و دشمن ما را بازی می‌کند و بر ضد منافع ما می‌جنگد.تعداد زیاد نقص‌هامحصولاتی که بدهی فنیِ قابل توجهی داشته باشند پیچیده‌تر می‌شوند و این موضوع شرایط را برای انجام درست کارها دشوارتر می‌کند. ترکیب نقص‌ها می‌تواند باعث خرابی‌های اساسی با فرکانس‌های شدید برای محصول شود. چنین خرابی‌هایی باعث ایجاد اختلال بزرگی در جریان طبیعی و ارزش آفرین توسعه می‌گردند. به علاوه، سربار مدیریت این همه نقص باعث کاهش زمان تولید ویژگی‌های با ارزش برای مشتری می‌شود. گاهی در حال غرق شدنیم اما آنقدر گرم فرو رفتن در باتلاق نقص‌ها هستیم که نمی‌توانیم راهی برای خلاص شدن از منجلابی که در آن گرفتار شده‌ایم، پیدا کنیم.افزایش هزینه‌های توسعه و پشتیبانیبا افزایش بدهی‌فنی، هزینه‌های توسعه و پشتیبانی شروع به افزایش می‌کند. کاری که قبلاً ساده و کم هزینه بود، پیچیده و پر هزینه می‌شود. با افزایش سطح بدهی فنی، حتی تغییرات کوچک نیز بسیار پرهزینه می‌شوند. زمانی که منحنی «بدهی‌فنی زیاد» با شیب تند بالا می‌رود، به جرمی بحرانی از بدهی فنی می‌رسیم و در نقطه اوج قرار می‌گیریم. برای ادامه کار گزینه‌های «توسعه‌ی یک ویژگی جدید» و «اصلاح یک نقض» وجود دارد. افزایش هزینه‌های می‌تواند موجب تغییر در مباحث اقتصادی و هزینه‌های مربوط به انتخاب یکی از این دو گزینه گردد. اگر بدهی‌فنی کم باشد، ساخت یک ویژکی یا رفع یک نقص کم‌هزینه است، اما همین کار در صورتی که بدهی‌فنی زیاد باشد، بسیار پرهزینه خواهد بود. نتیجه‌ی افزایش هزینه‌ها، انطباق پذیری کمتر محصولات در محیط درحال رشدی است که ناگزیریم در آن حضور داشته باشیم.آتروفی محصولاگر افزودن ویژگی‌های جدید یا اصلاح نقص‌ها که می‌تواند محصول سالخورده‌ی ما را جوان کند، متوقف شود، محصول آرام آرام جذابیت خود را برای مشتریان فعلی و مشتریان بالقوه از دست می‌دهد. در نتیجه محصول رفته رفته دچار آتروفی می‌شود و به راحتی جایگاه خود را به عنوان گزینه‌ای موفق نزد اکثر مشتریان از دست می‌دهد. آنهایی هم که همچنان با محصول کار می‌کنند، برای مدت کوتاهی و از روی ناچاری آن را تحمل می‌کنند. اما در اولین فرصتی که بتوانند محصول نویی را جایگزین آن کنند، حتماً این کار را خواهند کرد.کاهش قابلیت پیش‌بینیدر محصولی که سطح بدهی‌فنی در آن زیاد است، امکان هرگونه پیش‌بینی تقریباً غیر ممکن است. برای نمونه حتی برآوردهای باتجربه‌ترین افراد تیم نیز برآوردهای بسیار نادرستی خواهد شد. در واقع در هر محصول ورشکسته یعنی محصولی که بدهی‌اش بیشتر از توان پرداخت تیم است، عدم قطعیت زیادی درباره‌ی مدت زمان انجام کارها وجود دارد. در نتیجه توانایی تیم در تعهدسپاری و انتظار منطقی از انجام آنها دچار مشکل جدی می‌شود. کسب‌وکار اعتمادش را به تیم‌توسعه از دست می‌دهد و به دنبال آن، مشتریان نیز اعتماد خود را به کسب‌وکار از دست می‌دهند.افت کاراییمتأسفانه با افزایش بدهی فنی، انتظار افراد از کارایی تیم توسعه و حتی کارهای قابل انجام نیز بیش از  پیش کاهش می‌یابد. البته کاهش یافتن انتظارات در زنجیره‌ی ارزش شروع می‌شود و به همه جای آن سرایت می‌کند که نتیجه آن افت کارایی در کل سازمان خواهد بود.ناامیدی عمومینا امیدی افراد حاضر در زنجیره ارزش، یکی از پیامدهای تأسف‌بار و انسانیِ بدهی‌فنی بالاست. زمانی که همه‌ی میانبرهای (بدهی‌های فنی) کوچک اما آزاردهنده روی هم انباشته شوند، کار بر روی محصول را سخت و رنج‌آور می‌کنند. در نهایت لذت توسعه از بین می‌رود و جای خود را به خستگی و اعصاب خردی هر روزه می‌دهد که ناشی از مسائلی‌اند که محل مناقشه و دعوا هستند و هیچکس حاضر به حل و فصل آنها نیست. افراد به شدت احساس خستگی می‌کنند و دیگر قادر به ادامه‌ی کار نیستند. اعضایی از تیم توسعه که به کار مسلط هستند و دانش محصول در اختیار آنهاست، شروع به ترک تیم می‌کنند تا فرصت‌های شغلیِ راضی کننده‌تری پیدا کنند. در واقع این افراد بهترین گزینه برای رفع مشکلات فنی هستند و خروج آنها از تیم، اوضاع را برای افراد باقی مانده بدتر می‌کند. روحیه افراد به سرعت و با شدتی بیش از پیش کاهش می‌یابد.بدهی فنی نه تنها شادی و لذت را از فنی می‌گیرد، بلکه تأثیر مشابهی روی افراد کسب‌وکار دارد. تا کی می‌خواهیم به دادن تعهداتی که نمی‌توانیم آنها را انجام دهیم، ادامه دهیم؟ چه بر سر مشتریان بیچاره‌ی ما که می‌خواهند کسب‌وکار خود را با محصول ورشکسته‌ی ما اداره کنند، خواهد آمد؟ آنها نیز به سرعت از خرابی‌های پی در پی محصول و وعده‌های سرخرمن ما خسته می‌شوند. اعتمادی که زمانی در زنجیره‌ی ارزش وجود داشت، جای خود را به نا امیدی و ناراحتی می‌دهد.کاهش رضایت مشتریبا افزایش ناامیدی مشتریان، میزان رضایت آنان نیز کاهش می‌یابد. بنابراین وسعت خرابی ناشی از بدهی فنی فقط به تیم توسعه یا حتی کل سازمان توسعه محدود نمی‌شود، بلکه حتی بدتر از آن می‌تواند به شکل قابل ملاحظه‌ای روی مشتریان و برداشت آنان از ما تأثیر بگذارد.کنی اس. روبین</description>
                <category>HamidReza Ireh</category>
                <author>HamidReza Ireh</author>
                <pubDate>Sun, 26 Apr 2020 02:57:57 +0430</pubDate>
            </item>
                    <item>
                <title>بدهی فنی</title>
                <link>https://virgool.io/@ireh/%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-e6znwpzcaqnb</link>
                <description>مفهوم بدهی فنی نخستین بار توسط کانینگهام مطرح شد. وی بدهی فنی را اینگونه تعریف کرد: وقتی کدی را برای اولین بار تحویل می‌دهید مثل این است که خود را بدهکار کرده باشید. هر بدهی کوچک باعث افزایش سرعت توسعه می‌شود به شرطی که آن را در اسرع وقت و با بازنویسی کد، بازپرداخت کنید. زمانی این موضوع خطرناک می‌شود که بدهی بازپرداخت نشود. هر دقیقه‌ای که از عمر این کد که کاملا درست نوشته نشده است می‌گذرد، مانند بهره‌ای است که به بدهی قبلی افزوده می‌شود. شرکت‌های مهندسی زیر فشار بدهی ناشی از بی‌توجهی به اینگونه پیاده‌سازی‌های بازنویسی نشده ممکن است زمین‌گیر شوند و پیشرفت آنها متوقف شود.کانینگهام برای این که به تیم کسب‌وکار خود نشان دهد ساخت سریع نرم‌افزار برای دریافت بازخورد روش خوبی است، از استعاره‌ی بدهی فنی استفاده کرد. برای این کار، وی بر دو نکته‌ی کلیدی تأکید کرده است: اول آن که تیم و سازمان باید با افزایش درک و شناخت خود از حوزه‌ی کسب‌وکار، مراقب بازپرداخت بدهی‌ها باشد و دوم آن که با افزایش شناخت تیم و برای استفاده از آموخته‌های جدید، طراحی و پیاده‌سازی سیستم باید تغییر کند و تکمیل گردد.از زمان معرفی این واژه در اوایل دهه‌ی 1990، صنعت نرم‌افزار برداشت‌های آزادی از تعریف کانینگهام داشته است. امروزه بدهی فنی، هم به میانبرهایی که آگاهانه و عامدانه انتخاب می‌شوند و هم به موضوعات نادرستی که به سیستم نرم‌افزاری آسیب می‌زنند گفته می‌شود. این موضوعات شامل موارد زیر هستند:طراحی نامناسب یا بد: بخشی از طراحی که زمانی معقول و قابل بود، اما به دلیل تغییرات مهم کسب‌وکار یا تکنولوژی، دیگر معقول و قابل قبول نیست.نقص‌ها: مشکلات شناخته شده‌ای در نرم‌افزار که تاکنون زمانی برای رفع آنها گذاشته نشده است.پوشش ناکافیِ آزمون‌ها: بخش‌هایی که می‌دانیم به آزمون‌های بیشتری نیاز دارند اما تاکنون کاری برای آنها انجام نداده‌ایم.آزمون دستیِ بیش از حد: آزمون‌ها دستی انجام می‌شود در حالی که باید خودکار شوند.یکپارچه‌سازی و مدیریت ضعف انتشار: این فعالیت‌ها به گونه‌ای انجام می‌شوند که زمانبر و خطازا هستند.کم تجربگی در استفاده از سکو: برای نمونه برنامه‌های کاربردی برای رایانه‌های بزرگ و به زبان کوبول نوشته شده‌اند، در حالی که برنامه‌نویس باتجربه و مسلط به کوبول به تعداد کافی نداریم.و موارد دیگری از این دست؛ چرا که امروزه اصطلاح بدهی فنی به عنوان استعاره‌ای برای بیان مشکلات چند وجهی مورد استفاده قرار می‌گیرد.کانینگهام قصد نداشت که با «بدهی فنی» به نبود بلوغ در تیم و کسب‌وکار یا کاستی‌های فرایند اشاره کند و آن را دلیل بی‌نظمی در طراحی، استفاده از تجربه‌های ضعیفِ مهندسی و کمبود آزمون‌ها بداند. این نوع از بدهی‌ها را می‌توان با آموزش صحیح، درک روش درست به کارگیری تجربه‌های فنی و تصمیم‌گیری‌های منطقی در کسب‌وکار رفع نمود. به دلیل ماهیت غیر مسئولانه و غالباً تصادفیِ ایجاد این گونه از بدهی، آن را «بدهی ناشی از بی‌تجربگی» یا به اختصار «بدهی بی تجربگی» می‌نامیم. این بدهی با نام‌های دیگری مانند بدهیِ بی‌دقتی، بدهی غیرارادی و زباله نیز شناخته می‌شود.علاوه بر این، نوع دیگری از بدهی به نام «بدهی فنی اجتناب‌ناپذیر» نیز وجود دارد که معمولا غیر قابل پیش‌بینی و غیرقابل پیشگیری است. برای نمونه، شناخت ما از «طراحی خوب» در ابتدا کاملاً مشخص نیست و پس از پیاده‌سازی ویژگی‌های باارزش برای کاربران و مبتنی بر طراحی انجام شده، تازه به میزان خوب یا بد بودن طراحی پی می‌بریم. نمی‌توانیم مسیر تکامل و تغییر محصول و طراحی آن را به صورت کامل، از پیش و در ابتدا پیش‌بینی کنیم. بنابراین ممکن است تصمیم‌های طراحی و پیاده‌سازی که زود گرفته شده‌اند با بسته شدن حلقه‌های مهم یادگیری و کسب یادگیری معتبر نیاز به تغییر داشته باشند.تغییرات ایجاد شده در بخش‌های که تحت تأثیر قرار گرفته‌اند در دسته‌ی بدهی‌های فنی اجتناب‌ناپذیر قرار می‌گیرند.به عنوان نمونه‌ای دیگر فرض کنید مؤلفه‌ی شرکت ثالثی را خریداری کرده‌ایم و از آن در محصول استفاده کرده‌ایم. به مرور زمان رابطه‌های این مؤلفه تغییر کرده‌اند و کامل‌تر شده‌اند. محصول ما که زمانی به خوبی با این مؤلفه کار می‌کرد دچار نوعی بدهی فنی می‌شود که ما مقصر آن نیستیم. اگرچه این بدهی ممکن است قابل پیش‌بینی باشد( این که سازنده‌ی مؤلفه، رابطه‌های آن را به مرور تغییر خواهد داد، خیلی هم دور از ذهن نیست)، اما قابل پیشگیری نیست زیرا نمی‌توانیم پیش‌بینی کنیم که توسعه‌دهندگان مؤلفه چگونه آن را در آینده تغییر خواهند داد.آخرین نوع بدهی‌فنی، «بدهی‌فنی استراتژیک» است. این نوع بدهی ابزاری است که می‌تواند به بهبود اندازه گیری‌های کمّی و استفاده از مباحث اقتصادی در تصمیم‌گیری‌های مهم و فوری کمک کند. برای نمونه، شرکتی آگاهانه و عمداً تصمیم استراتژیکی می‌گیرد که میان‌بری را در توسعه محصول انتخاب کند تا به یکی از اهداف مهم و کوتاه‌مدت خود دست یابد. به عنوان نمونه‌ای از این اهداف می‌توان به عرضه پیش از موعدِ محصولی به بازار اشاره کرد که زمان عرضه‌ی آن بسیار حساس است و اهمیت فوق‌العاده‌ای دارد. در سازمانی که سرمایه‌ی محدودی دارد و با خطر اتمام منابع مالی قبل از تکمیل محصول مواجه است، تنها راه جلوگیری از نابودی سازمان، عرضه محصول با وجود بدهی‌فنی به بازار است. در ابتدا از هزینه‌ی توسعه چنین محصولی کاسته می‌شود تا سازمان پس از کسب درآمد بتواند به توسعه‌ای مداوم و خودکفا دست یابد.صرف نظر از چگونگی افزایش بدهی‌فنی، این اصطلاع، استعاره‌ی بسیار مؤثری است، زیرا آگاهی افراد را افزایش می‌دهد و دید آنها را نسبت به موضوع مهمی باز می‌کند. این استعاره در ذهن افراد حوزه‌ی کسب و کار که علاقه‌ی زیادی به کسب مهارت در زمینه‌ی وام و بدهی‌های مالی دارند، به خوبی جا می‌افتد. زمانی که آنها اصطلاح بدهی‌فنی را می‌شنوند، بی‌درنگ تأیید می‌کنند که لازمه‌ی بدهی، پرداخت بهره است و این بهره، خود را به شکل کارهایی نشان می‌دهد که در آینده به کارهای توسعه اضافه می‌شود. وقتی که بدهکاریم، دوگزینه پیش روی ماست: می‌توانیم کماکان به پرداخت بهره ادامه دهیم (با پرداختن به حواشی مشکلات) یا اینکه اصل بدهی را پرداخت کنیم (مثلاً کد را بازسازی کنیم تا قبل از تغییر بعدی، تمیزتر و ساه شود).کنی اس. روبین</description>
                <category>HamidReza Ireh</category>
                <author>HamidReza Ireh</author>
                <pubDate>Fri, 17 Apr 2020 23:50:31 +0430</pubDate>
            </item>
                    <item>
                <title>دام‌های مذاکره</title>
                <link>https://virgool.io/@ireh/%D8%AF%D8%A7%D9%85%D9%87%D8%A7%DB%8C-%D9%85%D8%B0%D8%A7%DA%A9%D8%B1%D9%87-buwhuueg0ljj</link>
                <description>همه ما تجربه مذاکره داریم، مذاکره‌هایی که برای کسب ویا حفظ منافع خودمون از کودکی در رفتار ما پدیدار شد و با گذشت زمان و کسب تجربه در آن پیشرفت کردیم. اما شخصاً اعتقاد دارم هر تجربه‌ای را با کسب دانش می‌توان به یک مهارت بهتر تبدیل کرد. مذاکره دارای ابعاد، پیچیدگی و آدابی هست که پیشنهاد می‌کنم، سعی کنید این اصول رو از منابع خوب یاد بگیرید؛ اگر در کلاس درسی حاضر می‌شوید حتما استاد آن کلاس تجربه کار عملی و دارای اطلاعات به روز باشد.در ادامه قصد دارم، ترفند‌ها و حیله‌های مذاکراتی، یکی از بخش‌های جذاب کتاب &quot;اصول، فنون و هنرهای مذاکره با نگرش بازار ایران&quot; هست رو براتون بنویسم تا به عنوان یک مذاکره کننده بتوانید جلوی حیله‌های طرف مقابل را بگیرید. این کتاب به قلم استاد خوبم دکتر محمدحسین غوثی و پرویز درکی می‌باشد و پیشنهاد می‌کنم آن رو تهیه و مطالعه کنید.1) روش محدودیت اختیار یا اختیار مشکوکباید دانست که مذاکره با افراد بدون اختیار کافی، نتیجه‌ی مذاکرات را به تباهی می‌کشاند. در ضمن باید دقت کرد که گروه خودی نیز بایستی با اختیارات مشخص از پیش تعیین شده که کاملاً برای افراد توجیه شده باشد، در جلسات شرکت جویند. تشخیص اختیار افراد بعضاً به سادگی صورت نمی‌پذیرد. در مذاکرات بیت المللی، مذاکره کنندگان عمدتا برگه‌ای به نام اختیارنامه دارند که محدوده‌ی اختیار طرف را برای مذاکره و توافق به طور کامل تشریح می‌کند. در بسیاری مواقع به رغم سؤال از طرف برای تشخیص میزان اختیار وی و حصول اطمینان از اینکه فردی دارای اختیار کافی است، در انتهای جلسه طرف مقابل برای برون رفت از توافق احتمالی یا خرید زمان بیشتر برای کسب اطلاعات یا تفکر بیشتر، عنوان می‌کند که مثلاً بایستی با رؤسا یا همکاران خود پیرامون این مطلب مشورت، و یا کسب تکلیف کنند. این تکنیک که خود یکی از حیله‌های مذاکراتی است، به نام روش &quot;اختیار مشکوک&quot; نامیده شده است که فرد می‌خواهد با خرید زمان بیشتر، امتیاز بیشتری را در آینده طلب کند یا در برخی مفاده قرارداد، تغییرات یکطرفه‌ای را اعمال کند.دو تکنیک برای برخورد با این روش موجود است؛ روش اول تقاضای مذاکره با فرد مافوق یا فرد مورد نظر است؛ یعنی اصطلاحاً رتبه مذاکره را یک درجه بالاتر ببریم. در اغلب موارد چون فرد صرفاً یک بلوف زده است، مجدداً به توافق بر می‌گردد ولی در بعضی مواقع ما قادر نیستیم با فرد مافوق ملاقات کنیم و به‌رغم تلاش ما، امکان برقراری جلسه در آینده نزدیک نیز فعلا فراهم نشده اسن. در چنین مواقعی، کار را به صورت توافق مشروط ادامه می‌دهیم؛یعنی به فرد می‌گوییم حالا که شما می‌خواهید با رؤسای خود پیرامون این مطلب مشورت کنید، ما نیز فرصت را مغتنم شمرده و سعی می‌کنیم با همکاران و مشاوران خود مشورت کنیم، این جمله بدان سبب گفته می‌شود که اگر طرف مقابل بعداً برخی از توافق‌های انجام شده را تغییر داد، ما هم فرصت تغییر دادن برخی از بندها را به نفع خود ایجاد کرده باشیم. همان‌طور که گفته شد، این روش را &quot;توافق مشروط&quot; می‌نامیم.2) روش پرش از مانع(سالامی)در این روش، فرد تقاضای خود را نه به صورت یکجا بلکه، به صورت برش برش (همانند کالباس) از طرف درخواست می‌کند و پس از دریافت هر جواب مثبت، درخواست بعدی را مطرح می‌کند. این حیله بدین منظور انجام شود که امتیاز متوالی و فراوان بدون اینکه حساسیتی را برانگیزد از طرف دریافت شود.برای مقابله با این روش کافی است پس از هر درخواستی، از فرد بپرسیم آیا چیز دیگری برای درخواست دارد یا خیر؟ با این کار موجب می‌شوید که فرد تمامی درخواست‌های خود را یکجا مطرح کند و قادر نباشد در مقاطع بعدی چیزی به آن بیفزاید یا از آن بکاهد. پس از جمع‌آوری کردن تمامی درخواست‌های طرف، می‌توان با آن به صورت یک بسته یا پکیج برخورد کرد.3) روش تهاجمی و تهدیددر مواقعی که مورد تهدید یا تهاجم قرار می‌گیرید، موارد زیر را اجرا کنید:تهدید را قبول نکنید، اگر فرد منطقی باشد تهدید نمی‌کند.تهدید را رد نکنید، چون موجب بدتر شدن اوضاع خواهد شد.تهدید مقابل نکنید.با دوستان خود در آن موقع مشورت نکنید.درخواست تعویق مذاکره را نکنید.انجام دو مورد آخری دال بر ترس و مؤثر واقع شدن تهدید است. آنچه باید انجام دهیم، در وهله‌ی اول حفظ آرامش و صبر است. باید به این مطلب اعتقاد داشت که انسان پرخاشگر و بی نزاکت، همواره بازنده است.پس سعی کنید جو غالب را از بین ببرید تا در عین حالی که برخورد مقابل نکرده‌اید، طرف مقابل نیز حس نکند از تهدیدهای وی ترسیده‌اید. در ضمن می‌توان به عملی که فرد دارد انجام می‌دهد اشاره کرد. تجربه ثابت کرده است که اشاره به عمل فرد موجب می‌شود طرف دست از آن کار بردارد.4) در سالن مذاکره روبه‌روی نور، تابلوهای اثر گذار منفی یا  در وضعیت پایین‌تر قرار داده می‌شوید.این عملیات برای خسته کردن و در موضع ضعف قرار دادن طرف انجام می‌پذیرد تا بتوان امتیاز زیادی را از وی گرفت. در اینگونه مواقع تا وضعیت مذاکره اصلاح نشود، به هیچ وجه مذاکره نکنید.5) سیاست جنازهسیاست جنازه یعنی ارائه‌ی پیشنهادات مکرر از سوی یکی از طرفین مذاکره و عدم واکنش طرف دیگر مذاکره به پیشنهادات داده شده. در این تکنیک، طرف دوم با عدم اظهارنظر در مورد پیشنهادات طرف مقابل و اصطلاحاً نقش جنازه را بازی کردن، سعی می‌کند تمامی مواضع طرف مقابل را رو کرده و از بین پیشنهادات موجود بهترین را برای خود انتخاب کند.این سیاست موجب رو شدن موضع طرف و از دست رفتن امتیازات فراوان می‌شود. برای مقابله با سیاست جنازه، پس از عدم قبول پیشنهاد اول از سوی طرف، توپ را در زمین او بیندازید و از او درخواست کنید پیشنهاد دوم را ارائه کند و تا زمانی که پیشنهاد دوم را نداده است اقدامی برای ارائه‌ی پیشنهادات بعدی نکنید.6)بازی تکراری آدم خوب، آدم بددر هنگام توضیح انواع نقش‌های مذاکره، به نقش‌های خوب و بد اشاره شد. همانطور که قبلاً نیز گفته شد، این نقش‌ها هر دو در جهت رسیدن به یک هدف تلاش می‌کنند، با این تفاوت که آدم بد ابتدا با تحت فشار قرار دادن و ترساندن طرف موجب می‌شود که فرد در موضع انفعال و ترس قرار گیرد و سپس آدم خوب با پادرمیانی و با ترفند وساطت بین دو نفر، وارد قضیه می‌شود و سعی می‌کند در حالت آرامش، فرد را به ارائه امتیازات و اینکه نباید کار را سخت گرفت هدایت کند.نحوه بر خورد با این ترفند، پافشاری روی موضع اصولی خود و درخواست دلیل و معیار عینی از طرف است. اشاره کردن به تکنیک مورد استفاده هم بسیار کارساز است.7) در گوشی صحبت کردن یا رد و بدل کردن فراوان یادداشتاین عمل به منظور در نظر نگرفتن شخصیت طرف انجام می‌گیرد و بهترین درمان آن سکوت در حین انجام این اعمال است. در ضمن گاهی اوقات می‌توان به فرد یادآور شد که در صورت تمایل یا گرفتار بودن وی، می‌توان جلسه را به زمان دیگری انداخت. البته این کار در زمانی اتفاق بیفتد که امکان برگزاری جلسه‌ی بعدی خیلی سخت نباشد یا طرف خودی به نتیجه‌ی مذاکرات زیاد تمایل نباشد.8) روش چماق و هویج(تهدید و تطمیع)این روش که به روش تنبیه و پاداش نیر معروف است، به این شکل اعمال می‌شود که به طرف دو راه نشان داده می‌شود، یک راه تشویق و پاداش و یک راه تنبیه، و هدف این است که اگر روش مورد نظر فرد انتخاب نشود، مورد تنبیه قرار گرفته و در صورت تبعیت از او پاداش می‌گیرد.باید دانست در صورت انتخاب روش پاداش، به فرد هیچ وقت پاداشی تعلق نخواهد گرفت.9) قطع مذاکراتاین روش برای ارزیابی میزان علاقه طرف به نتیجه مذاکرات انجام می‌گیرد، بدین‌رو باید در نظر داشت به‌رغم علاقه‌ی زیاد به نتیجه‌ی مذاکره، بایستی از ابراز آن به طرف مقابل خودداری به عمل آورد؛ چون مورد سوء استفاده قرار خواهد گرفت.10) شوکه کردنبا ذکر مطالب و اطلاعات ناگهانی، موجب شوکه شدن طرف می‌شوند تا تمرکز را از موضع مذاکره منحرف کنند. فرد در اینگونه موارد بایستی قدرت کنترل احساسات و محیط پیرامون خود را داشته باشد.11) تعویض مذاکره کنندگانبه منظور خارج کردن مذاکره از بن‌بست با جبران اشتباهات نفرات قبلی صورت می‌پذیرد. باید دانست این‌کار معمولاً با هزینه‌های سنگینی برای گروه تعویض کننده همراه است، بنابراین استفاده از آن توصیه نمی‌شود.12) نعل وارونهمراد از نعل وارونه، گذاشتن ردپای نعل اسب رو به سمت شمال و حرکت اسب به سمت جنوب است. این تکنیک برای انحراف از موضوع اصلی انجام می‌شود و به صورت مطرح کردن موضوعال فرعی صورت می‌پذیرد.13) سؤال مچ گیراین روش برای ارزیابی موضع طرف مقابل بدون افشای جزئیات طرح خود استفاده می‌شود.14) زخمی کردن کاردریافت توافق اولیه و موافقت با طرف و پس از قبول کار، اضافه کردن برخی پیشنهادات به آن.15) دام و جابجاییارائه پیشنهاد بزرگ و جذاب اولیه از سوی طرف و کم کردن برخی از پیشنهادات از آن.16) روش غیر قابل مذاکره(قرارداد مکتوب)در این روش، فرد مقابل با غیر قابل مذاکره نشان دادن قسمتی یا تمام موضوع مذاکره، سعی در قبولاندن موضوع مذاکره به طرف مقابل خود دارد بدون اینکه درگیر فرایند مذاکره شود. برای مقابله با این ترفند دو روش وجود دارد؛ پس اگر فردی یا گروهی به دنبال این مطلب است، حتماً هدف ناصوابی دارد.پس باید از او سؤال کرد که چرا مثلاً فلان مطلب غیرقابل مذاکره است. وقتی طرف مقابل در مورد دلایلش توضیح می‌دهد، به طور خودکار دارد در مورد مطلب غیرقابل مذاکره، مذاکره می‌کند.از این‌رو، این ترفند را می‌توان به سادگی خنثی کرد. روش دوم افزودن الحاقیه یا اصلاحیه به موضوعات یا قراردادهای غیر قابل تغییر است. از آنجا که الحاقیه‌ها و اصلاحیه‌های پس از قرارداد بر متن قرارداد نافذ هستند، افزودن آنها می‌تواند بدون تغییر دادن متن قرار داد، موضوع را به نفع شما تغییر دهد.17) پیش شرط گذاشتنیکی از روش‌های رایج مذاکرتی، پیش شرط گذاشتن است. باید دانست با قبول هر پیش شرطی، شرط دیگری در راه خواهد بود. از این رو باید دانست که قبول پیش شرط به هیچ وجه کاری حرفه‌ای نیست. از طرف دیگر به منظور مقابله با این روش باید بپرسیم در صورت قبول کردن یا قبول نکردن پیش شرط، چه اتفاقی می‌افتد؟ بنابراین می‌توان با تشخیص آینده‌ی کار، بهترین حالت را برای خود انتخاب کنیم.18) من بیچارهتحریک دلسوری و خوش باوری طرف و سپس  بردن مذاکره به نفع خود. بسیاری از افراد هستند که با غیر مطلع نشان دادن خود از موضوع یا نوعی مظلوم نمایی، در صدد فریب مقابل و ادامه مذاکره به نفع هود هستند.19) آدم پوشالیدست برداشتن از یک موضوع بی اهمیت، به منظور به دست آوردن مسائل مهمتر. در این حالت فرد با فشار  آوردن بری روی موضوعات بی اهمیت، آنها را برای طرف خیلی با اهمیت جلوه می‌دهد و در نهایت با دست کشیدن از آنها به ظاهر لطف بزرگی را در حق طرف مقابل انجام می‌دهدد تا در انتها در مورد مسائل مهم مورد نظر خود توافق لازم را به دست آورد.20) وقت کشیبرای نزدیک شدن طرف به محدودیت زمانی و گرفتن امتیاز به کار می رود. همان‌طور که قبلاً نیز گفته شده است، در اینگونه موارد بایستی مواردی را که موجب ایجاد شتاب می‌شود حذف کنیم یا طرف را از محدودیت‌های زمانی خود آگاه نکنیم.21) به مرگ گرفتن، به تب راضی شدناین روش نسبتاً مشابه روش آدم پوشالی است.22) موقعیت استثناییدر اینگونه موارد فرد در مورد وضعیت موجود بسیار مبالغه کرده و اعلام می‌کند اگر در این وضعیت با وی توافق شود، امتیازات فراوانی را اعطا می‌کند و صراحتاً نیز اعلام می‌کند در زمانی غیر از وضعیت فعلی، توافق با امتیازات فعلی امکانپذیر نخواهد بود. معمولاً توافق در چنین شرایطی، به صلاح و به صرفه نخواهد بود.23) خلاصه کردنگاهی اوقات افراد در حین جمع بندی مطالب و نوشتن صورتجلسات، برخی از مفاد آن را به نفع خود تغییر می‌دهند. از این رو توصیه می‌شود بار نوشتن صورتجلسات را خود بر عهده بگیرید یا از امضای صورتجلسه‌ای که با توافقات انجام شده مغایرت دارد خودداری کرده و تقاضای تغییر صورتجلسه را کنید.24) سؤالات پی در پیدر این حالت فرد با سؤالات پی‌درپی، حالت بازرسی متهم را پیدا می‌کند و موضع مذاکراتی خود را برای دریافت امتیاز بیشتر، بالاتر می‌برد.25) دام کوری ناشی از تمرکز(Focus Blindness)شاید برای هر کسی اتفاق افتاده باشد که در حین تماشای یک فیلم تلویزیونی متوجه آگهی‌های تبلیغاتی که در زیر فیلم پخش می‌شود، نشده باشد یا برای حل یک سری مسائل ریاضی فقط از یک راه‌حل استفاده کند و از سایر راه‌حل‌ها، هر چند ساده‌تر استفاده نکرده باشد.این مثال‌ها و مثال‌هایی از این دست نشان می‌دهد که توجه عمیق به یک موضوع، گاهی از قدرت توجه ما به سایر موضوعات می‌کاهد. نکته، در ندیدن یا کم دقتی نیست؛ نکته در این است که توجه بیش از حد به یک راه‌حل یا موضوع، موجب عدم توجه به سایر راه‌حل‌ها یا موضوعات می‌شود و موجب می‌شود فرد در دام کوری ناشی از تمرکز بیفتد.برای جلوگیری از افتادن در دام کوری ناشی از تمرکز، بایستی از انتخاب اولین راه‌حل پیش‌رو به عنوان تنها را‌حل خودداری شود و به سایر راه‌حل‌ها نیز توجه کافی شود. از این رو لازم است گاهی اوقات، سرعت تصمیم‌گیری را پایین آورده تا امکان بروز فرصت برای دیدن سایر نقاط اطراف نقطه‌ی کور را فراهم کرد.26) دام باتنا(BATNA Trap)باتنا برگرفته از عبارت &quot;Best Alternative To Negotiated Agreement&quot; معادل &quot;بهترین جایگزین برای توافقات مذاکراتی&quot; است. به طور خلاصه، واژه &quot;باتنا&quot; را می‌توان معادل واژه &quot;حق انتخاب&quot; در نظر گرفت. هر چه تعداد باتناها بیشتر باشد، یعنی حق انتخاب و قدرت انتخاب بیشتر است. هر چه تعداد باتناها کمتر باشد، یعنی این حق و قدرت انتخاب کمتر است. در مذاکره، حق انتخاب‌ها یا تعداد باتناها هر چه بیشتر باشد، موضع مذاکره کننده بهتر است و مذاکره کننده هر چه حق انتخاب کمتری داشته باشد، از موضع ضعیف‌تری برخوردار خواهد شد. باتناها گرچه در ذات خود خوب هستند، ولی می‌توانند دام‌هایی را نیز سر راه مذاکره کننده پهن کنند. تعدادی از این دام‌ها عبارتند از:الف)کاهش سطح انتظاراتب)وسوسه اشاره به باتناج)دام بلوف در مورد باتناد)دام کاهش انگیزه‌ی مذاکره27) دام دیوار کاذب اعتمادنخستین استعمارگران به همراه خود مسیونرهای مذهبی را هم می‌بردند. دری را که برای دزدی بکوبند، گشوده نخواهد شد. بنابراین با نام خدایی که برادری و برابری را تبلیغ می‌کند، از قلب‌ها وارد می‌شوند و نیازی نیست افراد مختلفی در تعدد نقش‌ها حضور داشته باشند.نیازی نیست برای صحنه پردازی، دروغ گفت و یا نیازی نیست همواره نقش اصلی را پشت نقش‌های فرعی پنهان کرد. فقط کافی است، اصالت را از نقش‌ها گرفت. توجه کنید که خواسته و نیاز صاحب نقش در چیست؟ نگرش دقیق به نیاز‌های برآورده شده و نقش‌های ظاهر شده، شما را از دام تعدد نقش‌ها و بی اصالتی آنها می‌رهاند.28) دام لنگر(Anchor Trap)وقتی کسی از شما سؤال زیر را پرسید، چه جوابی خواهید داد؟آیا درست است پاداشی که به مدیران می‌دهند می‌دهند، 65درصد بالاتر از پاداش کارگران است؟ در سؤال فوق، بهترین تخمینی که در مورد تفاوت بین پاداش مدیران و کارگران می‌زنید، چند درصد است؟تحقیقات نشان داده است که رقم 65 درصد ذکر شده در سؤال اول که یک رقم بی اساس است، به میزان زیادی بر روی پاسخی که سؤال دوم داده می‌شود اثر می‌گذارد.ذهن ما در هنکام تصمیم گیری تمایل دارد، به سمت سنگین‌ترین و مبالغه آمیزترین اطلاعات داده شده، حرکت کند.</description>
                <category>HamidReza Ireh</category>
                <author>HamidReza Ireh</author>
                <pubDate>Fri, 10 Apr 2020 12:49:56 +0430</pubDate>
            </item>
                    <item>
                <title>چرخه PDCA چیست و چگونه از آن استفاده کنیم؟</title>
                <link>https://virgool.io/@ireh/%DA%86%D8%B1%D8%AE%D9%87-pdca-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A7%D8%B2-%D8%A2%D9%86-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-owsd9ikdqmvp</link>
                <description>یکی از روش های کارامد ارائه شده در بهبود مستمر، چرخه ی (PDCA) است که توسط والتر شوهارت طراحی و در محیط آکادمیک ارائه گردید است و بعد از آن ادوارد دمینگ با بکارگیری در کیس‌های مختلف عامل معروف شدن این چرخه گردید.همانطور که از نام چرخه مشخص است به صورت دایره وار و چرخشی کار خود را  انجام می‌دهد. چرخه ی PDCA را می توان در بخش‌های مختلف همچون بازاریابی، توسعه محصول جدید، افزایش فروش و رضایت مشتری، بهبود کیفیت، سیاست گذاری‌های بلند مدت و … به کار برد.چرخه PDCA از ابتدای کلمات Plan، Do، Check, Act گرفته شده است که به ترتیب به  معنی برنامه ریزی، عمل، بررسی و اقدام است. در حقیقت این چرخه،  یک چرخه کاری چهار مرحله ای است که برای انجام تغییرات و بهبود فرایندها  در کسب و کار می‌باشد.این چرخه با نام‌های دیگر نیز شناخته شده و مورد استفاده قرار می‌گیرد که از جمله آن میتوان به OPDCA، PDSA اشاره کرد.شاید جالب باشد بدانید O در مدل OPDCA از Observe می‌آید، همانطور که احتمالا می‌دانید در خیلی از Framework ها و Based Practice ها وقتی صحبت از بهبود مطرح می‌شود یکی از گام‌هایی اولیه که به عنوان یک اصل توصیه می‌شود، بحث مشاهده مستقیم هست. مثلا اگر می‌خواهید در یک حوزه‌ای بهبود و یا تغییری ایجاد کنید بهتر است اول آن را ببینید، بررسی کنید، از نزدیک با موضوع و مبحث آشنا شوید که بعد از آن بتوانید وارد مرحله Do و ... بشوید.1. برنامه ریزی(Plan ):وقتی صحبت از بهبود و رفع مشکل می شود حالا این مشکل و یا بهبود میتونه اصلاح یه فرایند یا بهینه کردن آن باشه یا سرعت پاسخ دهی رو سریع تر بکنیم، می خواهیم تعداد مشکلات به وجود آمد رو کمتر کنیم، میخواهیم رضایت مشتری رو افزایش بدهیم، میخواهیم هزینه‌ها رو کاهش دهیم؛  در هر حوزه که باشد مرحله اول با یک برنامه ریزی شروع می شود.نکته اولی که در برنامه ریزی وجود دارد، این هست که ما قطعا از ابتدا نمی‌توانیم در خصوص آن بهبودی که می خواهیم ایجاد کنیم وارد برنامه‌های عملیاتی شویم زیرا جزئیات خیلی مشخص نیست و باید اطلاعاتی رو جمع آوری کنیم، یک سری تحلیل‌هایی رو انجام بدیم تا بتونیم یک مسیر شفاف رو مشخص کنیم. اگر همه چیز اینقدر واضح باشد که در ابتدا بتوان گفت چه کاری باید انجام داد تا مشکل حل شود قطعا این مشکلات به وجود نمی آمد و یا قبل تر حل شده بود. نکته دیگری که وجود دارد این هست که برنامه ریزی برای خود پروژه بهبود انجام می دهیم. در این مرحله اصولا شواهد و قرائن کافی برای انجام بهبود نداریم، این نکته بسیار مهمی هست که باید بهش توجه کنیم. در این مرحله موضوع مطرح می‌شود مثال می‌خواهیم رضایتمندی مشتریان رو افزایش دهیم اما نمی دانیم چطوری!نکته‌ای که هست اصلا نمی‌دونیم مشتری چرا ناراضی هست، نمی‌دونیم چرا تعداد خطاهای زیادی داریم، ما نمی دونیم چرا هزینه‌هایی که داره به سازمان تحمیل میشه اینقدر زیاد هست.پس عملا در مرحله برنامه ریزی تعدادی سورس اطلاعاتی تعریف می‌کنیم تا دلیل چرایی‌ها رو متوجه بشویم، مثال می‌خواهیم بدونیم چرا مشتری ناراضی هست، یک پرسشنامه طراحی می‌کنیم و به صورت رندم با مشتریان تماس می‌گیریم و ازشون سوال می‌پرسیم، یا مثلا هزینه‌ها بالا هست، اطلاعات در خصوص جاهایی که داریم هزینه می‌کنیم و برای ما بالا هست رو مشخص می‌کنیم.این‌ها رو در مرحله برنامه‌ریزی تعریف می‌کنیم تا که بدونیم در ارزیابی رضایت مشتری چه کاری بکنم؟ برای شناسایی هزینه های شرکت چکاری بکنیم؟ برنامه ریزی رو با پاسخ به چند سوال مهم انجام می دهیم:چشم انداز و ماموریت سازمان؟حوزه مورد نظر جهت بهبود؟منابع اطلاعاتی جهت سنجش وضع موجود؟منابع قابل تخصیص؟محدودیت ها؟2. عمل(Do):بر خلاف تصور عموم، این گام اجرای برنامه ریزی انجام شده نیست، بلکه انجام اقدامات اولیه جهت بستر سازی مناسب در راستای تحقق آن برنامه هاست.به عنوان مثال در گام قبل برای رسیدن به دلیل نارضایی مشتری تصمیم گرفتیم که به صورت تصادفی با تعدادی از مشتریان تماس گرفته و سوالات مشخصی پرسیده شود، در این گام برای رسیدن به دلیل نارضایی اقدام به اجرای این کار می‌کنیم.اگر در حین پرسش دلیلی بود که با فرضیات ما یکی بود و می‌شد تست کرد این کار رو می‌کنیم و از کاربر باز خورد می‌گرفت در واقع به صورت اجایل اقدام به انجام کار می‌کنیم تا هزینه کمتری برای آن بپردازیم.این گام شامل مراحل زیر می باشد:جمع آوری اطلاعات کافی از مراجع مناسبانجام آزمایش های جزئی جهت ارزیابی فرضیاتپردازش داده های جمع آوری شده ( تبدیل داده ها به اطلاعات)3. بررسی(Check):براساس اطلاعات به دست آمده به یک دانشی می‌رسیم که بر اساس آن دانش میتوانم یک Action Plan تدوین کنیم (برنامه اجرایی). مثال: به منظور افزایش میزان رضایت مشتریان و یا کاهش هزینه‌ها.این گام در برگیرنده تحلیل اطلاعات تولید شده در مرحله قبلی و تطبیق شرایط با برنامه ریزی انجام شده در مرحله اول است. شناسایی فرصت‌های بهبود در این گام انجام خواهد شد.این گام شامل مراحل زیر می باشد:تحلیل اطلاعات و تدوین گزارش شکاف موجودتدوین و ارائه برنامه اجرایی بر اساس فرضیات بررسی شدهخروجی این مرحله یک گزارش شکاف هست که در آن مشکلات و راه حل آن ها ارائه می شود.این مرحله اطلاعات به دانش تبدیل میشود تا با دانش دلیل نارضایی مشتریان با تبدیل اطلات دانش4. اقدام(Act):اقدامات لازم برای رفع مشکلات، برای تغییر فرایند، برای بهبود عملکرد سیستم برای جلب رضایت مشتری و ... این گام که در برخی مستندات تحت عنوان Adjust هم نام برده شده است، به اجرای برنامه‌های تدوین شده مراحل قبلی اختصاص خواهد داشت. در پایان این مرحله می‌بایست بهبودهای مورد نظر قابل مشاهده باشند.تکرار پذیریچرخه PDCA یک چرخه تکرار پذیر هست که ممکن هست شما برای اینکه در هر حوزه ای از نقطه A به نقطه B برسید اصولا با یک بار نمی‌توان به شرایط ایده آل برسید. یک مجموعه‌ای از تکرارها رو باید پشت هم انجام بدیم تا به شرایط مطلوب و مورد نظر برسیم.همانطور که در مرحله Do گفتیم یک سری فرضیات رو تست می‌کنیم، یک سری تست‌های کوچک. اما واقعیت این هست که به خصوص امروزه که بحث‌های اجایل و رویکردی مثل DevOps خیلی رایج هستن و یا اصولی که در ITIL4 دیده می‌شود، خیلی روی این موضوع تاکید دارند که کارها رو به صورت Iterative انجام بدیم، سعی کنیم اصولی مثل Fail Fast رو پیاده سازی کنیم.عموما سازمان‌ها می‌خواهد در گذر زمان بلوغ یک فرایند رو در سطح سازمان افزایش بدهند، کیفیت یک فرایند رو افزایش بدهند. (بلوغ یعنی میزان جدیت پیاده سازی یک فرایند در سطح سازمان)نکته: بعد از هر بار اجرای چرخه و رسیدن به سطحی از مطلوبیت باید وضعیت حاصل شده به استاندارد سازمان تبدیل شود.مدل PDCA اولین و آخرین مدل برای بهبود نیست به عنوان مثال در ITIL مدلی داریم با نام 7 Step Improvement که در هفت گام سعی در ایجاد بهبود می‌کند.تدوین استراتژی بهبودمشخص کردن چیزهایی که مهم و قابل اندازه گیری هستنجمع آوری دیتا در حوزه مشخص شدهپردازش داده‌هاتحلیل اطلاعاتاکشن پلن دادناجرای برنامهاگر بخواهیم مدل PDCA را با  7Step Improvement مطابقت بدهیم می‌توان مرحله 1و2 را معادل P، مرحله 3و4 را معادل D، مرحله 5و6 را معادل S و مرحله 7 را معادل A دانست.</description>
                <category>HamidReza Ireh</category>
                <author>HamidReza Ireh</author>
                <pubDate>Fri, 03 Apr 2020 21:06:25 +0430</pubDate>
            </item>
            </channel>
</rss>