كيف انتقلت من الهاكاثونات إلى منصب المدير التقني لشركة SaaS خلال 3 سنوات

مقدمة: من تجارب الهاكاثون إلى قيادة شركة تقنية

في هذا المقال أشارك تجربة مهنية بدأت بحضور فعاليات Hackathon بدافع الفضول، وانتهت خلال ثلاث سنوات تقريباً إلى تولّي منصب المدير التقني CTO في شركة برمجيات كخدمة SaaS تضم أكثر من 20 موظفاً. هذه الرحلة لم تكن مستقيمة، بل امتلأت بالتجارب، والإخفاقات، والتحولات الاستراتيجية، والتعلّم السريع.

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

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

البداية الحقيقية: أول هاكاثون وخسارة مفيدة

قبل ثلاث سنوات من تلك المرحلة، لم تكن لدي رغبة واضحة في ريادة الأعمال أو عالم الشركات. كنت أقرب في التفكير إلى الباحث العلمي؛ مهتماً بأسئلة معقدة على حدود العلم، من الذاكرة على المستوى الجزيئي، إلى تحسين تعلم بعض المرضى، وحتى التنبؤ باستعادة الوعي بعد إصابات الدماغ.

لكن في المقابل، كان لدي شغف عميق بالبرمجة وبناء أشياء جديدة. كنت أستمتع بابتكار أدوات غير موجودة أصلاً. من هذه المشاريع مثلاً بناء واجهة دماغ-حاسوب متوافقة مع تجهيزات تحفيز الدماغ وقياس الإشارات العصبية.

انطلقت أول تجربة لي في Hackathon عندما أراد أخي لفت انتباه مسؤولي التوظيف للحصول على وظيفة كمطور برمجيات. اعتقدنا أن المشاركة في هذه الفعاليات قد تمنحه فرصة جيدة. تشكل الفريق من أربعة أشخاص، وعملنا ليومين متواصلين على خوارزمية لمطابقة الأشخاص مع الوظائف بحسب خصائص محددة.

وصلنا إلى قائمة المتأهلين النهائيين، ثم أنهينا المنافسة في المركز الرابع. لم نفز، لكن الخسارة نفسها كانت درساً ثميناً.

ماذا تعلمت من أول هاكاثون؟

• التنفيذ وحده لا يكفي؛ العرض التقديمي قد يكون أكثر تأثيراً من جودة الخوارزمية نفسها.
• في المسابقات السريعة، القيمة التي يفهمها الحكام أهم من التعقيد التقني الذي لا يراه أحد.
• ليس كل جهد تقني يؤدي تلقائياً إلى نتيجة عملية مثل التوظيف أو التمويل.

الهاكاثون الثاني: فوز خاص بفضل الاستراتيجية

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

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

اعتمد المشروع على نماذج تعلم آلي وبيانات متاحة من مصادر حكومية، وكانت الفكرة ببساطة تقديم تنبؤات تساعد المدن والمستخدمين على تجنب المناطق المتأثرة بتصريف المياه الملوثة.

انتهت المنافسة بفوزنا بجائزة قدرها $1000، وكانت في ذلك الوقت إنجازاً كبيراً بالنسبة لنا.

أبرز دروس الهاكاثون الثاني

• اختيار المشكلة بذكاء قد يمنحك أفضلية أكبر من تعقيد الحل.
• العرض المقنع ليس عنصراً ثانوياً؛ بل جزء أساسي من النجاح.
• المنافسة الأقل جاذبية للآخرين قد تخفي فرصاً ممتازة للتميّز.

الهاكاثون الثالث: مشروع يقترب من الشركة

لم تكن الجائزة المالية هي النهاية، بل منحتنا تأهلاً سريعاً إلى نصف نهائي مسابقة أكبر، بجائزة تصل إلى $25,000. عندها بدأ التفكير يتغير: هل نقتسم المكافأة، أم نحاول تحويل المشروع إلى شيء أكبر؟

قررنا المضي قدماً. غيّرنا اسم الفريق إلى EGC Labs، وأنشأنا موقعاً للترويج للحل، وتمكنا من الوصول إلى المرحلة النهائية. كما حصلنا على دعم مالي إضافي للمساعدة في التأسيس والسفر.

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

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

في النهاية حصلنا مجدداً على المركز الرابع، ولكن من دون عائد مالي حقيقي.

الدروس الأهم من التجربة الثالثة

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

التحول الفعلي: دخول الحاضنة وتعلّم ريادة الأعمال

الوصول إلى نهائيات تلك المسابقة منحنا فرصة دخول حاضنة أعمال في مقاطعة كيبيك، وهي Centech. لم أكن أفهم وقتها معنى الحاضنة سوى بالمعنى الحرفي للكلمة، لذا لم أبدُ متحمساً كثيراً في البداية.

مع الوقت تغيّر الأمر تماماً. بدأت أحضر الدروس، وأنفذ الواجبات، وأتعامل مع المشروع بجدية أكبر. كانت التجربة ثرية للغاية، لأنها جمعت بين الإرشاد العملي، والاحتكاك برواد أعمال حقيقيين، والتجريب المستمر.

في تلك المرحلة أدركت خطأً شائعاً يقع فيه المؤسسون التقنيون: لقد بنينا التقنية أولاً، قبل أن نتحقق من وجود نموذج عمل قابل للاستمرار. وهذا قادنا إلى أول Pivot حقيقي.

التحول الأول: من التنبؤ بالفيضانات إلى تنظيف البيانات

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

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

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

وهنا كانت النتيجة واضحة: لسنا شغوفين بتنظيف البيانات بحد ذاته، بل نهتم بأتمتة العمل وصنع أدوات ترفع الكفاءة. لذا كان لا بد من تحول ثانٍ، وأكثر جذرية.

التحول الثاني: الاندماج مع فريق آخر وبداية شركة قابلة للنمو

خلال برنامج Centech تعرّفنا إلى مؤسسين آخرين لديهم مشكلة سوقية واضحة واهتمام من العملاء المحتملين، لكنهم يفتقرون إلى القدرات التقنية اللازمة لبناء المنتج. ومع تبادل المساعدة بيننا، اتضح أن دمج الجهود قد يكون أكثر فعالية من استمرار كل فريق بمفرده.

بعد عدة نقاشات، قررنا إيقاف مشروع EGC Labs نهائياً والانضمام إلى فكرتهم التي كانت تحمل اسم GRAD4. كان هذا القرار صعباً نفسياً، لكنه من أكثر القرارات صحة في تلك الرحلة.

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

كما حققنا مكاسب إضافية، منها الفوز بجائزة عرض سريع Elevator Pitch، ثم الفوز في نهاية البرنامج بجائزة Unicorn وقيمتها $15,000. والأهم أننا حصلنا على مكان في برنامج متقدم داخل الحاضنة، مع مكتب وموارد إضافية.

ما الذي أثبته هذا التحول؟

• التخلي عن فكرة ضعيفة ليس فشلاً، بل نضج في اتخاذ القرار.
• الفريق المؤسس الأكبر قد يسرّع التنفيذ ويوزّع المهام بكفاءة أعلى.
• أفضل تحقق من السوق هو أن يدفع العميل قبل بناء المنتج الكامل.
• التقنية مهمة، لكنها ليست نقطة البداية دائماً.

من الفكرة إلى المنتج: كيف بنينا النسخة الأولى؟

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

في صيف 2019 قمنا بأول توظيفين رسميين، وهما متدربان في هندسة البرمجيات. كان أحدهما يركز على Backend والآخر على Frontend. أما المنتج فكان تطبيقاً بسيطاً من نوع CRUD يربط بين المشترين والمصنّعين في قطاع القطع المعدنية، عبر طلبات تسعير وعروض أسعار.

التقنيات التي اخترناها في البداية

• Django وDjango REST API للواجهة الخلفية.
• React وRedux للواجهة الأمامية.
• Bootstrap للتنسيق.
• Heroku للاستضافة.
• GitHub لإدارة الشيفرة المصدرية.

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

أهم درس تقني في البداية

المبالغة في التفكير في القابلية للتوسع Scalability مبكراً غالباً مضيعة للوقت. الأهم هو أن تبني بسرعة بما تعرفه جيداً، ثم تتعلم من السوق ومن المستخدمين بأقصى سرعة ممكنة.

إطلاق النسخة التجريبية المغلقة: أول احتكاك حقيقي بالمستخدمين

في نهاية صيف 2019 أطلقنا النسخة الأولى للمستخدمين الذين دفعوا مسبقاً. تأخرنا شهراً عن الموعد الموعود، ولم تكن المنصة جميلة أو مستقرة، بل كان جزء من العمل يُنفّذ يدوياً من طرفنا، خصوصاً ما يخص المشترين.

لكن الإيجابي أننا واصلنا تلقي اهتمام من عملاء جدد، واستمر تدفق بعض الشيكات، ما منحنا وقتاً إضافياً للتطوير.

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

دروس الإطلاق الأول

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

فتح النسخة التجريبية وتطوير البنية التقنية

بعد تحسين المنصة بناءً على ملاحظات المستخدمين الأوائل، بدأنا توسيع قاعدة المستخدمين. ومع زيادة النشاط بدأت تظهر مشاكل توقف الخدمة Downtime وحدود البنية القديمة.

لذلك استعنا بمهندس برمجيات خبير ساعدنا في إعادة تنظيم طريقة العمل، وكانت التغييرات الأساسية كالتالي:

• الانتقال إلى AWS لمزيد من التحكم في البيئة السحابية.
• الانتقال إلى GitLab لتسهيل خطوط CI/CD.
• إضافة اختبارات آلية.
• التحول تدريجياً من Bootstrap إلى Material-UI.

أصبحت عمليات النشر أكثر موثوقية، وتراجع التوقف بشكل ملحوظ، وارتفعت ثقة الفريق في التعديلات البرمجية.

الدروس التقنية من هذه المرحلة

• مرحلة MVP ضرورية، لكن لا يجب البقاء فيها طويلاً.
• عندما تبدأ التعقيدات الفعلية، فإن طلب المساعدة من خبير قرار ذكي لا ضعف.
• الاختبارات الآلية وCI/CD ليست رفاهية عندما يبدأ المنتج في التوسع.

الحصول على أول استثمار حقيقي

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

خضنا عرضاً استمر نحو 25 دقيقة أمام لجنة طرحت أسئلة قوية حول العمل والتقنية. وفي النهاية حصلنا على التمويل.

المكسب هنا لم يكن المال وحده، بل العلاقات والخبرة والدعم الاستراتيجي.

الدرس الاستثماري الأهم

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

إعادة التنظيم مع العمل عن بُعد خلال الجائحة

قبل الجائحة كانت وتيرة العمل شاقة، مع اعتماد كبير على الحضور المكتبي والاجتماعات المتزامنة. وعندما ظهر COVID-19 اضطررنا إلى التحول السريع نحو العمل عن بُعد.

اتضح لنا أن كثيراً من مشاكلنا التنظيمية كانت مخفية بسبب وجود الجميع في المكتب. ظهرت فجأة مشكلات التوثيق، وتكرار الأسئلة، والعشوائية في الاجتماعات.

استفدنا من أدلة العمل عن بُعد، وخاصة أساليب GitLab، وطبقنا مجموعة تغييرات:

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

ما كشفه العمل عن بُعد

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

إطلاق النسخة المحسّنة من المنتج

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

ساعدت الواجهة الأفضل على رفع المبيعات، وبدأنا العمل بجدية على تقليل الدين التقني Technical Debt، وتحسين البنية الداخلية، وتوسيع فرق UI/UX، وخدمة العملاء، والتسويق.

كما طبقنا نظامين مهمين في الإدارة:

• OKR للتركيز على الأهداف والنتائج الرئيسية.
• نظام EOS المستلهم من كتاب Traction لضبط الرؤية والمواءمة والتنفيذ.

الدروس القيادية في هذه المرحلة

• دور المؤسس مع الوقت يجب أن يتحول إلى Elevate and Delegate، أي الارتقاء بالمستوى وتفويض التنفيذ.
• العمل 80 ساعة أسبوعياً عبر ثلاث وظائف مختلفة ليس بطولة، بل خلل هيكلي.
• التوظيف الجزئي أو التطوعي غالباً يبطئ التقدم في الشركات الناشئة سريعة الإيقاع.

برامج التسريع: التمويل، الذكاء الاصطناعي، وبناء السمعة

بعد الحاضنة دخلنا برامج تسريع مثل NEXT AI وEcoFuel. الفرق بين الحاضنة والمسرّعة واضح: الحاضنة تساعدك على الانطلاق، أما المسرّعة فتمنحك أدوات تدفع النمو إلى الأمام بسرعة.

من خلال هذين البرنامجين حصلنا على تمويل إجمالي بلغ $100,000. كما بدأنا تأسيس جانب بحثي أكثر عمقاً داخل الشركة، يهتم بتطوير نماذج الذكاء الاصطناعي وتحليل البيانات، بمشاركة طلاب دراسات عليا وباحثين.

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

الدرس الحاسم هنا

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

الوضع الحالي للشركة: من شركة ناشئة إلى مؤسسة أكثر نضجاً

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

أصبح لدينا قناعات تشغيلية واضحة، من أبرزها:

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

الفكرة الجوهرية كانت بسيطة: بناء شركة كنا نحن أنفسنا نحب أن نعمل فيها.

نصائح عملية لرواد أعمال SaaS

أولاً: نصائح تتعلق بالمنتج

• المنتج أقل أهمية مما تتوقع؛ القيمة التي يحصل عليها العميل هي الأهم.
• تحقق من الحاجة قبل أن تنشغل ببناء الحل.
• اختيار الحزمة التقنية Tech Stack أقل أهمية من القدرة على التنفيذ بها.
• ابدأ ببنية بسيطة، وغالباً يكفيك Monolith في المراحل الأولى.
• ضع أقل عدد ممكن من الميزات لتحقيق أكبر قيمة ممكنة.
• تحدث إلى العملاء باستمرار؛ فهم مصدر الميزة التنافسية الحقيقية.
• عندما يكبر المنتج، تصبح أدوات CI/CD والاختبارات والمراقبة ضرورة لا رفاهية.
• لا تستعن بمصادر خارجية Outsource في جوهر كفاءتك الأساسية.

ثانياً: نصائح تخص الذكاء الاصطناعي

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

ثالثاً: نصائح في بناء الشركة

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

رابعاً: نصائح في التوظيف وبناء الفرق

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

خامساً: نصائح شخصية للمؤسسين

• احمِ العلاقة بين المؤسسين من التآكل بسبب الضغط والإرهاق.
• تذكّر دائماً أن بناء الشركة ماراثون لا سباق قصير.
• اترك مساحة لنموك الشخصي بعيداً عن العمل اليومي.
• خصّص وقتاً حقيقياً للراحة والانفصال عن ضغط الشركة.
• استمتع بالرحلة نفسها، بما فيها المشاكل والأخطاء، لأنها جزء من البناء.

كتب أوصي بها لكل مؤسس تقني

• The Lean Startup
• Traction
• Measure What Matters
• Peopleware
• Drive
• Effective DevOps
• The Phoenix Project
• Designing Data-Intensive Applications
• Forge Your Future with Open Source
• Principles
• Delivering Happiness

هذه الكتب مفيدة لأنها تغطي ثلاث دوائر مترابطة: بناء المنتج، وبناء الفريق، وبناء النظام التشغيلي الذي يسمح للشركة بالاستمرار والنمو.

الخلاصة التقنية

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