البحث في الموقع

جميعنا نعلم أن التعهيد الخارجي للبرمجيات هو عبارة عن كارثة منتظرة في أية لحظة. في البداية تعثر على شركة تعدك بالحصول على كل ما تتمناه في منتج واحد، خلال وقت وميزانية محددين، بأعلى جودة ممكنة، مع واجهة استخدام جذابة، وتقنية متطورة، ودعم مدى الحياة دون متاعب. تقتنع بهذه المزايا وترسل لهم الدفعة الأولى؛ وهنا تبدأ الرحلة، ففريق العمل بالكاد يفهم متطلباتك، والجودة متدنية، ومع تجاوز كل الحدود المتوقعة للزمن والميزانية؛ يبلغ مستوى الإحباط لديك عنان السماء. بل إن "أفضل" جزء من ذلك كله هو أنه لا يمكن إيقافه؛ وإلا فستذهب كل الأموال التي أنفقتها هباء وسيكون عليك البدء من الصفر. لذا ستضطر للاستمرار بالارتباط مع هذا الفريق ﻷن تكلفة "الفراق" عنهم ستكون باهظة. ولكن؛ هل هناك طريقة أفضل للتعهيد الخارجي للبرمجيات؟ نعم؛ من الممكن القيام بذلك بطريقة صحيحة وخالية من المتاعب كليًا، ولكن عليك أن تكون مستعدًا لتعديل فلسفة الإدارة الخاصة بك. المبادئ الرئيسية هنا هي كالتالي: عليك أن تصارح فريق التعهيد بهواجسك بشكل مستمر ومنفتح. عليهم أن يبوحوا لك بالمخاطر والمشكلات التي تقابلهم بشكل مستمر ومنفتح أيضًا. هذان العاملان أساسيان لنجاح التعهيد الخارجي للبرمجيات؛ ولكن للأسف غالبًا ما يتم تجاهلهما. تعلّمت هذين المبدئين من المعلم وي لياو زي، إذ قال بما يتعلق بالاستراتيجية العسكرية في الصين القديمة عام 239 ق.م: دعوني أبرهن على هذا القول من خلال طرح بعض الأمثلة العملية عن كوارث التعهيد الخارجي للبرمجيات؛ وشرح كيفية تجنّب حصولها إذا اتبعت مبادئً تبلغ من العمر 2500 عام. أطول من الوقت المتوقع؛ أكثر من الميزانية المتاحة دائمًا ما يخبرك أفراد الفريق بأن المنتج جاهز بنسبة 95%، لكن هناك مع ذلك بعض المزايا غير المنفّذة أو المعطّلة. لقد قاموا بالكثير من العمل؛ ولقد دفعتَ الكثير من المال، لكن المنتج القابل للتسويق غير جاهز بعد؛ إنه يتطلب أسبوعًا إثر أسبوع؛ وشهرًا بعد شهر، دائمًا هناك تراكم، ولا يمكننا ببساطة أن ننتهي من ذلك، لقد بدأتَ ترى المشروع في كوابيسك، ولم يعد للأدوية المهدئة تأثير مساعد، هل يبدو لك هذا كله مألوفًا؟ الحقيقة التي ستدركها لاحقًا أنه لا يهم نوع العقد الذي وقعته مع شركائك في التعهيد الخارجي، كم عدد البنود التي حددتها، وكم عدد الوعود التي أُبرمت، إنهم يرغبون بالحفاظ عليك عميلًا دائمًا؛ أو على الأقل؛ ما دام في حسابك المصرفي شيء ما لتقدمه. كلاكما ترغبان بالنجاح بالتأكيد، لكن في حين يعني نجاحك كصاحب مشروع إطلاق المنتج النهائي للمستخدم، فإنّ نجاحهم كفريق تطوير برمجي يعني الاستمرار مطوّلًا بكتابة الشيفرات البرمجية لك، وهما هدفان لا يشتركان إلا بحيز ضيق، بل حتى يمكن القول أنهما هدفان متعارضان: فنجاحك يعني فشلهم. سيُسمعك أعضاء فريق التعهيد الكثير من العبارات من قبيل: أنهم يرغبون بإتمام بناء المنتج والتعاقد معك من جديد مستقبلًا؛ وسيقولون أن دافعهم الرئيسي هو سعادتك والحصول على منتج يشير لاسمك بقوّة؛ وسيؤكدون لك أن رضا العميل مقدّم لديهم على المال. على كل حال؛ أفترض أن لديك الجرأة الكافية لتعترف بالحقيقة: كل هذا محض كذب. إن الغالبية العظمى من مشاريع التعهيد الخارجي للبرمجيات تبوء بالفشل (انظر التقرير الأخير لـ CHAOS) ولعلّ مطوري البرمجيات يدركون هذه الحقيقة بشكل أفضل منك، إذ يعيشونها يوميًا مع مئات المشاريع؛ ولن يكون مشروعك استثناء من بينها. وهكذا؛ دعنا ننسى الوعود الجميلة ونسلط الضوء على الحقائق المتعبة، أنت الآن لوحدك. إليك ما أوصي به على ضوء المبادئ المذكورة آنفًا، تأكد من فهم الفريق لنقطتين: الوقت والميزانية والمجال المحدد لعملك. عواقب تجاوزهم هذه الحدود. وهذا يتعلق بالجزء الأول من المبادئ (عليك أن تصارح فريق التعهيد باهتمامك وقلقك بشكل مستمر ومنفتح). لكن ما يحدث عادة أن فريق التعهيد يبقى جاهلًا بالعمق الحقيقي للعمل؛ ما يسمعه فقط هو عبارة تتكرر على مسامعه مع كل مشروع (بأسرع وقت ممكن). والحقيقة أن عبارة "في أسرع وقت ممكن" ليست ميقاتًا محددًا، على العكس من ذلك؛ فهي تثبط الهمم خلافًا لما تفعله المواعيد الثابتة. يجب أن يكون لدى الفريق علم بالتاريخ الدقيق الذي ترغب باستلام المنتج فيه؛ وما الذي تريد استلامه بالضبط و"لماذا"، وعندما لا تكون الأمور واضحة ودقيقة بهذا الشكل سيبدأ العمل يتجه وفق منحى لا ترغب به. أؤكد هنا على سؤال "لماذا"؛ فمعظم أصحاب المشاريع يواجهون صعوبة في الإجابة عليه. لماذا تريد أن يكون المنتج جاهزًا مع بداية حزيران القادم؟ فقط لأنك سئمت من الانتظار؟ هذه ليست إجابة سديدة، فسأمُك من الانتظار لا يهم ما دام ثمة مال في حسابك المصرفي؛ لذا سيستمر الفريق في استنزافك، ولن يحترموا الموعد الذي أعطيته لهم. عجزك عن الإجابة على هذا السؤال أو عن إيضاحه للفريق سيجعلهم يشعرون بعدم وجود أهداف واضحة تتجه لها في عملك؛ الأمر الذي سيفقدك تقديرهم لتصرفك. إليك كيف يمكن أن يكون تحديد الزمن والتكلفة بشكله الصحيح: يجب أن تكون المزايا أ،ب وج جاهزة في الأول من شهر حزيران القادم، لأننا سنبدأ حملة تسويقية في الخامس منه. وإذا لم أطرح هذه المزايا سأخسر 25 ألف دولار من تكاليف التسويق، وإذا حدث ذلك سأضطر لخفض ميزانية التطوير الشهرية للنصف. عندما يسمع فريق التعهيد الخارجي هذه الكلمات؛ ويشعرون بأهمية المهلة المحددة لهم، سيتحولون إلى شريك حقيقي بالنسبة لك؛ وستبدأ أهدافهم بالتماشي مع أهدافك، لأنهم يعرفون مغبّة تجاوز العلامات الموضحة -ماديًا وزمنيًا-، ويدركون أن المتاعب التي ستواجهها جراء ذلك ستنتقل إليهم أيضًا. توقف عن طلب إتمام المنتج خلال "أسرع وقت ممكن"، توقف عن مهاتفة الفريق مرتين يوميًا؛ والصراخ والشكوى لمدة ساعة من أدائهم الضعيف، توقف عن استخدام هذه اللهجة في رسائلك الإلكترونية، هذه الضوضاء التي تحدثها لن تساعدك في الحصول على أي شيء؛ على العكس من ذلك، فهي تعقّد المسألة؛ ﻷنك تفقد احترامهم لك شيئًا فشيئًا، وعندها سيبدؤون بمعاملتك كبقرة حلوب تدفع لهم المال -وبالإضافة إلى هذا كشخص غبيّ وعاطفي-. بدلًا عن ذلك؛ قم بواجبك ووضح المعالم الحقيقية لمشروعك، فكر بالحدود اللازمة لكل من الوقت؛ المجال؛ والميزانية. اكتب ذلك بعبارات واضحة وموجزة، وتأكد أن تكون هذه الحدود واقعية وأن تتضمن الإجابة على السؤال الأهم: لماذا؟ لماذا تريد المنتج مع بداية شهر حزيران؟ لماذا تخصص مبلغًا أقل من 50 ألف دولار؟ لماذا تريد هذه المزايا الخمس في النسخة الأولى من المنتج؟ لماذا تريد أن يكون تطبيق الويب الخاص بمنتجك جاهزًا للتعامل مع ألف زيارة في نفس الوقت؟ لماذا تريد تطبيق الموبايل في الإصدار الأول؟ أجب على هذه الأسئلة لنفسك، وتأكد من كون الإجابات واضحة ومفهومة من قبل فريق التعهيد الخارجي، لا تخفِ عنهم هذه المعلومات. المنتج غير متقن تماما لديك أحلام بالحصول على موقع إلكتروني شبيه بـ Pinterest، سريع، سهل الاستخدام والتصفح، ويجعلك فخورًا عندما تستعرضه على زملائك. لكن كل ما تراه أمامك عبارة عن موقع غير متقن نهائيًا، بطيء، مع مظهر قبيح أيضًا. تطلبُ منهم القيام بشيء لإصلاح ذلك، ولا تحصل إلا على مزيد من الوعود. يستمر المشروع في استنزاف أموالك وتتضخم الميزانية المخصصة له، لكن ذلك لا يحسّنه ولا يزيد مظهره جمالًا، بالإضافة للفرق الشاسع بينه وبين Pinterest. يتزايد الإحباط يومًا إثر يوم؛ ولا تجد سبيلًا للخروج من ذلك كله. والنصيحة الوحيدة التي تتردد في محيطك هي بإعادة تصميم الموقع من الصفر مع فريق برمجي آخر. ألا يبدو لك هذا السيناريو مألوفًا؟ أعتقد أن السبب الرئيسي للوصول إلى هذه النهاية السيئة هو الخوف من الخصام، ففي بداية المشروع تسعى للحفاظ على علاقة جيدة مع فريق التعهيد الخارجي دون الإساءة لأي شخص منهم. وتحرصُ على عدم التدخل بعملهم لما قد يحمله ذلك من إهانة، ولعلّك لا ترغب أيضًا بالتعبير عن مخاوفك حيال جودة المنتج لئلّا تثبط فريق العمل، مع أملٍ لا تفصح عنه أن يتحسن المنتج في المستقبل، لكنك في المستقبل ستشعر أنك وصلت متأخرًا للغاية. مجددًا؛ مع استحضار المبادئ القديمة للفيلسوف الصيني؛ أود أن أنصحك بوضع إجراءات روتينية للتحقق من النتائج والتعبير عما يقلقك منذ اليوم الأول للمشروع. بالنسبة لنا فيTeamed.io فإننا نسأل العملاء أن يكونوا متواجدين على منصة GitHub ليستطلعوا ما نقوم به أولًا بأول، وأن يضيفوا تعليقاتهم على أيّ مشكل يلاحظونه مُباشرة على منصة GitHub. بالإضافة إلى أننا لا نمنّي صاحب المشروع بالكثير بخصوص الجودة؛ بل ونشجعه على أن يكون متشائمًا بهذا الخصوص؛ فقد أدركنا أننا بهذه الطريقة نخفف من مخاطر حدوث "الإحباط التراكمي". حاول أن تقوم بشيء مشابه مع فريق التعهيد الخارجي؛ لا تخف من الإساءة لأحد؛ فلطفك لن يساهم بالحفاظ على المشروع؛ بل لعله أسوأ ما تسديه لنفسك. مهما بدا لك منهج النقد المتكرر مثيرًا للنزاعات فهو صحيّ بشكل أكبر من السلام الناجم عن الصمت -السلام المؤدي إلى حروب في النهاية-، حاول أن تجد صيغة مناسبة لتوصل انطباعاتك وآرائك لفريق التعهيد بشكل منتظم، كن منفتحًا على هواجسك وصارح بها الفريق بانتظام حسب الوصية الأولى، وبهذا الشكل تحافظ على استقرار المشروع وتقلل من حصول المخاطر بأكبر شكل ممكن. بالإضافة إلى ذلك فمن الجيد للغاية أن تدعو من حين لآخر مُراجعين تقنيين لتحصل على آرائهم المستقلة حول منتج قيد التطوير. لا يمكنني الاعتماد على وعودهم تتصل بهم، تضع خطة للعمل، توضّح المعالم الأساسية، تعرّف المزايا المطلوبة، تحدد الأساسيات، تتّفقان على الجودة، ومن ثم تنتهي المكالمة. بعد عدة أيام تكتشف أن ذلك كله كان مضيعة للوقت، لا يمكنهم الإيفاء بوعودهم فهناك طارئ ما يحدث دومًا ويمنعهم من ذلك، أحدهم مريض، انهار الخادوم، بعض البرمجيات لا تؤدي الوظيفة المطلوبة، أجزاء من الكود البرمجي لم تعد تعمل.. إلخ. تتصل بهم مجددًا، تعبّر عن إحباطك بلهجة اتهام، تعود لتعريف المزايا المطلوبة مجددا؛ وتوضح من جديد كل ما ذكرته في مكالمتك السابقة، وبعد عدة أيام ستعود لنقطة البداية عينها، أليس كذلك؟ ألا يبدو هذا مشابهًا لما يحدث معك؟ انطلاقًا من تجربتي؛ فإن هذه الحالة من عدم القدرة على التنبؤ وعدم المصداقية تنجم عن صاحب المشروع نفسه وليس عن فريق التعهيد الخارجي. يحدث هذا عادة عند عدم إصغائك لهم؛ أو خوفهم من إخبارك بالحقيقة -وهما وجهان لعملة واحدة ويحملان التأثير نفسه على مشروعك-. البعض يسمي هذا بـ "التطوير المدفوع بالخوف" أو "fear-driven development". الفريق خائف منك؛ وهو مضطر للكذب عليك حتى تستمر بالعمل معه -والدفع له-. بشكل عام؛ سيخبرونك بما تودّ سماعه منهم: المشروع سينتهي قريبًا، العلل البرمجية يمكن إصلاحها بسهولة، مشاكل الأداء ثانوية وبسيطة، جودة بنية المشروع ممتازة، والفريق متحمس لعمله معك. عندما تسمع أيًا من هذه العبارات عليك أن تسأل نفسك: هل يشجعهم تعاملك على قول الحقيقة؟ وهل تمتنّ لهم لمصارحتك بالأخبار الحقيقية وإن كانت سيئة؟ مع استحضارنا مجددًا للمبدئين المذكورين أعلاه، أنصحك بالتأكد من اعتماد نهج المكافئة أو العقوبة تبعًا لشفافية فريق التعهيد الخارجي بنقل الأخبار لك؛ وأن يكون ذلك مقارنة مع أهداف المشروع لا حسب مشاعرك الشخصية. لا يجب على فرق تطوير البرمجيات أن تسعى لأن يكون العميل سعيدًا على الدوام؛ على العكس، فالمشروع المرجّح للنجاح هو ذاك الذي يكون فيه العميل بمزاج سيء ويحكم عليه بالفشل. لأوضح لك الأمر: إذا كنت تَسعد لكل خبر جيدٍ يزفه لك الفريق وتكافئهم عليه، فأنت تدرّبهم على الكذب. وإذا كنت تتوقع منهم تقديم أخبار جيدة باستمرار، فأنت لا تشجعهم على نقل الحقيقة دائمًا؛ ولا على فعل ما هو لمصلحة المشروع -لا لمصلحتك الشخصية-. أنت تثنيهم بذلك عن مجادلتك، بمعنى آخر؛ أنت تغلق قناة التواصل المفترضة بينك وبينهم؛ ولا تسمح للمعلومات أن تصل منهم إليك. وبهذه الطريقة تعزل نفسك عنهم، ويبدأ الفريق بالعمل ضدّك؛ وليس معك. ما أود نصحك به عمليًا هو كالتالي: أولًا: أعلن بشكل منتظم عن أهدافك وحدود مشروعك كما ذكرنا سابقًا، تأكد من فهم الفريق لخططك العملية والسبب الكامن ورائها -كإجابة على سؤال لماذا؟-. ثانيًا: اسأل الفريق بانتظام عن المشاكل والمخاطر التي تواجههم. اسألهم عن الأسباب التي تدفعهم للاعتقاد بضرورة تعديل أهداف المشروع، أو حتى بشكل أفضل؛ اطلب منهم أن يوثقوا المخاطر ويرسلوها لك بانتظام، كافئهم على شفافيتهم ومصداقيتهم بإرسال تقارير المخاطر. جرّب هذا النهج وسوف تفاجأ بما ستحتويه قائمة المخاطر من أشياء مثيرة للاهتمام. ترجمة -وبتصرف- للمقال How to Avoid a Software Outsourcing Disaster لكاتبه Yegor Bugayenko. حقوق الصورة البارزة: Designed by Freepik.

يحدُث كثيرا في مشاريع التعهيد الخارجي Outsourcing البرمجية أن تجد أن العميل لا يدري بالضبط مالذي يريده، ليس فقط على مستوى وظائف المنتج الذي تطوّره له، بل أيضًا على المستوى التقني. ما يجعل الموقف أسوأ أن العميل يظن نفسه يعرف ويفهم بما يكفي. يمكن أن تتساءل هنا: كيف يمكنني أن أجعله يفهم؟ كيف أدرّبه وأعلّمه؟ إياك أن تفعل. ستجد، رغم هذا التحذير، أنك متحفّز لفعل ذلك؛ فأنت تظن أن العميل صديق لك. ستريد مساعدته. ستشعر بحماسة كبيرة لجعل المنتج أفضل. علاوة على ذلك، أنت تمتلك المعرفة الكافية، فلماذا لا تشاركها؟ أليس هذا صحيحاً؟ خطأ. خطأ جسيم على مستويات كثيرة. أولًا، وقبل كلّ شيء؛ العميل ليس صديقك. ليس شريكا، و لا مساعدا، ولا زميلا، و لا حتى عضو فريق. العميل هو صاحب مصلحة في المشروع مثلك تماما، إلا أنّ رغباته تختلف تمامًا عن رغباتك؛ و هو يعي الأمر تماما. هو يريد إنهاء المشروع في أقرب وقت ممكن وينفق من جيبه أقل مبلغ ممكن. رغباته على النقيض منك تماما. كلاكما يعمل على نفس المشروع, لكن من زاويتين مختلفتين جداً. عاجلا، عندما يفشل المشروع (سيفشل غالبا، مثل ما هي حال 94% من جميع مشاريع البرمجيات، طبقاً لتقرير CHAOS ) سيبحث العميل عن شخص ليلقي اللوم عليه. لا داعي لإخبارك، لن يلقي باللوم على نفسه، سيوبخك أنت. طبقًا لنفس التقرير، سبعة بالمئة فقط من الإخفاقات كان سببها عدم الكفاءة التقنية. ومن ثم مشروعك سيفشل على الأرجح بسبب الفهم غير الصائب للمتطلبات والتخطيط دون المستوى وعدم ترتيب الأهداف الإدارية.. إلخ. هل تريد حقًا أن يُلقى اللوم عليك بسبب الأمور التي لا خبرة لك بها؟ دع العميل يفشل، إنه مشروعه، حياته و نقوده. أدّ عملك التقني بطريقة صائبة، و دع عنك عن الأشياء الأخرى. هذا هو ما تكون عليه الاحترافية الحقة، التركيز على الأشياء التي تستطيع عمل كل ما بوسعك فيها و بطريقة أفضل من أغلب الطرق التي يستخدمها الآخرون. ومع ذلك، لو لاحظت أنه يفعل أمرًا خاطئًا وأنه بحاجة ماسة إلى المساعدة، فانصحه بتوظيف مستشار. يوجد كثيرون في السوق يمكنهم مد يد العون في تحديد متطلبات المشروع، تجربة المستخدم، تحليل الأعمال، التسويق و العلامة التجارية إلى غيرها من الأمور التجارية. لا يدري العميل - غالبا - بوجود هؤلاء، أو أنه يظن أن الخدمات التي يقدّمونها هي فقط هدر للمال. حاول إقناعه بعدم صحة هذه النظرة، لكن لا تقحم نفسك في شيء لا تفهمه. وظيفتك هي كتابة الشفرة البرمجية، لذا ركّز عليها، عليها هي فقط. ترجمة - بتصرّف - لمقال How to Teach a Customer لصاحبه Yegor Bugayenko. حقوق الصورة البارزة محفوظة لـ Freepik

نحتاج جميعًا إلى التعهيد الخارجي للبرمجيات، بدءًا من أصحاب أصغر المواقع الإلكترونية وانتهاء بأغنى مئة رجل في العالم، لا سيما عندما نرغب بتصميم منتج برمجي لا يكون مهندس البرمجيات لدينا مؤهلًا لإنجازه، إلا أن النتيجة النهائية نادرًا ما تكون سارة، وفي الحقيقة فمن الصعب جدًا ألا تفشل هذه العملية؛ لذا أعددت هنا قائمة تلميحات بسيطة لكل من يقرر الاستعانة بمصادر خارجية لتطوير البرمجيات (مرتّبة من الأقل فالأكثر أهمية)، ولكم كنت أتمنى لو أُعطيت لي قبل 15 عامًا. حدّد في العقد من يملك حقوق المُنتج تأكد من احتواء العقد بينك وبين فريق التعهيد على عبارة مشابهة لـ: "يقر الطّرفان بأن كل ما سيتم تطويره هو خاضع للملكية الفكرية لصاحب المشروع"، وهو أبسط وأقصر تعريف لعبارة "كل ما تصممه لأجلي هو ملك لي"، عند تضمين العقد بهذه العبارة لن تتمكّن شركة التعهيد الخارجي من الادعاء بأن البرمجيات المصممة ملك لها، كما يحدث دومًا هنا وهناك. احصل على مستودع الشيفرة المصدرية تأكد من تحكّمك التام بالشيفرة المصدرية. الطريقة المثلى لذلك هي إنشاء مستودع GitHub خاص لقاء 7$ شهريًا، بحيث يكون قابلًا للوصول ومرئيًا من قبلك ومن قبل فريق التعهيد فقط. علاوة على ذلك؛ احرص على أن تكون الأذونات الممنوحة للفريق "للقراءة فقط"، وأنهم لا يستطيعون تعديل الشيفرة المصدرية بشكل مباشر إلا عبر تقديم طلب "pull requests"، لأن Git يتيح إمكانية تدمير كامل التأريخ الحالي بنقرة دفع -push- واحدة للفرع الرئيسي master branch، لذا فمن الأفضل أن تمتلك وحدك أذونات الكتابة. لتسهيل إدارة الأمور وتبسيطها، أنصحك بأداة Rultor والتي تمكنك من دمج طلبات Pull requests بشكل شبه أوتوماتيكي. اجمع الإحصائيات “Metrics” بانتظام : اطلب من أعضاء فريق التعهيد أن يجمعوا لك الإحصائيات/المقاييس الخاصّة بالبرنامج قيد الإنشاء ويرسلوها لك بانتظام بطريقة ما (كالبريد الإلكتروني ربما) وأنصح هنا باستخدام Hits-of-Code، النسبة التي تغطيها اختبارات الوحدة Unit tests (أو العدد الكلي لاختبارات فحسب)، التذاكر Tickets المغلقة والمفتوحة، ومدة البناء. أتحدث هنا عن مقاييس تعطيك صورة أوضح عن أداء الفريق، وهو ما لا يمكنك الحصول عليه بشكل مباشر من لدى استخدامك لأدوات التّحليل والمُتابعة كـ NewRelic. هذه المقاييس ستكون معيارًا لأداء الفريق، وليس المنتج قيد التطوير. لا أقول أنك يجب أن تدير الفريق من خلال هذه المقاييس، ولكن أبقِ عينيك مفتوحة على هذه الأرقام وعلى الأداء. إجراء مراجعات تقنية مستقلة: تكمن أهمية هذه المراجعات لصعوبة التحايل عليها. في الحقيقة فهذه الطريقة هي المثلى -ولعلها الوحيدة- لجمع آراء موضوعية عن البرنامج قيد الإنشاء وهو أمر ضروريّ جدًا بالنسبة لك. لا تعوّل على الوعود؛ التقارير، الضمانات أو التوثيق الشامل التي يقدّمها لك فريق التّعهيد، عوضًا عن ذلك؛ تعاقد مع شخص واطلب منه مراجعة ما يطوره لك فريق التعهيد الخارجي. قم بهذه المراجعات بشكل دوري ومنتظم، لا تخش من التّواصل مع فريق البرمجة، واشرح لهم بصراحة ما تحتويه المراجعات من نقاط تستوجب التعديل، إذا كانوا محترفين في عملهم فإنهم سيفهمون ويقدرون غرضك من هذا التصرف بالتأكيد. أتمتة النشر Deployment والتحكم به: اطلب من فريق التعهيد أتمتة آلية نشر التّطبيق deployment pipeline ووضعه تحت تحكمك، أنصحك أن تقوم بذلك خلال الأيام الأولى للمشروع، ما يعني أن المنتج سيُبنى؛ يُختبر؛ يُحزّم، يُركّب، وينشر في مستودع الإنتاج (أو على الخادوم) بنقرة واحدة. بالطبع أنت بحاجة لبعض السكربتات لأتمتة هذه السلسلة من العمليات، وينبغي على فريق التعهيد كتابتها لك. ومن ثم؛ عندما تبدأ عملية التطوير، سيُنفّذ السكربت نفسه عند إجراء أي تعديل على المستودع الذي سينشر للإنتاج. المهم هنا هو معرفتك كيفية عمل السكربت وآلية تشغيله، بحيث تكون قادرًا على بناء ونشر منتجك بنفسك. المطالبة بإصدارات أسبوعية: لا تنتظر النسخة النهائية من المنتج؛ واطلب من فريق التعهيد أن يصدروا نسخة أسبوعية منه، لا يهم مدى كثافة التطوير أو عدد الميزات الجاري تنفيذها، من الممكن دائمًا تحزيم نسخة جديدة وإطلاقها. إذا كان التطوير مكثفًا، اطلب من الفريق استخدام GitFlow مثلًا لعزل فرع مستقر من أفرع التطوير، لكن احذر من الانتظار. احرص على رؤية البرنامج مُحزّمًا ومنشورًا بشكل أسبوعي، دون استثناءات أو أعذار، إذا لم يكن فريق التعهيد قادرًا على إعطائك ذلك فذلك مدعاة للقلق، وقد تحتاج حينها إلى إجراء تغيير ما. وظّف CTO مستقل: أقدّم هذه النصيحة في المقام الأول للشركات الصغيرة أو الأفراد الذين يرغبون بتطوير منتج برمجي خاص بهم ويعتمدون على خبرتهم الشخصية أثناء مراقبة فريق التعهيد الخارجي. ففي كثير من الأحيان يحاول أصحاب المشاريع إبداء حذاقتهم في عالم البرمجيات ويتحكمون بفريق التعهيد بشكل مباشر، عبر تعلم لغة البرمجة المُستخدمة في المشروع، أو تعلّمهم لمبادئ DevOps، لكنهم لا يعلمون أن ذلك كله يقودهم للفشل. لذا كن ذكيًا واعتمد على الشخص المناسب: فالتعاقد مع مدير تقني تنفيذي chief technical officer (CTO) أمر لا بد منه في هذه الحالات، ليرسل لك تقارير مستمرة ويوجه عمل فريق التعهيد الخارجي. سيكون تعاملك المباشر مع مدير التقنية CTO ويتولى هو توجيه فريق التعهيد ومراقبته؛ بحيث يرسل CTO لك التقارير عن سير العمل، ويرسل له فريق التعهيد التقارير التقنية بدورهم. تحديد المكافآت والعقوبات: هذان العنصران أساسيان في عالم الإدارة والقيادة؛ ولست أعني هنا إدارتك للمبرمجين كأفراد كل واحد منهم على حدة، بل أن يكون الفريق تحت تحكمك كوحدة واحدة. الدوافع مهمة للغاية في هذا المجال؛ إذ يجب أن يعلم الفريق بوضوح ما الذي سيجنوه إن نجحوا؛ وما الثمن الذي سيدفعوه بالمقابل إن هم فشلوا، وإذا لم تكن صريحًا بهذه الآلية فستكون فرصتك بالنجاح ضئيلة بالفعل. يفترض معظم الناس أن أفضل دافع لفريق البرمجة هو استمرار العمل بالمشروع، والدفعات المالية التي تقدمها لهم؛ أليس كذلك؟ لكن في الحقيقة هذا خاطئ تمامًا، لا يمكن أن تكون الإدارة ناجحة عبر المكافأة من خلال تحويلات مصرفية شهرية أو المعاقبة بالحرمان منها، وسبب فشل هذا الأسلوب كليًا هو قسوته وغلظته، ابحث عن آلية أفضل وأكثر دماثة وفعالية في أسلوب المكافأة والعقوبة ترجمة -وبتصرّف- للمقال Software Outsourcing Survival Guide لصاحبه Yegor Bugayenko حقوق الصورة البارزة محفوظة لـ freepik

واحدة من الأمور المفضّلة لديّ هي مساعدة الأشخاص في أولى خطواتهم على درب الشركات الناشئة، فقد عشت شخصيًّا العديد من التجارب الفاشلة قبل مشروع Buffer، لذا سيكون من الرائع مشاركتكم بعض الدروس المستوحاة من الفشل؛كما أنني أشعر بالمتعة لاسترجاع تحدّيات الأيام الأولى لمشروع Buffer والتي مضى عليها خمسة أعوام حتى اليوم. في الأسبوع الأخير عقدتُ خمس جلسات -كلّ واحدة منها بحدود ثلاثين دقيقة بشكل شخصيّ أو عبر Hangouts- حيث كنت أحاول مساعدة أحدهم، كنتُ مُندهشّا من تكرار نفس التحديّات في ثلاثة من هذه الجلسات الخمس، لذا بدا لي بأن الموضوع جدير بأن يُطرح في مقال. التفكير بالتّعهيد الخارجي لبناء لشركتك الناشئة (outsourcing)من الطبيعي للغاية إذا لم تكن لديك خلفية تقنية وإذا لم تكن قادرًا على البرمجة أن تفكّر بعدم استطاعتك في بناء شركتك الناشئة دون مساعدة؛ وغالبا ما ستراودك فكرة تتمثل بأحد احتمالين: إمّا إيجاد شريك تقنيّ technical co-founder، أو التعهيد ببناء المنتج الفعّال القاعدي MVP لمستقلّ أو شركة خارجية. وحسب تجربتي؛ فإن هذان الخياران هما أقل المناهج جدوى لنجاح شركتك الناشئة بالسرعة المطلوبة. وإليكم الأسباب التي لأجلها أرى أنه لا يجدر بكم الاستعانة بمصادر خارجية لبناء شركاتكم الناشئة: 1. عدم وجود تطابق بين أهدافك وأهداف المستقلّإذا كنتَ تفكّر أن تستعين بمساعدة خارجيّة؛ فيجدر بك أن تعلم أنّ هدف الأشخاص المستقلين أو وكالات التطوير هو خدمة أكبر عدد من العملاء؛ وكسب المزيد من المال في نهاية الأمر، بينما يكون هدفك عندما تبدأ بشركة ناشئة هو الوصول إلى مُنتج مُلائم للسّوق Product-Market Fit وصنع شيء يمكن أن يجذب الناس traction. المشكلة الأبرز مع هذين الهدفين المختلفين؛ هو أنّ الطريق الناجح ليصل المستقل لهدفه مختلفٌ كُليّةً عن الطريق الناجح لمؤسسي الشركات الناشئة ليصلوا إلى منتج قابل للتسويق. واحدة من أبسط المشاكل التي تواجه المستقلين هي تجاوز مشاريع العميل الحدود التي رُسمت له قبل الشّروع في تنفيذها، وبالتالي فإنّ تحديد المستقل أو الوكالة لسعرٍ معيّنٍ لقاء العمل على المشروع؛ يعني أنهم سيحتاجون لاتخاذ عدة خطوات للتأكدّ أن المشروع لن يتجاوز الحجم المخطّط له منذ البداية، لذا سيتّجهون أوّلًا لتحديد الخصائص التي سيتضمنها المشروع بشكل واضح ومبيّن، فالمستقلّ يهدف في النهاية لكسب المال؛ والأداة الرئيسية في هذا هي في التفصيل الدقيق أثناء تحديد الخواص المطلوبة من المشروع منذ البداية؛ وتجنّب التغييرات في المواصفات على طول الطريق بقدر المستطاع. بينما تهدف أنت كمؤسّس لشركة ناشئة الوصول لمنتج مناسب للتسويق، ثمّة لمحات عظيمة في قول لـِ مات مولينويج (مُؤسس Wordpress/automattic) حول الأسباب التي يجدر بالمؤسسين لأجلها إطلاق شركاتهم الناشئة في أبكر مرحلة ممكنة؛ إذ يقول: لذا، فإنّ النهج المثاليّ لبناء شركة ناشئة ناجحة هو إطلاقها بأقصى سرعة ممكنة، لتستفيد بعدها من التغذية الراجعة والمعلومات التي تحصل عليها من آراء المستخدمين وخدمة العملاء في تعديل وتحسين المنتج، الأمر الذي سيكون موضع خلافٍ كليّ مع منهج معظم المستقلين في العمل. ليس هذا فقط؛ فمعظم المستقلين يفضّلون مشاريع من قبيل بناء مواقع ويب للأعمال التجارية الأكثر توقّعًا وثباتًا؛ لذا لن يفهموا غالبًا جوهر الشركات الناشئة. لا يعني هذا أن المستقل أو الوكالة يقومون بالأمور بشكل خاطئ، لكنهم فقط يجتهدون في أكثر أنواع المشاريع شيوعًا بين الزبائن: برمجة موقع ويب. على سبيل المثال موقع ويب لمطعم، لمقهى، أو نادي جولف، نحن نعرف تمامًا ما يجب أن يكون عليه موقع ويب خاص بمطعم؛ إذ يجب أن يحتوي قائمة الطعام الذي سيقدّمه؛ موقع المطعم الجغرافيّ؛ إلخ. أما في عالم الشركات الناشئة فنحن نعيش حالةً من"مشاكل غير معروفة، وحلول غير معروفة" حسب تعبير إيريك رايس، إذ لا ندري إذا ما كانت فكرتنا الجديدة ستنجح أم لا، لذا فإن الأمور بالنسبة لنا تحتاج لمنهج مختلفٍ بشكل كليّ؛ وأحسبُ أن ذلك لا يتفقّ أبدًا مع منهج المستقلين في تنفيذ المشاريع. 2. الصورة الذهنية الخاطئة حول "ما تحتاجه لتحصل على منتج من الصفر"بشكلٍ مرتبط جدّا بالتحديّ الأول المذكور للتوّ، أعتقد أن تفكيرك في الحصول على دعمٍ خارجيّ لتنفيذ فكرة شركتك الناشئة؛ يشير إلى وجود صورة ذهنية خاطئة لديك حول كيفية إنشاء شركة ناشئة بنجاح، إذ يدلّ على وجود انطباع مسبق بأن الجزء الأساسي من نجاح أيّة فكرة هو بناؤها فحسب، التفكير بهذه الطريقة يتجاهل أمرًا مهمّا؛ إذ كثيرًا ماتكون الفكرة بحدّ ذاتها بعيدة عمّا تريد؛ ولن تحصل على النجاح حالما تُطلقها وتطرحها للعموم. لحسن حظّي؛ بدأتُ تعلّم البرمجة منذ الثانية عشرة من عمري. لذا كنت مرتاحًا عندما فكّرت بتأسيس شركة ناشئة لأنّ الجانب البرمجيّ من العمل مغطّى، بعد عدّة سنوات من خوضي هذا المضمار؛ أدركتُ أن معرفتي البرمجية جعلتني أغفل عما يلزمني لإنشاء منتج ناجح، كنتُ أستمر بالبناء فحسب؛ ولكنّي اليوم لا أعتبر أنّ البناء هو الجزء الرئيسي من النجاح في إنشاء شركة ناشئة. ما يلزمُك بدايةً لإنشاء منتجٍ ناجح هو استبعاد كل الأفكار التي لم تتحقَّقْ من رغبة الناس بها؛ إيجاد فكرة لشيء يحتاجُه المستخدمون أو الزبائن بشدّة، ما يجعله منتجًا مناسبًا للتسويق وقابلًا للجذب، الأمر المهم في هذه الخطوة أنك لن تحتاج البرمجة لتحقيقها. ما أؤمن به -اليوم بشكل خاص- هو أنّك قادر على بناء النسخة الأولى الفعّالة تمامًا من شركتك الناشئة دون برمجة على الإطلاق -وإن كانت تلك النسخة أشبه بدليل أو بمجموعة خطوات مُحدّدة مُسبقًا-، يمكنك استخدام أدوات مثل Wufoo ،Unbounce، ووردبريس، نماذج Google، ووسائل أخرى لتنظم الأمور بنفسك مع بعضها، قد تقع في بعض الثغرات أثناء محاولتك تنفيذ الأفكار بشكل يدويّ وذاتيّ، إذ لن تكون الأمور متوازنة تمامًا، لكنّها الطريقة الأساسية للبدء بالنموّ والفهم؛ واختبار ما يصلح من أفكارك وما لا يصلح. ثق تمامًا أنه في وسعك الحصول على منتج أوّلي -غير قريب من المثالية- دون أية برمجة، بل قد يبدأ حصد بعض التفاعل traction إذا تابعت العمل عليه وبدأت بحل الجوانب التي لم يتم التّحقق منها بعد فيه. حالما تبدأ فكرتك بجذب تفاعل الناس؛ ستفتح لك أبوابًا كثيرة لمساعدتك في برمجة منتجك وجعله أجمل. من الأمور التي تُواجه وُترهق المُبرمج المُخضرم التالي: يعرض عليه صاحب فكرة فكرته ويطلب منه بناء المُنتج له. لكن في المقابل المُبرمج الجيّد سيكون مُهتمًا بالانضمام إليك في شركتك النّاشئة إن كُنت قادرًا على بناء مُنتج أولي ومن دون أية برمجة وحصلت على قدر كبير من الاهتمام والنّمو traction. 3. يجب على فريق التأسيس أن يكون ملمًّا بكل شيءأمر آخر يجعلني أؤمن بضرورة الانطلاق دون دعم خارجي لشركتك الناشئة: يجب على فريق المؤسسين أن يتعلّموا القيام بكل المهام في المشروع؛ وإليكم الأسباب: يجعلك هذا تؤمن بقدرتك على تنفيذ أية فكرة وجعلها حقيقة، عليك فقط أن تكتشف ولعَك والطرق المختصرة للقيام به؛ لتحقّق ما تريد بقدراتك الحالية.يسمح لك بالتّحكّم الكامل بكل أجزاء مشروعك، بما يضمن لك إمكانية التعديل والتغيير بشكل مباشر وسريع.سيعرّفك توظيف الآخرين للعمل معك على الفرق بين الإنسان المبدع في عمله وبين آخر ليس جيدًا بما فيه الكفاية.سيصحبك شغفُك بمستوياته المتعدّدة في مختلف مراحل بناء شركتك الناشئة، الأمر الذي يمكن أن يساعدك بإتقان مهارات كثيرة في آن معا أثناء ذلك. من الصعب أن تستأجر الشغف، ومن الصعب على أي شخص آخر أن يستغرق في بناء شيء لا يشعر بوجود حماس كافٍ لدى مؤسّسه.لهذا؛ أنصحك بشدة بالقيام بكلّ شيء مع شُركائك في بدايات المشروع. في البدايات المبكرة؛ قمنا أنا وشريكي بالتطوير، التصميم، إعداد قاعدة البيانات، وإدارة النظام، خدمة العملاء، التسويق، وأشياء أخرى، حتى أنني قمت ببناء النسخة الأولى من تطبيق الأندرويد قبل أن نضمّ مُطوّرًا لفريقنا ليتولّى المهمة. تقريبًا لا يوجد زاوية في مشروع Buffer لم نقم بها بشكلٍ شخصي ويدويّ أنا وشريكي في مرحلة التأسيس، النتيجة هي الحماسة الشديدة التي اكتسبناها بقدرتنا على إدارة الأمور في جميع المجالات، والقدرة على الحديث بعمق واستفاضة حول أي جزء من أجزاء المشروع لأيّ شخص. ما الذي نفعله عوضًا عن التّعهيد الخارجي؟حسب اعتقادي الشخصي؛ فإنّ بناءك لمنتج بنفسك هو الطريق الأمثل؛ بل لعلّه في الحقيقة الطريق الأسرع لإنشاء شركتك الناشئة بنجاح. قد يبدو الأمر معاكسًا للبديهة، فكيف يكون بناء المنتج بنفسك أسرع طريقة للنجاح في حين أنك لا تمتلك أية معرفة برمجية؟ الفكرة أنني لا أتحدث عن البرمجة، بل عن بناء المنتج بأية وسيلة يمكنك البناء بها. قد يعني هذا بناؤه من دون أية برمجة، ومن الممكن أن يعني التقاط المهارات وتعلّمها من هنا وهناك، وهو أمر عظيم في رأيي. السبب الذي يجعلني أعتبر بناء مُنتجك بنفسك هو الطريق الأقصر والأمثل؛ هو أنّه في حال كان ما تمتلكه هو الفكرة فقط؛ فإنّك ستجد عواقب كثيرة للحصول على شريك ذي خلفية تقنية ليشارك في بنائها؛ أو تُعهد بالأمر لمستقل أو وكالة، لكن قيامك بهذ الخطوة وعدم وجود علاقات عمل مع من يبني لك المنتج قد يحرمك من كونك جزءًا من أهم حلقة في إنشائه؛ وهي حلقة البناء-القياس-التعلم، والتي يؤدي تكرارها عادة لوصولك إلى منتجك مُتناسب مع السّوق product/market fit. لأجل ذلك كلّه، فإن النهج الذي أنصح به هو أن تفعل ذلك بمفردك؛ وفي الوقت ذاته أن تبقى على تواصل مع الأفراد الملمّين بالتقنية في محيطك أثناء بناء شركتك الناشئة، سيمرّ مشروعك بنقطة تحوّل واضحة عندما يصبح جذّابا بشكل كافٍ ليجذب شريكًا تقنيًًا إلى المشروع. لذا فإن لم تنجح بعد في جذب شريك تقنيّ -أو شخص ملمّ بالتقنية يرغب بالعمل معك كأول موظّف-؛ أرى أن عليك الاستمرار بالعمل والبحث والاهتمام بتطوير العميلcustomer development، التحقّق من افتراضاتك لإنشاء "شيء ما" يجذبهم إليك ويُحقّق النّمو والانتشار traction. تُرجم بتصرّف للمقال: 3reasons you shouldn't outsource your startup, and what to do instead لصاحبه جويل غاسكوين (مؤسس Buffer).