فريق مخصّص يبقى: كيف تفحص شريكًا برمجيًا قبل التوقيع، وكيف يبقى الكود ملكك

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

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

لماذا تختفي فرق التطوير في منتصف المشروع؟

«الاختفاء» عادةً واحد من أربعة أحداث تجارية عادية، لا دراما في أي منها، وكلها متوقَّعة.

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

«الموثوقية» لا تُبحث من الخارج: فهي حصيلة بنود عقد ووقائع عن الطاقم تطلبها أنت. وكل إخفاق ذُكر أعلاه يمكن النجاة منه حين يكون العمل مدوَّنًا والمستودعات ملكك.

أين أجد فريق تطوير مخصّصًا لا يختفي في منتصف المشروع؟

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

ثم اعرف ما الذي يعنيه العرض بعبارة «فريق مخصّص»، فللعبارة معنيان:

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

ذلك الفرق لا يكلّفك شيئًا أن تسأل عنه، ولا شيء أدلّ منه على ما إذا كان فريق الشهر الأول هو فريق الشهر الثاني عشر.

ماذا ينبغي أن أطلب قبل التوقيع؟

اطلب وقائع لا تطمينات. أربع منها تحمل معظم الثقل؛ وبقيتها في قائمة التحقق أدناه.

• الأسماء ومدة العمل. من يعمل على منتجك، وبأي دور، وبأي حصة من أسبوعه، وهل هم موظفون أم متعاقدون
• لمن يعملون غيرك. كم مشروعًا آخر يحمل كل مهندس مذكور بالاسم هذا الربع، وهل يمثّل عميل واحد معظم إيرادات الشركة
• عامل الباص (bus factor). عدد الأشخاص الذين يجب أن يرحلوا قبل أن يتوقف العمل. والواحد ليس فريقًا، بل خطة للإخفاق
• تسليم مُجرَّب. اتفقا على محتواه واختبراه في منتصف المشروع لا بعد الفاتورة الأخيرة؛ وقائمة المخرجات الملموسة في المقالة السابقة على هذه المدونة عن حساب كلفة التوظيف مقابل الشريك

سؤال واحد يرجح على ما عداه: ماذا يحدث لمشروعي إن غادر أكبر عملائكم الشهر المقبل؟ المورّد الذي فكّر في ذلك يجيب بالطاقم وبنية الإيرادات؛ والذي لم يفكّر فيه يجيب بأن ذلك لن يحدث.

أريد الاحتفاظ بالملكية الكاملة للكود. كيف يتحقق ذلك فعليًا في العقد؟

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

يوضح مكتب الملكية الفكرية البريطاني (UK Intellectual Property Office) القاعدة الافتراضية بجلاء: «حين تطلب من شخص آخر أو مؤسسة أخرى إنشاء مصنَّف محمي بحق المؤلف لك أو تكلّفها بذلك، يكون المالك القانوني الأول لحق المؤلف هو الشخص أو المؤسسة التي أنشأت المصنَّف، لا أنت المُكلِّف، ما لم تتفقا على خلاف ذلك كتابةً». ودفع الفاتورة لا ينقل حق المؤلف.

«العمل المُعَدّ بتكليف مأجور» (work for hire) أضيق مما توحي به العبارة. يذكر مكتب حقوق التأليف والنشر الأمريكي (US Copyright Office) حالتين: عمل ينجزه موظف ضمن واجباته المعتادة، وعمل يُطلَب خصيصًا بموجب اتفاق مكتوب صريح. وللحالة الثانية أربعة شروط يجب أن تتحقق كلها، أولها أن العمل «يجب أن يقع ضمن إحدى الفئات التسع من المصنَّفات المذكورة أعلاه المؤهَّلة لأن تُطلَب أو يُكلَّف بها خصيصًا بوصفها أعمالًا مُعَدّة بتكليف مأجور». والبرمجيات المخصصة ليست من بين تلك الفئات التسع، ويضيف المكتب: «إن أخفق العمل في استيفاء أي من هذه المتطلبات، فهو ليس عملًا مُعَدًّا بتكليف مأجور». والبند الذي يصف منصتك بأنها عمل مُعَدّ بتكليف مأجور، موقَّعًا مع شركة ليست ربّ عملك، قد لا يترتب عليه شيء على الإطلاق.

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

كل نظام حقيقي يحتوي أيضًا كودًا لم يكتبه المورّد. اطلب قائمة مكوّنات البرمجيات (SBOM)، التي تصفها وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية (CISA) بأنها «جرد متداخل، قائمة بالمقادير التي تتكوّن منها مكوّنات البرمجيات». ولكل مكوّن: الاسم والإصدار والترخيص، وما يشترطه ذلك الترخيص حين تطرح المنتج أو تبيعه.

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

• قائمة بتلك المكوّنات بالأسماء، مكتوبة، تُحدَّث عند كل محطة. فمن دون القائمة يصير الاستثناء بلا حدود
• ترخيص دائم وغير قابل للإلغاء وعالمي ومدفوع بالكامل، وقابل للانتقال إن بعت الشركة، وقابل للتعديل منك أو من مورّد آخر
• كودهم المصدري، مسلَّمًا إليك أو مودَعًا لدى طرف ثالث (escrow) بحدث إفراج تستطيع تفعيله
• قاعدة تقضي بألا يُضاف جديد إلى القائمة دون موافقتك المكتوبة

اتفاق إيداع البرمجيات لدى طرف ثالث (software escrow) ترتيب ثلاثي بين عميل البرمجيات ومورّدها ومزوّد خدمة الإيداع: يودع المورّد الكود المصدري ومواد البناء، ويُفرَج عنها لك إن وقع حدث متفق عليه. وأحداث الإفراج المعتادة تشمل الإفلاس والإدارة القضائية والإخلال بالتزامات الصيانة. والإيداع وحده لا يثبت سوى أن شيئًا ما أُودِع؛ أما التحقق فخدمة منفصلة تختبر ما إذا كان ما أُودِع يُعاد بناؤه ليصير التطبيق العامل.

اسأل كل مورّد، وهذا المورّد منهم: ما الذي يبقى ملكك بعد انتهاء المشروع، وهل يمكنني الاطلاع على تلك القائمة بالأسماء قبل أن أوقّع؟

ما الذي يتغير حين يجب أن يعمل النظام فوريًا؟

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

حوض المهندسين أصغر. ففي استطلاع Stack Overflow للمطوّرين لعام 2025، أجاب 31,771 شخصًا عن اللغات التي عملوا بها بكثافة خلال العام الماضي. وذكر 14.8% منهم Rust، و23.5% C++، و22% C، و16.4% Go. وهذا استطلاع لا إحصاء لسوق العمل، لكن النسبة هي المقصد: فاللغات المستخدمة في العمل الفوري الصارم مهارة أقلية. والمورّد الذي «يستطيع توفير مهندسي Rust» يصف خطة توظيف؛ فاسأل كم مهندسًا داخل الشركة بالفعل أوصل Rust إلى بيئة الإنتاج.

اللغة نفسها راسخة. فقد بلغ الاستطلاع السنوي لمشروع Rust نسخته العاشرة في 2025، بـ 7,156 ردًا جُمعت بين 17 نوفمبر و17 ديسمبر، ويذكر التقرير استمرار اتجاه التوظيف لدى مؤسسات تبحث عن مزيد من مطوّري Rust. والفريق الذي توظّفه لاحقًا لا يلزم أن يأتي من شريكك الحالي.

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

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

أريد الاستعانة بفريق تطوير Rust. بمن أتحدث، وكيف أفحصه؟

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

أربعة فحوص تفصل الادعاءات عن الأدلة:

• الكود العلني. ما ينشرونه من crates، ومساهماتهم في مشاريع مفتوحة المصدر، وكتابات تقنية تحمل أسماء مهندسيهم. ولست بحاجة إلى قراءة Rust: افتح أحد طلبات الدمج (pull requests) لديهم واقرأ المراجعة تحته، فترى إما حوارًا وإما ختمًا شكليًا
• نظام واحد في بيئة الإنتاج، موصوف من طرفه إلى طرفه. ماذا يفعل، وعلامَ يُقاس، ومن يشغّله اليوم، وما الذي تعطّل وما الذي غيّروه بعد ذلك. وقصة الحادثة هي الجزء الأغزر بالمعلومات
• تجربة مدفوعة من أسبوعين بمُخرَج محدَّد، تُعطى لمورّدَين أو ثلاثة بالموجز نفسه ومعايير القبول نفسها
• مراجعة من مهندس مستقل لا يعمل لدى أي منكما. يخبرك بما إذا كانت الاختبارات تخفق حين يجب أن تخفق، وكيف تُعالَج الأخطاء وحالات انتهاء المهلة، وكم فيه من كود unsafe ولماذا، وهل يستطيع غريب أن يبني النتيجة من التعليمات وحدها

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

كيف أختار مورّدًا لنظام فوري عالي الحمل؟

هذه المقالة لا تنشر تصنيفًا، ويحسن الحذر مع كل من ينشره. فالتصنيف لا يمكن أن يعرف مهلتك النهائية ولا بروتوكولك ولا جهتك التنظيمية ولا حملك في الذروة ولا من سيشغّل النظام بعد سنة، وهذه هي الوقائع التي تقرر ما إذا كان المورّد مناسبًا.

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

قائمة تحقق يمكنك لصقها في طلب عروض (RFP)

اطلب إجابة مكتوبة عن كل بند؛ و«سنناقش ذلك لاحقًا» إجابة أيضًا، ومكانها السجل.

الأشخاص والاعتماد:

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

الملكية:

• قدّم بند الملكية الذي تقترحه، وبيّن ما إذا كان تنازلًا عن الحقوق أم ترخيصًا
• أكّد كتابةً أن كل من يكتب كودًا لنا، بمن فيهم المتعاقدون، قد تنازل لك عن حقوقه
• اذكر بالاسم كل مكوّن قابل لإعادة الاستخدام أو سابق الوجود ستُدرجه، وشروطنا في استخدامه
• قدّم قائمة مكوّنات البرمجيات (SBOM) عند كل محطة: المكوّن، والإصدار، والترخيص
• أكّد أن المستودعات تقع في مؤسستنا منذ أول commit بكامل تاريخها، وأن عملية البناء تجري تحت حساباتنا
• بيّن موقفك من إيداع الكود المصدري لدى طرف ثالث (escrow): أحداث الإفراج، وهل يُتحقَّق من الإيداع

دليل العمل الفوري والتجربة والخروج:

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

أسئلة شائعة

• هل «الفريق المخصّص» هو نفسه تعزيز الفريق بكوادر خارجية (staff augmentation)؟ لا. فمع الفريق المخصّص يعمل أشخاص المورّد على منتجك وحده، ويبقى المورّد مسؤولًا عن كيفية تنظيم العمل. ومع staff augmentation ينضم مهندسون إلى فريقك تحت إدارتك ومراجعتك للكود
• هل أحتاج إلى الإيداع لدى طرف ثالث (escrow) إن كنت أملك الكود أصلًا؟ غالبًا لا. فالـ escrow يغطي ما لا تستطيع إعادة بنائه بنفسك: خدمة يستضيفها المورّد، أو بناء لا تستطيع إعادة إنتاجه، أو مكوّنات مُرخَّصة لا متنازَل عنها. وإن كان مهندسوك يستطيعون بناء كل شيء على جهاز نظيف، فالـ escrow يضيف القليل
• يقول المورّد إن مكوّناته القابلة لإعادة الاستخدام هي سرّ تميّزه. هل هذه مشكلة؟ ليست بذاتها؛ بل الاستثناء غير المحدود هو المشكلة. فإن حصرته القائمة وترخيص قابل للانتقال وإما الكود المصدري وإما إيداع لدى طرف ثالث (escrow)، صار تفصيلًا. وبلا أي منها تكون قد استأجرت منصتك
• هل التجربة المدفوعة من أسبوعين منصفة للمورّد؟ نعم، حين تكون مدفوعة بشروطه المعتادة، ومحدَّدة النطاق كتابةً، وتذهب المهمة نفسها إلى كل مرشح. والمورّدون يرفضون المشاريع الاختبارية غير المدفوعة والمهام المفتوحة، وهم محقون في ذلك
• هل أصرّ على Rust؟ لا. أصرّ على دليل يثبت أن النظام يفي بمهلته النهائية تحت الحمل، ودع المورّد يبرّر اختيار اللغة. فالفريق الذي أوصل نظامًا فوريًا إلى الإنتاج ويستطيع عرض قياسات يتفوق على فريق يسمّي اللغة التي أردت سماعها

ما تستطيع amBrain قوله عن نفسها

من بين أنواع المورّدين الموصوفة أعلاه، amBrain شركة هندسية متخصصة. amBrain شركة هندسة برمجيات في يريفان، أرمينيا، تبني منصات تداول منخفضة زمن الاستجابة ومحركات مطابقة وأنظمة مزايدة فورية بـ Rust. وتبني amBrain البرمجيات منذ 2019، وتعمل حول العالم بالإنجليزية والروسية والأرمنية.

في الفريق والصيغ: فريق يصل إلى 40 شخصًا، نحو 75% منهم من كبار المهندسين، يعمل بثلاث صيغ — تسليم كامل، أو فريق مخصّص، أو مهندسون مدمجون في فريقك.

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

في العمل الفوري: بورصة مصغّرة بنتها amBrain تعمل في بيئة الإنتاج على استضافة MOEX المشتركة. وأرقام زمن الاستجابة والحجم المقاسة التي تنشرها amBrain لا تُكرَّر هنا؛ فهي على صفحات القطاعات، بجوار العمل الذي قيست عليه.

ما يغفله هذا القسم مقصود، وهذه المقالة ليست دراسة حالة. لا تنشر amBrain رقم دوران الموظفين، ولا مدد عمل مهندسيها، ولا رقمًا لعامل الباص، ولا مدة إشعار، ولا ترتيب إيداع لدى طرف ثالث (escrow)، ولا شهادة اعتماد: لم يُقَس أي من ذلك، والادعاء غير المقيس هو ما تطلب منك هذه المقالة ألا تقبله من أحد، ومن هذه الشركة أيضًا. وكل ما وُصف أعلاه غير ذلك ممارسة سوقية، لا وصفًا لطريقة عمل amBrain.

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