قضيت شهوراً في بناء جداول المقارنة قبل أن أدرك أن قاعدة بياناتي كانت تخدعني.

كانت الواجهة تبدو جيدة. صفوف نظيفة، علامات صح مرتبة، وعلامات X حمراء حيث قصرت إحدى الأدوات. كان الزوار يتصفحونها وينقرون عليها أحياناً. ولكن تحت السطح، كان المخطط (schema) يفسد كل استنتاج بهدوء. لقد بنيت واجهة مستخدم جميلة فوق بيانات سيئة.

فخ القيم المنطقية (The Boolean Trap)

تبدأ صفحات المقارنة عادةً بنمط واضح. تقوم بإنشاء شبكة حيث تكون الصفوف هي الميزات، والأعمدة هي المنتجات، وكل خلية تحتوي على قيمة منطقية (boolean). "True" تعني أن الأداة تمتلك الميزة، و"False" تعني أنها لا تمتلكها. لفترة من الوقت، يبدو هذا وكأنه نظام. ثم تحاول مقارنة أداتين لإدارة المشاريع، أو ثلاث قواعد بيانات سحابية، أو أربع بوابات API، فتبدأ الشبكة في التمرد.

لا يمكن للخلايا المنطقية حمل الفروق الدقيقة. عندما تقرأ الخلية "false"، فقد يعني ذلك خمسة أشياء مختلفة تماماً. ربما تفتقر الأداة حقاً إلى هذه القدرة. ربما تحل نفس المشكلة من خلال آلية مختلفة. ربما الميزة موجودة ولكنها خلف جدار دفع للمؤسسات (enterprise paywall). ربما تتطلب إضافة (plugin) لم تلاحظها. أو ربما نسيت ببساطة التحقق منها، وتكون علامة X الحمراء مجرد مكان محجوز لعدم يقينك الخاص.

هذا الأمر مهم لأن المستخدمين يثقون في جداول المقارنة لاتخاذ قرارات مكلفة. عندما تضع علامة على أداة تعتمد على واجهة سطر الأوامر (CLI) بأنها تفتقر إلى التعاون في الوقت الفعلي، فقد تقصد أنها لا تدعم مشاركة المؤشر المباشر. لكن تلك الأداة نفسها ربما تستخدم سير عمل يعتمد على الفروع (branch-based workflows) وطوابير المراجعة لتحقيق النتيجة نفسها تماماً. وضع علامة "false" يحول خياراً تصميمياً إلى عيب. افعل ذلك عبر عشرين ميزة، ولن تكون قد قارنت بين أداتين، بل ستكون قد أعلنت أن إحداهما معطلة.

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

مفردات أفضل للحالة

يبدأ الحل من نوع البيانات نفسه. توقف عن تخزين القيم المنطقية (booleans). قم بتخزين حقل حالة (status field) بمفردات صريحة.

فكر في هذه الحالات الست.

Full تعني أن الأداة تؤدي المهمة دون الحاجة إلى حلول بديلة أو مشتريات إضافية.

Partial تعني أنها تتعامل مع بعضها، أو تتعامل معها فقط بعد تكوين شيء غامض. هنا يكمن معظم عدم الدقة في المقارنات. الأداة التي توفر التشفير ولكن فقط أثناء السكون (at rest) تستحق وصف Partial، وليس Full.

Different Model تعني أن المشكلة تُحل، ولكن ليس بالطريقة التي يحلها بها رائد الفئة. أداة الـ CLI التي تستخدم الفروع والمراجعات تنتمي إلى هذه الفئة. وكذلك قاعدة البيانات التي تستخدم نسخ القراءة المتماثلة (read replicas) بدلاً من اتصال مجمع واحد. تحافظ هذه الحالة على ذكاء تصميم المنتج بدلاً من معاقبته لأنه لم ينسخ المنافس.

Not Applicable تعني أن المفهوم نفسه لا ينطبق على هذا النوع من الأدوات. منصة الوظائف عديمة الخادم (serverless function platform) لا تحتاج إلى تخزين محلي دائم كما تفعل الآلة الافتراضية (virtual machine). فرض قيمة "false" هنا هو خلط في الفئات.

Absent تعني أنك بحثت، والقدرة مفقودة حقاً. لا يوجد حل بديل، ولا إضافة، ولا سير عمل بديل. الفجوة حقيقية.

Unknown تعني أنك لم تتحقق منها.