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