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

جميعنا نعلم أن التعهيد الخارجي للبرمجيات هو عبارة عن كارثة منتظرة في أية لحظة. في البداية تعثر على شركة تعدك بالحصول على كل ما تتمناه في منتج واحد، خلال وقت وميزانية محددين، بأعلى جودة ممكنة، مع واجهة استخدام جذابة، وتقنية متطورة، ودعم مدى الحياة دون متاعب. تقتنع بهذه المزايا وترسل لهم الدفعة الأولى؛ وهنا تبدأ الرحلة، ففريق العمل بالكاد يفهم متطلباتك، والجودة متدنية، ومع تجاوز كل الحدود المتوقعة للزمن والميزانية؛ يبلغ مستوى الإحباط لديك عنان السماء. بل إن "أفضل" جزء من ذلك كله هو أنه لا يمكن إيقافه؛ وإلا فستذهب كل الأموال التي أنفقتها هباء وسيكون عليك البدء من الصفر. لذا ستضطر للاستمرار بالارتباط مع هذا الفريق ﻷن تكلفة "الفراق" عنهم ستكون باهظة. ولكن؛ هل هناك طريقة أفضل للتعهيد الخارجي للبرمجيات؟ نعم؛ من الممكن القيام بذلك بطريقة صحيحة وخالية من المتاعب كليًا، ولكن عليك أن تكون مستعدًا لتعديل فلسفة الإدارة الخاصة بك. المبادئ الرئيسية هنا هي كالتالي: عليك أن تصارح فريق التعهيد بهواجسك بشكل مستمر ومنفتح. عليهم أن يبوحوا لك بالمخاطر والمشكلات التي تقابلهم بشكل مستمر ومنفتح أيضًا. هذان العاملان أساسيان لنجاح التعهيد الخارجي للبرمجيات؛ ولكن للأسف غالبًا ما يتم تجاهلهما. تعلّمت هذين المبدئين من المعلم وي لياو زي، إذ قال بما يتعلق بالاستراتيجية العسكرية في الصين القديمة عام 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