كيف تتحقق من سابقة أعمال شركة التطوير ومراجعها؟
قائمة أعمال أنيقة لا تقول من صمم ومن برمج، ولا شيئًا عن لوحة التحكم خلف الواجهة. دليل تنفيذ للمشتريات وصاحب المشروع: خمس خطوات للتحقق من سابقة أعمال أي شركة تطوير، وكيف تقرأ التشابه والاختلاف مع مشروعك.
التحقق من سابقة أعمال شركة برمجة يجيب عن ثلاثة أسئلة، لا عن سؤال «هل التطبيقات جميلة؟»: هل بنت الشركة ما تعرضه فعلًا، وما دورها فيه بالضبط؟ هل يعمل الآن كما يُوصف؟ وهل يشبه مشروعك في منطقه (الأطراف، ولوحة التحكم، والتكاملات، والاستثناءات) لا في شكله؟ الطريق خمس خطوات: فرز القائمة قبل الاجتماع، وفحص ما هو منشور بنفسك، وعرض مباشر تطلب فيه ما لا يظهر في الصور، وأسئلة تقنية للمهندس الذي بنى المشروع، ومكالمة مرجع بأسئلة محددة. والأعمال المحمية باتفاقيات السرية تُعرض بحجب البيانات لا بالرفض الكامل.
كل شركة تطوير تعرض قائمة أعمال، وأغلب القوائم تبدو مقنعة: شعارات، وصور شاشات أنيقة، وروابط لتطبيقات في المتاجر. المشكلة أن القائمة وحدها لا تقول من صمم ومن برمج ومن ورث المشروع لاحقًا، ولا تقول شيئًا عن لوحة التحكم التي تدير كل شيء خلف الواجهة. وقد تكون الشركة بنت فعلًا ما تعرضه، لكنه لا يشبه مشروعك إلا في اللون. هذا دليل تنفيذ تطبقه على أي شركة مرشحة، خطوة بخطوة، مع ما تطلبه في كل خطوة وكيف تقرأ ما تراه.
ما الذي يثبته التحقق فعلًا؟ ثلاثة أسئلة لكل عمل معروض
قبل أن تبدأ، ثبّت ما تبحث عنه. كل عمل في القائمة يمر على ثلاثة أسئلة، والإجابة عن سؤال منها لا تغني عن الآخرين:
- من بناه، وبأي دور؟
- «عملنا على هذا التطبيق» قد تعني البناء الكامل، أو التصميم فقط، أو تطبيق الجوال دون الخادم، أو الصيانة بعد أن بناه غيرهم. كلها خبرة مشروعة، لكنها خبرات مختلفة. المهم أن يطابق الدور ما ستحتاجه منهم.
- هل يعمل الآن كما يُوصف؟
- تطبيق حُذف من المتجر، أو توقف تحديثه منذ مدة طويلة، أو يعمل بأجزاء معطلة؛ كلها معلومات عن المشروع وعن علاقة الشركة بعميلها، وليست بالضرورة حكمًا عليها. اسأل عنها بدل أن تستنتج.
- هل يشبه مشروعك في المنطق؟
- تطبيق توصيل وتطبيق صيانة منزلية يختلفان في الشكل ويتشابهان في المنطق: طلب، وتوزيع على منفذ، وتتبع، وإغلاق بدفع. أما تطبيقا متجرين متشابهين في الشكل فقد يختلفان كليًا إن كان أحدهما مربوطًا بنظام مخزون والآخر لا.
- فرز القائمةاختيار عملين يشبهان مشروعك في المنطقأنت، قبل الاجتماع
- الفحص العلنيصفحة المتجر والتحديثات والتجربة بنفسكأنت
- العرض المباشرلوحة التحكم والاستثناءات وبيئة العملالشركة أمامك
- الأسئلة التقنيةللمهندس الذي بنى المشروع لا لمن يعرضهمهندس الشركة
- مكالمة المرجعأسئلة عن المشكلات لا عن الرضاعميل سابق
الخطوة 1: فرز قائمة الأعمال قبل الاجتماع
لا تحاول التحقق من كل ما في القائمة. اختر عملين أو ثلاثة يشبهون مشروعك في المنطق، وأعلن اختيارك للشركة قبل الاجتماع حتى يحضر من يعرفهما. استخدم هذا الجدول لتحديد ما يعنيه «مشابه» لمشروعك:
| البعد | ما تسأل عنه في العمل المعروض | متى يُعد التشابه قويًا |
|---|---|---|
| الأطراف | كم طرفًا يستخدم النظام (عميل، ومقدم خدمة، ومشرف، وإدارة)؟ | العدد نفسه والعلاقة نفسها بينهم، حتى لو اختلف القطاع |
| لوحة التحكم | ماذا تفعل الإدارة يوميًا من اللوحة؟ | توزيع، وموافقات، وتقارير، وصلاحيات بعمق قريب من حاجتك |
| التكاملات | بأي أنظمة يرتبط؟ محاسبة، أو موارد بشرية، أو دفع، أو خدمات حكومية | ربط بنوع النظام نفسه، لا بالمنتج نفسه بالضرورة |
| المال | هل فيه دفع، واسترداد، وتسويات، وعمولات؟ | منطق مالي بالتعقيد نفسه، خاصة الاسترداد والتسوية |
| الاستخدام الميداني | هل يعمل دون اتصال؟ هل يعتمد على الموقع أو الكاميرا؟ | القيد نفسه على الجهاز والشبكة |
| الحجم والتشغيل | كم مستخدمًا تقريبًا؟ أين يُستضاف؟ من يشغله اليوم؟ | حجم قريب ومتطلبات استضافة وأمن مشابهة |
بعد الجدول، تعرف مسبقًا ما ستطلب رؤيته. إن كان مشروعك يعتمد على توزيع الطلبات على فنيين، فالعمل الذي يستحق وقتك هو الذي فيه توزيع، حتى لو كان في قطاع آخر.
الخطوة 2: افحص ما هو منشور بنفسك
التطبيقات المنشورة تعطيك معلومات مجانية قبل أي اجتماع. نزّل التطبيق، وجرّبه كمستخدم عادي، واقرأ صفحته في المتجر:
- هل يعمل؟ سجّل، وأكمل الرحلة الأساسية إن أمكن، ولاحظ السرعة والرسائل وسلامة العربية واتجاه الواجهة.
- تاريخ آخر تحديث وملاحظات الإصدارات: تحديثات منتظمة تعني أن المشروع حي. انقطاع طويل ليس حكمًا، لكنه سؤال: هل ما زالت الشركة تعمل عليه؟
- المراجعات: اقرأ الشكاوى المتكررة عن الأعطال لا عن الخدمة نفسها. «التطبيق يخرج عند الدفع» تخص البناء، و«التوصيل تأخر» تخص العميل.
- اسم الحساب الناشر: إن كان التطبيق منشورًا باسم العميل فهذا ما يجب أن يكون. وإن كانت تطبيقات عملاء مختلفين كلها منشورة بحساب الشركة، فاسأل: هل تحتفظ الشركة بتطبيقات عملائها في حسابها؟ لأنها قد تفعل الشيء نفسه بتطبيقك.
لاحظ حدود هذه الخطوة: غياب اسم الشركة عن صفحة المتجر لا يعني أنها لم تبنه، والتطبيق الجيد في المتجر لا يقول شيئًا عن جودة الكود أو لوحة التحكم. الخطوة تنتج أسئلة، لا أحكامًا.
الخطوة 3: العرض المباشر، واطلب فيه ما لا يظهر في الصور
العرض المباشر ليس أن تشاهد الشركة تتنقل في التطبيق. صور الشاشات تفعل ذلك. اطلب مسبقًا أن يتضمن العرض ما يلي، على نظام يعمل (بيئة اختبار أو إنتاج مع حجب البيانات):
- لوحة التحكم من الداخل: كيف يُوزَّع طلب، وكيف تُدار الصلاحيات، وأين يظهر سجل من غيّر ماذا. اللوحة هي الجزء الذي لا يظهر في المتجر، وغالبًا الأكبر جهدًا.
- حالة استثناء واحدة على الأقل: إلغاء بعد الدفع، أو استرداد جزئي، أو فشل ربط مع نظام آخر. اطلب أن يُريك كيف يتصرف النظام، لا أن يصفه.
- أثر العمل لا ناتجه فقط: لوحة مهام أو سجل إصدارات من المشروع، ولو مع حجب الأسماء. يظهر فيها إيقاع العمل وحجم الفريق وكيف أُديرت المشكلات.
- تقرير أو وثيقة من المشروع: خطة اختبار، أو تقرير أخطاء، أو وثيقة معمارية مختصرة بعد حذف ما يخص العميل.
ردة فعل الشركة على هذه الطلبات جزء من التقييم. الشركة التي بنت المشروع تستطيع أن تفتح اللوحة وتشرح الاستثناء دون تحضير طويل. والتي تكتفي بعرض تقديمي ثابت لكل طلب، ربما لا تملك ما تعرضه، أو لا تملك وصولًا إليه.
الخطوة 4: أسئلة تقنية للمهندس الذي بنى المشروع
أقوى دليل على أن الشركة بنت ما تعرضه أن يتحدث عنه مهندس عمل عليه، بتفاصيل لا يعرفها إلا من عاشها. لا تحتاج إلى خبرة تقنية لتطرح هذه الأسئلة؛ تحتاج فقط إلى أن تلاحظ هل الإجابة محددة أم عامة:
| السؤال | إجابة من بناه فعلًا | إجابة من يعرضه فقط |
|---|---|---|
| ما أصعب قرار تقني اتخذتموه في هذا المشروع؟ | قرار محدد بسببه وبديله المرفوض، مثل تأجيل العمل دون اتصال إلى إصدار لاحق ولماذا | «كل شيء كان تحت السيطرة» أو حديث عام عن التقنية المستخدمة |
| ما الذي تغير بعد الإطلاق؟ | أمثلة: ميزة أُعيد تصميمها بعد ملاحظات المستخدمين، أو اختناق في الأداء عولج | «التطبيق ناجح والعميل راضٍ» |
| كيف ربطتم النظام الآخر؟ | طريقة الربط، وما كان ناقصًا في توثيقه، وكيف عولجت حالات تعطله | «ربطناه عبر API» دون تفصيل |
| من كان في الفريق، وما دورك أنت؟ | أدوار وأعداد تقريبية، ودوره الشخصي بوضوح | «فريق متكامل من الخبراء» |
| ماذا ستفعل مختلفًا لو بنيته اليوم؟ | نقد ذاتي محدد في بنية أو أداة أو تقدير | «لا شيء، كان مثاليًا» |
السؤال الأخير كاشف بشكل خاص: المهندس الذي بنى نظامًا حقيقيًا يعرف أين أخطأ، ويقول ذلك دون حرج. وإن كان مشروعك بـ Flutter تحديدًا، فمقالة تقييم خبرة فريق Flutter قبل التعاقد تضيف اختبارًا عمليًا لهذا الجانب، والأسئلة العامة عن المنهجية والعقد في مقالة الأسئلة التي تطرحها على شركة البرمجة قبل التعاقد.
الخطوة 5: مكالمة المرجع بأسئلة محددة
الشركة تختار مراجعها، وستختار راضين. لذلك لا فائدة من سؤال «هل أنتم راضون؟». اسأل عن مواقف، وخاصة الصعبة منها، لأن طريقة تعامل الشركة مع المشكلة هي ما ستعيشه أنت. اطلب المرجع للمرشحين النهائيين فقط، ويفضل أن يكون من المشروع الذي تحققت منه في الخطوات السابقة.
- ما الذي تأخر أو لم يسر كما خُطط، وكيف أبلغتكم الشركة به؟
- هل تغير أحد من الفريق أثناء المشروع؟ وكيف أثّر ذلك؟
- كيف تعاملت الشركة مع طلب تغيير أثناء التنفيذ؟ هل كان التقدير واضحًا قبل التنفيذ؟
- هل كان لديكم وصول إلى المستودع ونسخ تجريبية أثناء العمل؟
- باسم من الحسابات والمستودع اليوم؟
- هل ما زلتم تعملون معهم؟ وإن لا، فلماذا توقفتم؟
- لو بدأتم المشروع اليوم، هل تختارونهم مرة أخرى؟ وما الذي ستشترطونه عليهم هذه المرة؟
انتبه إلى التردد أكثر من الكلمات. مرجع يتحدث بحماسة عن النتيجة ويتجنب سؤال التأخير يعطيك معلومة. ومرجع يقول «تأخروا في مرحلة الربط، لكنهم أخبرونا مبكرًا وعدّلوا الخطة» يعطيك معلومة أفضل من المديح.
الأعمال المحمية باتفاقيات السرية: كيف تُعرض دون أن تُكشف
كثير من أهم أعمال شركات التطوير لا يمكن ذكرها علنًا: أنظمة داخلية لمنشآت، ومنصات لجهات، وتطبيقات لموظفين لا تظهر في المتاجر. هذا طبيعي، وهو في صالحك أيضًا؛ فالشركة التي تحمي عملاءها ستحمي مشروعك. لكن السرية لا تعني «لا نستطيع أن نريك شيئًا». الطرق المقبولة لعرض عمل محمي:
- عرض مباشر مع حجب البيانات: النظام يعمل أمامك في اجتماع، والأسماء والأرقام محجوبة أو من بيئة اختبار ببيانات وهمية.
- وصف حالة بلا معرّفات: القطاع، والمشكلة، والأطراف، والتكاملات، والقرارات الصعبة، دون اسم العميل.
- مخطط معمارية عام: مكونات النظام وتدفق البيانات بين الأطراف، دون تفاصيل تكشف العميل.
- وثائق بعد حذف ما يخص العميل: نموذج تقرير أسبوعي أو خطة اختبار من المشروع نفسه.
- مرحلة أولى صغيرة: إن بقي الشك، مرحلة تحليل أو نموذج أولي مدفوع ترى فيها طريقة العمل على مشروعك أنت.
وانتبه للعكس أيضًا: شركة تعرض عليك بيانات حقيقية لعملاء آخرين، أو تذكر تفاصيل مشروع يفترض أنه سري، تخبرك بما ستفعله ببيانات مشروعك. الإفراط في العرض علامة لا تقل أهمية عن الرفض الكامل، وكلاهما من علامات التحذير في شركات تطوير التطبيقات.
ماذا تعني التشابهات والاختلافات مع مشروعك؟
بعد الخطوات الخمس، ستجد أن العمل المعروض يشبه مشروعك في جوانب ويختلف في أخرى. القراءة الصحيحة لا تسأل «كم يشبه؟» بل «فيم يشبه؟»:
أقوى دليل. الخبرة قابلة للنقل: الأطراف والاستثناءات والتكاملات نفسها في قطاع آخر.
دليل قوي، مع سؤال: هل سيُعاد استخدام مكونات جاهزة؟ ومن يملكها في مشروعك؟
مضلل. واجهة تشبه فكرتك لا تعني أن من بناها واجه مشكلاتك الحقيقية.
لا يثبت ولا ينفي. اعتمد على الأسئلة التقنية ومرحلة أولى صغيرة لتحكم.
إن كان التشابه قويًا لدرجة أن الشركة تعرض «منتجًا جاهزًا يُخصص لك»، فاسأل صراحة: ماذا أملك في النهاية؟ الكود كله، أم ترخيص استخدام لجزء منه؟ الفرق بين الحالتين وأثره على قدرتك على الانتقال مفصل في مقالة ملكية الكود المصدري للتطبيق.
أخطاء شائعة في التحقق من سابقة الأعمال
- الحكم بالتصميم: واجهة جميلة قد تكون من مصمم مستقل استعان به العميل، ولا تخبرك شيئًا عن الخادم واللوحة.
- التحقق من كل شيء بسطحية: عشرة أعمال تتصفحها في دقائق أقل فائدة من عمل واحد تفحصه بالخطوات الخمس.
- الاكتفاء بعدد الأعمال: مئة تطبيق بسيط لا تثبت القدرة على نظام بأربعة أطراف وتكاملين.
- سؤال المبيعات عن التفاصيل التقنية: ستحصل على إجابات عامة صادقة النية. اطلب من سيقود التقنية.
- مرجع بسؤال واحد عن الرضا: تحصل على «ممتاز» ولا تتعلم شيئًا.
- معاقبة السرية: استبعاد شركة لأنها لا تذكر عملاءها بالاسم، بدل أن تطلب منها طرق العرض البديلة.
- تجاهل الدور: تحتسب مشروعًا لم تبنه الشركة إلا جزئيًا كأنه خبرتها كاملة.
ما تطلبه من شركة التطوير، وما تجهزه قبل اجتماع التحقق
جهّز قبل الاجتماع
- وصفًا من صفحة لمنطق مشروعك: الأطراف، والرحلة الأساسية، ولوحة التحكم، والتكاملات، والاستثناءات التي تقلقك.
- العملين أو الثلاثة الذين اخترتهم من قائمة الشركة، وسبب اختيار كل منهم بحسب جدول أبعاد التشابه.
- ملاحظاتك من الفحص العلني: ما جربته، وما لاحظته في المراجعات والتحديثات.
- أسئلة الخطوة الرابعة مكتوبة، ومن سيحضر من فريقك ليلاحظ الإجابات.
- اتفاقية سرية جاهزة إن كان في مشروعك ما يستدعيها.
اطلب من الشركة
- حضور مهندس عمل على المشروع المعروض، لا مندوب المبيعات وحده.
- عرضًا مباشرًا يتضمن لوحة التحكم وحالة استثناء على نظام يعمل.
- أثرًا من طريقة العمل: لوحة مهام أو سجل إصدارات أو تقرير، بعد حجب ما يخص العميل.
- توضيحًا مكتوبًا لدورها في كل عمل: بناء كامل، أو جزء، أو صيانة.
- مرجعًا من المشروع نفسه للمرشحين النهائيين، مع إذن العميل.
- إجابة صريحة عن المكونات الجاهزة التي قد تُستخدم في مشروعك، ومن يملكها.
الخلاصة: تحقق من عمل واحد بعمق
قائمة الأعمال دعوة للسؤال، لا جواب عنه. اختر عملًا أو اثنين يشبهان مشروعك في المنطق، وجربهما بنفسك، واطلب رؤية اللوحة والاستثناء على نظام يعمل، واسأل من بناه عن قراراته وأخطائه، ثم اسأل مرجعًا عن المواقف الصعبة. بعدها تعرف ما هو أهم من «هل بنوه؟»: هل واجهوا مشكلات مشروعك، وكيف تعاملوا معها. وسجّل ما تجده في مصفوفة الاختيار كما في مقالة كيف تختار شركة تطوير تطبيقات.
وطبّق الخطوات نفسها علينا. صفحة أعمالنا تعرض نماذج المشاريع التي نبنيها، وأغلبها منظومات: تطبيق للعميل وآخر لمقدم الخدمة ولوحة إدارة وتكاملات. وكما تذكر صفحة من نحن، قائمة الأعمال والعملاء تُعرض في الاجتماع بما تسمح به اتفاقيات السرية، ومهندس يحضر كل حوار من الاجتماع الأول. وطريقة عملنا التي تسأل عنها المراجع موصوفة في منهجية العمل. احجز اجتماعًا تقنيًا، وأخبرنا مسبقًا بمنطق مشروعك، لنعرض عليك أعمالًا مشابهة وتطرح عليها أسئلتك.
أسئلة شائعة
اطلب عرضًا مباشرًا للوحة التحكم وحالة استثناء على نظام يعمل، واطرح على مهندس عمل عليه أسئلة عن أصعب قرار تقني وما تغير بعد الإطلاق. من بنى النظام يجيب بتفاصيل محددة وينتقد قراراته، ومن يعرضه فقط يجيب بعموميات.
لا، بل هو المتوقع حين يُنشر التطبيق بحساب العميل كما يجب. المقلق هو العكس: أن تكون تطبيقات عملاء مختلفين كلها منشورة بحساب الشركة، لأن ذلك قد يعني أنها تحتفظ بتطبيقات عملائها في حسابها.
اطلب طرق عرض بديلة: عرض مباشر مع حجب البيانات، أو وصف حالة بلا اسم العميل، أو مخطط معمارية عام، أو وثائق بعد حذف ما يخص العميل. وإن بقي الشك، مرحلة أولى صغيرة مدفوعة ترى فيها طريقة العمل على مشروعك.
اسأل عن مواقف لا عن الرضا: ما الذي تأخر وكيف أُبلغتم به، وهل تغير أحد من الفريق، وكيف عولجت طلبات التغيير، وباسم من الحسابات اليوم، وهل ما زلتم تعملون معهم، وما الذي ستشترطونه لو بدأتم من جديد.
ليس بالضرورة. الأهم أن تكون واجهت منطق مشروعك: عدد الأطراف، وعمق لوحة التحكم، ونوع التكاملات، والمنطق المالي، والعمل دون اتصال. تطبيق صيانة في قطاع آخر قد يكون خبرة أقرب لمشروعك من تطبيق في قطاعك بمنطق أبسط.
خدمات وصفحات مرتبطة
اقرأ أيضًا
اطلب أعمالًا تشبه مشروعك، واسأل من بناها
احجز اجتماعًا مع مهندس، وأخبرنا بمنطق مشروعك مسبقًا، لنعرض أعمالًا مشابهة بما تسمح به اتفاقيات السرية وتطرح عليها أسئلتك.