موارد اقدام در مقابل تصمیمات: چرا پیگیری وظایف منطق را از دست میدهد
یک مورد عملی یک وظیفه است: چه کاری انجام خواهد شد، توسط چه کسی، تا چه زمانی — این مورد زمانی بسته میشود که کار تمام شده باشد. یک تصمیم یک انتخاب است: گزینه X به جای گزینههای Y و Z، به دلایل — و این تصمیم پس از بسته شدن هر وظیفه مرتبط همچنان مرتبط میماند، زیرا توضیح میدهد که چرا اوضاع به این شکل است. تیمها موارد عملی را به دقت در سیستمهای وظیفه پیگیری میکنند در حالی که تصمیمات پشت آنها ثبت نمیشود، که به همین دلیل سوالات حل شده دوباره مورد بحث قرار میگیرند. راه حل: هر تصمیم مهم را با گزینهها و دلایلش در یک ثبت تصمیم ثبت کنید و بگذارید موارد عملی به تصمیمی که اجرا میکنند ارجاع دهند.
پیگیری وظایف شما دقیق است و تصمیمات شما افسانهای هستند. تمایزی که آن را مشخص میکند به اندازهای کوچک است که میتوان هر کدام را در یک خط جا داد:
- یک مورد اقدام یک وظیفه است — چه، چه کسی، کی. این مورد زمانی بسته میشود که کار انجام شده باشد و پس از بسته شدن، تاریخ بیتحرک است.
- یک تصمیم یک انتخاب است — X بر Y و Z، زیرا. این هرگز "بسته" نمیشود: تا زمانی که پیامدهای آن ادامه دارد، باربر باقی میماند.
- ابزارها و عادات اولی را به دست میآورند و دومی را از دست میدهند — کار پس از جلسه ادامه دارد، اما استدلال ادامه ندارد.
- راه حل یک عادت است: تصمیمات مهم با گزینهها و دلایل ثبت میشوند (نحوه انجام) و موارد عملی به تصمیمی که اجرا میکنند ارجاع میدهند.
جلسه به خوبی به پایان میرسد. سه مورد اقدام در عرض چند دقیقه در پیگیری ثبت میشود: "انتقال صورتحساب به فروشنده A — K.، پایان اسپرینت." "غیرفعال کردن نقطه پایانی قدیمی — S.، جمعه." "بهروزرسانی صفحه قیمتگذاری — M.، پنجشنبه." مالکان، مهلتها، معیارهای انجام شده. کتاب درسی.
شش ماه بعد، هر سه وظیفه به طور کامل بسته شدهاند — و یک رهبر تیم جدید به فروشنده A نگاه میکند و میپرسد چرا این گزینه به جای گزینه واضحتر انتخاب شده است. ردیاب پاسخ سوالی را دارد که هیچکس نمیپرسد: چه کسی صورتحساب را منتقل کرد و کی. سوالی که مطرح میشود — چرا — هرگز مورد توجه کسی نبوده است. این تصمیمی بود که وظایف از آن ناشی میشد و در هیچجا وجود ندارد.
این نسخه سطح وظیفهای از مرزی است که این سری سه بار ترسیم میکند: در سطح سند در صورتجلسه در مقابل ثبت تصمیمات، و به عنوان یک تمرین کامل نوشتن در چگونه تصمیمات را مستند کنیم. این پست تیزترین برش از سه مورد است، زیرا وظایف و تصمیمات در یک نفس ادغام میشوند — معمولاً در دقیقه پایانی جلسه: "خوب، پس موارد اقدام این هستند…"
وظیفه پیگیری شد.
تصمیم گم شد.
مدل شکست جلسات بهخوبی برگزارشده
مورد اقدام در مقابل تصمیم: تفاوت واقعی
دو اثر را کنار هم قرار دهید و در هر ویژگی که مهم است، تفاوت دارند:
چیست
عملیات: یک واحد کار — چه کاری انجام خواهد شد، توسط چه کسی، تا چه زمانی. تصمیم: یک انتخاب حل شده — گزینه X به جای Y و Z، به دلایل بیان شده.
وقتی که تمام میشود
یک مورد اقدام زمانی بسته میشود که کار به پایان برسد و بسته به معنای بیتحرک است. یک تصمیم حالت انجامشده ندارد: تا زمانی که پیامدهای آن ادامه دارد، بار را تحمل میکند — اغلب به مدت سالها.
این سوال چه پاسخی بعداً میدهد
وظیفه پاسخ میدهد "آیا انجام شد؟" تصمیم پاسخ میدهد "چرا اینطور است؟" — سوالی که هر استخدام جدید، حسابرس و بررسی پس از وقوع واقعاً میپرسد.
هزینه از دست دادن آن چیست
یک وظیفه گمشده به طور خود به خود دوباره ظاهر میشود — کسی متوجه میشود که کار گم شده است. یک تصمیم گمشده به طور خاموشی شکست میخورد: انتخاب همچنان معتبر میماند در حالی که دلایل آن ناپدید میشود، تا اینکه کسی دوباره از ابتدا آن را مورد بررسی قرار دهد.
چرا تصمیم دارایی پایدار است
اینجا عدم تقارنی وجود دارد که این موضوع را ارزشمند میکند: مورد اقدام پس از اتمام بیارزش است؛ تصمیم ارزشمند میشود. هیچکس هرگز به "مهاجرت صورتحساب — K.، پایان اسپرینت" بعد از اتمام مهاجرت نیازی نداشت. اما "فروشنده A نسبت به B و ساخت، زیرا میزبانی اتحادیه اروپا B و هزینه ساخت را در دو فصل حذف کرد" هر ماه ارزش بیشتری پیدا میکند — این در چهل ثانیه سرپرست جدید را onboard میکند، یک پیشینه تعیین میکند که انتخاب فروشنده بعدی میتواند به آن ارجاع دهد، و در تجدید قرارداد به شما میگوید دقیقاً کدام فرضیات را باید دوباره بررسی کنید.
تیمها ذخیرهسازی را بهطور کاملاً معکوس انجام میدهند: سیستمهای پیچیده برای محصولی با عمر مفید یک اسپرینت و هیچ سیستمی برای محصولی با عمر مفید سالها. این معکوسسازی ناشی از بیتوجهی نیست — ردیابهای وظیفه وجود دارند زیرا وظایف صاحبانی دارند که درد از دست دادن آنها را این هفته احساس میکنند. یک تصمیم گمشده به شخص دیگری آسیب میزند، بعداً، که نمیتواند درد را به علت آن پیوند دهد. (ما آن هزینه انباشته را بهطور جداگانه در هزینه تصمیمات بدون مستندات محاسبه کردیم.) اهداف همان معکوسسازی را به ارث میبرند — اهداف سهماهه بهدقت پیگیری میشوند و استدلالی که آنها را تعیین کرده در هیچجا وجود ندارد، که موردی برای در نظر گرفتن یک نتیجه کلیدی به عنوان یک رکورد تصمیم است.
ضبط تصمیم واقعی چه چیزی را ثبت میکند
تعمیر این نیست که موارد اقدام را با زمینه پر کنیم — بلکه این است که تصمیم را به یک اثر مستقل خود بدهیم. عمل کامل ثبت هفتگانه است؛ جوهره سطح وظیفه سه چیزی است که یک مورد اقدام به طور ساختاری نمیتواند در بر بگیرد: گزینههایی که شکست خوردند (پس "آیا ما هرگز در نظر گرفتیم…؟" پاسخی دارد)، استدلالهایی که آن را تعیین کردند (پس میتوان استدلال را زمانی که شرایط تغییر میکند قضاوت کرد)، و تاریخ بازبینی (پس انتخاب به طور عمدی دوباره بررسی میشود نه به صورت بحران).
سپس به پایین لینک دهید: هر مورد عملی که تصمیم را اجرا میکند به آن اشاره میکند. "مهاجرت صورتحساب — ک., پایان اسپرینت (تصمیم #47)." یک اشارهگر، و تاریخچه بیتحرک ردیاب به تفکر زنده قابل دسترسی میشود — که همچنین ستون فقرات یک ردیابی حسابرسی تصمیم قابل استفاده است. SPADE همان درز را در حروف خود نامگذاری میکند: D تصمیم را تولید میکند و موارد عملی چیزی است که بعد از E بیرون میآید — دو اثر از یک آیین، که دقیقاً جدایی است که این پست برای آن استدلال میکند.
موارد عملی تصمیمات را اجرا میکنند.
آنها نمیتوانند آنها را توضیح دهند.
یک ثبت تصمیم لیست کارها نیست
یک اشتباه در همپوشانی نیاز به هشدار خاصی دارد، زیرا ابزارها آن را تشویق میکنند: قرار دادن تصمیمات در ردیاب وظایف به عنوان وظایف خاص. این کار به نظر منظم میرسد اما از نظر ساختاری شکست میخورد — کل چرخه عمر ردیاب برای تصمیمات مناسب نیست. وظایف میخواهند بسته شوند؛ تصمیمات نباید بسته شوند. وظایف پس از انجام از دید خارج میشوند؛ تصمیمات باید دقیقاً پس از اینکه همه چیز در اطرافشان "انجام شد" قابل پیدا کردن باشند. وظایف متعلق به انجامدهنده هستند؛ تصمیمات متعلق به تصمیمگیرنده. شش ماه بعد، یک تصمیم که به عنوان یک وظیفه ثبت شده، یک بلیط بسته در یک اسپرینت آرشیو شده است — از نظر فنی ذخیره شده، از نظر عملی ناپدید شده.
دو سیستم بهطور تمیز همزیستی میکنند به محض اینکه هر کدام اثر خود را داشته باشد: ردیاب کار را ردیابی میکند، لاگ انتخابها را نگه میدارد و اشارهگرها آنها را به هم متصل میکنند. (نسخه سطح سندی از همان جدایی: صورتجلسهها در مقابل لاگ تصمیمگیری.)
بلیطهای ما از قبل زمینه را دارند
قویترین اعتراض: بلیطهای مدرن غنی هستند — توصیفها، رشتههای نظرات، لینکها. کل بحث فروشنده در نظرات اپیک وجود دارد و زمانبندی شده است. چرا یک اثر دوم را حفظ کنیم وقتی که بحث قبلاً به کار متصل است؟
دو پاسخ ساختاری. اول، یک رشته نظر یک متن است، نه یک حکم: این رشته همه چیزهایی را که تا به حال گفته شده، به ترتیب حفظ میکند، بدون نشانهای که نشان دهد کدام استدلال واقعاً نتیجه را تعیین کرده است — بازسازی دلایل از چهل نظر باستانشناسی است و خواننده بعدی این کار را نخواهد کرد. دوم، رشته تحت کار، نه انتخاب، بایگانی میشود: وقتی حماسه بسته میشود و آرشیو دویدن به پایان میرسد، بحث نیز با آن غرق میشود. وظیفه رکورد برعکس است — یک حکم نیمصفحهای با دلایل قاطع، تحت سوال بایگانی میشود، که قابل پیدا کردن است زمانی که کاری که آن را حمل کرده، مدتها پیش ناپدید شده است.
تسلیم صادقانه: برای انتخابهای کوچک قابل بازگشت، رشته بلیط واقعاً کافی است — این روش برای تصمیماتی است که از بحث دوباره درباره آنها متنفر هستید. اگر بازگشت به آن هزینه یک دویدن یا بیشتر باشد، یک رکورد به دست میآورد؛ اگر بازگشت به آن هزینه یک بعدازظهر باشد، بگذارید بلیط آن را به دوش بکشد.
تشخیص
پیگیری خود را باز کنید و یک وظیفه کامل شده که یک انتخاب مهم را اجرا کرده است پیدا کنید. حالا سعی کنید به این سوال پاسخ دهید، از هر چیزی که در هر جایی نوشته شده است: گزینهها چه بودند و چرا شکست خوردند؟ اگر مسیر به "بر اساس بحث" ختم میشود — تصمیمات شما افسانههایی با مهلت هستند.
چگونه Argumentree تصمیمات را ثبت میکند — با استدلال مرتبط
دلیل اینکه تصمیمات ثبت نمیشوند این است که ثبت آنها یک مرحله جداگانه پس از بحث است — و مراحل جداگانه نادیده گرفته میشوند. در Argumentree خود بحث، ثبت است: سوال به وضوح مطرح شده، گزینهها با دلایل مثبت و منفی خود در یک درخت رتبهبندی شده قرار دارند و تصمیم با دلایل قاطع خود که از قبل ساختار یافته است، نهایی میشود. هیچ چیزی برای رونویسی، هیچ چیزی برای بازسازی وجود ندارد.
موارد عملی سپس تنها کاری را که در آن خوب هستند — اجرا کردن — انجام میدهند در حالی که هر سوال "چرا" به یک رکورد زنده ارجاع داده میشود. ردیاب اسپرینت را حفظ میکند؛ Argumentree دلایل را نگه میدارد. برای ثبت تصمیم بعدی به جای فقط وظایف آن، رایگان شروع کنید و یک انتخاب واقعی با دلایل آن را ثبت کنید.
کار را پیگیری کنید. دلیل را حفظ کنید.
موارد عملی و تصمیمات هر دو آثار واقعی هستند و هر دو نیاز به سیستم دارند — مشکل در این است که از یک سیستم برای هر دو استفاده میشود و اجازه داده میشود که اثر پایدار در چرخه عمر اثر قابل دور انداختن از بین برود.
بنابراین دقیقه پایانی جلسات خود را حفظ کنید، با یک اصلاح. بعد از "خوب، موارد اقدام عبارتند از..." سوال دوم را اضافه کنید: "و ما چه تصمیمی گرفتیم و چرا؟" پنج دقیقه، هفت حوزه، یک ورودی ثبت — و سرنخ جدید بعدی به جای یک پروژه باستانشناسی، پاسخی دریافت میکند.
کارها نزدیک میشوند. تصمیمات پیچیده میشوند.
به تصمیمات سیستم خاص خود را بدهید
یک بار به صورت ساختاری استدلال کن — و استدلال را تا زمانی که تصمیم برقرار است، حفظ کن.
منابع و مطالعه بیشتر
- نیگارد، م. (۲۰۱۱). مستندسازی تصمیمات معماری. کگنیتکت.عملکرد ثبت-بر-تصمیم که این پست به آن اشاره دارد در مرز وظیفه اعمال میشود — تصمیمات از کارهایی که آنها را اجرا میکنند فراتر میروند.
- راجرز، پی. و بلنکو، م. (2006). چه کسی D را دارد؟ نشریه کسب و کار هاروارد، ژانویه 2006.مالکیت تصمیمگیری (RAPID®) — چرا تصمیمگیرنده، نه انجامدهنده، مالک رکورد است.
- سوابق تصمیمات معماری — adr.github.ioالگوها و ابزارها برای شیوه ثبت تصمیمات.
سوالات متداول
تفاوت بین یک مورد اقدام و یک تصمیم چیست؟
یک مورد اقدام یک وظیفه است — چه کاری انجام خواهد شد، توسط چه کسی، تا چه زمانی — و زمانی که کار تمام شد، بسته میشود. یک تصمیم یک انتخاب حل شده است — یک گزینه نسبت به گزینههای دیگر، به دلایل بیان شده — و تا زمانی که پیامدهای آن ادامه دارد، مرتبط باقی میماند. وظیفه پاسخ میدهد "آیا انجام شد؟"; تصمیم پاسخ میدهد "چرا اینگونه است؟"
چرا نباید تصمیمات در ردیاب وظایف پیگیری شوند؟
زیرا چرخه عمر ردیاب برای آنها نادرست است: وظایف باید بسته و بایگانی شوند، در حالی که تصمیمات باید مدتها پس از اتمام کار مرتبط قابل پیدا کردن باشند. یک تصمیم که به عنوان یک تیکت ثبت شده، به یک مورد بسته در یک اسپرینت بایگانی شده تبدیل میشود — ذخیره شده اما عملاً غیرقابل پیدا کردن. تصمیمات باید در یک ثبت تصمیم قرار گیرند، با موارد عملی که به تصمیمی که اجرا میکنند اشاره دارند.
آیا همه تصمیمات نیاز به ثبت دارند؟
نه — فقط انتخابهای مهم. یک آستانه عملی: اگر معکوس کردن انتخاب هزینه یک اسپرینت یا بیشتر را داشته باشد، یا اگر از بحث دوباره درباره آن در شش ماه آینده متنفر باشید، ثبت میشود. انتخابهای کوچک و معکوسپذیر میتوانند در تیکتی که آنها را پیادهسازی میکند، باقی بمانند.
سند تصمیمگیری باید شامل چه مواردی باشد؟
حداقل سه چیزی که یک مورد اقدام نمیتواند شامل شود: گزینههایی که شکست خوردند، استدلالهایی که نتیجه را تعیین کردند و تاریخ بررسی. الگوی کامل هفتمیدانی — سوال، گزینهها، استدلالها، تصمیم، دلیل، مالک، تاریخ بررسی — در راهنمای ما برای مستندسازی تصمیمات موجود است.
آیا رشته نظرات بلیط در حال حاضر رکورد تصمیم نیست؟
یک رشته نظر یک متن است، نه یک حکم: همه چیزهایی که گفته شده را حفظ میکند بدون نشانهای برای آنچه واقعاً نتیجه را تعیین کرده است و تحت کار بایگانی میشود، بنابراین وقتی بلیط بسته میشود، آرشیو میشود. یک رکورد برعکس است — یک حکم کوتاه با استدلال قاطع، که تحت سوال بایگانی میشود و پس از ناپدید شدن کار قابل پیدا کردن است.
چگونه موارد اقدام و ثبت تصمیمات به هم متصل میشوند؟
با ارجاع: هر مورد عملی که یک تصمیم را اجرا میکند، ورودی ثبت آن را ذکر میکند ("تصمیم شماره ۴۷"). پیگیریکننده کار را نگه میدارد؛ ثبتنام دلیل را نگه میدارد؛ اشارهگر آنها را در هر دو جهت قابل پیمایش نگه میدارد.
از بحث مجدد در مورد سوالات حل شده خودداری کنید
بحث ساختاریافته با سوابق تصمیمگیری خودکار — استدلال به اندازهای که تصمیم وجود دارد، باقی میماند.
درباره 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.
مقالات مرتبط
آیا فکر میکنید موضوع بلیط کافی است؟
استدلال را به صورت ساختار یافته به فروم آرگومنتری بیاورید.
به بحث بپیوندید
