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