لوحة المتصدرين

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

جمعنا في هذا المقال 10 أدوات تساعد مستخدمي لينكس في مهامّ متنوعة مثل مراقبة الشبكة، فحص النظام وأوامر أخرى للرفع من الإنتاجية. الأداة w يُظهر أمر w المستخدمين مسجلي الدخول إلى النظام والعمليات التي ينفذونها: w أضف الخيار h- للحصول على المساعدة: w -h nmon وهي أداة تعرض معلومات عن أداء النظام، يمكن تثبيتها على أوبنتو بالأمر: sudo apt-get install nmon ثم بعد التثبيت ننفذ الأمر: nmon يمكن للأداة تحصيل معلومات عن استخدام الشبكة، المعالج والذاكرة. اضغط على حرف c لمعلومات عن استخدام المعالج: وحرف n لمعلومات عن الشبكة: تعطي الأداة بالضغط على حرف d معلومات عن استخدام القرص الصلب: ncdu وهي أداة تُستعمَل لتحليل استخدام مساحة القرص الصلب. للتثبيت على أوبنتو نفذ الأمر: sudo apt-get install ncdu وللاستخدام: ncdu / تأخذ الأداة معطى يمثّل المجلد الذي نريد معرفة مساحته على القرص الصلب. في المثال أعلاه حدّدنا المجلّد الجذر. قد يأخذ تحليل القرص بعض الوقت حسب حجمه، ثم تظهر النتيجة: استخدم الأسهم للانتقال بين قائمة المجلدات، وزر Enter لاختيار مجلد، n لترتيبها حسب الاسم و s لترتيبها حسب الحجم (تُرتّب المجلدات مبدئيا حسب الحجم). slurm تُستخدَم هذه الأداة لمراقبة تدفق البيانات عبر الشبكة حيث تظهرها في شكل منحنيات بيانية. sudo apt-get install slurm استخدم الخيار i- لمراقبة واجهة شبكة محددة: slurm -i eth1 اضغط زر l و c للانتقال بين طريقتي العرض، r لتحديث الشاشة و q للخروج. findmnt يُُستخدَم أمر findmnt للعثور على نظم الملفات المركّبة Mounted. كما يُستخدَم لتركيب أو نزع تركيب أجهزة طرفية عند الحاجة. findmnt نستخدم خيار l- للعرض على هيئة لائحة. findmnt -l عرض نظم الملفات المركّبة في ملف fstab: findmnt -s يمكن أيضا البحث عن نظم الملفات حسب النوع: findmnt -t ext4 dstat هي أداة مجمَّعة لمراقبة استخدام الذاكرة، عمليات النظام وأداء القرص الصلب. تُعدّ dstat بديلا جيدا لكل من ifstat ،iostat و dmstat. للتثبيت: sudo apt-get install dstat نفذ أمر dstat للحصول على معلومات مفصّلة عن استخدام المعالج، القرص الصلب والشبكة. يتيح الخيار c- تركيز المعلومات المعروضة على المعالج: dstat -c كما يمكن استخدام الخيار l- مع c- لمعرفة متوسّط استخدام المعالج لدقيقة، 3 دقائق أو 15 دقيقة. يوجد خيار D-الذي يمكن من متابعة أداء تجزئة قرص صلب بدلا من كامل القرص (d- لعرض أداء القرص فقط دون بقية الإحصاءات): dstat -dD sda7 saidar أداة أخرى تعمل في سطر الأوامر لمراقبة إحصاءات النظام مثل استخدام القرص الصلب، الشبكة، الذاكرة، مساحة الإبدال Swap وغيرها. للتثبيت: sudo apt-get install saidar ثم ننفذ أمر saidar للحصول على إحصاءات عن مختلف موارد النظام. يمكن استخدام الخيار c- لتلوين المخرجات. saider -c ss تأتي ss (اختصار لـSocket statistics) بديلا لأداة netstat لتجميع معلومات من فضاء النواة Kernel، تتميّز بالسرعة مقارنة مع netstat. لعرض جميع الاتصالات (نستخدم less لتسهيل تصفح المخرجات، اضغط على زر المسافة للانتقال للشاشة الموالية): ss |less يمكن استخدام الخيار A- لحصر النتائج حسب النوع: ss -A tcp كما توجد إمكانية عرض أسماء ومعرّفات العمليات pid: ss -ltp ccze تتيح هذه الأداة عرض السجلات Logs بهيئة أكثر جاذبية، للتثبيت نفذ الأمر: sudo apt-get install ccze مثال على الاستخدام: tailf /var/log/syslog | ccze تمكّن الأداة أيضا من حفظ السجلات بنفس طريقة العرض في ملف HTML: tailf /var/log/syslog | ccze -h > /path_to_file.html يعرض الأمر عند استخدام الخيار l- وحدات الأداة (أنواع السجلات التي تتعامل معها). ranwhen.py وهو سكربت python يعمل في الطرفية لعرض نشاطات النظام بيانيا، ينشئ السكربت منحنيات بيانية ملوّنة لعرض تفاصيل الأنشطة. للتثبيت على أوبنتو أضف المستودع التالي: sudo apt-add-repository ppa:fkrull/deadsnakes ثم حدّث النظام: sudo apt-get update وثبّت الإصدار 3.2 من python: sudo apt-get install python3.2 نزّل السكربت: wget -c https://github.com/p-e-w/ranwhen/archive/master.zip ثم فك ضغطه: unzip master.zip && cd ranwhen-master بإمكاننا الآن تنفيذ الأداة: python3.2 ranwhen.py ترجمة - وبتصرّف - لمقال Ten 10 Useful Utilities For Linux Users لصاحبه Rajneesh Upadhyay.