CTO as a Service

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

تعريف الدور ومعايير الملاءمة

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

ماذا يشمل هذا العمل

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

العناية التقنية الواجبة وتحديد الوضع الراهن

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

سجل القرارات المعمارية والتسبيب

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

اختيار التقنية وتقييم الموردين

السؤال في الاختيار ليس أي التقنيات أفضل، بل ما ثمن الخطأ. وثلاثة معايير تحسمه: من يتولى الصيانة بعد التسليم، وهل يوجد في سوقكم مهندسون لتلك التقنية، وهل تبقى الاستضافة داخل حساباتكم أنتم. وعلى منظومة تعمل أصلا يكون الجواب الافتراضي ألا تغير، لأن مبرر المجازفة بما يعمل أصلا من أجل بديل يبدو أفضل على الورق فحسب يظل ضعيفا غالبا. ولم تستبدل في أعمال Tegoly وFinteo وTerazzi أي تقنية عاملة: ففي عمل Tegoly جرى الشغل على MSSQL وAzure القائمين أصلا، وفي Finteo وTerazzi جرى على المنصتين اللتين كانتا لدى الشركتين من قبل. أما في جانب المورد فالمقياس ليس قائمة المراجع بل صورة التسليم وملكية الحسابات.

بناء الفريق وتقييم المهندسين

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

جرد الدين التقني وترتيب الأولويات

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

التواصل مع المستثمرين ومجلس الإدارة

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

أي القرارات لا رجعة فيها

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

معايير تقييم الوكالة أو المورد

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

الخروج: أن تصيروا مستقلين

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

تقاسم صلاحية القرار

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

كيف عمل هذا في ثلاث حالات

الأعمال الثلاثة التالية هي الحالات التي أنجز فيها هذا العمل. ولكل واحدة صفحتها في قسم قصص النجاح، ويمكن التحقق من كل منها من الخارج.

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