كنا نعرف ذلك قبل أن نبدأ.

ما قيل لنا

طلبت منا شركة المساعدة في تحسين تنظيم تطوير البرمجيات لديها.

قبل بدء المشروع، التقينا بالرئيس التنفيذي ورئيس قسم التطوير لمناقشة الجوانب التي يمكننا المساعدة فيها.

وقيل لنا أيضًا إن صلاحيات الوصول والأذونات اللازمة للعمل ستُمنح فورًا.

من الناحية النظرية، لم تكن هناك مشكلة في الوصول.

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

ما لاحظناه

اقترح الرئيس التنفيذي في البداية إشراكنا في مشروع قائم يحتاج إلى تحسين.

أوضح رئيس قسم التطوير سبب عدم جدوى ذلك: كان للمشروع بالفعل موعد إطلاق محدد.

اقترح الرئيس التنفيذي مشروعًا آخر. لم يكن لهذا المشروع موعد إطلاق محدد.

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

كان بإمكان كلا الاعتراضين، على حدة، أن يكونا معقولين تمامًا.

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

هذه المرة، جاء الرد إيجابيًا.

بدا ذلك واعدًا.

فطرحنا سؤالًا.

هل كان هناك نهج تطوير مشترك في المؤسسة، أم أن كل مهندس كان حرًا في تحديد طريقة عمله؟

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

ثم طرحنا على رئيس قسم التطوير سؤالًا افتراضيًا:

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

كانت الإجابة لا.

كانت لتلك الإجابة أهمية.

لكن النمط كان أكثر أهمية.

النمط

في كل مرة كان الرئيس التنفيذي يقترح فيها طريقة لمساهمتنا، كان رئيس قسم التطوير يوضح لماذا لن تنجح.

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

كانت هناك إشارة أخرى.

لم يُقترح أي بديل.

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

كانت الاعتراضات الفردية بمثابة بيانات.

وكان النمط المشترك بينها دليلًا على شيء أكبر.

فرضيتنا

لم تكن المشكلة في المشروع أ.

ولم تكن في المشروع ب.

ولم تكن في الشكل المحدد لتحسين الإنتاجية الذي كان محل النقاش.

كانت فرضيتنا أن تنظيم التطوير لم يكن، في الواقع، يقبل أي تدخل خارجي.

إذا كانت هذه الفرضية صحيحة، فلن تنتهي المشكلة بمجرد تحديد العمل الذي ينبغي علينا القيام به.

فبمجرد بدء المشروع، ستظهر المقاومة نفسها في كل ما يلزم لإنجاز ذلك العمل — بما في ذلك الوصول إلى الأنظمة والمعلومات والأذونات.

لذا، قبل بدء المشروع، توقعنا أن الحصول على الصلاحيات اللازمة للعمل بفعالية سيصبح مشكلة.

لماذا مضينا قُدمًا رغم ذلك

في الظروف العادية، كان هذا سيمثل سببًا كافيًا لرفض المشروع.

وكنا ننوي فعل ذلك.

لكن القرارات التجارية يتخذها بشر، لا خوارزميات تحسين.

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

لذا مضينا قدمًا رغم الخطر الذي حددناه.

ما أظهرته الأدلة

بعد بدء المشروع، أصبحت صلاحيات الوصول والأذونات التي قيل لنا إنها ستُمنح فورًا عائقًا كبيرًا.

تحقق ما توقعناه.

لكن هذا لم يكن تمرينًا في كشف الكذب.

لم نكن بحاجة لتحديد ما إذا كان أحدهم قد أدلى عن علم بتصريح غير صحيح. فمن الممكن أن يكونوا قد اعتقدوا فعلًا أن الصلاحيات اللازمة يمكن توفيرها فورًا.

لأغراضنا، لم تكن النية ذات أهمية.

كان التصريح بمثابة بيان واحد من البيانات.

وكان السلوك الذي لاحظناه خلال ذلك النقاش نفسه بيانًا آخر.

وعندما أشارت تلك البيانات إلى اتجاهات مختلفة، صُغنا فرضية حول ما سيحدث فعليًا — وانتظرنا أدلة ملموسة تؤكدها أو تدحضها.

ما قاله الناس كان بيانًا واحدًا. وكيف تصرفوا وهم يقولونه كان بيانًا آخر.

وجهة نظر Pulsar

يحدث معظم عملنا بعد ظهور المشكلة بالفعل. لكن هذه الحالة كانت مختلفة.

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

كان بالإمكان أن يكون التوقع خاطئًا. لم يكن مضمونًا في اللحظة التي صُغناه فيها.

وما جعل ذلك ممكنًا هو التعامل مع الإشارة السلوكية كدليل قائم بذاته، لا كهامش لما قيل.

الفرضية التي تتأكد لاحقًا ليست حظًا. إنها ما يحدث عندما تتعامل مع السلوك كبيانات قبل أن تُضطر إلى ذلك.