كيف صممت وأطلقت مشروع SaaS (البرمجيات كخدمة) من الصفر وحصولي على أول 10 عملاء

السلام عليكم ورحمة الله، وصلى الله وسلم على سيدنا محمد وعلى آله وصحبه أجمعين.

حياكم الله إخوتي الكرام،

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

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

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

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

لهذا السبب، قرّرت العمل بطريقة واضحة وشفافة تماماً ومشاركة كل ما واجهني خلال تجربتي -بما في ذلك ما نجحت وفشلت فيه- بهدف مساعدة بعضنا البعض من خلال المناقشة. يمكنك متابعة تقدّمي للمشروع من صفحتي على IndieHacker.

المقال مقسّم إلى سبعة أقسام مرتّبة زمنياً حسب كل مرحلة من مراحل العمل التي قمت بها:

• صيد المشكلة.
• تحديد حجم المشكلة.
• تقييم المنافسين وطريقة معالجتهم للمشكلة.
• تطوير النموذج الأولي (Prototype).
• إلغاء كل شيء والبدء من جديد.
• الحصول على أول زبون.
• كيف تمضي قدماً نحو هدفك.

المشروع الذي أنشأته هو Inspector، يقدم خدمة المراقبة لمساعدة مطوري البرمجيات وتجنّب خسارة العملاء والمال بسبب الأعطال الفنية في تطبيقاتهم.

صيد المشكلة

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

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

ولكن لو أنكرت الواقع، قد تزعج عملاءك كثيراً لدرجة أنهم قد يعيدون النظر فيما إذا كنت هل "تستحق" أن يدفعوا لك؟

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

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

"إذا اتصل بك عميل غاضب أو منزعج، فبرنامجك لا يعمل .."

لكنها ليست حلاً تقنياً ..

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

ساعدني العمل بهذا النهج لمدة عشر سنوات على أنّ هناك مشكلة واضحة!

تحديد حجم المشكلة

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

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

من ناحية أخرى، لم أكن بحاجة إلى أداة لمراقبة كل شيء، لأن كل شيء لا يعني شيء! ولم أرغب في أن يكون الأمر معقّداً- لا أريد أن أقضي شهراً في تعلّم كيفية عمله ولا تعيين مطورين آخرين خبراء لهذه الوظيفة.

كان لابد من جعل وظيفتي أسهل مما كنت عليه، وتكون لدي أداة مطوّرة وجاهزة للعمل.

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

يا حبيبي! هذه نتائج كثيرة جداً كلها تحاول حل هذه المشكلة الضخمة فعلاً! لكن ما حجمها بالضبط؟

ان عدم كفاءة فريق التطوير، مشكلة كنت أواجهها بشكل مباشر، لكن هناك فرق كبير بين تقدير مُهِمَّة العمل وتحديد الأثر الاقتصادي لمشكلة ما. بل هو أكثر صعوبة على نطاق واسع.

استحوذت هذه التغريدة على انتباهي:

صرّح 50% من المطورين أن الأمر يستغرق 50% من وقتهم فقط للتحقق باستمرار من أن التطبيق يعمل بشكل سليم.

يتم دفع تكاليف تطوير البرمجيات بشكل أساسي من خلال الوقت الذي يقضيه المهندسون في العمل على المشروع، وإذا أمضى المطوّر في فترات معيّنة 50% من جهدهم فإن الأداة تقوم بعمل أتمتة لهذا العمل بالكامل وقد تكون كافية لشرائها.

فلماذا ليست شائعة بين المطوّرين؟

تقييم المنافسين وطريقة معالجتهم للمشكلة

فكرت في المعايير الأساسية التي يجب على الشركة مراعاتها عند تحديد الأدوات التي يجب استخدامها لزيادة الإنتاجية:

• البساطة (سهولة التركيب والاستخدام).
• الفاعلية (أقضي س ساعة في مشكلة تساوي س+10 لكشف وحل المشكلة. لذلك أحصل على +10).

باستخدام هذين المعيارين، قضيت حوالي أسبوع في إنشاء ورقة تقييم لأكثر الأدوات شهرة ووضعتها في رسم بياني:

بعد أيام من تجميع المعلومات، كان الرسم كافياً لإدراك مكان المشكلة.

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

بنظري، المشكلة ليست في المراقبة ذاتها ولكن في كفاءة فريق التطوير.

لذلك لأجل تبني نطاق واسع من الفِرق، من الضروري توفير منتج يتطلب دقيقة تثبيت واحدة دون أي تكوين مسبق، ويحتاج أيضا إلى توفير معلومات كاملة وسهلة للرجوع إليها، حتى يمكن لفريق التطوير متوسط الحجم حل المشكلة ومراقبة تطبيقاتهم في الوقت الفعلي (real-time).

وبالطبع يجب أن يكون رائعاً.

تطوير النموذج الأولي (Prototype)

أخيراً قررت المحاولة، سارت تجربة العمل بشكل جيّد، وأظن بداخلي من المستحيل بالنسبة لي إنشاء هذه الأداة.

لذلك أبلغت أصدقائي على الفور أنني أرغب في بناء MVP خلال الشهرين إلى ثلاث أشهر القادمة، عندما أشرح لهم يصعب عليهم فهم المشكلة لأنهم ليسوا المبرمجين الذين أعمل معهم لكنهم منحوني إحساساً بالثقة لـ 90% وأنا ممتن لهم بذلك.

بعد ثلاث أشهر تمكّنت من إنشاء هذا النموذج الأولي:

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

من وجهة نظر تقنية، يجب تصميم منتجات المراقبة (monitoring) للتعامل مع كميات كبيرة من البيانات، وأود معالجة هذا البيانات في الوقت الفعلي (real-time).

بالنسبة لجزء backend (بعبارة أخرى الجزء غير المرئي أو in-cloud software) كان علي قضاء وقت أطول من المتوقّع -مع ترك الواجهة الأمامية (كما ترون أعلاه)- وهي الجزء الذي يراه المستخدمون ويتفاعلون معه.

إلغاء كل شئ والبدء من جديد

في السنوات القليلة الماضية، دفعني حلم إطلاق منتج في السوق إلى مواصلة البحث وتطبيق استراتيجات التسويق المطبّقة على مشاريع SaaS بشكل خاص (حتى المشاريع الفاشلة).

بدأت في كتابة مقالات على مدونتي بهدف نشرها على المواقع المختلفة ووسائل التواصل الاجتماعي لجمع الملاحظات الأولى (feedback).

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

• لا يمكنني فهم ما أفعل به ..
• كيف يمكنني تثبيته؟
• لماذا نستخدمه بدلا من منتج س؟
• ما الذي يقدّمه لأستخدمه عن أي منتج آخر؟
• ...إلى آخره.

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

الدرس الأول: البيع بشكل سيء

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

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

استعنت بروبن -كاتب محتوى على fiverr- قام بتصحيح الأخطاء اللغوية والإملائية بما في ذلك محتوى الموقع تحسين جودة كتابة اللغة الإنجليزية لمستوى (native).

الدرس الثاني: منتج غير كافٍ

الخوف من سوء واجهة المستخدم هو خوف له ما يُبَرِّرهُ، ما فعلته لم يكن كافياً لخلق تجربة مستخدم جيّدة، لذلك كان عليّ أن أبدأ من جديد.

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

من أجل تحسين وعيي بالتصميم أخذت دورتين دراسيتين حول تصميم الواجهات وقراءة 3 كتب تصميم وتجربة المستخدم UX وإجراء تجارب مباشرة باستخدام Vuejs كإطار للواجهة الأمامية.

الدرس الثالث: جرّب رغم الشكوك

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

على سبيل المثال يُقال: إذا انتظرت حتى يصبح كل شيء جاهز فلن تبدأ عملك - هذه حقيقة!

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

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

ولادة Inspector

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

Inspector - اكتشف الأعطال الفنية في تطبيقك قبل أن يراها مستخدموك في أقل من دقيقة.

الغرض من أداتنا ليست المراقبة بحدّ ذاتها، ولكن مساعدة المطورين على أتمتة سير العمل الخاص بهم:

• دون جهد.
• لا حاجة لإضاعة الوقت في الاختبار اليدوي.
• تأكد من سير العمل عند الضرورة.

الحصول على أول زبون

في 14 يوليو 2019، وافق موقع Laravel News نشر إحدى إرشاداتي التقنية، فوصلت مقالتي إلى جمهور واسع جداً.

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

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

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

• https://medium.com/inspector
• https://dev.to/inspector
• https://valerio.hashnode.dev/
• https://www.facebook.com/inspector.realtime
• https://www.linkedin.com/company/14054676
• https://www.indiehackers.com/product/inspector
• https://www.reddit.com/r/InspectorFans/
• https://www.producthunt.com/posts/inspector

الآن جرّبت أكثر من 800 شركة ورجال أعمال منتجي ولدينا الآن أكثر من 20 اشتراكاً نشطاً.

كيف تمضي قدما نحو هدفك

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

لهذا السبب بدأنا رواية هذه القصة في أهم حدث إيطالي بموضوع الابتكار.

الآن، أصبحنا جزءًا من برنامج Hubble، وهي عبارة عن مسرّعة أعمال إيطالية لريادة الأعمال تم إنشاؤها بواسطة Paolo Barberis و Jacopo Marello و Alessandro Sordi، المكوّن من ثلاثة مؤسسين لـ Dada. لقد عملوا معًا لمدة 20 عامًا وساهموا معًا في 30 من الشركات الإيطالية والأجنبية تقدّم التمويل والدعم لهم.

هدفنا هو تقديم أنفسنا للمديرين الآخرين ورجال الأعمال وخبراء التسويق والتقنيين من أجل الارتقاء بالمنتج إلى مستوى أعلى واختبار أدوات واستراتيجيات جديدة لجعل Inspector معروفًا عَالَمِيًّا.

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

الختام

هذه كانت تجربة فاليريو باربيرا صاحب Inspector، قرأت مقالته بشهر 8 المنصرم واحتفظت بها وترجمتها إلى العربية.

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

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