ألقي مهندس لدى شركة Anthropic درسًا تمهيديًا في FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ
كين باي يعمل حاليًا في فريق Applied AI التابع لـ Anthropic. وقبل ذلك كان عضوًا مؤسسًا في فريق FDE لدى Rippling، وقبل Rippling قضى سنوات عدة في Palantir. مؤخرًا قدم عرضًا بعنوان FDE 101، شرح فيه بوضوح دور مهندس النشر في الخط الأمامي (Frontline). ومن المفيد تلخيص ما قاله.
لنبدأ ببيانٍ واحد: في شركات SaaS المدرجة، وبحسب متوسط قيمة العقد، تأتي Palantir في المرتبة الأولى بـ 4 ملايين دولار، ثم ServiceNow بـ 1.2 مليون، وWorkday بـ 600 ألف، ولا توجد أي شركة أخرى تتجاوز 500 ألف. لقد حققت Palantir متوسط قيمة تعاقدات مرتفعًا باستخدام بضعة آلاف من الموظفين، وهو ما لا تستطيع شركات أخرى تحقيقه حتى مع عشرات الآلاف. والسبب يكمن في نموذج FDE.
فماذا يحل FDE بالضبط؟
يعد منتج Palantir Foundry عبارة عن منصة لبناء التطبيقات، ومستوى العوائق التقنية فيها مرتفع. لكن المشتريين هم من المديرين التنفيذيين غير التقنيين في قطاعات مثل النفط والسلع الاستهلاكية. إذا ألقيت منصة تقنية معقدة في يد شخص لا يكتب الكود، وتوقعت أن يفهم وحده كيفية استخدامها، فهذا غير واقعي.
لذلك تتبع Palantir نهجًا يتمثل في أن العميل لا يشتري منتج برمجيًا ولا خدمة استشارية، بل يشتري «نتيجة». ترسل مهندسين إلى العميل، وتغوص في فهم سيناريوهات العمل الخاصة به، ثم تبني لهم ما يلزم على المنصة. ما يهتم به العميل هو عدد المنتجات التي «تزداد على الرفوف»، ومدى تحسن كفاءة خط الإنتاج. أمّا كيفية تنظيم البيانات، فلا يشغل باله—ولا ينبغي أن يشغله.
ما الفرق بين FDE وبين تطوير مُسند/خارجي؟
أكد كيفن نقطةً واحدة على وجه الخصوص: إذا كان مهندسوك يكتبون كودًا مخصصًا للعميل من الصفر في كل مرة، فذلك ليس FDE، بل تطوير خارجي. يمكن أن ينجح نموذج FDE فقط إذا كانت هناك منصة قابلة لإعادة الاستخدام. يقوم المهندس بتركيب وتخصيص الحل انطلاقًا من قدرات المنصة الموجودة بالفعل، وليس بإعادة اختراع العجلة في كل مرة. بدون منصة، ستلتهم تكاليف الصيانة كل الأرباح، وسيغادر المهندسون لأن عليهم لاحقًا صيانة عشرات قواعد الكود غير المرتبطة ببعضها.
هل يجب عليك تبني FDE؟ سؤالان يكفيان للحسم.
أولًا: هل تحتاج إلى بيع شيء تقني التعقيد إلى مشترٍ غير تقني؟ إذا كان عملاؤك أنفسهم مهندسين—مثلًا إذا كنت تبيع GitHub أو Datadog—فلست بحاجة إلى FDE. وإذا كان منتجك بحد ذاته جاهزًا للاستخدام فورًا مثل Slack أو Jira، فلست بحاجة أيضًا. FDE يكون ضروريًا فقط عندما يكون منتجك معقدًا، والعميل لا يفهم التقنية.
ثانيًا: هل لديك منصة قابلة لإعادة الاستخدام؟ أو هل أنت مستعد للاستثمار لبنائها؟ بدون مكونات أساسية مشتركة قابلة لإعادة الاستخدام، يكون FDE غير مستدام.
ما التغير الجديد في 2026؟
كانت تقديرات كيفن مثيرة للاهتمام: طريقة ممارسة الأعمال في قطاع البرمجيات نفسها تتغير. فبفضل الذكاء الاصطناعي أصبح بناء البرمجيات أسهل بشكل كبير، وتتجه تقريبًا جميع المنصات نحو نمط الوكلاء (Agent hóa). وهذا يعني أن معظم المنصات ستصبح قابلة للتخصيص بدرجة عالية. النتيجة هي أن عددًا متزايدًا من العملاء لن يكون قادرًا على فهم ما الذي يمكن لمنتجك فعله بالضبط. وفي عصر الوكلاء، يصبح تسليم نجاح/فشل منتجك ليكتشفه العميل بنفسه أمرًا أصعب فأصعب.
وهذا يحوّل FDE من كونه طريقة خاصة ومحدودة الاستخدام لدى Palantir، إلى موضوع ينبغي على عدد أكبر من شركات البرمجيات أخذه بجدية في الاعتبار.
سؤال أخير: ما نوع الأشخاص المناسبين للعمل في FDE؟
إجابة كيفن كانت مختصرة جدًا: FDE هو عمل يضع فيه ثقتك في مهندس برمجيات لدرجة أنك تسمح له بأن يواجه العملاء مباشرة. الكفاءة التقنية هي الأساس، لكن عليك أيضًا أن تكون مطمئنًا إلى أنه سيُمثل الشركة ويتعامل مع العملاء.
https://www.youtube.com/watch?v=KwhgfwOSToQ
كين باي يعمل حاليًا في فريق Applied AI التابع لـ Anthropic. وقبل ذلك كان عضوًا مؤسسًا في فريق FDE لدى Rippling، وقبل Rippling قضى سنوات عدة في Palantir. مؤخرًا قدم عرضًا بعنوان FDE 101، شرح فيه بوضوح دور مهندس النشر في الخط الأمامي (Frontline). ومن المفيد تلخيص ما قاله.
لنبدأ ببيانٍ واحد: في شركات SaaS المدرجة، وبحسب متوسط قيمة العقد، تأتي Palantir في المرتبة الأولى بـ 4 ملايين دولار، ثم ServiceNow بـ 1.2 مليون، وWorkday بـ 600 ألف، ولا توجد أي شركة أخرى تتجاوز 500 ألف. لقد حققت Palantir متوسط قيمة تعاقدات مرتفعًا باستخدام بضعة آلاف من الموظفين، وهو ما لا تستطيع شركات أخرى تحقيقه حتى مع عشرات الآلاف. والسبب يكمن في نموذج FDE.
فماذا يحل FDE بالضبط؟
يعد منتج Palantir Foundry عبارة عن منصة لبناء التطبيقات، ومستوى العوائق التقنية فيها مرتفع. لكن المشتريين هم من المديرين التنفيذيين غير التقنيين في قطاعات مثل النفط والسلع الاستهلاكية. إذا ألقيت منصة تقنية معقدة في يد شخص لا يكتب الكود، وتوقعت أن يفهم وحده كيفية استخدامها، فهذا غير واقعي.
لذلك تتبع Palantir نهجًا يتمثل في أن العميل لا يشتري منتج برمجيًا ولا خدمة استشارية، بل يشتري «نتيجة». ترسل مهندسين إلى العميل، وتغوص في فهم سيناريوهات العمل الخاصة به، ثم تبني لهم ما يلزم على المنصة. ما يهتم به العميل هو عدد المنتجات التي «تزداد على الرفوف»، ومدى تحسن كفاءة خط الإنتاج. أمّا كيفية تنظيم البيانات، فلا يشغل باله—ولا ينبغي أن يشغله.
ما الفرق بين FDE وبين تطوير مُسند/خارجي؟
أكد كيفن نقطةً واحدة على وجه الخصوص: إذا كان مهندسوك يكتبون كودًا مخصصًا للعميل من الصفر في كل مرة، فذلك ليس FDE، بل تطوير خارجي. يمكن أن ينجح نموذج FDE فقط إذا كانت هناك منصة قابلة لإعادة الاستخدام. يقوم المهندس بتركيب وتخصيص الحل انطلاقًا من قدرات المنصة الموجودة بالفعل، وليس بإعادة اختراع العجلة في كل مرة. بدون منصة، ستلتهم تكاليف الصيانة كل الأرباح، وسيغادر المهندسون لأن عليهم لاحقًا صيانة عشرات قواعد الكود غير المرتبطة ببعضها.
هل يجب عليك تبني FDE؟ سؤالان يكفيان للحسم.
أولًا: هل تحتاج إلى بيع شيء تقني التعقيد إلى مشترٍ غير تقني؟ إذا كان عملاؤك أنفسهم مهندسين—مثلًا إذا كنت تبيع GitHub أو Datadog—فلست بحاجة إلى FDE. وإذا كان منتجك بحد ذاته جاهزًا للاستخدام فورًا مثل Slack أو Jira، فلست بحاجة أيضًا. FDE يكون ضروريًا فقط عندما يكون منتجك معقدًا، والعميل لا يفهم التقنية.
ثانيًا: هل لديك منصة قابلة لإعادة الاستخدام؟ أو هل أنت مستعد للاستثمار لبنائها؟ بدون مكونات أساسية مشتركة قابلة لإعادة الاستخدام، يكون FDE غير مستدام.
ما التغير الجديد في 2026؟
كانت تقديرات كيفن مثيرة للاهتمام: طريقة ممارسة الأعمال في قطاع البرمجيات نفسها تتغير. فبفضل الذكاء الاصطناعي أصبح بناء البرمجيات أسهل بشكل كبير، وتتجه تقريبًا جميع المنصات نحو نمط الوكلاء (Agent hóa). وهذا يعني أن معظم المنصات ستصبح قابلة للتخصيص بدرجة عالية. النتيجة هي أن عددًا متزايدًا من العملاء لن يكون قادرًا على فهم ما الذي يمكن لمنتجك فعله بالضبط. وفي عصر الوكلاء، يصبح تسليم نجاح/فشل منتجك ليكتشفه العميل بنفسه أمرًا أصعب فأصعب.
وهذا يحوّل FDE من كونه طريقة خاصة ومحدودة الاستخدام لدى Palantir، إلى موضوع ينبغي على عدد أكبر من شركات البرمجيات أخذه بجدية في الاعتبار.
سؤال أخير: ما نوع الأشخاص المناسبين للعمل في FDE؟
إجابة كيفن كانت مختصرة جدًا: FDE هو عمل يضع فيه ثقتك في مهندس برمجيات لدرجة أنك تسمح له بأن يواجه العملاء مباشرة. الكفاءة التقنية هي الأساس، لكن عليك أيضًا أن تكون مطمئنًا إلى أنه سيُمثل الشركة ويتعامل مع العملاء.