دراسة الجدوى التقنية في هندسة البرامج: ما يجب مراعاته قبل بدء عملية التطوير

خلال سنة 2021، وفي حدث خيب بشدة آمال محبي استكشاف الفضاء عبر العالم، أجلت وكالة ناسا NASA رحلةً طال انتظارها إلى القمر بما لا يقل عن سنة كاملة، واعترفت السلطات حينها بأن الموعد المحدد سابقًا بسنة 2024 لهبوط الإنسان على القمر لم يستند إلى دراسة جدوى تقنية.

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

لماذا نحتاج إلى دراسة الجدوى؟

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

تغطي دراسة الجدوى الشاملة خمس جوانب أساسية يرمز لها اختصارًا بالحروف اللاتينية TELOS المعروفة لدى مديري المشاريع والمنتجات.

كما تُظهر الصورة أعلاه، يرمز TELOS إلى العناصر التالية:

تستكشف الجدوى التقنية ما إذا كان يمكن أصلًا بناء المنتج باستخدام الأدوات والخبراء المتوفرين.
تفحص الجدوى الاقتصادية تكاليف المنافع الاقتصادية للمشروع، ولتحديد الجدوى الاقتصادية، كثيرًا ما يستخدم التقدير التقريبي rough order of magnitude ROM.
تتأكد الجدوى القانونية من أن المنتج يتوافق مع كل التنظيمات ولا يخترق أية قوانين، على سبيل المثال، إذا كان البرنامج يتعلق ببيانات صحية، فلا بد أن يحترم اللوائح المتعلقة بخصوصية المرضى، كما ينبغي استكشاف المخاطر القانونية الممكنة وكيف يمكن أن تؤثر على المشروع.
تستكشف الجدوى العملياتية كيفية تأثير مشروع جديد على العمليات اليومية في الشركة، والإجراءات التي ينبغي تطبيقها، والجهود التي ينبغي بذلها للحفاظ عليها، فإذا افترضنا على سبيل المثال أن الأمر يتعلق بإطلاق منصة عالمية للتجارة الإلكترونية، فسنحتاج تبعًا لذلك إلى مخازن وفرق عمل محلية، وفي بعض الحالات إلى مواقع إنترنت محلية في كل بلد. وعليه، من الصعب جدًا تحقيق هذا المشروع عمليًا، وربما يكون ذلك غير ممكن إطلاقًا، رغم أن الفكرة الأولية تبدوا جذابةً اقتصاديًا وقابلةً للتطبيق تقنيًا.
تعطي الجدوى الزمنية للمشروع آجالًا واقعيةً للتنفيذ وتساعد على الالتزام بها.

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

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

ما هي الجدوى التقنية؟

تُعَد الجدوى التقنية أكثر أجزاء دراسة الجدوى استهلاكًا للوقت في مجال هندسة البرامج وأكثرها تعقيدًا، لذلك، عند الحديث عن جدوى المنتجات الرقمية، فنحن نعني الجدوى التقنية بالدرجة الأولى.

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

تُقيَّمُ الجدوى خلال مرحلة التفكير في تطوير المنتج، وذلك بعد جمع المتطلبات المبكرة للمشروع والمتمثلة في:

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

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

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

مثال عن دراسة جدوى تقنية

دراسة الجدوى التقنية هي فحص متعمق للعوامل التقنية ذات الصلة بالمشروع المعني، وتشمل أمورًا مثل:

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

تتضمن هذه الدراسة سلسلةً من الخطوات سنتناولها فيما يلي بتفصيل أكثر.

التفكير في خيارات التنفيذ

الخبراء المعنيون: مهندس برامج أو مهندس حلول solution architect، خبراء تقنيون آخرون.

قبل كل شيء، ينبغي التفكير في خيارات التنفيذ، وهنا، لدينا عادةً عدة بدائل:

1. ألا نفعل شيئا

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

2. تحديد برنامج جاهز وتعديله وفقا لاحتياجاتنا

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

أنظمة إدارة الممتلكات الخاصة بالفنادق
أنظمة خدمة المسافرين الخاصة بشركات الخطوط الجوية
أنظمة السجلات الصحية الإلكترونية الخاصة بالمستشفيات.

عند اختيار منتج جاهز للاستخدام ينبغي أن نقيس بحذر الجوانب التالية:

الأداء.
سهولة التعلم.
سهولة الإطلاق.
درجة الدعم المقدمة من البائع.
التوافق مع التقنيات الأساسية الأخرى التي نستخدمها.
قابلية التوسع.
خيارات الترخيص.

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

3. بناء نظام مخصص

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

تقييم بيئة الأجهزة والبرامج

الخبراء المعنيون هنا هم مهندس برامج أو مهندس حلول solution architect، ومحللي الأنظمة، ومهندسي تقنيات المعلومات.

سواءً اخترنا منتجًا جاهزًا أو بناء نظام مخصص، لا بد من جرد أجهزة وبرامج الشركة للإجابة على السؤال: هل يمكن إدارة المشروع باستخدام مكونات البيئة الحالية؟

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

بالنسبة لمقدمي الخدمات على مدار اليوم والأسبوع 24/7، مثل وكالات السفر ومنصات البنوك الرقمية، من المهم إلى جانب امتلاك طاقة معالجة كافية الحفاظ على الاتصال الدائم بشبكة الإنترنت؛ وفي هذه الحالة، لا بد من إنشاء تكرار للشبكة Network redundancy. وإحدى الطرق المباشرة لذلك هي تثبيت نسخة واحدة على الأقل من نظام الأجهزة الحالي، بما في ذلك الخوادم وأجهزة التوجيه وغيرها، وتشغيلها جنبًا إلى جنب. وفي حالة توقف أو فشل مسار المرور الأول، سيتولى المسار الثاني المسؤولية فورًا.

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

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

إحدى الطرق الواعدة لحل مشكلات طول وقت الاستجابة في مجال إنترنت الأشياء الطبية Internet of Medical Things وأنظمة إنترنت الأشياء هي حوسبة الحافة Edge computing، والتي توزع بعض وظائف الحوسبة عبر خوادم دقيقة موجودة قرب مصادر البيانات، متمثلةً في المجسات والأجهزة الذكية، بدل الاعتماد الكامل على المعالجات المركزية عن بعد، غير أن هذه التقنية لا تزال غير ناضجة، مما يجعلها تنطوي على مخاطر فشل كبيرة.

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

إنشاء عدة تصاميم تقنية

الخبراء المعنيون هنا هم مهندس برامج أو مهندس حلول solution architect، إلى جانب الخبراء التقنيين، والمستشارين الخارجيين.

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

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

ينبغي دراسة كل واحد من الخيارات التقنية من كل جوانب الجدوى الاقتصادية والقانونية والعملياتية والزمنية.

تحليل المخاطر والقيود التقنية

الخبراء المعنيون:

مهندس برامج أو مهندس حلول solution architect
الخبراء التقنيون.

زيادةً على جوانب الجدوى، ينبغي تحليل المخاطر التقنية المرتبطة بكل خيار، والتي تشمل على سبيل المثال لا الحصر:

اعتماديات الأطراف الخارجية third-party dependencies.
التبني المبكرة للتقنيات غير الناضجة.
استخدامات أدوات جديدة على فريق العمل.
التعامل مع الأنظمة القديمة.

أخيرًا، ينبغي النظر في القيود التقنية والمزالق الممكنة للتصاميم المقترحة، والمتمثلة في:

قيود الأداء.
التعقيدات المتعلقة بالتطبيق.
مخاوف قابلية التوسع: هل سيستطيع النظام تحمل الحجم المتزايد للعمل؟
مخاوف قابلية الاستهلاك: هل سيستطيع النظام دعم وظائف وواجهات جديدة وغيرها؟
التعقيدات المتعلقة بالصيانة والدعم.

عند الحصول على كل المعلومات المهمة، لا يبقى إلى اتخاذ القرار واختيار أفضل بديل.

المقارنة بين الحلول المقترحة واختيار الأفضل

الخبراء المعنيون: كل المختصين المذكورين في العناصر السابقة.

للمقارنة بين الحلول واختيار البديل الأفضل، ربما ستحتاج الشركة إلى بناء مصفوفة قرار decision matrix.

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

كتابة تقرير الجدوى

الخبراء المعنيون: كل المختصين المذكورين في العناصر السابقة.

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

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

اختبار وإثبات الجدوى

بعد تحديد التصميم المختار وكتابة تقرير الجدوى، يمكن تخفيف الأخطار المحتملة أكثر من خلال اختبار فرضية المنتج عن طريق:

إثبات المفهوم proof of concept.
النموذج الأولي prototype.
منتج الحد الأدنى MVP.

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

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

بناء إثبات المفهوم لتأكيد الجدوى التقنية

الخبراء المعنيون: محللو الأعمال، ومصممو واجهة وتجربة المستخدم.

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

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

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

بناء النموذج الأولي لاختبار الواجهة

الخبراء المعنيون: محللو الأعمال
مصممو واجهة وتجربة المستخدم
مطورو البرامج.

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

بناء منتج الحد الأدنى للتأكد من جدوى السوق

الخبراء المعنيون: مديرو المشاريع

مطورو البرامج.

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

متى تكون للجدوى التقنية أهمية قصوى؟

ما هي درجة العمق التي ينبغي أن تبلغها دراسة الجدوى لضمان سير الأمور على ما يرام دون أي مفاجآت غير سارة خلال مرحلة التطوير؟ كلما زادت درجة الابتكار في المنتج، زادت كمية التفاصيل التي ينبغي للدراسة أن تشملها، فقط، وتكون دراسة الجدوى التقنية ذات أهمية خاصة في المجالات التالية:

تطوير منتج جديد.
إضافة خصائص جديدة.
إعادة التصميم الجذري، مثل تجزئة نظام العمل الشامل إلى أنظمة خدمات مصغرة جدًا.

بعبارة أخرى، هل توجد حالات لا ضرورة فيها لدراسة الجدوى التقنية؟ بالتأكيد، ويمكن إحصائها على أصابع اليد الواحدة كما يلي:

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

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

ترجمة -وبتصرّف- للمقال Technical Feasibility Study in Software Engineering: Things to Consider Before Development Starts