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