ایک ٹیم میں تنازعات کا انتظام - ایک توازن عمل یا ایک اہم ضرورت؟

ایپی گراف:
ایک دفعہ کا ذکر ہے کہ ہیج ہاگ اور چھوٹا ریچھ جنگل میں ملے۔
- ہیلو، ہیج ہاگ!
- ہیلو، چھوٹے ریچھ!
لہٰذا، لفظ بہ لفظ، مذاق بہ مذاق، ہیج ہاگ ننھے ریچھ کے چہرے پر مارا گیا...

ذیل میں ہمارے ٹیم لیڈر کے ساتھ ساتھ RAS پروڈکٹ ڈویلپمنٹ ڈائریکٹر ایگور مارناٹ کی طرف سے کام کے تنازعات کی تفصیلات اور ان کے انتظام کے ممکنہ طریقوں کے بارے میں گفتگو ہے۔

کام پر جن تنازعات کا ہم سامنا کرتے ہیں ان میں سے زیادہ تر اس منظر نامے کے مطابق تیار ہوتے ہیں جیسا کہ اوپر ایپی گراف میں بیان کیا گیا ہے۔ بہت سے شرکاء ایسے ہوتے ہیں جو شروع میں ایک دوسرے کے لیے کافی اچھا سلوک کرتے ہیں، وہ کسی نہ کسی مسئلے کو حل کرنے کی کوشش کرتے ہیں، لیکن آخر میں مسئلہ حل نہیں ہوتا ہے، اور کسی نہ کسی وجہ سے شرکاء کے درمیان تعلقات خراب ہو جاتے ہیں۔

زندگی متنوع ہے، اور اوپر بیان کردہ منظر نامے میں تغیرات پائے جاتے ہیں۔ بعض اوقات شرکا کے درمیان تعلقات شروع میں بہت اچھے نہیں ہوتے، بعض اوقات ایسا مسئلہ بھی نہیں ہوتا جس کے لیے براہ راست حل کی ضرورت ہو (جیسا کہ مثال کے طور پر ایپی گراف میں)، بعض اوقات بحث کے بعد بھی تعلق وہی رہتا ہے جیسا کہ شروع ہوا تھا، لیکن مسئلہ بالآخر حل نہیں ہوا ہے.

ان تمام حالات میں کیا چیز مشترک ہے جسے کام کے تنازعہ کی صورت حال کے طور پر بیان کیا جا سکتا ہے؟



سب سے پہلے، دو یا زیادہ اطراف ہیں. یہ جماعتیں تنظیم میں مختلف جگہوں پر قابض ہو سکتی ہیں، برابری کے رشتے میں ہو سکتی ہیں (ایک ٹیم میں ساتھی)، یا درجہ بندی کی مختلف سطحوں پر (باس - ماتحت)، انفرادی (ملازم) یا گروہ (کسی کے درمیان تنازعہ کی صورتوں میں) ملازم اور ایک ٹیم یا دو ٹیمیں) وغیرہ۔ تنازعہ کا امکان اور اس کے حل کی آسانی شرکاء کے درمیان اعتماد کی سطح سے بہت متاثر ہوتی ہے۔ فریقین ایک دوسرے کو جتنی بہتر طریقے سے جانتے ہیں، اعتماد کی سطح اتنی ہی زیادہ ہوگی، اتنا ہی زیادہ امکان ہوگا کہ وہ ایک دوسرے کو سمجھیں گے۔ مثال کے طور پر، تقسیم شدہ ٹیم کے ممبران جنہوں نے کبھی آمنے سامنے بات چیت نہیں کی ہے، ان لوگوں کے مقابلے میں جن لوگوں نے کم از کم چند آمنے سامنے بات چیت کی ہے، کام کے ایک سادہ مسئلے پر تنازعہ کا سامنا کرنے کا زیادہ امکان ہے۔ اس لیے، تقسیم شدہ ٹیموں میں کام کرتے وقت، یہ یقینی بنانا بہت ضروری ہے کہ ٹیم کے تمام اراکین وقتاً فوقتاً ایک دوسرے کے ساتھ ملیں۔

دوم، کام کی جگہ پر تنازعہ کی صورت حال میں، فریقین کسی ایسے مسئلے کو حل کرنے کی حالت میں ہیں جو فریقین میں سے کسی ایک کے لیے، دونوں کے لیے، یا مجموعی طور پر تنظیم کے لیے اہم ہے۔ ایک ہی وقت میں، صورت حال کی تفصیلات کی وجہ سے، فریقین کے پاس عام طور پر کافی وقت ہوتا ہے اور اسے حل کرنے کے مختلف طریقے ہوتے ہیں (رسمی، غیر رسمی، ملاقاتیں، خطوط، انتظامی فیصلے، ٹیم کے اہداف اور منصوبوں کی موجودگی، درجہ بندی کی حقیقت، وغیرہ)۔ یہ کسی تنظیم میں کام (یا غیر کام) کے مسئلے کو حل کرنے کی صورت حال سے مختلف ہے، مثال کے طور پر، ایک اہم سوال کو حل کرنے سے: "اوہ، بچے، تم کس علاقے سے ہو؟!" سڑک پر، یا epigraph سے تنازعہ. کام کے مسئلے کو حل کرنے کی صورت میں، کام کے عمل کا معیار اور ٹیم میں مسائل کو حل کرنے کا کلچر اہم ہے۔

تیسرا، تنازعہ کا تعین کرنے والا عنصر (ہماری بحث کے نقطہ نظر سے) یہ حقیقت ہے کہ اس عمل کے فریق آزادانہ طور پر اس مسئلے کے حل تک نہیں پہنچ سکتے جو تمام فریقوں کے لیے موزوں ہو۔ صورت حال ایک تیسرے فریق، ایک بیرونی ثالث کی مداخلت کی متقاضی ہے۔ یہ نکتہ متنازعہ معلوم ہو سکتا ہے، لیکن خلاصہ یہ ہے کہ اگر کسی بیرونی ثالث کی مداخلت کے بغیر تنازعہ کی صورت حال کامیابی کے ساتھ حل ہو جائے، مسئلہ کامیابی سے حل ہو جائے اور فریقین کے تعلقات خراب نہ ہوں، تو یہی وہ صورت حال ہے جس کے لیے ہمیں کوشش کرنی چاہیے۔ . ہمیں غالباً اس طرح کے تنازعہ کے بارے میں معلوم بھی نہیں ہوگا، یا اس کے حل ہونے کے بعد ہمیں اتفاق سے پتہ چل جائے گا۔ جتنے زیادہ مسائل ایک ٹیم خود حل کر سکتی ہے، اتنا ہی زیادہ موثر ہوگا۔

تنازعہ کی ایک اور خصوصیت جس کو چھونے کے قابل ہے فیصلے کے دوران جذباتی شدت کی ڈگری ہے۔ ضروری نہیں کہ تنازعہ اعلیٰ جذباتی سطح سے وابستہ ہو۔ صورت حال کو، جوہر میں، ایک تنازعہ بننے کے لیے شرکاء کو چیخنے چلانے اور اپنے بازو لہرانے کی ضرورت نہیں ہے۔ مسئلہ حل نہیں ہوا ہے، ایک خاص جذباتی تناؤ موجود ہے (شاید ظاہری طور پر اس کا اظہار واضح طور پر نہیں کیا گیا ہے)، جس کا مطلب ہے کہ ہمیں تنازعہ کی صورت حال کا سامنا ہے۔

کیا تنازعات کے حالات میں مداخلت کرنا بالکل ضروری ہے، یا یہ بہتر ہے کہ ان کے حل کو اپنا راستہ اختیار کرنے دیا جائے اور مسئلہ خود حل ہونے کا انتظار کیا جائے؟ کرنے کی ضرورت ہے. تنازعہ کو مکمل طور پر حل کرنا ہمیشہ آپ کے اختیار یا اہلیت میں نہیں ہوتا ہے، لیکن کسی بھی صورت حال میں، کسی بھی پیمانے کے تنازعہ میں، آپ بالغ پوزیشن اختیار کر سکتے ہیں، اس طرح آپ کے اردگرد کئی اور لوگوں کو لا کر اس کے منفی نتائج کو کم کیا جا سکتا ہے۔ تنازعہ اور اس کے حل میں تعاون کریں۔

تنازعات کے حالات کی چند مثالوں کو دیکھنے سے پہلے، آئیے چند اہم نکات کو دیکھتے ہیں جو تمام تنازعات میں مشترک ہیں۔

تنازعہ کو حل کرتے وقت، لڑائی کے اوپر ہونا ضروری ہے، نہ کہ اس کے اندر (اسے "میٹا پوزیشن لینا" بھی کہا جاتا ہے)، یعنی حل کے عمل میں فریقین میں سے کسی ایک کا حصہ نہ بننا۔ بصورت دیگر، ایک بیرونی ثالث کا فیصلہ میں مدد کرنے سے فریقین میں سے ایک کی پوزیشن دوسرے فریق کو نقصان پہنچانے کے لیے ہی مضبوط ہوگی۔ فیصلہ کرتے وقت، یہ ضروری ہے کہ تمام فریقین اسے اخلاقی طور پر قبول کریں، جیسا کہ وہ کہتے ہیں، "خرید لیا گیا"۔ تاکہ فریقین اگر اس فیصلے سے خوش نہ ہوں تو بھی کم از کم اس پر عمل درآمد کرنے پر رضامند ہو جائیں۔ جیسا کہ وہ کہتے ہیں، اختلاف کرنے اور ارتکاب کرنے کے قابل ہونا۔ بصورت دیگر، تصادم محض اپنی شکل بدل دے گا، سلگتی ہوئی آگ پیٹ کے دلدل کے نیچے رہے گی اور کسی وقت لامحالہ دوبارہ بھڑک اٹھے گی۔

دوسرا نکتہ، جس کا جزوی طور پر پہلے سے تعلق ہے، یہ ہے کہ اگر آپ تنازعہ کو حل کرنے میں حصہ لینے کا فیصلہ کر چکے ہیں، تو اسے مواصلات کے نقطہ نظر سے اور سیاق و سباق کا مطالعہ کرنے کے لحاظ سے ممکنہ حد تک سنجیدگی سے لیں۔ ہر فریق کے ساتھ ذاتی طور پر بات کریں۔ ہر ایک کے ساتھ الگ الگ، شروعات کرنے والوں کے لیے۔ میل کے لیے تصفیہ نہ کریں۔ تقسیم شدہ ٹیم کے معاملے میں، کم از کم ویڈیو لنک کے ذریعے بات کریں۔ سنی سنائی باتوں اور عینی شاہدین کی رپورٹوں سے مطمئن نہ ہوں۔ کہانی کو سمجھیں، ہر فریق کیا چاہتا ہے، وہ کیوں چاہتا ہے، وہ کیا توقع کرتے ہیں، کیا انہوں نے اس مسئلے کو پہلے حل کرنے کی کوشش کی، حل نہ ہونے کی صورت میں کیا ہوگا، وہ کیا حل دیکھتے ہیں، وہ کس طرح کی پوزیشن کا تصور کرتے ہیں۔ دوسری طرف، وہ کیا سوچتے ہیں، صحیح یا غلط، وغیرہ۔ کھلے ذہن کے ساتھ تمام ممکنہ سیاق و سباق کو اپنے سر میں لوڈ کریں، یہ فرض کرتے ہوئے کہ ہر کوئی صحیح ہے۔ آپ تنازعہ کے اندر نہیں ہیں، آپ اس سے باہر ہیں، ایک میٹاپوزیشن میں ہیں۔ اگر سیاق و سباق صرف پوسٹ تھریڈ میں دستیاب ہے تو کم از کم اسے مکمل طور پر اور اس سے متعلق تھریڈز اور دستاویزات کو پڑھیں۔ اسے پڑھنے کے بعد بھی اپنی آواز سے بولیں۔ آپ کو کوئی ایسی اہم بات سننے کی تقریباً ضمانت دی گئی ہے جو میل میں نہیں ہے۔

تیسرا اہم نکتہ مواصلات کے لیے عمومی نقطہ نظر ہے۔ یہ عام چیزیں ہیں، کچھ بھی کائناتی نہیں، لیکن یہ بہت اہم ہیں۔ ہم وقت بچانے کی کوشش نہیں کرتے، ہم تمام شرکاء سے بات کرتے ہیں، ہم اس شخص پر تنقید نہیں کرتے، لیکن ہم اس کے اعمال کے نتائج پر غور کرتے ہیں ("آپ بدتمیز ہیں" نہیں، بلکہ "شاید لوگ ناراض ہو سکتے ہیں) یہ چیز")، ہم چہرہ بچانے کا موقع دیتے ہیں، ہم ذاتی طور پر بات چیت کرتے ہیں، لائن کے سامنے نہیں۔

تنازعات عام طور پر دو وجوہات میں سے ایک کی وجہ سے ہوتے ہیں۔ پہلا اس بات سے متعلق ہے کہ آیا تنازعہ کے وقت کوئی شخص بالغ کی حیثیت میں ہے یا بچے کی پوزیشن میں (اس پر مزید ذیل میں)۔ یہ اس کی جذباتی پختگی کی وجہ سے ہے، اس کے جذبات کو سنبھالنے کی صلاحیت (جس کا تعلق ہمیشہ اس کی عمر سے نہیں ہوتا)۔ دوسری عام وجہ کام کے عمل کی خرابی ہے، جس سے سرمئی علاقوں کے حالات پیدا ہوتے ہیں جن میں شرکاء کے درمیان ذمہ داری پھیل جاتی ہے، فریقین کی توقعات ایک دوسرے سے شفاف نہیں ہوتیں، اور اس عمل میں کردار دھندلا جاتا ہے۔

اس کے مطابق، تنازعہ کو حل کرنے میں (نیز کسی دوسرے مسئلے کے ساتھ ساتھ)، مینیجر کو تین نقطہ نظر کو ذہن میں رکھنا چاہیے: قلیل مدتی - یہاں اور اب مسئلہ/تنازع کو حل کرنے کے لیے، درمیانی مدت کے لیے - ایک اور تنازعہ پیدا ہونے کے امکانات کو کم کرنے کے لیے۔ اسی وجہ سے، اور طویل مدتی - ٹیم کے فرد میں بالغ ثقافت کو فروغ دینا۔

ہم میں سے ہر ایک کا ایک اندرونی بچہ ہوتا ہے، جس کی عمر تقریباً تین یا چار سال ہوتی ہے۔ وہ زیادہ تر وقت کام پر سوتا ہے، لیکن کبھی کبھی جاگتا ہے اور قابو پا لیتا ہے۔ بچے کی اپنی ترجیحات ہوتی ہیں۔ اس کے لیے یہ اصرار کرنا ضروری ہے کہ یہ اس کا سینڈ باکس ہے، اس کی ماں اس سے زیادہ پیار کرتی ہے، اس کی مشین بہترین ہے (ڈیزائن بہترین ہے، وہ بہترین پروگرام کرتا ہے،...)۔ تنازعہ کی صورت حال میں، ایک بچہ کھلونے دبا سکتا ہے، اپنے پیروں کو روک سکتا ہے اور اس کے اسپاٹولا کو توڑ سکتا ہے، لیکن وہ بالغوں کے مسائل (حل فن تعمیر، خودکار جانچ کے نقطہ نظر، رہائی کی تاریخ وغیرہ) کو حل نہیں کر سکتا، وہ فوائد کے لحاظ سے نہیں سوچتا۔ ٹیم کے لئے. تنازعات میں مبتلا بچے کو اپنے بالغ کو فون کرنے کے لیے کہہ کر اس کی حوصلہ افزائی، تسلی اور بستر پر بھیجا جا سکتا ہے۔ تنازعہ کی صورت حال میں بحث شروع کرنے سے پہلے، اس بات کو یقینی بنائیں کہ آپ کسی بالغ سے بات کر رہے ہیں، بچے سے نہیں، اور یہ کہ آپ خود ایک بالغ کی حیثیت میں ہیں۔ اگر اس وقت آپ کا ایماندارانہ مقصد کسی سنگین مسئلے کو حل کرنا ہے، تو آپ بالغ ہونے کی پوزیشن میں ہیں۔ اگر آپ کا مقصد اپنے پیروں کو روکنا اور اپنے کندھے کے بلیڈ کو توڑنا ہے، تو یہ بچکانہ پوزیشن ہے۔ اپنے اندرونی بچے کو بستر پر بھیجیں اور کسی بالغ کو کال کریں، یا بحث کو دوبارہ ترتیب دیں۔ ایک شخص جذباتی فیصلہ کرتا ہے، اور پھر اس کے لیے عقلی جواز تلاش کرتا ہے۔ بچوں کی ترجیحات کی بنیاد پر بچے کی طرف سے کیا گیا فیصلہ بہترین نہیں ہوگا۔

تنازعہ کے وقت رویے کے علاوہ، ایک بچے یا بالغ کی حیثیت بھی ذمہ داری کی سطح کی طرف سے خصوصیات ہے کہ ایک شخص خود کو لینے کے لئے تیار ہے. اس کے انتہائی مظاہر میں، ایک پروگرامر کی بچکانہ پوزیشن، جس سے میں ایک سے زیادہ بار ملا ہوں، اس طرح لگتا ہے: میں نے کوڈ لکھا، اسے جائزہ کے لیے بھیجا - میرا کام ختم ہو گیا ہے۔ جائزہ لینے والوں کو اس کا جائزہ لینا چاہیے اور اسے منظور کرنا چاہیے، QA کو اسے چیک کرنا چاہیے، اگر کوئی مسئلہ ہے تو وہ مجھے بتائیں گے۔ عجیب بات ہے، یہاں تک کہ کافی بالغ اور تجربہ کار لوگ بھی بعض اوقات اس طرح کا برتاؤ کرتے ہیں۔ اسکیل کا دوسرا سرا یہ ہے کہ ایک شخص اپنے آپ کو اس بات کا ذمہ دار سمجھتا ہے کہ اس کا کوڈ کام کرتا ہے، ٹیسٹوں کے ذریعے اس کا احاطہ کیا گیا ہے، اس کی طرف سے ذاتی طور پر جانچ پڑتال کی گئی ہے، جائزے کو کامیابی کے ساتھ پاس کیا گیا ہے (اگر ضروری ہو تو، جائزہ لینے والوں کو پنگ کرنے، مسائل پر بحث کرنے میں کوئی مسئلہ نہیں ہے۔ بذریعہ آواز وغیرہ عام صورتوں میں، پروگرامر یا تو پیمانے کے بالغ سرے کے قریب سے شروع ہوتا ہے، یا تجربہ حاصل کرتے ہی وہاں منتقل ہوتا ہے (بشرطیکہ ٹیم کے اندر صحیح ثقافت کاشت کی جائے)۔ انتہائی صورتوں میں، وہ کام جاری رکھتا ہے، عام طور پر بچکانہ حیثیت اختیار کرتا ہے، پھر اسے اور ٹیم کو وقتاً فوقتاً مسائل اور تنازعات کا سامنا کرنا پڑتا ہے۔

کسی ٹیم میں صحیح، بالغ ثقافت کو فروغ دینا کسی بھی مینیجر کے لیے ایک اہم کام ہے۔ یہ ایک طویل وقت اور روزانہ کوشش لیتا ہے، لیکن نتیجہ اس کے قابل ہے. ٹیم کلچر کو متاثر کرنے کے دو طریقے ہیں - مثال کے طور پر رہنمائی کرنا (جس پر یقینی طور پر عمل کیا جائے گا؛ ٹیم ہمیشہ لیڈر کی طرف دیکھتی ہے) اور صحیح رویے پر بحث اور انعام دینا۔ یہاں کچھ بھی غیر معمولی یا انتہائی رسمی نہیں ہے، صرف مسائل پر بحث کرتے وقت، نوٹس کریں کہ یہاں کچھ کیا جا سکتا تھا، اس بات پر زور دیں کہ آپ نے محسوس کیا کہ اس کا صحیح فیصلہ کب ہوا، تعریف، ریلیز کے جائزے کے دوران نوٹ، وغیرہ۔

آئیے کئی عام تنازعات پر غور کریں، سادہ سے پیچیدہ تک:

تنازعات کام کے مسائل سے متعلق نہیں ہیں۔

اکثر کام پر تنازعات ہوتے ہیں جو کام کے مسائل سے متعلق نہیں ہوتے ہیں۔ ان کی موجودگی اور حل میں آسانی کا تعلق عام طور پر شرکاء کی جذباتی ذہانت کی سطح، ان کی پختگی کی سطح سے ہوتا ہے اور اس کا تعلق کام کے عمل کی کمال یا خرابی سے نہیں ہوتا ہے۔

عام مثالیں: کوئی اکثر واشنگ مشین یا شاور کا استعمال نہیں کرتا ہے، جو دوسروں کو پسند نہیں ہے، کوئی بھرا ہوا ہے، جب کہ دوسروں کو کھڑکی کھولنے پر ہوا چلتی ہے، کسی کو بہت شور ہوتا ہے، اور دوسروں کو کام کرنے کے لیے خاموشی کی ضرورت ہوتی ہے، اور اسی طرح. بہتر ہے کہ اس قسم کے تنازعات کے حل میں تاخیر نہ کی جائے اور انہیں اپنا راستہ اختیار نہ کرنے دیا جائے۔ وہ خود حل نہیں کریں گے اور ہر روز آپ کو کام سے ہٹا دیں گے اور ٹیم میں ماحول کو زہریلا کریں گے۔ خوش قسمتی سے، ان کو حل کرنا عام طور پر کوئی بڑا مسئلہ نہیں ہوتا ہے - صرف اپنے ساتھی کے ساتھ سکون سے بات کریں (یقیناً ایک دوسرے سے) جو حفظان صحت کو نظر انداز کرتا ہے، ان لوگوں کے لیے آرام دہ بیٹھنے کی سہولت فراہم کریں جو خاموشی/ٹھنڈک کو ترجیح دیتے ہیں، آواز کو جذب کرنے والے ہیڈ فون خریدتے ہیں یا پارٹیشنز انسٹال کرتے ہیں۔ وغیرہ

ایک اور مثال جس کا مجھے اپنے کام کے دوران کئی بار سامنا ہوا وہ ہے ٹیم کے ارکان کی نفسیاتی عدم مطابقت۔ کسی وجہ سے، لوگ صرف ایک ساتھ کام نہیں کر سکتے؛ ہر تعامل ایک اسکینڈل میں ختم ہوتا ہے۔ بعض اوقات یہ اس حقیقت کی وجہ سے ہوتا ہے کہ لوگ کسی اہم مسئلے (عام طور پر سیاسی) پر قطبی خیالات رکھتے ہیں اور یہ نہیں جانتے کہ انہیں کام سے باہر کیسے چھوڑنا ہے۔ انہیں ایک دوسرے کو برداشت کرنے یا اپنے رویے کو تبدیل کرنے پر راضی کرنا ایک بے کار کام ہے۔ میں نے صرف ایک استثناء کا سامنا کیا ہے وہ نوجوان ساتھی ہیں جن کا کھلا خیال ہے؛ ان کے رویے کو اب بھی وقتاً فوقتاً گفتگو کے ذریعے تبدیل کیا جا سکتا ہے۔ عام طور پر مسئلہ کو کامیابی کے ساتھ مختلف ٹیموں میں الگ کرکے حل کیا جاتا ہے، یا کم از کم کام پر اوورلیپ ہونے کا موقع فراہم کرکے بہت کم ہی ہوتا ہے۔

مندرجہ بالا تمام حالات میں، تمام شرکاء سے ذاتی طور پر بات کرنا، صورتحال پر تبادلہ خیال کرنا، یہ پوچھنا کہ کیا انہیں اس معاملے میں کوئی مسئلہ نظر آتا ہے، یہ پوچھنا کہ ان کی رائے میں، حل کیا ہیں، اور اس کو بنانے میں ان کی شرکت کو یقینی بنانا۔ فیصلہ

کام کے عمل کو بہتر بنانے کے نقطہ نظر سے (جس کا میں نے ذکر کیا ہے، درمیانی مدت کا نقطہ نظر)، یہاں زیادہ کچھ نہیں کیا جا سکتا؛ اصلاح کا واحد نکتہ یہ ہے کہ ٹیم بناتے وقت مطابقت کے عنصر کو مدنظر رکھا جائے اور لوگوں کو شامل نہ کیا جائے۔ ایک دوسرے کے ساتھ پیشگی جو تنازعہ کرے گا.

ٹیم کلچر کے نقطہ نظر سے، اس طرح کے حالات بالغ کلچر والی ٹیموں میں بہت کم ہوتے ہیں، جہاں لوگ ٹیم اور ساتھیوں کا احترام کرتے ہیں اور یہ جانتے ہیں کہ مسائل کو آزادانہ طور پر کیسے حل کرنا ہے۔ اس کے علاوہ، اس طرح کے تنازعات ان ٹیموں میں زیادہ آسانی سے (اکثر خود بخود) حل ہو جاتے ہیں جہاں اعلیٰ سطح کا اعتماد ہوتا ہے، لوگوں نے طویل عرصے تک ایک ساتھ کام کیا ہے اور/یا کام سے باہر اکثر بات چیت کرتے ہیں۔

کام کے مسائل سے متعلق تنازعات:

اس طرح کے تنازعات عام طور پر ایک ہی وقت میں دونوں وجوہات کی وجہ سے ہوتے ہیں، دونوں جذباتی (حقیقت یہ ہے کہ شرکاء میں سے ایک بالغ کی حیثیت میں نہیں ہے) اور خود کام کے عمل کی خرابی ہے۔ شاید سب سے عام قسم کے تنازعات جن کا میں نے سامنا کیا ہے وہ کوڈ کے جائزے یا ڈویلپرز کے درمیان فن تعمیر کے مباحثوں کے دوران تنازعات ہیں۔

میں یہاں دو عام صورتوں پر روشنی ڈالوں گا:

1) پہلی صورت میں، ڈویلپر کسی ساتھی سے کوڈ کا جائزہ نہیں لے سکتا۔ پیچ کو جائزہ کے لیے بھیجا جاتا ہے، اور کچھ نہیں ہوتا۔ پہلی نظر میں، دونوں فریقوں کے درمیان کوئی واضح تنازعہ نہیں ہے، لیکن اگر آپ اس کے بارے میں سوچتے ہیں، تو یہ کافی تنازعہ ہے. کام کا مسئلہ حل نہیں ہوا ہے، فریقین میں سے ایک (جائزہ کا انتظار کر رہا ہے) واضح تکلیف کا تجربہ کرتا ہے۔ اس معاملے کی ایک انتہائی ذیلی قسم کمیونٹی میں یا مختلف ٹیموں میں ترقی ہے، جب کہ جائزہ لینے والے کو اس مخصوص کوڈ میں دلچسپی نہیں ہو سکتی، لوڈنگ یا دیگر حالات کی وجہ سے، ہو سکتا ہے کہ نظرثانی کی درخواست پر بالکل بھی توجہ نہ دے، اور بیرونی ثالث (ایک مینیجر جو دونوں طرف مشترک ہے) ) بالکل موجود نہیں ہو سکتا۔

حل کا نقطہ نظر جو ایسی صورت حال میں مدد کرتا ہے، طویل مدتی نقطہ نظر، ایک بالغ کی ثقافت سے خاص طور پر تعلق رکھتا ہے. سب سے پہلے، سمارٹ سرگرمی کام کرتی ہے۔ آپ کو یہ توقع نہیں رکھنی چاہیے کہ ریویو پر لٹکا ہوا کوڈ خود جائزہ لینے والے کی توجہ مبذول کر لے گا۔ ہمیں جائزہ لینے والوں کی اسے نوٹس میں مدد کرنے کی ضرورت ہے۔ پنگانی کچھ لوگ، سنکیپ پر ایک سوال پوچھیں، بحث میں حصہ لیں۔ ظاہر ہے، مدد سے زیادہ نقصان پہنچانے کا امکان ہے، آپ کو عقل استعمال کرنے کی ضرورت ہے۔ دوم، پہلے سے تیاری اچھی طرح سے کام کرتی ہے۔ اگر ٹیم سمجھتی ہے کہ کیا ہو رہا ہے اور کیوں، اس کوڈ کی بالکل ضرورت کیوں ہے، ڈیزائن پر سب کے ساتھ پہلے سے بات چیت اور اس پر اتفاق کیا گیا ہے، لوگ اس طرح کے کوڈ پر توجہ دینے اور اسے کام کے لیے قبول کرنے کا زیادہ امکان رکھتے ہیں۔ سوم، اتھارٹی کام کرتی ہے۔ اگر آپ جائزہ لینا چاہتے ہیں تو خود بہت سارے جائزے کریں۔ حقیقی جانچوں، حقیقی ٹیسٹوں اور مفید تبصروں کے ساتھ اعلیٰ معیار کے جائزے کریں۔ اگر ٹیم میں آپ کا عرفی نام اچھی طرح سے جانا جاتا ہے، تو اس بات کا زیادہ امکان ہے کہ آپ کے کوڈ کو دیکھا جائے گا۔

ورک فلو کے نقطہ نظر سے، یہاں ممکنہ بہتری درست ترجیح ہے جس کا مقصد ڈویلپر کو اپنے اور ٹیم کے اہداف حاصل کرنے میں مدد کرنا ہے (دوسروں کا جائزہ لینا، کمیونٹی کو خط لکھنا، کوڈ کے ساتھ فن تعمیر کی تفصیل، دستاویزات، ٹیسٹ، بات چیت میں حصہ لینا کمیونٹی، وغیرہ)، پیچ کو قطار میں زیادہ دیر تک لٹکنے سے روکتا ہے، وغیرہ۔

2) کوڈ یا ڈیزائن کے جائزوں کے دوران تنازعات کا دوسرا عام معاملہ تکنیکی مسائل، کوڈنگ کے انداز، اور ٹولز کے انتخاب پر مختلف خیالات ہیں۔ اس معاملے میں بہت اہمیت شرکاء کے درمیان اعتماد کی سطح، ایک ہی ٹیم سے تعلق، اور ایک ساتھ کام کرنے کا تجربہ ہے۔ ایک مردہ انجام اس وقت ہوتا ہے جب شرکاء میں سے کوئی بچکانہ موقف اختیار کرتا ہے اور یہ سننے کی کوشش نہیں کرتا کہ بات کرنے والا اسے کیا کہنا چاہتا ہے۔ اکثر، دوسرے فریق کی طرف سے تجویز کردہ نقطہ نظر اور ابتدائی طور پر تجویز کردہ نقطہ نظر دونوں ہی کامیابی سے کام کر سکتے ہیں اور اصولی طور پر اس سے کوئی فرق نہیں پڑتا کہ کون سا انتخاب کرنا ہے۔

ایک دن، میری ٹیم کے ایک پروگرامر نے (آئیے اسے پاشا کہتے ہیں) نے پیکج کی تعیناتی کے نظام میں تبدیلیوں کے ساتھ ایک پیچ تیار کیا، جسے پڑوسی محکمہ کے ساتھیوں نے تیار کیا اور اس کی حمایت کی۔ ان میں سے ایک (Igor) کی اپنی مضبوط رائے تھی کہ پیکجز کی تعیناتی کے دوران لینکس سروسز کو کس طرح ترتیب دیا جانا چاہیے۔ یہ رائے پیچ میں تجویز کردہ نقطہ نظر سے مختلف تھی، اور وہ متفق نہیں ہو سکے۔ ہمیشہ کی طرح، ڈیڈ لائن ختم ہو رہی تھی، اور کسی قسم کے فیصلے پر آنا ضروری تھا؛ ان میں سے کسی ایک کا بالغ پوزیشن لینا ضروری تھا۔ پاشا نے تسلیم کیا کہ دونوں طریقوں کو زندگی گزارنے کا حق ہے، لیکن وہ چاہتا تھا کہ اس کا اختیار گزر جائے، کیونکہ نہ تو ایک اور نہ ہی دوسرے آپشن کے کوئی واضح تکنیکی فوائد تھے۔

ہماری گفتگو کچھ اس طرح نظر آئی (بہت تدبیر سے، یقیناً، بات چیت آدھے گھنٹے تک جاری رہی):

- پاشا، ہمارے پاس کچھ دنوں میں ایک فیچر منجمد ہے۔ یہ ضروری ہے کہ ہم سب کچھ اکٹھا کریں اور جلد از جلد جانچ شروع کریں۔ ہم Igor کے ذریعے کیسے حاصل کر سکتے ہیں؟
- وہ خدمات کو مختلف طریقے سے ترتیب دینا چاہتا ہے، اس نے میرے لیے وہاں تبصرے پھنسائے...
- اور وہاں کیا ہے، بڑی تبدیلیاں، بہت ہنگامہ؟
- نہیں، ایک دو گھنٹے کام ہے، لیکن آخر میں کوئی فرق نہیں ہے، یہ دونوں طرح سے کام کرے گا، یہ کیوں ضروری ہے؟ میں نے کچھ ایسا بنایا جو کام کرتا ہے، آئیے اسے قبول کرتے ہیں۔
’’سنو، تم کب سے یہ سب بحث کر رہے ہو؟
- ہاں، ہم ابھی ڈیڑھ ہفتے سے وقت نکال رہے ہیں۔
- ام... کیا ہم کوئی مسئلہ دو گھنٹوں میں حل کر سکتے ہیں جس میں پہلے ہی ڈیڑھ ہفتہ لگ چکا ہو، اور ایسا نہ ہو؟
- ٹھیک ہے، ہاں، لیکن میں نہیں چاہتا کہ ایگور یہ سوچے کہ میں اس میں پھنس گیا ہوں...
- سنو، آپ کے لئے کیا زیادہ اہم ہے، رہائی جاری کرنا، اپنے اندر کے فیصلے کے ساتھ، یا ایگور کو مارنا؟ ہم اسے بلاک کر سکتے ہیں، تاہم، ریلیز کے ساتھ پرواز کرنے کا ایک اچھا موقع ہے۔
- ٹھیک ہے... یقیناً ایگور کی ناک صاف کرنا اچھا ہوگا، لیکن ٹھیک ہے، رہائی زیادہ اہم ہے، میں اتفاق کرتا ہوں۔
- کیا یہ واقعی آپ کے لیے اتنا اہم ہے کہ ایگور کیا سوچتا ہے؟ سچ پوچھیں تو، وہ کسی بھی طرح کی لعنت نہیں دیتا، وہ صرف اس چیز کے مختلف مقامات پر ایک متحد نقطہ نظر چاہتا ہے جس کے لئے وہ ذمہ دار ہے۔
- ٹھیک ہے، ٹھیک ہے، مجھے ایسا کرنے دو جیسا کہ وہ تبصروں میں پوچھتا ہے اور آئیے جانچ شروع کرتے ہیں۔
- آپ کا شکریہ، پاشا! مجھے یقین تھا کہ آپ دونوں میں سے آپ زیادہ بالغ ہوں گے، حالانکہ ایگورک آپ سے بڑے ہیں :)

مسئلہ حل ہو گیا، رہائی وقت پر ہوئی، پاشا کو زیادہ عدم اطمینان محسوس نہیں ہوا، کیونکہ۔۔۔ اس نے خود ایک حل تجویز کیا اور اسے نافذ کیا۔ ایگور عام طور پر خوش تھا، کیونکہ... اس کی رائے کو مدنظر رکھا گیا اور انہوں نے جیسا کہ اس نے تجویز کیا۔

بنیادی طور پر ایک ہی تنازعہ کی ایک اور قسم کسی پروجیکٹ میں تکنیکی حل/لائبریریوں/ نقطہ نظر کے درمیان انتخاب ہے، خاص طور پر تقسیم شدہ ٹیم میں۔ ایک پروجیکٹ میں، جسے C/C++ کے استعمال کے طور پر رکھا گیا تھا، یہ پتہ چلا کہ پروجیکٹ کا تکنیکی انتظام واضح طور پر STL (اسٹینڈرڈ ٹیمپلیٹ لائبریری) کے استعمال کے خلاف تھا۔ یہ ایک معیاری زبان کی لائبریری ہے جو ترقی کو آسان بناتی ہے، اور ہماری ٹیم اس کی بہت عادی ہے۔ پتہ چلا کہ یہ پروجیکٹ C++ کے مقابلے C کے بہت قریب ہے، جس نے ٹیم کو زیادہ متاثر نہیں کیا، کیونکہ انتظامیہ نے اپنی پوری کوشش کی اور بہت اچھے پلیئرز کو بھرتی کیا۔ ایک ہی وقت میں، ٹیم کا امریکی حصہ، انجینئرز اور مینیجر دونوں، ایک طویل عرصے تک کمپنی میں کام کر چکے تھے، موجودہ حالات کے عادی تھے، اور ہر چیز سے خوش تھے۔ ٹیم کے روسی حصے کو حال ہی میں، چند ہفتوں کے اندر (بشمول میں) اکٹھا کیا گیا تھا۔ ٹیم کا روسی حصہ واضح طور پر ترقی کے معمول کے نقطہ نظر کو ترک نہیں کرنا چاہتا تھا۔

دونوں براعظموں کے درمیان لامتناہی تحریری گفتگو کا آغاز ہوا، تین یا چار اسکرینوں پر خطوط آگے پیچھے، گروپ میلنگ اور ذاتی خطوط میں، پروگرامرز سے لے کر پروگرامرز اور مینیجرز تک۔ جیسا کہ عام طور پر ہوتا ہے، اس طوالت کے خطوط مصنفین اور ان کے پرجوش حامیوں کے علاوہ کوئی نہیں پڑھتا تھا۔ STL کے تکنیکی فوائد کے بارے میں مختلف سمتوں میں ملٹی اسکرین خیالات سے گزرتے ہوئے چیٹس، یہ کتنی اچھی طرح سے جانچا گیا ہے، یہ کتنا محفوظ ہے، اور عام طور پر، اس کے ساتھ زندگی کتنی شاندار ہے، اور اس کے بغیر یہ کتنی خوفناک ہے۔ .

یہ سب کافی دیر تک جاری رہا، یہاں تک کہ مجھے آخر کار یہ احساس ہوا کہ ہم مسئلے کے تکنیکی پہلوؤں پر بات کر رہے ہیں، لیکن مسئلہ درحقیقت تکنیکی نہیں تھا۔ مسئلہ STL کے فوائد یا نقصانات یا اس کے بغیر کام کرنے میں دشواری کا نہیں ہے۔ مسئلہ تنظیمی ہے۔ ہمیں صرف یہ سمجھنے کی ضرورت ہے کہ ہم جس کمپنی کے لیے کام کرتے ہیں وہ کیسے کام کرتی ہے۔ اس سے پہلے ہم میں سے کسی کو بھی ایسی کمپنی میں کام کرنے کا تجربہ نہیں تھا۔ بات یہ تھی کہ کوڈ کے تیار ہونے اور پروڈکشن میں جاری ہونے کے بعد، دوسرے ممالک سے، دوسری ٹیموں کے بالکل مختلف لوگوں کے ذریعے سپورٹ سنبھالی گئی۔ کئی دسیوں ہزار انجینئروں کی یہ بڑی انجینئرنگ ٹیم (مجموعی طور پر) صرف ایک مکمل طور پر بنیادی کم از کم تکنیکی ذرائع کی متحمل ہو سکتی ہے، تو بات کرنے کے لیے، ایک کم از کم کم از کم۔ کوئی بھی چیز جو کمپنی میں جسمانی طور پر قائم کردہ انجینئرنگ کے معیار سے آگے نکل گئی ہے مستقبل میں اس کی حمایت نہیں کی جا سکتی ہے۔ ٹیم کی سطح کا تعین اس کے کمزور ترین ارکان کی سطح سے ہوتا ہے۔ ہمارے سمجھنے کے بعد حقیقی حوصلہ افزائی ٹیم کے امریکی حصے کی کارروائیوں کے بعد، اس مسئلے کو ایجنڈے سے ہٹا دیا گیا تھا، اور ہم نے مل کر کمپنی کی طرف سے اپنائے گئے معیارات کا استعمال کرتے ہوئے کامیابی کے ساتھ پروڈکٹ کو تیار اور جاری کیا۔ اس معاملے میں خطوط اور بات چیت اچھی طرح سے کام نہیں کرتی تھی؛ اس نے ایک عام فرق تک پہنچنے کے لئے کئی دورے اور بہت زیادہ ذاتی بات چیت کی۔

ورک فلو کے نقطہ نظر سے، اس خاص معاملے میں، استعمال شدہ ٹولز کی تفصیل، ان کے لیے تقاضے، نئے شامل کرنے پر پابندیاں، اور اس طرح کی پابندیوں کے جواز میں مدد ملے گی۔ اس طرح کی دستاویزات تقریباً ان پیراگرافوں سے مطابقت رکھتی ہیں جو "سافٹ ویئر ڈویلپمنٹ کے لیے مینیجر کی ہینڈ بک" کے دوبارہ استعمال کی حکمت عملی اور ترقیاتی ماحولیات میں بیان کی گئی ہیں۔ ناسا. اس کی عمر کے باوجود، یہ اس قسم کے سافٹ ویئر کی ترقی کے تمام اہم سرگرمیوں اور منصوبہ بندی کے مراحل کو مکمل طور پر بیان کرتا ہے۔ اس طرح کی دستاویزات رکھنے سے یہ بات کرنا بہت آسان ہو جاتا ہے کہ پروڈکٹ میں کون سے اجزاء اور طریقے استعمال کیے جا سکتے ہیں، اور کیوں۔

ثقافتی نقطہ نظر سے، ظاہر ہے، زیادہ پختہ پوزیشن کے ساتھ، جس میں فریقین اپنے ساتھیوں کے اعمال کے اصل محرک کو سننے اور سمجھنے کی کوشش کرتے ہیں اور منصوبے اور ٹیم کی ترجیحات کی بنیاد پر کام کرتے ہیں، نہ کہ ذاتی انا کی بنیاد پر۔ ، تنازعات کو آسان اور تیزی سے حل کیا جائے گا۔

تکنیکی حل کے انتخاب پر ایک اور تنازعہ میں، مجھے فریقین میں سے ایک کے محرک کو سمجھنے میں کافی وقت لگا (یہ ایک بہت ہی غیر معمولی معاملہ تھا)، لیکن محرک واضح ہونے کے بعد، حل واضح تھا۔

صورت حال یہ ہے: تقریباً 20 افراد کی ٹیم میں ایک نیا ڈویلپر نمودار ہوتا ہے، آئیے اسے Stas کہتے ہیں۔ اس وقت، ایک ٹیم کے طور پر رابطے کے لیے ہمارا معیاری ٹول Skype تھا۔ جیسا کہ بعد میں پتہ چلا، Stas اوپن اسٹینڈرڈز اور اوپن سورس سافٹ ویئر کا بہت بڑا پرستار تھا، اور اس نے صرف ٹولز اور آپریٹنگ سسٹم استعمال کیے جن کے ذرائع عوامی طور پر دستیاب تھے اور جو عوامی طور پر بیان کردہ پروٹوکول استعمال کرتے تھے۔ اسکائپ ان ٹولز میں سے ایک نہیں ہے۔ ہم نے اس نقطہ نظر کے فوائد اور نقصانات پر بحث کرنے میں کافی وقت صرف کیا، مختلف آپریٹنگ سسٹمز پر اسکائپ کے اینالاگز لانچ کرنے کی کوششیں، ٹیم کو دوسرے معیارات پر سوئچ کرنے پر راضی کرنے کی Stas کی کوششیں، اسے ذاتی طور پر بذریعہ ڈاک لکھنا، اسے ذاتی طور پر کال کرنا۔ فون، اس کے لیے خاص طور پر سکائپ وغیرہ کے لیے دوسرا کمپیوٹر خریدیں۔ آخر میں، میں نے محسوس کیا کہ یہ مسئلہ، جوہر میں، تکنیکی یا تنظیمی نہیں ہے، بلکہ یہ نظریاتی ہے، یہاں تک کہ، کوئی کہہ سکتا ہے، مذہبی (Stas کے لیے)۔ یہاں تک کہ اگر ہم آخر کار Stas اور Skype کو جوڑ دیتے ہیں (جس میں کئی مہینے لگے)، مسئلہ کسی بھی بعد کے آلے پر دوبارہ پیدا ہو جائے گا۔ میرے پاس Stas کے عالمی نظریہ کو تبدیل کرنے کا کوئی حقیقی ذریعہ نہیں تھا، اور اس ماحول میں بالکل کام کرنے والی ٹیم کے عالمی نظریہ کو تبدیل کرنے کی کوشش کرنے کی کوئی وجہ نہیں تھی۔ شخص اور کمپنی اپنے عالمی نظریہ میں محض آرتھوگونل تھے۔ ایسے حالات میں ایک اچھا حل تنظیم سازی ہے۔ ہم نے Stas کو دوسری ٹیم میں منتقل کر دیا، جہاں وہ زیادہ نامیاتی تھا۔

اس تنازعہ کی وجہ، میری رائے میں، کسی خاص شخص کی ذاتی ثقافت (جس کی ایک مضبوط رائے ہے جو اسے سمجھوتہ کرنے کی اجازت نہیں دیتی ہے) اور کمپنی کی ثقافت کے درمیان تضاد ہے۔ اس معاملے میں بلاشبہ یہ منیجر کی غلطی ہے۔ ابتدا میں اسے اس قسم کے پروجیکٹ پر لینا غلط تھا۔ Stas آخر کار ایک اوپن سورس سافٹ ویئر ڈویلپمنٹ پروجیکٹ میں چلا گیا اور وہاں شاندار کارکردگی کا مظاہرہ کیا۔

ڈویلپر کے بچکانہ رویہ اور کام کے عمل کی خامیوں دونوں کی وجہ سے پیدا ہونے والے تنازعہ کی ایک اچھی مثال ایک ایسی صورت حال ہے جس میں مکمل کی تعریف نہ ہونے کی صورت میں، ڈویلپر اور QA ٹیم کی تیاری کے حوالے سے مختلف توقعات ہیں۔ خصوصیت QA کو منتقل کر دی گئی۔ ڈویلپر کا خیال تھا کہ کوڈ لکھنا اور فیچر کو باڑ کے اوپر QA پر پھینک دینا کافی ہے - وہ اسے وہاں ترتیب دیں گے۔ ایک کافی سمجھدار اور تجربہ کار پروگرامر، ویسے، لیکن یہ معیار کے لیے اس کی داخلی حد تھی۔ QA نے اس سے اتفاق نہیں کیا اور انہیں دکھانے اور بیان کرنے کا مطالبہ کیا کہ اس نے خود کیا چیک کیا تھا، اور ان کے لیے ٹیسٹنگ اسکرپٹ کا مطالبہ کیا۔ انہیں ماضی میں اس ڈویلپر کی فعالیت کے ساتھ مسائل کا سامنا تھا اور وہ دوبارہ اپنا وقت ضائع نہیں کرنا چاہتے تھے۔ ویسے، وہ ٹھیک تھے - فیچر واقعی کام نہیں کرتا تھا، اس نے کوڈ کو QA کو بھیجنے سے پہلے چیک نہیں کیا تھا۔

صورت حال کو حل کرنے کے لیے، میں نے اس سے کہا کہ وہ مجھے دکھائے کہ سب کچھ واقعی کام کر رہا ہے (اس نے کام نہیں کیا، اور اسے اسے ٹھیک کرنا تھا)، ہم نے ٹیم کے ساتھ بات کی اور ڈون کی QA تعریف کے ساتھ بات کی (وہ اس میں کامیاب نہیں ہوئے۔ لکھنا، کیونکہ ہم اس عمل کو زیادہ بیوروکریٹک نہیں بنانا چاہتے تھے، ٹھیک ہے، ہم نے جلد ہی اس ماہر (عام ریلیف کے لیے) سے علیحدگی اختیار کر لی۔

ورک فلو کے نقطہ نظر سے، اس معاملے میں ممکنہ بہتری میں مکمل کی تعریف کی موجودگی، ہر یونٹ کی خصوصیت اور انضمام کے ٹیسٹ کی حمایت کے تقاضے، اور ڈویلپر کی طرف سے کی جانے والی جانچ کی تفصیل ہے۔ ایک پروجیکٹ میں، ہم نے CI کے دوران ٹیسٹ کے ذریعے کوڈ کوریج کی سطح کی پیمائش کی اور اگر پیچ شامل کرنے کے بعد کوریج کی سطح گر گئی، تو ٹیسٹوں کو ناکام کے طور پر نشان زد کیا گیا، یعنی کوئی بھی نیا کوڈ صرف اس صورت میں شامل کیا جا سکتا ہے جب اس کے لیے نئے ٹیسٹ ہوں۔

کام کے عمل کی تنظیم سے قریبی تعلق رکھنے والے تنازعہ کی ایک اور عام مثال۔ ہمارے پاس ایک پروڈکٹ، ایک پروڈکٹ ڈویلپمنٹ ٹیم، ایک سپورٹ ٹیم، اور ایک گاہک ہے۔ گاہک کو پروڈکٹ اور رابطوں کی سپورٹ میں مسائل ہیں۔ سپورٹ مسئلہ کا تجزیہ کرتا ہے اور سمجھتا ہے کہ مسئلہ پروڈکٹ میں ہے اور مسئلہ کو پروڈکٹ ٹیم کو منتقل کرتا ہے۔ پروڈکٹ ٹیم مصروف وقت میں ہے، ریلیز قریب آرہی ہے، اس لیے ایک گاہک کی طرف سے مسئلہ کا ٹکٹ، ڈویلپر کے دوسرے ٹکٹوں میں گم ہو گیا جسے یہ تفویض کیا گیا ہے، بغیر توجہ کے کئی ہفتوں تک لٹکا رہتا ہے۔ سپورٹ کا خیال ہے کہ ڈویلپر کسٹمر کے مسئلے پر کام کر رہا ہے۔ گاہک انتظار کرتا ہے اور امید کرتا ہے کہ ان کے مسئلے پر کام ہو رہا ہے۔ حقیقت میں، ابھی تک کچھ نہیں ہو رہا ہے۔ چند ہفتوں کے بعد، گاہک آخرکار پیش رفت میں دلچسپی لینے کا فیصلہ کرتا ہے اور مدد سے پوچھتا ہے کہ حالات کیسے چل رہے ہیں۔ سپورٹ ترقی کے لیے مانگتی ہے۔ ڈویلپر لرزتا ہے، ٹکٹوں کی فہرست دیکھتا ہے اور وہاں موجود گاہک سے ٹکٹ تلاش کرتا ہے۔ ایک گاہک سے ٹکٹ پڑھ کر، وہ سمجھتا ہے کہ مسئلہ کو حل کرنے کے لیے کافی معلومات نہیں ہیں، اور اسے مزید لاگ اور ڈمپ کی ضرورت ہے۔ سپورٹ کسٹمر سے اضافی معلومات کی درخواست کرتا ہے۔ اور پھر گاہک کو احساس ہوتا ہے کہ اس سارے عرصے میں کوئی بھی اس کے مسئلے پر کام نہیں کر رہا ہے۔ اور گرج چمک آئے گی...

اس صورت حال میں، تنازعہ کا حل بذات خود بالکل واضح اور لکیری ہے (مصنوعات کو درست کریں، دستاویزات اور ٹیسٹوں کو اپ ڈیٹ کریں، کسٹمر کو مطمئن کریں، ہاٹ فکس جاری کریں، وغیرہ)۔ کام کے عمل کا تجزیہ کرنا اور یہ سمجھنا ضروری ہے کہ دونوں ٹیموں کے درمیان تعامل کو منظم کرنے کا ذمہ دار کون ہے، اور یہ صورتحال پہلی جگہ کیوں ممکن ہوئی۔ یہ واضح ہے کہ اس عمل میں کیا طے کرنے کی ضرورت ہے - کسی کو صارفین کی طرف سے یاد دہانیوں کے بغیر مجموعی تصویر کو فعال طور پر مانیٹر کرنا چاہیے۔ گاہک کے ٹکٹوں کو ڈویلپرز کے دوسرے ٹکٹوں کے درمیان الگ ہونا چاہیے۔ سپورٹ کو یہ دیکھنا چاہیے کہ آیا ترقیاتی ٹیم فی الحال اپنے ٹکٹوں پر کام کر رہی ہے، اور اگر نہیں، تو وہ کب کام شروع کر سکتی ہے، اور کب نتائج کی توقع کی جا سکتی ہے۔ سپورٹ اور ڈیولپمنٹ کو وقتاً فوقتاً رابطہ کرنا چاہیے اور ٹکٹوں کی حیثیت پر تبادلہ خیال کرنا چاہیے، ڈیبگنگ کے لیے ضروری معلومات کا مجموعہ جتنا ممکن ہو خودکار ہونا چاہیے، وغیرہ۔

جس طرح جنگ میں دشمن دو یونٹوں کے درمیان سنگم کو نشانہ بنانے کی کوشش کرتا ہے، اسی طرح کام میں سب سے نازک اور کمزور نقطہ عموماً ٹیموں کے درمیان بات چیت ہوتا ہے۔ اگر سپورٹ اور ڈیولپمنٹ مینیجر کافی پرانے ہیں، تو وہ خود اس عمل کو ٹھیک کر سکیں گے، اگر نہیں، تو یہ عمل تنازعات اور مسائل پیدا کرتا رہے گا جب تک کہ کوئی مینیجر مداخلت نہ کرے جو صورتحال کو ٹھیک کر سکے۔

ایک اور عام مثال جو میں نے مختلف کمپنیوں میں بار بار دیکھی ہے وہ ایسی صورتحال ہے جس میں ایک پروڈکٹ کو ایک ٹیم لکھتی ہے، اس کے لیے خودکار انٹیگریشن ٹیسٹ دوسری ٹیم کے ذریعے لکھے جاتے ہیں، اور انفراسٹرکچر جس پر یہ سب چلایا جاتا ہے اس کے ساتھ تیسرا ہوتا ہے۔ ٹیم ٹیسٹ چلانے کے دوران ہر وقت مسائل پیدا ہوتے ہیں، اور ان میں مسائل کی وجہ پروڈکٹ اور ٹیسٹ اور انفراسٹرکچر دونوں ہو سکتے ہیں۔ عام طور پر اس بات پر متفق ہونا مشکل ہوتا ہے کہ مسائل کا ابتدائی تجزیہ کس کو کرنا چاہیے، فائل کی خرابیاں، پروڈکٹ کے پارس لاگ، ٹیسٹ اور انفراسٹرکچر وغیرہ۔ یہاں تنازعات بہت کثرت سے ہوتے ہیں، اور، ایک ہی وقت میں، یکساں۔ زیادہ جذباتی شدت کی صورت میں، شرکاء اکثر بچگانہ پوزیشن میں آجاتے ہیں اور سیریز میں بحثیں شروع ہوتی ہیں: "میں اس کے ساتھ کیوں ٹنکر کروں،" "وہ اکثر ٹوٹ جاتے ہیں،" وغیرہ۔

ورک فلو کے نقطہ نظر سے، کسی مسئلے کو حل کرنے کے مخصوص اقدامات کا انحصار ٹیموں کی ساخت، ٹیسٹوں کی قسم اور پروڈکٹ وغیرہ پر ہوتا ہے۔ منصوبوں میں سے ایک میں، ہم نے متواتر ڈیوٹی متعارف کرائی، جس میں ٹیموں نے ایک وقت میں، ہفتہ وار ایک ٹیسٹ کی نگرانی کی۔ دوسرے میں، ابتدائی تجزیہ ہمیشہ ٹیسٹ ڈویلپرز کے ذریعے کیا جاتا تھا، لیکن تجزیہ بہت بنیادی تھا اور پروڈکٹ کافی مستحکم تھی، اس لیے اس نے اچھا کام کیا۔ کلید اس بات کو یقینی بنانا ہے کہ عمل شفاف ہو، تمام فریقوں کے لیے توقعات واضح ہوں، اور یہ کہ صورتحال سب کے لیے منصفانہ محسوس ہو۔

کیا کسی تنظیم میں تنازعہ بھی ایک مسئلہ ہے؟ عام طور پر، نہیں، کیونکہ اگر ترقی ہو، ترقی ہو، کسی قسم کی حرکیات ہو، تو ایسے مسائل پیدا ہوتے ہیں جو پہلے کبھی حل نہیں ہوئے، اور ان کو حل کرتے وقت تنازعات پیدا ہو سکتے ہیں۔ یہ اس بات کا اشارہ ہے کہ کچھ شعبوں پر توجہ کی ضرورت ہے، کہ بہتری کے لیے علاقے موجود ہیں۔ یہ بری بات ہے اگر تنازعات کثرت سے پیدا ہوں، حل کرنے میں مشکل ہو یا زیادہ وقت لگے۔ یہ غالباً ناکافی طور پر منظم کام کے عمل اور ٹیم کی ناکافی پختگی کی علامت ہے۔

ماخذ: www.habr.com