چارچوب ورودیهای کسبوکار و فرایند تحویل محصول¶
Info
نسخه: 1.0
وضعیت: پیشنهادی
دامنه: همکاری کسبوکار، محصول، طراحی، نرمافزار و تیمهای تخصصی
مخاطبان: Business، Product، Design، Engineering، QA، Operations، Risk، Legal، Security و Management
۱. هدف سند¶
این سند مشخص میکند:
- تیم محصول برای آغاز و ادامه کار چه مستندات و تصمیمهایی از کسبوکار نیاز دارد؛
- کدام ورودیها باید توسط سایر تیمهای تخصصی مانند بانک، ریسک، حقوقی، برند، امنیت و عملیات تأمین شوند؛
- تیم محصول چگونه ورودیهای کسبوکار را به خروجی قابلطراحی و قابلتوسعه تبدیل میکند؛
- چه شرایطی برای ورود به Discovery، Development و Release لازم است؛
- برای احراز هویت، ورود، ساخت کسبوکار و افتتاح حساب SME Neobank چه تصمیمها و مستندات اختصاصی لازم است.
این سند جایگزین PRD، سیاستهای ریسک، مستندات حقوقی، استاندارد امنیت یا مستند API نیست؛ بلکه قرارداد همکاری و ورودیهای موردنیاز میان تیمها را تعریف میکند.
۲. اصل پایه همکاری¶
تیم کسبوکار لازم نیست راهکار فنی، طراحی رابط یا PRD کامل تولید کند. مسئولیت اصلی کسبوکار، شفافکردن و تأیید موارد زیر است:
- مسئله و فرصت؛
- مشتری هدف؛
- هدف و ارزش مورد انتظار؛
- دامنه و اولویتها؛
- قواعد، محدودیتها و پارامترهای کسبوکار؛
- فرایند عملیاتی و استثناها؛
- معیار موفقیت و پذیرش.
تیم محصول این ورودیها را به مسئله تعریفشده، Journey، Scope، Prototype، PRD، Backlog و Acceptance Criteria تبدیل میکند. تیم نرمافزار نیز راهکار فنی را طراحی، پیادهسازی، آزمون و عملیاتی میکند.
flowchart LR
subgraph B["کسبوکار تحویل میدهد"]
B1["جهت و ارزش<br/>Business Brief، مشتری هدف، ارزش پیشنهادی، KPI"]
B2["دامنه و قواعد<br/>Journey، MVP، Business Rule، عملیات و استثنا"]
B3["تصمیم و پذیرش<br/>Decision Matrix، Dependency، UAT، Go/No-Go"]
end
P["تیم محصول پردازش میکند<br/>کشف و اعتبارسنجی مسئله<br/>رفع ابهام و ثبت تصمیم<br/>تعریف دامنه و اولویت<br/>طراحی جریان و Prototype<br/>تعریف Requirement و AC"]
O["تیم محصول تولید میکند<br/>Product Brief / PRD<br/>Journey / Service Blueprint<br/>Prototype / UX/UI<br/>Backlog / User Story<br/>Acceptance Criteria<br/>Roadmap / Release Plan"]
B1 --> P
B2 --> P
B3 --> P
P --> O
Important
تیم محصول میتواند گزینه، تحلیل و پیشنهاد ارائه کند، اما نباید تصمیمهای کسبوکاری، حقوقی، ریسکی یا بانکی را حدس بزند. هر فرض موقت باید ثبت شود و مالک تأیید داشته باشد.
۳. مرز مسئولیت تیمها¶
| حوزه | مالک اصلی | نقش تیم محصول | نقش تیم نرمافزار |
|---|---|---|---|
| مسئله، بازار و هدف کسبوکار | Business | کشف و صورتبندی مسئله | ارائه محدودیت و امکانسنجی |
| مشتری هدف و ارزش پیشنهادی | Business | تحقیق، Segment و Persona | مشارکت در امکانسنجی |
| Scope و اولویت محصول | Product با تأیید Business | مالک تعریف و اولویتبندی | تخمین و اعلام وابستگی |
| قواعد کسبوکار | Business و Domain Owner | تبدیل به Rule و AC قابلتست | پیادهسازی و تست |
| الزامات حقوقی و انطباق | Legal، Risk و Compliance | تبدیل الزام به جریان و نیازمندی | پیادهسازی کنترلها و شواهد |
| UX و UI | Product Design | مالک طراحی و اعتبارسنجی | بررسی امکانپذیری و پیادهسازی |
| معماری و راهکار فنی | Engineering | ارائه نیاز و محدودیت محصول | مالک تصمیم فنی |
| API و سرویس بانکی | Bank/Technical Owner | مشخصکردن نیاز سرویس | اعتبارسنجی، اتصال و مانیتورینگ |
| عملیات و استثناها | Operations و Business | طراحی Service Blueprint | ساخت ابزار و اتوماسیون |
| پذیرش کسبوکار | Business Owner | برنامهریزی و تسهیل UAT | رفع نقص و ارائه نسخه |
| انتشار و پایداری | Engineering، Operations و Product | هماهنگی Go/No-Go | انتشار، Rollback و پایش |
۴. بسته عمومی مستندات موردنیاز از کسبوکار¶
کسبوکار لازم نیست نویسنده انحصاری همه اسناد باشد، اما باید مالک جمعآوری پاسخها، هماهنگی ذینفعان و اخذ تأیید نهایی باشد.
۴.۱ اسناد لازم پیش از Discovery¶
| کد | سند | حداقل محتوای الزامی | قالب پیشنهادی | تأییدکننده |
|---|---|---|---|---|
| D01 | Business/Product Brief | مسئله، فرصت، هدف قابلاندازهگیری، مشتری کلان، فرضیات، محدودیتها و اسپانسر | ۱ تا ۲ صفحه | Sponsor و Business Owner |
| D02 | سند مشتری و بازار هدف | Segmentها، ویژگی مشتری، نیاز، صنعت، اندازه، جغرافیا، شرایط ورود و گروههای خارج از هدف | جدول Segment | Business Owner |
| D03 | ارزش پیشنهادی و مدل کسبوکار | ارزش برای مشتری، جایگزینها، رقبا، مدل درآمد، هزینه، شرکا و فرضیات اقتصادی | Value Proposition و Business Model Canvas | Business و Finance |
| D04 | سفرهای اولویتدار و دامنه MVP | ۳ تا ۵ Journey اصلی، نیازهای عملیات، Must/Should/Later، داخل و خارج MVP | Journey/Use Case Priority Table | Business و Product |
| D05 | ماتریس مالکیت تصمیمها | ذینفعان، تصمیمگیر هر حوزه، تأییدکننده، SLA تصمیم و مسیر Escalation | RACI و Decision Matrix | Sponsor |
۴.۲ اسناد لازم پیش از تعهد توسعه¶
| کد | سند | حداقل محتوای الزامی | قالب پیشنهادی | تأییدکننده |
|---|---|---|---|---|
| D06 | کاتالوگ قواعد کسبوکار | Rule ID، Trigger، Condition، Outcome، Exception، Source، Owner و Version | Spreadsheet | Business/Domain Owner و تیم تخصصی مربوطه |
| D07 | ماتریس پارامترهای محصول | شرایط پذیرش، مدارک، تعرفه، محدودیتها، نقشها، آستانهها و خروجی هر شرط | Decision Table | Business، Finance، Risk حسب موضوع |
| D08 | فرایند عملیات و استثناها | Happy Path، مراحل دستی، نقش اپراتور، صف، SLA، خطا، بازگشت، توقف و Escalation | BPMN/Swimlane و Exception Table | Business و Operations |
| D09 | رجیستر وابستگیها و تعهد شرکا | وابستگی، سرویس/شریک، مالک، موعد، وضعیت، مدرک آمادگی، اثر تأخیر و Plan B | Dependency Register | Sponsor و Dependency Owner |
| D10 | پیشبینی حجم و سطح خدمت | تعداد مشتری، رشد، تراکنش، Peak، Conversion، ساعات خدمت و SLA وعدهدادهشده | Base/High Forecast | Business، Finance و Operations |
| D11 | فرهنگ KPI و گزارشها | تعریف KPI، فرمول، منبع، Target، بازه، تفکیک، تناوب و مالک اقدام | KPI Dictionary | Business، Product و Data |
۴.۳ سند لازم پیش از انتشار¶
| کد | سند | حداقل محتوای الزامی | قالب پیشنهادی | تأییدکننده |
|---|---|---|---|---|
| D12 | سناریوهای UAT و مجوز انتشار | سناریوی End-to-End، خطا و Edge Case، نتیجه مورد انتظار، تستکننده، شرط Go/No-Go و Sign-off | UAT Sheet و Readiness Checklist | Business Owner و Operations |
۴.۴ معیار پذیرش و اثر نبود هر سند¶
| کد | معیار پذیرش سند | اگر سند موجود یا قابل قبول نباشد |
|---|---|---|
| D01 | هدف دارای عدد و بازه زمانی است و سند صرفاً فهرست قابلیتها نیست | تیم نمیداند چه نتیجهای باید بسازد یا موفقیت را چگونه بسنجد |
| D02 | برای هر Segment بتوان بهروشنی گفت چه کسی داخل و چه کسی خارج دامنه است | جریان و محتوا برای یک کاربر فرضی طراحی میشود |
| D03 | دلیل استفاده مشتری و منطق اقتصادی محصول هر دو روشن و قابلآزموناند | ممکن است محصول قابلساخت باشد اما ارزش یا توجیه اقتصادی نداشته باشد |
| D04 | هر درخواست اولویت دارد و مرز MVP با فازهای بعدی مخلوط نیست | همه خواستهها ضروری تلقی میشوند و زمان و هزینه کنترلپذیر نیست |
| D05 | برای هر حوزه یک تصمیمگیر نهایی و SLA پاسخ مشخص وجود دارد | جلسه برگزار میشود اما تصمیم و مسئول تأخیر مشخص نیست |
| D06 | هر قاعده بهشکل «اگر/آنگاه» قابلتست است و عبارت مبهم ندارد | تیم توسعه ناچار میشود قواعد کسبوکار را حدس بزند |
| D07 | برای هر ترکیب مهم از شرایط، خروجی و پارامتر دقیق مشخص است | محصول از نظر ظاهری ساخته میشود اما رفتار واقعی آن تعریف نشده است |
| D08 | برای هر شکست یا توقف، اقدام بعدی، مالک و SLA مشخص است | فقط Happy Path ساخته میشود و محصول در خطاهای واقعی متوقف میماند |
| D09 | هر وابستگی مالک، موعد و مدرک آمادگی دارد | برنامه توسعه بر وعدههایی بدون زمان تحویل متکی میشود |
| D10 | عددها دارای بازه زمانی، سناریو و منبع فرضیات هستند | ظرفیت، هزینه، معماری و پشتیبانی قابلبرآورد نیست |
| D11 | دو نفر مستقل هر KPI را به یک شکل محاسبه میکنند | موفقیت یا شکست محصول پس از انتشار قابلاثبات نیست |
| D12 | سناریوهای بحرانی پاس شده و پذیرش کتبی Business Owner موجود است | تیم فنی بهتنهایی مسئول ریسک کسبوکاری انتشار میشود |
۴.۵ قواعد کیفی بسته عمومی¶
هر سند باید:
- مالک و تأییدکننده مشخص داشته باشد؛
- تاریخ و نسخه داشته باشد؛
- تصمیمها را از فرضیات و پرسشهای باز جدا کند؛
- از عبارات مبهم مانند «در صورت نیاز» یا «طبق روال» بدون تعریف دقیق پرهیز کند؛
- به تصمیم یا نتیجه قابلآزمون منتهی شود؛
- تغییرات آن در Decision Log ثبت شود.
۵. خروجیهایی که تیم محصول تولید میکند¶
پس از دریافت و تحلیل ورودیها، تیم محصول مسئول تولید و نگهداری خروجیهای زیر است:
| خروجی | هدف |
|---|---|
| Problem Statement | تعریف مسئله، کاربر و اثر آن |
| Product Brief / PRD | تعریف هدف، دامنه، نیازمندی، قواعد، وابستگی و معیار پذیرش |
| Customer Journey | نمایش تجربه کاربر از ابتدا تا انتها |
| Service Blueprint | نمایش تعامل مشتری، سیستم، عملیات و تیمهای پشتصحنه |
| Prototype و UX/UI Design | اعتبارسنجی جریان و راهکار پیش از توسعه |
| Backlog و User Story | شکستن نیازمندی به اقلام قابلتحویل |
| Acceptance Criteria | تعریف رفتار قابلآزمون |
| Roadmap و Release Plan | ترتیب تحویل، وابستگی و هدف هر انتشار |
| Decision Log | ثبت تصمیم، مالک، تاریخ، گزینهها و دلیل انتخاب |
| Assumption Log | ثبت فرضیات تأییدنشده و برنامه اعتبارسنجی |
۶. ورودیهای موردنیاز از سایر تیمها¶
| تیم | ورودی موردنیاز |
|---|---|
| Branding | نام رسمی محصول، لوگو، رنگ، تایپوگرافی، لحن، واژهنامه، قواعد استفاده از برند و تأیید محتوا |
| Legal | قراردادها، رضایتنامهها، حریم خصوصی، شرایط استفاده، مالکیت داده و متنهای حقوقی |
| Risk/Compliance | KYC/KYB، AML، کنترل تقلب، تحریم/PEP حسب دامنه، نگهداری داده و قواعد پذیرش/رد |
| Bank/Technical Provider | API، مستندات، Sandbox، Access، Authentication، Sample، Error Code، Rate Limit، SLA و Support Owner |
| Operations | فرایند دستی، نقش اپراتور، صف، SLA، استثنا، Escalation و Runbook |
| Support | کانالها، سناریو پاسخ، شکایت، سطح خدمت و آموزش |
| Security/Infrastructure | سیاست Authentication، Session، Access، Logging، Monitoring، Pentest، Incident و Disaster Recovery |
| Data/BI | تعریف KPI، Eventها، گزارشها، Data Classification، Retention و دسترسی داده |
| Finance | کارمزد، هزینه، تسویه، بودجه، حجم و کنترل مالی |
۷. معیار آمادگی API و سرویس بیرونی¶
وجود نام یک API یا وعده ارائه آن بهمعنای آمادگی نیست. هر سرویس زمانی Ready است که موارد زیر موجود و آزموده شده باشد:
APIچکلیست آمادگی سرویس بیرونی
- کاربرد و مالک سرویس
- Endpoint و Method
- Schema ورودی و خروجی
- فیلدهای اجباری و Validation
- Sample Request/Response
- Error Code، Timeout و Retry Behavior
- Authentication، Certificate، VPN و IP Access
- Sandbox قابلاستفاده
- Rate Limit و ظرفیت
- SLA و ساعات پشتیبانی
- Versioning و Change Policy
- Webhook یا الگوی پردازش غیرهمزمان
- Data Policy، Logging و اطلاعات حساس
- اتصال آزمایشی موفق و شواهد آن
Warning
تا پیش از اتصال آزمایشی موفق، وابستگی API نباید در برنامه تحویل بهعنوان «آماده» در نظر گرفته شود.
۸. چرخه توسعه محصول نرمافزاری¶
flowchart LR
A["۱. جهت و مالکیت"] --> B["۲. کشف نیاز"]
B --> C["۳. تعریف محصول"]
C --> D["۴. طراحی تجربه و راهکار"]
D --> E["۵. آمادگی فنی و وابستگیها"]
E --> F["۶. ساخت و آزمون"]
F --> G["۷. UAT و انتشار"]
G --> H["۸. عملیات و بهبود"]
H --> B
| مرحله | ورودی اصلی | خروجی اصلی | دروازه عبور |
|---|---|---|---|
| جهت و مالکیت | هدف، مشتری، Sponsor و حدود اختیار | Product Charter، RACI و KPI | هدف و مالکیت تأیید شده است |
| کشف نیاز | دسترسی به مشتری، عملیات و خبرگان | مسئله معتبر، Journey و پرسشهای باز | مسئله و کاربر با شواهد تأیید شدهاند |
| تعریف محصول | Journey، قواعد و مدل اقتصادی | PRD، MVP، Backlog و AC | دامنه و قواعد به تأیید رسیدهاند |
| طراحی | PRD، برند، حقوقی و قیود فنی | Prototype، UI و Solution Design | تجربه و راهکار تأیید شدهاند |
| آمادگی فنی | API، Sandbox، Access و Environment | سرویس قابلتست و محیط آماده | وابستگی حیاتی واقعاً قابل استفاده است |
| ساخت و آزمون | Backlog Ready و Design Approved | نسخه قابلآزمون و Test Evidence | معیار کیفیت و AC پاس شده است |
| UAT و انتشار | نسخه پایدار، UAT و مجوزها | Sign-off و Go/No-Go | مالکان تخصصی انتشار را پذیرفتهاند |
| عملیات و بهبود | KPI، رخداد و بازخورد | گزارش عملکرد و Backlog بهبود | چرخه یادگیری و پاسخگویی برقرار است |
۹. Definition of Ready در سه سطح¶
Gate 1Ready for Discovery
- D01 تا D05 موجود است
- Business Owner و Decision Owner معرفی شدهاند
- مشتری یا نماینده عملیات برای مصاحبه در دسترس است
- سؤالهای باز و محدودیتهای شناختهشده ثبت شدهاند
Gate 2Ready for Development
- D06 تا D11 تأیید شدهاند
- PRD، Flow، Design و Acceptance Criteria آمادهاند
- API Contract و معماری Review شدهاند
- وابستگیهای حیاتی در Sandbox آزموده شدهاند
- Security، Risk، Legal و Operations موارد مرتبط را تأیید کردهاند
- Scope و تغییرات پس از شروع، فرایند Change Management دارند
Gate 3Ready for Release
- D12 و UAT Sign-off موجود است
- تست Functional، Integration، Security و Performance حسب نیاز پاس شده است
- Monitoring، Alerting، Runbook و Rollback آمادهاند
- آموزش Operations و Support انجام شده است
- مجوزهای Risk، Legal، Security و Business اخذ شدهاند
- مالک Go/No-Go مشخص است
۱۰. بسته اختصاصی SME Neobank برای احراز هویت، ورود و افتتاح حساب¶
۱۰.۱ اصل تصمیمگیری¶
در محصول بانکی، پاسخها از چهار منبع میآیند:
- Business: محصول برای چه مشتری و چه نتیجهای طراحی میشود؛
- Bank/Risk/Legal/Compliance: چه چیزی مجاز است و چگونه باید اعتبارسنجی شود؛
- Product: قواعد چگونه به Journey، UX، Scope و Requirement تبدیل میشوند؛
- Engineering/Security: راهکار چگونه امن، پایدار و قابلپایش پیادهسازی میشود.
۱۰.۲ مالک پاسخ پرسشهای کلیدی¶
| پرسش | مالک تصمیم/پاسخ | خروجی تیم محصول |
|---|---|---|
| مشتری حقیقی، حقوقی یا هر دو است؟ | Business با تأیید Bank/Risk | Segment و Journeyهای مجزا |
| چه نوع حساب یا محصولی باز میشود؟ | Business و Bank با تأیید Finance/Legal | Account Opening Flow و Product Configuration |
| چه کسی مجاز به ساخت کسبوکار است؟ | Bank، Legal، Risk و Business | Eligibility Rule و UX Scenario |
| چه کسانی به کسبوکار و حساب دسترسی دارند؟ | Business، Bank، Operations و Risk | Role/Permission Matrix |
| مالک، مدیرعامل، نماینده و امضادار چه اختیاری دارند؟ | Legal، Bank، Risk و Business | Authority Model و Approval Flow |
| آیا کارتابل لازم است؟ | Product بر اساس فرایند Business/Operations | Service Blueprint و Back-office Scope |
| مالکیت یا نمایندگی چگونه اثبات میشود؟ | Bank، Risk، Legal و Compliance | Verification Flow و Decision Table |
| در عدم تطابق چه اتفاقی میافتد؟ | Risk و Operations | Exception Flow و Manual Review |
| Login و Recovery چگونه است؟ | Security/Risk با همکاری Product و Business | Login، Recovery و Session UX |
| چه زمانی درخواست پذیرفته و قابل انتشار است؟ | Business Owner و تیمهای تخصصی | UAT و Release Criteria |
۱۰.۳ دوازده سند اختصاصی¶
| کد | سند | پرسش اصلی | حداقل محتوای لازم | خروجی تیم محصول | تأیید مشترک |
|---|---|---|---|---|---|
| S01 | ماتریس مشتری هدف و شرایط پذیرش | چه اشخاص و کسبوکارهایی مشتریاند؟ | حقیقی/حقوقی، نوع شخصیت، صنعت، اندازه، جغرافیا، شرایط ورود و رد | Segment، Persona و Journeyهای مجزا | Business، Bank و Risk |
| S02 | مدل رابطه شخص، کسبوکار و حساب | اشخاص چگونه به کسبوکار و حساب مرتبطاند؟ | چند کسبوکار برای یک شخص، چند حساب، مالک، نماینده، مدیرعامل، امضادار و پایان رابطه | Domain Model و ساختار Tenant/Organization | Business، Bank و Legal |
| S03 | ماتریس محصول و حساب بانکی | برای هر مشتری چه حسابی ایجاد یا متصل میشود؟ | نوع حساب، افتتاح/اتصال، فعالسازی، مسدودی، کارمزد، سقف، مدارک و قرارداد | Product Configuration و Journey افتتاح حساب | Business، Bank، Finance و Legal |
| S04 | قواعد مالکیت، نمایندگی و اختیار قانونی | چگونه سمت و اختیار فرد اثبات میشود؟ | سمت مجاز، منبع معتبر، مدرک، وکالت، تعارض و اطلاعات قدیمی | Verification Rule و مسیرهای تطبیق/عدم تطبیق | Bank، Legal، Risk و Business |
| S05 | ماتریس نقش و سطح دسترسی | هر نقش چه اقدامی میتواند انجام دهد؟ | مشاهده، ایجاد، تأیید، دعوت، حذف، تفکیک وظایف، تعلیق و خروج | Role/Permission Model و تجربه مدیریت کاربران | Business، Bank، Operations و Risk |
| S06 | Journey ثبتنام و مدل وضعیتها | درخواست از شروع تا فعالشدن چه مراحلی دارد؟ | مراحل، داده/مدرک، ذخیره موقت، وضعیتها، پیام و اقدام بعدی | Customer Journey، State Machine و UX Flow | Business، Operations و Risk |
| S07 | Decision Table احراز حقیقی و حقوقی | با هر نتیجه استعلام چه تصمیمی گرفته میشود؟ | پذیرش خودکار، رد، بررسی دستی، تطبیق، تکرار، انقضا و تغییر اطلاعات | Business Rule Engine و Acceptance Criteria قابلتست | Bank، Risk، Compliance و Legal |
| S08 | سناریوهای ورود و چرخه دسترسی | کاربر چگونه فعال، وارد، بازیابی، قفل یا خارج میشود؟ | فعالسازی، انتخاب کسبوکار، Recovery، تغییر شماره، Lock، Session و قطع همکاری | Login/Recovery Flow و نیازمندیهای نشست | Business، Security و Risk |
| S09 | قواعد امضا، تأیید و اقدام مشترک | چه اقدامی با تأیید چه ترکیبی معتبر است؟ | اقدام، تعداد/ترکیب تأییدکننده، سقف اختیار، ترتیب، مهلت، لغو و انقضا | Approval Workflow و مدل Maker/Checker | Bank، Legal، Risk و Business |
| S10 | فرایند عملیات، کارتابل و استثنا | چه مواردی نیازمند دخالت انسانی است؟ | صف، نقش اپراتور، Manual Review، مدرک تکمیلی، SLA، Escalation و Audit Trail | Service Blueprint و دامنه Back-office/کارتابل | Business، Operations، Risk و Bank |
| S11 | رجیستر منابع داده و وابستگیها | هر تصمیم از کدام داده یا سرویس تأمین میشود؟ | منبع رسمی، سرویس، مالک API، موعد Sandbox، مدرک آمادگی و Fallback | Integration Map، API Contract و برنامه وابستگیها | Sponsor، Bank و Technical Owner |
| S12 | UAT و پذیرش کسبوکار | چه چیزی آمادگی انتشار را اثبات میکند؟ | سناریوی موفق، خطا، Edge Case، نتیجه، Tester، شرط پذیرش و Sign-off | UAT Plan، Release Criteria و صورتجلسه Go/No-Go | Business Owner، Operations و تیمهای تخصصی |
۱۰.۴ ترتیب منطقی تصمیمها¶
flowchart LR
A["مشتری هدف<br/>S01"] --> B["رابطه شخص، کسبوکار و حساب<br/>S02"]
B --> C["نوع محصول و حساب<br/>S03"]
C --> D["مالکیت و نمایندگی<br/>S04"]
D --> E["نقش و دسترسی<br/>S05"]
E --> F["Journey و وضعیتها<br/>S06"]
F --> G["تصمیم KYC/KYB<br/>S07"]
G --> H["ورود و بازیابی<br/>S08"]
H --> I["امضا و تأیید<br/>S09"]
I --> J["کارتابل و استثنا<br/>S10"]
J --> K["منابع و APIها<br/>S11"]
K --> L["UAT و انتشار<br/>S12"]
۱۱. معیار نیاز به کارتابل یا Back-office¶
وجود یکی از شرایط زیر میتواند نیاز به ابزار عملیاتی یا کارتابل را ایجاد کند:
- بررسی دستی مدارک؛
- عدم تطابق داده فرد و کسبوکار؛
- تصمیم Risk/Compliance؛
- تأیید چندمرحلهای افتتاح حساب؛
- تبادل درخواست میان شرکت و بانک؛
- درخواست مدرک تکمیلی؛
- رد، تعلیق، بازگشایی یا Appeal؛
- مدیریت صف، SLA و Escalation؛
- الزام Audit Trail و ثبت دلیل تصمیم.
Business و Operations باید فرایند و استثنا را تعریف کنند. Product پس از تحلیل تصمیم میگیرد راهکار مناسب، کارتابل کامل، پنل ساده، اتصال به ابزار موجود یا اتوماسیون بدون UI است.
۱۲. اصل اعتبارسنجی مالکیت و نمایندگی¶
ادعای کاربر بهتنهایی برای اثبات مالکیت یا نمایندگی کافی نیست. «مالک»، «مدیرعامل»، «نماینده قانونی» و «امضادار مجاز» ممکن است افراد متفاوتی باشند.
قواعد باید مشخص کنند:
- چه سمتهایی اجازه آغاز درخواست دارند؛
- منبع معتبر هر داده چیست؛
- چه اطلاعاتی با هم تطبیق داده میشوند؛
- چه مدارکی قابل قبولاند؛
- نمایندگی و وکالت چگونه اثبات میشود؛
- در تعارض، فقدان یا قدیمیبودن داده چه میشود؛
- آیا تأیید فرد یا افراد دیگری لازم است؛
- مسیر Manual Review و مالک تصمیم نهایی چیست.
۱۳. مدیریت Prototype و فرضیات¶
Prototype میتواند پیش از آمادهشدن همه ورودیها برای کشف، تست جریان و کاهش ریسک طراحی ساخته شود؛ اما نباید بهعنوان محصول Production-Ready یا مبنای تعهد زمان معرفی شود.
هر Prototype مبتنی بر فرض باید این برچسب را داشته باشد:
این جریان بر اساس فرض اولیه طراحی شده و منوط به تأیید Business، Bank، Risk، Legal و سایر مالکان مرتبط است.
وضعیت هر جریان باید شفاف باشد:
| وضعیت | معنا |
|---|---|
| فرض اولیه | هنوز توسط مالک تصمیم تأیید نشده است |
| تأیید کسبوکار | هدف و رفتار کسبوکاری پذیرفته شده است |
| تأیید تخصصی | Risk/Legal/Security/Bank بخش مرتبط را پذیرفته است |
| آماده توسعه | Design، Rule، AC و Dependency آمادهاند |
| آماده انتشار | Test، UAT، Operations و Sign-off کاملاند |
۱۴. قالبهای حداقلی پیشنهادی¶
T01Business Rule
| Rule ID | Trigger | Condition | Outcome | Exception | Source | Owner | Version |
|---|---|---|---|---|---|---|---|
| BR-001 |
T02Decision Log
| Decision ID | موضوع | گزینهها | تصمیم | دلیل | تصمیمگیر | تاریخ | اثر |
|---|---|---|---|---|---|---|---|
| DEC-001 |
T03Dependency Register
| Dependency | نیاز | مالک | موعد | وضعیت | مدرک آمادگی | اثر تأخیر | Plan B |
|---|---|---|---|---|---|---|---|
T04Role and Permission Matrix
| نقش | مشاهده | ایجاد | ویرایش | تأیید | دعوت کاربر | مدیریت دسترسی | محدودیت |
|---|---|---|---|---|---|---|---|
T05UAT Scenario
| Scenario ID | پیششرط | مراحل | نتیجه مورد انتظار | نتیجه واقعی | وضعیت | Tester | Sign-off |
|---|---|---|---|---|---|---|---|
| UAT-001 |
۱۵. قواعد اجرایی همکاری¶
- هر Requirement باید Business Owner و Product Owner مشخص داشته باشد.
- نظر شفاهی تا زمان ثبت در سند یا Decision Log، تصمیم نهایی محسوب نمیشود.
- هر تغییر پس از Approval باید اثر زمانی، هزینهای و فنی آن مشخص شود.
- هر وابستگی باید Owner، Due Date و Evidence of Readiness داشته باشد.
- هیچ Rule حساس نباید توسط Product یا Engineering حدس زده شود.
- هر Requirement باید از Business Goal تا Release و KPI قابل ردیابی باشد.
- Demo برای دریافت بازخورد است و جایگزین Business Approval یا UAT نیست.
- نبود ورودی باید بهعنوان Blocker یا Assumption ثبت شود، نه اینکه پنهانی با حدس تیم پوشانده شود.
- تعهد زمانی توسعه پس از Ready for Development ارائه میشود.
- تصمیم Go/No-Go باید مشترک، ثبتشده و دارای مالک مشخص باشد.
۱۶. جمعبندی¶
مدل مطلوب همکاری چنین است:
- Business مسئله، مشتری، ارزش، قواعد، اولویت و پذیرش را مالک است؛
- Product کشف، صورتبندی، Scope، Journey، Design، PRD و Backlog را مالک است؛
- Engineering معماری، ساخت، کیفیت، Integration و عملیات فنی را مالک است؛
- تیمهای تخصصی الزامات و تأییدهای حوزه خود را ارائه میکنند؛
- تحویل محصول نتیجه همکاری و تصمیمگیری شفاف میان همه این نقشهاست.
معیار بلوغ فرایند، تعداد جلسات یا حجم مستندات نیست؛ معیار آن تصمیمهای روشن، مسئولیت قابلردیابی، ورودی قابلآزمون و خروجی قابلتحویل است.