مهندس المنتج Product Engineer يملك النتيجة لا المهمة

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

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

• كيف تصف PostHog وLinear وغيرهما هذا الدور، وما الذي يتفقون عليه.
• الحس المنتجي Product Sense للمطور، والحديث مع المستخدمين دون أن تصبح مدير منتج.
• دورة الميزة Feature Cycle عند مهندس المنتج: من تعريف النجاح إلى إضافة الأحداث Instrumentation والإطلاق الصغير خلف Feature Flag، ثم قراءة البيانات قبل وبعد مع مثال حقيقي.
• الفرق بينه وبين مهندس المنصة Platform Engineer والبنية التحتية، والمسار المهني.
• قائمة تحقق عملية لمطور يريد أن ينتقل إلى هذه الطريقة في العمل.

كيف تصف الشركات مهندس المنتج Product Engineer؟

أوضح وصف منشور تجده في كتيب Product Engineer Handbook الذي تنشره PostHog، وهي شركة تحليلات منتجات Product Analytics تعمل بهذا النموذج، وفيه أن وظيفة مهندس المنتج تتجاوز كتابة الكود، فهو يتحدث مع المستخدمين، ويقرر ماذا يبنى، ويملك تجربة المستخدم User Experience، ويدعم العملاء مباشرة، ومسؤول أولاً أمام مستخدميه وعملائه الذين يدفعون. وتلخص الصفحة الدور بأنه مطور يهتم بالنتيجة وأثر الكود على المستخدمين أكثر من اهتمامه بطريقة التنفيذ، ومن صفاته كما تذكرها: أن يكون له رأي في خارطة الطريق Roadmap، وأن يتخذ قرارات تصميم بنفسه، وأن يكون أقل تمسكاً بالميزات التي بناها سابقاً، وأن يعرف كيف يرتبط عمله باستراتيجية الشركة.

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

أما Linear فلا تنشر تعريفاً، ولكن إعلان وظيفة Senior / Staff Product Engineer لديها يطلب حساً منتجياً Product Sensibility يهتم بتجربة المستخدم والسرعة والإتقان ويعترض عندما لا يكون شيء صحيحاً، وأن يكون المهندس مرتاحاً للعمل دون إشراف ثقيل من مدير منتج Product Manager، فيساعد في تشكيل المشكلة لا تنفيذ الحل فقط، وأن يأخذ الميزة من الفكرة إلى الإطلاق. وطريقة عملها المنشورة باسم Linear Method تقول في صفحة Build with users إن على من يبني المنتج عندما يطلب المستخدم ميزة أن يسأله عن المشكلة التي يحاول حلها، وفي صفحة Write issues not user stories إنهم يفضلون أن يقضي الفريق الوقت في الحديث مع المستخدمين بدل كتابة قصص المستخدم User Stories.

وقبل أن ينتشر المسمى كتب Gergely Orosz سنة 2019 مقال The Product-Minded Software Engineer عن المطور المهتم بالمنتج، وذكر فيه تسع صفات منها: المبادرة بأفكار وآراء عن المنتج، والاهتمام بالعمل وسلوك المستخدمين وبياناتهم، وطرح المفاضلة Trade-off بين المنتج والهندسة مبكراً، والتعامل العملي مع الحالات الحدية Edge Cases، ودورات تحقق سريعة، وامتلاك الميزة من البداية إلى النهاية.

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

أين يقف مهندس المنتج Product Engineer بين الأدوار الأخرى؟

الصورة التالية تضع الأدوار على خط واحد، من الأقرب إلى المستخدمين والعمل إلى الأقرب إلى الأنظمة والمهندسين الآخرين:

وقد يتساءل البعض: هل هذا يعني أن مهندس المنصة Platform Engineer أو البنية التحتية Infrastructure أقل قيمة؟ والإجابة لا، وإنما مستخدمه مختلف، فمهندس المنصة يبني الطريق الذي يمشي عليه مهندسو المنتج: خطوط النشر Deployment Pipelines، والبيئات Environments، وأدوات المراقبة Monitoring، وخدمة ال Feature Flags نفسها، ومستخدموه هم المطورون، ويجب أن يعاملهم كمستخدمين بنفس الطريقة، أي أن يسألهم عن مشكلاتهم ويقيس هل استخدموا ما بناه. وقد شرحنا أنواع الفرق بحسب كتاب Team Topologies في خارطة CTO، ومهندس المنتج يعمل غالباً في الفريق المرتبط بمسار العمل Stream-aligned Team، ومهندس المنصة في فريق المنصة Platform Team.

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

الحس المنتجي Product Sense للمطور

الحس المنتجي Product Sense ليس موهبة، وإنما عادات تتكرر حتى تصبح طريقة تفكير، وأهمها عند المطور أربع:

• اسأل عن المشكلة قبل الحل: عندما تصلك تذكرة «أضف زر تصدير Excel» اسأل ماذا يفعل المستخدم بالملف بعد تصديره، وقد شرحنا هذا السؤال في الحاجة أم الحل.
• فكر في المسار كله لا في الشاشة: الميزة التي تعمل في الشاشة وتفشل في رسالة البريد التي تليها، أو في حالة المستخدم الذي ليس لديه بيانات بعد Empty State، لم تكتمل.
• اعرض المفاضلة مبكراً: «هذا الحل يأخذ أسبوعين، وهذا الحل الأبسط يحل 80% من الحالات في يومين، أيهما نختار؟» جملة واحدة من مهندس في الوقت المناسب توفر على الفريق أسابيع، وهي ما تعنيه صفة طرح المفاضلة مبكراً في قائمة Orosz.
• كن أقل تمسكاً بالكود: الميزة التي لا يستخدمها أحد تحذف حتى لو كنت فخوراً بكودها، والسبب أن كل ميزة تبقى في الكود تكلف صيانة واختبارات وتعقيداً لكل من يأتي بعدك.

الحديث مع المستخدمين دون أن تصبح مدير منتج Product Manager

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

وعندما تتحدث مع المستخدم فالقاعدة نفسها التي شرحناها في مقابلات الاكتشاف: اسأل عما فعله في مرة محددة في الماضي، لا عن رأيه في فكرتك، والسؤال الذي يستخدمه مهندسو PostHog كما في دليلهم: «هل حاولت أن تحل هذه المشكلة من قبل؟ ماذا فعلت؟».

ولاحظ أن PostHog نفسها تكتب في نفس الدليل رأياً يختلف قليلاً عما في مقال الاكتشاف، فهي ترى أن التحقق من الأفكار Validation مقدماً بالمقابلات محدود الفائدة، وأن الإطلاق الصغير السريع Ship Small هو غالباً أفضل طريقة للتحقق، بشرط أن تصغر نطاق الميزة كثيراً، وأن تديره بإطلاق تدريجي Gradual Rollout، وأن تتابع بعده هل يستخدمها أحد. وهذا ليس تناقضاً، والسبب أن الشركة تقول في نفس الصفحة إنها تبني منتجات لها منافسون ناجحون أصلاً، فالسؤال عندها «هل يريد مستخدمونا هذا منا؟» وليس «هل المشكلة حقيقية؟»، وكلما كانت الفكرة أجد وأغلى في البناء زادت قيمة الاكتشاف Discovery قبلها.

دورة الميزة Feature Cycle عند مهندس المنتج Product Engineer

الفرق العملي بين مهندس ينفذ التذكرة ومهندس يملك النتيجة يظهر في ما يحدث قبل الكود وبعده، والصورة التالية تبين الدورة كاملة:

1. الحديث مع المستخدمين Talk to Users: تعرف المشكلة من مصدرها، لا من ملخص في تذكرة.
2. تعريف النجاح Define Success: تكتب في التذكرة نفسها المقياس Metric الذي يجب أن يتغير وقيمته الحالية، مثل «نسبة العيادات التي تحجز أول موعد خلال 7 أيام من التسجيل، وهي الآن 49%»، والسبب أنك إذا لم تكتب القيمة قبل البدء فسوف تقنع نفسك بعد الإطلاق بأن أي رقم جيد.
3. إضافة الأحداث Instrumentation: تضيف الأحداث التي تقيس المقياس قبل الإطلاق، لا بعده، لأن الحدث الذي يضاف بعد الإطلاق لا يرى ما حدث قبله.
4. الإطلاق الصغير خلف Feature Flag: تطلق أصغر نسخة مفيدة لفريقك أولاً ثم لنسبة من المستخدمين، وقد شرحنا ذلك بالتفصيل مع تجربة عملية في مقال Feature Flags، والقاعدة في التطوير على الفرع الرئيسي أن يصل الكود إلى الإنتاج كل يوم وال Flag هو الذي يقرر من يراه.
5. قراءة البيانات Read the Data: بعد أسبوعين أو أربعة تقرأ نفس المقياس، وتقارن بحذر كما سنرى في المثال التالي.
6. القرار Decide: تبقي الميزة، أو تحسنها، أو تحذفها مع ال Flag والكود القديم، وتكتب ما تعلمته في التذكرة أو في مراجعة السبرنت Sprint Review.

كيف تكتب حدثاً Event تستطيع قراءته بعد ستة أشهر

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

في الصورة أعلاه لاحظ التالي:

• الاسم بصيغة الشيء ثم الفعل بالماضي، مثل booking_created وclinic_created، وبحروف صغيرة وشرطة سفلية في كل مكان، والسبب أن BookingCreated وbooking-created سيظهران في التقارير كحدثين مختلفين ولن ينتبه أحد.
• الحدث المهم يرسل من السيرفر عندما يحدث فعلاً في قاعدة البيانات، لا من زر في المتصفح قد يضغط ثم يفشل الطلب، وإذا أرسلته من الاثنين فسوف يعد مرتين.
• المعرف user_id معرف داخلي مستعار Pseudonymous ID، وليس البريد ولا رقم الجوال، والسبب أن أداة التحليلات لا تحتاج إلى بيانات شخصية Personal Data لتعد، وكل بيان شخصي تضيفه يضيف عليك التزامات في نظام حماية البيانات الشخصية، وسوف نعود إلى هذا في مقال مقاييس المنتج Product Metrics.
• الخصائص هي ما يسمح لك بتقسيم النتيجة لاحقاً، فخاصية onboarding هي التي ستسمح لنا في المثال التالي بالمقارنة بين من رأى قائمة البداية ومن لم يرها.

قراءة البيانات قبل الإطلاق Launch وبعده: مثال حقيقي

في مقال مقاييس المنتج سوف نبني مختبراً كاملاً فيه Umami وPostgreSQL وبيانات تجريبية Synthetic Data لنظام العيادات، أي مستخدمون وأحداث مولدة بسكربت لا تخص أشخاصاً حقيقيين، وفي هذه البيانات فعلنا قائمة خطوات البداية Onboarding Checklist يوم 15 سبتمبر 2026. والسؤال الذي يسأله مهندس المنتج: هل زادت نسبة العيادات التي تحجز أول موعد خلال 7 أيام؟ والاستعلام التالي يقارن قبل التاريخ وبعده من جدول events:

-- activation before and after the onboarding checklist (turned on 15 September 2026)
WITH clinic AS (
    SELECT user_id, min(occurred_at) AS t FROM events WHERE event = 'clinic_created' GROUP BY user_id
), activated AS (
    SELECT DISTINCT c.user_id FROM clinic c JOIN events e USING (user_id)
    WHERE e.event = 'first_booking' AND e.occurred_at BETWEEN c.t AND c.t + interval '7 days'
)
SELECT CASE WHEN c.t < '2026-09-15' THEN 'before checklist' ELSE 'after checklist' END AS period,
       count(*) AS clinics, count(a.user_id) AS activated,
       round(100.0 * count(a.user_id) / count(*), 1) AS activation_pct
FROM clinic c LEFT JOIN activated a USING (user_id)
GROUP BY 1 ORDER BY 1 DESC;

docker exec lab-product-db psql -U umami -d product -f /out/activation.sql

والمخرج سوف يكون كما يلي:

      period      | clinics | activated | activation_pct
------------------+---------+-----------+----------------
 before checklist |     229 |       112 |           48.9
 after checklist  |     232 |       156 |           67.2
(2 rows)

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

docker run --rm --name lab-product-stats -v "$PWD/gen:/gen:ro" \
  node:22.23.3-bookworm-slim node /gen/stats.mjs ztest 112 229 156 232

A 112/229 = 48.9%  B 156/232 = 67.2%  z = 3.99  p-value = 0.00007

في المخرج أعلاه لاحظ التالي:

• النسبة ارتفعت من 48.9% إلى 67.2%، والفرق دال إحصائياً Statistically Significant، أي أن احتمال أن يظهر فرق بهذا الحجم بالصدفة وحدها صغير جداً.
• ولكن هذه مقارنة قبل وبعد، وليست اختبار A/B، فكل ما تغير بين الفترتين يدخل في الفرق: موسم مختلف، أو حملة تسويق، أو نوع مختلف من العيادات سجل في الأسبوع الثاني. والدلالة الإحصائية Statistical Significance لا تحل هذه المشكلة، فهي تقول إن الفرق ليس صدفة، ولا تقول إن قائمة البداية سببه.
• والطريقة الأنسب كانت أن يطلق ال Feature Flag القائمة لنصف العيادات الجديدة عشوائياً في نفس الفترة، ثم نقارن المجموعتين، وهنا يظهر سبب إضافة خاصية onboarding للحدث: هي التي تسمح بهذه المقارنة دون تغيير الكود.
• وتذكر أن هذه البيانات تجريبية وضعنا فيها الفرق بأنفسنا لنشرح الطريقة، والنسب ليست مرجعاً لأي منتج حقيقي.

المسار المهني Career Path لمهندس المنتج

المسمى نفسه جديد نسبياً، ولا يوجد مسار موحد له، ولكن ما تنشره الشركات يعطي صورة: Linear مثلاً تعلن عن وظائف Product Engineer وSenior / Staff Product Engineer ضمن الهندسة لا ضمن إدارة المنتج Product Management، أي أن المسار هندسي Engineering Track، ويرتفع فيه المهندس بحجم المشكلات التي يملكها: من ميزة، إلى مجال كامل في المنتج، إلى منتج جديد من الصفر. وما يلي رأينا، لا نتيجة دراسة: المهندس الذي يبني هذه العادات يفتح أمامه أكثر من طريق، فقد يبقى في المسار الهندسي إلى Staff، أو يصبح أول مهندس في شركة ناشئة، أو ينتقل إلى إدارة المنتج إذا وجد أنه يحب الجزء الثاني أكثر، أو يؤسس شركته، والسبب أن كل هذه الطرق تحتاج إلى نفس الشيء: أن تعرف لماذا تبني ما تبنيه، وأن تعرف هل نجح.

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

أخطاء شائعة عند الانتقال إلى هندسة المنتج Product Engineering

• المسمى دون الصلاحية Ownership: تغير الشركة اسم الوظيفة إلى Product Engineer، ثم تستمر التذاكر في الوصول بحلول جاهزة وتواريخ، والعلاج أن يعطى الفريق مشكلة ونتيجة مطلوبة كما شرحنا في المخرجات والنتائج.
• المطور الذي يقرر كل شيء وحده: من يملك النتيجة يشرك المصمم Designer ومدير المنتج في القرار، والسبب أن كل منهم يرى خطراً مختلفاً من المخاطر الأربع.
• الأحداث بعد الإطلاق: تطلق الميزة ثم تتذكر أنك لا تعرف كيف تقيسها، والعلاج سطر في تعريف الإنجاز Definition of Done: «الأحداث موجودة ومختبرة قبل الإطلاق».
• قراءة قبل وبعد كأنها تجربة: الفرق بين فترتين ليس دليلاً على السبب، كما رأينا في المثال.
• عدم الحذف: الميزة التي فشلت تبقى لأن أحداً لا يريد أن يعترف، والعلاج أن يكون الحذف أحد القرارات الثلاثة المكتوبة في آخر الدورة.
• كل شيء من الصفر: مهندس المنتج الذي يبني خدمة Flags أو تحليلات خاصة به بدل استخدام ما في الشركة يضيع وقت المنتج على البنية.

قائمة تحقق Checklist لمطور يريد أن يعمل كمهندس منتج

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

وفي المقال التالي والأخير في هذه المرحلة سوف نبني بإذن الله المختبر الذي استخدمنا منه هذا المثال، ونختار المقاييس الصحيحة لمنتجك من مقياس النجم الشمالي North Star إلى قمع التحويل وجداول العودة.

دليلإدارة المنتج: ماذا يفعل مدير المنتج Product Manager؟الفرق بين مدير المنتج ومدير المشروع ومالك المنتج Product Owner، وكيف يختار مدير المنتج ما يبنى ويرتب أولوياته ويقيس نتيجته.دليلماذا تبني قبل أن تبنيه؟ اكتشاف المنتج Product Discoveryكيف تتحقق من المشكلة والحل بمقابلات ونماذج أولية Prototypes وتجارب رخيصة قبل أن يكتب فريقك سطراً واحداً من الكود.دليلمقاييس المنتج Product Metrics وكيف تعرف أن الميزة نجحتكيف تختار مقياساً رئيسياً North Star لمنتجك، وتبني قمع التحويل Funnel وجدول العودة Retention من أحداث تطبيقك بأدوات تستضيفها على سيرفرك.دليلFeature Flags: انشر الكود وفعل الميزة لاحقاًكيف يفصل ال Feature Flag بين نشر الكود وإطلاق الميزة، وكيف تطلقها لجزء من المستخدمين أولاً وتوقفها فوراً إذا تعطلت.دليلTrunk-Based Development: فروع قصيرة ودمج يوميلماذا تنفجر الفروع الطويلة يوم الإصدار، وكيف يدمج الفريق عمله في main كل يوم بأمان مع CI وFeature Flags.دليلAgile في عصر الذكاء الاصطناعي: ما الذي تغير فعلاً؟ما الذي تقوله الأبحاث عن الذكاء الاصطناعي في فرق البرمجيات، وكيف تعدل طريقة عمل فريقك في Scrum وKanban دون أن تخسر الجودة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من كتيب Product Engineer Handbook ودليل الهندسة في PostHog، وإعلان وظيفة Product Engineer وصفحات Linear Method، ومقال Gergely Orosz، مع مثال قبل وبعد من بيانات تجريبية في PostgreSQL 17.11 واختبار z بسكربت Node.js 22.23.3.