متخصص تقني يبني ليفهم.

النسخة المختصرة

أنا مهند بكار، متخصص تقني مقيم في أونتاريو، كندا. يقع عملي بين متطلب الأعمال والنظام العامل: فهم ما يحتاجه العميل، وتحديد كيف تُشكّل البرمجيات والتكاملات، والبقاء مشاركًا حتى تعمل بشكل موثوق في الإنتاج.

قضيت معظم مسيرتي في برمجيات يعتمد عليها الناس دون أن يفكروا فيها كثيرًا — أنظمة الفوترة وخدمة العملاء في المرافق، والآن منصات الدفع والفوترة في Paymentus. يعلّمك هذا السياق نوعًا خاصًا من الصبر: يجب أن تكون البرمجيات صحيحة، والحالات الحدّية مالية أو تشغيلية، وللناس الذين يستخدمونها عمل يجب أن يُنجز.

ما يتضمنه العمل فعليًا

التنفيذ التقني يبدو وظيفة واحدة. عمليًا هو مجموعة وظائف أصغر، والأجزاء غير اللامعة هي التي تحدد عادةً نجاح التسليم:

• قراءة المتطلب وملاحظة ما يتركه غامضًا.
• تصميم كيفية انتقال البيانات بين أنظمة بُنيت بشكل منفصل.
• تهيئة تطبيق ليتوافق مع العملية الفعلية للعميل.
• التعامل مع المصادقة والوصول والهوية.
• اختبار المسارات التي لا يفكر فيها أحد حتى تفشل في الإنتاج.
• الإطلاق، ثم البقاء قريبًا حتى تستقر الأمور.

لا شيء من ذلك لامع. لكنه كله ما يجعل النظام قابلًا للاستخدام بعد أن يغادر فريق المشروع.

كيف وصلت إلى هنا

مرّ مساري المهني عبر برمجيات المرافق، ومؤخرًا عبر التكنولوجيا المالية. في Advanced Utility Systems عملت مستشارًا تقنيًا ثم قدت فريق الخدمات التقنية. وفي Paymentus أعمل على تنفيذ حلول الدفع والفوترة لعملاء مختلفين.

لم يكن المسار خطًا مستقيمًا في تخصص واحد. الثابت كان الأنظمة: فهم كيف تتصل الأجزاء، وأن تكون الشخص الذي يتتبع المشكلة من العرض إلى سببها.

لماذا أبني خارج العمل

للوظيفة حدود: عميل ونطاق وإصدار. المشاريع المستقلة تزيل هذه الحدود وتكشف كل ما تبقّى — قرارات المنتج والتصميم والنشر والدعم، وما إذا كان أحد يريد الشيء فعلًا.

Basket موجود لأن مشكلة منزلية تكررت. المختبر المنزلي موجود لأن القراءة عن الشبكات لا تكفي. ومشروع مزرعة الزيتون موجود لأن التقاء البرمجيات بالمياه والطاقة والمسافة نوع مختلف فعلًا من الهندسة.

هذه المشاريع أيضًا حيث أواصل التعلّم. معظم ما أعرفه عن الحاويات وDNS والنماذج المحلية جاء من كسر شيء في المنزل ومحاولة إصلاحه.

ما يهمني في الحل

يهمني كيف يتصرف النظام عندما يكون قليل الصيانة وقليل المراقبة ويستخدمه شخص لم يتدرب عليه. هذا هو الاختبار الحقيقي عادةً — لا العرض التوضيحي، ولا المسار السعيد.

الحل الذي يستطيع الفريق تشغيله وتشخيصه وتوسيعه يستحق عادةً أكثر من حل أنيق لا يستطيع أحد صيانته.

هذا الاعتقاد يشكّل طريقة تحديدي للنطاق وتوثيقي للقرارات واختياري بين تصميم ذكي وتصميم بسيط يصمد.