malik7mb7.com عيّنة مجانية
عيّنة مجانية — نصّ الدرس الأول كاملاً

طلب برمجة مخصصة — من فكرة إلى نظام

أغلب مشاريع البرمجيات لا تفشل تقنياً. تفشل لأن الطرفين وقّعا وهما يتخيّلان شيئين مختلفين، أو لأن أحداً لم يكن موجوداً ليقرّر، أو لأن كلمة «تمّ» كان لها معنيان.

الدرس 1 / 8

لماذا تفشل مشاريع البرمجيات — وأين يقع دورك

بنهاية هذا الدرس ستكون قادراً على:

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

هو عن الدور الذي تلعبه أنت في مشروع برمجي — الدور الذي يقرّر نتيجته أكثر مما يقرّرها أي

اختيار تقني.

من أنا ولماذا يهمّك ذلك

أنا أبني هذه الأنظمة. يعني أنني الطرف الذي ستتعامل معه، وهذا سبب وجيه لتشكّ في نصيحتي.

فلأقلها من البداية: كثير مما سأعلّمك إياه هنا يجعل التعامل معي أصعب — ستكتب نطاقاً

محدّداً يمنعني من التوسّع فيه، وستطلب معايير قبول تُقاس عليّ، وستحتفظ بدفعة أخيرة حتى

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

أين تفشل المشاريع فعلاً

الفشل نادراً ما يكون تقنياً. في الغالب يقع في واحدة من أربع:

نطاق غامض. «نريد نظاماً يدير المبيعات» جملة يفهمها كل شخص بطريقة. الطرفان يوقّعان وهما

يتخيّلان شيئين مختلفين، ويكتشفان ذلك عند التسليم.

تغيّر الطلب أثناء البناء. ليس التغيير في ذاته مشكلة — المشكلة أن يُعامَل كأنه مجاني.

كل تغيير له كلفة وقت وكلفة مال، وحين لا يُحسَبان يتأخر المشروع ويتوتّر الطرفان.

غياب صاحب قرار. المطوّر يسأل سؤالاً فلا يجد من يجيب، أو يجد ثلاثة يجيبون بثلاثة أجوبة.

كل يوم انتظار هو يوم يضيع.

«تمّ» بمعنيين. المطوّر يعني «كتبتُ الميزة»، والعميل يعني «تعمل عندي كما تخيّلتها».

لاحظ أن ثلاثاً من هذه الأربع تقع في ملعبك أنت. هذه هي الأخبار الجيدة: ما يقع في ملعبك

تستطيع إصلاحه.

دورك الحقيقي

ليس أن تفهم التقنية. دورك أربعة أشياء:

  1. أن تصف ما يجب أن يحدث في عملك، بدقة كافية لألّا يُفهَم بطريقتين.
  2. أن تقرّر حين يُسأل، وبسرعة.
  3. أن تختبر ما يُسلَّم، بنفسك أو بمن سيستخدمه.
  4. أن تحمي نفسك في العقد بما تملكه وما تستطيع الخروج به.

كل درس بعد هذا يعالج واحدة من هذه.

الوهم الذي يكلّف كثيراً

«المطوّر خبير، هو أدرى بما أحتاج».

هو أدرى كيف يُبنى، وأنت أدرى ماذا يجب أن يُبنى. لا أحد في العالم يعرف عملك مثلك.

حين تسلّم القرار لمن لا يعرف تفاصيل يومك، تحصل على نظام منطقي وجميل ولا يشبه عملك.

ثلاثة أسئلة قبل أن تبني أصلاً

قبل أن تكمل الكورس، اسأل نفسك ثلاثة أسئلة قد تنهيه مبكراً — وهذا توفير لا خسارة:

1. هل توجد أداة جاهزة تحلّ 80% من مشكلتي؟ كثير مما يُطلب بناؤه موجود ويُشترى باشتراك

شهري بسيط. بناء ما هو مبني قرار مكلف يحتاج مبرّراً. المبرّر المقبول: أن الـ20% الباقية هي

ميزتك التنافسية فعلاً، لا مجرد اختلاف في العادة.

2. هل مشكلتي في المعلومة أم في الإجراء؟ إن كان الطلبات تضيع لأن لا أحد مسؤول عن متابعتها،

فالنظام سيوثّق ضياعها بدقّة. الإجراء يُصلَح بقرار إداري لا ببرمجة، والبرمجة بعده تكون أنفع

بكثير.

3. هل عملياتي مستقرة؟ إن كنت تغيّر طريقة عملك كل شهرين، فستبني نظاماً على شكل تتخلّى عنه

قبل أن ينتهي. التأجيل ستة أشهر قرار مشروع.

جواب «لا» على الثاني أو الثالث يعني: أوقف المشروع الآن. أنا أفضّل أن أقول لك هذا هنا على أن

نكتشفه معاً بعد ثلاثة أشهر.

ما ستخرج به من هذا الكورس

وثيقة. كرّاسة متطلبات مكتوبة بيدك تصلح لإرسالها إلى أي مطوّر — أنا أو غيري. الدروس الثمانية

تبنيها قطعة قطعة، والدرس الأخير يجمّعها.

قبل أن تكمل

اكتب في سطر واحد: ما المشكلة التي تريد حلّها بهذا النظام؟ لا الحل — المشكلة. سنعود إلى هذا

السطر أكثر من مرة.

قرأت العيّنة كاملة — والباقي بانتظارك

ما قرأته الآن جزء واحد فقط. النسخة الكاملة فيها:

اشترك الآن