ایپی گراف:
شوہر غمگین بچوں کو دیکھ کر بیوی سے کہتا ہے: اچھا، ہم ان کو دھوئیں یا نئے کو جنم دیں؟
کٹ کے نیچے ہماری ٹیم کی قیادت کے ساتھ ساتھ RAS پروڈکٹ ڈویلپمنٹ ڈائریکٹر، Igor Marnat، کی حوصلہ افزائی کرنے والے پروگرامرز کی خصوصیات کے بارے میں گفتگو ہے۔
ٹھنڈے سافٹ ویئر پروڈکٹس بنانے میں کامیابی کا راز سب کو معلوم ہے - ٹھنڈے پروگرامرز کی ایک ٹیم لیں، ٹیم کو ٹھنڈا خیال دیں اور ٹیم کے کام میں مداخلت نہ کریں۔ ٹھنڈے ڈویلپرز نایاب اور مانگ میں ہیں۔ کچھ بھرتی کرنے والے یہاں تک کہتے ہیں کہ ان کا یہ تاثر ہے کہ مارکیٹ سے کسی کی خدمات حاصل کرنے کے بجائے ایک ٹھنڈا پروگرامر تیار کرنا آسان ہے۔ اس طرح کی خدمات حاصل کرنے میں مشکلات کے علاوہ، ہر مخصوص ڈویلپر کا تجربہ، موجودہ پروڈکٹ کے بارے میں اس کا علم اور اس کی ترقی کی تاریخ، اکثر ناقابل تلافی یا مشکل اور وقت طلب ہوتی ہے۔ لہذا، اگر آپ خوش قسمت ہیں اور پہلے سے ہی پروگرامرز کی ایک ٹھنڈی ٹیم ہے، تو ان کی حوصلہ افزائی پر کام کرنا ضروری ہے۔ نئے ڈویلپرز کی خدمات حاصل کرنا اور ان کی تربیت کرنا، ان میں سے ایک ٹیم بنانا تقریباً اتنا ہی مشکل اور وقت طلب ہے جتنا کہ بچوں کو جنم دینا اور ان کی پرورش کرنا۔
آئیے پریزنٹیشن کی وضاحت اور ساخت کے لیے مسلو کے اہرام کا استعمال کرتے ہوئے پروگرامرز (پروگرامرز کی ٹیموں) کے لیے حوصلہ افزائی کے اہم عوامل پر غور کریں۔ اگر آپ نے مسلو کے اہرام کے بارے میں نہیں سنا ہے، تو یہ امریکی ماہر نفسیات ابراہم ہیرالڈ مسلو کا غیر متنازعہ نہیں بلکہ بہت مشہور اور مثالی نظریہ ہے، جس نے انسانی ضروریات کے درجہ بندی کی بنیاد پر ذاتی محرک کا نظریہ پیش کیا تھا (نیچے تصویر دیکھیں)۔
ماسلو نے فرد کی ضروریات کو ایک درجہ بندی کے مطابق ترتیب دیا، جسمانی ضروریات سے لے کر ممکنہ نشوونما اور خود کو حقیقت بنانے کی ضرورت تک۔ مسلو کے نظریہ میں ایک اہم مفروضہ یہ ہے کہ "ایک شخص اعلیٰ سطح کی ضروریات کا تجربہ نہیں کر سکتا جب تک کہ اس کی نچلی سطح کی ضروریات پوری نہ ہوں۔" مثال کے طور پر، ایک شخص کو علم کی ضرورت یا جمالیاتی ضرورتوں سے نہیں چلایا جا سکتا اگر اس شخص نے تین دن تک سوئے یا نہ کھائے ہوں۔
تفصیلات میں جانے سے پہلے، آئیے ایک واضح حقیقت پر توجہ مرکوز کرتے ہیں - ایک ٹیم لوگوں پر مشتمل ہوتی ہے، تمام لوگ مختلف ہوتے ہیں، ہر ایک کا اپنا محرک ڈھانچہ ہوتا ہے۔ اس حقیقت کے علاوہ کہ ہر فرد مختلف مفادات سے متاثر ہوتا ہے، ہر شخص مختلف زندگی کے حالات میں بھی ہوتا ہے۔ کوئی ایک کیریئر کے آغاز میں ہے اور اس کے بارے میں سوچ رہا ہے کہ اسے کیسے بنایا جائے، کوئی شادی کرنے والا ہے، اور کوئی کسی نئے موضوع کے شعبے میں مہارت حاصل کرنا چاہتا ہے۔ جو چیز ایک کے لیے اہم ہے وہ دوسرے کے لیے بالکل غیر اہم ہے، اور کل سب کچھ پھر سے بدل جائے گا۔ اس سیاق و سباق کو صحیح طریقے سے سمجھنے کے لیے، ایک آسان طریقہ ہے - آپ کو اس کے بارے میں سوچنے اور اس کے ساتھ کام کرنے کی ضرورت ہے۔ سب سے اہم بات بات چیت ہے۔
اپنی ٹیم کے ساتھ کام کے علاوہ کسی اور چیز کے بارے میں بات کرنا یقینی بنائیں، غیر رسمی تعلقات استوار کریں۔
لہذا، اب ہم مسلو کے اہرام سے گزرتے ہیں اور اس کی سطحوں پر غور کرتے ہیں جیسا کہ پروگرامرز کی ٹیم کو منظم کرنے پر لاگو ہوتا ہے۔
I: جسمانی، حیاتیاتی ضروریات:
حوصلہ افزائی کے بارے میں بات کرتے وقت، بہت سے لوگ اکثر سب سے پہلے تنخواہ کے بارے میں سوچتے ہیں. اس صورت میں، تنخواہ سے میرا مطلب ہے معاوضے کے پیکیج کا ایک مستقل حصہ، جو کسی بھی طرح سے نتائج پر منحصر نہیں ہے۔ یہ بونس، بونس اور کمپنی پروموشنز پر لاگو نہیں ہوتا ہے۔ یہ وہ تنخواہ ہے جسے میں اپنے معاملے میں "جسمانی ضروریات" کی سطح سے منسوب کروں گا۔ بونس، کارکردگی، اختیارات اور کمپنی کے حصص کی بنیاد پر بونس - میں ان سب کو دوسری سطحوں پر درجہ بندی کروں گا۔
میری رائے میں، اس سے کوئی فرق نہیں پڑتا کہ یہ کتنا ہی عجیب لگ رہا ہے، تنخواہ اس کے بجائے ہوسکتی ہے demotivating محرک عنصر کے بجائے عنصر۔ پروگرامرز کے ساتھ کام کرنے کی خاصیت یہ ہے کہ وہ سب لوگ ہیں، سب سے پہلے، بہت ہوشیار (پیشہ کی ایک خصوصیت)، اور دوم، گہری اور/یا وسیع پیمانے پر تعلیم یافتہ۔ عام طور پر، پروگرامرز، اپنے پیشے کے علاوہ، ایک یا زیادہ مضامین کی گہری سمجھ رکھتے ہیں جن کے لیے وہ مصنوعات بناتے ہیں۔ اس کے علاوہ، اچھے پروگرامرز پروگرامنگ کی ترقی، الگورتھم، معیارات وغیرہ میں دلچسپی رکھتے ہیں اور اچھی طرح جانتے ہیں۔ یہی بات ان کے موضوع کے علاقے پر بھی لاگو ہوتی ہے۔ اس سطح پر لوگوں کے لیے، تنخواہ عام طور پر اہم محرک عنصر نہیں ہے۔
ایک ہی وقت میں، پروگرامرز کے لیے مناسب تنخواہ کا فقدان، ان کی سمجھ میں، بہت زیادہ تنزلی اور تنزلی کرتا ہے۔ مناسب تنخواہ کا ہونا معمول ہے۔ تنخواہ معمول (مارکیٹ) سے بہت زیادہ ہے - یہ بھی، عجیب طور پر کافی ہے، بلکہ مایوس کن عنصر۔ ایک ساتھی نے ایک بار مجھے ایک بڑی امریکی اینی میشن کمپنی میں پروگرامرز کی ٹیم کے بارے میں بتایا، جس نے متعدد حالات کی وجہ سے مارکیٹ سے دو سے تین گنا زیادہ تنخواہ وصول کی۔ جیسا کہ اس نے کہا، اس نے اپنی زندگی میں اس سے زیادہ بور، سست اور مایوس پروگرامرز نہیں دیکھے۔ تنخواہ میں اضافے کی حقیقت مختصر مدت میں حوصلہ افزائی کر سکتی ہے، لیکن چند مہینوں کے بعد نئی تنخواہ معمول بن جاتی ہے اور حوصلہ افزائی کرنا چھوڑ دیتی ہے۔ عام طور پر، میں یہ کہوں گا کہ پروگرامرز کے لیے اپنے کیریئر کے آغاز میں تنخواہ کا عنصر زیادہ اہم ہوتا ہے، کیونکہ جیسے جیسے وہ پیشہ ورانہ طور پر بڑھتے اور ترقی کرتے ہیں، اس کی اہمیت کم ہوتی جاتی ہے اور دیگر عوامل غالب آنے لگتے ہیں۔
دوسرا اہم نکتہ ٹیم میں تنخواہوں کی سطح میں منصفانہ توازن کی موجودگی ہے۔ اگر کسی ٹیم کو لگتا ہے کہ ایک رکن کی شراکت نمایاں طور پر کم ہے، لیکن معاوضے کی سطح ایک جیسی ہے، تو اس سے پوری ٹیم کی تنزلی ہو جائے گی۔ بعض اوقات مینیجرز کو پیسوں سے آگ بھڑکانے کا لالچ دیا جاتا ہے - کسی جلے ہوئے یا مایوس شخص کو اس کی تنخواہ معمول سے زیادہ بڑھا کر برقرار رکھنے کے لیے۔ یہ عام طور پر صرف طویل مدت میں مسائل پیدا کرتا ہے - خود شخص کی حوصلہ افزائی زیادہ نہیں ہوگی، یا یہ ایک دو مہینے تک بڑھے گی، لیکن باقی ٹیم کی حوصلہ افزائی گر جائے گی. اس طرح کے حالات میں، یہ دوسرے طریقوں کو تلاش کرنے کے قابل ہے، جب تک کہ، یقینا، یہ ایک منفرد ماہر ہے جسے کسی بھی قیمت پر برقرار رکھنے کی ضرورت ہے، یہاں تک کہ مختصر وقت کے لئے.
II حفاظت، آرام، زندگی کے حالات کی مستقل مزاجی کی ضرورت:
70 سال پہلے، گاڑی کا انتخاب کرتے وقت گاڑی میں چولہے کی موجودگی ایک حوصلہ افزا عنصر ہو سکتی تھی؛ تب یہ معمول سے بالاتر تھا اور عیش و آرام کی علامت تھی۔ اب یہاں تک کہ ایئر کنڈیشنگ کی عدم موجودگی بھی بکواس ہے، اور کار کا انتخاب کرتے وقت اس کی موجودگی یقیناً ایک محرک عنصر نہیں ہوگی۔ تو 10-15 سال پہلے، ایک آسان دفتر، اچھا ہارڈ ویئر، مزیدار کافی، فٹنس، لچکدار اوقات وغیرہ۔ اچھے محرک عوامل ہو سکتے ہیں، لیکن اب یہ ایک اچھے پروگرامر کے کام کا معمول ہے۔ ایک ہی وقت میں، ان کی غیر موجودگی دوبارہ demotivating ہو جائے گا.
ایک اہم تنزلی کا عنصر توجہ مرکوز کرنے کی صلاحیت کی کمی اور کام کا شور والا ماحول ہے۔ ایک پروگرامر کا کام خاموشی اور ارتکاز کی ضرورت ہے۔ اگر دفتر کی جگہ ڈویلپرز کو ایک ویران کام کی جگہ فراہم کرنے کا موقع فراہم نہیں کرتی ہے، تو کم از کم ان ساتھیوں کے درمیان آرام دہ تعاون کو یقینی بنانا ضروری ہے جو ایک دوسرے کے ساتھ مداخلت نہیں کرتے ہیں۔ یہ بہتر ہے کہ متحرک اور بلند آواز والے ساتھیوں کو ایک دوسرے کے ساتھ متحد کریں، ان لوگوں کو توجہ مرکوز کرنے کا موقع فراہم کریں جنہیں اس کی ضرورت ہے۔
ایک پروگرامر کے وقت کی قیمت اب اس ہارڈ ویئر کی قیمت سے کافی زیادہ ہے جس پر وہ کام کرتا ہے۔ دو یا تین مانیٹر، طاقتور کمپیوٹر، ہر ڈویلپر کے لیے ایک آرام دہ کام کی جگہ - کسی بھی کمپنی میں معمول ہونا چاہیے۔ اس موضوع کو جوئل اسپولسکی کے ایک مضمون میں اچھی طرح سے احاطہ کیا گیا ہے۔جوئل ٹیسٹ: بہتر کوڈ کے لیے 12 قدم۔
آرام کا جسمانی جزو سب سے بنیادی اور سادہ ہے، اب باقی بات کرتے ہیں۔
بہت سی کمپنیوں میں، پروگرامرز کا معمول کام کا ایک لچکدار شیڈول ہے اور کوئی ڈریس کوڈ نہیں۔ یہ اچھا اور درست ہے اگر ٹیم کے کام کی تفصیلات اس کی اجازت دیتی ہیں (مثال کے طور پر، گاہکوں، سیاست دانوں یا بینکرز کے ساتھ کوئی ملاقاتیں نہیں ہوتی ہیں)۔
اہم بات یہ ہے کہ وقت کی ایک مخصوص کھڑکی ہو جہاں پوری ٹیم مقامی طور پر مل کر کام کرے تاکہ لوگ بات چیت کر سکیں اور مسائل کو آمنے سامنے حل کر سکیں۔ ایک پروگرامر، جوہر میں، کام کے بعد بھی کام نہیں چھوڑتا۔ عام طور پر، دفتر میں اس کی موجودگی سے قطع نظر اس کے دماغ میں کام کے مسائل دوبارہ چلتے ہیں، اور اچھے فیصلے اکثر دفتر کے باہر سے آتے ہیں۔ اچھے ہونے کی ضرورت کو دیکھتے ہوئے (جس پر ہم ذیل میں بات کریں گے)، معمولی کنٹرول نقصان دہ ہے۔ یہ نہ صرف تنزلی کا باعث ہے بلکہ یہ پیداواری صلاحیت کو بھی کم کرتا ہے۔ جیسا کہ پریکٹس سے پتہ چلتا ہے، کنٹرول کی غیر موجودگی میں، ایک حوصلہ افزائی ٹیم ضرورت سے زیادہ کام کرنے کا زیادہ امکان رکھتی ہے۔ اگر کنٹرول ہے تو، ڈویلپرز نو سے چھ تک کی بورڈ پر بیٹھ سکتے ہیں، لیکن نتیجہ، میرے خیال میں، بدتر ہوگا۔ جیسا کہ وہ کہتے ہیں، ایک شخص گھوڑے کو پانی تک لے جا سکتا ہے، لیکن اگر وہ نہ چاہے تو سو آدمی بھی اسے پینے پر مجبور نہیں کریں گے۔
ضروریات کے اس درجے کی تفصیل میں اضطراب اور خوف سے آزادی، انتشار کی عدم موجودگی اور ساخت و ترتیب کی ضرورت کا بھی ذکر ہے۔ یہ بھی انتہائی اہم نکات ہیں جو ٹیم کے ماحول کو بہت متاثر کرتے ہیں۔
سب سے پہلے، افراتفری، ساخت اور ترتیب کی عدم موجودگی - ٹیم کو یہ سمجھنا چاہیے کہ کون کس چیز کے لیے ذمہ دار ہے، کردار کیسے تقسیم کیے جاتے ہیں، کیا کرنے کی ضرورت ہے، کس کے لیے، کب، کون سی ضروریات پروڈکٹ کے تحت ہیں، انتظامیہ کی کیا توقعات ہیں اور گاہک... اس میں سے زیادہ تر کو باضابطہ طور پر بیان کیا جانا چاہیے، ہر چیز پر وقتاً فوقتاً بحث کی جانی چاہیے۔ بحث اور متواتر استعمال کے بغیر، وضاحتیں کام نہیں کرتی ہیں۔ رہائی کے بعد پوسٹ مارٹم کے تجزیے کے نتائج کی بنیاد پر وقتاً فوقتاً ان پر تبادلہ خیال کرنا اور انہیں اپ ڈیٹ کرنا اچھا عمل ہے۔
دوم، ایک پرسکون اور دوستانہ ماحول۔ ہم سب اپنا زیادہ تر وقت کام پر صرف کرتے ہیں، اور ہم اسے بغیر کسی تناؤ، تنازعہ یا خوف کے کرنا چاہتے ہیں۔ ترقیاتی ٹیم عام طور پر نظام الاوقات اور صارفین کے دباؤ میں کام کرتی ہے۔ کسی کو بھی ساتھیوں اور اعلیٰ افسران سے اضافی تناؤ کی ضرورت نہیں ہے۔ ٹیم میں ماحول، عام طور پر یہ حقیقت کہ ڈویلپرز کے ایک گروپ کو بلایا اور "ٹیم" بنایا جا سکتا ہے، مینیجر کی براہ راست اور اہم ذمہ داری ہے، جو سب سے اہم درمیانی اور طویل مدتی کاموں میں سے ایک ہے۔ اس لیے، مینیجر کے لیے یہ ضروری ہے کہ وہ کام کرے، خاص طور پر، ٹیم میں تنازعات کے ساتھ، اور اپنی ترقی کو اپنا راستہ اختیار نہ ہونے دیں۔ تنازعات کا انتظام ایک الگ موضوع ہے جو علیحدہ مطالعہ کا مستحق ہے۔
ٹیم کی جذباتی حالت اور ساتھیوں کے رویے کو متاثر کرنے کے دو اہم طریقے ہیں (اگر کوئی تبصرے میں شامل کرے تو یہ بہت اچھا ہوگا)۔ پہلا آپ کا اپنا طرز عمل ہے۔ مینیجر اور ٹیم کے لیے ذاتی مثال انتہائی اہم ہے۔ جیسا کہ وہ کہتے ہیں، جیسا کہ پادری ہے، اسی طرح آمد ہے. ایسا برتاؤ کریں جس طرح آپ اپنے ساتھیوں سے برتاؤ کی توقع کرتے ہیں۔ دوسرا صحیح رویے کی حوصلہ افزائی کرنا ہے اور اسی طرح غلط رویے کی حوصلہ افزائی کرنا ہے۔ لوگوں سے رابطہ کریں، انہیں رائے دیں، ایسا کرنے کے بہت سے طریقے ہیں۔ عام طور پر، رائے ایک الگ بحث کا موضوع ہے؛ یہ حوصلہ افزائی کے ساتھ کام کرنے کا ایک بڑا اور اہم حصہ ہے۔
ماحول کے بارے میں ایک اور نوٹ، جو غیر معمولی لگ سکتا ہے، لیکن عملی طور پر یہ اہم ہے. زیادہ تر اکثر، مردوں کے مقابلے ترقیاتی ٹیم میں لڑکیاں کم ہوتی ہیں۔ اکثر گروپ مکمل طور پر مرد ہوتے ہیں۔ ایسے حالات میں بوجھ تلے بھی بعض اوقات ٹیم میں فحش زبان استعمال ہونے لگتی ہے۔ پریکٹس سے پتہ چلتا ہے کہ اس کا ماحول پر منفی اثر پڑتا ہے؛ بات چیت آہستہ آہستہ بدتمیز ہو جاتی ہے۔ آپ اسے خود استعمال کرنے سے گریز کریں اور اپنی ٹیم میں اس کے استعمال کی حوصلہ شکنی کریں۔
ترقیاتی ٹیموں کو اکثر R&D (تحقیق اور ترقی) کہا جاتا ہے، جس میں تحقیق کام کا ایک اہم حصہ بنتی ہے۔ یہ وہ حصہ ہے جس کے لیے پروگرام اور منصوبہ بندی کرنا عموماً مشکل ہوتا ہے، ورنہ یہ تحقیق نہیں ہوتی۔ یہ ضروری ہے کہ ٹیم کو غلطیاں کرنے، پہل کرنے، مختلف آپشنز آزمانے کا حق حاصل ہو جو کہ کامیابی پر ختم ہو سکتے ہیں یا نہیں۔ غلطیاں کام کا ایک عام حصہ ہیں، ان سے گریز نہیں کیا جا سکتا، لیکن آپ مطالعہ کر سکتے ہیں، تجزیہ کر سکتے ہیں، مستقبل کے لیے ان سے سیکھ سکتے ہیں اور آگے بڑھ سکتے ہیں۔ 5 کیوں کا اصول، جو ٹویوٹا سے شروع ہوا، کسی مسئلے کی جڑ تک پہنچنے کا ایک اچھا طریقہ ہے۔ غلطیوں کو سزا دینا خوف اور غیر یقینی کی فضا پیدا کرنے کا ایک بہترین طریقہ ہے۔ صرف استثناء ہے جب، تجزیہ کے نتائج کی بنیاد پر، یہ پتہ چلتا ہے کہ غلطی کام کرنے کے غیر پیشہ ورانہ رویہ کی وجہ سے ہوئی ہے، اس صورت میں، اہلکاروں کے فیصلے کرنے کی ضرورت ہوسکتی ہے.
بات چیت شروع ہونے سے پہلے ٹیم کا ماحول آپ کی توقعات اور جذباتی کیفیت سے بہت متاثر ہوتا ہے۔ ایک مشکل بحث شروع کرنے سے پہلے، کسی قسم کی ڈیبریفنگ، یا محض ایک جذباتی گفتگو، آپ کا مزاج اور اس شخص کے ساتھ رویہ ضروری ہے جس کے ساتھ آپ بات کرنے جا رہے ہیں۔ میں ہمیشہ ڈیفالٹ طور پر اس بات پر یقین رکھتا ہوں اور عمل کرتا ہوں کہ اس شخص نے خلوص دل سے بہترین کام کرنے کی کوشش کی۔ اگر آپ کے موقف سے ایسا لگتا ہے کہ ایسا نہیں ہے، تو آپ کو سکون سے اور تفصیل سے سیاق و سباق کو تلاش کرنے کی ضرورت ہے اور یہ سمجھنے کی ضرورت ہے کہ اس نے کیا صحیح کیا، کیوں اس نے اسے صحیح سمجھا، اور ہماری توقعات کہاں سے ہٹ جاتی ہیں۔ یہ عام طور پر پتہ چلتا ہے کہ وہ حقیقت میں الگ نہیں ہوتے ہیں، یہ صرف یہ ہے کہ سیاق و سباق کے بارے میں اس کا نقطہ نظر زیادہ مکمل یا تازہ ہے، اور کچھ ایسا ہے جو آپ نہیں جانتے تھے۔ یا، اس کے برعکس، وہ کچھ نہیں جانتا تھا. یہ تقسیم شدہ ٹیم میں خاص طور پر اہم ہے، جب لوگ ذاتی طور پر کم ہی بات چیت کرتے ہیں اور ای میل اور فوری میسنجر استعمال کرتے ہیں۔ مختلف ممالک کے پروگرامرز پر مشتمل اور مختلف ٹائم زونز میں تقسیم ہونے والی ٹیم میں یہ اور بھی اہم ہے۔ یہیں سے ثقافتی اختلافات ایک بڑا کردار ادا کرنے لگتے ہیں۔
مشکل حالات میں چلتے پھرتے گاڑی چلانا آسان ہے، بہت آسان، لیکن پھر پیچھے گاڑی چلانا مشکل ہے، اور تلچھٹ کافی دیر تک باقی رہتی ہے۔ میں آپ کو حالیہ تجربے سے ایک سادہ سی مثال دیتا ہوں۔ ٹیم مینیجرز میں سے ایک کو کسی دوسرے ملک میں متعلقہ ٹیم کے مینیجر سے کسٹمر کے ساتھ کسی مسئلے کے بارے میں فوری طور پر تبصرے کی ضرورت ہے۔ اس نے میسنجر میں ایک ساتھی کو پنگ کیا، 15 منٹ انتظار کیا، دوبارہ پنگ کیا، پھر 15 منٹ بعد وہ ایک بڑی چیٹ میں گیا جس میں دوسرے مینیجر بھی تھے، اور ساتھی پر ہلکا سا حملہ کیا، اس طرح کے الفاظ کے ساتھ: "چونکہ آپ ایسا نہیں کرتے۔ مجھے جواب دینے کے لئے تیار ہوں، شاید، اور سوال اتنا ضروری نہیں ہے؟" آخر میں، یہ پتہ چلا کہ ہمارے کارپوریٹ میسنجر تھوڑا سا مدھم تھا، اور ساتھی نے سوال بالکل نہیں دیکھا. مجھے معافی مانگنی پڑی۔ عام طور پر، یہ بہتر ہے کہ اچھے سے شروع کریں۔ بری غلطی کرنا اور بعد میں مصیبت میں پڑنا ہمیشہ ممکن ہے؛ اس میں کوئی مسئلہ نہیں ہے (حالانکہ آپ کو ایسا نہیں کرنا چاہیے)۔ عام طور پر، ہماری صنعت میں کام کرنے کے 20 سال سے زیادہ عرصے میں، میں واقعی ایک بدنیتی پر مبنی ساتھی سے صرف ایک بار ملا ہوں (!)۔ خوش قسمتی سے، ہم بہت جلد ٹوٹ گئے. یہ سمجھنا کہ ساتھی سیاق و سباق کی اپنی بہترین تفہیم کے مطابق سب سے بہتر چاہتے ہیں۔
مینیجر کے طور پر آپ کا کام سیاق و سباق کی ہم آہنگی کو یقینی بنانا ہے، توقعات، تقاضوں، ڈیڈ لائنز اور ٹیم میں قبول کردہ معیارات کی مشترکہ سمجھ۔ یہ چھوٹی چیزوں کی طرح لگ سکتے ہیں، لیکن ٹیم میں ماحول ان چھوٹی چیزوں سے بالکل ٹھیک بنایا گیا ہے. تقسیم شدہ ٹیم کے نقطہ نظر سے، اہم کاموں میں سے ایک یہ یقینی بنانا ہے کہ ٹیم کے اراکین کے درمیان وقتاً فوقتاً آمنے سامنے بات چیت ہو۔ میں نے پروگرامرز سے ایک سے زیادہ بار سنا ہے کہ اس کے بعد، مثال کے طور پر، سپورٹ ٹیم کے انجینئرز ان کے پاس آئے اور ذاتی طور پر مل کر کام کیا، وہ خوشی خوشی پاشا کی ذاتی طور پر ایک مشکل معاملے میں مدد کرنے کے لیے کام پر رہے، جو حال ہی میں ان کے پاس آیا تھا، اگرچہ پہلے پاشا میسنجر میں صرف ایک آئیکن تھا، اور کوئی بھی آئکن کی خاطر نہیں رکتا تھا۔
ویسے، میں نے سپورٹ ٹیم کے بارے میں بات شروع کی اور اپنے لیے ایک روایتی مثال یاد آ گئی۔ ایک بار، امریکہ میں ایک گاہک کو پروڈکٹ کے ساتھ مسئلہ درپیش تھا، سپورٹ ٹیم کے انجینئرز میں سے ایک جس نے اس کے نفاذ پر کام کیا تھا (روس سے دوسرا) کام کے بعد مدد کے لیے ٹھہرے رہے، لیکن مسئلہ حل نہیں ہوا اور نہ ہی حل ہوا۔ عام طور پر، وہ دیر تک وہیں بیٹھا رہا اور صبح تک۔ اس وقت، گاہک کے مینیجرز نے مسئلہ کو بڑھایا، ان کے لیے اس کی اہمیت کی نشاندہی کی، اور شام کو کام چھوڑ دیا۔ بڑھنے کا عمل پہلے ہی ایک مختلف ٹائم زون میں زور پکڑ رہا تھا، روس میں سپورٹ مینیجرز نے مدد کرنے کی کوشش شروع کر دی، کسٹمر کے دفتر کے ساتھ بات چیت میں کچھ مشکلات کی وجہ سے (VPN، کنکشن کے مسائل، ممالک کے درمیان کالز میں مشکلات،...) مجھے معلوم نہیں تھا کہ وہ لڑکا پہلے سے ہی دفتر میں جیل میں تھا اور اس مسئلے کو حل کرتا ہے، اور اسے تلاش کرنے کی کوشش کرتا ہے۔ انہوں نے اسے صرف صبح (امریکی) میں پایا، جب مسئلہ پہلے ہی عملی طور پر حل ہو چکا تھا اور پروڈکٹ کام کر رہی تھی۔ بلے سے ہی وہ کہنے لگے کہ کیا بات ہے، گاہک اتنا بڑھ گیا ہے، کچھ کام نہیں کر رہا، تم کہاں ہو، ہم تمہیں ڈھونڈ نہیں پا رہے، وغیرہ۔ کہنے کی ضرورت نہیں، اس طرح کے رویے کے نتیجے میں آدمی کو بہت مایوس کیا گیا تھا. تقسیم شدہ ٹیم کے کام کو منظم کرنا ایک الگ بڑا موضوع ہے، لیکن دو باتیں یاد رکھنا ضروری ہے۔ سب سے پہلے، مواصلات اور ماحول بہت اہم ہے، کام کی کامیابی اس پر منحصر ہے. دوم، یہ خود سے کام نہیں کرتا؛ اسے الگ الگ اور گہرائی سے نمٹا جانا چاہیے۔
اس سطح کی ضروریات سے متعلق ایک اور اہم نکتہ دوبارہ تنخواہ ہے۔ تنخواہ کا سائز نہیں، اس طرح، لیکن اسے تبدیل کرنے کے لئے ایک مخصوص طریقہ کار کی موجودگی. کمپنی کے پاس مختلف سطحوں پر عہدوں کے لیے تقاضوں کا تعین کرنے کا طریقہ ہونا چاہیے۔ ہر ڈویلپر کو کمپنی کے ساتھ اپنے کام کی توقعات پر تبادلہ خیال کرنے کے قابل ہونا چاہئے، یہ سمجھنا چاہئے کہ ان کی کوششیں ان کی تنخواہ پر کیسے اور کب اثر انداز ہو سکتی ہیں۔ مینیجر کے ساتھ متواتر ملاقاتیں، نیم سالانہ یا سالانہ کارکردگی کے جائزے اس مقصد کو پورا کرتے ہیں۔ یہ، ایک بار پھر، ان لمحات میں سے ایک ہے جن کی موجودگی واضح طور پر حوصلہ افزائی نہیں کرتی ہے، لیکن ان کی غیر موجودگی بہت مایوس کن ہے.
آرڈر کی ضرورت اور قواعد کی موجودگی سے ان قواعد کی تعمیل کرنے کی ضرورت ہوتی ہے، ٹیم میں قبول کردہ اصولوں پر عمل کرنا، رسمی اور غیر رسمی دونوں۔ عام طور پر، میں اسے "اچھے ہونے" کی ضرورت کہوں گا۔ اس ضرورت کی موجودگی اس بات کی تصدیق کرتی ہے کہ مائیکرو مینجمنٹ ضروری نہیں ہے، بلکہ نقصان دہ ہے۔ ایک شخص کو کام کے لیے ضروری ہر چیز فراہم کرنا، اسے سیاق و سباق، ترجیحات کا علم دینا اور اس کی سطح پر عمل اور فیصلہ سازی کی آزادی فراہم کرنا کافی ہے۔ اس طرح کے حالات میں، وہ اعتماد محسوس کرے گا، اپنے فیصلے خود کرنے کا موقع ملے گا، ان کی ذمہ داری قبول کرے گا، اور اپنی صلاحیت کو ظاہر کرنے کے قابل ہو جائے گا.
ایک اور اہم نکتہ جسے ترتیب کی ضرورت اور افراتفری کی عدم موجودگی سے منسوب کیا جانا چاہئے وہ ہے کسی کام پر توجہ مرکوز کرنے کی صلاحیت، بار بار سیاق و سباق کے سوئچ کی عدم موجودگی۔ پروگرامر ہونے کے لیے وقت اور توجہ کی ضرورت ہوتی ہے۔ پروگرامرز واقعی میں ایک کام کو فوری طور پر ترک کرنا اور دوسرے کو تبدیل کرنا پسند نہیں کرتے ہیں۔ پروگرامر کے کام کا ایک ضروری حصہ عام طور پر نہ صرف کوڈ کی حقیقی نشوونما ہوتا ہے بلکہ اس میں بگ فکسنگ اور صارفین کی طرف سے درخواستوں پر کارروائی کرنے میں مدد بھی شامل ہوتی ہے۔ اس طرح کی چیزوں کی پہلے سے منصوبہ بندی کرنے کے قابل ہے، اس طرح کہ پروگرامر کو دوسرے کام پر جانے سے پہلے ایک کام پر سکون اور مکمل طور پر مکمل کرنے کی اجازت دی جائے۔ بہترین آپشن یہ ہے کہ اپنے آپ کو اپنے کام کی منصوبہ بندی کرنے کا موقع فراہم کریں، ترجیحات اور آنے والے کاموں کی پہلے سے نشاندہی کریں، ایک قسم کے کام پر کام کرنے کے لیے طویل، توسیع شدہ وقت مختص کریں۔ اس موضوع کو کتاب میں اچھی طرح بیان کیا گیا ہے۔گوگل - سائٹ قابل اعتماد انجینئرنگ"، جو ٹیموں کے کام کی منصوبہ بندی کرنے کے طریقوں کو اچھی طرح سے بیان کرتا ہے جو بڑے، انتہائی بھاری بھرکم، غلطی کو برداشت کرنے والے نظاموں کے آپریشن اور ترقی کو یقینی بناتی ہے، اور ساتھ ہی انجینئرز جن کا پیشہ سافٹ ویئر کی ترقی اور اس کی معاونت کو یکجا کرتا ہے۔
جاری رکھنا ...
ماخذ: www.habr.com