تحویل فنی و پذیرش مشتری دو رویداد متفاوت‌اند
تیم می‌گوید قابلیت تحویل شده؛ مشتری می‌گوید مسئله‌اش حل نشده است. معمولاً یکی از این شکاف‌ها وجود دارد: نیاز اولیه مبهم بوده، معیار پذیرش نوشته نشده، تغییرها بدون تأیید وارد شده‌اند یا مشتری محصول را فقط در روز آخر دیده است.
| نقطه شکست | نشانه | کنترل مناسب |
|---|---|---|
| دریافت درخواست | «گزارش بهتر می‌خواهیم» | فرم با هدف، کاربر و نمونه خروجی |
| تعریف محدوده | برداشت فروش و اجرا متفاوت | صفحه محدوده و موارد خارج از دامنه |
| ساخت | بازخورد فقط پایان کار | نمایش افزایشی و ثبت تصمیم |
| پذیرش | UAT بدون سناریو | معیار قبول و نام تأییدکننده |
| انتشار | مشتری از تغییر بی‌خبر | بسته انتشار و پیام اثرمحور |
چرخهٔ عملی از انتظار تا پذیرش
۱. مسئله را با زبان مشتری ثبت کنید
ویژگی درخواستی را به کار، کاربر و نتیجهٔ مورد انتظار وصل کنید. «داشبورد» راه‌حل است؛ «مدیر فروش تا ساعت ۹ شکاف هدف را ببیند» نیاز است.
۲. معیار پذیرش و خارج از دامنه را بنویسید
نمونه داده، نقش‌ها، خطاها و محدودیت‌ها را قبل از ساخت روشن کنید. موارد خارج از دامنه جلوی این تصور را می‌گیرد که هر برداشت معقولی در قیمت اولیه بوده است.
۳. تغییر را به تصمیم تبدیل کنید
هر درخواست تازه اثر زمان و هزینه داشته باشد و مشتری یا مالک محصول یکی از گزینه‌های افزودن، جایگزینی یا تعویق را تأیید کند. تغییر شفاهی بعداً به اختلاف حافظه تبدیل می‌شود.
۴. UAT را زود طراحی کنید
پذیرش نباید در روز انتشار اختراع شود. سناریو، داده تست، مسئول پاسخ و مهلت اصلاح را از قبل آماده کنید.
۵. انتشار را با نتیجه توضیح دهید
فهرست commit برای مشتری معنا ندارد. بگویید چه مسئله‌ای حل شده، چه چیزی تغییر نکرده و برای استفاده چه اقدامی لازم است.
سناریوی نمونه
مشتری «خروجی مالی ماهانه» می‌خواهد. تیم فایل PDF می‌سازد، اما مشتری انتظار تفکیک شعب و خروجی اکسل داشته است. راه‌حل جلسهٔ دفاع از تحویل نیست؛ نمونه خروجی و معیار پذیرش باید پیش از ساخت تأیید می‌شد. در تغییر بعدی، تیم دو نمونه را روی تسک می‌گذارد و انتخاب مشتری را ثبت می‌کند.
نقش WKFGo و محدودیت آن
فرم‌ها برای intake، ویکی برای محدوده، تأیید تسک برای دروازه کیفیت و انتشار/پکیج برای گروه‌بندی خروجی‌ها کمک می‌کنند. ابزار رضایت مشتری را تضمین نمی‌کند و جای مصاحبه، قرارداد حقوقی یا مدیریت رابطه را نمی‌گیرد. دسترسی مهمان و اسناد حساس را پیش از پایلوت آزمایش کنید.
معیار پایلوت
- بازکاری ناشی از برداشت متفاوت؛
- درخواست تغییر بدون تصمیم ثبت‌شده؛
- سناریوی UAT ردشده و علت آن؛
- زمان پاسخ به بازخورد؛
- شکایت پس از انتشار به تفکیک دامنه، کیفیت و آموزش.
قدم بعدی
یک تحویل اخیر را از درخواست تا پذیرش دنبال و اولین نقطهٔ اختلاف را پیدا کنید. کنترل خزش محدوده را بخوانید یا برای طراحی پایلوت مشتری تماس بگیرید.