برنامج إدارة المجمعات السكنية: من مواصفات بمئات البنود إلى خطة السبرنت

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

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

نبذة موجزة عن المشروع

برنامج إدارة المجمعات السكنية منصة تشغيلية طوّرناها لعميل يدير عددًا كبيرًا من المجمعات السكنية المتباينة تحت مظلة مؤسسية واحدة. وتتكوّن من لوحة تحكم إدارية على الويب وتطبيقات جوال للسكان والفرق الميدانية والمديرين. وتعمل وحدات الطلبات والشكاوى، والأعطال والصيانة وأوامر العمل، ورسوم الخدمة والمالية، وحجز المرافق المشتركة، والزوار، والطرود، والإعلانات، والمخزون، والعدادات على العمود الفقري نفسه من البيانات. وتتصل الأنظمة الخارجية، مثل ERP والمحاسبة، ونظام POS البنكي، والفاتورة الإلكترونية، والرسائل القصيرة SMS، وعدادات IoT، والتعرف على لوحات السيارات، عبر طبقة تكامل منفصلة.

من بند المواصفات إلى معيار القبول

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

• أي بند من بنود المواصفات يقابله وفي أي مرحلة يندرج،
• قواعد العمل والسيناريوهات الرئيسية والاستثناءات،
• حقول البيانات ومتطلبات الشاشات والتبعيات،
• معايير القبول والنقاط المفتوحة والافتراضات.

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

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

ترك كل مرحلة جاهزة للتي تليها

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

وكان من أنفع أجزاء الخطة قائمة «المجالات الخارجة عن نطاق المرحلة والمرتبطة بها» الموجودة في وثيقة كل مرحلة. ففي المرحلة الأولى لم تكن تُسلَّم أنظمة العبور المعتمدة على العتاد، ولا التدفق الكامل للتكاملات المالية، ولا بيانات العدادات؛ لكن نموذج البيانات والمعمارية بُنيا مع أخذ هذه المجالات في الحساب. وعندما جاء التعرف على لوحات السيارات في المرحلة الثالثة، كان الأساس الذي يربط معلومات المركبة بالبنية المادية في مكانه منذ المرحلة الأولى.

وطبّقنا المنطق نفسه على الأنظمة الخارجية. فقد كان البنك والفاتورة الإلكترونية وERP والتعرف على لوحات السيارات وأجهزة العدادات تدخل الخدمة وفق جداول زمنية مختلفة. ولأننا ربطنا التكاملات عبر طبقة محوّلات منفصلة لا تمس قواعد العمل، لم يؤخر تأخر أحد التكاملات المنتج. وتُدار مفاتيح API وحالات الخدمات من لوحة التحكم أيضًا؛ ولكل اتصال، مثل البنك أو ERP، مفتاحه الخاص، ويُحفظ في السجل في أي مجمعات وبأي نطاقات يُستخدم.

الأمان من القاعدة، والفروق مكتوبة

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

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

ما تعلّمناه في الميدان

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

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

كيف يمكن أن تتحول مواصفاتكم إلى خطة؟

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