في تدوينتي السابقة في اليوميات، بعد خمسة أشهر داخل بيئة تنسيق معقدة، كتبت جملة واحدة لم تفارقني منذ ذلك الحين:
لا ينبغي لدماغ المنسق أن يتحول إلى قاعدة بيانات المشروع.
كانت في حينها ملاحظة. كنت قد أصبحت المكان الذي يعيش فيه تاريخ المشروع: أي أصل تعلّقت به أي مشكلة. أي التعليقات حُلّت فعليًا وأيها أُغلقت إداريًا فقط. أي القرارات استندت إلى معلومات معتمدة وأيها كانت افتراضات موروثة. ومن عليه الرد التالي.
نجح ذلك، بمعنى أنني كنت أستطيع في الغالب الإجابة عن السؤال. لكنه فشل بمعنى أهم: إذا كانت الإجابة لا توجد إلا في رأسي، فقد كان للمشروع نقطة فشل وحيدة. وكانت تلك النقطة أنا.
هذه التدوينة عمّا فعلته حيال ذلك. لقد بنيت أداة اسمها b1m.solutions.
المشكلة التي ظللت أصطدم بها
لا تفتقر المشاريع إلى أماكن توضع فيها المعلومات. فهناك منصات تتبّع المشكلات، وبيئات البيانات المشتركة، ومراسلات Aconex، والبريد الإلكتروني، ومحاضر الاجتماعات، ومجموعات WhatsApp، والجولات الميدانية. المشكلة ليست في التخزين. المشكلة أن أيًّا من هذه الأماكن لا يحتفظ بالخيط.
منصة تتبّع المشكلات تسجّل حالة. يمكنها أن تخبرك بأن بندًا ما قد أُغلق. لكنها في الغالب لا تستطيع أن تخبرك بمن أكّد ذلك، وعلى أي أساس، أو ما الذي كان ينتظره قبل ذلك.
محاضر الاجتماعات تسجّل قرارًا. ولا أحد يعود إليها بعد ثلاثة أشهر، حين يتعيّن بصمت أن يسري القرار نفسه على عشرين أصلًا آخر.
تُرسَل الطلبات إلى المقاولين والاستشاريين. وعندما لا يجيب أحد، لا يعود شيء ليذكّرك. يصبح الصمت ببساطة جزءًا من المشروع.
في تدوينتي السابقة وصفت التحول من رؤية التعارض على أنه المشكلة إلى رؤيته كملاحظة:
الشيء الدائم ليس بالضرورة هو التعارض نفسه، بل هو سياق وخيط التنسيق الملتف حوله.
وهذا الخيط تحديدًا هو ما يضيع. لذلك بدأت أبني شيئًا يحفظه.
إذا قُرئ من الأسفل إلى الأعلى، فهذا هو خيط مشكلة واحدة: ملاحظة في الموقع، وقياس، وطلب إلى فريق الأعمال الكهروميكانيكية (MEP)، وجوابهم، وتحققي من أن الجواب استوفى الطلب، وادعاؤهم أنها أُصلحت، وجولة العميل. في معظم المشاريع، تتوزع هذه الأجزاء على خمسة أماكن مختلفة.
ما هو b1m، وما ليس كذلك
أما b1m.solutions فهو ذاكرة تنسيق.
ليس أداة نمذجة، ولا بيئة بيانات مشتركة، ولا يحلّ محلّ منصات تتبّع المشكلات التي يستخدمها المشروع أصلًا. بل يعمل إلى جانبها، ويحفظ ما تميل إلى فقدانه: ما حدث حول المشكلة، بالترتيب، مع الأسباب مرفقةً به.
بنيته لنفسي أولًا. منسق واحد، وأصول كثيرة، ومعظم العمل يجري بعيدًا عن المكتب: في الموقع، وبين الاجتماعات، وعلى الهاتف.
وقد شكّلت بضعة مبادئ كل قرار فيه تقريبًا.
- لا يُكتب فوق أي شيء في السجل. عندما يتغير شيء ما، تبقى النسخة السابقة في السجل التاريخي (History)، مع بيان من غيّرها ومتى. وعندما يُسجَّل شيء بعد وقت من حدوثه، يذكر السجل ذلك.
- الادعاء ليس تأكيدًا. فهما حدثان مختلفان، والأداة تتعامل مع كل منهما بطريقة مختلفة.
- القرار يحمل أساسه. من قرّر، ومتى، وأين سُجّل، وإلى أي مدى يسري.
- ما تنتظره يعود إليك. الصمت يُبرَز، ولا يضيع.
تعرض لقطات الشاشة أدناه مشروعًا متخيَّلًا. أما المشروع الحقيقي فيعود إلى أحد العملاء.
الادعاء لا يعني التأكيد
في مقالتي عندما يسبق التنسيق الوضوح ذهبت إلى أن الإغلاق الإداري والحل الفني ليسا الحدث نفسه. فتحديث النموذج، ورفع الملف، وإغلاق المشكلة لا تُثبت، بحد ذاتها، أن شيئًا قد حُلّ.
لذلك فإن «أُبلغ عن الإصلاح» (Reported fixed) في b1m حالة قائمة بذاتها. عندما يقول مقاول إن مشكلة ما قد أُصلحت، يُسجَّل ذلك على حقيقته: ادعاء، من شخص ما، في تاريخ ما. وتبقى المشكلة موسومةً بوضوح بعبارة «لم يُؤكَّد بعد» (not yet confirmed) حتى يصل التأكيد فعلًا.
عند تسجيل حلّ المشكلة، يُطرح سؤال واحد لا تطرحه معظم أنظمة التتبّع أبدًا: كيف نعرف؟ التأكيد يأتي من مدير BIM، أو فريق الموقع، أو فريق التصميم، أو عبر نموذج معتمد، أو قرار اجتماع، أو تقديم معتمد، مع المرجع إلى جانبه حيثما وُجد: البريد الإلكتروني، أو بند المحضر، أو مراجعة النموذج.
ينبغي للمشكلة المحلولة أن تكون قادرة دائمًا على الإجابة عن السؤال: كيف نعرف؟
القرارات تحمل أساسها، ومدى سريانها
تُتخذ معظم قرارات التنسيق في الاجتماعات وورش العمل والمكالمات. ومعظمها يُعاد بناؤه لاحقًا من الذاكرة.
في b1m يُسجَّل القرار مع سبب اتخاذه، ومن اتخذه، ومتى، وأين دُوِّن (المحضر، أو البريد الإلكتروني، أو طلب المعلومات RFI)، وأي قرار سابق يحلّ محله إن وُجد. القرار السابق لا يختفي، بل يُوسَم بأنه استُبدل، ويبقى الاثنان قابلين للقراءة.
وعلّمني العمل عبر أصول كثيرة متكررة درسًا ثانيًا أيضًا، وصفته بأنه الفرق بين ما يجب حله مرة واحدة كقاعدة عامة وما يجب أن يظل معالجًا وفقًا لخصوصية كل حالة. فالقرار المتخذ في مشكلة واحدة كثيرًا ما يتبيّن أنه يسري في كل مكان. لذلك يمكن وسم القرار بأنه يسري على المشروع كله، ويمكن تسجيل أصل بعينه كاستثناء، مع ذكر السبب.
الغاية ليست البيروقراطية. الغاية أن يتمكن أحدهم، بعد ستة أشهر، من فتح السجل وفهم لماذا يبدو النموذج على ما هو عليه، دون أن يضطر إلى البحث عن الشخص الذي يتذكر.
ما تنتظره يعود إليك
جزء كبير من التنسيق هو الانتظار. انتظار مسار معدَّل، أو توضيح، أو موافقة، أو تحقق في الموقع.
في b1m، يسجّل كل طلب ما هو مستحق، وعلى مَن، ومنذ متى. لا يرسل b1m أي شيء بنفسه؛ بل يتذكر ما طلبته، وممّن طلبته. وإذا لم يُجب أحد، يطرح الموجز (Briefing) ذلك بكلمات واضحة، كأن يذكر أنه لم يصل أي رد منذ عشرة أسابيع. وعندما يتوقف الرد على اجتماع، يذكّرني b1m بعد انقضاء الاجتماع بأن أسجّل ما حُسم فيه.
أصبح تذكير الاجتماع هذا من أكثر الميزات التي أعتمد عليها. فهو عادةً ما يدفعني إلى تدوين ما دار في الاجتماع قبل أن يتلاشى.
يذكر كل بند في الموجز سبب وجوده فيه. لا شيء يُرتَّب وفق درجة لا أستطيع تفسيرها. إذا كان شيء ما يحتاج إلى انتباه، فالسبب مكتوب بجانبه.
العثور على الشذرة
الذاكرة لا تعود على هيئة رقم سجل. بل تعود على هيئة شذرة: أحدهم أكّد مسافة الخلوص في الموقع، قبل بضعة أسابيع، على ما أظن.
لذلك يبحث b1m في كل ما قيل: التحديثات، والردود، والقرارات، والمذكّرات، والملاحظات، بما في ذلك السجل التاريخي. وتعرض النتيجة الكلمات كما كُتبت، ومن قالها ومتى، وتفتحها في موضعها من الخيط.
مصمَّم للهاتف، وللتقدير الشخصي
يجري معظم عملي التنسيقي بعيدًا عن المكتب، لذلك لم يكن الهاتف يومًا أمرًا ثانويًا.
يمكن التقاط الملاحظات في الموقع خلال ثوانٍ، مع الصور، وفرزها لاحقًا. والكتابة غير المكتملة لا تضيع إذا أغلق الهاتف التطبيق في منتصف جملة. والمراسلات التي ليست مشكلة (مكالمة، أو رسالة، أو محادثة في الموقع) يمكن حفظها كمذكّرة وربطها بالأصول والمشكلات التي تتعلق بها.
وهناك شيء واحد أبقيته عمدًا خارج السجلات: تقديري الشخصي لما يهم اليوم. فاجتماع واحد قد يعيد ترتيب يوم كامل في ساعة. وما يهم عادةً هو مدى حرج الأمر ومدى إلحاح العميل عليه. لذلك أستطيع أن أضع على مشكلة أو مهمة علامة «ما يهم الآن» (Matters now)، مع سبب إن كان ذلك مفيدًا (العميل يضغط، أو الأمر يعطّل العمل، أو حان موعد تقديم)، فتتصدّر الشاشة الرئيسية. وتُظهر العلامة منذ متى وُضعت، فيسهل رؤية الأولوية التي تقادمت. ولا تصبح أبدًا جزءًا من السجل التاريخي، لأن الأولوية ليست حقيقة عن المشروع.
ما تعمّدتُ ألّا يفعله
لا يقرر أي شيء. لا يغلق المشكلات نيابةً عني. لا يستنتج أن شيئًا ما قد اعتُمد. ولا يحوّل الادعاء إلى حل.
وترتبط هذه النقطة الأخيرة بحجة طرحتها في مقالتي المستوى التالي من نضج BIM. فمع بدء مساعدي الذكاء الاصطناعي بالمشاركة في التنسيق، تزداد أهمية السجل الذي يعملون انطلاقًا منه، لا تقل. يستطيع المساعد قراءة سجلات b1m عبر موصِّل (connector) أمنحه أنا الصلاحية. وإذا سمحت له، يمكنه أن يضيف شيئًا واحدًا: ملاحظة يسألني عنها أولًا، ثم أفرزها أنا بنفسي. لا يستطيع أن يحلّ أو يغلق أو يعدّل أو يحذف أي شيء، ولا يستطيع أن يعيد في الخفاء كتابة السجل التاريخي الذي يقرؤه. وإذا كانت مبررات المشروع المنطقية ستقرؤها الآلات، فالأجدر أن تُكتب كما ينبغي أولًا.
لكي يتطور المشروع بأمان، يجب أن تكون مبرراته المنطقية دائمة وراسخة مثل هيكله المادي.
فكرة ختامية
لم يبدأ b1m كفكرة منتج. بل بدأ بإدراك غير مريح: أنني أصبحت ذاكرة المشروع، وأن المشروع الذي يعتمد على ذاكرة شخص واحد هشّ، مهما كانت تلك الذاكرة قوية.
النموذج يُظهر ما هو موجود. ومنصات تتبّع المشكلات تُظهر ما هو مفتوح. أما ما أردته فهو شيء يحفظ السبب: لماذا تغيّر شيء ما، ومن أكّده، وماذا كان ينتظر، وما الذي تقرّر على طول الطريق.
لا ينبغي أن يعتمد المشروع على أي شخص بعينه ليتذكّر السبب. بل ينبغي أن يكون قادرًا على أن يخبرك به بنفسه.