كيف يجد مهندس staff المشكلات التي تستحق العمل عليها

نشر مهندس staff يعمل على أداة قياس الأداء Perfetto الإجابة التي يقدّمها لزملائه المستعدّين للترقية حين يسألون كيف يجدون مشكلات تستحق العمل عليها. منهجه ليس ساعة «تفكير استراتيجي» محجوزة في التقويم، جرّبها ورآها غير مثمرة، بل عادة الاستماع بصفاء الإسفنج والسماح للمشكلات بالتراكم.

استوعب المشكلات لا الطلبات

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

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

دع المشكلات تتراكم

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

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

من طلبات الميزات إلى الامتدادات

يعرض Perfetto تسجيلات نشاط النظام على خط زمني من صفوف تسمى tracks. وعلى مدى سنوات طلبت فرق ميزات واجهة ضيقة: إبقاء مسارات فريقهم في الأعلى، وفتح التسجيل مكبّرًا على جزء معين، وعرض تجميع مخصص. بل بنى بعضهم حلولًا ملتوية باستخدام bookmarklets. وخلص الكاتب إلى أن الحاجة الحقيقية ليست ميزة بعينها بل القدرة على توسيع الواجهة دون فرض خيارات فريق واحد على الجميع. كانت الإضافات (plugins) موجودة لكنها تتطلب جعل كود الإضافة كله مفتوح المصدر، وهو ما لم يناسب فرقًا داخلية كثيرة.

ناقش الاقتراح مع مديره وزملائه وفرق العملاء، وكتب مذكرتي RFC، وأجرى لقاءات فردية وقدّم عروضًا، ثم صمّم وأطلق الماكروز كـ«امتدادات خفيفة» بالإضافة إلى extension servers لتشارك الفرق ماكروزها. واليوم تستخدم عشرات الفرق داخل Google الماكروز وextension servers، بينما تستخدم شركات أخرى عدة سيرفرات الامتدادات داخليًا.

لماذا يهم ذلك

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