تخيل معي المشهد… غرفة اجتماعات “مقفولة” في شركة سعودية.
وجوه متجهمة. مدير المنتج ماسك اللابتوب كأنه درع. مدير المالية يتنفس بصعوبة من كثر ما انضغط. فريق التطوير صامت… مو لأنهم ما عندهم حلول، لكن لأنهم تعِبوا من التغييرات اللي ما تخلص.
العميل على الطرف الثاني من الطاولة يقولها بصوت واضح:
“المشروع تأخر 6 شهور… الميزانية خلصت… وأنا ما شفت شي يشتغل فعلاً!”
الكل يلتفت تلقائياً للـ Developer Lead… وكأن المشكلة “كود”.
بس الحقيقة؟ غالباً البرمجة كانت آخر شي انهار.
اللي انهار قبلها بكثير هو: إدارة الفوضى.
أنا كمدير مشاريع تقني (PMP) شفت سيناريوهات كثير في السوق السعودي: مشاريع تطبيقات، ERP، بوابات خدمات، أنظمة مبيعات، منصات داخلية… نفس النهاية تتكرر، وبنفس الكلمات:
“ما حسبناها صح… المتطلبات كانت تتغير… ما كان فيه توثيق… الأمن عطّلنا…”
خلّنا نفككها بهدوء — لأن هذا المقال هدفه مو يجلدك، هدفه يطبطب على الجرح ويعطيك خطة “تقومك” من أول أسبوع.
أولاً: “70% تفشل” لأن المشروع بدأ غلط… من يومه الأول
أغلب المشاريع التقنية اللي تتعطل في المملكة ما تتعطل لأن الفريق ما يعرف يبرمج.
تتعطل لأن البداية كانت “وعود” أكثر من كونها “نظام إدارة”.
ما فيه وثائق واضحة (Scope / Requirements / Acceptance Criteria)
ما فيه خط أساس للوقت والتكلفة (Baseline)
ما فيه إدارة مخاطر حقيقية (Risk Register)
الأمن السيبراني ينذكر متأخر… بعد ما تبني نصف النظام
العميل يغيّر رأيه… والفريق يقول “حاضر” بدون ضبط نطاق
النتيجة؟
مشروع يمشي شهرين كويس… بعدين يبدأ ينزف.
مو فجأة، لكن بشكل تدريجي… إلى أن توصل لاجتماع “غرفة متوترة” مثل اللي فوق.
1) غياب التوثيق: لما كل شيء يصير “بالذاكرة” بدل ما يكون “بالورق”
في مشاريع كثيرة، التوثيق يُعامل كأنه رفاهية.
الواقع؟ التوثيق هو صمّام الأمان الوحيد لما تتوتر الأمور.
بدون توثيق واضح:
ما تقدر تثبت “مين طلب إيش ومتى”
ما تقدر تمنع اختلاف التوقعات
ما تقدر تحاسب على التأخير بدقة
وما تقدر تحمي الفريق من الارتباك
التوثيق مو أوراق زيادة.
التوثيق يعني: “نحط الواقع على الطاولة… بدل ما كل واحد يتخيل مشروع مختلف.”
أبسط أمثلة التوثيق اللي تنقذ مشاريع:
وثيقة نطاق (Scope Statement) مختصرة وواضحة
User Stories + Definition of Done
محاضر اجتماعات رسمية (Minutes of Meeting)
قرارات معتمدة (Decision Log)
2) الزحف في النطاق (Scope Creep): “بس أضفوا هالميزة…” اللي تقتل المشاريع
أشهر جملة سمعتها من العملاء ومن داخل الشركات:
“هي بسيطة… بس أضفوها”
المشكلة مو في الميزة… المشكلة في “طريقة دخولها”.
لما ما عندك Change Control واضح، كل “بس” تصير:
أسبوع إضافي
ثم أسبوع ثاني
ثم ميزانية إضافية
ثم اختلاف في الأولويات
ثم فوضى في الاختبارات
ثم انهيار الجدول بالكامل
نصيحة PMP ذهبية:
أي تغيير لازم يمر بثلاث أسئلة قبل الموافقة:
كم بيزيد الوقت؟
كم بيزيد التكلفة؟
إيش بنشيل مقابله؟ (Trade-off)
إذا ما قدرت تجاوب… لا توافق.
3) تجاهل الأمن السيبراني والامتثال: سبب “التوقف المفاجئ” اللي ما أحد يحسب حسابه
هنا نجي للسبب اللي كثير يتجاهله… وبعدين يتفاجأ أن المشروع توقف فجأة.
في السوق السعودي اليوم، موضوع الأمن السيبراني والامتثال ما عاد خيار.
خصوصاً مع متطلبات الجهات والحوكمة والأنظمة الداخلية، والالتزام بضوابط مثل ضوابط الهيئة الوطنية للأمن السيبراني (NCA) في بيئات كثيرة.
وش يصير لما الأمن يجي متأخر؟
تكتشف أن التصميم يحتاج إعادة هيكلة (Access Control / Logging / Encryption)
تكتشف أن صلاحيات المستخدمين فوضى
تكتشف أن بيئة الاستضافة ما عليها Controls واضحة
تكتشف أن فيه فجوات امتثال تمنع الإطلاق (Go-Live)
وفجأة… المشروع يتوقف “لين نضبط الأمن”
وهنا تبدأ الدوامة:
“خل نعدّل… خل نراجع… خل نسوي تدقيق…”
والعميل يسمع كلمة واحدة: “تأخير”.
الدرس الكبير:
الأمن السيبراني إذا ما دخل من يوم 1، غالباً بيدخل عليك في يوم 180… بس وهو مكلف ومؤلم.
عشان مشروعك ما يوقفش بسبب مخالفة ضوابط الأمن السيبراني، استخدم أدوات تساعدك تلتزم من أول يوم — مثل NCA Dashboard Pro:
https://digitalmindsimplified.com/nca-product-final_updated.html
(الفكرة مو تشتري أداة وخلاص… الفكرة إنك تربط مشروعك من البداية بمؤشرات واضحة للامتثال بدل ما تكتشف الفجوة متأخر.)
4) إدارة المخاطر “على الورق” فقط… بينما الواقع يمشي بدونك
في كثير مشاريع، المخاطر تُكتب أول أسبوع وبعدين تُنسى.
بينما المخاطر الحقيقية تمشي يومياً:
اعتمادك على شخص واحد (Bus Factor)
مورد خارجي متأخر
متطلبات تتغير من عدة جهات
بيئة تشغيل غير جاهزة
تكاملات (Integrations) غير مستقرة
تدقيق أمني قادم… وما أحد مستعد
إدارة المخاطر لازم تكون أسبوعية ضمن روتين المشروع:
تحديث Risk Register
تقييم الاحتمالية والأثر
خطط استجابة واضحة (Mitigation / Contingency)
مالك لكل خطر (Risk Owner)
طيب… كيف “تدير الفوضى” بدل ما تتفاجأ فيها؟
هنا الزبدة. وهذا الجزء اللي أبيك تحفظه.
1) ابدأ بـ “تعريف نجاح واضح” قبل ما تبدأ بكود واحد
ما هو تعريف النجاح؟
ما هي مؤشرات القبول؟
ما هو “الحد الأدنى المقبول” للإطلاق؟
إذا ما اتفقتم عليها… كل واحد بيقيم المشروع بمزاجه.
2) وثّق بطريقة ذكية وخفيفة (لا تعقّدها)
وثّق ما تحتاجه للتنفيذ والقرار والمحاسبة فقط:
Scope مختصر
Backlog واضح
محاضر قرارات
مخاطر أسبوعية
3) استخدم Agile صح… مو كاسم
Agile مو يعني “بدون خطة”.
Agile يعني:
خطة قصيرة تتحدث باستمرار
تسليم تدريجي
Feedback سريع
وشفافية كاملة
أدوات مثل Sprint Planning + Review + Retrospective
تخلي الفوضى “مرئية” وتحت السيطرة.
4) “Change Control” محترم… حتى لو بسيط
خلك لطيف لكن واضح:
“أكيد نقدر نضيف”
“بس نحتاج نحدد تأثيرها ونعدّل الجدول”
العميل ما يكره النظام… العميل يكره المفاجآت.
5) الأمن والامتثال يدخلون من البداية (Security by Design)
سوها كقائمة فحص من أول أسبوع:
صلاحيات وأدوار (RBAC)
سجلات تدقيق (Audit Logs)
تشفير بيانات حساسة
سياسات كلمات مرور
مراجعة الاستضافة والنسخ الاحتياطي
متطلبات امتثال واضحة
ولو تبغى تختصر الطريق وتخلي الالتزام “مرئي” طول عمر المشروع، استخدم لوحة تساعدك تتابع الضوابط من البداية:
https://digitalmindsimplified.com/nca-product-final_updated.html
الخلاصة: البرمجة تبني… لكن إدارة الفوضى هي اللي “تحمي البناء”
إذا كنت مدير مشروع أو صاحب قرار، لا تسأل فقط:
“كم باقي ونخلص؟”
اسأل السؤال الأهم:
“هل مشروعنا تحت السيطرة؟ ولا إحنا بس نركض ورا الأحداث؟”
المشاريع التقنية في المملكة ما تحتاج عباقرة كود بقدر ما تحتاج:
توثيق محترم
نطاق مضبوط
مخاطر مُدارة
وأمن/امتثال من اليوم الأول
وقتها… الغرفة المتوترة تتحول لغرفة “إنجاز”.