knowcap.ai / blog / why-odoo-projects-fail-in-the-meeting-not-the-code-ar
odoo-partnersodooodoo-partnersodoo-implementation

لماذا تفشل مشاريع برنامج اودو في الاجتماع لا في الكود

2026-06-156 min read

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

أين يُتَّخذ قرار مشروع برنامج اودو فعلياً

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

لماذا يربح نزاع النطاق دائماً

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

لماذا لا تلتقط أدواتك لحظة الاتفاق

نوعان من الأدوات يحضران في معظم عمليات التطبيق، ولا يلتقط أيٌّ منهما القرار. أدوات المشاريع — الخطة في جدول، والمهام داخل اودو نفسه، ووثيقة المتطلبات في درايف — تخزّن المُخرَج، لا لحظة الاتفاق عليه. يجلس المتطلَّب في خانةٍ بلا أيّ رابطٍ بالمحادثة التي التزم فيها العميل به فعلاً. وأدوات تسجيل الاجتماعات تلتقط الصوت وتنتج ملخّصاً، لكن الملخّص أفضل تخمينٍ من النموذج لِما كان مهمّاً، لم يؤكّده أحد. وفي اللحظة التي يصبح فيها المتطلَّب مسألةً تعاقدية، يصير الملخّص غير المؤكَّد بلا قيمة — فهو تفسير آلةٍ واحدة، لا شيءٌ وضع العميل اسمه عليه. وهكذا يبقى الشريك مع أداتين تفشلان عند نقطة الخلاف تماماً: خطةٌ لا تقول من وافق، ونصٌّ يثبت أن كلماتٍ قيلت لا أن أحداً قرّر أنها مهمّة. ولمن يريد الأساس أولاً — كيف يُكتب محضر الاجتماع نفسه والعناصر التي يجب أن يتضمّنها — هناك نموذج محضر اجتماع جاهز مع شرح خطوة بخطوة.

ما الذي يتغيّر حين يؤكّد كلَّ متطلَّبٍ إنسانٌ مُسمّى

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

كيف يبدو ذلك في مشروع اودو بالمنطقة

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

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

لماذا تفشل مشاريع اودو إذا كان البرنامج يعمل؟

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

أليست وثيقة المتطلبات الموقَّعة كافية؟

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

كيف يختلف هذا عن ملاحظات الاجتماع التي نكتبها أصلاً؟

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

هل يساعد هذا في طلبات التغيير وفي تحصيل أجر النطاق الإضافي؟

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

هل علينا تأكيد كلّ متطلَّب؟

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

مشروع برنامج اودو المبنيّ على الذاكرة نزاعٌ ينتظر شرارة. أمّا المبنيّ على قراراتٍ مؤكَّدة فيجيب عن السؤال قبل أن يضطرّ العميل إلى طرحه.

AI that only acts on truth.

Capture the work. Confirm the claims. Let agents act on what’s verified.

Start Verifying →