ٹم لسٹر - کتابوں کے شریک مصنف
- "انسانی عنصر۔ کامیاب منصوبے اور ٹیمیں" (اصل کتاب کو "پیپل ویئر" کہا جاتا ہے)
- "ریچھوں کے ساتھ والٹزنگ: سافٹ ویئر پروجیکٹس میں رسک کا انتظام"
- "ایڈرینالین پاگل اور پیٹرن کے ذریعہ زومبیفائیڈ۔ پروجیکٹ ٹیموں کے طرز عمل کے نمونے"
یہ تمام کتابیں ان کے شعبے میں کلاسیکی ہیں اور ان کے ساتھیوں کے ساتھ مل کر لکھی گئیں۔ . روس میں، ان کے ساتھی سب سے زیادہ مشہور ہیں - и جس نے کئی مشہور کام بھی لکھے۔
ٹم کے پاس سافٹ ویئر ڈویلپمنٹ کا 40 سال کا تجربہ ہے؛ 1975 میں (اس سال اس habrapost لکھنے والوں میں سے کوئی بھی پیدا نہیں ہوا تھا)، ٹم پہلے ہی Yourdon Inc کے ایگزیکٹو نائب صدر تھے۔ اب وہ اپنا وقت مشورے، پڑھانے اور لکھنے میں صرف کرتا ہے، کبھی کبھار دورے کرتا ہے۔ دنیا بھر میں کانفرنسیں.
ہم نے خاص طور پر ہیبر کے لئے ٹم لسٹر کے ساتھ ایک انٹرویو کیا۔ وہ DevOops 2019 کانفرنس کا آغاز کرے گا، اور ہمارے پاس کتابوں اور بہت کچھ کے بارے میں بہت سارے سوالات ہیں۔ یہ انٹرویو میخائل ڈروزینن اور اولیگ چیروخین نے کانفرنس پروگرام کمیٹی سے لیا ہے۔
مائیکل: کیا آپ اس کے بارے میں کچھ الفاظ کہہ سکتے ہیں جو آپ ابھی کر رہے ہیں؟
ٹم: میں اٹلانٹک سسٹمز گلڈ کا سربراہ ہوں۔ گلڈ میں ہم میں سے چھ ہیں، ہم خود کو پرنسپل کہتے ہیں۔ تین امریکہ میں اور تین یورپ میں - اسی لیے گلڈ کو بحر اوقیانوس کہا جاتا ہے۔ ہم اتنے سالوں سے اکٹھے ہیں کہ آپ ان کو شمار نہیں کر سکتے۔ ہم سب کی اپنی خصوصیات ہیں۔ میں گزشتہ دہائی یا اس سے زیادہ عرصے سے کلائنٹس کے ساتھ کام کر رہا ہوں۔ میرے پروجیکٹس میں نہ صرف انتظام شامل ہے، بلکہ ضروریات کی ترتیب، پروجیکٹ کی منصوبہ بندی، اور تشخیص بھی شامل ہے۔ ایسا لگتا ہے کہ ایسے منصوبے جو خراب طور پر شروع ہوتے ہیں وہ عام طور پر خراب ختم ہوتے ہیں۔ لہذا، یہ یقینی بنانا ضروری ہے کہ تمام سرگرمیاں واقعی اچھی طرح سے سوچی سمجھی اور مربوط ہیں، تخلیق کاروں کے خیالات یکجا ہیں۔ یہ سوچنے کے قابل ہے کہ آپ کیا کر رہے ہیں اور کیوں کر رہے ہیں۔ منصوبے کو پایہ تکمیل تک پہنچانے کے لیے کون سی حکمت عملی استعمال کی جائے۔
میں کئی سالوں سے گاہکوں کو مختلف طریقوں سے مشورہ کر رہا ہوں۔ ایک دلچسپ مثال ایک کمپنی ہے جو گھٹنے اور کولہے کی سرجری کے لیے روبوٹ بناتی ہے۔ سرجن مکمل طور پر آزادانہ طور پر کام نہیں کرتا، لیکن ایک روبوٹ استعمال کرتا ہے۔ یہاں حفاظت، واضح طور پر، اہم ہے. لیکن جب آپ ان لوگوں کے ساتھ ضروریات پر بات کرنے کی کوشش کرتے ہیں جو مسائل کو حل کرنے پر مرکوز ہیں... یہ عجیب لگے گا، لیکن امریکہ میں (فیڈرل ڈرگ ایڈمنسٹریشن)، جو ان روبوٹس جیسی مصنوعات کو لائسنس دیتا ہے۔ اس سے پہلے کہ آپ کچھ بھی بیچیں اور اسے زندہ لوگوں پر استعمال کریں، آپ کو لائسنس حاصل کرنا ہوگا۔ شرائط میں سے ایک یہ ہے کہ آپ اپنی ضروریات کو ظاہر کریں، ٹیسٹ کیا ہیں، آپ نے انہیں کیسے آزمایا، ٹیسٹ کے نتائج کیا ہیں۔ اگر آپ ضروریات کو تبدیل کرتے ہیں، تو آپ کو اس پورے بڑے ٹیسٹنگ عمل سے بار بار گزرنا ہوگا۔ ہمارے کلائنٹس نے اپنی ضروریات میں ایپلی کیشنز کے بصری ڈیزائن کو شامل کرنے کا انتظام کیا۔ ان کے پاس ضروریات کے حصے کے طور پر براہ راست اسکرین شاٹس تھے۔ ہمیں انہیں باہر نکالنا ہوگا اور سمجھانا ہوگا کہ زیادہ تر یہ تمام پروگرام گھٹنوں اور کولہوں کے بارے میں کچھ نہیں جانتے، یہ تمام چیزیں کیمرے کے ساتھ وغیرہ۔ ہمیں ضروریات کے دستاویزات کو دوبارہ لکھنے کی ضرورت ہے تاکہ وہ کبھی تبدیل نہ ہوں، جب تک کہ کچھ واقعی اہم بنیادی حالات تبدیل نہ ہوں۔ اگر بصری ڈیزائن ضروریات میں نہیں ہے تو، مصنوعات کو اپ ڈیٹ کرنا بہت تیز ہو جائے گا. ہمارا کام ان عناصر کو تلاش کرنا ہے جو گھٹنے، کولہوں، کمر پر آپریشن کرتے ہیں، انہیں الگ الگ دستاویزات میں نکالتے ہیں اور کہتے ہیں کہ یہ بنیادی ضروریات ہوں گی۔ آئیے گھٹنے کے آپریشن کے بارے میں ضروریات کا ایک الگ تھلگ گروپ بنائیں۔ یہ ہمیں ضروریات کا ایک زیادہ مستحکم سیٹ بنانے کی اجازت دے گا۔ ہم پوری پروڈکٹ لائن کے بارے میں بات کریں گے، نہ کہ مخصوص روبوٹس کے بارے میں۔
بہت سا کام ہو چکا تھا، لیکن وہ پھر بھی ایسی جگہوں پر پہنچ گئے جہاں پہلے انہوں نے کئی ہفتوں اور مہینوں تک بغیر کسی معنی یا ضرورت کے بار بار ٹیسٹ کیے، کیونکہ کاغذ پر بیان کی گئی ان کی ضروریات ان حقیقی ضروریات سے میل نہیں کھاتی تھیں جن کے لیے سسٹمز بنائے گئے تھے۔ ایف ڈی اے نے انہیں ہر بار کہا: آپ کی ضروریات بدل گئی ہیں، اب آپ کو شروع سے ہر چیز کو چیک کرنے کی ضرورت ہے۔ پوری پروڈکٹ کی مکمل جانچیں انٹرپرائز کو ہلاک کر رہی تھیں۔
لہذا، اس طرح کے شاندار کام ہوتے ہیں جب آپ اپنے آپ کو کسی دلچسپ چیز کے بالکل آغاز میں پاتے ہیں، اور پہلے ہی اعمال کھیل کے مزید اصول طے کرتے ہیں۔ اگر آپ اس بات کو یقینی بناتے ہیں کہ یہ ابتدائی سرگرمی انتظامی اور تکنیکی دونوں نقطہ نظر سے اچھی طرح کام کرنا شروع کر دیتی ہے، تو اس بات کا امکان ہے کہ آپ ایک عظیم پروجیکٹ کے ساتھ اختتام پذیر ہوں گے۔ لیکن اگر یہ حصہ ریل سے ہٹ گیا ہے اور کہیں غلط ہو گیا ہے، اگر آپ بنیادی معاہدے نہیں پا سکتے ہیں... نہیں، ایسا نہیں ہے کہ آپ کا پروجیکٹ لازمی طور پر ناکام ہو جائے گا۔ لیکن آپ اب یہ نہیں کہہ سکیں گے: "ہم نے بہت اچھا کیا، ہم نے سب کچھ واقعی مؤثر طریقے سے کیا۔" یہ وہ چیزیں ہیں جو میں گاہکوں کے ساتھ بات چیت کرتے وقت کرتا ہوں۔
مائیکل: یعنی، آپ پروجیکٹ شروع کرتے ہیں، کوئی کِک آف کرتے ہیں اور چیک کرتے ہیں کہ ریل صحیح سمت میں جا رہی ہے؟
ٹم: ہمارے پاس اس بارے میں بھی آئیڈیاز ہیں کہ کس طرح پہیلی کے تمام ٹکڑوں کو ایک ساتھ رکھنا ہے: ہمیں کن مہارتوں کی ضرورت ہے، جب بالکل ان کی ضرورت ہے، ٹیم کا بنیادی حصہ کیسا لگتا ہے اور اس طرح کی دیگر بنیادی چیزیں۔ کیا ہمیں کل وقتی ملازمین کی ضرورت ہے یا ہم کسی کو پارٹ ٹائم ملازم رکھ سکتے ہیں؟ منصوبہ بندی، انتظام۔ سوالات جیسے: اس خاص منصوبے کے لیے سب سے اہم کیا ہے؟ اس کو کیسے حاصل کیا جائے؟ ہم اس پروڈکٹ یا پروجیکٹ کے بارے میں کیا جانتے ہیں، کیا خطرات ہیں اور نامعلوم کہاں ہیں، ہم ان سب سے کیسے نمٹیں گے؟ یقیناً، اس وقت کوئی چیخنا شروع کر دیتا ہے "چست کے بارے میں کیا؟!" ٹھیک ہے، آپ سب لچکدار ہیں، لیکن کیا؟ پروجیکٹ بالکل کیسا لگتا ہے، آپ اسے اس طرح سے کیسے نکالیں گے جو پروجیکٹ کے مطابق ہو؟ آپ صرف یہ نہیں کہہ سکتے کہ "ہمارا نقطہ نظر کسی بھی چیز تک پھیلا ہوا ہے، ہم ایک سکرم ٹیم ہیں!" یہ بکواس اور بکواس ہے۔ آگے کہاں جانا ہے، یہ کام کیوں کرے، بات کہاں کی ہے؟ میں اپنے گاہکوں کو ان تمام سوالات کے بارے میں سوچنا سکھاتا ہوں۔
فرتیلی کے 19 سال
مائیکل: چست میں، لوگ اکثر کوشش کرتے ہیں کہ کسی بھی چیز کی پہلے سے وضاحت نہ کریں، لیکن جتنی دیر ہو سکے فیصلے کریں، کہتے ہیں: ہم بہت بڑے ہیں، میں مجموعی فن تعمیر کے بارے میں نہیں سوچوں گا۔ میں دوسری چیزوں کے ایک گروپ کے بارے میں نہیں سوچوں گا؛ اس کے بجائے، میں کچھ ایسی ڈیلیور کروں گا جو اس وقت کسٹمر کو کارآمد ہو۔
ٹم: مجھے لگتا ہے کہ فرتیلی طریقہ کار، کے ساتھ شروع 2001 میں، صنعت کی آنکھیں کھولیں. لیکن دوسری طرف، کچھ بھی کامل نہیں ہے. میں تمام تکراری ترقی کے لیے ہوں۔ زیادہ تر پروجیکٹس میں تکرار بہت معنی رکھتی ہے۔ لیکن آپ کو جس سوال کے بارے میں سوچنے کی ضرورت ہے وہ یہ ہے کہ: ایک بار جب پروڈکٹ ختم ہو جائے اور استعمال میں ہو، تو یہ کب تک چلتا ہے؟ کیا یہ ایسی پروڈکٹ ہے جو کسی اور چیز سے تبدیل ہونے سے پہلے چھ ماہ تک رہے گی؟ یا یہ ایک ایسی مصنوع ہے جو کئی سالوں تک کام کرے گی؟ بلاشبہ، میں نام نہیں بتاؤں گا، لیکن... نیویارک اور اس کی مالیاتی برادری میں، سب سے بنیادی نظام بہت پرانے ہیں۔ یہ حیرت انگیز ہے. آپ ان کو دیکھتے ہیں اور سوچتے ہیں، کاش آپ 1994 میں وقت پر واپس جا سکیں، اور ڈویلپرز کو بتائیں: "میں مستقبل سے آیا ہوں، 2019 سے۔ جب تک آپ کی ضرورت ہو بس اس نظام کو تیار کریں۔ اسے قابل توسیع بنائیں، فن تعمیر کے بارے میں سوچیں۔ اس کے بعد اسے پچیس سال سے زیادہ کے لیے بہتر کیا جائے گا۔ اگر آپ ترقی میں تھوڑی دیر اور تاخیر کرتے ہیں تو چیزوں کی عظیم الشان اسکیم میں کوئی بھی نظر نہیں آئے گا! جب آپ طویل مدتی چیزوں کا تخمینہ لگا رہے ہیں، تو آپ کو اس پر غور کرنے کی ضرورت ہے کہ اس کی مجموعی قیمت کتنی ہوگی۔ کبھی کبھی اچھی طرح سے ڈیزائن کیا گیا فن تعمیر واقعی اس کے قابل ہوتا ہے، اور کبھی کبھی ایسا نہیں ہوتا ہے۔ ہمیں اپنے اردگرد دیکھنے اور اپنے آپ سے پوچھنے کی ضرورت ہے: کیا ہم ایسے فیصلے کے لیے صحیح صورتحال میں ہیں؟
لہذا ایک خیال جیسا کہ "ہم فرتیلی کے لئے ہیں، گاہک خود ہمیں بتائے گا کہ وہ کیا حاصل کرنا چاہتا ہے" - یہ انتہائی سادہ ہے۔ گاہکوں کو یہ بھی نہیں معلوم کہ وہ کیا چاہتے ہیں، اور اس سے بھی زیادہ وہ نہیں جانتے کہ انہیں کیا مل سکتا ہے۔ بعض لوگ دلیل کے طور پر تاریخی مثالیں دینا شروع کر دیں گے، یہ میں دیکھ چکا ہوں۔ لیکن تکنیکی طور پر ترقی یافتہ لوگ عام طور پر ایسا نہیں کہتے۔ وہ کہتے ہیں: "یہ 2019 ہے، ہمارے پاس یہی مواقع ہیں، اور ہم ان چیزوں کو دیکھنے کے انداز کو مکمل طور پر تبدیل کر سکتے ہیں!" موجودہ حلوں کی نقل کرنے کے بجائے، انہیں تھوڑا خوبصورت اور زیادہ کنگھی بنانے کے، بعض اوقات آپ کو باہر جا کر کہنا پڑتا ہے: "آئیے ہم یہاں کیا کرنے کی کوشش کر رہے ہیں اسے مکمل طور پر دوبارہ ایجاد کریں!"
اور مجھے نہیں لگتا کہ زیادہ تر صارفین اس مسئلے کے بارے میں اس طرح سوچ سکتے ہیں۔ وہ صرف وہی دیکھتے ہیں جو ان کے پاس پہلے سے موجود ہے، بس۔ جس کے بعد وہ درخواستوں کے ساتھ آتے ہیں جیسے "آئیے اسے تھوڑا سا آسان بنائیں" یا جو بھی وہ عام طور پر کہتے ہیں۔ لیکن ہم ویٹر یا ویٹریس نہیں ہیں، لہذا ہم آرڈر لے سکتے ہیں چاہے وہ کتنا ہی احمقانہ کیوں نہ ہو اور پھر اسے کچن میں بیک کر لیں۔ ہم ان کے رہنما ہیں۔ ہمیں ان کی آنکھیں کھول کر کہنا ہے: ارے، ہمارے پاس یہاں نئے مواقع ہیں! کیا آپ کو احساس ہے کہ آپ کے کاروبار کے اس حصے کو انجام دینے کے طریقے کو ہم واقعی تبدیل کر سکتے ہیں؟ Agile کے ساتھ ایک مسئلہ یہ ہے کہ یہ اس شعور کو دور کرتا ہے کہ ایک موقع کیا ہے، مسئلہ کیا ہے، ہمیں کیا کرنے کی بھی ضرورت ہے، اس مخصوص صورتحال کے لیے کون سی دستیاب ٹیکنالوجیز بہترین ہیں۔
شاید میں یہاں حد سے زیادہ شکی ہوں: فرتیلی برادری میں بہت ساری حیرت انگیز چیزیں ہو رہی ہیں۔ لیکن مجھے اس حقیقت کے ساتھ مسئلہ ہے کہ لوگ کسی پروجیکٹ کی تعریف کرنے کے بجائے ہاتھ اٹھانے لگتے ہیں۔ میں یہاں پوچھوں گا - ہم کیا کر رہے ہیں، ہم اسے کیسے کرنے جا رہے ہیں؟ اور کسی نہ کسی طرح جادوئی طور پر یہ ہمیشہ پتہ چلتا ہے کہ کلائنٹ کو کسی سے بہتر جاننا چاہئے۔ لیکن کلائنٹ صرف اس وقت بہتر جانتا ہے جب وہ کسی کی بنائی ہوئی چیزوں میں سے انتخاب کرتا ہے۔ اگر میں ایک کار خریدنا چاہتا ہوں اور مجھے اپنے خاندانی بجٹ کا سائز معلوم ہے، تو میں فوری طور پر ایسی کار کا انتخاب کروں گا جو میرے طرز زندگی کے مطابق ہو۔ یہاں میں سب کچھ کسی سے بہتر جانتا ہوں! لیکن براہ کرم نوٹ کریں کہ کسی نے پہلے ہی کاریں بنا رکھی ہیں۔ مجھے نہیں معلوم کہ نئی کار کیسے ایجاد کی جائے، میں ماہر نہیں ہوں۔ جب ہم اپنی مرضی کے مطابق یا خصوصی مصنوعات بناتے ہیں، تو گاہک کی آواز کو ضرور مدنظر رکھنا چاہیے، لیکن اب یہ صرف آواز نہیں رہی۔
اولیگ: آپ نے چست منشور کا ذکر کیا۔ کیا ہمیں مسئلہ کی جدید تفہیم کو مدنظر رکھتے ہوئے اسے کسی طرح اپ ڈیٹ یا نظر ثانی کرنے کی ضرورت ہے؟
ٹم: میں اسے ہاتھ نہیں لگاتا۔ میرے خیال میں یہ ایک عظیم تاریخی دستاویز ہے۔ میرا مطلب ہے، وہ وہی ہے جو وہ ہے۔ وہ 19 سال کا ہو رہا ہے، وہ بوڑھا ہو گیا ہے، لیکن اپنے دور میں اس نے انقلاب برپا کر دیا۔ اس نے جو اچھا کیا وہ یہ تھا کہ اس نے ردعمل کو متحرک کیا اور لوگ اس کے بارے میں سرگوشی کرنے لگے۔ آپ، غالباً، 2001 میں ابھی تک انڈسٹری میں کام نہیں کر رہے تھے، لیکن پھر سب نے عمل کے مطابق کام کیا۔ سافٹ ویئر انجینئرنگ انسٹی ٹیوٹ، سافٹ ویئر کی تکمیل کے ماڈل کے پانچ درجے (CMMI)۔ مجھے نہیں معلوم کہ قدیم قدیم کی ایسی داستانیں آپ کو کچھ بتاتی ہیں، لیکن پھر یہ ایک پیش رفت تھی۔ پہلے پہل، لوگوں کا خیال تھا کہ اگر عمل درست طریقے سے ترتیب دیا گیا تو مسائل خود ہی ختم ہو جائیں گے۔ اور پھر منشور ساتھ آتا ہے اور کہتا ہے: "نہیں، نہیں، نہیں - ہم لوگوں پر مبنی ہوں گے، عمل پر نہیں۔" ہم سافٹ ویئر ڈویلپمنٹ کے ماہر ہیں۔ ہم سمجھتے ہیں کہ مثالی عمل سراب ہے، ایسا نہیں ہوتا۔ منصوبوں میں بہت زیادہ محاورہ ہے، تمام منصوبوں کے لیے ایک ہی کامل عمل کا خیال کوئی معنی نہیں رکھتا۔ یہ دعویٰ کرنے کے لیے مسائل بہت پیچیدہ ہیں کہ ہر چیز کا ایک ہی حل ہے (ہیلو، نروان)۔
میں مستقبل کو دیکھنے کا خیال نہیں رکھتا، لیکن میں یہ کہوں گا کہ لوگوں نے اب پراجیکٹس کے بارے میں مزید سوچنا شروع کر دیا ہے۔ میرے خیال میں چست منشور چھلانگ لگانے اور کہنے میں بہت اچھا ہے، "ارے! آپ ایک جہاز پر ہیں، اور آپ خود اس جہاز کو چلا رہے ہیں۔ آپ کو فیصلہ کرنا پڑے گا - ہم تمام حالات کے لیے ایک عالمگیر نسخہ تجویز نہیں کریں گے۔ آپ جہاز کے عملہ ہیں، اور اگر آپ کافی اچھے ہیں، تو آپ مقصد کا راستہ تلاش کر سکتے ہیں۔ آپ سے پہلے اور بھی جہاز تھے اور آپ کے بعد بھی اور بھی جہاز ہوں گے لیکن پھر بھی ایک لحاظ سے آپ کا سفر منفرد ہے۔ ایسا ہی کچھ! یہ سوچنے کا ایک طریقہ ہے۔ میرے لیے سورج کے نیچے کوئی نئی بات نہیں، لوگ پہلے بھی بحری سفر کر چکے ہیں اور پھر بھی جائیں گے، لیکن آپ کے لیے یہ آپ کا اصل سفر ہے، اور میں آپ کو یہ نہیں بتاؤں گا کہ آپ کے ساتھ کیا ہو گا۔ آپ کے پاس ایک ٹیم میں مربوط کام کی مہارت ہونی چاہیے، اور اگر آپ کے پاس واقعی یہ ہیں، تو سب کچھ کام کرے گا اور آپ جہاں چاہیں گے وہاں پہنچ جائیں گے۔
پیپل ویئر: 30 سال بعد
اولیگ: کیا پیپل ویئر ایک انقلاب کے ساتھ ساتھ منشور بھی تھا؟
ٹم: لوگوں کا سامان... ٹام اور میں نے یہ کتاب لکھی، لیکن ہم نے نہیں سوچا تھا کہ ایسا ہو گا۔ کسی نہ کسی طرح یہ بہت سے لوگوں کے خیالات کے ساتھ گونجتا ہے. یہ پہلی کتاب تھی جس میں کہا گیا تھا: سافٹ ویئر ڈویلپمنٹ ایک انتہائی انسانی سرگرمی ہے۔ ہماری تکنیکی نوعیت کے باوجود، ہم لوگوں کی ایک کمیونٹی بھی ہیں جو کچھ بڑا، یہاں تک کہ بہت بڑا، بہت پیچیدہ بنا رہے ہیں۔ ایسی چیزیں کوئی اکیلا نہیں بنا سکتا، ٹھیک ہے؟ تو "ٹیم" کا خیال بہت اہم ہو گیا۔ اور نہ صرف انتظامی نقطہ نظر سے، بلکہ تکنیکی لوگوں کے لیے بھی جو نامعلوم افراد کے ایک گروپ کے ساتھ واقعی پیچیدہ گہرے مسائل کو حل کرنے کے لیے اکٹھے ہوئے۔ ذاتی طور پر میرے لیے، یہ میرے پورے کیریئر میں ذہانت کا ایک بہت بڑا امتحان رہا ہے۔ اور یہاں آپ کو یہ کہنے کے قابل ہونے کی ضرورت ہے: ہاں، یہ مسئلہ اس سے کہیں زیادہ ہے جو میں خود ہینڈل کر سکتا ہوں، لیکن مل کر ہم ایک خوبصورت حل تلاش کر سکتے ہیں جس پر ہمیں فخر ہو سکتا ہے۔ اور مجھے لگتا ہے کہ یہی خیال سب سے زیادہ گونجا۔ یہ خیال کہ ہم وقت کا کچھ حصہ اپنے طور پر کام کرتے ہیں، وقت کا کچھ حصہ گروپ کے حصے کے طور پر، اور اکثر فیصلہ گروپ ہی کرتا ہے۔ گروپ کے مسائل کا حل تیزی سے پیچیدہ منصوبوں کی ایک اہم خصوصیت بن گیا ہے۔
اس حقیقت کے باوجود کہ ٹم نے بڑی تعداد میں بات چیت کی ہے، ان میں سے بہت کم یوٹیوب پر پوسٹ کیے گئے ہیں۔ آپ 2007 کی رپورٹ "پیپل ویئر کی واپسی" کو دیکھ سکتے ہیں۔ معیار، یقینا، مطلوبہ ہونے کے لئے بہت کچھ چھوڑ دیتا ہے۔
مائیکل: کیا کتاب شائع ہونے کے بعد پچھلے 30 سالوں میں کچھ بدلا ہے؟
ٹم: آپ اسے بہت سے مختلف زاویوں سے دیکھ سکتے ہیں۔ سماجی اعتبار سے... ایک زمانے میں، آسان اوقات میں، آپ اور آپ کی ٹیم ایک ہی دفتر میں بیٹھی تھی۔ آپ ہر روز قریب ہوسکتے ہیں، ایک ساتھ کافی پی سکتے ہیں اور کام پر تبادلہ خیال کرسکتے ہیں۔ جو چیز واقعی تبدیل ہوئی ہے وہ یہ ہے کہ ٹیموں کو اب جغرافیائی طور پر، مختلف ممالک اور ٹائم زونز میں تقسیم کیا جا سکتا ہے، لیکن پھر بھی وہ ایک ہی مسئلے پر کام کر رہی ہیں، اور اس سے پیچیدگی کی ایک نئی پرت شامل ہو جاتی ہے۔ یہ پرانا اسکول لگ سکتا ہے، لیکن آمنے سامنے بات چیت جیسی کوئی چیز نہیں ہے جہاں آپ سب اکٹھے ہوں، مل کر کام کر رہے ہوں، اور آپ کسی ساتھی کے پاس جا کر کہہ سکتے ہیں، دیکھو میں نے کیا دریافت کیا، آپ کو یہ کیسا لگا؟ آمنے سامنے بات چیت غیر رسمی مواصلت میں منتقلی کا ایک تیز طریقہ فراہم کرتی ہے، اور میرے خیال میں چست کے شوقین افراد کو بھی یہ پسند کرنا چاہیے۔ اور میں پریشان بھی ہوں کیونکہ حقیقت میں دنیا بہت چھوٹی نکلی ہے، اور اب یہ سب تقسیم شدہ ٹیموں سے ڈھکی ہوئی ہے، اور یہ سب بہت پیچیدہ ہے۔
ہم سب DevOps میں رہتے ہیں۔
مائیکل: یہاں تک کہ کانفرنس پروگرام کمیٹی کے نقطہ نظر سے، ہمارے پاس کیلیفورنیا، نیویارک، یورپ، روس میں لوگ ہیں... سنگاپور میں ابھی تک کوئی نہیں ہے۔ جغرافیہ میں فرق کافی بڑا ہے، اور لوگ اس سے بھی زیادہ پھیلنے لگے ہیں۔ اگر ہم ترقی کے بارے میں بات کر رہے ہیں، تو کیا آپ ہمیں ڈیوپس اور ٹیموں کے درمیان رکاوٹوں کو توڑنے کے بارے میں مزید بتا سکتے ہیں؟ ایک تصور ہے کہ ہر کوئی اپنے اپنے بنکروں میں بیٹھا ہے، اور اب بنکر گر رہے ہیں، آپ اس تشبیہ کو کیا سمجھتے ہیں؟
ٹم: مجھے لگتا ہے کہ حالیہ تکنیکی پیش رفتوں کی روشنی میں، ڈیوپس بہت اہمیت کا حامل ہے۔ پہلے، آپ کے پاس ڈویلپرز اور ایڈمنسٹریٹرز کی ٹیمیں تھیں، وہ کام کرتے تھے، کام کرتے تھے، کام کرتے تھے، اور کسی وقت ایک چیز سامنے آتی تھی جس کے ساتھ آپ ایڈمنز کے پاس آ سکتے تھے اور اسے پروڈکشن کے لیے رول آؤٹ کر سکتے تھے۔ اور یہاں بنکر کے بارے میں بات چیت شروع ہوئی، کیونکہ ایڈمنز اتحادی قسم کے ہوتے ہیں، کم از کم دشمن نہیں، لیکن آپ نے ان سے تب ہی بات کی جب سب کچھ پروڈکشن میں جانے کے لیے تیار تھا۔ کیا آپ ان کے پاس کچھ لے کر گئے اور کہا: دیکھو ہمارے پاس کیا ایپلی کیشن ہے، لیکن کیا آپ اس ایپلیکیشن کو رول آؤٹ کر سکتے ہیں؟ اور اب ترسیل کا پورا تصور بہتر کے لیے بدل گیا ہے۔ میرا مطلب ہے، یہ خیال تھا کہ آپ تبدیلیوں کو تیزی سے آگے بڑھا سکتے ہیں۔ ہم پرواز پر مصنوعات کو اپ ڈیٹ کر سکتے ہیں۔ میں ہمیشہ مسکراتا ہوں جب میرے لیپ ٹاپ پر فائر فاکس پاپ اپ ہوتا ہے اور کہتا ہے، ارے، ہم نے آپ کے فائر فاکس کو پس منظر میں اپ ڈیٹ کر دیا ہے، اور جیسے ہی آپ کے پاس ایک منٹ ہے، کیا آپ کو یہاں کلک کرنے پر اعتراض ہے اور ہم آپ کو تازہ ترین ریلیز دیں گے۔ اور میں اس طرح تھا، "اوہ ہاں، بچے!" جب میں سو رہا تھا، وہ میرے کمپیوٹر پر مجھے ایک نئی ریلیز فراہم کرنے پر کام کر رہے تھے۔ یہ حیرت انگیز، ناقابل یقین ہے۔
لیکن یہاں مشکل ہے: آپ کے پاس یہ خصوصیت سافٹ ویئر کو اپ ڈیٹ کرنے کے ساتھ ہے، لیکن لوگوں کو مربوط کرنا زیادہ مشکل ہے۔ میں DevOops کے کلیدی نوٹ پر جو بات کرنا چاہتا ہوں وہ یہ ہے کہ اب ہمارے پاس پہلے سے کہیں زیادہ کھلاڑی ہیں۔ اگر آپ صرف ایک ٹیم میں شامل ہر ایک کے بارے میں سوچتے ہیں…. آپ نے اسے ایک ٹیم کے طور پر سوچا، اور یہ صرف پروگرامرز کی ایک ٹیم سے کہیں زیادہ ہے۔ یہ ٹیسٹرز، پروجیکٹ مینیجر، اور دوسرے لوگوں کا ایک گروپ ہیں۔ اور دنیا کے بارے میں ہر ایک کے اپنے خیالات ہیں۔ پروڈکٹ مینیجرز پروجیکٹ مینیجرز سے بالکل مختلف ہیں۔ ایڈمن کے اپنے کام ہیں۔ تمام شرکاء کو مربوط کرنا ایک مشکل مسئلہ بن جاتا ہے تاکہ کیا ہو رہا ہے اس سے باخبر رہیں اور پاگل نہ ہوں۔ گروپ کے کاموں اور ہر ایک پر لاگو ہونے والے کاموں کو الگ کرنا ضروری ہے۔ یہ بہت مشکل کام ہے۔ دوسری طرف، میں سمجھتا ہوں کہ یہ سب کچھ کئی سال پہلے کے مقابلے میں بہت بہتر ہے۔ یہ بالکل وہی سڑک ہے جس پر لوگ بڑھتے ہیں اور صحیح طریقے سے برتاؤ کرنا سیکھتے ہیں۔ جب آپ انضمام کرتے ہیں، تو آپ سمجھتے ہیں کہ کوئی زیر زمین ترقی نہیں ہونی چاہیے، تاکہ آخری لمحے میں سافٹ ویئر جیک ان دی باکس کی طرح رینگنے نہ پائے: جیسے، دیکھو ہم نے یہاں کیا کیا! خیال یہ ہے کہ آپ انضمام اور ترقی کرنے کے قابل ہو جائیں گے، اور آخر میں آپ صاف ستھرا اور تکراری انداز میں رول آؤٹ کریں گے۔ یہ سب میرے لیے بہت معنی رکھتا ہے۔ یہ سسٹم کے صارفین اور آپ کے کلائنٹ کے لیے مزید قدر پیدا کرنا ممکن بناتا ہے۔
مائیکل: ڈیوپس کا پورا خیال یہ ہے کہ جلد از جلد بامعنی پیشرفت کی جائے۔ میں دیکھ رہا ہوں کہ دنیا میں تیزی سے تیزی آنے لگی ہے۔ اس طرح کے سرعت کو کیسے اپنانا ہے؟ دس سال پہلے یہ موجود نہیں تھا!
ٹم: یقینا، ہر کوئی زیادہ سے زیادہ فعالیت چاہتا ہے۔ منتقل کرنے کی ضرورت نہیں، بس مزید ڈھیر لگائیں۔ بعض اوقات آپ کو اگلی اضافی اپڈیٹ کے لیے بھی کچھ بھی مفید لانے کے لیے سست کرنا پڑتا ہے - اور یہ بالکل عام بات ہے۔
یہ خیال کہ آپ کو دوڑنا، دوڑنا، دوڑنا ہے سب سے بہتر نہیں ہے۔ یہ ممکن نہیں ہے کہ کوئی بھی اپنی زندگی اس طرح گزارنا چاہتا ہو۔ میں چاہوں گا کہ ڈیلیوری کی تال پروجیکٹ کی اپنی تال قائم کرے۔ اگر آپ صرف چھوٹی، نسبتاً بے معنی چیزوں کا ایک سلسلہ تیار کرتے ہیں، تو یہ سب کچھ بے معنی ہو جاتا ہے۔ چیزوں کو جلد از جلد ریلیز کرنے کی بے فکری سے کوشش کرنے کے بجائے، جو چیز لیڈ ڈویلپرز اور پروڈکٹ اور پروجیکٹ مینیجرز کے ساتھ بات چیت کے قابل ہے وہ حکمت عملی ہے۔ کیا یہ بھی معنی رکھتا ہے؟
پیٹرن اور اینٹی پیٹرنز
اولیگ: آپ عام طور پر پیٹرن اور اینٹی پیٹرن کے بارے میں بات کرتے ہیں، اور یہ منصوبوں کی زندگی اور موت کے درمیان فرق ہے. اور اب، ڈیوپس ہماری زندگیوں میں پھٹ جاتے ہیں۔ کیا اس کا اپنا کوئی پیٹرن اور اینٹی پیٹرن ہے جو اس پروجیکٹ کو موقع پر ہی ختم کر سکتا ہے؟
ٹم: پیٹرن اور اینٹی پیٹرن ہر وقت ہوتے ہیں۔ کے بارے میں بات کرنے کے لئے کچھ. ٹھیک ہے، اس چیز کو ہم "چمکدار چیزیں" کہتے ہیں۔ لوگ واقعی، واقعی نئی ٹیکنالوجی کو پسند کرتے ہیں۔ وہ صرف ہر چیز کی چمک سے مسحور ہوتے ہیں جو ٹھنڈی اور سجیلا لگتی ہے، اور وہ سوال کرنا چھوڑ دیتے ہیں: کیا یہ ضروری بھی ہے؟ ہم کیا حاصل کرنے جا رہے ہیں؟ کیا یہ بات قابل اعتماد ہے، کیا اس کا کوئی مطلب ہے؟ میں اکثر لوگوں کو ٹیکنالوجی کے جدید ترین کنارے پر دیکھتا ہوں۔ وہ دنیا میں جو کچھ ہو رہا ہے اس سے ہپناٹائزڈ ہیں۔ لیکن اگر آپ اس پر گہری نظر ڈالیں کہ وہ کیا مفید کام کرتے ہیں، تو اکثر کچھ بھی مفید نہیں ہوتا!
ہم ابھی اپنے ساتھیوں سے بحث کر رہے تھے کہ یہ سال سالگرہ کا سال ہے، چاند پر لوگوں کو اترے پچاس سال ہو گئے ہیں۔ یہ 1969 کی بات ہے۔ جس ٹیکنالوجی نے لوگوں کو وہاں پہنچنے میں مدد کی وہ 1969 کی ٹیکنالوجی بھی نہیں ہے، بلکہ 1960 یا 62 کی ہے، کیونکہ ناسا صرف وہی استعمال کرنا چاہتا تھا جس میں قابل اعتماد ہونے کا اچھا ثبوت ہو۔ اور اس طرح آپ اسے دیکھتے ہیں اور سمجھتے ہیں - ہاں، اور وہ سچے تھے! اب، نہیں، نہیں، لیکن آپ ٹکنالوجی کے ساتھ مسائل میں پڑ جاتے ہیں صرف اس وجہ سے کہ ہر چیز کو بہت مشکل سے دھکیل دیا جاتا ہے، تمام دراڑوں سے فروخت ہوتا ہے۔ لوگ ہر طرف سے چیخ رہے ہیں: "دیکھو، کیا چیز ہے، یہ سب سے نئی چیز ہے، دنیا کی سب سے خوبصورت چیز، بالکل ہر ایک کے لیے موزوں ہے!" ٹھیک ہے، یہ ہے ... عام طور پر یہ سب کچھ صرف ایک فریب ہوتا ہے، اور پھر یہ سب پھینک دینا پڑتا ہے. شاید یہ سب اس لیے ہے کہ میں پہلے سے ہی ایک بوڑھا آدمی ہوں اور ایسی چیزوں کو بڑے شکوک و شبہات کے ساتھ دیکھتا ہوں، جب لوگ ختم ہو جاتے ہیں اور کہتے ہیں کہ انہیں بہترین ٹیکنالوجیز بنانے کا واحد، سب سے درست طریقہ مل گیا ہے۔ اس لمحے، میرے اندر ایک آواز اٹھتی ہے جو کہتی ہے: "کیا گڑبڑ ہے!"
مائیکل: درحقیقت، ہم نے چاندی کی اگلی گولی کے بارے میں کتنی بار سنا ہے؟
ٹم: بالکل، اور یہ چیزوں کا معمول ہے! مثال کے طور پر... ایسا لگتا ہے کہ یہ پہلے ہی دنیا بھر میں ایک مذاق بن چکا ہے، لیکن یہاں لوگ اکثر بلاک چین ٹیکنالوجی کے بارے میں بات کرتے ہیں۔ اور وہ حقیقت میں بعض حالات میں معنی رکھتے ہیں! جب آپ کو واقعی واقعات کے قابل اعتماد ثبوت کی ضرورت ہوتی ہے، کہ سسٹم کام کرتا ہے اور کسی نے ہمیں دھوکہ نہیں دیا، جب آپ کے پاس سیکیورٹی کے مسائل ہوں اور وہ تمام چیزیں آپس میں مل جائیں تو بلاکچین معنی رکھتا ہے۔ لیکن جب وہ کہتے ہیں کہ بلاکچین اب پوری دنیا میں جھاڑو دے گا، اپنے راستے میں موجود ہر چیز کو صاف کر دے گا؟ مزید خواب دیکھیں! یہ بہت مہنگی اور پیچیدہ ٹیکنالوجی ہے۔ تکنیکی طور پر پیچیدہ اور وقت طلب۔ مکمل طور پر الگورتھم کو بھی شامل کرتے ہوئے، ہر بار جب آپ کو معمولی تبدیلیوں کے ساتھ ریاضی کی دوبارہ گنتی کرنے کی ضرورت ہوتی ہے... اور یہ ایک بہت اچھا خیال ہے - لیکن صرف کچھ معاملات کے لیے۔ میری پوری زندگی اور کیریئر اسی کے بارے میں رہا ہے: بہت ہی مخصوص حالات میں دلچسپ خیالات۔ یہ سمجھنا بہت ضروری ہے کہ آپ کی صورتحال کیا ہے۔
مائیکل: جی ہاں، بنیادی "زندگی، کائنات اور ہر چیز کا سوال": کیا یہ ٹیکنالوجی یا طریقہ آپ کے حالات کے لیے موزوں ہے یا نہیں؟
ٹم: اس سوال پر ٹیکنالوجی گروپ کے ساتھ پہلے ہی بات کی جا سکتی ہے۔ شاید کوئی کنسلٹنٹ بھی لے آئیں۔ پروجیکٹ پر ایک نظر ڈالیں اور سمجھیں - کیا اب ہم پہلے سے بہتر اور صحیح اور مفید کام کریں گے؟ شاید یہ فٹ ہو جائے گا، شاید یہ نہیں ہو گا. لیکن سب سے اہم بات یہ ہے کہ اس طرح کا فیصلہ ڈیفالٹ نہ کریں، صرف اس وجہ سے کہ کسی نے دھندلایا: "ہمیں ایک بلاک چین کی اشد ضرورت ہے! میں نے ابھی ہوائی جہاز پر ایک میگزین میں اس کے بارے میں پڑھا تھا! سنجیدگی سے؟ یہ مضحکہ خیز بھی نہیں ہے۔
افسانوی "ڈیوپس انجینئر"
اولیگ: اب ہر کوئی ڈیوپس کو نافذ کر رہا ہے۔ کوئی انٹرنیٹ پر ڈیوپس کے بارے میں پڑھتا ہے، اور کل ایک اور خالی جگہ بھرتی کرنے والی سائٹ پر ظاہر ہوتی ہے۔ "ڈیوپس انجینئر". یہاں میں آپ کی توجہ مبذول کروانا چاہوں گا: کیا آپ کے خیال میں اس اصطلاح "ڈیوپس انجینئر" کو زندگی کا حق حاصل ہے؟ ایک رائے ہے کہ ڈیوپس ایک ثقافت ہے، اور یہاں کچھ شامل نہیں ہوتا ہے۔
ٹم: کچھ خاص نہیں. پھر وہ فوراً اس اصطلاح کی کچھ وضاحت کریں۔ اسے منفرد بنانے کے لیے کچھ۔ جب تک وہ یہ ثابت نہیں کر دیتے کہ اس طرح کی آسامی کے پیچھے مہارتوں کا کوئی انوکھا مجموعہ ہے، میں اسے نہیں خریدوں گا! میرا مطلب ہے، ٹھیک ہے، ہمارے پاس نوکری کا عنوان ہے، "ڈیوپس انجینئر،" ایک دلچسپ عنوان، ہاں، آگے کیا ہے؟ ملازمت کے عنوانات عام طور پر ایک بہت ہی دلچسپ چیز ہوتے ہیں۔ آئیے کہتے ہیں "ڈویلپر" - ویسے بھی یہ کیا ہے؟ مختلف تنظیموں کا مطلب بالکل مختلف چیزیں ہیں۔ کچھ کمپنیوں میں، اعلیٰ معیار کے پروگرامرز ایسے ٹیسٹ لکھتے ہیں جو دوسری کمپنیوں میں خصوصی پیشہ ور ٹیسٹرز کے لکھے گئے ٹیسٹوں سے زیادہ معنی خیز ہوتے ہیں۔ تو کیا، اب وہ پروگرامر ہیں یا ٹیسٹر؟
ہاں، ہمارے پاس نوکری کے عنوانات ہیں، لیکن اگر آپ کافی دیر تک سوالات پوچھتے ہیں، تو آخر کار یہ پتہ چلتا ہے کہ ہم سب مسائل حل کرنے والے ہیں۔ ہم حل تلاش کرنے والے ہیں، اور کچھ کے پاس کچھ تکنیکی مہارتیں ہیں اور کچھ مختلف ہیں۔ اگر آپ ایسے ماحول میں رہتے ہیں جہاں DevOps داخل ہو چکا ہے، تو آپ ترقی اور انتظامیہ کے انضمام میں مصروف ہیں، اور اس سرگرمی کا کچھ خاصا اہم مقصد ہے۔ لیکن اگر آپ سے پوچھا جائے کہ آپ اصل میں کیا کرتے ہیں اور آپ کس کے ذمہ دار ہیں، تو پتہ چلتا ہے کہ یہ سب کام لوگ قدیم زمانے سے کرتے چلے آ رہے ہیں۔ "میں فن تعمیر کا ذمہ دار ہوں"، "میں ڈیٹا بیس کے لیے ذمہ دار ہوں" اور اسی طرح، جو کچھ بھی ہو، آپ دیکھتے ہیں - یہ سب کچھ "ڈیوپس" سے پہلے تھا۔
جب کوئی مجھے اپنی ملازمت کا عنوان بتاتا ہے، تو میں واقعی زیادہ نہیں سنتا ہوں۔ بہتر ہے کہ وہ آپ کو بتائے کہ وہ اصل میں کس چیز کے لیے ذمہ دار ہے، اس سے ہم اس مسئلے کو زیادہ بہتر طریقے سے سمجھ سکیں گے۔ میری پسندیدہ مثال یہ ہے کہ جب کوئی شخص "پروجیکٹ مینیجر" ہونے کا دعوی کرتا ہے۔ کیا؟ اس کا کوئی مطلب نہیں ہے، میں ابھی تک نہیں جانتا کہ آپ کیا کرتے ہیں۔ ایک پروجیکٹ مینیجر ایک ڈویلپر ہوسکتا ہے، چار لوگوں کی ٹیم کا لیڈر، کوڈ لکھتا، کام کرتا، جو ٹیم لیڈ بن گیا، جسے لوگ خود اپنے درمیان لیڈر تسلیم کرتے ہیں۔ اور اس کے علاوہ، ایک پروجیکٹ مینیجر ایک مینیجر ہو سکتا ہے جو کسی پروجیکٹ پر چھ سو لوگوں کا انتظام کرتا ہے، دوسرے مینیجرز کا انتظام کرتا ہے، نظام الاوقات بنانے اور بجٹ کی منصوبہ بندی کرنے کا ذمہ دار ہوتا ہے، بس۔ یہ دو بالکل مختلف دنیایں ہیں! لیکن ان کی ملازمت کا عنوان ایک ہی لگتا ہے۔
آئیے اسے تھوڑا مختلف انداز میں موڑ دیں۔ آپ واقعی کس چیز میں اچھے ہیں، بہت تجربہ ہے، کیا آپ کے پاس ہنر ہے؟ آپ کس چیز کی ذمہ داری لیں گے کیونکہ آپ کو لگتا ہے کہ آپ کام کو سنبھال سکتے ہیں؟ اور یہاں کوئی فوری طور پر انکار کرنا شروع کر دے گا: نہیں، نہیں، نہیں، مجھے پروجیکٹ کے وسائل سے نمٹنے کی کوئی خواہش نہیں ہے، یہ میرا کاروبار نہیں ہے، میں ایک تکنیکی دوست ہوں اور میں قابل استعمال اور یوزر انٹرفیس کو سمجھتا ہوں، میں نہیں کرتا لوگوں کی فوجوں کا انتظام بالکل کرنا چاہتے ہیں، مجھے بہتر کام پر جانے دیں۔
اور ویسے، میں ایک ایسے نقطہ نظر کا ایک بڑا حامی ہوں جس میں اس قسم کی مہارت کی علیحدگی ٹھیک کام کرتی ہے۔ جہاں تکنیکی ماہرین جہاں تک چاہیں اپنے کیریئر کو بڑھا سکتے ہیں۔ تاہم، میں اب بھی ایسی تنظیموں کو دیکھتا ہوں جہاں تکنیکی ماہرین شکایت کرتے ہیں: مجھے پراجیکٹ مینجمنٹ میں جانا پڑے گا کیونکہ اس کمپنی میں یہی واحد راستہ ہے۔ بعض اوقات یہ خوفناک نتائج کی طرف جاتا ہے۔ بہترین تکنیکی ماہرین اچھے مینیجر نہیں ہوتے، اور بہترین مینیجر ٹیکنالوجی کو نہیں سنبھال سکتے۔ آئیے اس کے بارے میں ایماندار بنیں۔
میں اب اس کی بہت مانگ دیکھ رہا ہوں۔ اگر آپ ٹیکنیکل ہیں، تو آپ کی کمپنی آپ کی مدد کر سکتی ہے، لیکن اس سے قطع نظر، آپ کو واقعی اپنے کیریئر کا راستہ تلاش کرنے کی ضرورت ہے کیونکہ ٹیکنالوجی بدلتی رہتی ہے اور آپ کو اس کے ساتھ ساتھ اپنے آپ کو دوبارہ ایجاد کرنے کی ضرورت ہے! صرف بیس سالوں میں ٹیکنالوجیز کم از کم پانچ بار تبدیل ہو سکتی ہیں۔ ٹیکنالوجی ایک عجیب چیز ہے...
"ہر چیز کے ماہرین"
مائیکل: لوگ ٹیکنالوجی کی تبدیلی کی اس رفتار سے کیسے نمٹ سکتے ہیں؟ ان کی پیچیدگی بڑھ رہی ہے، ان کی تعداد بڑھ رہی ہے، لوگوں کے درمیان رابطے کی کل مقدار بھی بڑھ رہی ہے، اور یہ پتہ چلتا ہے کہ آپ "ہر چیز میں ماہر" نہیں بن سکتے۔
ٹم: ٹھیک ہے! اگر آپ ٹکنالوجی میں کام کرتے ہیں، ہاں، آپ کو یقینی طور پر کسی مخصوص چیز کا انتخاب کرنے اور اس میں دلچسپی لینے کی ضرورت ہے۔ کچھ ٹکنالوجی جو آپ کی تنظیم کو مفید معلوم ہوتی ہے (اور شاید حقیقت میں مفید ہوگی)۔ اور اگر آپ کو اس میں مزید دلچسپی نہیں ہے - مجھے کبھی یقین نہیں ہوگا کہ میں یہ کہوں گا - ٹھیک ہے، ہوسکتا ہے کہ آپ کو کسی دوسری تنظیم میں چلے جائیں جہاں ٹیکنالوجی زیادہ دلچسپ یا مطالعہ کرنے میں زیادہ آسان ہو۔
لیکن عام طور پر، ہاں، آپ ٹھیک کہتے ہیں۔ ٹیکنالوجیز ایک ساتھ تمام سمتوں میں بڑھ رہی ہیں؛ کوئی بھی یہ نہیں کہہ سکتا کہ "میں موجود تمام ٹیکنالوجیز میں ماہر ٹیکنولوجسٹ ہوں۔" دوسری طرف، ایسے سپنج لوگ ہیں جو لفظی طور پر تکنیکی علم کو جذب کرتے ہیں اور اس کے دیوانے ہیں۔ میں نے ایسے کچھ لوگوں کو دیکھا ہے، وہ لفظی سانس لیتے ہیں اور جیتے ہیں، ان سے بات کرنا مفید اور دلچسپ ہے۔ وہ نہ صرف اس بات کا مطالعہ کرتے ہیں کہ تنظیم کے اندر کیا ہو رہا ہے، بلکہ عام طور پر، وہ اس کے بارے میں بات کرتے ہیں، وہ واقعی اچھے تکنیکی ماہرین بھی ہیں، وہ بہت باشعور اور بامقصد ہیں۔ وہ صرف لہر کی چوٹی پر رہنے کی کوشش کرتے ہیں، قطع نظر اس کے کہ ان کا اصل کام کیا ہے، کیونکہ ان کا جذبہ ٹیکنالوجی کی تحریک، ٹیکنالوجی کا فروغ ہے۔ اگر آپ کی اچانک کسی ایسے شخص سے ملاقات ہو جائے تو آپ اس کے ساتھ لنچ پر جائیں اور لنچ کے دوران مختلف ٹھنڈی چیزوں پر تبادلہ خیال کریں۔ میرے خیال میں کسی بھی ادارے کو کم از کم ایسے لوگوں کی ضرورت ہوتی ہے۔
خطرات اور غیر یقینی صورتحال
مائیکل: معزز انجینئرز، جی ہاں. آئیے خطرے کے انتظام کو چھوتے ہیں جب تک ہمارے پاس وقت ہے۔ ہم نے اس انٹرویو کا آغاز طبی سافٹ ویئر کی بحث کے ساتھ کیا، جہاں غلطیاں سنگین نتائج کا باعث بن سکتی ہیں۔ پھر ہم نے قمری پروگرام کے بارے میں بات کی، جہاں ایک غلطی کی قیمت لاکھوں ڈالر ہے، اور ممکنہ طور پر کئی انسانی جانیں ہیں۔ لیکن اب میں انڈسٹری میں اس کے برعکس حرکت دیکھ رہا ہوں، لوگ خطرات کے بارے میں نہیں سوچتے، ان کی پیش گوئی کرنے کی کوشش نہیں کرتے، ان کا مشاہدہ بھی نہیں کرتے۔
اولیگ: تیزی سے حرکت کریں اور چیزوں کو توڑ دیں!
مائیکل: جی ہاں، تیزی سے حرکت کریں، چیزوں کو توڑیں، زیادہ سے زیادہ چیزیں، جب تک کہ آپ کسی چیز سے مر جائیں۔ آپ کے نقطہ نظر سے، اوسط ڈویلپر کو اب رسک مینجمنٹ سیکھنے کا طریقہ کیسے اختیار کرنا چاہیے؟
ٹم: آئیے یہاں دو چیزوں کے درمیان ایک لکیر کھینچتے ہیں: خطرات اور غیر یقینی صورتحال۔ یہ مختلف چیزیں ہیں۔ غیر یقینی صورتحال اس وقت پیدا ہوتی ہے جب آپ کے پاس کسی بھی وقت مقررہ جواب پر پہنچنے کے لیے کافی ڈیٹا نہیں ہوتا ہے۔ مثال کے طور پر، کسی پروجیکٹ کے بالکل ابتدائی مرحلے میں، اگر کوئی آپ سے پوچھے کہ "آپ کام کب ختم کریں گے"، اگر آپ کافی ایماندار شخص ہیں، تو آپ کہیں گے، "مجھے کچھ معلوم نہیں۔" آپ صرف نہیں جانتے، اور یہ ٹھیک ہے. آپ نے ابھی تک مسائل کا مطالعہ نہیں کیا اور ٹیم سے واقف نہیں ہیں، آپ کو ان کی صلاحیتوں کا علم نہیں ہے، وغیرہ۔ یہ غیر یقینی صورتحال ہے۔
خطرات اس وقت پیدا ہوتے ہیں جب ممکنہ مسائل کی پہلے ہی نشاندہی کی جا سکے۔ اس قسم کی چیز ہو سکتی ہے، اس کا امکان صفر سے زیادہ، لیکن سو فیصد سے کم، درمیان میں کہیں ہے۔ اس کی وجہ سے، تاخیر اور غیر ضروری کام سے لے کر کچھ بھی ہو سکتا ہے، لیکن یہاں تک کہ اس منصوبے کے لیے مہلک نتیجہ بھی نکل سکتا ہے۔ نتیجہ، جب آپ کہتے ہیں - دوستو، آئیے اپنی چھتریوں کو جوڑ دیں اور ساحل سمندر کو چھوڑ دیں، ہم اسے کبھی ختم نہیں کریں گے، یہ سب ختم ہو گیا، مدت۔ ہم نے قیاس کیا کہ یہ چیز کام کرے گی، لیکن یہ بالکل کام نہیں کرتا، اب رکنے کا وقت آگیا ہے۔ یہ حالات ہیں۔
اکثر، مسائل کو حل کرنا سب سے آسان ہوتا ہے جب وہ پہلے ہی ابھر چکے ہوں، جب مسئلہ ابھی ہو رہا ہو۔ لیکن جب کوئی مسئلہ آپ کے سامنے ہوتا ہے، تو آپ رسک مینجمنٹ نہیں کر رہے ہوتے — آپ مسئلہ حل کر رہے ہوتے ہیں، کرائسس مینجمنٹ کر رہے ہوتے ہیں۔ اگر آپ لیڈ ڈویلپر یا مینیجر ہیں، تو آپ سوچ رہے ہوں گے کہ ایسا کیا ہو سکتا ہے جس کی وجہ سے تاخیر، وقت ضائع، غیر ضروری اخراجات، یا پورے پروجیکٹ کے خاتمے کا خدشہ ہو؟ کیا چیز ہمیں روکنے اور دوبارہ شروع کرنے پر مجبور کرے گی؟ جب یہ سب چیزیں کام کرتی ہیں تو ہم ان کا کیا کریں گے؟ ایک سادہ سا جواب ہے جو زیادہ تر حالات کے لیے درست ہے: خطرات سے مت بھاگیں، ان پر کام کریں۔ دیکھیں کہ آپ کس طرح ایک پرخطر صورتحال کو حل کر سکتے ہیں، اسے کم کر سکتے ہیں، اسے کسی مسئلے سے کسی اور چیز میں تبدیل کر سکتے ہیں۔ یہ کہنے کے بجائے: ٹھیک ہے، ہم مسائل کو حل کریں گے جیسے ہی وہ پیدا ہوں گے۔
آپ جس چیز سے بھی نمٹتے ہیں اس میں غیر یقینی اور خطرہ سب سے آگے ہونا چاہیے۔ آپ ایک پروجیکٹ پلان لے سکتے ہیں، وقت سے پہلے کچھ اہم خطرات کو دیکھ سکتے ہیں اور کہہ سکتے ہیں: ہمیں ابھی اس سے نمٹنے کی ضرورت ہے، کیونکہ اگر اس میں سے کوئی بھی غلط ہو جاتا ہے، تو کسی اور چیز سے فرق نہیں پڑے گا۔ اگر یہ واضح نہیں ہے کہ آیا آپ رات کا کھانا بنا سکتے ہیں تو آپ کو میز پر دسترخوان کی خوبصورتی کی فکر نہیں کرنی چاہیے۔ سب سے پہلے آپ کو ایک مزیدار رات کے کھانے کی تیاری کے تمام خطرات کی نشاندہی کرنے کی ضرورت ہے، ان سے نمٹنا ہے، اور اس کے بعد ہی دوسری تمام چیزوں کے بارے میں سوچنا ہے جن سے کوئی حقیقی خطرہ نہیں ہے۔
ایک بار پھر، آپ کے پروجیکٹ کو کیا منفرد بناتا ہے؟ آئیے دیکھتے ہیں کہ ہمارے پراجیکٹ کو پٹریوں سے دور جانے کی کیا وجہ بن سکتی ہے۔ ایسا ہونے کے امکان کو کم کرنے کے لیے ہم کیا کر سکتے ہیں؟ عام طور پر آپ انہیں صرف 100٪ بے اثر نہیں کر سکتے اور صاف ضمیر کے ساتھ اعلان کر سکتے ہیں: "بس، یہ اب کوئی مسئلہ نہیں ہے، خطرہ حل ہو گیا ہے!" میرے نزدیک یہ بالغ رویے کی علامت ہے۔ یہ ایک بچے اور بالغ میں فرق ہے - بچے سمجھتے ہیں کہ وہ لافانی ہیں، کہ کچھ بھی غلط نہیں ہو سکتا، سب ٹھیک ہو جائے گا! ایک ہی وقت میں، بالغ دیکھتے ہیں کہ کس طرح تین سالہ بچے کھیل کے میدان پر چھلانگ لگاتے ہیں، ان کی آنکھوں سے حرکت کی پیروی کرتے ہیں اور اپنے آپ سے کہتے ہیں: "اوہ اوہ، اوہ اوہ۔" میں قریب ہی کھڑا رہتا ہوں اور جب بچہ گرتا ہے تو پکڑنے کے لیے تیار ہو جاتا ہوں۔
دوسری طرف، مجھے اس کاروبار کو اتنا پسند کرنے کی وجہ یہ ہے کہ یہ خطرناک ہے۔ ہم چیزیں کرتے ہیں، اور وہ چیزیں خطرناک ہیں۔ وہ ایک بالغ نقطہ نظر کی ضرورت ہے. صرف جوش آپ کے مسائل حل نہیں کرے گا!
بالغ انجینئرنگ سوچ
مائیکل: بچوں کے ساتھ مثال اچھی ہے۔ اگر میں ایک عام انجینئر ہوں تو مجھے بچہ ہونے پر خوشی ہے۔ لیکن آپ زیادہ بالغ سوچ کی طرف کیسے بڑھیں گے؟
ٹم: ان خیالات میں سے ایک جو ابتدائی یا قائم شدہ ڈویلپر کے ساتھ یکساں طور پر کام کرتا ہے وہ سیاق و سباق کا تصور ہے۔ ہم کیا کر رہے ہیں، ہم کیا حاصل کرنے جا رہے ہیں۔ اس منصوبے پر واقعی کیا اہم ہے؟ اس سے کوئی فرق نہیں پڑتا کہ آپ اس پروجیکٹ میں کون ہیں، چاہے آپ انٹرن ہوں یا چیف آرکیٹیکٹ، ہر کسی کو سیاق و سباق کی ضرورت ہے۔ ہمیں ہر ایک کو اپنے کام کے ٹکڑوں سے زیادہ بڑے پیمانے پر سوچنے کی ضرورت ہے۔ "میں اپنا ٹکڑا بناتا ہوں، اور جب تک میرا ٹکڑا کام کرتا ہے، میں خوش ہوں۔" نہیں اور دوبارہ نہیں۔ لوگوں کو جس سیاق و سباق میں وہ کام کرتے ہیں اس کی یاد دلانا ہمیشہ (بدتمیزی کے بغیر!) قابل قدر ہے۔ جسے ہم سب مل کر حاصل کرنے کی کوشش کر رہے ہیں۔ یہ خیالات کہ آپ اس وقت تک بچے بن سکتے ہیں جب تک کہ آپ کے پروجیکٹ کے ٹکڑے کے ساتھ سب کچھ ٹھیک ہے - براہ کرم، ایسا نہ کریں۔ اگر ہم بالکل بھی فنش لائن کو عبور کرتے ہیں، تو ہم اسے صرف ایک ساتھ کراس کریں گے۔ آپ اکیلے نہیں ہیں، ہم سب ساتھ ہیں۔ اگر پروجیکٹ میں شامل تمام لوگ، بوڑھے اور جوان دونوں، اس بارے میں بات کرنا شروع کر دیں کہ اس منصوبے کے لیے بالکل کیا اہم ہے، کمپنی اس میں پیسہ کیوں لگا رہی ہے جسے ہم سب حاصل کرنے کی کوشش کر رہے ہیں... ان میں سے اکثر بہت بہتر محسوس کریں گے کیونکہ وہ دیکھیں گے کہ ان کا کام باقی سب کے کام سے کس طرح مطابقت رکھتا ہے۔ ایک طرف، میں اس ٹکڑے کو سمجھتا ہوں جس کے لیے میں ذاتی طور پر ذمہ دار ہوں۔ لیکن کام ختم کرنے کے لیے ہمیں دوسرے تمام لوگوں کی بھی ضرورت ہے۔ اور اگر آپ واقعی سوچتے ہیں کہ آپ نے کام کر لیا ہے، تو ہمارے پاس ہمیشہ اس پروجیکٹ میں کام کرنا ہوتا ہے!
اولیگ: نسبتاً، اگر آپ کنبان کے مطابق کام کرتے ہیں، جب آپ کچھ ٹیسٹنگ کی رکاوٹ کو مارتے ہیں، تو آپ وہاں جو کچھ کر رہے تھے اسے چھوڑ سکتے ہیں (مثال کے طور پر، پروگرامنگ) اور جا کر ٹیسٹرز کی مدد کر سکتے ہیں۔
ٹم: بالکل۔ میرے خیال میں بہترین تکنیکی ماہرین، اگر آپ ان کو قریب سے دیکھیں تو وہ اپنے ہی مینیجرز کی طرح ہیں۔ میں یہ کیسے بنا سکتا ہوں...
اولیگ: آپ کی زندگی آپ کا پروجیکٹ ہے، جس کا آپ انتظام کرتے ہیں۔
ٹم: بالکل! میرا مطلب ہے، آپ ذمہ داری لیتے ہیں، آپ اس مسئلے کو سمجھتے ہیں، اور جب آپ دیکھتے ہیں کہ آپ کے فیصلے ان کے کام کو متاثر کر سکتے ہیں تو آپ لوگوں سے رابطے میں آتے ہیں، اس طرح کی چیزیں۔ یہ صرف آپ کی میز پر بیٹھنے، اپنا کام کرنے، اور آپ کے ارد گرد کیا ہو رہا ہے اس کا احساس تک نہیں ہے۔ نہیں نہیں نہیں. ویسے، Agile کے بارے میں سب سے اچھی بات یہ ہے کہ انہوں نے مختصر سپرنٹ کی تجویز پیش کی، کیونکہ اس طرح تمام شرکاء کی حالت واضح طور پر قابل مشاہدہ ہے، وہ یہ سب ایک ساتھ دیکھ سکتے ہیں۔ ہم ہر روز ایک دوسرے کے بارے میں بات کرتے ہیں۔
رسک مینجمنٹ میں کیسے جائیں
اولیگ: کیا اس علاقے میں علم کا کوئی باضابطہ ڈھانچہ ہے؟ مثال کے طور پر، میں جاوا ڈویلپر ہوں اور تعلیم کے ذریعے حقیقی پروجیکٹ مینیجر بنے بغیر رسک مینجمنٹ کو سمجھنا چاہتا ہوں۔ میں شاید پہلے میک کونل کا "سافٹ ویئر پروجیکٹ کی لاگت کتنی ہے" پڑھوں گا، اور پھر کیا؟ پہلے اقدامات کیا ہیں؟
ٹم: سب سے پہلے پروجیکٹ میں لوگوں کے ساتھ بات چیت شروع کرنا ہے۔ یہ ساتھیوں کے ساتھ رابطے کے کلچر میں فوری بہتری فراہم کرتا ہے۔ ہمیں ہر چیز کو چھپانے کے بجائے بطور ڈیفالٹ کھول کر شروع کرنے کی ضرورت ہے۔ کہو: یہ وہ چیزیں ہیں جو مجھے پریشان کرتی ہیں، یہ وہ چیزیں ہیں جو مجھے رات کو جاگتی رہتی ہیں، میں آج رات کو جاگتا تھا اور ایسا تھا: میرے خدا، مجھے اس کے بارے میں سوچنے کی ضرورت ہے! کیا دوسروں کو بھی یہی نظر آتا ہے؟ ایک گروپ کے طور پر، کیا ہمیں ان ممکنہ مسائل کا جواب دینا چاہئے؟ آپ کو ان موضوعات پر بحث کی حمایت کرنے کے قابل ہونے کی ضرورت ہے۔ کوئی پہلے سے تیار شدہ فارمولہ نہیں ہے جس کے ذریعے ہم کام کرتے ہیں۔ یہ ہیمبرگر بنانے کے بارے میں نہیں ہے، یہ سب لوگوں کے بارے میں ہے۔ "چیزبرگر بنایا، چیزبرگر بیچیں" ہماری چیز بالکل نہیں ہے، اور اسی وجہ سے مجھے یہ کام بہت پسند ہے۔ مجھے یہ پسند ہے جب سب کچھ جو مینیجر کرتے تھے اب ٹیم کی ملکیت بن جاتی ہے۔
اولیگ: آپ نے کتابوں اور انٹرویوز میں اس بارے میں بات کی ہے کہ کس طرح لوگ گراف پر نمبروں سے زیادہ خوشی کی فکر کرتے ہیں۔ دوسری طرف، جب آپ ٹیم کو کہتے ہیں: ہم ڈیوپس کی طرف بڑھ رہے ہیں، اور اب پروگرامر کو مسلسل بات چیت کرنی چاہیے، یہ اس کے کمفرٹ زون سے بہت باہر ہو سکتا ہے۔ اور اس لمحے وہ کہہ سکتا ہے کہ وہ بہت زیادہ ناخوش ہے۔ اس صورت حال میں کیا کیا جائے؟
ٹم: مجھے یقین نہیں ہے کہ کیا کرنا ہے۔ اگر کوئی ڈویلپر بہت الگ تھلگ ہے، تو وہ یہ نہیں دیکھتے کہ کام پہلے کیوں کیا جا رہا ہے، وہ صرف اپنے کام کے حصے کو دیکھتے ہیں، اور انہیں اس میں جانے کی ضرورت ہے جسے میں "سیاق و سباق" کہتا ہوں۔ اسے یہ جاننے کی ضرورت ہے کہ سب کچھ آپس میں کیسے جڑا ہوا ہے۔ اور ظاہر ہے، میرا مطلب رسمی پیشکش یا اس طرح کی کوئی چیز نہیں ہے۔ میں اس حقیقت کے بارے میں بات کر رہا ہوں کہ آپ کو مجموعی طور پر کام کے بارے میں ساتھیوں کے ساتھ بات چیت کرنے کی ضرورت ہے، نہ کہ صرف اس کے اس حصے کے بارے میں جس کے لیے آپ ذمہ دار ہیں۔ یہ وہ جگہ ہے جہاں آپ خیالات، مشترکہ معاہدوں پر بات چیت شروع کر سکتے ہیں تاکہ آپ کے کام کو اچھی طرح سے فٹ کیا جا سکے، اور ایک ساتھ مل کر مشترکہ مسئلہ سے کیسے نمٹا جائے۔
ان کو اپنانے میں مدد کرنے کے لیے، وہ اکثر ٹیکنیز کو تربیت کے لیے بھیجنا چاہتے ہیں، اور وہ تربیت پر تبادلہ خیال کرتے ہیں۔ میرا ایک دوست یہ کہنا پسند کرتا ہے کہ تربیت کتوں کی ہے۔ لوگوں کی تربیت ہے۔ ایک ڈویلپر کے طور پر سیکھنے کے بارے میں بہترین چیزوں میں سے ایک آپ کے ساتھیوں کے ساتھ بات چیت کرنا ہے۔ اگر کوئی واقعی کسی چیز میں اچھا ہے، تو آپ کو اسے کام کرتے دیکھنا چاہیے یا ان سے ان کے کام یا کسی اور چیز کے بارے میں بات کرنی چاہیے۔ کچھ روایتی کینٹ بیک نے مسلسل انتہائی پروگرامنگ کے بارے میں بات کی۔ یہ مضحکہ خیز ہے کیونکہ XP اتنا آسان خیال ہے، لیکن یہ بہت ساری پریشانیوں کا سبب بنتا ہے۔ کچھ لوگوں کے لیے، XP کرنا دوستوں کے سامنے برہنہ ہونے پر مجبور ہونے جیسا ہے۔ وہ دیکھیں گے کہ میں کیا کر رہا ہوں! وہ میرے ساتھی ہیں، وہ نہ صرف دیکھیں گے، بلکہ سمجھیں گے! خوفناک! کچھ لوگ سنجیدگی سے گھبرانے لگے ہیں۔ لیکن جب آپ کو احساس ہوتا ہے کہ یہ سیکھنے کا حتمی طریقہ ہے، تو سب کچھ بدل جاتا ہے۔ آپ لوگوں کے ساتھ مل کر کام کرتے ہیں، اور کچھ لوگ اس موضوع کو آپ سے زیادہ بہتر سمجھتے ہیں۔
مائیکل: لیکن یہ سب آپ کو اپنے کمفرٹ زون سے باہر نکلنے پر مجبور کرتا ہے۔ بطور انجینئر، آپ کو اپنے کمفرٹ زون سے باہر نکل کر بات چیت کرنی ہوگی۔ ایک مسئلہ حل کرنے والے کے طور پر، آپ کو اپنے آپ کو مسلسل کمزور پوزیشن میں رکھنا ہوگا اور سوچنا ہوگا کہ کیا غلط ہوسکتا ہے۔ اس قسم کا کام فطری طور پر ایک پریشانی کے لیے ڈیزائن کیا گیا ہے۔ آپ جان بوجھ کر اپنے آپ کو دباؤ والے حالات میں ڈالتے ہیں۔ عام طور پر لوگ ان سے دور بھاگتے ہیں، لوگ خوش مزاج بچے بننا پسند کرتے ہیں۔
ٹم: کیا کیا جا سکتا ہے، آپ باہر آ سکتے ہیں اور کھل کر کہہ سکتے ہیں: "سب کچھ ٹھیک ہے، میں اسے سنبھال سکتا ہوں! میں اکیلا نہیں ہوں جو بے چینی محسوس کرتا ہے۔ آئیے ایک ٹیم کے طور پر، سب مل کر، مختلف غیر آرام دہ چیزوں پر تبادلہ خیال کریں!" یہ ہمارے مشترکہ مسائل ہیں، ہمیں ان سے نمٹنا چاہیے، آپ جانتے ہیں؟ میرے خیال میں غیر معمولی جینیئس ڈویلپرز میمتھ کی طرح ہیں، وہ غائب ہو گئے۔ اور ان کی اہمیت بہت محدود ہے۔ اگر آپ بات چیت نہیں کر سکتے، تو آپ اچھی طرح سے حصہ نہیں لے سکتے۔ اس لیے بس بولیں۔ ایماندار اور کھلے رہو. مجھے بہت افسوس ہے کہ یہ کسی کے لیے ناگوار ہے۔ کیا آپ سوچ سکتے ہیں کہ کئی سال پہلے ایک تحقیق سامنے آئی تھی جس کے مطابق امریکہ میں اصل خوف موت نہیں بلکہ کیا ہے؟ عوامی تقریر کا خوف! اس کا مطلب یہ ہے کہ کہیں ایسے لوگ ہیں جو اونچی آواز میں تعریف کہنے کے بجائے مرنا پسند کریں گے۔ اور مجھے لگتا ہے کہ آپ کے لیے کچھ بنیادی مہارتیں ہونا کافی ہے، اس پر منحصر ہے کہ آپ کیا کرتے ہیں۔ بولنے کی مہارت، لکھنے کی مہارت - لیکن صرف اتنا ہی جتنا آپ کے کام میں درکار ہے۔ اگر آپ تجزیہ کار کے طور پر کام کرتے ہیں، لیکن پڑھ، لکھ یا بول نہیں سکتے، تو، بدقسمتی سے، آپ کو میرے پروجیکٹس میں کچھ نہیں کرنا پڑے گا!
مواصلات کی قیمت
اولیگ: کیا ایسے سبکدوش ملازمین کو مختلف وجوہات کی بنا پر ملازمت دینا زیادہ مہنگا نہیں ہے؟ سب کے بعد، وہ کام کرنے کے بجائے مسلسل چیٹنگ کر رہے ہیں!
ٹم: میرا مطلب ٹیم کا مرکز تھا، اور نہ صرف ہر کوئی۔ اگر آپ کے پاس کوئی ایسا ہے جو ڈیٹا بیس کو ٹیوننگ کرنے میں واقعی اچھا ہے، ڈیٹا بیس کو ٹیوننگ سے محبت کرتا ہے، اور اپنی ساری زندگی آپ کے ڈیٹا بیس کو ٹیون کرنا جاری رکھے گا اور بس، اچھا، اسے جاری رکھیں۔ لیکن میں ان لوگوں کے بارے میں بات کر رہا ہوں جو پروجیکٹ میں ہی رہنا چاہتے ہیں۔ ٹیم کا بنیادی مقصد، اس منصوبے کو تیار کرنا ہے۔ یہ لوگ واقعی ایک دوسرے کے ساتھ مسلسل بات چیت کرنے کی ضرورت ہے. اور خاص طور پر پراجیکٹ کے آغاز میں، جب آپ خطرات، عالمی اہداف حاصل کرنے کے طریقوں اور اس طرح کی چیزوں پر گفتگو کرتے ہیں۔
مائیکل: اس کا اطلاق پراجیکٹ میں شامل ہر فرد پر ہوتا ہے، قطع نظر اسپیشلائزیشن، ہنر، یا کام کرنے کے طریقے۔ آپ سب اس منصوبے کی کامیابی میں دلچسپی رکھتے ہیں۔
ٹم: جی ہاں، آپ محسوس کرتے ہیں کہ آپ اس منصوبے میں کافی حد تک ڈوبے ہوئے ہیں، کہ آپ کا کام اس منصوبے کو پورا کرنے میں مدد کرنا ہے۔ چاہے آپ پروگرامر، تجزیہ کار، انٹرفیس ڈیزائنر، کوئی بھی ہوں۔ یہی وجہ ہے کہ میں روزانہ صبح کام پر آتا ہوں اور ہم یہی کرتے ہیں۔ ہم ان تمام لوگوں کے ذمہ دار ہیں، چاہے ان کی مہارت کچھ بھی ہو۔ یہ بالغوں کی گفتگو کرنے والے لوگوں کا ایک گروپ ہے۔
اولیگ: درحقیقت باتونی ملازمین کے بارے میں بات کرتے ہوئے، میں نے لوگوں کے اعتراضات کو نقل کرنے کی کوشش کی، خاص طور پر مینیجرز، جنہیں ڈیوپس پر جانے کے لیے کہا جاتا ہے، دنیا کے اس پورے نئے وژن کی طرف۔ اور آپ کو، بطور مشیر، ایک ڈویلپر کے طور پر، مجھ سے زیادہ بہتر طور پر ان اعتراضات سے آگاہ ہونا چاہیے! مینیجرز کو سب سے زیادہ پریشان کن چیزوں کا اشتراک کریں؟
ٹم: مینیجرز؟ ہم اکثر، مینیجرز مسائل کے دباؤ میں ہوتے ہیں، انہیں فوری طور پر کسی چیز کو جاری کرنے اور ڈیلیوری کرنے کی ضرورت کا سامنا کرنا پڑتا ہے، وغیرہ۔ وہ دیکھتے ہیں کہ ہم کس طرح کسی چیز کے بارے میں مسلسل بحث اور بحث کرتے ہیں، اور وہ اسے اس طرح دیکھتے ہیں: گفتگو، گفتگو، مکالمات... اور کون سی گفتگو؟ واپس جاو کام پر! کیونکہ بات کرنا انہیں کام کی طرح محسوس نہیں ہوتا۔ آپ کوڈ نہیں لکھتے، سافٹ ویئر کی جانچ نہیں کرتے، ایسا نہیں لگتا کہ آپ کچھ کرتے ہیں - آپ کو کچھ کرنے کے لیے کیوں نہیں بھیجتے؟ سب کے بعد، ترسیل پہلے ہی ایک مہینے میں ہے!
مائیکل: جاؤ کچھ کوڈ لکھو!
ٹم: مجھے ایسا لگتا ہے کہ وہ کام کے بارے میں نہیں، لیکن ترقی کی نمائش کی کمی کے بارے میں فکر مند ہیں. ایسا محسوس کرنے کے لیے کہ ہم کامیابی کے قریب پہنچ رہے ہیں، انہیں ہمیں کی بورڈ پر بٹن دباتے ہوئے دیکھنے کی ضرورت ہے۔ صبح سے شام تک سارا دن۔ یہ مسئلہ نمبر ایک ہے۔
اولیگ: میشا تم کچھ سوچ رہی ہو۔
مائیکل: معذرت، میں سوچ میں گم ہو گیا اور فلیش بیک پکڑا۔ اس سب نے مجھے ایک دلچسپ ریلی کی یاد دلا دی جو کل ہوئی تھی... کل بہت زیادہ ریلیاں تھیں... اور یہ سب بہت مانوس لگتا ہے!
تنخواہ کے بغیر زندگی
ٹم: ویسے ابلاغ کے لیے ’’ریلیوں‘‘ کا اہتمام کرنا بالکل ضروری نہیں ہے۔ میرا مطلب ہے، ڈویلپرز کے درمیان سب سے مفید بات چیت اس وقت ہوتی ہے جب وہ صرف ایک دوسرے سے بات کرتے ہیں۔ آپ صبح ایک کپ کافی کے ساتھ چلتے ہیں، اور وہاں پانچ لوگ جمع ہیں اور غصے سے کسی تکنیکی بات پر بحث کر رہے ہیں۔ میرے لیے، اگر میں اس پروجیکٹ کا مینیجر ہوں، تو بہتر ہے کہ بس مسکرا کر اپنے کاروبار کے بارے میں کہیں جاؤں، انہیں اس پر بات کرنے دیں۔ وہ پہلے سے ہی زیادہ سے زیادہ ملوث ہیں. یہ ایک اچھی علامت ہے۔
اولیگ: ویسے آپ کی کتاب میں نوٹوں کا ایک گچھا ہے کہ کیا اچھا ہے اور کیا برا۔ کیا آپ خود ان میں سے کسی کو استعمال کرتے ہیں؟ نسبتاً بولتے ہوئے، اب آپ کے پاس ایک کمپنی ہے، اور وہ ایک بہت ہی غیر روایتی انداز میں تشکیل دی گئی ہے...
ٹم: غیر روایتی، لیکن یہ آلہ ہمارے لیے بالکل مناسب ہے۔ ہم ایک دوسرے کو کافی عرصے سے جانتے ہیں۔ ہم ایک دوسرے پر بھروسہ کرتے ہیں، ہم شراکت دار بننے سے پہلے ایک دوسرے پر بہت اعتماد کرتے تھے۔ اور مثال کے طور پر، ہمارے پاس کوئی تنخواہ نہیں ہے. ہم صرف کام کرتے ہیں، اور مثال کے طور پر، اگر میں نے اپنے کلائنٹس سے پیسے کمائے، تو ساری رقم میرے پاس چلی گئی۔ اس کے بعد، ہم تنظیم کو رکنیت کی فیس ادا کرتے ہیں، اور یہ خود کمپنی کی مدد کے لیے کافی ہے۔ اس کے علاوہ، ہم سب مختلف چیزوں میں مہارت رکھتے ہیں۔ مثال کے طور پر، میں اکاؤنٹنٹس کے ساتھ کام کرتا ہوں، ٹیکس ریٹرن بھرتا ہوں، کمپنی کے لیے ہر طرح کے انتظامی کام کرتا ہوں، اور کوئی بھی مجھے اس کے لیے ادائیگی نہیں کرتا۔ جیمز اور ٹام ہماری ویب سائٹ پر کام کرتے ہیں اور کوئی بھی انہیں ادائیگی نہیں کرتا ہے۔ جب تک آپ اپنے واجبات ادا کرتے ہیں، کوئی بھی آپ کو یہ بتانے کے بارے میں نہیں سوچے گا کہ آپ کو کیا کرنے کی ضرورت ہے۔ مثال کے طور پر، ٹام اب پہلے کے مقابلے میں بہت کم کام کرتا ہے۔ اب اس کی دوسری دلچسپیاں ہیں؛ وہ کچھ چیزیں کرتا ہے جو گلڈ کے لیے نہیں ہے۔ لیکن جب تک وہ اپنے واجبات ادا کرتا ہے، کوئی بھی اس کے پاس نہیں آئے گا اور کہے گا، "ارے، ٹام، کام پر جاؤ!" جب آپ کے درمیان پیسے نہ ہوں تو ساتھیوں سے نمٹنا بہت آسان ہے۔ اور اب ہمارا تعلق مختلف خصوصیات کے سلسلے میں بنیادی نظریات میں سے ایک ہے۔ یہ کام کرتا ہے اور یہ بہت اچھا کام کرتا ہے۔
بہترین مشورہ
مائیکل: "بہترین مشورے" پر واپس جانا، کیا آپ اپنے مؤکلوں کو بار بار بتاتے ہیں؟ 80/20 کے بارے میں ایک خیال ہے، اور کچھ مشورہ شاید زیادہ کثرت سے دہرایا جاتا ہے۔
ٹم: میں نے ایک بار سوچا تھا کہ اگر آپ نے والٹزنگ ود بیئرز جیسی کتاب لکھی تو یہ تاریخ کا دھارا بدل دے گی اور لوگ رک جائیں گے، لیکن... ٹھیک ہے، دیکھو، کمپنیاں اکثر یہ دکھاوا کرتی ہیں کہ ان کے ساتھ سب کچھ ٹھیک ہے۔ جیسے ہی کچھ برا ہوتا ہے، یہ ان کے لیے صدمہ اور سرپرائز ہوتا ہے۔ "دیکھیں، ہم نے سسٹم کا تجربہ کیا، اور یہ سسٹم کا کوئی ٹیسٹ پاس نہیں کرتا، اور یہ مزید تین ماہ کا غیر طے شدہ کام ہے، یہ کیسے ہو سکتا ہے؟ کون جانتا تھا؟ کیا غلط ہو سکتا ہے؟ سنجیدگی سے، کیا آپ اس پر یقین رکھتے ہیں؟
میں سمجھانے کی کوشش کر رہا ہوں کہ آپ کو موجودہ صورتحال پر زیادہ غصہ نہیں آنا چاہیے۔ ہمیں اس پر بات کرنے کی ضرورت ہے، واقعی یہ سمجھنا چاہیے کہ کیا غلط ہو سکتا ہے، اور مستقبل میں ایسی چیزوں کو ہونے سے کیسے روکا جائے۔ اگر کوئی مسئلہ ظاہر ہوتا ہے تو ہم اس کا مقابلہ کیسے کریں گے، اس پر کیسے قابو پائیں گے؟
میرے نزدیک یہ سب خوفناک لگتا ہے۔ لوگ پیچیدہ، پریشان کن مسائل سے نمٹتے ہیں اور یہ دکھاوا کرتے رہتے ہیں کہ اگر وہ صرف اپنی انگلیاں عبور کرتے ہیں اور بہترین کی امید کرتے ہیں، تو "بہترین" واقعتاً ہوگا۔ نہیں، یہ اس طرح کام نہیں کرتا ہے۔
رسک مینجمنٹ کی مشق کریں!
مائیکل: آپ کی رائے میں، کتنی تنظیمیں رسک مینجمنٹ میں مصروف ہیں؟
ٹم: جو چیز مجھے پریشان کرتی ہے وہ یہ ہے کہ لوگ صرف خطرات لکھتے ہیں، نتیجے کی فہرست کو دیکھتے ہیں اور کام پر جاتے ہیں۔ درحقیقت، ان کے لیے خطرات کی نشاندہی کرنا رسک مینجمنٹ ہے۔ لیکن میرے نزدیک یہ پوچھنے کی ایک وجہ کی طرح لگتا ہے: ٹھیک ہے، ایک فہرست ہے، آپ بالکل کیا تبدیل کریں گے؟ آپ کو ان خطرات کو مدنظر رکھتے ہوئے اقدامات کے اپنے معیاری سلسلے کو تبدیل کرنے کی ضرورت ہے۔ اگر کام کا کچھ سب سے مشکل حصہ ہے، تو آپ کو اس سے نمٹنے کی ضرورت ہے، اور تب ہی کسی آسان چیز کی طرف بڑھیں۔ پہلے سپرنٹ میں، پیچیدہ مسائل کو حل کرنا شروع کریں۔ یہ پہلے سے ہی رسک مینجمنٹ کی طرح لگتا ہے۔ لیکن عام طور پر لوگ یہ نہیں کہہ سکتے کہ خطرات کی فہرست مرتب کرنے کے بعد ان میں کیا تبدیلی آئی ہے۔
مائیکل: اور ابھی تک، ان میں سے کتنی کمپنیاں رسک مینجمنٹ میں شامل ہیں، پانچ فیصد؟
ٹم: بدقسمتی سے، مجھے یہ کہنے سے نفرت ہے، لیکن یہ کچھ بہت ہی معمولی حصہ ہے۔ لیکن پانچ سے زیادہ، کیونکہ واقعی بڑے منصوبے ہیں، اور اگر وہ کم از کم کچھ نہ کریں تو وہ صرف موجود نہیں رہ سکتے۔ آئیے صرف یہ کہتے ہیں کہ اگر یہ کم از کم 25٪ ہے تو مجھے بہت حیرت ہوگی۔ چھوٹے منصوبے عام طور پر اس طرح کے سوالات کا جواب دیتے ہیں: اگر مسئلہ ہمیں متاثر کرتا ہے، تو ہم اسے حل کریں گے۔ پھر وہ کامیابی کے ساتھ اپنے آپ کو مشکل میں ڈالتے ہیں اور مسئلہ کے انتظام اور بحران کے انتظام میں مشغول ہوجاتے ہیں۔ جب آپ کسی مسئلے کو حل کرنے کی کوشش کرتے ہیں اور مسئلہ حل نہیں ہوتا ہے تو بحران کے انتظام میں خوش آمدید۔
جی ہاں، میں اکثر سنتا ہوں، "ہم مسائل کے پیدا ہوتے ہی حل کریں گے۔" یقینا ہم کریں گے؟ کیا ہم واقعی فیصلہ کریں گے؟
اولیگ: آپ اسے آسانی سے کر سکتے ہیں اور پراجیکٹ چارٹر میں صرف اہم انویرینٹس لکھ سکتے ہیں، اور اگر انویرینٹس ٹوٹ جاتے ہیں، تو بس پروجیکٹ کو دوبارہ شروع کریں۔ یہ بہت piembucky باہر کر دیتا ہے.
مائیکل: جی ہاں، میرے ساتھ یہ ہوا کہ جب خطرات کو متحرک کیا گیا تو اس منصوبے کو آسانی سے نئے سرے سے بیان کیا گیا۔ اچھا، بنگو، مسئلہ حل ہو گیا، مزید پریشان نہ ہوں!
ٹم: آئیے ری سیٹ بٹن دبائیں! نہیں، یہ اس طرح کام نہیں کرتا ہے۔
DevOops 2019 میں کلیدی بیان
مائیکل: ہم اس انٹرویو کے آخری سوال کی طرف آتے ہیں۔ آپ کلیدی نوٹ کے ساتھ اگلے DevOops پر آ رہے ہیں، کیا آپ جو کچھ بتانے جا رہے ہیں اس پر رازداری کا پردہ اٹھا سکتے ہیں؟
ٹم: ابھی، ان میں سے چھ ورک کلچر، تنظیموں کے غیر کہے گئے اصولوں کے بارے میں ایک کتاب لکھ رہے ہیں۔ ثقافت کا تعین تنظیم کی بنیادی اقدار سے ہوتا ہے۔ عام طور پر لوگ اس کا نوٹس نہیں لیتے، لیکن کئی سالوں سے مشاورت میں کام کرنے کے بعد، ہم اسے نوٹس کرنے کے عادی ہیں۔ آپ ایک کمپنی میں داخل ہوتے ہیں، اور لفظی طور پر چند منٹوں میں آپ محسوس کرنے لگتے ہیں کہ کیا ہو رہا ہے۔ ہم اسے "ذائقہ" کہتے ہیں۔ کبھی کبھی یہ خوشبو واقعی اچھی ہوتی ہے، اور کبھی کبھی یہ، ٹھیک ہے، افوہ۔ مختلف تنظیموں کے لیے چیزیں بہت مختلف ہیں۔
مائیکل: میں بھی برسوں سے مشاورت میں کام کر رہا ہوں اور اچھی طرح سمجھتا ہوں کہ آپ کیا بات کر رہے ہیں۔
ٹم: دراصل، کلیدی نوٹ میں بات کرنے کے قابل چیزوں میں سے ایک یہ ہے کہ ہر چیز کا تعین کمپنی کے ذریعہ نہیں کیا جاتا ہے۔ آپ اور آپ کی ٹیم، ایک کمیونٹی کے طور پر، آپ کی اپنی ٹیم کی ثقافت ہے۔ یہ پوری کمپنی، یا ایک الگ محکمہ، ایک الگ ٹیم ہو سکتی ہے۔ لیکن اس سے پہلے کہ آپ نے کہا، یہاں وہی ہے جو ہم مانتے ہیں، یہاں اہم ہے... آپ کسی ثقافت کو تبدیل نہیں کر سکتے جب تک کہ مخصوص اعمال کے پیچھے موجود اقدار اور عقائد کو سمجھا نہ جائے۔ رویے کا مشاہدہ کرنا آسان ہے، لیکن عقائد کی تلاش مشکل ہے۔ DevOps صرف ایک عمدہ مثال ہے کہ چیزیں کس طرح پیچیدہ ہوتی جارہی ہیں۔ تعاملات صرف پیچیدہ ہوتے جا رہے ہیں، وہ بالکل صاف یا واضح نہیں ہو رہے ہیں، اس لیے آپ کو سوچنا چاہیے کہ آپ کس چیز پر یقین رکھتے ہیں اور آپ کے آس پاس کا ہر شخص کس چیز کے بارے میں خاموش ہے۔
اگر آپ فوری نتائج حاصل کرنا چاہتے ہیں، تو یہ آپ کے لیے ایک اچھا موضوع ہے: کیا آپ نے ایسی کمپنیاں دیکھی ہیں جہاں کوئی نہیں کہتا کہ "میں نہیں جانتا"؟ ایسی جگہیں ہیں جہاں آپ لفظی طور پر کسی شخص پر تشدد کرتے ہیں جب تک کہ وہ یہ تسلیم نہ کر لے کہ وہ کچھ نہیں جانتا۔ ہر کوئی سب کچھ جانتا ہے، ہر کوئی ایک ناقابل یقین ماہر ہے. آپ کسی بھی شخص سے رجوع کریں، اور اسے فوری طور پر سوال کا جواب دینا ہوگا۔ "میں نہیں جانتا" کہنے کے بجائے۔ ہورے، انہوں نے علما کے ایک گروپ کی خدمات حاصل کی ہیں! اور کچھ ثقافتوں میں عام طور پر یہ کہنا بہت خطرناک ہے کہ "میں نہیں جانتا"؛ اسے کمزوری کی علامت سمجھا جا سکتا ہے۔ ایسی تنظیمیں بھی ہیں جن میں، اس کے برعکس، ہر کوئی کہہ سکتا ہے "مجھے نہیں معلوم۔" وہاں یہ مکمل طور پر قانونی ہے، اور اگر کوئی کسی سوال کے جواب میں کوڑا کرکٹ پھینکنا شروع کر دے، تو اس کا جواب دینا بالکل معمول کی بات ہے: "آپ نہیں جانتے کہ آپ کس بارے میں بات کر رہے ہیں، ٹھیک ہے؟" اور یہ سب ایک مذاق میں تبدیل.
مثالی طور پر، آپ ایسی نوکری کرنا چاہیں گے جہاں آپ مسلسل خوش رہ سکیں۔ یہ آسان نہیں ہوگا، ہر دن دھوپ اور خوشگوار نہیں ہوتا، کبھی کبھی آپ کو سخت محنت کرنے کی ضرورت ہوتی ہے، لیکن جب آپ اسٹاک لینا شروع کریں گے، تو یہ نکلے گا: واہ، یہ واقعی ایک شاندار جگہ ہے، مجھے یہاں کام کرنا اچھا لگتا ہے، دونوں جذباتی اور فکری طور پر. اور ایسی کمپنیاں ہیں جہاں آپ کنسلٹنٹ کے طور پر جاتے ہیں اور فوری طور پر احساس ہوتا ہے کہ آپ اسے تین مہینے تک برداشت نہیں کر سکتے اور خوفزدہ ہو کر بھاگ جائیں گے۔ یہ وہی ہے جس کے بارے میں میں رپورٹ میں بات کرنا چاہتا ہوں۔
ٹم لسٹر ایک کلیدی نوٹ کے ساتھ آئے گا۔ DevOops 2019 کانفرنس میں، جو 29-30 اکتوبر 2019 کو سینٹ پیٹرزبرگ میں ہوگی۔ آپ ٹکٹ خرید سکتے ہیں۔ . ہم DevOops پر آپ کا انتظار کر رہے ہیں!
ماخذ: www.habr.com