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

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

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

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

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

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

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

وزرّان يؤديان عملين مختلفين لا ينبغي أن يتشابها. فإن جعلتهما متطابقين، ساء أحدهما في أداء وظيفته.

ومن Cervello جاء هذا. فأكثر من نوع واحد من الناس يبني على المنصة: صاحب عمل يفهم الـ IoT، ومطور، ومصمم. والـ UI Builder في معظمه drag and drop، وإن كان فيه جزء كود، فالوصف الأمين أنه almost zero-code لا zero-code. والـ Reports أقرب إلى العالم الذي يعمل فيه صاحب الأعمال أصلًا. وهما لا يتشابهان، وذلك كان المقصود. فالنظام نفسه مفتوح لموظف أعمال، ومطور، وشخص في الحسابات، وآخر في الموقع، والصفحة تتبع وظيفتها هي لا شكل الصفحة المجاورة لها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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