مستقل أم شركة تطوير برمجيات أم فريق داخلي: كيف تختار؟

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

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

السؤال الذي تسأله ليس السؤال الذي يقرر

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

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

الخيارات الثلاثة كما هي فعلاً

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

لاحظ أن العمود الأخير هو الذي يقرر عادةً، وهو العمود الوحيد الذي لا يظهر في أي عرض سعر.

متى يكون المستقل الخيار الصحيح

المستقل خيار ممتاز حين تتحقق ثلاثة شروط معاً، لا واحد منها:

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

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

متى تكون شركة تطوير برمجيات هي الخيار الصحيح

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

شركة التطوير تصبح الخيار المنطقي حين يتحول المشروع من «مهمة» إلى «منتج». المؤشرات العملية:

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

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

متى يستحق الفريق الداخلي

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

الشروط العملية قبل التوظيف:

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

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

التكاليف التي لا تظهر في العرض

كل خيار من الثلاثة يحمل تكلفة حقيقية لا يذكرها أحد في العرض، لأنها تقع عليك أنت:

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

النموذج المختلط الذي ينجح أكثر مما يُعترف به

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

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

خمسة أسئلة تكشف الجودة قبل التوقيع

هذه الأسئلة تصلح للخيارات الثلاثة، ولا تحتاج خلفية تقنية لتقييم إجاباتها:

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

الخطوة العملية التالية

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

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