<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های عطیه پوردرخشان</title>
        <link>https://virgool.io/feed/@m_41685981</link>
        <description>کسی که رشد رو تو یادگیری می‌بینه، عاشق رسوندن محصول از صفر به یک!</description>
        <language>fa</language>
        <pubDate>2026-06-15 22:41:40</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/4814196/avatar/qrNp6w.jpg?height=120&amp;width=120</url>
            <title>عطیه پوردرخشان</title>
            <link>https://virgool.io/@m_41685981</link>
        </image>

                    <item>
                <title>محصول در نقطه توقف!</title>
                <link>https://virgool.io/@m_41685981/%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%AF%D8%B1-%D9%86%D9%82%D8%B7%D9%87-%D8%AA%D9%88%D9%82%D9%81-f62ggyw9gaw8</link>
                <description>گاهی محصول در نقطه‌ای قرار می‌گیره که اگر فیچر جدید منتشر نکنه، به نظر می‌رسه محصول عقب رفته؛در حالی که اگر منتشر کنه، ممکنه اصلاً امکان ادامه‌ مسیرش رو از دست بده. مدیریت این تضاد، یکی از سخت‌ترین وضعیت‌های مدیریت محصوله. چون در نگاه اول، رشد با «اضافه شدن» قابلیت‌ها و خروجی‌ها شناخته می‌شه. اما گاهی مسئله اصلاً توسعه نیست؛ مسئله اینه که سیستم توان تحمل تغییر رو داره یا نه.هر محصول یک نقطه‌ پنهان داره؛ نقطه‌ای که فشار برای حرکت، از ظرفیت واقعی سیستم جلو می‌زنه. از بیرون همه‌چیز هنوز شبیه یک سیستم فعال و در حال کاره، اما درونش ممکنه منابع، تمرکز یا زیرساخت در وضعیتی باشن که هر تغییر جدید به جای کمک، تبدیل به بار اضافه بشه. در چنین اوضاعی، تصمیم درست درباره این نیست که «چه چیزی ساخته بشه». بلکه درباره اینه که «چه چیزی نباید ساخته بشه»؛ و مهم‌تر اینکه آیا اضافه شدن یک قابلیت یا فیچر واقعاً سیستم رو جلو می‌بره یا فقط پیچیدگی به ماجرا اضافه می‌کنه.یک مثال واقعی از محصول خودمون اینجا می‌تونه کمک‌کننده باشه. در یک مقطع، فشار مالی بالا رفته بود، منابع محدود شده بودن و هم‌زمان زیرساخت و اینترنت هم ناپایدارتر شده بود. تصمیم این بود که توسعه‌ محصول متوقف بشه. ما عملا وارد فاز فریز محصول شده بودیم و قرار بود تمام منابع باقی‌مونده صرف یک هدف بشه: زنده نگه داشتن سیستم. این تصمیم شاید از بیرون شبیه «رشد نکردن» به نظر بیاد، اما اشتباه نبود. چون هر محصول در هر مقطع، مسئله‌ متفاوتی داره. گاهی مسئله رشد کردنه، گاهی کشف مشکل واقعی کاربره، گاهی فروشه و گاهی فقط دوام آوردنه. هیچ کدوم از این مسائل مشکلی ایجاد نمی‌کنن. اشتباه از جایی شروع می‌شه که همه‌ این وضعیت‌ها با یک معیار سنجیده می‌شن.در خیلی از تیم‌ها، موفقیت مدیر محصول به‌مرور با تعداد فیچرهای منتشرشده تعریف می‌شه. انگار اگر چیزی بیرون نیاد، محصول جلو نرفته. در حالی که همیشه این‌طور نیست. یک محصول می‌تونه ماه‌ها فیچر جدید نده، اما همچنان تصمیم‌های درست بگیره. اتفاق خطرناک‌تر وقتی رخ می‌ده که مدیر محصول، بدون درک وضعیت واقعی سیستم، محصول رو وارد فاز توسعه‌ کنه درحالی‌که زیرساخت تحملش رو نداره. وقتی منابع فنی فقط برای پایداری کنار گذاشته شدن، حتی یک قابلیت ساده هم می‌تونه به جای پیشرفت، فشار مضاعف ایجاد کنه.از بیرون با این تصویر مواجه می‌شیم که فیچر منتشر می‌شه، جلسه‌ها بیشتر می‌شن، تسک‌ها در جریانن و نمودار فعالیت بالا می‌ره. اما این تصویر لزوماً نشانه‌ی سلامت سیستم نیست. اون هم در شرایطی که زیرساخت هم قابل اتکا نباشه، اینترنت ناپایدار باشه، رفتار کاربر تغییر کنه، خطاهای جدید ظاهر شن و حتی فرض‌های پایه‌ محصول زیر سؤال برن. در چنین فضایی، یک تغییر کوچک هم می‌تونه اثرات زنجیره‌ای بسازه؛ نه فقط روی تجربه کاربر، بلکه روی کل پایداری سیستم.خبر بدی که وجود داره اینه: این نوع ریسک معمولاً دیر دیده می‌شه. چون سیستم هنوز از هم نپاشیده؛ هنوز کاربر هست، هنوز سرویس کار می‌کنه. و همین «هنوزها» فشار برای حرکت بیشتر ایجاد می‌کنن، نه کمتر. اینجاست که نقش واقعی مدیریت محصول خودش رو نشون می‌ده.مدیریت محصول فقط ساختن فیچر نیست. بخش مهم‌ترش اینه که بتونی تشخیص بدی: الان مهم‌ترین کاری که نباید انجام بدیم چیه؟ و گاهی پاسخ این سؤال، نه سرعت بیشتره، نه خروجی بیشتر؛ بلکه توقف آگاهانه‌ست. حتی وقتی بیرون از سیستم، همه چیز خلافش رو فریاد می‌زنه. اینجا مفهوم کم‌حرکتی آگاهانه شکل می‌گیره؛ توانایی دفاع از تصمیم انجام ندادن، وقتی اضافه کردن هر چیز جدید می‌تونه هزینه‌ای بزرگ‌تر از فایده‌اش داشته باشه. این نوع تصمیم‌گیری ضد رشد نیست؛ اتفاقاً یکی از بالغ‌ترین شکل‌های مدیریت محصوله. چون به جای خروجی کوتاه‌مدت، از ظرفیت تصمیم‌گیری سیستم محافظت می‌کنه. این تصمیم اگر درست روایت بشه، خودش یک دستاورد محسوب می‌شه و مدیر محصول باید بتونه تعریف موفقیت رو برای ذی‌نفعان عوض کنه و به‌جای اینکه در ارائه‌های خودش بگه «چی ساختیم؟» باید بگه «از فروپاشی چه چیزی جلوگیری کردیم؟»این یعنی جابه‌جایی KPIها از خروجی به سمت پایداری. اگر بخوایم این تغییر زاویه نگاه رو در عمل ببینیم، باید معیارهای موفقیت رو هم عوض کنیم. نه در سطح شعار، بلکه در سطح عدد و رفتار سیستم. در این نگاه، KPIها دیگه فقط عدد نیستن؛ تبدیل می‌شن به سیگنال‌هایی که می‌گن سیستم در چه وضعیه و آیا اصلاً اجازه‌ ادامه دادن داریم یا نه. اگر بخوایم این رو به اجرا ترجمه کنیم، هر دسته از این سیگنال‌ها یک سؤال مرکزی جلوی ما می‌ذاره:پایداری سیستم: اینجا سؤال این نیست که چقدر خروجی داریم؛ سؤال اینه که آیا سیستم اساساً قابل اتکاست یا نه و برای رصد، این موارد بررسی می‌شن:درصد در دسترس بودن سرویستعداد اختلال‌های بحرانیمیانگین زمان بین خرابی‌ها (MTBF)میانگین زمان رفع خرابی (MTTR)سلامت خطاها: اینجا به جای رشد، داریم گوش می‌دیم به این‌که سیستم کجاها داره از کنترل خارج می‌شه و در این زمینه‌ها داده‌ها کمک می‌کنن:نرخ خطا در درخواست‌هاخطاهای تکرارشوندهخطاهای سمت کاربرنرخ شکست عملیات‌های کلیدیتاب‌آوری سیستم: سؤال اصلی اینه: وقتی فشار وارد می‌شه، سیستم فقط می‌شکنه یا می‌تونه برگرده. در این زمینه می‌تونیم شاخص‌های زیر رو داشته باشیم:زمان بازگشت به وضعیت پایدار بعد از اختلالمیزان موفقیت در failover / fallbackتحمل سیستم در شرایط ناپایداردرصد بازیابی بدون مداخله انسانیسلامت انتشار: اینجا انتشار دیگه نشونه رشد نیست؛ تبدیل می‌شه به آزمون پایداری سیستم. برای رصد این موضوع این موارد مهم هستن:نرخ انتشار بدون خطای بحرانیتعداد rollback یا بازگشت از انتشارتعداد hotfixهای اضطراریزمان شناسایی تا رفع مشکل بعد از انتشارفشار عملیاتی: این دسته نشون می‌ده تیم واقعاً در چه سطحی از تنش کار می‌کنه، نه اینکه فقط چقدر کار انجام می‌ده. برای این موضوع این موارد رو رصد می‌کنیم:تعداد رخدادهای پشتیبانیدرخواست‌های فوری و اضطراریescalations به تیم فنیزمان پاسخ‌گویی به مسائل بحرانیثبات تجربه کاربر: اینجا داریم اثر واقعی تصمیم‌ها رو روی رفتار کاربر می‌بینیم، نه روی خروجی تیم! برای رسیدن به این هدف باید این موارد بررسی بشن:نوسان در نرخ استفادهنرخ ریزش ناشی از خطاثبات در تکمیل مسیرهای اصلی کاربرتغییرات ناگهانی در رفتار کاربرانسلامت تیم در شرایط بقا: این بخش مهم‌ترین بخشه و اگر آسیب ببینه، بقیه KPIها معنی خودشون رو از دست می‌دن و موارد زیر می‌تونن نکات زیادی رو بهمون نشون بدن:حجم کار خارج از برنامهنشانه‌های فرسودگی تیمنسبت کار واکنشی به کار برنامه‌ریزی‌شدهظرفیت باقی‌مانده برای کار توسعه‌ای واقعیگاهی بهترین تصمیم، نساختن یک فیچره، گاهی بهترین تصمیم، کند کردن ریتم تغییره و گاهی موفقیت یعنی اینکه در یک سیستم شکننده، ریسک تازه‌ای وارد نکنی. چون همه‌ حرکت‌ها نشونه‌ پیشرفت نیستن. بعضی حرکت‌ها فقط دیرتر نشون می‌دن که تعادل از قبل به‌هم خورده بوده.</description>
                <category>عطیه پوردرخشان</category>
                <author>عطیه پوردرخشان</author>
                <pubDate>Sat, 23 May 2026 00:07:39 +0330</pubDate>
            </item>
                    <item>
                <title>پروموشن همیشه به معنی رشد نیست</title>
                <link>https://virgool.io/@m_41685981/%D9%BE%D8%B1%D9%88%D9%85%D9%88%D8%B4%D9%86-%D9%87%D9%85%DB%8C%D8%B4%D9%87-%D8%A8%D9%87-%D9%85%D8%B9%D9%86%DB%8C-%D8%B1%D8%B4%D8%AF-%D9%86%DB%8C%D8%B3%D8%AA-saqtkowypjay</link>
                <description>پروموشن در ظاهر یک تصمیم ساده‌ست. کسی خوب کار کرده، پس به سطح بعدی میره و مسئولیت بیشتری می‌گیره. اما در عمل، خیلی وقت‌ها این تصمیم نه درباره رشد فرده، نه درباره نیاز واقعی سازمان؛ بیشتر نتیجه فشاریه که سیستم نمی‌تونه درست مدیریت کنه. فشار برای نگه داشتن آدم‌ها، فشار برای پر کردن سریع نقش‌ها، فشار برای اینکه نشون داده بشه مسیر رشد وجود داره. پس پروموشن از یک تصمیم مبتنی بر آمادگی، تبدیل میشه به یک واکنش و دقیقاً از همین نقطه چالش‌ها شروع میشه.در حالت طبیعی، فرد باید زمانی پروموت بشه که پیچیدگی‌های اون سطح براش تکراری شده نه اینکه هنوز در حال ساختن فهم اون نقش باشه. اما خیلی وقت‌ها این اتفاق نمی‌افته و فرد در حالی به سطح بعدی منتقل میشه که تازه داره به درک نقش قبلی شکل می‌ده. در ظاهر پیشرفت کرده، اما در عمل یک عدم‌تعادل شکل می‌گیره بین مسئله‌هایی که سنگین‌تر شدن و ظرفیتی که هنوز کامل نشده.پروموشن زودهنگام باعث می‌شه فرد قبل از اینکه در یک سطح به بلوغ برسه، ازش عبور کنه. در نتیجه تجربه‌ها تکه‌تکه می‌شن، نه عمیق. این یعنی به جای اینکه شهود تصمیم‌گیری ساخته بشه، یک سری الگوی سطحی از تجربه شکل می‌گیره.فرد وارد فضایی می‌شه که تصمیم‌ها پیچیده‌ترن، بازخوردها دیرتر و مبهم‌ترن و اثر تصمیم‌ها گسترده‌تر و کمتر قابل برگشتن. اما چون چارچوب ذهنی سطح قبلی هنوز کامل نشده، به جای عمیق‌تر شدن، یک نوع جبران شکل می‌گیره. جبران با سرعت، جبران با ظاهر تصمیم‌گیری، جبران با تکیه بر تجربه‌های پراکنده و به‌تدریج یادگیری از فهم مسئله تبدیل می‌شه به مدیریت دیده شدن.پروموشن اشتباه در مدیریت محصولاین مسئله در مدیریت محصول شکل شدیدتری پیدا می‌کنه. پروموشن اشتباه در مدیریت محصول فقط به این ختم نمیشه که “آدم مناسب نیست”؛ چون مدیریت محصول یه نقش خطی و ایزوله نیست. هر خطای ظرفیت، مستقیم در تصمیم‌ها، اولویت‌ها و حتی فرهنگ تصمیم‌گیری پخش می‌شه. این اختلال معمولاً خودش رو در رفتارهای خیلی روزمره نشون می‌ده.مثلاً جایی که نقش فرد Delivery Product Manager تعریف شده، اما پیشرفت کار رو به کامل شدن یک‌سری پیش‌نیاز و سند بالا‌دستی گره می‌زنه که اساساً شرط شروع کارها نیست. در عمل، به جای جلو بردن کار با چیزهای موجود، حرکت متوقف می‌شه تا چیزی کامل بشه که نیاز نبوده کامل باشه.یا جایی که نقش فرد فقط هماهنگ‌کردن و شفاف‌سازی بین تیم‌هاست، اما وارد خودِ تصمیم‌گیری می‌شه؛ بدون اینکه مسئله، ریسک‌ها یا اثر تصمیم رو درست به فرد پاسخگو منتقل کنه. نتیجه این می‌شه که تصمیم‌ها کم‌کم در لایه‌های غیرشفاف گرفته می‌شن و مسیر محصول، آرام و نامحسوس، از جایی که باید باشه فاصله می‌گیره و شاید خطرناک‌ترین بخش ماجرا همین‌جاست که کار جلو می‌ره، اما جهت محصول به خاطر شهود پایین روی فضای مسئله، آرام و نامرئی تغییر می‌کنه؛ بدون اینکه کسی دقیق بفهمه چرا. اگر بخوایم عمیق‌تر نگاه کنیم، مسئله چند لایه داره:اولین و فوری‌ترین مشکل، اختلال در خود تصمیم‌گیریه. وقتی کسی زودتر از ظرفیت واقعی وارد نقش مدیر محصول یا سطح بالاترش می‌شه، معمولاً دو رفتار افراطی شکل می‌گیره: یا تلاش برای قطعی‌کردن چیزهایی که ذاتاً قطعی نیستن (دیتا، تحلیل، تاییدهای زیاد)، یا تصمیم‌های شتاب‌زده برای فرار از ابهام. نتیجه در هر دو حالت یکیه: تصمیم‌ها یا دیر می‌رسن یا سطحی می‌شن.لایه دوم، به‌هم‌ریختن مرز مالکیت تصمیمه. در مدیریت محصول، خیلی مهمه بدونی کجا باید مالک تصمیم باشی و کجا فقط هماهنگ‌کننده. پروموشن زودهنگام این مرز رو مبهم‌تر می‌کنه. فرد یا بیش‌ از حد وارد جزئیات اجرا می‌شه یا از تصمیم‌گیری عقب می‌کشه و حس مالکیت واقعی شکل نمی‌گیره. هر دو حالت باعث می‌شه تیم دچار سردرگمی بشه که کی مسئول تصمیمه؟لایه سوم، اثر روی backlog و اولویت‌بندی‌‌هاست. مدیر محصول ضعیف یا زودپروموت‌شده معمولاً یا بیش‌ازحد واکنشی می‌شه (هر پیشنهاد یا فشار کوچیک تبدیل به فیچر می‌شه)، یا بیش‌ازحد محافظه‌کار. در نتیجه، backlog یا شلوغ و بی‌جهت می‌شه یا فلج. اینجا خطا فقط فردی نیست، سیستمیه.وقتی سیستم می‌خواد اشتباهش رو پس بگیرهفرض کنین بعد از مدتی، سیستم متوجه می‌شه این انتخاب اشتباه بوده و سعی می‌کنه اصلاحش کنه. برای همین تصمیم می‌گیره پروموشن رو پس بگیره و این تصمیم به یک چالش جدید دامن می‌زنه. چون وقتی فرد یک بار وارد نقش بالاتر شده باشه، برگشتن به نقش قبلی معمولاً فقط یک جابه‌جایی ساده نیست. یا از نظر ذهنی برای فرد سنگینه، یا از نظر جایگاه اجتماعی در سازمان قابل هضم نیست. در نتیجه دو مسیر بیشتر باقی نمی‌مونه: یا دیموشن (بازگرداندن به نقش پایین‌تر) که برای خیلی‌ها به معنی شکست یا پس‌رفت تعبیر می‌شه و معمولاً باعث ترک سازمان می‌شه، یا موندن در همان وضعیت با یک نارضایتی مزمن؛ جایی که فرد نه در نقش قبلی جا داره، نه در نقش فعلی واقعاً موفق عمل می‌کنه و همین باعث می‌شه یک تصمیم که در ابتدا برای رشد گرفته شده بود، در نهایت به یک وضعیتی تبدیل بشه که امکان رشد رو هم برای فرد، هم برای سازمان می‌سوزونه و ممکنه فرد فرصت برگشت به مسیر اصولی رشد خودش رو برای همیشه از دست بده.در مدیریت محصول، پروموشن اشتباه فقط جابجایی یک نفر نیست؛ تغییر کیفیت تصمیم‌گیری کل سیستمه.</description>
                <category>عطیه پوردرخشان</category>
                <author>عطیه پوردرخشان</author>
                <pubDate>Fri, 15 May 2026 09:40:31 +0330</pubDate>
            </item>
                    <item>
                <title>وقتی می‌دونی مسیر اشتباهه، ولی نمی‌تونی عوضش کنی</title>
                <link>https://virgool.io/@m_41685981/%D9%88%D9%82%D8%AA%DB%8C-%D9%85%DB%8C-%D8%AF%D9%88%D9%86%DB%8C-%D9%85%D8%B3%DB%8C%D8%B1-%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87%D9%87-%D9%88%D9%84%DB%8C-%D9%86%D9%85%DB%8C-%D8%AA%D9%88%D9%86%DB%8C-%D8%B9%D9%88%D8%B6%D8%B4-%DA%A9%D9%86%DB%8C-g7nq4azul3uk</link>
                <description>خیلی از آدم‌ها فکر می‌کنن تصمیم‌های اشتباه معمولاً از ناآگاهی میان؛ اینکه تیم یا مدیر نمی‌فهمه چه اتفاقی داره می‌افته. اما در عمل، همیشه این‌طور نیست. گاهی همه می‌دونن مشکل کجاست، حتی درباره‌ش حرف هم می‌زنن، ولی سیستم در وضعیتی قرار گرفته که توان اصلاح خودش رو از دست داده. تیم ما یه تیم تازه‌نفس و جوون و به‌روز تو دل یه شرکت باسابقه و سنتی بود و ما این وضعیت رو دو بار و به دو شکل مختلف تجربه کردیم.اولین بار مسئله این بود که تیم داشت با منطق یک محصول مدرن جلو می‌رفت، ولی داخل ساختاری کار می‌کرد که هنوز با اون مدل تصمیم‌گیری فاصله داشت. خیلی از چیزهایی که برای ما بدیهی بودن، برای لایه‌های بالاتر هنوز قابل لمس یا قابل اعتماد نبودن. تغییرهایی که باید سریع اتفاق می‌افتادن، وارد چرخه‌ی توضیح، قانع‌سازی و تأیید می‌شدن. برای هر تصمیم باید زمان زیادی صرف می‌شد تا اول اصل مسئله پذیرفته بشه. در ظاهر همه‌چیز در حال حرکت بود، اما در عمل بخش زیادی از انرژی تیم صرف جنگیدن با مقاومت تغییر سیستم می‌شد. زمان از دست می‌رفت، فرصت‌ها رد می‌شدن و کم‌کم فاصله‌ای شکل می‌گرفت بین چیزی که می‌دونستیم باید انجام بشه و چیزی که واقعاً امکان انجامش وجود داشت. اون زمان فکر می‌کردیم اگر ساختار بالاخره ضرورت تغییر رو بفهمه، بخش بزرگی از مسئله حل میشه.روزگار گذشت و با جمعبندی اتفاقات، بررسی و تحلیل دلیل‌ها و مرور چالش‌ها، درک برای تغییر ایجاد شد. تقریباً همه می‌دونستن که خیلی از ساختارها باید تغییر کنن، مدل‌های قدیمی جواب نمی‌دن، بعضی زیرساخت‌ها باید از اول ساخته بشن، ساختار انسانی و فرآیندها یا حتی شیوه تصمیم‌گیری نیاز به بازطراحی دارن. این بار جنگ و بحران مالی و فشارهایی که به هر کسب‌ و کاری ضربه می‌زنه شروع شد و مسئله ما تغییر کرد.در چنین بحران‌هایی فشار بیرونی زیاد میشه، اولویت سیستم از «اصلاح» میره روی «دوام آوردن». تصمیم‌ها کوتاه‌مدت‌تر میشن، تمرکز میره روی درآمد فوری و تیم کم‌کم وارد حالت بقا میشه. بنابراین حتی اگر بدونی یک مسیر اشتباهه، لزوماً توان تغییرش رو نداری. چون تغییر فقط فهم مسئله نمی‌خواد؛ زمان، تمرکز، ظرفیت ذهنی و تحمل افت موقت هم می‌خواد. مواردی که معمولاً در بحران اولین چیزهایی‌ان که از بین میرن.کم‌کم وضعیت عجیبی شکل می‌گیره. همه می‌دونن بعضی مسیرها پایدار نیستن، ولی همون مسیرها ادامه پیدا می‌کنن. نه چون کسی متوجه مشکل نشده، بلکه چون حجم فشار و کار اون‌قدر زیاد شده که دیگه فرصتی برای بازطراحی واقعی وجود نداره.تیم بیشتر از اینکه در حال ساختن باشه، در حال واکنش نشون دادنه.تصمیم‌ها لحظه‌ای‌تر میشن.فشار کاری بالا میره و انرژی سیستم صرف حل بحران امروز میشه، نه ساختن آینده.و شاید یکی از خطرناک‌ترین وضعیت‌های مدیریتی همین باشه که همه می‌دونن مسیر فعلی جواب نمی‌ده، اما فشار بقا اجازه‌ ساختن مسیر جدید رو نمی‌ده. از یک جایی به بعد، سیستم دیگه تلاش نمی‌کنه بهتر بشه؛ فقط تلاش می‌کنه از هم نپاشه. شاید در چنین وضعیتی، مسئله این نباشه که بخوایم همه‌چیز رو سریع درست کنیم.سیستمی که وارد حالت بقا شده، معمولاً دیگه ظرفیت تغییرهای بزرگ رو نداره. هر تصمیم جدید، هر بازطراحی و هر تغییری خودش تبدیل میشه به یک فشار تازه.شاید مهم‌تر این باشه که چه چیزهایی نباید زیر فشار کوتاه‌مدت از بین برن.کدوم تصمیم‌ها رو نباید فقط برای رد کردن امروز گرفت.کجا باید آگاهانه سرعت رو کمتر کرد، حتی وقتی همه‌چیز داره هل میده به سمت تصمیم‌های عجولانه و فوری.چون بعضی وقت‌ها، خطر اصلی این نیست که سیستم تصمیم اشتباه بگیره. بلکه اینه که اون‌قدر درگیر دوام آوردن بشه که دیگه فرصتی برای فکر کردن به مسیر نداشته باشه و از یک جایی به بعد، مسئله فقط این نیست که نتیجه‌ درست نمی‌گیری؛ کم‌کم توان رسیدن به نتیجه‌ی درست رو هم از دست میدی.</description>
                <category>عطیه پوردرخشان</category>
                <author>عطیه پوردرخشان</author>
                <pubDate>Fri, 08 May 2026 23:30:36 +0330</pubDate>
            </item>
                    <item>
                <title>تصمیم گرفتن با اطلاعات ناقص</title>
                <link>https://virgool.io/@m_41685981/%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D8%A8%D8%A7-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D9%86%D8%A7%D9%82%D8%B5-bopq781mso5p</link>
                <description>مشکل خیلی از تصمیم‌های اشتباه این نیست که دیتا نداریم؛ بیشتر اینه که فکر می‌کنیم دیتا یعنی قطعیت. انگار هرچی گزارش‌ها دقیق‌تر و داشبوردها کامل‌تر بشن، تصمیم هم لزوماً درست‌تر می‌شه. در حالی که در دنیای واقعی، این رابطه پایدار نیست. گاهی وقتا مسئله کمبود داده نیست؛ مسئله اینه که قانون بازی عوض می‌شه. یعنی چیزی که دیروز از روی داده درست تفسیر می‌شد، امروز ممکنه کاملاً گمراه‌کننده باشه. رفتار کاربر، شرایط بازار یا حتی انگیزه خرید تغییر می‌کنه، اما ما هنوز با همون مدل ذهنی قبلی داریم داده رو تفسیر می‌کنیم.مثلاً در شرایطی مثل جنگ، تورم شدید یا بحران اقتصادی، الگوی خرید کاربر تغییر می‌کنه. کسی که قبلاً برای کیفیت انتخاب می‌کرد، ممکنه فقط به قیمت حساس بشه. یا در یک محصول آموزشی، اگر زمان دیدن ویدیو رابطه مستقیم با قبولی کاربر در امتحان داشت، ممکنه این رابطه به دلیل مشکلات اینترنت یا استرس‌های زمان جنگ اعتبار خودش رو از دست بده. یا در یک فروشگاه اینترنتی، اضافه شدن محصول به سبد خرید همیشه یک سیگنال مثبت تلقی می‌شه. اما در دوره‌ای از بی‌ثباتی قیمت، کاربران تعداد زیادی کالا به سبد اضافه می‌کنن بدون اینکه خرید را نهایی کنن. چون صرفاً می‌خوان قیمت‌ها رو زیر نظر داشته باشن.همون‌طوری که مشخصه گاهی داده عوض نمیشه؛ بلکه معنا تغییر می‌کنه. این یعنی رابطه بین داده و واقعیت ثابت نیست، و همین باعث می‌شه پیش‌بینی بر اساس گذشته قابل اتکا نباشه. به همین دلیل، ابزارهای کلاسیک تصمیم‌گیری هم محدود می‌شن. ابزارهایی مثل A/B تست، قیف یا KPIها معمولاً بر این فرض ساخته شدن که آینده ادامه‌ گذشته است. اما وقتی رفتارها تغییر ساختاری می‌کنن، این ابزارها فقط گذشته رو بهتر توضیح می‌دن، نه آینده رو.پس مسئله اصلی اینه: وقتی دیتا دیگه پیش‌بینی دقیق نمی‌ده، باید چطور تصمیم بگیریم؟ در چنین شرایطی، وضعیت محصول به محصول صفر به یک نزدیک‌تر میشه و باید با همون استراتژی پیش رفت. قدم‌های کوچک اکتشافی و فرضیه‌سازی و تست فرضیه‌ها. نقش مدیر یا لیدر هم دچار تغییراتی میشه:۱. تصمیم‌ها باید از «قطعیت» به «فرضیه» تبدیل بشن. یعنی به جای اینکه دنبال جواب نهایی باشیم، با فرض‌هایی کار کنیم که قابل تست و اصلاح باشن.۲. مزیت از «کامل بودن تحلیل» به «سرعت یادگیری» منتقل بشه. چرخه ساختن، سنجیدن و یاد گرفتن مهم‌تر از اینه که قبل از حرکت، همه‌چیز رو کامل بفهمیم.۳. باید به جای عددهای پایدار، دنبال تغییر الگوها باشیم. در محیط‌های ناپایدار، مهم‌تر از مقدار KPIها، جهت تغییر اون‌هاست.۴. باید بپذیریم فقط داده تغییر نکرده. بلکه «معنا» هم متغیره. یعنی یک شاخص ممکنه در دو شرایط مختلف دو معنی کاملاً متفاوت داشته باشه.۵. در نهایت، نقش داده هم تغییر می‌کنه. داده کمتر ابزار پیش‌بینی آینده است و بیشتر ابزار فهم وضعیت فعلی. مثل حسگری که به ما می‌گه الان چه خبر است، نه نقشه‌ای که بگه بعداً چه می‌شود.در چنین فضایی، مدیریت یعنی توانایی حرکت در ابهام. نه اینکه تصمیم کامل بگیری، باید سریع‌تر بفهمی کجا اشتباه کردی و سریع‌تر مسیر رو اصلاح کنی و شاید مدیریت بحران دقیقاً همین باشه، تصمیم گرفتن، وقتی نه داده کامل داری، نه آینده قابل پیش‌بینیه و محصول هم از نسخه بهتر تبدیل می‌شه به فرضیه‌ای که باید کشف بشه.</description>
                <category>عطیه پوردرخشان</category>
                <author>عطیه پوردرخشان</author>
                <pubDate>Fri, 01 May 2026 23:51:26 +0330</pubDate>
            </item>
                    <item>
                <title>تعدیل نیرو نتیجه‌ی یک زنجیره‌ست، نه یک اتفاق!</title>
                <link>https://virgool.io/@m_41685981/%D8%AA%D8%B9%D8%AF%DB%8C%D9%84-%D9%86%DB%8C%D8%B1%D9%88-%D9%86%D8%AA%DB%8C%D8%AC%D9%87-%DB%8C-%DB%8C%DA%A9-%D8%B2%D9%86%D8%AC%DB%8C%D8%B1%D9%87-%D8%B3%D8%AA-%D9%86%D9%87-%DB%8C%DA%A9-%D8%A7%D8%AA%D9%81%D8%A7%D9%82-mgjxnshoeiwb</link>
                <description>تعدیل نیرو از روزی شروع میشه که اولین تصمیم اشتباه رو نادیده می‌گیری. در این زمینه معمولاً روایت‌های ساده بیشتر شنیده می‌شن: شرایط بد شد، جنگ شد، فروش کم شد و مجبور شدیم تعدیل کنیم. اما واقعیت این‌قدر خطی نیست. تعدیل نیرو نتیجه‌ی یک زنجیره‌ست، نه یک اتفاق.ما یه تیم خوب داشتیم که به‌تازگی یه محصول رو لانچ کرده بود. هدفمون این بود که کم‌کم وارد بازار بشیم و با تست، محصول رو بهینه کنیم. اما خیلی زود مشخص شد مسیری که برای فروش انتخاب کرده بودیم، اون‌قدر که باید قابل اتکا نیست. در عین حال، فشار برای رسیدن به نتیجه‌ی سریع بالا بود و زیرساخت‌ها هم کامل نشده بودند. در چنین شرایطی، تصمیم‌ها کم‌کم از حالت استراتژیک به واکنشی تغییر می‌کنن و تمرکز هم میره سمت کارهای زودبازده! آروم‌آروم به‌جای اصلاح مسیر، وارد چرخه‌ای میشی که فقط قراره امروز رو نگه داره، نه آینده رو. در نتیجه، فاصله‌ی بین «کاری که انجام میدی» و «نتیجه‌ای که می‌خوای» بیشتر و بیشتر میشه.از طرف دیگه یک واقعیت ساده هم هست: هر کسب‌وکاری باید چند ماه هزینه‌هاش رو با اطمینان پوشش بده؛ یعنی بدون اینکه درآمد جدیدی بیاد، بتونه چند ماه دوام بیاره. تو استیج‌های اولیه این عدد می‌تونه فرق کنه، اما اصل ماجرا یکیه: بدون این اطمینان، حتی تصمیم درست هم سخت و پرریسک میشه.و آخرین ضربه، شرایط بیرونی مثل جنگ، فشار اقتصادی، افت بازار و... که کار رو سخت‌تر می‌کنه. درسته که این‌ شرایط واقعی‌ان، اما معمولاً فقط چیزی رو آشکار می‌کنن که از قبل ساخته شده. اگر مسیر از پایه پایدار نباشه، فشار بیرونی فقط سرعت رسیدن به نقطه‌ی شکست رو بیشتر می‌کنه و اون نقطه گاهی خودش رو این‌طوری نشون میده:روزی که باید به یکی از بهترین آدم‌هات بگی: «از فردا نیا.»سؤال مهم اینه: چطور می‌شه جلوی رسیدن به این نقطه رو گرفت؟اگر به مسیرهایی که به تعدیل نیرو ختم می‌شن نگاه کنیم، معمولاً با یک تصمیم اشتباه شروع نمی‌شن.با مجموعه‌ای از نشانه‌های کوچک شروع می‌شن که در لحظه جدی گرفته نمی‌شن.گاهی وقتی یک مسیر فروش به‌وضوح قابل اتکا نیست، به‌جای بازطراحی، با فشار بیشتر ادامه پیدا می‌کنه.گاهی وقتی فاصله بین تلاش و نتیجه زیاد می‌شه، به‌جای مکث و بازبینی، با کارهای زودبازده پر می‌شه.و گاهی وقتی ساختار انسانی یا زیرساخت‌های لازم هنوز کامل نیستند، در عمل دیده نمی‌شن و به‌صورت پیش‌فرض پذیرفته می‌شن که «در مسیر شکل گرفتن هستند».هیچ‌کدوم از این‌ها از ابتدا بحرانی به نظر نمی‌رسن. حتی قابل توجیه‌اند. اما در مجموع، یک مسیر تدریجی شکل می‌گیره که هزینه‌ی اصلاحش هر بار بیشتر از قبل می‌شه.پیشگیری از این نقطه، بیشتر از اینکه به تصمیم‌های بزرگ وابسته باشه، به زمان دیده شدن این فاصله‌ها برمی‌گرده؛ هر مسیری یک نقطه داره که هنوز قابل تغییره، اما دیگر به‌سادگی قابل ادامه دادن نیست و تفاوت اصلی، معمولاً در تشخیص همین نقطه‌ست.در نهایت، تعدیل نیرو کمتر نتیجه‌ی یک بحران ناگهانیه و بیشتر نتیجه‌ی مجموعه‌ای از نشانه‌هایی‌ست که دیر دیده شده‌اند.</description>
                <category>عطیه پوردرخشان</category>
                <author>عطیه پوردرخشان</author>
                <pubDate>Fri, 24 Apr 2026 22:10:20 +0330</pubDate>
            </item>
            </channel>
</rss>