بناء طريقة العمل التي احتاجها المنتج — مبادئ مكتوبة نقرر بها، ونظام تصميم نبني منه، وصيغة توثيق تبقى مع الميزة بعد إطلاقها.

الفصلان قبله يصفان ما صُمم. وهذا الفصل يصف كيف، وهو الجزء الذي عاش بعد المنتج بالنسبة لي شخصيًا: فكل ما أفعله اليوم في العمل المصرفي المنظّم بدأ كعادة تكوّنت هنا.

كُتبت في البداية، لتحسم الخلافات قبل أن تقع. اثنان منها عاديان، واثنان يتخذان موقفًا حقيقيًا.

Seamless — بلا تسرّب. صمّم الرحلة كقمع لا ثقوب فيه — كل خطوة تؤدي إلى موضع، ولا شيء ينتهي إلى طريق مسدود.

Defensive design — التصميم الدفاعي. ابحث دائمًا عما يمكن أن يسوء، بدل أن تصمم المسار الذي ينجح فيه كل شيء فقط.

Security Over Usability — الأمان قبل سهولة الاستخدام. حين تهم التجربة، يكون الأمان هو الهدف، والتصميم السهل هو الطريق إليه. وفي منصة ستتحكم لاحقًا في أجهزة مادية، لا تساوي شاشة أسلس شاشة أضعف أمانًا. وهذا المبدأ هو ما أنتج قرار التسجيل في الفصل السابق — رفض تأكيد ما إذا كان بريد مسجلًا، على حساب تيسير صغير.

Context Over Consistency — السياق قبل الاتساق. من الأفضل أن تكون صائبًا لا متسقًا. وهذا المبدأ أدافع عنه أكثر من غيره. فالاتساق وسيلة لا غاية — ومعاملته كغاية تنتج واجهات خاطئة بانتظام. وحين يختلف الموقف فعلًا، ينبغي للتصميم أن يختلف معه.

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

قبل أن يُرسم شيء، كانت كل ميزة تُكتب كـ idea card: المشكلة، والقيمة المقترحة، والقدرات المطلوبة، و— وهو الجزء الذي يُتجاوز عادةً — قيودها وحدودها، مذكورة من البداية.

وتسمية ما لن تفعله الميزة في لحظة اقتراحها هي ما يمنع اكتشاف النطاق في منتصف بنائها.

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

التسليم لم يكن إلقاء ملفات. فقد جُرّد التصميم البصري إلى مكونات، ورُتّبت في ثلاث مجموعات صريحة:

١. مكونات قائمة — مبرمجة بالفعل في نظام التصميم؛ يُشار إليها وتُعاد الاستفادة منها.

٢. مكونات جديدة — تحتاج بناءً فعليًا.

٣. دليل أنماط عام — القواعد السارية على كل شيء.

وقيمة هذا الترتيب أنه يجعل التكلفة مرئية قبل التقدير. فالمهندس الذي يقرأه يعرف فورًا ما هو تجميع وما هو بناء — بدل أن يكتشف ذلك في منتصف الـ sprint.

هذا أكثر ما أعتز به في المنهج، لأنه ليس مخرجًا — بل صيغة.

لكل ميزة مستند واحد يتبعها من أول فكرة إلى ما بعد الإطلاق. ثلاثة عشر قسمًا:

ملخص · تعريف المشكلة · البيرسونا المستهدفة · الحل · القيمة · التحقق · الوصف · كيف يعمل · السيناريوهات · المتطلبات القبلية والبعدية · معايير القبول · توثيق الـ API

وكل تكرار يُضاف كـ thread داخل المستند نفسه، لا كملف جديد.

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

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

توثيق من طبقتين، ومبادئ تحسم الخلافات بدل أن تزين عرضًا تقديميًا، ومكتبة مكونات مرتبة بحسب تكلفة البناء، وسجل يحفظ سبب كل قرار — كل ذلك بدأ هنا، في منتج موجه للمطورين.

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

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