چگونه تصمیمات را مستند کنیم: راهنمای عملی قطعی
چگونه تصمیمات را مستند کنیم: برای هر تصمیم مهم، هفت حوزه را ثبت کنید — سوال، گزینههای مورد بررسی، دلایل موافق و مخالف، خود تصمیم، توجیه، مالک و تاریخ بازبینی. چارچوبهای نقش (RAPID، DACI، RACI) مشخص میکنند که چه کسی تصمیم میگیرد؛ یک رکورد تصمیم، آنچه تصمیمگیری شده و دلایل آن را حفظ میکند. مهندسی این موضوع را در سال ۲۰۱۱ با رکوردهای تصمیمگیری معماری مایکل نیگارد حل کرد؛ همین روش سبک برای هر تیمی کار میکند: رکورد را زمانی که تصمیم گرفته میشود بنویسید، آن را در یک مکان قابل جستجو نگه دارید و تاریخ بازبینی را تعیین کنید تا نتایج بتوانند با دلایل مقایسه شوند.
بیشتر تیمها وظایف را به دقت مستند میکنند و تصمیمات را اصلاً مستند نمیکنند — به همین دلیل است که سوالات حل شده هر سه ماه دوباره مورد بحث قرار میگیرند. راه حل یک ثبت تصمیم سبک است و این روش کامل است:
- نقشها ≠ سوابق. RAPID، DACI و RACI به شما میگویند چه کسی تصمیم میگیرد؛ هیچکدام از آنها چه چیزی تصمیمگیری شده و چرا را حفظ نمیکنند. شما به هر دو بخش نیاز دارید.
- هفت زمینه — سوال، گزینهها، استدلالها، تصمیم، دلیل، مالک، تاریخ بررسی — همه چیزهایی را که یک خواننده آینده نیاز دارد پوشش میدهد (این الگو متعلق به ماست؛ آن را بدزدید).
- زمانی که تصمیم گرفته شد آن را بنویسید، در یک خانه قابل جستجو، یک رکورد برای هر تصمیم — نه در صورتجلسهها، رشتههای چت یا ارائهها پنهان شده.
- سابقه چیزی است که تصمیمات را از رویدادهای یکباره به دارایی تبدیل میکند که سازمان شما میتواند از آن بیاموزد.
یازده ماه پیش، تیم شما سه جلسه را صرف انتخاب بین ساخت ادغام درونسازمانی و خرید آن کرد. افراد با آمادگی آمده بودند. کسی یک صفحهگسترده تهیه کرده بود. بحث واقعاً خوب بود — نگرانیها مطرح شد، مزایا و معایب سنجیده شد، و تصمیمی گرفته شد. سپس همه به کار خود بازگشتند.
این هفته یک رهبر جدید مهندسی به تیم پیوست، به ادغام نگاه کرد و سوال منطقی را مطرح کرد: "چرا ما این را خودمان نساختیم؟" و پاسخ صادقانهای که برای هر کسی در اتاق در دسترس بود این بود: هیچکس دقیقاً به یاد نمیآورد. بنابراین سوال دوباره باز است. سه جلسه دوباره در حال برگزاری است — با اطلاعات کمتر از بار اول، زیرا شخصی که صفحهگسترده را تهیه کرده بود در ماه مارس رفت.
هیچ چیز در مورد آن داستان غیرمعمول نیست و این خود مشکل است. تیمهایی که هرگز یک وظیفه را از دست نمیدهند، به طور مداوم تصمیمات را از دست میدهند، زیرا وظایف یک سیستم دارند و تصمیمات یک حس دارند. این پست راهحل کامل و عملی است: چه چیزی را باید یادداشت کرد، هفت زمینهای که اهمیت دارند، چارچوبهایی که ارزش قرض گرفتن دارند و عادتهایی که باعث میشوند این تمرین پایدار بماند.
پیگیری کارهای شما هر کار انجام دادنی از سال 2023 را میداند.
هیچکس نمیتواند بگوید چرا معماریای را که با آن زندگی میکنید انتخاب کردهاید.
فاصله مستندات در تقریباً هر سازمان
سند تصمیم چیست — و این پست چه مواردی را پوشش میدهد
یک سند تصمیمگیری یک سند کوتاه و ساختارمند است که یک تصمیم مهم را ثبت میکند: چه چیزی تصمیمگیری شده، گزینههای جایگزین چه بودند، چرا این گزینه انتخاب شد، چه کسی مسئول تصمیم بود و چه زمانی بررسی خواهید کرد که آیا این تصمیم مؤثر بوده است یا نه. این سند زمانی که تصمیم گرفته میشود نوشته میشود، نه اینکه بعداً بازسازی شود و در جایی قرار دارد که کل تیم بتواند به آن دسترسی داشته باشد.
این یادداشتهای جلسه نیستند — یک حساب زمانی از یک مکالمه — و این یک وظیفه نیست. این تمایزها به اندازهای مهم هستند که هر کدام پست خاص خود را دارند: یادداشتهای جلسه در مقابل ثبت تصمیمات سطح سند را پوشش میدهد و موارد اقدام در مقابل تصمیمات سطح وظیفه را پوشش میدهد. این پست راهنمایی است که هر دوی آنها به آن اشاره میکنند.
یک یادداشت در مورد دامنه: تصمیمات مهم. محل برگزاری جلسه خارج از سایت نیازی به ثبت ندارد. هر چیزی که در شش ماه آینده از بحث دوباره آن متنفر باشید — معماری، تأمینکنندگان، قیمتگذاری، سیاست، معیارهای استخدام — نیاز به ثبت دارد. یک آزمون مفید: اگر یک همکار آینده به طور منطقی بتواند بپرسد "چرا اینطور است؟"، آن تصمیم واجد شرایط است.
هزینه واقعی تصمیمات بدون مستندات
هزینهها عادی، تکراری و عمدتاً نامرئی هستند زیرا به شکل کار معمولی ظاهر میشوند. سوالات حل شده دوباره مورد بررسی قرار میگیرند — همان بحث، دوباره به صحنه میآید، به جز کسی که زمینه را در دست داشت. استخدامهای جدید سیستمهایی را به ارث میبرند که هیچکس نمیتواند شکل آنها را توضیح دهد، بنابراین یا با شکستن چیزها دوباره یاد میگیرند یا هر سوالی را به طولانیترین فرد در اتاق ارجاع میدهند. و وقتی نتیجهای اشتباه میشود، هیچ راهی برای تشخیص اینکه آیا استدلال بد بود یا شانس بد بود وجود ندارد — که به این معنی است که فرآیند هرگز بهبود نمییابد.
یک جنبه تیزتر نیز وجود دارد: پاسخگویی. زمانی که یک تصمیم تنها در حافظه وجود دارد، تاریخچه آن توسط هر کسی که آن را بازگو میکند دوباره نوشته میشود — معمولاً به نفع خودشان. یک رکورد باعث میشود که استدلال در زمانهای مهم قابل بررسی باشد، که اساس یک ردیابی حسابرسی تصمیم واقعی است. ما یک مقاله کوتاه همراه درباره هزینه انباشته خود نوشتیم: هزینه تصمیمات بدون سند.
چارچوبهایی که در حال حاضر وجود دارند — و فاصلهای که ایجاد میکنند
شما نیازی به اختراع این روش ندارید؛ چندین چارچوب جدی به آن پرداختهاند. اما ارزش دارد که توجه کنید هر کدام واقعاً چه چیزی را پوشش میدهند، زیرا محبوبترینها مشکل مختلفی را حل میکنند نسبت به آنچه که این پست دربارهاش است.
ADR — سوابق تصمیمات معماری (نیگارد، ۲۰۱۱)
پاسخ دنیای مهندسی، از مقاله مایکل نیگارد در سال 2011: یک فایل کوچک برای هر تصمیم معماری مهم — زمینه، تصمیم، عواقب — که در مخزن پروژه نگهداری میشود. ADRها ثابت کردند که مستندسازی تصمیمات دقیقاً زمانی کار میکند که سبک باشد؛ این عمل در سطح صنعت گسترش یافت و یک اکوسیستم کامل از الگوها را به وجود آورد. این نزدیکترین چیز موجود به آنچه هر تیم نیاز دارد است. راهنمای عملی ADR ما فرمت، اکوسیستم الگوها و دلیلی که بیشتر شیوههای ADR به آرامی میمیرند — بحث و ثبت در مکانهای مختلف زندگی میکنند — را پوشش میدهد.
DACI — راننده، تأییدکننده، مشارکتکنندگان، مطلع (آتلسیان)
بازی Atlassian برای نقشها در تصمیمگیری: چه کسی تصمیم را پیش میبرد، چه کسی آن را تأیید میکند، چه کسی مشارکت میکند، چه کسی مطلع میشود. عالی برای رفع انسداد "چه کسی واقعاً این را تصمیم میگیرد؟" — اما یک انتصاب DACI یک ثبت نیست. پس از اتخاذ تصمیم، DACI هیچ چیزی برای گفتن درباره حفظ استدلال ندارد. اگر بین چارچوبهای نقش انتخاب میکنید به جای اینکه یکی یکی درباره آنها بخوانید، ما RAPID، DACI و RACI را در کنار هم با مثالهای عملی قرار دادهایم.
RAPID® — پیشنهاد، توافق، اجرا، ورودی، تصمیمگیری (بین)
چارچوب ثبت شده Bain & Company، که توسط پل راجرز و مارشیا بلنکو در مقاله خود در Harvard Business Review در سال 2006 با عنوان "چه کسی D را دارد؟" معرفی شد. مانند DACI، این چارچوب نقشهای تصمیمگیری را تعیین میکند — "D" آن تنها تصمیمگیرنده مسئول است — و به وضوح سازمانهای متوقف شده را تسریع میکند. همچنین مانند DACI: این چارچوب لحظه انتخاب را مدیریت میکند، نه حافظه آن. مقایسه سهجانبه مشخص میکند که RAPID کجا پیچیدگی اضافی خود را نسبت به DACI به دست میآورد و کجا این کار را نمیکند.
راسی — مسئول، پاسخگو، مشورت شده، مطلع
قدیمیترین و عمومیترین نمودارهای نقش، از دههها تجربه در ترسیم مسئولیت. برای وضوح اجرا در هر فرآیند مفید است؛ کمترین تصمیمگیری خاص از چهار نمودار، و دوباره — یک ماتریس نقش، نه یک ثبت. اگر چهار نمودار حروف با هم تداخل دارند، راهنمای حقوق تصمیمگیری ما برای پایان دادن به خرید وجود دارد: یکی را در پنج دقیقه انتخاب کنید و تلاش را صرف اجرای آن کنید.
الگو را مشاهده کنید: سه تا از چهار چارچوب معروف نقشها را تعیین میکنند؛ تنها ADR یک ثبت تولید میکند. نقشها و ثبتها نیمههای مکمل هستند — RAPID یا DACI به شما میگوید که چه کسی D را دارد؛ ثبت آنچه D تصمیم گرفته و چرا را حفظ میکند. بیشتر تیمهایی که احساس میکنند "ما یک فرآیند تصمیمگیری داریم" یک چارچوب نقش را پذیرفته و ثبت را به طور کامل نادیده گرفتهاند. این شکاف است که هفت زمینه زیر پر میکنند. یک چارچوب خط را در بر میگیرد و ارزش نام بردن را دارد زیرا نزدیکترین چیز به یک ثبت است که یک چارچوب نقش تولید میکند: SPADE (گوکول راجارام، استفاده شده در گوگل، فیسبوک و اسکوئر) گزینهها و توضیح را به نقشهایی که دیگران تعیین میکنند اضافه میکند — دو تا از هفت زمینه زیر، که در لحظه تصمیمگیری ثبت میشوند نه بعد از آن. این هنوز بر اساس جلسه تصمیمگیری سازماندهی میشود نه بر اساس تصمیم، بنابراین هنوز یک ثبت نیست؛ اما تیمی که در حال حاضر SPADE را اجرا میکند دو زمینه از یک ثبت فاصله دارد. نسخه کوتاه چارچوب SPADE در پنج حرف است و همه چهار چارچوب نقش در راهنمای حقوق تصمیمگیری در کنار هم قرار دارند.
چه چیزی را ثبت کنیم: هفت حوزه
این قالب اختصاصی Argumentree است — نه یک استاندارد خارجی، بلکه ترکیبی است که ما استفاده میکنیم و توصیه میکنیم: انضباط ثبت ADR، که با دو چیزی که تصمیمات کلی تیم به آن نیاز دارند و تصمیمات معماری به صورت رایگان دریافت میکنند (یک مالک صریح و یک تاریخ بررسی) گسترش یافته است. آن را به همان صورت دزدیده و استفاده کنید.
1. سوال
آنچه واقعاً در حال تصمیمگیری بود — به عنوان سوال واقعی بیان شده، نه موضوع. "کدام فروشنده برای پرداختها؟" بهتر از "پرداختها." یک سوال بد فرموله شده این است که چگونه تیمها به طور دقیق به چیز اشتباهی پاسخ میدهند. همان انضباط به اهداف نیز اعمال میشود نه انتخابها: یک نتیجه کلیدی سوالی است که از قبل پاسخ داده شده است، به همین دلیل است که یک OKR بهتر است به عنوان یک ثبت خوانده شود تا یک هدف.
2. گزینههای مورد بررسی
هر گزینهای که بهطور جدی مطرح بود، از جمله "هیچ کاری نکنیم." این زمینهای است که بیشترین بازنگری را میکشد: بیشتر تصمیمات دوباره باز شده با "آیا هرگز به این موضوع فکر کردیم...؟" شروع میشود — و پاسخ معمولاً بله است.
۳. استدلالها برای و علیه
مزایا و معایبی که واقعاً مورد بررسی قرار گرفتهاند، به گزینههایی که به آنها تعلق دارند، پیوست شدهاند. این حوزه تقریباً هر الگوئی نادیده میگیرد و دارای بیشترین ارزش به ازای هر خط است — دلیلتراشی چیزی است که یک خواننده آینده نیاز دارد تا قضاوت کند آیا تصمیم هنوز معتبر است یا خیر.
۴. تصمیم
گزینه انتخاب شده، به وضوح بیان شده است. یک جمله. اگر این فیلد یک پاراگراف را بگیرد، فیلد سوال اشتباه بوده است.
5. دلیل منطقی
چرا این گزینه برنده شد - کدام استدلالها تعیینکننده بودند و کدام مصالحهها بهطور آگاهانه پذیرفته شدند. "ما X را انتخاب کردیم با علم به اینکه هزینهاش Y است" جملهای است که مانع میشود فرد بعدی Y را بهعنوان یک غفلت در نظر بگیرد.
6. مالک
شخص مسئول برای تصمیم — "D" RAPID، نوشته شده. نه کمیته: یک نام. تصمیماتی که صاحب ثبت شدهای ندارند، به تصمیماتی تبدیل میشوند که هیچکس نمیتواند به آنها مراجعه کند، اصلاح کند یا از آنها دفاع کند.
۷. تاریخ بازبینی
زمانی که شما نتیجه را با استدلال بررسی خواهید کرد. این حوزه عادت بایگانی را به یک حلقه یادگیری تبدیل میکند — این تفاوت بین یک آرشیو و یک دارایی است و مکانیزم پشت اصل بازخورد هوش تصمیمگیری است.
یک رکورد که میتوانید کپی کنید
در عمل، هفت حوزه در نیم صفحه جا میگیرند. یک مثال کار شده، فشرده:
سوال: آیا ادغام صورتحساب را درونسازمان بسازیم یا از فروشنده A خرید کنیم؟ · گزینهها: ساخت؛ فروشنده A؛ فروشنده B؛ شش ماه به تعویق بیندازید. · استدلالها: ساخت = کنترل کامل اما ~2 فصل از نقشه راه؛ A = در 3 هفته فعال میشود، ریسک قفل شدن؛ B = ارزانتر، پوشش ضعیفتر در اتحادیه اروپا؛ به تعویق انداختن = دو قرارداد شرکتی را مسدود میکند. · تصمیم: فروشنده A، قرارداد 12 ماهه. · دلایل: دو قرارداد مسدود شده ریسک قفل شدن را در این طول قرارداد جبران میکند؛ ساخت در زمان تجدید نظر دوباره بررسی میشود. · مالک: J. Meyer. · بررسی: تجدید نظر 2027-03.
این کل اثر است. هر کسی که سال آینده به تیم ملحق شود، در چهل ثانیه آن را میخواند و میداند چه تصمیمی گرفته شده، چه چیزی را شکست داده، چه هزینهای داشته و چه زمانی دوباره به حالت اول برمیگردد. این را با صورتجلسههای سه جلسه مقایسه کنید.
تصمیمی بدون دلیل ثبت شده
این تصمیمی است که تیم شما دوباره خواهد گرفت.
روشهایی که آن را ماندگار میکند
الگوها شکست نمیخورند؛ عادتها شکست میخورند. چهار عمل که تیمهایی را که سوابق تصمیمگیریشان زنده است از تیمهایی که سوابقشان بعد از هفته دوم میمیرد جدا میکند:
آن را در اتاق بنویسید
سابقه زمانی نوشته میشود که تصمیم گرفته میشود — پنج دقیقه آخر جلسه، صفحه به اشتراک گذاشته میشود — نه "بعداً تمیز میشود." بازسازی جایی است که دلیل از بین میرود و جایی که بلندترین حافظه به رسمیترین حالت تبدیل میشود.
یک خانه، قابل جستجو
تمام سوابق در یک مکان که کل تیم میتواند جستجو کند — یک پوشه مخزن، یک فضای ویکی، یک ابزار اختصاصی. یک رکورد که هیچکس نمیتواند آن را پیدا کند، به اندازهی عدم وجود رکورد ارزش دارد. پراکنده در یادداشتهای جلسه، اینگونه است که امروز شکست میخورد.
یک رکورد برای هر تصمیم
نه به ازای هر جلسه. جلسات بحث را تولید میکنند؛ ثبتنام تصمیم را ضبط میکند، هر جلسه (یا رشته) که در نهایت در آن قرار گرفته باشد. این هسته تمایز صورتجلسه و ثبت تصمیم است.
در واقع بررسی را نگه دارید
زمانی که تاریخ بررسی فرا میرسد، ده دقیقه را صرف مقایسه نتیجه با دلایل ثبتشده کنید. آیا استدلال منطقی بود و نتیجه بدشانس بود، یا استدلال نادرست بود؟ این تمایز — که بدون ثبت امکانپذیر نیست — نحوه انباشت کیفیت تصمیمگیری است.
اشتباهات رایج
چهار حالت شکست بیشتر گزارشهای تصمیمگیری رها شده را شامل میشود:
ضبط کردن همه چیز
یک گزارش با تصمیمات سفارش ناهار در آن، همه را آموزش میدهد که آن را نادیده بگیرند. آستانه اهمیت: آیا دوباره بحث کردن در مورد این موضوع در شش ماه آینده آسیب خواهد زد؟
فقط ثبت حکم
"ما فروشنده A را انتخاب کردیم" بدون گزینهها و دلایل به هیچ سوالی که یک خواننده آینده بپرسد پاسخ نمیدهد. دلیلتراشی بار معنایی دارد؛ خود حکم تنها یک اطلاعات بیاهمیت است.
آن را به عنوان بوروکراسی متعلق به یک نفر در نظر گرفتن
اگر یک فرد کوشا لاگ را نگه دارد، با تعطیلات او میمیرد. نوشتن با مالکیت تصمیم چرخش میکند — هر کسی که D را دارد، رکورد را مینویسد.
هیچ تاریخ بازبینی وجود ندارد
یک لاگ فقط نوشتنی به یک قبرستان با نیتهای خوب تبدیل میشود. تاریخ بررسی چیزی است که باعث میشود این عمل به طور قابل مشاهدهای برای خود سودآور باشد و همین چیزی است که آن را زنده نگه میدارد.
ما چابک هستیم — آیا این فقط بار اضافی مستندسازی نیست؟
قویترین نسخه از این اعتراض شایسته بیان درست است: مستندسازی هزینه واقعی دارد، بیشتر اسناد هرگز خوانده نمیشوند و تیمی که انرژی خود را صرف نوشتن درباره کار به جای انجام آن میکند، خود را بیدلیل کندتر کرده است. بینش اجایل — نرمافزار کاربردی به جای مستندسازی جامع — اصلاحی بر یک بیماری واقعی بود.
پاسخ این است که اعتراض به شیء نادرست هدفگیری شده است. نیگارد ADRها را برای تیمهای چابک نوشت، بر اساس همین استدلال: این سند نیم صفحه است، یک بار نوشته شده، در لحظهای که دانش آزاد است — و خوانندهاش یک حسابرس نیست بلکه شما در آینده است، یازده ماه بعد، که به ادغام خیره شده و از خود میپرسد چرا. عدم تقارن هزینه بسیار شدید است: پنج دقیقه در زمان تصمیمگیری در مقابل سه جلسه دوبارهپرسی بعدی. این سند نادر است که هزینهاش را با جلوگیری از جلسات جبران میکند.
هشدار صادقانه: این روش زمانی شکست میخورد که به عنوان تئاتر فرآیند تحمیل شود — فیلدهای الزامی که هیچکس به آنها اعتقاد ندارد، سوابقی که برای رضایت یک چک باکس نوشته میشوند. این روش زمانی مؤثر است که تیم درد ناشی از آن را احساس کرده باشد. اگر تیم شما هنوز تصمیمی را از دست نداده است، با یک ورودی ثبت برای تماس مهم بعدیتان شروع کنید و بگذارید اولین لحظه "صبر کنید، ما این را نوشتیم!" عادت را به فروش برساند.
تشخیص
هر تصمیم مهمی که تیم شما در سه ماهه گذشته گرفته است را انتخاب کنید. آیا فردی که در آنجا نبود میتواند از آنچه که در هر جایی نوشته شده است، بازسازی کند که گزینهها چه بودند و چرا شکست خوردند؟ اگر نه، شما یک رویه مستندسازی ندارید؛ شما افسانه دارید.
چگونه Argumentree به طور خودکار تصمیمات را مستند میکند
همه چیز بالا با یک صفحه ویکی کار میکند. دلیلی که ما Argumentree را ساختیم این است که سختترین زمینه برای ثبت دستی، زمینه ۳ — استدلالها — است، زیرا این استدلالها به صورت زنده و در بحث اتفاق میافتند و نوشتن آنها بعد از بحث به معنای خلاصهسازی از حافظه است. در Argumentree خود فرایند بررسی ساختار یافته است: سوال صریح است، گزینهها و استدلالهای موافق و مخالف آنها یک درخت را تشکیل میدهند و امتیازها نشان میدهند که کدام استدلالها واقعاً تصمیم را تحت تأثیر قرار دادهاند.
که به این معنی است که رکورد تصمیم یک سند نیست که کسی بعد از جلسه بنویسد — این ساختار خود جلسه است که حفظ شده است. تمام هفت زمینه به طور خودکار خارج میشوند: سوال، گزینهها، استدلالها، تصمیم، دلیل (مسیر استدلال برنده)، مالک و تاریخ بررسی. هیچ مرحلهای برای رونویسی، هیچ انحراف حافظه و تمام استدلالها برای هر خواننده آینده قابل بررسی باقی میماند. آن را به صورت کامل در هوش جلسه ببینید. اگر میخواهید این فرمت را در یک تصمیم واقعی این هفته امتحان کنید، میتوانید رایگان شروع کنید و مورد بعدی را در حین انجام آن مستند کنید.
تصمیمات یک دارایی هستند — اگر آنها را حفظ کنید
تفاوت بین سازمانی که هوشمندتر میشود و سازمانی که فقط مشغول است، هوش نیست — بلکه حافظه است. کارها انجام میشوند و ناپدید میشوند؛ تصمیمات، همراه با دلایلشان، انباشته میشوند: سوابق شکل میگیرند، الگوها ظاهر میشوند و بازبینیها فرآیند را برای بهبود خود آموزش میدهند.
کوچکتر از آنچه جدی به نظر میرسد شروع کنید. تصمیم مهم بعدی: پنج دقیقه، هفت حوزه، یک خانه قابل جستجو، یک تاریخ بررسی. وقتی رهبر جدید مهندسی میپرسد "چرا این را خودمان نساختیم؟" — و کسی با یک خوانش چهل ثانیهای به جای سه جلسه پاسخ میدهد — این روش برای خود هزینهاش را به طور دائمی جبران خواهد کرد.
پنج دقیقه در زمان تصمیمگیری. سه جلسه یازده ماه بعد را نجات داد.
سند را به محصول جانبی جلسه تبدیل کنید
تصمیم مهم بعدی خود را در Argumentree اجرا کنید: استدلالهای ساختاریافته، سوابق تصمیمگیری خودکار، تاریخهای بازبینی درونساخته.
منابع و مطالعه بیشتر
- نیگارد، م. (۲۰۱۱). مستندسازی تصمیمات معماری. کگنیتکت.مقالهای که روند ADR را آغاز کرد — زمینه، تصمیم، پیامدها، یک فایل سبک برای هر تصمیم.
- سوابق تصمیمگیری معماری — adr.github.ioخانه جامعه الگوها و ابزارهای ADR؛ نشانهای از اینکه چقدر عمل ثبت گسترش یافته است.
- راجرز، پی. و بلنکو، م. (2006). چه کسی D را دارد؟ چگونه نقشهای تصمیمگیری واضح عملکرد سازمانی را بهبود میبخشد. نشریه هاروارد بیزنس ریویو، ژانویه 2006.مقالهای که چارچوب RAPID® بین را معرفی میکند — درمان مرجع نقشهای تصمیمگیری.
- کتاب بازی تیم آتلسیان — بازی DACI.چارچوب نقش آتلسیان برای تصمیمگیری: راننده، تأییدکننده، مشارکتکنندگان، مطلع.
- بین و شرکت — چه کسی D را دارد؟ (مروری بر RAPID®)خلاصه خود بین از چارچوب؛ RAPID علامت تجاری ثبت شده بین است.
سوالات متداول
سند تصمیم چیست؟
یک سند کوتاه و ساختارمند که یک تصمیم مهم را ثبت میکند: سوال، گزینههای مورد بررسی، دلایل موافق و مخالف، تصمیم، دلایل آن، مالک و تاریخ بازبینی. این سند زمانی که تصمیم گرفته میشود نوشته میشود و در یک مکان قابل جستجو نگهداری میشود.
تفاوت بین RAPID، DACI، RACI و یک رکورد تصمیم چیست؟
RAPID، DACI و RACI چارچوبهای نقشی هستند — آنها مشخص میکنند که چه کسی پیشنهاد میدهد، تأیید میکند، مشارکت میکند و تصمیم میگیرد. یک رکورد تصمیمگیری آنچه را که تصمیمگیری شده و چرا را حفظ میکند. نقشها لحظه انتخاب را مدیریت میکنند؛ رکورد حافظه آن را حفظ میکند. بیشتر تیمها به یک چارچوب نقشی به علاوه یک شیوه رکورد نیاز دارند.
کدام تصمیمات باید مستند شوند؟
مهمترینها: هر تصمیمی که از بحث دوباره آن در شش ماه آینده متنفر باشید — معماری، تأمینکنندگان، قیمتگذاری، سیاست، استانداردهای استخدام. یک آزمون عملی: اگر یک همکار آینده بهطور منطقی بتواند بپرسد چرا اوضاع اینگونه است، آن را ثبت کنید. انتخابهای عملیاتی روزمره واجد شرایط نیستند؛ ثبت همه چیز باعث از بین رفتن این تمرین میشود.
ADRها (سندهای تصمیمگیری معماری) چیستند؟
یک روش مهندسی سبک از مقاله مایکل نیگارد در سال ۲۰۱۱: یک فایل کوچک برای هر تصمیم معماری مهم، که زمینه، تصمیم و پیامدها را ثبت میکند و در مخزن پروژه ذخیره میشود. ADRها قویترین مدرک هستند که نشان میدهند مستندسازی تصمیمات سبک کار میکند و مدلی است که هر تیمی میتواند از آن تعمیم بگیرد.
چه کسی باید صورتجلسه تصمیم را بنویسد؟
مالک تصمیم — شخصی که در اصطلاح RAPID دارای D است. نوشتن با مالکیت چرخش میکند، که این عمل را در زمانی که هر فردی غایب است زنده نگه میدارد و مسئولیت را به رکورد متصل میکند.
سند تصمیمگیری چگونه با صورتجلسه جلسه متفاوت است؟
صورتجلسات یک حساب زمانی از یک مکالمه هستند که بر اساس جلسه سازماندهی شدهاند. ثبت تصمیم بر اساس تصمیم سازماندهی میشود، صرفنظر از اینکه کدام جلسات یا موضوعات آن را تولید کردهاند و گزینهها و دلایلی را که در صورتجلسات دفن یا حذف شدهاند، ثبت میکند. مقایسه کامل در پست صورتجلسات ما در مقابل ثبت تصمیم موجود است.
دیگر به بررسی مجدد تصمیماتی که قبلاً گرفتهاید نپردازید
بحث ساختاریافته در، سوابق تصمیمگیری کامل خارج — با دلایل پیوست شده و تاریخهای بررسی درونساخته.
درباره Argumentree Team
Decision Science
The Argumentree team is building the collaborative decision-making platform Argumentree. Our mission is to transform how organizations make, document, and learn from decisions.
مقالات مرتبط
با هفت حوزه مخالفید؟
در جایی که استدلالها ساختارمند هستند، بحث کنید — به بحث در انجمن Argumentree بپیوندید.
به بحث بپیوندید
