تبدیل یادداشت پراکنده به سند تصمیم با واقعیت و مسئول مشخص
سند قرار است کدام تصمیم را ممکن کند؟
گزارش را با تصمیمی که باید گرفته شود و پیشنهاد خودتان شروع کنید. بعد، شاهدها، گزینهها و ابهامهای مؤثر را بیاورید. خواننده باید بداند از او چه تصمیمی خواستهاید و با چه اطلاعاتی میتواند آن را بگیرد.
اگر یادداشتهای جلسه دربارهٔ مشکل یک فرم پراکندهاند، بازنویسی جملهها کافی نیست. باید روشن شود آیا دربارهٔ تحقیق بیشتر، تغییر متن یا ساخت قابلیت تازه تصمیم میگیرید. هرکدام اطلاعات و مسئول متفاوتی نیاز دارد.
گزارش مدیریتی، وضعیت و انتخابها را برای تصمیم توضیح میدهد. سند نیازمندی محصول، رفتار مورد انتظار و محدودهٔ کار را برای تیم اجرا روشن میکند. این دو میتوانند از یک مسئله شروع شوند و خروجی متفاوت داشته باشند.
واقعیت و برداشت را چگونه جدا کنیم؟
کنار یادداشتهای اولیه چهار برچسب بگذارید: مشاهده، تفسیر، فرض و پیشنهاد. مشاهده چیزی است که شاهد مشخص دارد. تفسیر، معنایی است که از آن میگیرید. فرض هنوز نیازمند بررسی است و پیشنهاد، اقدام مورد نظر شماست.
در سناریوی فرضی این مقاله، تیم هنگام مرور یک فرم دیده است راهنمای قالب شناسه کنار فیلد وجود ندارد. همین مشاهده محدود است. هنوز نمیدانیم چند کاربر دچار مشکل میشوند یا افزودن راهنما چه اثری دارد.
جملهٔ «کاربران بهخاطر این فیلد ثبتنام را رها میکنند» از دادهٔ سناریو پشتیبانی نمیشود. میتوانید آن را به پرسش تحقیق تبدیل کنید. هیچ نرخ ریزش یا نتیجهٔ آزمونی برای پرکردن گزارش نمیسازیم.
| نوع جمله | جملهٔ سناریوی فرضی | مدرک یا نیاز بعدی |
|---|---|---|
| مشاهده | کنار فیلد شناسه، راهنمای قالب نیست | مشاهدهٔ نسخهٔ فرم در سناریو |
| تفسیر | ممکن است انتظار فیلد روشن نباشد | نیازمند مشاهدهٔ کاربر |
| فرض | نمونهٔ قالب به فهم کمک میکند | نیازمند آزمون |
| پیشنهاد | نسخهای با راهنما بررسی شود | تصمیم دربارهٔ اجرای بررسی |
یادداشت تصمیم کوتاه چه شکلی دارد؟
نمونهٔ زیر برای همان فرم فرضی نوشته شده است. هدف، انتخاب گام بعدی است. متن از مدیر تأیید انتشار یا بودجهٔ نامشخص نمیگیرد؛ تصمیم خواستهشده را به بررسی محدود میکند.
از همان مسئله، سند محصول چگونه بسازیم؟
سند محصول باید رفتار قابل مشاهده و مرز کار را توضیح دهد. راهنمای رسمی اتلسیان، هدف، فرضها، داستان کاربر و پرسشهای باز را از اجزای سند نیازمندی میداند. این ساختار به همکاری تیم کمک میکند؛ ابزار خاصی برای نوشتن آن لازم نیست.
تا زمانی که قالب شناسه تأیید نشده، متن نهایی راهنما هم نباید قطعی شود. سند میتواند شرط آمادهشدن متن و آزمون لازم را مشخص کند. نمونهٔ زیر دربارهٔ یک تغییر پیشنهادی است و وجود قابلیت اجراشده را ادعا نمیکند.
با عددها و ابهامهای گزارش چه کنیم؟
هر عدد باید واحد، بازهٔ زمانی و محل استخراج داشته باشد. اگر تعداد پیامهای پشتیبانی را میآورید، مشخص کنید تکرارها چگونه شمرده شدهاند. اگر داده ناقص است، اثر این نقص بر تصمیم را توضیح دهید.
گاهی عدد لازم هنوز جمع نشده است. خانه را با برچسب «اندازهگیری نشده» نگه دارید و کار جمعآوری را تعریف کنید. «صفرِ مشاهدهشده» یعنی سنجش انجام شده و رخدادی ثبت نشده است. «کاربرد ندارد» یعنی این سنجه برای موضوع مناسب نیست.
در نمونهٔ فرم، از نبودن راهنما نمیتوان نرخ خطا استخراج کرد. گزارش خوب این فاصله را قابل دیدن میکند. مدیر میتواند دربارهٔ نیاز به بررسی تصمیم بگیرد، بدون اینکه پیشاپیش نتیجهٔ بررسی به او القا شود.
صورتجلسه چگونه به کار قابل پیگیری برسد؟
برای هر تصمیم، متن دقیق، مسئول پذیرفتهشده و موعد تأییدشده را بنویسید. اگر مسئول یا موعد هنوز تعیین نشده است، همان وضعیت را ثبت کنید. نسبتدادن کار به کسی که نپذیرفته، پیگیری را از ابتدا مبهم میکند.
در پایان جلسه، تصمیم را برای حاضران بازخوانی کنید. فرق «پیشنهاد شد» با «تصویب شد» را حفظ کنید. نسخهٔ سند و محل ثبت اصلاحها را نیز مشخص کنید تا یادداشتهای موازی به تصمیمهای ناسازگار تبدیل نشوند.
راهنمای اتلسیان، بهروزرسانی سند با تغییر نیازمندیها را مسئلهای واقعی میداند. برای همین، پس از هر تصمیم مؤثر، بخش مرتبط سند را اصلاح کنید. نگهداشتن سند قدیمی کنار محصول تازه، خوانندهٔ بعدی را گمراه میکند.
چطور سند را پیش از جلسه آزمایش کنیم؟
سند را به همکاری بدهید که در بحث اولیه نبوده است. از او بخواهید پرسش تصمیم، شاهد اصلی و مجهول مؤثر را پیدا کند. اگر لازم شد شفاهی چند دقیقه توضیح بدهید، همان اطلاعاتِ ضروری احتمالاً در سند کم است.
نظر او را به محل مشخص وصل کنید. بهجای «گزارش واضح نیست»، بپرسید کدام جمله تصمیم یا وضعیت را نامعلوم گذاشته است. سپس همان بخش را اصلاح کنید و دوباره از ابتدا بخوانید.
پرسشهای هنگام نهاییکردن سند
آیا خلاصهٔ مدیریتی باید نتیجهٔ قطعی داشته باشد؟ میتواند پیشنهاد مشروط یا درخواست بررسی باشد. درجهٔ قطعیت باید با شاهد هماهنگ بماند.
آیا سند محصول باید همهٔ جزئیات فنی را تعیین کند؟ نیاز و معیار پذیرش را روشن کنید. راهحل فنی را با تیم مسئول بررسی کنید و تصمیمهای مؤثر را در سند مرتبط نگه دارید.
برای تمرین، پنج جمله از آخرین صورتجلسه را انتخاب کنید. به هرکدام یکی از چهار برچسب بدهید. سپس یک پرسش تصمیم بنویسید که واقعاً با همین اطلاعات قابل بررسی باشد.
منابع مقاله
- اتلسیان؛ نوشتن سند نیازمندی محصول
اجزای سند از جمله هدف، فرض، نیاز کاربر و پرسش باز؛ همچنین خطر قدیمیشدن سند. نمونههای این مقاله مستقل و فرضیاند.
تاریخ بررسی: ۱۲ مهر ۱۴۰۵
- دولت بریتانیا؛ بررسی انجام کار توسط کاربر
پشتوانهٔ روش مشاهدهٔ تکلیف مشخص؛ برای سناریوی مقاله هیچ آزمون واقعی یا نتیجهٔ آماری گزارش نشده است.
تاریخ بررسی: ۱۲ مهر ۱۴۰۵
در تهیه و بررسی این مقاله از هوش مصنوعی کمک گرفتهایم. منابع بالا برای بررسی بیشتر در دسترساند. پیشنهادها را با شرایط کار خودتان بسنجید.
این روش را روی متن خودتان امتحان کنید
اشتباه یا نکتهٔ مبهمی دیدید؟ در گیتهاب گزارش کنید. نام مقاله و بخش مربوط کافی است؛ اطلاعات محرمانه را در گزارش عمومی ننویسید.