ليه مشروع البرمجيات بيتأخر رغم إن فريق التطوير شغال طول الوقت؟

Engineering Team شغالة.

Tickets بتتحرك.

Slack مليان Activity.

Meetings مالية Calendar.

Pull Requests بتتفتح.

ومع ذلك Release Date كل شوية تتحرك.

من زاوية CEO أو Product Leader، المشهد ممكن يكون محير:

لو كل الناس Busy، ليه الـProduct لسه متأخرة؟

لأن Activity وDelivery مش نفس الحاجة.

Software Project ممكن يكون فيها شغل كثير جدًا بينما Customer Value قليلة جدًا هي اللي توصل Production.

الوقت المفقود غالبًا مش داخل Coding. موجود بين المراحل.

أول غلطة: تقيس Effort بدل Flow

لما Project تتأخر، طبيعي الناس تسأل عن ساعات Developers وعدد Tickets وStory Points وPull Requests. Signals دي تصف Activity، لكن مش بالضرورة تشرح Elapsed Delivery Time.

Feature ممكن تحتاج 3 أيام Implementation لكن تأخذ 3 أسابيع علشان توصل Production لأنها تقضي باقي الوقت مستنية.

فبدل ما تسأل Development أخدت قد إيه، اسأل:

Work قضت قد إيه في كل Stage من Request لحد Verified Production؟

أعد بناء رحلة Feature واحدة

اختار Meaningful Feature اتشحنت مؤخرًا متأخرة واعمل Timeline:

Requested → Clarified → Approved → Designed → Started → Reviewed → Tested → Deployed → Verified

اكتب Actual Dates لو موجودة، وبعدين احسب Feature كانت Active Change إمتى وكانت Waiting إمتى.

ممكن تكتشف إن "Development أخدت 4 أسابيع" معناها فعليًا يومين Waiting على Product Answer، 4 أيام Implementation، 3 أيام Waiting for Review، 5 أيام Waiting for QA، أسبوع Waiting for Release Window، ووقت إضافي بعد Late Requirement Change.

دلوقتي Problem أصبحت قابلة للتشخيص.

تأخير 1: Requirements لسه بتتكتشف أثناء Implementation

Software Work دائمًا فيها Uncertainty. مش محتاج Giant Specification قبل كتابة Code، لكن فيه فرق بين Healthy Discovery وبين إنك تبدأ باستمرار Work محدش فاهمها بما يكفي.

لو Acceptance Criteria تظهر بعد البداية، Stakeholders متوقعين Behavior مختلفة، Designs تتغير قرب النهاية، أو Finished Work تترفض بسبب اختلاف التوقعات، فالنتيجة Rework.

Team تبدو Busy لأنها بتبني نفس Outcome أكثر من مرة.

الحل مش Documentation أكثر تلقائيًا. المطلوب Clarity كفاية حول User/Business Problem وExpected Outcome وImportant Constraints وAcceptance Boundary ومين يقدر يحسم Unresolved Product Questions.

تأخير 2: Priorities تتغير أسرع من قدرة Team على الإنهاء

خمسة Developers يبدأوا خمس Priorities، وبعدها Urgent Request تدخل فيعمل اتنين Switch، وبعد أسبوع Launch Target تتغير فيتحرك شخص ثالث.

نهاية الشهر كل الناس اشتغلت، لكن قليل هو اللي Complete.

دي Work-in-Progress Problem.

اسأل:

إحنا مستعدين نوقف إيه علشان New Priority دي تبدأ؟

لو الإجابة "ولا حاجة"، الشركة لا تعمل Reprioritization؛ هي بتراكم Parallel Work.

تأخير 3: كل Work مستنية Senior Engineer واحدة

شخص واحد يعمل Review للImportant Code، يفهم Production، يعرف Legacy System، ويقدر Approve Architecture. الشخص ده يتحول Queue.

دور على Pull Requests مستنية نفس Reviewer، Repeated Questions لنفس الشخص، Deployments تتعطل في غيابه، وComponents شخص واحد فقط آمن يغيرها.

Long-term Fix هي Distribution للKnowledge وDecision Rights، مش إن Senior Engineer تشتغل أسرع.

تأخير 4: Code Review تحولت Approval Queue

Review Process ممكن تتحول Queue لما ناس قليلة جدًا تقدر Approve، Pull Requests كبيرة، Expectations غير واضحة، أو كل Change تحتاج عدة Approvals مهما كان Risk.

قِس Time to First Meaningful Review. Pull Request مستنية 3 أيام قبل ما حد يفتحها Flow Problem.

تأخير 5: QA بتحصل Batch كبيرة في الآخر

Pattern شائعة:

Build لأسابيع → QA لكل شيء → Problems كثيرة → رجوع Development → Retest

Smaller Testable Changes تعمل Feedback أسرع. ده لا يعني إلغاء QA؛ معناه تقريب Quality من Development باستخدام Automated Tests وDeveloper Testing وCI وSmaller Releases وEarlier Acceptance Checks وRisk-based Manual Testing.

Quality جزء من Delivery System، مش Department في آخرها.

تأخير 6: Deployment نفسها Project

لو Release تحتاج Special Day وعدة أشخاص وLong Checklist وخوف، Deployment Process بتستهلك Capacity.

Large Release Windows وManual Server Changes وEnvironment Differences وDifficult Rollbacks وفترات طويلة بين Deployments كلها Signals.

CI/CD وAutomation وObservability وSmaller Releases ممكن تغير Economics الـDelivery بشكل كبير.

تأخير 7: Architecture تخلي كل Change تلمس كل حاجة

Feature تبدو صغيرة، ثم تحتاج Changes في Modules وServices وShared Database قديمة.

Architecture Debt تظهر كDelivery Delay: Small Features بـLarge Blast Radius، Regressions غير مرتبطة، Teams بتBlock بعض، وSynchronized Releases.

الحل مش Microservices عشوائيًا. الهدف Clearer Boundaries وSafer Change.

تأخير 8: Production Incidents بتسرق Planned Capacity

Roadmap تفترض إن Engineers متاحين للFeatures، لكن كل أسبوع يضيع وقت في Bugs وCustomer Escalations وFailed Deployments وData Fixes وInfrastructure Problems.

Track Unplanned Work بوضوح. لو Recurring Incidents تستهلك Capacity، Fix Root Causes جزء من Product Delivery Work.

تأخير 9: Dependencies تظهر متأخر

Feature قربت تخلص وبعدين نكتشف Legal Approval أوAPI من Team ثانية أوMobile Release أوData Migration أوVendor Approval أوSecurity Review.

اسأل أثناء Planning:

إيه اللي لازم يكون صحيح خارج Code علشان Feature دي توصل Customer؟

السؤال ده يظهر Dependencies بدري.

تأخير 10: Handoffs أكثر من اللازم

Product → Design → Frontend → Backend → DevOps → QA → Product.

كل Handoff تعمل Queue وContext Loss وCoordination وفرصة لسوء الفهم.

Specialization أحيانًا ضرورية، لكن Excessive Functional Handoffs تخلي Small Change تمشي في Organization كأنها ورق حكومي.

تأخير 11: Estimates يتم التعامل معها كPromises رغم Uncertainty

Estimate Model مبنية على اللي Team تعرفه حاليًا. المشاكل تبدأ لما Rough Estimate تتحول Fixed Date، Scope تكبر بدون تحريك Date، أو New Information تظهر بدون Update للPlan.

Good Planning لا تتظاهر إن Uncertainty غير موجودة؛ تقللها وتحدث Decisions لما Evidence تتغير.

تأخير 12: Project كبيرة جدًا علشان تنتج Feedback

Project ست شهور ممكن تحتوي مئات Assumptions. لو Customer لن يرى شيء حتى النهاية، Team ممكن تقضي شهور غلط بدون ما تعرف.

بدل "Build New Operations Platform"، قسمها Outcomes مثل:

Import Orders → Assign Ownership → Track Status → Notify Customer → Add Reporting

كل Step تعلم Team قبل اكتمال Platform كلها.

Busy ممكن تخفي Blocked

Blocked Engineer غالبًا تبدأ Task ثانية بدل ما تقعد. وبعدها الثانية تتBlock. فجأة Team عندها حاجات كثيرة In Progress وActivity عالية، لكن Completion بطيئة.

Maximum Individual Utilization مش الهدف. الهدف Healthy Flow لـValuable Work.

Busy ممكن تخفي Rework

Team ممكن تنتج Code كثير لأنها تستبدل Code كتبته الأسبوع الماضي.

Track سبب Reopened Work: Defect؟ Misunderstood Requirement؟ Late Design Change؟ Integration Surprise؟ Missing Acceptance Criteria؟

تقليل Avoidable Rework يخلق Capacity بدون Hiring.

CEO مش محتاج يدير Jira

Leadership لازم تفهم Delivery بدون Micromanagement.

اسأل:

• إيه Top Outcomes الموجودة In Progress؟
• إيه Blocked وبقاله قد إيه؟
• أنهي Decision مطلوبة ومن مين؟
• إيه Unplanned Work غيرت Plan؟
• إيه اللي اتعمل له Release مؤخرًا؟
• اتعلمنا إيه بعد Release؟

دي أسئلة عن Flow وDecisions، مش Surveillance.

Engineering Leader المفروض تخلي إيه Visible؟

Current Priorities، Major Technical Risks، Delivery Constraints، Important Dependencies، Unplanned Work، Architecture Decisions ذات Business Impact، وإيه اللي تغير في Forecast وليه.

Bad News توصل بدري Useful Information. Bad News مخفية لحد Deadline Expensive.

اعمل Delivery Timeline مش Sprint Report فقط

لسample من Important Features سجل Requested، Ready، Development Started/Completed، Review، QA، Production Release وOutcome Verified.

وبعدين افحص Gaps. أكبر Opportunity ممكن لا تكون Coding Speed أصلًا.

Metrics مفيدة — بحذر

Team-level Signals مثل Lead Time for Changes، Deployment Frequency، Change Failure Patterns، Recovery Patterns، Review Wait Time، Work in Progress، Reopened Work وPlanned vs Unplanned Work ممكن تساعد Investigation.

ما تستخدمش Metric واحدة كIndividual Developer Productivity Score.

ليه إضافة Developers ممكن تأخر Project المتأخرة أكثر؟

New Engineer تعمل Short-term Cost قبل Long-term Capacity: Onboarding وPairing وReviews وEnvironment Setup وDomain Learning وCoordination.

لو Deadline قريبة، Hiring قد لا تحلها. Hiring Organizational Investment، مش Emergency Speed Button.

إمتى Hiring فعلًا تكون الإجابة؟

لما Priorities واضحة، Work مش Blocked بشكل مبالغ، Reviews وDeployment Flow كويسين، Architecture تدعم Parallel Work، Unplanned Work تحت Control، ولسه Validated Work أكثر من قدرة Team المستدامة.

هنا Hiring عندها Case قوي، وأنت عارف Capability المطلوبة.

Delivery Audit عملية

لو براجع Delayed Software Project، أبدأ Evidence:

1. اختار Meaningful Recent Features وBugs وIncidents.
2. أعد بناء Timelines وحدد Active vs Waiting Time.
3. صنف Blockers: Product، Technical Decision، Review، QA، Dependency، Infrastructure، Approval أو Incident.
4. قِس ليه Completed Work رجعت.
5. افحص Started Work مقابل Finishing Work.
6. ارسم مين يقدر يعمل كل Recurring Decision.
7. افحص صعوبة نقل Small Change بأمان إلى Production.
8. قارن Plan بالUnplanned Work التي استهلكت Capacity.

في النهاية لازم تقدر تسمي Major Constraints بدل "Engineering بطيئة".

ما تعملش Optimize لكل Stage مرة واحدة

لو Development 3 أيام، Review Wait 4 أيام، QA Wait 6 أيام وDeployment Wait يوم، جعل Developers أسرع 20% بالكاد يغير Total Lead Time.

اضرب Largest Meaningful Constraint الأول، وبعدها Measure ثاني.

Delivery Problems غالبًا System Problems

Delivery تمر عبر Product وEngineering وDesign وQA وInfrastructure وManagement وأحيانًا Sales وLegal وVendors.

Local Team ممكن تكون Efficient بينما Complete System بطيئة.

علشان كده Senior Technical Leadership لازم تعمل Optimize للPath to Production، مش Developer Output فقط.

سؤال أفضل للStatus Meeting الجاية

بدل:

"ليه لسه ما خلصناش؟"

اسأل:

"Work مستنية فين، وأنهي Decision أو System Change ممكن تشيل الانتظار ده؟"

Team عندك Busy والProduct لسه متأخرة؟

أقدر أساعدك تعيد بناء Real Delivery Flow عبر Product وEngineering وArchitecture وQA وProduction، نحدد الوقت بيروح فين، ونفصل Capacity Problems عن Process وTechnical Leadership Problems.

ناقش Software Delivery أو Engineering Leadership Review مع فادى مندي.

الهدف مش نخلي Developers شكلها Busy أكثر. الهدف نخلي Valuable Software توصل Production بWaiting وRework وAvoidable Risk أقل.

---

مرتبط: Engineering Leadership، Product Engineering، Fractional CTO، Engineering Architecture، Custom Software Development، ومقال هل فريق التطوير محتاج Developers أكثر أم Technical Leadership أقوى؟