القاعدة الحاكمة
لا تطلب أن يُوصف لك شيء — اطلب أن يُشغَّل أمامك. الفرق بين «نعم النظام يدعم ذلك» و«تفضل، هذا هو يعمل» هو الفرق بين وعد وتكلفة تطوير لم تُذكر لك بعد.
لماذا العرض التوضيحي مضلل بطبيعته؟
ليس لسوء نية غالباً — بل لأن العرض مصمَّم لغرض مختلف عن غرضك:
| ما يريده المزوّد | ما تريده أنت |
|---|---|
| عرض أقوى المزايا في وقت محدود | معرفة ما ينقص وما يكلّف |
| بيانات نموذجية مثالية ومرتبة | سلوك النظام مع فوضى بياناتك الحقيقية |
| مسار عرض مُعَدّ ومجرَّب | مسار عملك أنت بتفاصيله |
| ترك انطباع إيجابي عام | إجابات محددة قابلة للمقارنة |
النتيجة أن ثلاثة عروض ممتازة تترك ثلاثة انطباعات جيدة — ولا تعطيك أساساً للاختيار بينها.
ما تجهّزه قبل الجلسة
نصف قيمة العرض تتحدد قبل بدايته. خمس دقائق من التحضير تغيّر الجلسة كلها:
- مشروع حقيقي من مكتبك — اسمه ومراحله وقيمته، لتطلب عرضه على النظام
- أكثر مشكلة تشغيلية تؤلمك — لتقيس هل يحلها فعلاً
- قائمة السيناريوهات الستة أدناه مطبوعة أمامك
- من يحضر من فريقك — مهندس ومحاسب على الأقل، لا المدير وحده
- سؤال الاعتراض الداخلي — ما الذي سيقوله فريقك رفضاً؟ اطرحه في الجلسة
لماذا يحضر فريقك؟
لأن المدير يقيّم القرار والفريق يقيّم الاستخدام. نظام يُعجب المدير ويرفضه الفريق لا يُطبَّق. ووجود مهندس ومحاسب في الجلسة يكشف في ساعة ما يظهر بعد شهرين من التطبيق.
ستة سيناريوهات اطلب رؤيتها تعمل
هذه ليست أسئلة عن مزايا — بل مهام محددة اطلب تنفيذها أمامك:
حدّث إصدار مخطط وامنع القديم
اطلب رفع إصدار جديد لمخطط، ثم اطلب أن يحاول شخص فتح الإصدار السابق. المطلوب أن يرى المعتمد فقط، وأن يظهر سجل من اعتمد ومتى.
سجّل تقرير عدم مطابقة وأغلقه
من التسجيل الميداني بصورة وموقع، إلى إسناده للمقاول، إلى توثيق المعالجة، إلى التحقق والإغلاق. اطلب الدورة كاملة لا شاشة التسجيل فقط.
ولّد مستخلصاً من مرحلة منجزة
اطلب اعتماد مرحلة في مشروع، ثم اطلب المستخلص المستحق عليها. المطلوب أن يظهر تلقائياً بنسبته، لا أن يُدخَل يدوياً.
سجّل زيارة ميدانية دون اتصال
اطلب إطفاء الاتصال عن الجهاز، ثم تسجيل زيارة بصور وملاحظات، ثم إعادة الاتصال والمزامنة. هذا يحسم أهم شرط تقني لمكاتب الإشراف.
اعرض ربحية مشروع منتهٍ
اطلب رقم ربحية مشروع مكتمل — كيف حُسب، ومن أي بيانات. المطلوب أن يظهر من الساعات والتكاليف والفوترة المرتبطة، لا من إدخال يدوي.
أضف مستخدماً وحدد صلاحياته
اطلب إنشاء حساب لمهندس ومنعه من رؤية البيانات المالية. هذا يكشف عمق نظام الصلاحيات في دقيقتين.
السيناريو الذي يكشف أكثر
الرابع — العمل دون اتصال. كثير من الأنظمة تعرض «تطبيق جوال» ثم يتضح أنه واجهة ويب مصغّرة. في موقع تنفيذ حقيقي لا اتصال، والتطبيق الذي لا يعمل دون شبكة لا يُستخدم — فيعود المشرف إلى الورقة والمحادثات.
السؤال الذي يلي كل سيناريو
بعد أن يُنفَّذ السيناريو أمامك، اطرح ثلاثة أسئلة ثابتة — وسجّل الإجابات كتابةً:
| السؤال | لماذا يهم |
|---|---|
| هل هذا جاهز في المنتج أم يحتاج تطويراً؟ | يفصل الميزة عن الوعد — والوعد له تكلفة |
| هل يعمل هكذا افتراضياً أم بعد تهيئة؟ | التهيئة العميقة ترفع رسوم التطبيق |
| من يصونه بعد سنتين إن كان تطويراً مخصصاً؟ | يكشف مخاطرة الاعتماد على شريك تنفيذ |
ثلاث إجابات مكتوبة عن ستة سيناريوهات تعطيك ثمانية عشر معلومة قابلة للمقارنة بين المزودين — بدل انطباع عام لا يُقارَن.
احجز جلسة واختبرها بهذه القائمة
نرحّب بأن تأتي بقائمتك ومشروعك الحقيقي. الجلسة 45 دقيقة، مجانية، ولا تلزمك بشيء — والهدف أن تخرج بإجابات لا بانطباع.
احجز عرضاً توضيحياًخمس علامات إنذار أثناء العرض
- رفض العرض على بياناتك — الإصرار على البيانات النموذجية فقط يخفي شيئاً
- «هذا يمكن تطويره» متكررة — كل واحدة بند تكلفة غير مذكور
- تجاوز سؤال بلا إجابة — الانتقال لشاشة أخرى بدل الإجابة
- عرض شرائح بدل النظام — الشرائح تصف، والنظام يُثبت
- ضغط زمني على القرار — «العرض ينتهي هذا الأسبوع» ليس معياراً تقنياً
كيف تقارن عروضاً متعددة؟
أنشئ جدولاً بسيطاً: ستة أسطر للسيناريوهات، وعمود لكل مزوّد، وفي كل خانة ثلاث كلمات — «جاهز» أو «يحتاج تطويراً» أو «غير متاح». هذا الجدول وحده يحسم أكثر مما تحسمه ساعات النقاش.
قاعدة الترجيح
صنّف السيناريوهات الستة إلى حرِج ومهم ومرغوب قبل العروض لا بعدها. ثم أسقط أي نظام يفشل في بند حرِج مهما تفوّق في غيره — فالبند الحرِج الواحد كافٍ لإفشال التطبيق كله.