منگل کی اسٹیٹس میٹنگ اسی بے چینی کے احساس کے ساتھ ختم ہوتی ہے۔ آپ پروجیکٹ مینیجر ہیں؛ ٹیک لیڈ (tech lead) بتاتا ہے کہ API انٹیگریشن کی رکاوٹ دور ہو گئی ہے، وینڈر کہتا ہے کہ وہ اپ ڈیٹ شدہ تفصیلات (specs) بھیج دے گا، اور آپ کا اسپانسر پوچھتا ہے کہ کیا آپ لانچ کی تاریخ کے مطابق کام کر رہے ہیں۔ آپ دس منٹ بعد میٹنگ کے خلاصے (recap notes) بھیج دیتے ہیں۔ جمعرات تک، QA ٹیم غلط ‘بلڈ’ (build) کی جانچ کر رہی ہوتی ہے، وینڈر کی تفصیلات موصول نہیں ہوتیں، اور آپ کا اسپانسر آپ کا بھیجا ہوا خلاصہ ہی واپس بھیج کر پوچھتا ہے کہ اسکوپ (کام کے دائرہ کار) میں تبدیلی کی منظوری کس نے دی۔ جو فیصلہ رکا ہوا ہے اس کا تعلق تکنیکی پہلو سے نہیں ہے، بلکہ اس بات سے ہے کہ اگلا قدم اٹھانے کی ذمہ داری کس کی ہے اور فیصلے کا ریکارڈ کیا مانا جائے گا۔ ہر گزرتا دن دوبارہ کام (rework) اور مزید فالو اپ میٹنگز کا بوجھ بڑھاتا ہے اور مقررہ تاریخ کے لیے خطرہ پیدا کرتا ہے۔
آپ کسی اور میٹنگ کا اضافہ کیے بغیر اس مسئلے کو حل کر سکتے ہیں۔ آپ کو بات چیت سے لے کر عملی کام کی تکمیل تک ایک ایسا طریقہ کار درکار ہے جسے بار بار اپنایا جا سکے؛ ایک ایسا طریقہ جس سے فیصلوں کو ذمہ دار افراد اور مقررہ تاریخوں کے ساتھ تفویض کردہ کاموں (assignments) میں بدلا جا سکے؛ اور ایک ایسی واضح جگہ جہاں پروجیکٹ کی اصل صورتحال (project truth) کا ریکارڈ موجود ہو۔ یہ سبق ایک ہفتے کے ٹائم لائن کا استعمال کرتے ہوئے یہ نشاندہی کرتا ہے کہ نتائج کہاں ضائع ہو جاتے ہیں، پھر ‘میٹنگ سے کام کی تکمیل’ تک کے عمل (pipeline) کو متعارف کرواتا ہے، اور آخر میں یہ دکھاتا ہے کہ اس عمل میں AI کا کردار کہاں ہونا چاہیے اور کہاں نہیں۔
ٹائم لائن کو دیکھنے سے پہلے، اس پہلے ناکامی کے مقام (failure point) کی پیش گوئی کریں جو ایک عام ‘ری کیپ ای میل’ کو ٹیم کے لیے اضافی کام میں بدل دیتا ہے۔
اکثر اوقات مسئلہ یہ نہیں ہوتا کہ میٹنگ کے دوران نوٹس نہیں لیے گئے۔ اصل مسئلہ یہ ہوتا ہے کہ میٹنگ کے نتیجے میں کوئی اہم پیش رفت یا فیصلہ تو سامنے آتا ہے، لیکن اسے کسی ‘قابلِ تکمیل کام’ (deliverable) کی حیثیت نہیں دی جاتی۔
کسی فیصلے پر بات تو ہوتی ہے لیکن اس فیصلے کے ذمہ دار کا تعین نہیں کیا جاتا، چنانچہ بعد میں کوئی یہ تصدیق نہیں کر پاتا کہ آیا کوئی حتمی فیصلہ ہوا تھا یا صرف بحث و مباحثہ ہوا تھا۔ کام کی منتقلی (handoff) کا اشارہ تو ملتا ہے—مثلاً یہ کہ ڈویلپرز QA ٹیم کو ‘بلڈ’ (build) بھیجیں گے—لیکن اسے کسی ذمہ دار شخص اور مقررہ تاریخ (due date) کے ساتھ باقاعدہ ٹاسک کے طور پر تفویض نہیں کیا جاتا، جس کی وجہ سے یہ ڈویلپرز کی ‘کیو’ (queue) میں موجود دیگر کاموں کے ساتھ مقابلے میں پیچھے رہ جاتا ہے۔ کسی انحصار (dependency) کا ذکر تو ہوتا ہے—جیسے وینڈر کی تفصیلات (specifications)—لیکن اسے اندرونی کاموں والے نظام میں ٹریک نہیں کیا جاتا، لہٰذا یہ تب تک نظروں سے اوجھل رہتا ہے جب تک کہ یہ کام میں رکاوٹ نہ بن جائے۔ اسپانسر کوئی ایسا سوال پوچھتا ہے جس میں کسی ایک آپشن کا انتخاب درکار ہوتا ہے، لیکن اس کا جواب میٹنگ کے طویل خلاصے (recap) میں کہیں دب جاتا ہے؛ نتیجتاً اسپانسر دوبارہ وہی سوال پوچھتا ہے اور آپ کی ساکھ متاثر ہوتی ہے۔
پروجیکٹ مینیجر (PM) کی ایک عام غلطی یہ ہے کہ وہ خلاصہ ای میل (recap email) کو ہی کام کا اختتام سمجھ بیٹھتے ہیں۔ یہ عمل ذمہ داری کا احساس دلاتا ہے کیونکہ اس میں ہونے والی کارروائی کا ریکارڈ موجود ہوتا ہے۔ اس کا نتیجہ یہ نکلتا ہے کہ ‘ذمہ داری قبول کرنے’ (ownership) کی جگہ محض ‘دستاویزی ریکارڈ’ لے لیتا ہے، اور پروجیکٹ یاد دہانیوں، وضاحتوں اور دوبارہ کام کرنے (rework) کے نہ ختم ہونے والے چکر میں پھنس جاتا ہے۔
جب کسی میٹنگ کے نتیجے میں کام جنم لیتا ہے، تو آپ کو ایک ایسے نظام یا عمل (pipeline) کی ضرورت ہوتی ہے جو غیر منظم گفتگو کو پروجیکٹ کے باقاعدہ اور منظم ریکارڈز (artifacts) میں تبدیل کر سکے۔ یہاں مقصد محض بہتر نوٹس لینا نہیں ہے، بلکہ مقصد یہ ہے کہ میٹنگ کے نتائج کو ایسے عملی اقدامات میں تبدیل کیا جائے جو ٹولز کی تبدیلی یا یادداشت کے کمزور پڑنے کے باوجود برقرار رہ سکیں۔
اس عمل (pipeline) کو دیکھنے سے پہلے، یہ طے کریں کہ جب میٹنگز کا انبار لگ جاتا ہے تو کون سا مرحلہ چھوٹ جانے کی وجہ سے آپ کے پروجیکٹس کو سب سے زیادہ نقصان پہنچتا ہے۔