تغرينا الصفحة الفارغة بأن نبدأ بالأجزاء المألوفة: واجهة برمجية، وطابور رسائل، وقاعدة بيانات. لكن الرسم قد يبدو مقنعًا قبل أن نفهم المشكلة أصلًا.
البداية الأنفع هي سؤال بسيط: من يحتاج إلى فعل ماذا، وما الذي يعوقه؟
اسأل قبل أن ترسم
تخيّل مكتبة صغيرة تريد استقبال طلبات شراء الكتب عبر الإنترنت. عبارة «نحتاج إلى نظام للطلبات» تصلح كبداية، لكنها تترك أسئلة مهمّة بلا إجابة.
- هل يمكن أن يشتري عميلان آخر نسخة من الكتاب في اللحظة نفسها؟
- ماذا يحدث إذا نجح الدفع ولم يُحفظ الطلب؟
- هل يحتاج المتجر إلى تأكيد فوري، أم يمكنه الانتظار بضع ثوانٍ؟
تخبرنا كل إجابة بشيء عن شكل النظام. ولا يتطلّب أيّ من هذه الأسئلة اختيار إطار عمل.
ارسم أصغر مسار مفيد
يصف الرسم التالي مسارًا محتملًا للطلب. القرار واضح فيه: لا نؤكّد الطلب إلا بعد حجز نسخة من الكتاب.
تعذّر عرض الرسم. يمكنك قراءة مصدره أدناه.
مصدر الرسم
flowchart RL
accTitle: مسار طلب كتاب
accDescr: نفحص المخزون ثم نحجز نسخة ونؤكّد الطلب، أو نعرض عدم التوفّر.
A[إرسال الطلب] --> B{الكتاب متوفّر؟}
B -->|نعم| C[حجز نسخة]
C --> D[تأكيد الطلب]
B -->|لا| E[عرض عدم التوفّر]هذا الرسم غير مكتمل عن قصد. فالدفع، وإعادة المحاولة، والتوصيل تحتاج إلى نقاشات مستقلّة. والرسم الصغير يمنح هذه النقاشات نقطة بداية.
اكتب القرار بالكلمات
يمكن لسجلّ قصير أن يحتفظ بالسياق الذي لا يظهر في الرسم.
decision: Reserve stock before confirming an order
context: A book can have only one remaining copy
consequence: Reservations need an expiry policy
open_question: When should payment be captured?يقول هذا السجلّ: نحجز المخزون قبل تأكيد الطلب، لأن الكتاب قد لا تتبقّى منه سوى نسخة واحدة. ويترتّب على ذلك وضع سياسة لانتهاء الحجز. أمّا توقيت تحصيل الدفع فما زال سؤالًا مفتوحًا.
السؤال المفتوح مهمّ بقدر القرار نفسه. فهو يُظهر ما لم نحسمه بدلًا من إخفائه خلف رسم مرتّب.
اجعل الخطوة التالية صغيرة
اختر سيناريو واقعيًا، واتبعه من وجهة نظر العميل. ثم أضف حالة فشل: قاعدة بيانات غير متاحة، أو طلبًا مكرّرًا، أو عميلًا أغلق الصفحة.
الرسم المعماري المفيد يساعد شخصًا ما على طرح سؤال أفضل.
يمكن للمربّعات أن تنتظر. تأكّد أولًا من أن الجميع يحاول حلّ المشكلة نفسها.