سازمان‌ها آنچه را که تصمیم گرفته‌اند به یاد می‌آورند، اما دلیل آن را فراموش می‌کنند. نحوه کارکرد سوابق تصمیم‌گیری، آنچه باید ثبت شود، یک قالب سبک و نحوه پیوند دادن هر کدام به نتایج.
ابراهیم الکوبییسی · · زمان مطالعه: 6 دقیقه ·
از یک تیم بپرسید چرا سیاستی وجود دارد و اغلب با سکوت مواجه می‌شوید. کسی جلسه‌ای را به یاد می‌آورد، دیگری فکر می‌کند مشکل از تأمین‌کننده بوده و آن کسی که می‌دانست، سال گذشته سازمان را ترک کرده است. تصمیم باقی مانده، اما دلایل آن نه.
این یک اتفاق عادی اما پرهزینه است. بدون دانستن دلایل، یک تیم با دو گزینه ضعیف روبروست: یا تصمیمی را که دیگر درک نمی‌کند حفظ کند، یا آن را لغو کرده و ریسک بازگشت مشکلی که قبلاً حل شده بود را بپذیرد. یک Log تصمیمات، گزینه سومی ارائه می‌دهد: سند را بخوانید، بررسی کنید آیا شرایط هنوز برقرار است یا خیر، و دوباره با هدف مشخصی تصمیم بگیرید.
چرا سازمان‌ها دلیل تصمیمات خود را فراموش می‌کنند
سه عامل علیه حافظه سازمان در مورد تصمیمات خود فعالیت می‌کنند.
- دلایل در گفتگوها زنده می‌مانند. تصمیمات در جلسات، تماس‌ها و رشته‌پیام‌ها گرفته می‌شوند. نتیجه به یک سیاست یا برنامه ختم می‌شود، اما زمینه (Context) به‌ندرت به آن مرحله می‌رسد.
- افراد جابه‌جا می‌شوند. افرادی که گزینه‌ها را بررسی کرده‌اند، نقش خود را تغییر می‌دهند یا سازمان را ترک می‌کنند. درک آن‌ها با خودشان می‌رود.
- حافظه، خود را بازنویسی می‌کند. در مطالعه‌ای در سال 1975، روان‌شناس Baruch Fischhoff دریافت که وقتی افراد از یک نتیجه باخبر می‌شوند، آن را قابل‌پیش‌بینی‌تر از آنچه واقعاً بوده قضاوت می‌کنند. او این پدیده را «جبرگرایی خزنده» نامید. پس از وقوع حادثه، یک تصمیم منطقی که نتیجه بدی داشته، بی‌ملاحظه به نظر می‌رسد و یک تصمیم خوش‌شانسانه، خردمندانه جلوه می‌کند.
نکته آخر از همه مهم‌تر است. حتی وقتی همان افراد باقی می‌مانند، حافظه آن‌ها از دلیل تصمیم‌گیری، تحت تأثیر اتفاقات بعدی شکل می‌گیرد. تنها سندی که در همان لحظه نوشته شده باشد، آنچه را که مشخص، مورد انتظار و نامشخص بوده، حفظ می‌کند.
راهنمای معماری Microsoft این هزینه را به وضوح بیان می‌کند: تصمیمی که هرگز ثبت نشود، «احتمالاً فراموش خواهد شد و منجر به بحث‌های تکراری می‌گردد.»
آنچه تیم‌های نرم‌افزاری آموختند: سند تصمیم معماری (ADR)
مهندسی نرم‌افزار پاسخی آزموده‌شده دارد. در نوامبر 2011، Michael Nygard مفهوم ADR یا سند تصمیم معماری را پیشنهاد داد: سندی کوتاه برای هر تصمیم مهم که به ترتیب شماره‌گذاری شده و همراه با پروژه نگهداری می‌شود. قالب او شامل پنج بخش است.
- عنوان. یک عبارت اسمی کوتاه همراه با شماره، مانند: "ADR 9: LDAP برای یکپارچه‌سازی Multitenant."
- زمینه (Context). عوامل مؤثر: فنی، سیاسی، اجتماعی و محلی. Nygard توصیه کرد که این بخش باید خنثی و صرفاً توصیفی از واقعیت‌ها باشد.
- تصمیم. پاسخ به آن عوامل، در قالب جملات کامل و با فعل معلوم: "ما ... را انجام خواهیم داد."
- وضعیت. پیشنهادی، پذیرفته‌شده، منسوخ یا جایگزین‌شده، همراه با ارجاع به جایگزین احتمالی.
- پیامدها. زمینه حاصل از تصمیم. به گفته Nygard: "تمام پیامدها باید در اینجا لیست شوند، نه فقط موارد مثبت."
این روش گسترش یافت. Thoughtworks در بخش Adopt از Technology Radar خود، ADRهای سبک را در بالاترین سطح توصیه قرار داد و توصیه کرد که آن‌ها به جای یک wiki جداگانه، در کنترل نسخه (Source Control) نگهداری شوند. چارچوب Azure Well-Architected در Microsoft، سند تصمیم را یکی از مهم‌ترین خروجی‌های یک معمار راهکار می‌داند. راهنمای آن دو قانون ارزشمند را اضافه می‌کند: با Log تصمیمات مانند یک فایل فقط-افزودنی (Append-only) رفتار کنید و با هر تصمیم، سطح اطمینان را ثبت کنید.
هیچ‌کدام از این‌ها مختص نرم‌افزار نیست. بیمارستان‌ها پروتکل‌های پذیرش را تغییر می‌دهند. مدارس سیاست‌های ارزیابی را تغییر می‌دهند. سازمان‌ها تأمین‌کنندگان خود را تغییر می‌دهند. هر یک از این تصمیمات دارای زمینه، گزینه‌ها و پیامدهاست و هر کدام بعداً توسط کسی که در جلسه حضور نداشته، مورد پرسش قرار خواهد گرفت.
آنچه یک سند تصمیم‌گیری باید ثبت کند
یک Log تصمیمات، مجموعه‌ای از این سوابق است که دارای یک فهرست برای خلاصه‌سازی هر کدام می‌باشد. دستورالعمل مهندسی Microsoft، این Log را به عنوان جدولی از خلاصه‌های مدیریتی، همراه با متادیتا برای تصمیمات موجود در سوابق کامل توصیف می‌کند. قالب Log تصمیمات زیر فراتر از حوزه مهندسی نیز کاربرد دارد. هر فیلد جایگاه خود را دارد.
- شناسه و عنوان. یک شماره و عبارتی که بیان کند چه چیزی تصمیم گرفته شده است.
- تاریخ. زمان اتخاذ تصمیم، نه زمان نوشتن آن.
- مسئول. فرد پاسخگو برای تصمیم و کسانی که با آن‌ها مشورت شده است.
- زمینه (Context). مسئله، محدودیت‌ها و عوامل درگیر.
- گزینه‌های بررسی‌شده. شامل گزینه‌های رد شده و دلیل رد شدن آن‌ها. این فیلدی است که اغلب فراموش می‌شود اما بیشترین نیاز به آن وجود دارد.
- تصمیم. یک جمله شفاف که با "ما ... را انجام خواهیم داد" شروع شود.
- شواهد. لینک به داده‌ها، گزارش‌ها، حسابرسی‌ها یا بازخوردهایی که تصمیم بر آن‌ها استوار بوده است.
- نتیجه مورد انتظار. آنچه در صورت موفقیت تصمیم باید محقق شود و تا چه زمانی.
- میزان اطمینان. بالا، متوسط یا پایین، همراه با توضیحی درباره آنچه همچنان نامشخص است.
- تاریخ بازبینی. زمانی که تصمیم در برابر نتیجهٔ مورد انتظار سنجیده می‌شود.
- وضعیت. پیشنهادی، پذیرفته‌شده، جایگزین‌شده یا بایگانی‌شده، همراه با لینکی به جایگزین احتمالی.
فیلدهای نتیجهٔ مورد انتظار و میزان اطمینان، نقش یک Journal تصمیم‌گیری را ایفا می‌کنند. آن‌ها آنچه را که پیش از دانستن نتیجه باور داشتید ثبت می‌کنند؛ یعنی دقیقاً همان چیزی که نگاه به گذشته (hindsight) از بین می‌برد.
ما در تصمیم‌گیری‌های مربوط به محصول خودمان نیز همین روال را رعایت می‌کنیم. آنچه مشاهده شده را از آنچه استنباط شده متمایز می‌نویسیم و دیدگاه‌های متضاد را بدون اصلاح یا ساده‌سازی، حفظ می‌کنیم. هر تصمیمی حداقل شایسته همین میزان دقت است.
هر تصمیم را به شواهد و نتیجهٔ آن متصل کنید.
ثبت یک گزارش، حتی اگر مستقل باشد، بهتر از هیچ است. اما گزارشی که به موارد دیگر لینک شده باشد، بسیار کاربردی‌تر است.
لینک به شواهد. وقتی یک تصمیم به نظرسنجی بیمار، تحلیل هزینه یا گزارش حادثه استناد می‌کند، خودِ منبع را لینک کنید. خوانندگان بعدی می‌توانند قضاوت کنند که آیا آن شواهد هنوز معتبر هستند یا خیر. راهنمای Microsoft نیز همین نکته را می‌گوید: گزارشی بدون توجیه، «با گذشت زمان ارزش خود را از دست می‌دهد.»
لینک به نتیجه. در تاریخ بازبینی، آنچه واقعاً رخ داده را در کنار آنچه انتظار می‌رفت، بنویسید. اگر شکاف بزرگی وجود دارد، علت را بپرسید. آیا شواهد ضعیف بودند؟ آیا شرایط تغییر کرد؟ آیا تصمیم درست بود و نتیجه صرفاً بدشانسی بود؟ پاسخ، یک درس است و باید در همان زنجیره قرار بگیرد. مقاله ما درباره درس‌های آموخته‌شده‌ای که پروژه بعدی را تغییر می‌دهند، نحوه ماندگار کردن این درس‌ها را توضیح می‌دهد.
لینک به تصمیمات بعدی. وقتی تصمیمی تغییر می‌کند، گزارش قدیمی را ویرایش نکنید. آن را به عنوان «جایگزین‌شده» علامت‌گذاری کرده و به تصمیم جدید ارجاع دهید. تاریخچهٔ تغییر مسیر، اغلب ارزشمندترین بخش یک Log است.
یک مثال فرضی این زنجیره را نشان می‌دهد: یک کلینیک تصمیم می‌گیرد تماس‌های پیگیری را از پرستاران به یک هماهنگ‌کننده اختصاصی منتقل کند. در گزارش، به داده‌های تکمیل تماس استناد شده، مدیر عملیات به عنوان مسئول معرفی شده، انتظار می‌رود میزان تکمیل تماس‌ها ظرف سه ماه افزایش یابد و یک تاریخ بازبینی تعیین می‌شود. در زمان بازبینی، میزان تکمیل افزایش یافته اما حجم کاری پرستاران طبق انتظار کاهش نیافته است. یک گزارش جدید جایگزین گزارش اول می‌شود، نقش‌ها را اصلاح می‌کند و به گزارش اول لینک می‌دهد. دو سال بعد، یک مدیر جدید می‌تواند کل داستان را در پنج دقیقه بخواند.
آن را به اندازه کافی سبک نگه دارید تا پایدار بماند.
گزارش‌های تصمیم‌گیری (Decision logs) همان‌گونه شکست می‌خورند که اکثر مستندسازی‌ها شکست می‌خورند: تبدیل شدن به یک کار طاقت‌فرسا و در نهایت متوقف شدن. پنج قانون آن‌ها را زنده نگه می‌دارد.
- فقط تصمیمات مهم را ثبت کنید. معیار Microsoft کاربردی است: تصمیماتی که ساختار را شکل می‌دهند، بر کیفیت‌های کلیدی تأثیر می‌گذارند یا بازگشت از آن‌ها دشوار است.
- هر گزارش را کوتاه نگه دارید. یک صفحه یا کمتر. به جای کپی کردن مطالب پشتیبان، به آن‌ها لینک دهید.
- در همان لحظه تصمیم‌گیری بنویسید. گزارشی که در همان هفته نوشته شود، دقیق است. گزارشی که ماه‌ها بعد نوشته شود، بازسازیِ حافظه است.
- آن را در محل انجام کار نگه دارید. گزارشی که در کنار برنامه‌ها و دستورالعمل‌های مرتبط با آن باشد، خوانده می‌شود. گزارشی که در پوشه‌ای جداگانه باشد، خوانده نمی‌شود.
- همین حالا شروع کنید، سپس موارد قبلی را تکمیل کنید. با تصمیمات جدید شروع کنید. سپس تعداد محدودی از تصمیمات گذشته را که مردم بیشتر درباره آن‌ها می‌پرسند بازسازی کرده و آن‌ها را با علامت «بازسازی‌شده» مشخص کنید.
تصمیمی بدون دلایل، صرفاً یک دستور است. تصمیمی همراه با دلایل، می‌تواند با دقت مورد آزمایش، حفظ یا تغییر قرار گیرد.
چگونه Prism گزارش‌های تصمیم‌گیری را نگه می‌دارد
Prism تصمیمات و دانش یک سازمان را به عنوان مواردی با سطح اعتماد مشخص نگه می‌دارد: تأییدشده، مستندشده، مشاهده‌شده یا استنباط‌شده. هر تصمیم به شواهد خود، به مراحل اجرای آن و به نتایج و درس‌های Pause and Learn متصل است. وقتی تصمیمی جایگزین می‌شود، تصمیم قبلی همچنان قابل مشاهده باقی می‌ماند. دستیارانی که تیم شما در حال حاضر استفاده می‌کند نیز می‌توانند گزارش را بخوانند تا در صورت پرسش، دلایل در دسترس باشند. افراد تصمیم می‌گیرند؛ Prism دلایل آن‌ها را نگه می‌دارد.
منابع
- مستندسازی تصمیمات معماری. Michael Nygard، وبلاگ Relevance (اکنون Cognitect)، 2011.
- گزارش تصمیم معماری (Azure Well-Architected Framework). Microsoft Learn، 2024.
- گزارش تصمیم (Code-With Engineering Playbook). Microsoft، 2024.
- گزارش‌های سبک تصمیم معماری (Technology Radar). Thoughtworks، 2018.
- نگاه به گذشته ≠ آینده‌نگری: تأثیر دانستن نتیجه بر قضاوت در شرایط عدم قطعیت. Journal of Experimental Psychology: Human Perception and Performance 1(3) (B. Fischhoff)، 1975.
نظرات
یکپارچه شده در ROADYOM Prism
بیشتر بدانید
