فيزياء مشاريع البرمجيات
الأشخاص، الجدول الزمني، نطاق المشروع
تخيل معايا انك شغال على مشروع مع فريق مكوّن من 5 أفراد، وكل حاجة متقسمة بشكل واضح:
milestones، features، components، epics، وstories،
ومعاها timeline محدد.
كل حاجة ماشية تمام لحد ما يحصل موقف زي دول:
حد من الفريق يسيب المشروع.
الشركة تواجه تحديات وتحتاج المشروع يخلص أسرع من اللي كان مخططله.
نطاق المشروع يكبر، ويتطلب إضافة مزايا جديدة.
التحديات الرئيسية:
المواقف دي بتأثر على 3 عوامل أساسية في أي مشروع:
الأشخاص (People)
الجدول الزمني (Timeline)
نطاق المشروع (Scope)
لما عامل من العوامل دي يتغير، التوازن بيتأثر، وعلشان تحل المشكلة لازم تعدّل واحد من العوامل التانية. مثلا:
لو عدد الأشخاص قل، الشغل هيحتاج وقت أطول.
لو الوقت قل، لازم تقلل نطاق الشغل أو تضيف ناس أكتر (وده مش دايمًا فعال).
لو نطاق المشروع كبر، هيحتاج يا إما وقت أكتر أو ناس زيادة.
ليه إضافة ناس زيادة مش دايمًا الحل؟
ممكن تسأل ليه ما نضيفش ناس جدد؟ هنا بيظهر مفهوم "قانون بروكس" اللي بيقول:
"إضافة أعضاء لفريق في مشروع متأخر بيخليه يتأخر أكتر."
ده لأن إضافة أعضاء جدد متأخر في المشروع بيكلف وقت ومجهود في تدريبهم، وتعريفهم بالسياق، وتوفيقهم مع الفريق. غالبًا، الوقت اللي هيكونوا فيه منتجين هيبقى المشروع قرب يخلص، فالفايدة بتكون قليلة جدًا.
تقليل تأثير التحديات:
علشان تقلل من تأثير السيناريوهات دي، ممكن تقسّم المشروع لأجزاء أصغر ومستقلة مش معتمدة على بعضها بشكل كبير. بالطريقة دي، الفريق يقدر يشتغل بالتوازي وبأقل قدر من الاعتماد المتبادل. لكن الوصول لتقسيم بالمستوى ده بيكون صعب خاصة في المراحل الأولى من التخطيط.
نصيحة إضافية:
لو السيناريوهات دي مألوفة ليك، جرّب تقرأ The Software Engineer’s Guidebook، الكتاب ده فيه أفكار ممتازة عن إدارة المشاريع البرمجية.إنت إيه رأيك؟ حصل معاك مواقف زي دي في مشاريعك؟
المقالة الأصلية:
