|
النظم الصغيرة والكبيرة
إن أغلب النماذج التي طورت حتى الآن كانت تركز على تنظيم دورة تطوير النظم
ذات الحجم الكبير ويرجع ذلك إلى أن واضعيها كان هدفهم حل المشاكل التي
تواجهها الشركات والمؤسسات الكبيرة في إدارة فرق العمل والتخطيط لعملية
التطوير. وعلى الجانب الآخر أُهملت عملية تطوير النظم الصغيرة والمتوسطة
بعض الشيء وترك للراغبين في تطوير هذه النظم المجال مفتوحاً وغير محدد
لاختيار وانتقاء ما يناسب مشاريعهم من النماذج المعدة أساساً لخدمة النظم
الكبيرة.
وعندما نحاول تطبيق نموذج واحد لخدمة كل من الأنظمة الصغيرة والكبيرة فإننا
نرتكب خطأ كبيراً نتيجة للخصائص التي يتمتع بها كل منهما. فمن ناحية, تحتاج
الأنظمة الكبيرة إلى مستوى عالي من التنظيم والمتابعة والإدارة وعادة ما
تكون العوائد المرجوة من مثل هذه الأنظمة سواء العوائد المادية أو المعنوية
مبرراً كافياً لتحمل تكاليف هذا المستوى من التنظيم, كما أنها تكون قادرة
على تغطية مثل هذه التكاليف. في حين أن النظم الصغيرة عادة لا تكون بحاجة
لمثل هذا المستوى العالي من التنظيم بل يعتبر عبئاً عليها تفشل في أحيان
كثيرة في مجرد تغطية تكاليفه كما أن العوائد المعنوية لها عادة ما تكون أقل
من أن تبرر مثل هذا الإنفاق الضخم والوقت المبذول.
فحين نحاول تقديم نموذج موحد لا يفرق بين أحجام النظم المختلفة فإننا نجد
أمامنا خيارين, إما أن نهمل احتياج الأنظمة الكبيرة للمستوى العالي من
التنظيم أو أن نُحمّل الأنظمة الصغيرة أعباءً غير ضرورية, قد تؤدي أحياناً
إلى فشلها أو على الأقل تشكل هدراً للمصادر التي يمكن الاستفادة منها في
تحقيق أهداف أخرى سواء للمنشأة أو لفرق العمل الصغيرة القائمة بذاتها أو
حتى للمبرمجين المنفردين.
وما يحدث حقيقة أن مثل هؤلاء يستخدمون هذه النماذج ظاهرياً من خلال إعداد
الوثائق التي تشير إلى اتباعهم نموذجاًً معيناً في العمل في حين أنهم حقيقة
يقومون بالتطوير من خلال أسلوب التجربة والخطأ والاستكشاف فقط. وأحياناً
يتجنبون كلية استخدام أية نماذج محددة.
ومن ناحية أخرى عادة ما يكون تطوير
النظم الكبيرة من خلال منشئات كبيرة يعمل بها المتخصصون والمحترفون بدرجات
عالية في حين أن أغلب النظم الصغيرة تطورها منشئات صغيرة يكون العاملون بها
إما من المبتدئين أو الهواة أو حتى المحترفين بدرجات أقل من نظرائهم في
الشركات الكبيرة وهو ما ينعكس مباشرة على أسلوب العمل, ففي حين يتمكن ذوو
الخبرة الأوسع من المحترفين من تقدير جزء كبير من المتطلبات التي يحتاجها
النظام والوسائل التي يمكن تحقيقها بواسطتها, نجد بالمقابل أن ذوي الخبرة
الأقل عادة ما يعجزون عن تحديد المتطلبات بشكل كافي قبل الشروع فعلياً في
عملية تطوير النظام كما لا تتوفر لديهم أيضاً في أحيان كثيرة الإحاطة
الكافية بالأدوات التي سيتم استعمالها لتحقيق الأهداف. وينجم عن تطبيق
النماذج المعدة لتطوير النظم الكبيرة على النظم الصغيرة التي يطورها هؤلاء,
أنها حقيقة تطبق مشوهة نظراً لأن عملية الاستكشاف والتجربة أثناء التطوير
تمارس بشكل مكثف مما يؤثر على جودة هيكل النظام ومدى اتسامه بالوضوح.
الوقت والتكاليف والجودة
عندما تقوم المنشئات الصغيرة باستخدام نموذج لا يراعي حجم قدراتها ومصادرها
فإنها عادة ما تفشل. والحقيقة أن هذا لا يحدث إلا نادراً لأن هذه المنشئات
عادة ما تقوم باستخدام أشباه نماذج يتم وضعها أثناء عملية التطوير نفسها
بناء على الظروف والمعطيات التي تصادفها عملية التطوير لكل منتج على حدة ,
وذلك يبدو منطقياً لأنها تسعى لخفض التكاليف حتى تتجنب الفشل.
إن قيام المنشئات بمثل هذا التصرف رغم أنه يحقق لها مزية التوفير إلا أنه
يؤدي إلى عدم وجود أسلوب ثابت أو نمط رئيسي يحكم عمليات التطوير المختلفة
مما يؤدي في النهاية إلى اختلاف معايير الجودة والتصميم من منتج لآخر على
الرغم من أنها جميعاً طورت في منشأة واحدة بل وربما بواسطة نفس الأشخاص.
أما لو وجد الأسلوب الذي يراعي قدرات ومصادر هذه المنشئات فإن استخدام هذه
المنشئات لهذا الأسلوب سيؤدي إلى تكوين ما يمكن أن نسميه بأساس موحد لعملية
التطوير التي تقوم بها الشركة فالمعايير تصبح ثابتة وما يختلف بين نظام
وآخر هو ما يتعلق باختلاف أهداف كلا النظامين دون أن يمنع ذلك من حدوث
عملية تطوير للمعايير ضمن إطار واضح مفهوم بدلاً من التطوير العشوائي.
إن هذه العشوائية في العمل تعتبر مصدر رئيسي
لاستنزاف موارد المنشأة سواء الموارد المالية أو الزمنية نظراً لعمليات
التكرار الغير ضرورية أو بسبب الاعتماد الكلي على الاستكشاف والتجربة
والخطأ.
البساطة والتعقيد
إن أحد أهم الأسباب التي تدفع بالكثير من مطوري النظم الصغيرة وأحياناً
المتوسطة إلى عدم إتباع منهجيات محددة في العمل أو تطبيق نماذج التطوير هو
أنهم يجدون فيها تعقيداً لا مبرر له بالنسبة لهم, فالكثير منهم يطور أنظمة
تكون الحاجة فيها إلى التوثيق الدقيق قليلة جداً وأحياناً معدومة, فالنظام
الذي يصممه يتكون من عدد محدود نوعاً ما من المكونات وعدد صغير نسبياً من
أسطر الأوامر ومن خلال قضاء بضعة دقائق أو حتى ساعات قليلة في مراجعة أسطر
الأوامر التي يتكون منها البرنامج يمكن عادة إعادة استيعاب المنطق الذي
يسير به.
وفي نفس الوقت فبالنسبة لهؤلاء فهناك احتمال ضئيل جداً أن يقوم شخص آخر من
خارج فريق التطوير بالإطلاع على الأوامر أو محاولة تصحيح سير البرنامج
ولذلك لا يرى داعياً لكل الإجراءات المعقدة التي تتطلبها النماذج المعدة
لإدارة عملية تطوير النظم الكبيرة. وحتى عندما يكون هناك احتمال أكبر أو
حاجة واضحة لنوع من التوثيق فإنه يجد أنه من الكافي وجود بعض التعليقات
داخل البرنامج ومخططات كروكية بسيطة لمنطق العمل. والحقيقة أنهم محقون في
ذلك ولا حاجة لهم فعلياً بكل هذا الجهد والتعقيد.
وهنا يبرز سؤال في أذهان البعض, أليس من المفيد تطبيق هذه النماذج على
النطاق الصغير من باب التعلم والخبرة قبل تطبيقها على النظم الكبيرة؟
في الحقيقة إن إجابة هذا السؤال هي نعم إن ذلك مفيد ولكن ماذا عن أولئك
الذين ليست لديهم الرغبة في الدخول في إطار تطوير النظم الكبيرة في
المستقبل؟ لماذا ندفعهم لتحمل هذا العبء بدون داعي؟ وفي نفس الوقت ما
المانع أن يكون هناك نموذج مبسط يتعلم من خلاله من يرغب في التعلم بحيث
يحصل من خلال ممارسته له على أساسيات التنظيم في العمل وأساليب التفكير
والتحليل وإيجاد الحلول الصحيحة وبعد ذلك وعندما يحين وقت العمل في النظم
الكبيرة فلن يكون من الصعب عليه أن يدرك بسرعة مقبولة متطلبات الوضع الجديد
الذي هو مقدم عليه, بل على العكس من ذلك فإن التدرج في التعلم شيء منطقي
يسهل عملية الاستيعاب.
تفجير الطاقات الكامنة
في الواقع أن هناك مشكلة كبيرة يغفل عنها الكثيرين من المطورين خصوصاً في
دول العالم الثالث وهي أن أغلب النماذج الموجودة حالياً تشجع بطريقة أو
بأخرى الاستخدام غير المحدود للمولدات التلقائية والمعالجات التي تقوم
بأداء العمل نيابة عن المطور.
في الحقيقة أن هذه الأدوات هي سلاح ذو حدين وأنا لست ممن يعارضون استخدامها
أو ينكرون الفوائد الكبيرة التي تقدمها ولكن لابد أن يكون هناك مستوى من
التوازن بين استخدام الآلة واستخدام العقل البشري. وهؤلاء الذين يسعون إلى
تقليل الاعتماد على العقل البشري إلى أقل حد ممكن أو حتى إلغاؤه هم في
الحقيقة يتقدمون باتجاه خاطئ لأنهم بدايةً مهما فعلوا فلن يستطيعوا الوصول
إلى شيء كامل يغني تماماً عن العقل البشري , هذا من ناحية ومن ناحية أخرى
فإن الاعتماد بشكل أساسي على هذه الأدوات يقتل القدرة الإبداعية لدى
العاملين في حقل التطوير. إن هذه الأدوات يجب استخدامها داخل حيز محدد من
أداء الأعمال الروتينية التي يتسبب عمل المطور فيها بشعوره بالملل وإضاعة
وقته وجهده دون أن يشعر أنه يقوم فعلاً بشيء جديد سوى اتباع روتين محدود
متكرر لأجل الوصول إلى الهدف. أما عندما نتكلم عن التصميم والتطوير فعلياً
فيجب أن يتوقف استخدام هذه الأدوات عند الحدود التي تقوم بتبسيط التعقيدات
وتقديم تصورات واضحة, أما أن نجعلها تقوم هي كلياً بكل العمل فهذا بالإضافة
إلى أنه كما ذكرت يقتل بمرور الوقت قدرة المطور على الإبداع فإنه يورثه
الاعتمادية على هذه الأدوات حتى أنه يصبح عاجزاً عن العمل بدونها, وفي نفس
الوقت ينقله من دور المطور الحقيقي إلى دور المستخدم الرشيد, فهو قد أصبح
مجرد مستخدم لأدوات وبرامج يصنعها الآخرون ولا يدرك عن خوافي الأمور إلا
القليل. والحقيقة أن هذه النقطة بالتحديد هي أحد أهم أسباب تخلف علوم
الحاسب وحتى العلوم الأخرى في الدول النامية فأغلب المطورين في هذه الدول
هم في الحقيقة مستخدمون للأدوات التي يتم تطويرها في الدول المتقدمة وقليل
جداً أولئك الذين لديهم معرفة كافية عما تقوم به هذه الأدوات فعلياً من
وراء الكواليس.
إنني بالتأكيد لا أعني أنه يفترض بالمطور أن يعرف بالتفصيل ما الذي تفعله
هذه الأدوات ولكن لابد أن يكون لديه فهم كافي للأسس التي تحكم عملها بما
يعطيه المجال أن يطورها أو أن يطور أدوات أحدث منها عند الضرورة أو على
الأقل حتى تكون لديه فرصة أكبر لإيجاد الحلول الإلتفافية التي يضطر كثيراً
لاستخدامها لتجاوز العقبات الفنية التي تفرضها قوانين اللغة أو الأداة التي
يستعملها. وعليه فإننا بحاجة إلى نموذج يضع بالاعتبار هذا التوازن بين
الآلة والإنسان. ويقودوني هذا للحديث عن نقطة أوسع وهي
الميل لميكانيكية العمل حيث أصبح الإتجاه السائد لدى المنشآت العاملة في
حقل تطوير البرمجيات هو تحويل عملية التطوير إلى خطوط إنتاج تشبه تلك
الموجودة في المصانع حيث يتم تحويل النظام المطلوب تطويره إلى أجزاء مبسطة
يتم تحديدها من قبل الإدارة العليا ثم تتم عملية إنتاجها بشكل آلي من قبل
مبرمجين نمطيين. وبشكل أوضح أصبحت وظيفة المبرمج كوظيفة العامل الذي
يقوم بتنفيذ الرسومات الهندسية لتي يضعها المهندسون. ورغم إن هناك حاجة
لشيء من هذا القبيل في تصميم النظم الكبيرة (وإن لم تكن تلك الحاجة مبررا
لهذه المبالغة الموجودة في اتباع هذا المنحى) إلا أن الحاجة لمثل هذا
الإجراء في النظم الصغيرة والمتوسطة تكاد تكون منعدمة بل إنها على العكس
تتسبب في السلبيات التي ذكرتها منذ قليل.
ومن ناحية أخرى فكثير من الأساليب الموجودة حالياً تركز بشكل كامل على
النواحي الاقتصادية والمالية لمشاريع تطوير البرمجيات وتهمل التنقيب والبحث
عن الأفكار الجديدة المبدعة التي يمكن استغلالها، وهي تفعل ذلك دون قصد حين
تركز على الجوانب الاقتصادية وحدها وتحول الأمر إلى لغة المال فقط دون أن
تأخذ بالاعتبار أو تراعي الطبيعة البشرية للعاملين في هذه المشاريع مما
يصدهم عن محاولات الابتكار والتجديد بل ويمتد إلى أن يصبح العمل بيئة
بيروقراطية. والبيروقراطية تعني باختصار إضاعة الوقت في إتباع إجراءات
مفروضة يمكن الاستغناء عنها. في الحقيقة أنني أرى أن كثيراً من الإجراءات
التي تفرضها النماذج الموجودة حالياً هي نوع من البيروقراطية غير الضرورية
خصوصاً عندما نتكلم عن تصميم النظم التي لا تصل إلى الحجم الكبير.
على كلٍ هناك نقطة مهمة أحب الإشارة إليها هنا وهي أن البيروقراطية لا
تتمثل فقط في وجود الإجراءات التي تفرض علينا بدون داعي بل تتجسد أيضاً في
تفكيرنا وسلوكياتنا. فأحيانا تكون الإجراءات منطقية وضرورية ولا تدخل في
حيز البيروقراطية ولكننا نحن بأسلوب تطبيقنا لها ندخلها بالقوة داخل هذا
الحيز المظلم. فتعاطينا مع الإجراءات بسلاسة وديناميكية وتقدير سليم لظروف
واحتياجات الواقع يمكن حتى في بعض الأحيان أن يجعل من الإجراءات التي هي
أساساً منضوية تحت لواء البيروقراطية أمراً عملياً مقبولاً. ومن هنا تأتي
الحاجة لوجود نموذج يتيح أكبر قدر من الديناميكية والمرونة في التعاطي مع
الإجراءات ومعطيات الواقع دون المساس بأسس ومعايير التطوير والجودة.
الحاجة الدائمة للتطور
إن القوانين الطبيعية التي أوجدها الله تعالى في هذا الكون تحكم دائماً
بعدم وجود الشيء الكامل فلا كامل إلا هو سبحانه ومن الطبيعي أن تكون هناك
دوماً حاجة إلى التطوير والتجديد ومن هذا يتفرع الاحتياج الدائم لأن يكون
هناك تطوير في النماذج والأساليب التي تحكم عملية تطوير النظم والبرمجيات
من أجل تحسينها وتلافي عيوبها وعلاج المشاكل التي تنتج عن استخدامها وفي
نفس الوقت إضافة الأفكار الجديدة التي تساهم في رفع كفاءة المطورين وقدرتهم
على الإبداع والإنتاج.
وأنا من خلال هذا السياق أحاول أن أضيء شمعة جديدة في الطريق لعلها تنير
مساحة أوسع منه, ولعله يأتي في وقت ما شخص آخر يستضيء بها ويضيء شمعة أخرى
تنير مساحة أوسع منها.
الخلاصة
وأحب أن ألفت نظر القارئ الكريم إلى أن النقاط السابقة وإن بدت وكأنها
تتحدث عن نفس القضية وهذه حقيقة إلا أن كلاً منها تنظر إليها بصورة مختلفة
ومن زاوية جديدة ويمكنني أن ألخص الاحتياج لأسلوب جديد في النقاط الستة
التالية:
1. الحاجة للتفريق بين النظم الصغيرة والنظم الكبيرة
2. الحاجة لتوفير والوقت والتكاليف للمنشئات الصغيرة والمطورين المنفردين
3. الحاجة للتبسيط والسهولة في تطوير النظم الصغيرة والمتوسطة
4. الحاجة إلى تفجير الطاقات الإبداعية في أعضاء فريق العمل
5. الحاجة إلى محاربة البيروقراطية في العمل
6. الحاجة الطبيعية لتطوير نموذج جديد يجمع مميزات ما سبقه ويتلافى عيوبه
قدر الإمكان
|