ویب سائٹ کی تجدید و آرائش (revamp) کے چھ ہفتوں پر محیط منصوبے کے تیسرے ہفتے میں، قانونی مشیر پروجیکٹ مینیجر کو مطلع کرتے ہیں کہ ایک نئے ضابطے کی وجہ سے ‘کوکی کنسنٹ’ (cookie consent) کے مطلوبہ عمل میں تبدیلی کرنی ہوگی۔ ڈیزائن ٹیم پہلے ہی وائر فریمز (wireframes) کی منظوری دے چکی ہے، انجینئرنگ ٹیم تعمیر کا کام شروع کر چکی ہے، اور مارکیٹنگ ٹیم لانچ کے اعلان کا وقت بھی طے کر چکی ہے۔ اب ٹیم ایک فیصلے پر اٹک گئی ہے: کیا کام روک کر نئے سرے سے منصوبہ بندی کی جائے، یا کام جاری رکھا جائے اور تبدیلی کو بعد میں شامل کیا جائے؟ فیصلے میں ہر گزرتے دن کے ساتھ دوبارہ کام (rework) کا بوجھ بڑھتا جاتا ہے اور اعتماد کم ہوتا ہے کیونکہ کوئی بھی یہ نہیں بتا سکتا کہ لانچ کی نئی تاریخ کا کیا مطلب ہوگا۔ یہ کورس آپ کو وہ عملی طریقے سکھاتا ہے جن سے آپ اس تعطل سے نکل سکتے ہیں۔ آپ سیکھیں گے کہ فیڈ بیک کے مختصر دورانیے (short feedback loops) کیسے کام کرتے ہیں، ہفتہ وار حقیقت پسندانہ اہداف کے تعین کے لیے ‘بیک لاگ’ (backlog) اور ‘سپرنٹ’ (sprint) کا استعمال کیسے کیا جائے، شفاف دستاویزات کے ذریعے اسٹیک ہولڈرز کو کیسے ہم آہنگ رکھا جائے، اور ہر نئی درخواست کو بحران (crisis) میں تبدیل کیے بغیر تبدیلیوں کو کیسے سنبھالا جائے۔
یہ دیکھنے کے لیے کہ فیڈ بیک سست ہونے پر کیا خرابیاں پیدا ہوتی ہیں، آپ ایک سادہ پروجیکٹ ٹائم لائن پر کام کریں گے جس میں کام کے دوران ہی کسی ضرورت (requirement) میں تبدیلی آتی ہے اور ٹیم کو اسے اپنے کام کا حصہ بنانا پڑتا ہے۔
بات یہ نہیں ہے کہ منصوبہ بندی (planning) بری چیز ہے۔ اصل مسئلہ یہ ہے کہ جب کئی ہفتوں کے کام کے بعد نئی معلومات یا سمجھ بوجھ (learning) حاصل ہوتی ہے، تو منصوبے کو اپ ڈیٹ کرنا مہنگا پڑتا ہے۔
ایسا منصوبہ جو مستقل اور غیر تبدیل شدہ تقاضوں (stable requirements) کو بنیاد بناتا ہے، دراصل ایک بہت بڑا جوا کھیلنے کے مترادف ہوتا ہے۔ آپ شروع میں ہی تمام تقاضے طے کر لیتے ہیں، پورے منصوبے کا تخمینہ لگاتے ہیں، اور پھر حتمی ڈیلیوری (handoff) کی طرف کام کرتے ہیں۔ جب تیسرے ہفتے میں کوئی قانونی تقاضا سامنے آتا ہے، تو ٹیم کے پاس دو برے متبادل ہوتے ہیں۔ پہلا متبادل یہ ہے کہ تبدیلی کو روک دیا جائے اور ایسا کام آگے بڑھایا جائے جو تقاضوں کے مطابق نہیں ہے؛ اس سے آپریشنل خطرات پیدا ہوتے ہیں اور دباؤ کے عالم میں بعد ازاں مزید کام (follow-up work) کرنا پڑتا ہے۔ دوسرا متبادل یہ ہے کہ تبدیلی کو قبول کر لیا جائے اور پرانے فیصلوں پر نظر ثانی کی جائے؛ اس سے دوبارہ کام (rework) کرنا پڑتا ہے کیونکہ UI، ٹریکنگ، مواد اور ٹیسٹ اسکرپٹس پرانے طریقہ کار (flow) کے مطابق بنائے گئے تھے۔ یہاں ناکامی کی وجہ محنت کی کمی نہیں، بلکہ معلومات یا سمجھ بوجھ کا تاخیر سے حاصل ہونا ہے۔ پروجیکٹ کو کوئی اہم حقیقت معلوم تو ہوتی ہے، لیکن اتنی دیر سے کہ منصوبے میں اسے کم خرچ یا آسانی کے ساتھ شامل کرنا ممکن نہیں رہتا۔
عام غلطی پروجیکٹ کے دوران آنے والی کسی تبدیلی کو محض ایک ‘استثنائی واقعہ’ (one-time exception) سمجھنے سے پوشیدہ طور پر دوبارہ کام (rework) کا بوجھ بڑھ جاتا ہے، اور پھر شیڈول میں تاخیر ہوتی ہے جو منصوبہ بندی کی خامی کے بجائے ناقص عمل درآمد (poor execution) کا تاثر دیتی ہے۔
Agile (ایجائل) کا طریقہ کار ‘سیکھنے کے عمل’ (learning) کو کم خرچ بنا کر اس مسئلے کا حل پیش کرتا ہے۔ یہ مختصر دورانیے کے چکروں (cycles) کے ذریعے ممکن ہوتا ہے جن میں آپ کام کے ایک چھوٹے حصے کی منصوبہ بندی کرتے ہیں، اسے تیار کرتے ہیں، اسٹیک ہولڈرز کے ساتھ اس کا جائزہ لیتے ہیں، اور مزید کام کا بوجھ ڈالنے سے پہلے حالات کے مطابق تبدیلی (adapt) لاتے ہیں۔
Agile کوئی سخت اصولوں کی کتاب نہیں ہے۔ یہ اقدار کا ایک ایسا مجموعہ ہے جو آپ کو ایسے رویوں کی طرف راغب کرتا ہے جن سے غیر متوقع مسائل (surprises) کم ہوتے ہیں۔ شفافیت (Transparency) کا مطلب ہے کہ اصل صورتحال صرف سلائیڈ اپ ڈیٹس میں نہیں، بلکہ بیک لاگ (backlog)، سپرنٹ بورڈ (sprint board) اور جائزے کے قابل انکریمنٹ (reviewable increment) جیسے ذرائع میں بھی واضح نظر آئے۔ باہمی تعاون (Collaboration) کا مطلب ہے کہ فیصلے کرنے والے اور کام کرنے والے افراد کثرت سے مل کر کام کریں، تاکہ فیصلے اس وقت کیے جا سکیں جب تبدیلی لانا ابھی کم خرچ ہو۔ مطابقت پذیری (Adaptation) کا مطلب ہے کہ آپ تقاضوں میں تبدیلی کی توقع رکھتے ہیں اور جوابدہی کو برقرار رکھتے ہوئے دوبارہ منصوبہ بندی (replan) کا ایک منظم طریقہ وضع کرتے ہیں۔
ان اقدار کو اپنے مخصوص حالات پر لاگو کرنے سے پہلے، یہ اندازہ لگائیں کہ تیسرے ہفتے میں آنے والی قانونی تبدیلی کے معاملے میں کس رویے نے دوبارہ کام (rework) کی سب سے زیادہ بچت کی ہوتی۔
پریڈکٹیو (Predictive) طریقہ کار—جسے اکثر ‘واٹر فال’ (Waterfall) بھی کہا جاتا ہے—اس وقت کارآمد ہوتا ہے جب تقاضے (requirements) مستحکم ہوں اور گورننس کے تحت شروع ہی میں کام کے دائرہ کار (scope) کا تعین کرنا ضروری ہو۔ ایجائل (Agile) اس وقت موزوں رہتا ہے جب غیر یقینی صورتحال زیادہ ہو، ریلیز کی تکرار (frequency) اہم ہو، اور اسٹیک ہولڈرز فوری رائے (feedback) دینے کی صلاحیت رکھتے ہوں۔ ہائبرڈ (Hybrid) طریقہ کار ان دونوں کا امتزاج ہے؛ مثال کے طور پر، تعمیلی تقاضوں (compliance) کے لیے طے شدہ سنگِ میل (milestones) مقرر کرنا اور ہر سنگِ میل کے اندر ایجائل کے ذریعے ڈیلیوری (delivery) کو یقینی بنانا۔
پروجیکٹ مینیجر یہ انتخاب ذاتی ترجیحات کی بنیاد پر نہیں بلکہ درپیش رکاوٹوں اور حدود (constraints) کو مدنظر رکھتے ہوئے کرتا ہے۔ اس سلسلے میں تقاضوں میں غیر یقینی صورتحال، ریلیز کی ممکنہ تکرار، تعمیلی تقاضے، جائزوں (reviews) کے لیے اسٹیک ہولڈرز کی دستیابی اور ٹیم کے استحکام جیسے عوامل پر غور کریں۔ اگر اسٹیک ہولڈرز ہفتہ وار جائزے نہیں لے سکتے، تو ایجائل کے معمول کے اجلاس (ceremonies) محض ایسے اجلاس بن کر رہ جاتے ہیں جن میں کوئی فیصلہ نہیں ہو پاتا۔ اگر تعمیلی تقاضوں کے تحت کام شروع کرنے سے قبل تفصیلی منظوری درکار ہو، تو خالص ایجائل طریقہ کار گورننس کے اصولوں کی خلاف ورزی کا باعث بن سکتا ہے، الا یہ کہ اس میں پریڈکٹیو نوعیت کے کنٹرولز بھی شامل کیے جائیں۔
فیصلہ کرنے کے لیے موزونیت کے اشاروں (fit signals) کو استعمال کریں، اور پھر یہ بھی دیکھیں کہ کس مخصوص رکاوٹ یا حد نے اس فیصلے کا تعین کیا۔