ایپی گراف:
شوہر غمگین بچوں کو دیکھ کر بیوی سے کہتا ہے: اچھا، ہم ان کو دھوئیں یا نئے کو جنم دیں؟
کٹ کے نیچے ہماری ٹیم لیڈر کے ساتھ ساتھ RAS پروڈکٹ ڈویلپمنٹ ڈائریکٹر ایگور مارناٹ کے مضمون کا دوسرا حصہ ہے، جو پروگرامرز کی حوصلہ افزائی کی خصوصیات کے بارے میں ہے۔ مضمون کا پہلا حصہ یہاں پایا جا سکتا ہے -
مضمون کے پہلے حصے میں، میں نے مسلو کے اہرام کی دو نچلی سطحوں کو چھوا: جسمانی ضروریات، حفاظت کی ضروریات، آرام اور استحکام اور اگلے، تیسرے درجے پر جائیں، یعنی:
III - تعلق اور محبت کی ضرورت
میں جانتا تھا کہ اطالوی مافیا کو "کوسا نوسٹرا" کہا جاتا ہے، لیکن جب مجھے پتہ چلا کہ "کوسا نوسٹرا" کا ترجمہ کیسے کیا جاتا ہے تو میں بہت متاثر ہوا۔ اطالوی سے ترجمہ شدہ "کوسا نوسٹرا" کا مطلب ہے "ہمارا کاروبار"۔ حوصلہ افزائی کے لیے نام کا انتخاب بہت کامیاب ہے (آئیے پیشے کو ایک طرف چھوڑ دیں، اس معاملے میں ہم صرف حوصلہ افزائی میں دلچسپی رکھتے ہیں)۔ ایک شخص عام طور پر کسی ٹیم کا حصہ بننا چاہتا ہے، کوئی بڑا، عام، ہمارا کاروبار کرنا چاہتا ہے۔
فوج، بحریہ اور کسی بھی بڑے نیم فوجی دستوں میں تعلق اور محبت کی ضرورت کو پورا کرنے کو بہت اہمیت دی جاتی ہے۔ اور، جیسا کہ ہم دیکھتے ہیں، مافیا میں۔ یہ قابل فہم ہے، کیونکہ آپ کو ان لوگوں کو مجبور کرنے کی ضرورت ہے جن میں بہت کم مشترکات ہیں، جو ابتدائی طور پر ہم خیال لوگوں کی ٹیم نہیں بناتے ہیں، جنہیں بھرتی کے ذریعے اکٹھا کیا جاتا ہے (رضاکارانہ طور پر نہیں)، جن کی تعلیم کی مختلف سطحیں، مختلف ذاتی اقدار ہیں۔ , لفظی طور پر اپنی زندگیاں وقف کرنے کے لیے، جان لیوا خطرے میں، کسی عام مقصد کے لیے، اپنی زندگی کو ایک ساتھی کے سپرد کرنا۔
یہ ایک بہت مضبوط ترغیب ہے؛ زیادہ تر لوگوں کے لیے یہ محسوس کرنا انتہائی ضروری ہے کہ وہ کسی بڑی چیز سے تعلق رکھتے ہیں، یہ جاننا کہ آپ ایک خاندان، ایک ملک، ایک ٹیم کا حصہ ہیں۔ فوج میں یونیفارم، مختلف رسومات، پریڈ، مارچ، بینرز وغیرہ ان مقاصد کو پورا کرتے ہیں۔ کسی بھی ٹیم کے لیے تقریباً وہی عوامل اہم ہوتے ہیں۔ علامتیں، کارپوریٹ برانڈ اور کارپوریٹ رنگ، سامان اور تحائف اہم ہیں۔
یہ ضروری ہے کہ اہم واقعات کی اپنی ظاہری شکل ہوتی ہے جس کے ساتھ وہ منسلک ہو سکتے ہیں۔ آج کل، ایک کمپنی کا اپنا سامان، جیکٹس، ٹی شرٹس وغیرہ رکھنا معمول ہے۔ لیکن کمپنی کے اندر ٹیم کو اجاگر کرنا بھی ضروری ہے۔ ہم اکثر ریلیز کے نتائج کی بنیاد پر ٹی شرٹس جاری کرتے ہیں، جو ریلیز میں شامل تمام لوگوں کو دی جاتی ہیں۔ کچھ تقریبات، مشترکہ تقریبات یا پوری ٹیم کے ساتھ سرگرمیاں حوصلہ افزائی کا ایک اور اہم عنصر ہیں۔
بیرونی صفات کے علاوہ، کئی دیگر عوامل ٹیم سے تعلق کے احساس کو متاثر کرتے ہیں۔
سب سے پہلے، ایک مشترکہ مقصد کی موجودگی جسے ہر کوئی سمجھتا ہے اور اس کی اہمیت کا اندازہ لگاتا ہے۔ پروگرامرز عام طور پر یہ سمجھنا چاہتے ہیں کہ وہ ایک اچھی چیز کر رہے ہیں، اور وہ ایک ٹیم کے طور پر یہ اچھی چیز مل کر کر رہے ہیں۔
دوم، ٹیم کے پاس ایک مواصلاتی جگہ ہونی چاہیے جس میں پوری ٹیم موجود ہو اور جس کا تعلق صرف اس سے ہو (مثال کے طور پر، میسنجر میں چیٹ، متواتر ٹیم کی ہم آہنگی)۔ کام کے مسائل کے علاوہ، غیر رسمی بات چیت، کبھی کبھی بیرونی واقعات پر بحث، روشنی آف ٹاپ - یہ سب کمیونٹی اور ٹیم کا احساس پیدا کرتا ہے۔
تیسرا، میں ٹیم کے اندر انجینئرنگ کے اچھے طریقوں کے تعارف کو اجاگر کروں گا، کمپنی میں قبول کیے گئے معیارات کے مقابلے میں معیار بلند کرنے کی خواہش۔ صنعت میں قبول کیے گئے بہترین طریقوں کو نافذ کرنا، پہلے ٹیم میں، اور پھر مجموعی طور پر کمپنی میں، ٹیم کو یہ محسوس کرنے کا موقع فراہم کرتا ہے کہ وہ کسی نہ کسی طرح دوسروں سے آگے ہے، راہنمائی کر رہی ہے، اس سے تعلق کا احساس پیدا ہوتا ہے۔ ایک ٹھنڈی ٹیم کو۔
تعلق کا احساس بھی منصوبہ بندی اور انتظام میں ٹیم کی شرکت سے متاثر ہوتا ہے۔ جب ٹیم کے اراکین پراجیکٹ کے اہداف، کام کے منصوبوں، ٹیم کے معیارات اور انجینئرنگ کے طریقوں پر بحث کرنے اور نئے ملازمین کے انٹرویو کرنے میں شامل ہوتے ہیں، تو ان میں شرکت، مشترکہ ملکیت، اور کام پر اثر و رسوخ کا احساس پیدا ہوتا ہے۔ لوگ دوسروں کی طرف سے تجویز کردہ فیصلوں کے مقابلے میں خود سے کیے گئے فیصلوں کو انجام دینے کے لیے بہت زیادہ تیار ہوتے ہیں، چاہے وہ عملی طور پر ہم آہنگ ہوں۔
سالگرہ، سالگرہ، ساتھیوں کی زندگیوں میں اہم واقعات - ایک مشترکہ پیزا، ٹیم کی طرف سے ایک چھوٹا سا تحفہ شمولیت اور شکرگزار کا ایک گرم احساس دیتا ہے. کچھ کمپنیوں میں، کمپنی میں 5، 10، 15 سال کے کام کے لیے چھوٹی یادگاری نشانیاں دینے کا رواج ہے۔ ایک طرف، مجھے نہیں لگتا کہ یہ مجھے نئی کامیابیوں کے لیے اتنا حوصلہ دیتا ہے۔ لیکن، ظاہر ہے، تقریباً کوئی بھی خوش ہو گا کہ وہ اس کے بارے میں نہیں بھولے ہیں۔ یہ ان صورتوں میں سے ایک ہے جہاں حقیقت کی عدم موجودگی اس کی موجودگی کو تحریک دینے کے بجائے تنزلی کا باعث بنتی ہے۔ متفق ہوں، یہ کافی شرم کی بات ہو سکتی ہے اگر LinkedIn نے صبح آپ کو یاد دلایا اور آپ کے کام کی جگہ پر آپ کو آپ کی 10ویں سالگرہ پر مبارکباد دی، لیکن کمپنی کے کسی بھی ساتھی نے آپ کو مبارکباد نہیں دی یا آپ کو یاد نہیں کیا۔
بلاشبہ، ایک اہم نکتہ ٹیم کی ساخت میں تبدیلی ہے۔ یہ واضح ہے کہ یہاں تک کہ اگر ٹیم میں سے کسی کی آمد یا روانگی کا پہلے سے اعلان کر دیا جائے (مثال کے طور پر، کمپنی یا ٹیم کے نیوز لیٹر میں، یا ٹیم میٹنگ میں)، تو یہ خاص طور پر کسی کو نئی کامیابیوں کی طرف راغب نہیں کرتا ہے۔ لیکن اگر ایک اچھا دن آپ کو اپنے ساتھ ایک نیا شخص نظر آتا ہے، یا کوئی پرانا نظر نہیں آتا ہے، تو یہ حیرت کی بات ہو سکتی ہے، اور اگر آپ وہاں سے چلے جاتے ہیں، تو بالکل ناگوار ہو سکتا ہے۔ لوگوں کو خاموشی سے غائب نہیں ہونا چاہیے۔ خاص طور پر تقسیم شدہ ٹیم میں۔ خاص طور پر اگر آپ کا کام کسی دوسرے دفتر کے ساتھی پر منحصر ہے جو اچانک اٹھ کر غائب ہو گیا۔ ایسے لمحات یقینی طور پر ٹیم کو الگ سے پہلے سے آگاہ کرنے کے قابل ہیں۔
ایک اہم عنصر، جسے انگریزی میں کہتے ہیں۔ ملکیت ("قبضہ" کا لفظی ترجمہ اس کے معنی کی مکمل عکاسی نہیں کرتا)۔ یہ ملکیت کا احساس نہیں ہے، بلکہ آپ کے پروجیکٹ کے لیے ذمہ داری کا احساس ہے، یہ احساس جب آپ جذباتی طور پر اپنے آپ کو پروڈکٹ اور پروڈکٹ کو اپنے ساتھ جوڑتے ہیں۔ یہ تقریباً فلم "فل میٹل جیکٹ" میں میرین کی دعا کے مساوی ہے: "یہ میری رائفل ہے۔ ایسی بہت سی رائفلیں ہیں، لیکن یہ میری ہے۔ میری رائفل میری بہترین دوست ہے۔ وہ میری زندگی ہے. مجھے اس کا مالک بننا سیکھنا چاہیے جس طرح میں اپنی زندگی کا مالک ہوں۔ میرے بغیر میری رائفل بیکار ہے۔ میں اپنی رائفل کے بغیر بیکار ہوں۔ مجھے اپنی رائفل سیدھی گولی مارنی چاہیے۔ مجھے اس دشمن سے زیادہ درست طریقے سے گولی مارنی ہے جو مجھے مارنے کی کوشش کر رہا ہے۔ اس سے پہلے کہ وہ مجھے گولی مار دے مجھے اسے گولی مارنی ہوگی۔ ایسا ہی رہنے دو..."
جب کوئی شخص کسی پروڈکٹ پر طویل عرصے تک کام کرتا ہے، اسے اس کی تخلیق اور نشوونما کی پوری ذمہ داری اٹھانے کا موقع ملتا ہے، یہ دیکھنے کے لیے کہ کام کرنے والی چیز "کچھ نہیں" سے کیسے پیدا ہوتی ہے، لوگ اسے کیسے استعمال کرتے ہیں، یہ طاقتور احساس پیدا ہوتا ہے۔ پروڈکٹ ٹیمیں جو ایک پراجیکٹ پر لمبے عرصے تک اکٹھے کام کرتی ہیں عام طور پر ان ٹیموں کے مقابلے میں زیادہ حوصلہ افزائی اور ہم آہنگ ہوتی ہیں جو مختصر وقت کے لیے جمع ہوتی ہیں اور اسمبلی لائن موڈ میں کام کرتی ہیں، ایک پروجیکٹ سے دوسرے پروجیکٹ میں تبدیل ہوتی ہیں، پوری پروڈکٹ کی مکمل ذمہ داری کے بغیر۔ شروع سے آخر تک۔
چہارم پہچان کی ضرورت
ایک مہربان لفظ بھی بلی کو خوش کرتا ہے۔ ہر کوئی اپنے کیے ہوئے کام کی اہمیت اور اس کی مثبت تشخیص سے حوصلہ افزائی کرتا ہے۔ پروگرامرز سے بات کریں، انہیں وقتاً فوقتاً فیڈ بیک دیں، اچھی طرح سے کیے گئے کام کا جشن منائیں۔ اگر آپ کے پاس ایک بڑی اور تقسیم شدہ ٹیم ہے تو متواتر ملاقاتیں (جسے ایک سے ایک کہا جاتا ہے) اس کے لیے بہترین ہیں؛ اگر ٹیم بہت چھوٹی ہے اور مقامی طور پر مل کر کام کرتی ہے، تو یہ موقع عام طور پر کیلنڈر پر خصوصی ملاقاتوں کے بغیر فراہم کیا جاتا ہے (حالانکہ متواتر ملاقاتیں صرف ایک کے لیے بس اس کی ضرورت ہے، آپ اسے کم ہی کر سکتے ہیں)۔ یہ موضوع manager-tools.com پر مینیجرز کے لیے پوڈ کاسٹ میں اچھی طرح سے احاطہ کرتا ہے۔
تاہم، ثقافتی فرق کو ذہن میں رکھنے کے قابل ہے۔ امریکی ساتھیوں سے واقف کچھ نقطہ نظر ہمیشہ روسیوں کے ساتھ کام نہیں کریں گے۔ مغربی ممالک کی ٹیموں میں روزانہ کی بات چیت میں شائستگی کی جو سطح قبول کی جاتی ہے وہ ابتدائی طور پر روس کے پروگرامرز کے لیے ضرورت سے زیادہ معلوم ہوتی ہے۔ روسی ساتھیوں کی کچھ سیدھی سادی خصوصیت کو دوسرے ممالک کے ساتھی ان کے ساتھیوں کے ذریعہ بدتمیزی کے طور پر سمجھا جاسکتا ہے۔ یہ ایک بین الثانی ٹیم میں رابطے میں بہت اہم ہے؛ اس موضوع پر بہت کچھ لکھا جا چکا ہے؛ ایسی ٹیم کے مینیجر کو یہ یاد رکھنا چاہیے۔
خصوصیت کے مظاہرے، جہاں پروگرامرز سپرنٹ کے دوران تیار کردہ خصوصیات دکھاتے ہیں، اس ضرورت کو محسوس کرنے کے لیے ایک اچھا عمل ہے۔ اس حقیقت کے علاوہ کہ یہ ٹیموں کے درمیان کمیونیکیشن چینلز کو صاف کرنے، پروڈکٹ مینیجرز اور ٹیسٹرز کو نئی خصوصیات سے متعارف کرانے کا ایک بہترین موقع ہے، یہ ڈویلپرز کے لیے اپنے کام کے نتائج دکھانے اور اپنی تصنیف کی نشاندہی کرنے کا ایک اچھا موقع بھی ہے۔ ٹھیک ہے، اور اپنی عوامی بولنے کی مہارت کو پالش کریں، یقیناً، جو کبھی نقصان دہ نہیں ہوتا۔
مشترکہ ٹیم کے اجتماعات میں سرٹیفکیٹس، یادگاری نشانات (کم از کم ایک مہربان لفظ) کے ساتھ خاص طور پر ممتاز ساتھیوں کی اہم شراکت کا جشن منانا اچھا خیال ہوگا۔ لوگ عام طور پر ایسے سرٹیفکیٹس اور یادگاری نشانیوں کو بہت اہمیت دیتے ہیں، انہیں حرکت کرتے وقت اپنے ساتھ لے جاتے ہیں، اور عام طور پر ہر ممکن طریقے سے ان کا خیال رکھتے ہیں۔
ٹیم کے کام میں زیادہ اہم، طویل مدتی شراکت، جمع شدہ تجربے اور مہارت کو نشان زد کرنے کے لیے، ایک گریڈ سسٹم اکثر استعمال کیا جاتا ہے (دوبارہ، فوج میں فوجی صفوں کے نظام کے ساتھ تشبیہ دی جا سکتی ہے، جس کے علاوہ ماتحتی کو یقینی بنانا، اس مقصد کو بھی پورا کرتا ہے)۔ اکثر نوجوان ڈویلپرز اپنے کندھے کے پٹے پر نئے ستارے حاصل کرنے کے لیے دوگنا محنت کرتے ہیں (یعنی جونیئر ڈویلپر سے کل وقتی ڈویلپر کی طرف جانا وغیرہ)۔
اپنے لوگوں کی توقعات کو جاننا ضروری ہے۔ کچھ کو اعلیٰ درجے کی طرف سے حوصلہ افزائی کا زیادہ امکان ہوتا ہے، کہنے کا موقع، ایک معمار کہلانے کا، جبکہ دیگر، اس کے برعکس، گریڈز اور عنوانات سے لاتعلق ہیں اور تنخواہ میں اضافے کو کمپنی کی طرف سے پہچان کی علامت سمجھیں گے۔ . لوگوں کے ساتھ بات چیت کریں تاکہ وہ سمجھ سکیں کہ وہ کیا چاہتے ہیں اور ان کی توقعات کیا ہیں۔
شناخت کا مظاہرہ، ٹیم کی جانب سے اعلیٰ سطح کا اعتماد، عمل کی زیادہ آزادی یا کام کے نئے شعبوں میں شمولیت کے ذریعے دیا جا سکتا ہے۔ مثال کے طور پر، کچھ تجربہ حاصل کرنے اور کچھ نتائج حاصل کرنے کے بعد، ایک پروگرامر، اپنی خصوصیات کو تصریح کے مطابق نافذ کرنے کے علاوہ، نئی چیزوں کے فن تعمیر پر کام کر سکتا ہے۔ یا نئے شعبوں میں شامل ہوں جن کا براہ راست تعلق ترقی سے نہیں ہو سکتا ہے - ٹیسٹ آٹومیشن، بہترین انجینئرنگ کے طریقوں کو نافذ کرنا، ریلیز مینجمنٹ میں مدد کرنا، کانفرنسوں میں بات کرنا وغیرہ۔
V. ادراک اور خود حقیقت پسندی کی ضرورت۔
بہت سے پروگرامرز اپنی زندگی کے مختلف مراحل میں مختلف قسم کی پروگرامنگ سرگرمیوں پر توجہ مرکوز کرتے ہیں۔ کچھ لوگ مشین لرننگ کرنا، ڈیٹا کے نئے ماڈل تیار کرنا، کام کے لیے بہت سا سائنسی لٹریچر پڑھنا، اور شروع سے کچھ نیا بنانا پسند کرتے ہیں۔ دوسرا ڈیبگنگ اور موجودہ ایپلیکیشن کو سپورٹ کرنے کے قریب ہے، جس میں آپ کو موجودہ کوڈ، اسٹڈی لاگ، اسٹیک ٹریسز اور نیٹ ورک کیپچز کو دنوں اور ہفتوں تک گہرائی میں کھودنے کی ضرورت ہے، اور تقریباً کوئی نیا کوڈ نہیں لکھنا ہوگا۔
دونوں عمل کے لیے بڑی فکری کوشش کی ضرورت ہوتی ہے، لیکن ان کا عملی نتیجہ مختلف ہے۔ یہ خیال کیا جاتا ہے کہ پروگرامرز موجودہ حلوں کی حمایت کرنے میں ہچکچاتے ہیں؛ بلکہ وہ نئے حل کرنے کے لیے حوصلہ افزائی کرتے ہیں۔ اس میں حکمت کا دانہ ہے۔ دوسری طرف، سب سے زیادہ حوصلہ افزا اور متحد ٹیم جس کے ساتھ میں نے اب تک کام کیا ہے وہ کسی موجودہ پروڈکٹ کو سپورٹ کرنے، سپورٹ ٹیم کے رابطہ کرنے کے بعد کیڑے تلاش کرنے اور ٹھیک کرنے کے لیے وقف تھی۔ لوگ لفظی طور پر اس کام کے لیے رہتے تھے اور ہفتہ اور اتوار کو باہر جانے کے لیے تیار رہتے تھے۔ ہم نے ایک بار بے تابی سے ایک اور فوری اور پیچیدہ مسئلہ سے نمٹا، یا تو 31 دسمبر کی شام کو یا یکم جنوری کی سہ پہر کو۔
کئی عوامل نے اس اعلیٰ ترغیب کو متاثر کیا۔ سب سے پہلے، یہ صنعت میں ایک بڑا نام رکھنے والی کمپنی تھی، ٹیم نے خود کو اس سے منسلک کیا (دیکھیں "وابستگی کی ضرورت")۔ دوسری بات یہ کہ وہ آخری محاذ تھے، ان کے پیچھے کوئی نہیں تھا، اس وقت کوئی پروڈکٹ ٹیم نہیں تھی۔ ان کے اور صارفین کے درمیان دو سطحوں کی حمایت تھی، لیکن اگر مسئلہ ان تک پہنچا تو پیچھے ہٹنے کی کوئی جگہ نہیں تھی، ان کے پیچھے کوئی نہیں تھا، پوری کارپوریشن ان (چار نوجوان پروگرامرز) پر تھی۔ تیسرا، اس بڑی کمپنی کے بہت بڑے گاہک (ملکی حکومتیں، آٹوموبائل اور ہوابازی کے خدشات وغیرہ) اور کئی ممالک میں بہت بڑے پیمانے پر تنصیبات تھیں۔ نتیجے کے طور پر، ہمیشہ پیچیدہ اور دلچسپ مسائل، سادہ مسائل گزشتہ سطحوں کی حمایت کی طرف سے حل کیا گیا تھا. چوتھی بات، ٹیم کی حوصلہ افزائی سپورٹ ٹیم کی پیشہ ورانہ سطح سے بہت متاثر ہوئی جس کے ساتھ انہوں نے بات چیت کی (بہت تجربہ کار اور تکنیکی طور پر قابل انجینئرز تھے)، اور ہمیں ان کے تیار کردہ ڈیٹا کے معیار، ان کے تجزیہ پر ہمیشہ اعتماد تھا۔ وغیرہ پانچویں، اور مجھے لگتا ہے کہ یہ سب سے اہم نقطہ ہے - ٹیم بہت چھوٹی تھی، تمام لوگ اپنے کیریئر کے آغاز میں تھے. وہ ایک بڑے اور پیچیدہ پراڈکٹ کا مطالعہ کرنے میں دلچسپی رکھتے تھے، ایک نئے ماحول میں ان کے لیے نئے آنے والے سنگین مسائل کو حل کرنے میں دلچسپی رکھتے تھے، انھوں نے پیشہ ورانہ طور پر ارد گرد کی ٹیموں، مسائل اور صارفین کی سطح سے مطابقت پیدا کرنے کی کوشش کی۔ یہ پروجیکٹ ایک بہترین اسکول ثابت ہوا، بعد میں سب نے کمپنی میں اچھا کیریئر بنایا اور ٹیکنیکل لیڈرز اور سینئر مینیجر بن گئے، ان لڑکوں میں سے ایک اب ایمیزون ویب سروسز میں ٹیکنیکل مینیجر ہے، دوسرا آخر کار گوگل میں چلا گیا، اور سبھی ان میں سے اب بھی اس منصوبے کو گرمجوشی سے یاد کرتے ہیں۔
اگر یہ ٹیم ایسے پروگرامرز پر مشتمل ہوتی جن کے پیچھے 15-20 سال کا تجربہ ہوتا، تو حوصلہ مختلف ہوتا۔ عمر اور تجربہ یقیناً 100 فیصد تعین کرنے والے عوامل نہیں ہیں؛ یہ سب محرک کی ساخت پر منحصر ہے۔ اس خاص معاملے میں، نوجوان پروگرامرز کے علم اور ترقی کی خواہش نے بہترین نتائج برآمد کیے ہیں۔
عام طور پر، جیسا کہ ہم نے پہلے ہی کئی بار ذکر کیا ہے، آپ کو اپنے پروگرامرز کی توقعات کو جاننا چاہیے، سمجھنا چاہیے کہ ان میں سے کون اپنی سرگرمی کے شعبے کو بڑھانا یا تبدیل کرنا چاہتا ہے، اور ان توقعات کو مدنظر رکھیں۔
مسلو کے اہرام سے آگے: نتائج کی مرئیت، گیمفیکیشن اور مقابلہ، کوئی بات نہیں
پروگرامرز کی ترغیب کے حوالے سے مزید تین اہم نکات ہیں جن کا تذکرہ یقینی طور پر کرنے کی ضرورت ہے، لیکن انہیں Maslow کی ضروریات کے ماڈل میں کھینچنا بہت مصنوعی ہوگا۔
پہلا نتیجہ کی مرئیت اور قربت ہے۔
سافٹ ویئر کی ترقی عام طور پر ایک میراتھن ہے. R&D کی کوششوں کے نتائج مہینوں، بعض اوقات سالوں بعد نظر آتے ہیں۔ کسی مقصد تک جانا مشکل ہے جو افق سے بہت آگے ہے، کام کی مقدار خوفناک ہے، ہدف بہت دور ہے، واضح اور نظر نہیں آتا، "رات اندھیری اور خوفناک ہے۔" بہتر ہے کہ اس سڑک کو حصوں میں توڑ دیں، قریب ترین درخت تک راستہ بنائیں جو دکھائی دے، قابل رسائی ہو، خاکہ واضح ہو، اور یہ ہم سے زیادہ دور نہیں ہے - اور اس قریبی مقصد کی طرف بڑھیں۔ ہم کئی دنوں یا ہفتوں کی کوشش کرنا چاہتے ہیں، نتیجہ حاصل کرنا اور اس کا اندازہ لگانا چاہتے ہیں، پھر آگے بڑھتے ہیں۔ لہذا، کام کو چھوٹے حصوں میں توڑنے کے قابل ہے (چست طریقے سے سپرنٹ اس مقصد کو اچھی طرح سے انجام دیتے ہیں). ہم نے کام کا کچھ حصہ مکمل کر لیا ہے - اسے ریکارڈ کیا، سانس چھوڑی، اس پر بحث کی، قصورواروں کو سزا دی، بے گناہوں کو انعام دیا - ہم اگلا چکر شروع کر سکتے ہیں۔
یہ ترغیب کچھ حد تک اس سے ملتی جلتی ہے جس کا تجربہ کھلاڑی کمپیوٹر گیمز کو مکمل کرتے وقت کرتے ہیں: وہ وقتاً فوقتاً ہر سطح کو مکمل کرتے ہوئے تمغے، پوائنٹس، بونس حاصل کرتے ہیں؛ اسے "ڈوپامین موٹیویشن" کہا جا سکتا ہے۔
ایک ہی وقت میں، نتیجہ کی مرئیت لفظی طور پر اہم ہے۔ فہرست میں بند فیچر کو سبز ہونا چاہیے۔ اگر کوڈ لکھا ہوا ہے، ٹیسٹ کیا گیا ہے، جاری کیا گیا ہے، لیکن پروگرامر کو دکھائی دینے والی بصری حالت میں کوئی تبدیلی نہیں آئی ہے، تو وہ نامکمل محسوس کرے گا، تکمیل کا کوئی احساس نہیں ہوگا۔ ہمارے ورژن کنٹرول سسٹم کی ٹیموں میں سے ایک میں، ہر پیچ تین لگاتار مراحل سے گزرا - تعمیر کو جمع کیا گیا اور ٹیسٹ پاس ہوئے، پیچ نے کوڈ کا جائزہ لیا، پیچ کو ضم کر دیا گیا۔ ہر سٹیج کو بصری طور پر سبز ٹک یا سرخ کراس سے نشان زد کیا گیا تھا۔ ایک بار ڈویلپرز میں سے ایک نے شکایت کی کہ کوڈ کا جائزہ لینے میں بہت زیادہ وقت لگتا ہے، ساتھیوں کو رفتار بڑھانے کی ضرورت ہے، پیچ کئی دنوں سے لٹک رہے تھے۔ میں نے پوچھا، یہ اس کے لیے اصل میں کیا بدلتا ہے؟ سب کے بعد، جب کوڈ لکھا جاتا ہے، تعمیر کو جمع کیا جاتا ہے اور ٹیسٹ گزر چکے ہیں، اگر کوئی تبصرہ نہیں ہے تو اسے بھیجے گئے پیچ پر توجہ دینے کی ضرورت نہیں ہے. ساتھی خود اس کا جائزہ لیں گے اور اسے منظور کریں گے (اگر، دوبارہ، کوئی تبصرہ نہیں ہے)۔ اس نے جواب دیا، "ایگور، میں جلد از جلد اپنے تین سبز ٹک ٹک حاصل کرنا چاہتا ہوں۔"
دوسرا نکتہ گیمفیکیشن اور مقابلہ ہے۔
مصنوعات میں سے کسی ایک کو تیار کرتے وقت، ہماری انجینئرنگ ٹیم کا ہدف تھا کہ وہ اوپن سورس پروڈکٹس میں سے کسی ایک کی کمیونٹی میں نمایاں مقام حاصل کرے، ٹاپ-3 میں داخل ہو۔ اس وقت، کمیونٹی میں کسی کی مرئیت کا اندازہ لگانے کا کوئی معروضی طریقہ نہیں تھا؛ ہر بڑی شرکت کرنے والی کمپنیاں دعویٰ کرسکتی تھیں (اور وقتاً فوقتاً یہ دعویٰ کرتی تھیں) کہ وہ نمبر ایک شراکت دار ہے، لیکن شرکاء کی شراکت کا موازنہ کرنے کا کوئی حقیقی طریقہ نہیں تھا۔ آپس میں، وقت میں اس کی حرکیات کا جائزہ لینے کے لیے۔ اس کے مطابق، ٹیم کے لیے کوئی ہدف مقرر کرنے کا کوئی طریقہ نہیں تھا جسے کچھ طوطوں میں ناپا جا سکتا، اس کی کامیابی کی ڈگری کا اندازہ لگانا وغیرہ۔ اس مسئلے کو حل کرنے کے لیے، ہماری ٹیم نے کمپنیوں اور انفرادی شراکت داروں کی شراکت کی پیمائش اور تصور کے لیے ایک ٹول تیار کیا ہے۔ . محرک نقطہ نظر سے، یہ صرف ایک بم نکلا. یہ صرف انجینئرز اور ٹیمیں ہی نہیں تھیں جنہوں نے اپنی ترقی اور اپنے ساتھیوں اور حریفوں کی پیشرفت کی مسلسل نگرانی کی۔ ہماری کمپنی کی اعلیٰ انتظامیہ اور تمام بڑے حریفوں نے بھی اپنے دن کا آغاز stackalytics کے ساتھ کیا۔ سب کچھ بہت شفاف اور بصری ہو گیا، ہر کوئی احتیاط سے اپنی ترقی کی نگرانی کر سکتا تھا، ساتھیوں سے موازنہ کر سکتا تھا، وغیرہ۔ انجینئرز، مینیجرز اور ٹیموں کے لیے اہداف کا تعین کرنا آسان اور آسان ہو گیا ہے۔
ایک اہم نکتہ جو مقداری میٹرکس کے کسی بھی نظام کو لاگو کرتے وقت پیدا ہوتا ہے وہ یہ ہے کہ جیسے ہی آپ نے ان کو لاگو کیا ہے، نظام خود بخود ان مقداری میٹرکس کے حصول کو ترجیح دینے کی کوشش کرتا ہے، تاکہ کوالیٹیٹیو کو نقصان پہنچے۔ مثال کے طور پر، مکمل کردہ کوڈ کے جائزوں کی تعداد کو میٹرکس میں سے ایک کے طور پر استعمال کیا جاتا ہے۔ ظاہر ہے، کوڈ کا جائزہ مختلف طریقوں سے کیا جا سکتا ہے، آپ مکمل جائزہ لینے اور جانچ پڑتال کے ساتھ پیچیدہ پیچ کی جانچ پڑتال پر کئی گھنٹے صرف کر سکتے ہیں، اسے اپنے بینچ پر چلا سکتے ہیں، دستاویزات کے ساتھ چیک کر سکتے ہیں، اور اپنے کرما میں پلس ون جائزہ حاصل کر سکتے ہیں، یا چند منٹ کے پیچ میں آنکھیں بند کرکے چند درجن پر کلک کریں، ہر ایک کو +1 دیں اور کرما میں بیس جمع کریں۔ ایسے مضحکہ خیز واقعات تھے جب انجینئرز نے پیچ پر اتنی تیزی سے کلک کیا کہ انہوں نے CI سسٹم سے خودکار پیچ کو +1 دیا۔ جیسا کہ ہم نے بعد میں مذاق کیا، "جاؤ، جاؤ، جینکنز۔" کمٹ کے معاملے میں، بہت سے لوگ ایسے بھی تھے جنہوں نے کوڈ فارمیٹنگ ٹولز کے ذریعے کوڈ سے گزرے، تبصروں میں ترمیم کی، پیریڈ کو کوما میں تبدیل کیا، اور اس طرح اپنے کرما کو بڑھایا۔ اس سے نمٹنا بہت آسان ہے: ہم عقل کا استعمال کرتے ہیں اور مقداری میٹرکس کے علاوہ، ضروری، کوالٹیٹیو بھی استعمال کرتے ہیں۔ ٹیم کے کام کے نتائج کے استعمال کی ڈگری، بیرونی شراکت داروں کی تعداد، ٹیسٹ کوریج کی سطح، ماڈیولز اور پوری مصنوعات کا استحکام، پیمانے اور کارکردگی کی جانچ کے نتائج، بنیادی جائزہ لینے والے کندھے حاصل کرنے والے انجینئرز کی تعداد straps، حقیقت یہ ہے کہ پروجیکٹس کو بنیادی پروجیکٹس کمیونٹی میں قبول کیا گیا تھا، انجینئرنگ کے عمل کے مختلف مراحل کے معیار کی تعمیل - یہ سب اور بہت سے دوسرے عوامل کا اندازہ سادہ مقداری میٹرکس کے ساتھ کیا جانا چاہیے۔
اور آخر میں، تیسرا نکتہ - کوئی بکواس نہیں۔
ڈویلپرز بہت ہوشیار لوگ ہیں اور اپنے کام کی لائن میں انتہائی منطقی ہیں۔ وہ دن میں 8-10 گھنٹے طویل اور پیچیدہ منطقی زنجیروں کی تعمیر میں صرف کرتے ہیں، اس لیے انہیں پرواز کے دوران ان میں کمزوریاں نظر آتی ہیں۔ کچھ کرتے وقت، وہ، سب کی طرح، یہ سمجھنا چاہتے ہیں کہ وہ ایسا کیوں کر رہے ہیں، بہتر کے لیے کیا تبدیلی آئے گی۔ یہ انتہائی اہم ہے کہ آپ نے اپنی ٹیم کے لیے جو اہداف مقرر کیے ہیں وہ ایماندار اور حقیقت پسندانہ ہوں۔ پروگرامنگ ٹیم کو برا خیال بیچنے کی کوشش کرنا برا خیال ہے۔ ایک خیال برا ہے اگر آپ خود اس پر یقین نہیں کرتے ہیں، یا، انتہائی صورتوں میں، آپ کے پاس اختلاف اور عزم کی اندرونی حالت نہیں ہے (میں متفق نہیں ہوں، لیکن میں یہ کروں گا)۔ ہم نے ایک بار ایک کمپنی میں ایک حوصلہ افزائی کا نظام نافذ کیا، جس کے عناصر میں سے ایک فیڈ بیک فراہم کرنے کا ایک الیکٹرانک نظام تھا۔ انہوں نے بہت پیسہ لگایا، لوگوں کو تربیت کے لیے امریکہ لے گئے، عام طور پر، انہوں نے بھرپور سرمایہ کاری کی۔ ایک بار، تربیت کے بعد بات چیت میں، ایک مینیجر نے اپنے ماتحتوں سے کہا: "یہ خیال برا نہیں ہے، ایسا لگتا ہے کہ یہ کام کرے گا. میں خود آپ کو الیکٹرانک فیڈ بیک نہیں دوں گا، لیکن آپ اسے اپنے لوگوں کو دیتے ہیں اور ان سے اس کا مطالبہ کرتے ہیں۔ بس، مزید کچھ بھی نافذ نہیں ہو سکا۔ خیال، یقینا، کچھ بھی نہیں میں ختم ہوا.
ماخذ: www.habr.com