اہم ترین قدم یہ ہے کہ ترجیحات کے درمیان سمجھوتوں (trade-offs) کو جلد واضح کیا جائے۔ اگر بینک کے SSO (سنگل سائن آن) مسئلے کے حل کے لیے ‘آئیڈینٹٹی ٹیم’ کی جانب سے کسی تبدیلی کی ضرورت ہو جس پر آپ کا اختیار نہیں، تو بھی آپ منصوبے، مواصلات اور متبادل لائحہ عمل (fallback path) کی ذمہ داری تو لے سکتے ہیں، لیکن محض اپنی قوتِ ارادی سے اس تبدیلی کو عملی جامہ نہیں پہنا سکتے۔
جب آپ ایک مصروفیت (engagement) سے تین کی طرف بڑھتے ہیں، تو کام تین گنا نہیں ہوتا، بلکہ انتظامی بوجھ (overhead) کئی گنا بڑھ جاتا ہے۔ اب ہر مصروفیت کی اپنی الگ میٹنگز، اسٹیک ہولڈرز، سسٹمز (environments) اور ناکامی کے ممکنہ پہلو ہوتے ہیں، اور ہر بار کام تبدیل کرنے پر آپ کو وقت اور توانائی کا اضافی نقصان (tax) اٹھانا پڑتا ہے۔
ناکامی کی تین صورتیں تیزی سے سامنے آتی ہیں۔
Thrash (بے نتیجہ بھاگ دوڑ): یہ تب ہوتا ہے جب آپ کسی رکاوٹ کو دور کیے بغیر کام کو بار بار نئے سرے سے شروع کرتے رہتے ہیں۔ آپ Slack کا جواب دیتے ہیں، کال پر جاتے ہیں، لاگز (logs) پر سرسری نظر ڈالتے ہیں، ٹکٹ کھولتے ہیں، اور پھر اصل کام کا تسلسل کھو بیٹھتے ہیں۔ بظاہر بہت مصروفیت نظر آتی ہے، لیکن کوئی ٹھوس نتیجہ برآمد نہیں ہوتا۔
Silent scope (خاموشی سے دائرہ کار کا بڑھنا): یہ تب ہوتا ہے جب مختلف صارفین کی جانب سے چھوٹی چھوٹی “فوری فرمائشیں” جمع ہو کر ایک بڑے کام کی شکل اختیار کر لیتی ہیں، حالانکہ اس پر باقاعدہ کوئی اتفاق رائے نہیں ہوا ہوتا۔ آپ کو پورا ہفتہ لگتا ہے کہ آپ مددگار ثابت ہو رہے ہیں، لیکن پھر POC (ثبوتِ تصور) کا ڈیمو اچانک نامکمل یا ناقص رہ جاتا ہے کیونکہ آپ نے منگل کا دن صرف “ایک اور” چھوٹی سی ایکسپورٹ (export) کی تبدیلی میں گزار دیا ہوتا ہے۔
Trust decay (اعتماد میں کمی): یہ تب ہوتا ہے جب پیش رفت کی معلومات مبہم یا غیر واضح ہوں۔ صارفین کو کمال (perfection) کی ضرورت نہیں ہوتی، لیکن انہیں مسلسل اور واضح معلومات درکار ہوتی ہیں۔ جب وہ لگاتار دو بار یہ سنتے ہیں کہ “اس پر کام ہو رہا ہے”، تو وہ یہ سمجھنے لگتے ہیں کہ یا تو آپ کسی مسئلے میں پھنس گئے ہیں یا آپ کی توجہ بٹ گئی ہے، اور پھر وہ یقین دہانی حاصل کرنے کے لیے معاملے کو اعلیٰ حکام تک لے جانے (escalate کرنے) لگتے ہیں۔
دیکھیں کہ ناکامی کی یہ صورتیں کس طرح آپس میں جڑی ہوئی ہیں اور ایک دوسرے کو مزید بڑھاتی ہیں۔
پیر کی صبح، آپ کے پاس تین ٹیبز (tabs) کھلے ہیں اور ان میں سے کوئی بھی غیر ضروری نہیں ہے۔ ایک ریٹیل بینک جمعرات کو ہونے والے سیکیورٹی جائزے سے پہلے اپنے ‘سنگل سائن آن’ (SSO) سسٹم میں اصلاح چاہتا ہے (یہ سسٹم ایک مرکزی شناخت کے ذریعے لاگ ان کی سہولت دیتا ہے تاکہ ایک ہی لاگ ان کئی ایپس پر کام کر سکے)۔ ایک لاجسٹکس کمپنی ڈیٹا ایکسپورٹ کے معاملے پر رکی ہوئی ہے جو ان کے روزانہ کے آپریشنز ڈیش بورڈ کو چلاتا ہے۔ ہیلتھ کیئر اینالیٹکس کی ایک ٹیم آپ کے ‘پروف آف کانسیپٹ’ (POC) کی منتظر ہے—یہ ایک ابتدائی نمونہ یا چھوٹا ورژن ہوتا ہے جس کا مقصد پروڈکشن (حتمی عمل درآمد) شروع کرنے سے پہلے یہ ثابت کرنا ہوتا ہے کہ کوئی چیز کام کر رہی ہے—کیونکہ ان کا ایگزیکٹو اسپانسر ڈیمو دیکھنے آ رہا ہے۔
آپ یہ تینوں کام ایک ہی ہفتے میں کر سکتے ہیں۔ لیکن آپ ان سب کو یکساں رفتار، گہرائی اور یقینیت کے ساتھ مکمل نہیں کر سکتے۔ جس لمحے آپ اس حقیقت کو تسلیم کر لیتے ہیں، آپ ‘بیک وقت ڈیلیوری ماڈل’ (concurrent delivery model) میں داخل ہو جاتے ہیں، چاہے آپ نے اس کی منصوبہ بندی کی ہو یا نہ ہو۔
بیک وقت جاری کاموں میں توازن قائم کرنے کا مطلب ہے کہ آپ بیک وقت صارفین کے متعدد کاموں (workstreams) کا فعال طور پر انتظام کرتے ہیں، جبکہ اپنے وقت اور توجہ کو محدود وسائل کے طور پر دیکھتے ہیں؛ اور آپ واضح وعدے کرتے ہیں کہ آگے کیا ہوگا، کس کے لیے ہوگا، اور کب تک ہوگا۔ یہ محض ‘ملٹی ٹاسکنگ’ (ایک ساتھ کئی کام کرنا) نہیں ہے۔ یہ فیصلہ کرنا ہے کہ کس صارف کو آپ کا اگلا ‘خالص وقت’ (بغیر کسی خلل کے کام کا گھنٹہ) ملے گا، کس صارف کے ساتھ مختصر جائزہ (check-in) ہوگا، اور کس صارف کو اس وقت تک واضح ‘نہ’ (no) کہا جائے گا جب تک کہ کوئی رکاوٹ یا انحصار (dependency) دور نہ ہو جائے۔
عملی طور پر، توازن کا تعلق ان تین حدود سے ہے جن کے لیے آپ جوابدہ ہیں۔
آئیے ایک سادہ ذہنی ماڈل کا جائزہ لیں کہ یہ قوتیں کس طرح آپس میں ٹکراتی یا مقابلہ کرتی ہیں۔