چھ ہفتوں پر محیط ریلیز (release) کا تیسرا ہفتہ ہے اور آپ کی سافٹ ویئر ٹیم تعطل کا شکار ہے۔ پروڈکٹ مینیجر کو کسٹمر ڈیمو کے لیے ایک حتمی تاریخ درکار ہے، انجینئرنگ مینیجر نقائص (defects) کی تعداد میں اچانک اضافے سے خبردار کر رہا ہے، اور QA ٹیم پہلے ہی راتوں کو کام کر رہی ہے۔ دو انجینئرز میں سے ہر ایک کو تین مختلف اقدامات (initiatives) سونپے گئے ہیں، پروڈکشن سپورٹ کی روٹیشن انہیں بار بار کام سے ہٹا دیتی ہے، اور ڈیزائنر کا وقت دو مختلف ٹیموں (squads) کے درمیان تقسیم ہے۔ جس فیصلے پر تعطل ہے، وہ کاغذ پر تو سادہ معلوم ہوتا ہے: کیا آپ مقررہ تاریخ برقرار رکھتے ہوئے کام کا دائرہ کار (scope) کم کریں گے، یا دائرہ کار برقرار رکھتے ہوئے تاریخ آگے بڑھائیں گے، یا پھر ایسی اضافی صلاحیت (capacity) شامل کریں گے جو درحقیقت آپ کے پاس موجود ہی نہیں؟ آپ جتنے دن انتظار کرتے ہیں، دوبارہ کام (rework) بڑھتا ہے اور اعتماد کم ہوتا ہے۔ یہ کورس آپ میں ایسی عادات اور طریقہ کار (artifacts) پیدا کرتا ہے جو آپ کو اس تعطل سے نکالتے ہیں۔ آپ شیڈول میں وسائل کی پوشیدہ ضروریات کو سمجھنا سیکھیں گے، صلاحیت کا ایسا ماڈل بنائیں گے جو لوگوں کے حقیقی کام کرنے کے انداز سے مطابقت رکھتا ہو، اور AI کا استعمال کرتے ہوئے ایسے متبادل تیار کریں گے جن پر آپ متعلقہ اسٹیک ہولڈرز کے ساتھ بات چیت کر سکیں۔
اس کی پہلی علامت ‘گینٹ چارٹ’ (Gantt chart) نہیں، بلکہ کام میں بار بار آنے والی رکاوٹوں کا تسلسل ہے۔ مثال کے طور پر، ایک انجینئر کسی فیچر پر کام شروع کرتا ہے لیکن اسے ‘Sev 2’ (اہم نوعیت) کے کسی مسئلے کو حل کرنے میں لگا دیا جاتا ہے؛ پھر وہ واپس آ کر ‘مرج کنفلکٹس’ (merge conflicts) کو حل کرتا ہے، اور اس کے فوراً بعد کسی دوسرے پروجیکٹ کے لیے ‘کوڈ ریویو’ (code review) کی جلدی کرتا ہے کیونکہ اس کی وجہ سے ٹیم کے کسی ساتھی کا کام رکا ہوا ہوتا ہے۔ اس کے نتیجے میں ‘مائل اسٹون’ (اہم سنگِ میل) کا وقت نکل جاتا ہے اور ٹیم ٹیسٹنگ (tests) کو چھوڑ کر اس کمی کو پورا کرنے کی کوشش کرتی ہے۔ ایک ہفتے بعد نقائص (defects) بڑھ جاتے ہیں، QA (کوالٹی ایشورنس) کا مرحلہ رکاوٹ (bottleneck) بن جاتا ہے، اور ‘ریلیز کینڈیڈیٹ’ (release candidate) کی تیاری میں مشکلات پیدا ہوتی ہیں۔ کام کی زیادتی اور ذہنی دباؤ (burnout) کا اظہار کام کے طویل دورانیے (cycle time)، کام کی منتقلی میں کمزوری (brittle handoffs)، اور اصل کام کرنے کے بجائے کام کی پیش رفت کے بارے میں پوچھ گچھ میں زیادہ وقت صرف ہونے کی صورت میں ہوتا ہے۔
پروجیکٹ مینیجر (PM) کی ایک عام غلطی اسے محض ‘کام کی تکمیل’ (execution) کا مسئلہ سمجھنا ہے۔ یہ سوچ اس لیے درست لگتی ہے کیونکہ آپ مزید ‘اسٹینڈ اپ’ (standup) میٹنگز بلا سکتے ہیں، ‘جیرا’ (Jira) کے استعمال کو سخت کر سکتے ہیں اور ٹیم کو کام پر توجہ مرکوز کرنے کے لیے کہہ سکتے ہیں۔ لیکن اس کا نتیجہ یہ نکلتا ہے کہ آپ انہی لوگوں پر، جنہیں پہلے ہی ضرورت سے زیادہ کام سونپا جا چکا ہے، باہمی رابطے اور ہم آہنگی (coordination) کا بوجھ مزید بڑھا دیتے ہیں۔ اصل مسئلہ یہ ہے کہ شیڈول (time schedule) ایسے ہفتوں میں، افرادی قوت کے اتنے گھنٹوں (person-hours) کا تقاضا کر رہا ہے جو ٹیم معیار (quality) پر سمجھوتہ کیے بغیر فراہم نہیں کر سکتی۔
جب آپ لوگوں کو کام تفویض کرتے ہیں، تو آپ محض خانوں کو پُر نہیں کر رہے ہوتے بلکہ حدود و قیود (constraints) کے ایک مسئلے کو حل کر رہے ہوتے ہیں۔ اسکوپ (Scope) سے مراد وہ کام ہے جس کا آپ نے وعدہ کیا ہے۔ شیڈول (Schedule) سے مراد وہ وقت ہے جب یہ کام مکمل ہونا چاہیے۔ صلاحیت (Capacity) سے مراد کام کے وہ قابلِ استعمال گھنٹے ہیں جو ٹیم ہر ہفتے فراہم کر سکتی ہے۔ مہارتیں (Skills) اس بات کا تعین کرتی ہیں کہ کون سے لوگ، کس قسم کے کام کو، ناقابلِ قبول خطرے کے بغیر انجام دے سکتے ہیں۔ دستیابی کے مفروضے (Availability assumptions) وہ پوشیدہ عوامل یا اصول ہیں—جیسے ‘آن کال’ ڈیوٹی، میٹنگز، اور مشترکہ خدمات (shared services) کی درخواستیں—جو کام کی مجموعی صلاحیت کو کم کر دیتے ہیں۔
کسی بھی اقدام کا انتخاب کرنے سے پہلے، یہ اندازہ لگائیں کہ آپ کی صورتحال میں اصل رکاوٹ یا حد (constraint) کون سی ہے: شیڈول، مہارتیں، یا دستیابی۔
اس بات کی اہمیت کی وجہ یہ ہے کہ ایک ہی مسئلے کی علامات کے پیچھے مختلف وجوہات ہو سکتی ہیں۔ سافٹ ویئر کی فراہمی (delivery) کے عمل میں، اکثر مہارتوں کی کمی یا محدود دستیابی (skills constraints) کا مسئلہ حاوی رہتا ہے؛ مثال کے طور پر، ہو سکتا ہے کہ ‘ڈیپلائمنٹ پائپ لائن’ (deployment pipeline) کے بارے میں معلومات صرف ایک ہی شخص کے پاس ہوں۔ مارکیٹنگ مہم کے معاملے میں، سب سے بڑی رکاوٹ بیرونی تقریبات سے منسلک کیلنڈر کی تاریخیں ہو سکتی ہیں۔ صحت کی دیکھ بھال کے آپریشنز کے نفاذ (rollout) کے دوران، عملے کی تعداد مناسب ہونے کے باوجود، تربیت کے وقت اور شفٹ کوریج جیسی دستیابی کی ضروریات کام میں رکاوٹ بن سکتی ہیں۔ آپ کا کام اس رکاوٹ کی نشاندہی کرنا اور پھر ایسا حل اختیار کرنا ہے جو اس رکاوٹ کو دور یا تبدیل کرے، نہ کہ صرف مزید دباؤ بڑھائے۔
جب تک آپ کو یہ معلوم نہ ہو کہ آپ کے پاس اصل میں کتنے وسائل موجود ہیں، آپ ان کا درست توازن (leveling) قائم نہیں کر سکتے۔ کپیسٹی ماڈل (capacity model) سے مراد ہر کردار (role) کے لیے ہفتہ وار قابلِ استعمال گھنٹوں کا وہ واضح تخمینہ ہے جو پروجیکٹ کو آگے نہ بڑھانے والے اوقات کو منہا کرنے کے بعد حاصل ہوتا ہے۔ شروعات کل مقررہ گھنٹوں (nominal hours) سے کریں۔ اس میں سے چھٹیوں (PTO) اور عام تعطیلات کا وقت نکال دیں۔ طے شدہ میٹنگز اور دیگر رسمی سرگرمیوں کا وقت بھی منہا کر دیں۔ پھر اس پر ‘فوکس فیکٹر’ (focus factor) کا اطلاق کریں؛ یعنی بقیہ وقت کا وہ تناسب جو کام میں خلل اور باہمی رابطے (coordination) کے باوجود حقیقت پسندانہ طور پر پروجیکٹ کے منصوبہ بند کام پر صرف کیا جا سکتا ہے۔ آخر میں، مشترکہ خدمات (shared services) جیسے کہ ‘پروڈکشن سپورٹ’ یا ایسی اندرونی درخواستیں جنہیں نظر انداز نہیں کیا جا سکتا، ان کے لیے درکار وقت کو بھی منہا کر دیں۔
‘بلڈر’ (builder) ٹول کا استعمال کرتے ہوئے ‘سپرنٹ کپیسٹی پلان’ (sprint capacity plan) کا مسودہ تیار کریں جس میں ہر کردار کے لیے چھٹیوں (PTO) اور میٹنگز کے بوجھ کو بھی شامل کیا گیا ہو۔