هل يصحّ أن تبقى وثيقة المواصفات في التطوير التعاقديّ على شكل Excel؟ ── اختيار الصيغة المناسبة كمُسلَّم

«استلمتُ النسخة المُعدَّلة من وثيقة المواصفات، لكنّني ختمتُ الاستلام دون أن أعرف أين تغيّرت»

«عندما أردتُ طلب تعديل، وجدتُ أنّ وثيقة مواصفات Excel المُسلَّمة تختلف تماماً عن الشاشة الحاليّة»

«وصلتني من شركة التطوير وثيقة مواصفات على شكل ورق Excel مُربَّع، فهل هذا أمر معتاد؟»

عند تكليف جهة خارجيّة بتطوير نظام، تُسلَّم وثيقة المواصفات والتصميم مع البرنامج. وفي التطوير التعاقديّ الياباني، غالباً ما تُصنَع هذه الوثيقة بواسطة Excel، وتُكتَب غالباً بأسلوب يُعرَف بـ«ورق Excel المُربَّع»، وهو تقطيع الخلايا إلى مربّعات دقيقة واستخدامها كورقة كتابة يدويّة.

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

1. الخلاصة أوّلاً

نلخِّص النقاط الأساسيّة أوّلاً.

• لا تُختار صيغة وثيقة المواصفات المُسلَّمة وفق «سهولة الكتابة أثناء التطوير»، بل وفق «هل يستطيع العميل مراجعتها؟» و«هل تتحمَّل الفحص والاستلام؟» و«هل يمكن مشاركة فروقات تغيير المواصفات؟» و«هل تصلح للصيانة بعد سنوات؟»
• الخلاصة ليست «التخلّي عن Excel»، بل «التخلّي عن الورق المُربَّع والعودة إلى الأداة المناسبة لكلّ غرض». النصوص بـ Word، والجداول بجدول Excel الأصيل، والرسوم بأداة رسم، وسجلّ الاتّفاق بـ PDF
• قبل الجدل حول الصيغة، حدِّد في العقد (تحديد المُخرَجات في العقد الفرديّ) أيّ وثيقة تُعتبَر مُخرَجاً، وهل يمكن الحصول على أصل قابل للتعديل

إليك جدول قرار بالصيغة المُوصَى بها حسب طبيعة الوثيقة.

فيما يلي شرح مُرتَّب لسبب هذا الاختيار.

2. ما مشكلة وثيقة مواصفات ورق Excel المُربَّع بوصفها مُسلَّماً

لنوضِّح أوّلاً: المشكلة ليست في برنامج Excel نفسه. فـ Excel أداة ممتازة للحسابات الجدوليّة والقوائم، وهو الخيار الصحيح لوثائق تعريف العناصر مثلاً، كما سنوضِّح لاحقاً. المشكلة هي حشر النصّ والرسم والجدول - أشياء مختلفة الطبيعة - كلّها داخل «الورق المُربَّع».

لو كانت وثيقة داخليّة للشركة، لكانت المشكلة تخصّ كاتبيها فقط. لكنّ الأمر يختلف عندما تصبح مُسلَّماً. فوثيقة المواصفات هي مُخرَج يدفع العميل ثمنه ويستلمه، وموضوع للفحص والاستلام، وأصل يُستخدَم لسنوات لاحقاً. ومن منظور المُسلَّم، توجد في ورق Excel المُربَّع المشكلات التالية.

2.1 يتعذَّر مراجعته بالكامل عند الفحص والاستلام

لا يملك ورق Excel المُربَّع آليّة عرض فروقات عمليّة كسجلّ التغييرات في Word. وبدقّة أكبر، تحتوي بيئة التحرير المشترك في Microsoft 365 على سجلّ تغييرات الخلايا («عرض محتوى التغيير» أو سجلّ الإصدارات)، وتوجد أدوات مثل Spreadsheet Compare لمقارنة المصنَّفات. لكنّ ما يمكن تتبّعه يتمحور أساساً حول قيم الخلايا والصيغ (formulas)، ولا يشمل نصوص الأشكال ومربّعات النصّ التي تُستخدَم بكثرة في وثائق الورق المُربَّع، كما أنّ سجلّ التحرير المشترك لا يعمل أصلاً في بيئة تسليم تتناقل فيها الملفّات كمرفقات بريد إلكترونيّ.

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

هذا تجويف لإجراء الفحص والاستلام. فالاستلام هو إجراء «التحقّق من مطابقة المُسلَّم للمحتوى المتَّفق عليه وقبوله»، وعندما يُصبح هذا الإجراء شكليّاً، تنشأ لاحقاً عند اكتشاف مشكلة نقاشات عقيمة من نوع «ألم تُجرِ الاستلام؟» مقابل «بل لم يُسلَّم بصيغة يمكن التحقّق منها».

2.2 لا يبقى سجلّ للاتّفاق على تغيير المواصفات

لا بدّ أن تتغيّر المواصفات أثناء التطوير. وإن كانت الوثيقة على شكل ورق Excel المُربَّع في تلك اللحظة، تميل عمليّة تبادل التغييرات إلى أن تصبح «كومة من نُسَخ الملفّات». لا شكّ أنّ كثيرين يتذكّرون أسماء ملفّات من نوع 仕様書_v2_最終_修正(2).xlsx (وثيقة_المواصفات_إصدار2_نهائيّ_تعديل(2).xlsx).

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

2.3 يتباعد عن التنفيذ في مرحلة الصيانة

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

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

2.4 يتعذَّر الاستفادة منه لدى العميل

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

3. المنظور التعاقديّ ── وثيقة المواصفات «مُخرَج»

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

بعبارة أخرى، لا يكتسب الجدل حول الصيغة - Excel أم Word - معنىً إلّا بعد تحديد الأساس التالي.

• أيّ وثيقة هي المُخرَج: أدرِجها على مستوى اسم الوثيقة، لا كـ «مجموعة وثائق»
• بأيّ صيغة تُستلَم: هل تشمل أصلاً قابلاً للتعديل (ملفّ Word أو Excel)؟ فالاكتفاء بـ PDF وحده يُصعِّب الصيانة
• طريقة الفحص والاستلام: ما الذي يُتحقَّق منه للقبول؟ وكيف تُعرَض فروقات النسخة المُعدَّلة؟
• معاملة حقوق النشر والاستخدام الثانويّ: هل يستطيع العميل النسخ والتعديل داخليّاً؟ وهل يمكن تسليم الوثيقة عند تكليف شركة أخرى بالصيانة مستقبلاً؟

إن لم يُحدَّد هذا في العقد، فمهما كانت الصيغة المُختارة راقية، سينشأ خلاف حول «هل هذه الوثيقة أصلاً ضمن نطاق التسليم؟». راجع أيضاً «ما ينبغي تنظيمه قبل طلب تعهيد أو تطوير تعاقديّ لتطبيق Windows» بخصوص التنظيم قبل الطلب.

4. خيارات صيغة التسليم ── المقارنة وفق «هل تصلح كمُسلَّم؟»

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

نُفصِّل كلّ خيار.

4.1 Word ── الخيار الأوّل لوثائق المواصفات النصّيّة

الوثائق «التي تُروى بالنصّ»، مثل وثيقة التصميم الإجماليّ أو شرح مسار العمل، ينبغي أصلاً أن تُكتَب ببرنامج معالجة نصوص. ويحتوي Word منذ البداية على الأدوات اللازمة لوثيقة تسليم.

• أنماط العناوين والفهرس التلقائيّ: تصبح بنية الوثيقة واضحة، ويمكن القفز من الفهرس إلى الموضع المطلوب
• سجلّ التغييرات (ميزة المراجعة): يظهر بالأحمر أين تغيَّرت النسخة المُعدَّلة، ممّا يرفع فعاليّة المراجعة والاستلام بشكل كبير
• ميزة التعليقات: تبقى ملاحظات العميل والردود عليها مُدوَّنة على الوثيقة نفسها
• مقارنة الوثائق: يمكن عرض الفروقات بين نسختين لاحقاً أيضاً

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

الملاحظة المهمّة هي أنّه إن أُنشئت الوثيقة بمظهر مُرتَّب فقط دون استخدام الأنماط، تقع في نفس الفخّ الذي يمكن تسميته «ورق Word المُربَّع». اجعل العناوين بأنماط العناوين، والتخطيط بضبط التنسيق لا بتكرار المسافات. كما أنّ «مشكلة أيّ نسخة هي الأحدث» تحدث في Word أيضاً، فاستخدمه مصحوباً بتشغيل إدارة الإصدارات المذكور لاحقاً.

4.2 استخدام Excel كـ«جدول حقيقيّ» فعلاً

الوثائق مثل تعريف عناصر الشاشة، وقائمة الرموز، ومصفوفة الصلاحيّات هي بطبيعتها جداول. وكتابتها بـ Word غير عمليّة، بل الصحيح هو Excel. لكن استخدمه ليس كورق مُربَّع، بل كجدول أصيل يمكن معالجته كبيانات.

• صفّ واحد = سجلّ واحد، وعمود واحد = خاصيّة واحدة. ضع جدولاً واحداً فقط في كلّ شيت
• لا تصنع التخطيط بدمج الخلايا. اجعل العناوين في صفّ واحد في الأعلى
• لا تُفسِد بنية البيانات من أجل مظهر الطباعة (اجعل تنسيق الطباعة بوسيلة منفصلة)

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

4.3 PDF ── صيغة تجميد «النسخة المتَّفق عليها»

صعوبة التعديل السهل في PDF هي عيب وميزة في آنٍ واحد. فهو غير صالح كأصل لوثيقة المواصفات، لكنّه مناسب كلقطة (snapshot) للنسخة التي اجتازت الاستلام أو النسخة المتَّفق عليها عند تغيير المواصفات. وبما أنّه لا يتغيّر بالخطأ، فهو يعمل كسجلّ لـ«ما اتُّفِق عليه في هذه اللحظة».

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

المبدأ الآخر بسيط: يجب أن يكون PDF دائماً مصحوباً بأصل قابل للتعديل. فتسليم PDF وحده يُضيِّق خيارات العميل المستقبليّة (الاستفادة الداخليّة، تكليف شركة أخرى بالصيانة).

4.4 اعتماد Markdown + Git كأصل، وتوليد Word / PDF للتسليم

من جانب إدارة شركة التطوير، انتشرت في السنوات الأخيرة طريقة كتابة وثيقة المواصفات بـ Markdown وإدارة إصداراتها في نفس مستودع Git الخاصّ بالشيفرة المصدريّة. يمكن الحصول على فروقات على مستوى السطر، ومراجعة الوثيقة بنفس آليّة مراجعة الشيفرة، ويبقى مسار التغييرات كسجلّ تاريخيّ (هذا يكفي كسجلّ للممارسة التطويريّة، لكن إن كان مطلوباً كدليل للتدقيق أو التعامل مع النزاعات، يلزم بشكل منفصل تشغيل يحظر إعادة كتابة السجلّ التاريخيّ وما شابه).

لا حاجة هنا إلى مطالبة العميل باستخدام Git. بجعل الأصل مُداراً بـ Markdown، وتوليد المُسلَّم (Word أو PDF) عبر أداة تحويل مثل Pandoc، يستلم العميل Word/PDF كالمعتاد فقط. وبهذا يمكن الجمع بين كفاءة إدارة جانب التطوير وسهولة قراءة جانب العميل.

الملاحظة المهمّة هي توضيح «أيّ منهما الأصل» تعاقديّاً. فإن عدَّل العميل ملفّ Word المُولَّد مباشرةً، يتفرَّع عن الأصل، لذا يلزم اتّفاق تشغيليّ مثل استلام طلبات التعديل كتعليقات وتطبيقها على الأصل.

4.5 Wiki وأدوات الإنترنت ── «وثيقة مواصفات حيّة» عند وجود صيانة مستمرّة

بالنسبة للأنظمة ذات عقد الصيانة المستمرّ والتعديلات المتكرّرة، يُعدّ تحديث وثيقة المواصفات باستمرار عبر أداة عبر الإنترنت مثل Notion أو Confluence خياراً قويّاً أيضاً. قابليّة البحث فيها عالية، ويبقى سجلّ التغييرات تلقائيّاً، وهي صيغة يسهل معها الحفاظ على «وثيقة حيّة» بدل «التسليم ثمّ الانتهاء».

لكن من منظور المُسلَّم، يجب تحديد ما الذي يتبقّى عند انتهاء العقد منذ البداية: صيغة التصدير (هل يمكن التصدير إلى Word أو PDF؟)، وملكية المساحة وتحمُّل تكلفتها، ومعاملة حسابات الاطّلاع. وإن تُرِك هذا غامضاً، يحدث ارتهان (lock-in) لأداة معيّنة، مع خطر فقدان الوصول إلى الوثيقة بمجرَّد انتهاء العقد.

5. كيفيّة إدارة تبادل تغييرات المواصفات

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

1. جهِّز سجلّاً واحداً لإدارة التغييرات: قائمة تُسجِّل في صفّ واحد رقم التغيير والتاريخ والمحتوى والأثر (التكلفة/الموعد) وأطراف الاتّفاق. يكفي جدول Excel أصيل لهذا الغرض. اجعله متطابقاً مع إجراء إدارة التغييرات في عقد IPA النموذجيّ (راجع المقال المذكور آنفاً)
2. اجعل تعديل الوثيقة يتبادَل بصيغة تُظهِر الفروقات: في Word، فعِّل سجلّ التغييرات وأرسِل النسخة المُعدَّلة، ويتحقَّق العميل مركِّزاً على النصّ الأحمر. وإن كان هناك قلق من إغفال تفعيل سجلّ التغييرات، يمكن للطرف المُستلِم استخدام ميزة «المقارنة» في Word لمطابقتها بالنسخة المتَّفق عليها سابقاً، فيُكتشَف الإغفال أيضاً. وعند الاتّفاق، طبِّق السجلّ وثبِّت النسخة
3. حدِّد قاعدة ترقيم النسخ: اجعل نسخة الاستلام v1.0، وارفعها إلى v1.1 وv1.2 عند كلّ اتّفاق على تغيير. لا تستخدم «نهائيّ» أو «تعديل» أو «(2)» في اسم الملفّ
4. جمِّد النسخة المتَّفق عليها بصيغة PDF واحفظها لدى الطرفين: بحيث يستطيع أيّ شخص لاحقاً تحديد أيّ نسخة اتُّفِق عليها

أيّاً كانت الأداة، إن دارت هذه النقاط الأربع، يمكن منع أكبر مشكلتين تقريباً: «لا يُعرَف أين تغيَّر» و«لا تُعرَف النسخة المتَّفق عليها». وبعبارة أخرى، الاتّفاق على قواعد التشغيل أهمّ من اختيار الأداة.

6. ما ينبغي للجهة الطالبة التحقّق منه قبل التعاقد

نُلخِّص للجهة الطالبة قائمة فحص بما ينبغي التحقّق منه في مرحلة التقدير والتعاقد.

• هل قائمة المُخرَجات تتضمَّن وثيقة المواصفات والتصميم على مستوى اسم الوثيقة؟ (وليست «مجموعة وثائق»)
• هل يمكن الحصول على أصل قابل للتعديل (ملفّ Word/Excel وغيره)؟ وليس PDF فقط؟
• عند استلام النسخة المُعدَّلة، هل تُعرَض بصيغة يُعرَف منها أين تغيَّرت (سجلّ التغييرات أو قائمة مواضع التغيير)؟
• هل يشمل نطاق عقد الصيانة تحديث الوثيقة عند التعديل؟ وإن لم يكن مشمولاً، هل من المقبول افتراض حدوث تباعد؟
• معاملة حقوق النشر والاستخدام الثانويّ للوثيقة. وهل يمكن تسليمها عند تكليف شركة أخرى بالصيانة مستقبلاً؟
• هل حُدِّد إجراء تغيير المواصفات (سجلّ إدارة التغييرات وطريقة توثيق الاتّفاق)؟

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

7. الأسئلة الشائعة

س1. حدَّدت الجهة الطالبة قالب ورق Excel المُربَّع. هل يجب الالتزام به؟

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

س2. سُلِّمت وثيقة المواصفات بصيغة PDF فقط. هل هذا مقبول؟

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

س3. إلى أيّ درجة من التفصيل ينبغي أن تُكتَب وثيقة المواصفات؟

ليست القاعدة «كلّما زاد التفصيل كان أفضل». فالوثيقة الأكثر تفصيلاً تكون تكلفة تحديثها أعلى، ويسهل تباعدها عن التنفيذ. المعيار التقريبيّ هو أن يكون السلوك محدَّداً بدرجة تكفي لاستخدامها كمعيار للفحص والاستلام، وأن تبقى المعلومات المرجعيّة وقت الصيانة والتعديل (عناصر الشاشة، بنية البيانات، التكامل الخارجيّ، قواعد العمل). أمّا الشرح التفصيليّ للتنفيذ الذي يُفهَم بقراءة الشيفرة، فمن الأفضل تركه في الشيفرة والتعليقات لا في الوثيقة، فذلك لا يتباعد. درجة التفصيل ترتبط مباشرةً بالساعات والمبلغ، لذا يجب الاتّفاق عليها قبل التعاقد.

س4. مَن المسؤول عن تحديث وثيقة المواصفات بعد التسليم؟

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

الخلاصة

نُلخِّص نقاط هذا المقال بخصوص وثيقة المواصفات المُسلَّمة في التطوير التعاقديّ.

• اختر صيغة وثيقة المواصفات المُسلَّمة من منظور الفحص والاستلام وتغيير المواصفات والصيانة، لا وفق «سهولة الكتابة أثناء التطوير» وحدها
• المشكلة الجوهريّة لورق Excel المُربَّع هي تجويف الفحص والاستلام الناتج عن عدم ظهور الفروقات، وفقدان سجلّ الاتّفاق، والتباعد عن التنفيذ بسبب ارتفاع تكلفة التحديث
• الخلاصة ليست «إلغاء Excel كلّيّاً»، بل العودة إلى الأداة المناسبة لكلّ غرض. النصوص بـ Word (الأنماط + سجلّ التغييرات)، والجداول بجدول Excel الأصيل، وسجلّ الاتّفاق بتجميد PDF
• بنية إدارة أصل جانب التطوير عبر Markdown+Git، وتوليد Word/PDF كمُسلَّم، يمكنها الجمع بين ميزتَي الطرفين
• قبل الصيغة، حدِّد في العقد قائمة المُخرَجات، وتسليم الأصل القابل للتعديل، ومعاملة حقوق النشر. الاتّفاق على قواعد التشغيل أهمّ من الأداة

أمّا موضوع قراءة وكتابة Excel من برنامج (إخراج التقارير)، فنتناوله في «كيفيّة صناعة إخراج تقارير Excel - COM/Open XML/القوالب»، وبناء العقد نتناوله في المقال الشارح لنموذج تعاقد وشراء IPA. طالِعهما أيضاً.

لمن يفكِّر في تكليفنا بالتطوير التعاقديّ أو الصيانة

عند تنفيذ التطوير التعاقديّ لتطبيقات Windows للأعمال، تحرص شركة Komura Soft LLC على الاتّفاق مسبقاً مع الجهة الطالبة، وفق الفكر المطروح في هذا المقال، على نطاق وصيغة وتشغيل تحديث وثائق المُخرَجات. كما نستقبل طلبات التحقيق من حالة «توجد وثيقة مواصفات لكن لا يُعرَف إن كانت مطابقة للوضع الحاليّ» في تعديل البرمجيّات القائمة. لا تتردَّدوا في استشارتنا، بما في ذلك تجهيز وثيقة المواصفات ومراجعة صيغة التسليم.

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

حدَّدت الجهة الطالبة قالب ورق Excel المُربَّع. هل يجب الالتزام به؟

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

سُلِّمت وثيقة المواصفات بصيغة PDF فقط. هل هذا مقبول؟

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

إلى أيّ درجة من التفصيل ينبغي أن تُكتَب وثيقة المواصفات؟

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

مَن المسؤول عن تحديث وثيقة المواصفات بعد التسليم؟

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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