کیوں صرف اپنی کوڈنگ کو اپ گریڈ کرنے سے آپ ایک بہتر ڈویلپر نہیں بن سکتے

Techlead Skyeng Kirill Rogovoy (فلیش ہہہ) کانفرنسوں میں ایک پریزنٹیشن دیتا ہے جس میں وہ ان مہارتوں کے بارے میں بات کرتا ہے جو ہر اچھے ڈویلپر کو بہترین بننے کے لیے تیار کرنا چاہیے۔ میں نے اس سے کہا کہ وہ یہ کہانی حبرہ کے قارئین کے ساتھ شیئر کرے، میں کرل کو فرش دیتا ہوں۔

ایک اچھے ڈویلپر کے بارے میں افسانہ یہ ہے کہ وہ:

1. صاف کوڈ لکھتا ہے۔
2. بہت سی ٹیکنالوجیز جانتا ہے۔
3. کاموں کو تیزی سے کوڈنگ کرنا
4. الگورتھم اور ڈیزائن پیٹرن کا ایک گروپ جانتا ہے۔
5. کلین کوڈ کا استعمال کرتے ہوئے کسی بھی کوڈ کو ریفیکٹر کر سکتا ہے۔
6. نان پروگرامنگ کاموں میں وقت ضائع نہیں کرتا
7. آپ کی پسندیدہ ٹیکنالوجی کا 100% ماسٹر

HR مثالی امیدواروں کو اس طرح دیکھتا ہے، اور اس کے مطابق اسامیوں کو بھی اس طرح نظر آتا ہے۔

لیکن میرا تجربہ کہتا ہے کہ یہ زیادہ سچ نہیں ہے۔

سب سے پہلے، دو اہم تردید:
1) میرا تجربہ پروڈکٹ ٹیموں کا ہے، یعنی کمپنیاں ان کی اپنی مصنوعات کے ساتھ، آؤٹ سورسنگ نہیں؛ آؤٹ سورسنگ میں سب کچھ بہت مختلف ہو سکتا ہے۔
2) اگر آپ جونیئر ہیں، تو تمام مشورے لاگو نہیں ہوں گے، اور اگر میں آپ ہوتا، تو میں ابھی پروگرامنگ پر توجہ دیتا۔

اچھا ڈویلپر: حقیقت

1: اوسط کوڈ سے بہتر

ایک اچھا ڈویلپر جانتا ہے کہ کس طرح ٹھنڈا فن تعمیر کرنا ہے، ٹھنڈا کوڈ لکھنا ہے، اور بہت زیادہ کیڑے نہیں بنانا ہے۔ عام طور پر، وہ اوسط سے بہتر کارکردگی کا مظاہرہ کرتا ہے، لیکن وہ ماہرین کے سب سے اوپر 1% میں نہیں ہے۔ زیادہ تر بہترین ڈویلپرز جن کو میں جانتا ہوں وہ عظیم کوڈر نہیں ہیں: وہ اپنے کام میں بہت اچھے ہیں، لیکن وہ کچھ بھی غیر معمولی نہیں کر سکتے۔

2: مسائل پیدا کرنے کے بجائے حل کرتا ہے۔

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

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

3: زیادہ سے زیادہ نتائج حاصل کرنے کے لیے کم سے کم کوشش کرنے کی کوشش کرتا ہے، چاہے اس کا مطلب بیساکھی لکھنا ہو۔

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

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

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

4. اس کا اپنا بزنس مینجمنٹ سسٹم ہے اور اس میں کسی بھی پیچیدگی کے پروجیکٹس پر کام کرنے کے قابل ہے۔

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

5. سوالات اور کسی بھی شرائط اور تعارف کی وضاحت کرتا ہے۔

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

6. آپ کے ارد گرد کے عمل اور لوگوں کو بہتر بناتا ہے۔

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

7. دوسروں کو سنبھالنے میں بہترین، چاہے مینیجر ہی کیوں نہ ہو۔

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

8. اپنے علم کو عقیدہ نہیں سمجھتا، تنقید کے لیے مسلسل کھلا رہتا ہے۔

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

آئیے ایک مثالی ڈویلپر کے بارے میں میرے خیال کا عام طور پر قبول کردہ سے موازنہ کریں:

یہ تصویر دکھاتی ہے کہ اوپر بیان کیے گئے نکات میں سے کتنے کوڈ سے متعلق ہیں اور کتنے نہیں ہیں۔ ایک پروڈکٹ کمپنی میں ترقی صرف ایک تہائی پروگرامنگ ہے، باقی 2/3 کا کوڈ سے بہت کم تعلق ہے۔ اور اگرچہ ہم بہت سارے کوڈ لکھتے ہیں، لیکن ہماری تاثیر کا انحصار ان "غیر متعلقہ" دو تہائی پر ہے۔

تخصص، عمومیت اور 80-20 اصول

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

80-20 اصول ہمیں بتاتا ہے کہ 80% نتیجہ 20% کوششوں سے آتا ہے۔ 80% محصول 20% صارفین سے آتا ہے، 80% منافع 20% ملازمین سے آتا ہے، وغیرہ۔ تدریس میں، اس کا مطلب ہے کہ 80% علم ہم پہلے 20% وقت گزارے میں حاصل کرتے ہیں۔

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

کل: آپ اپنا 100% وقت کسی ہنر کی حد تک مطالعہ کرنے میں صرف کر سکتے ہیں، یا آپ اتنا ہی وقت پانچ شعبوں پر صرف کر سکتے ہیں، ہر ایک میں 80% تک لیول کر سکتے ہیں۔ اس سادہ ریاضی کی پیروی کرتے ہوئے، ہم ایک ہی وقت میں چار گنا زیادہ مہارت حاصل کر سکتے ہیں۔ یہ ایک مبالغہ آرائی ہے، لیکن یہ خیال کو واضح کرتا ہے۔

متعلقہ مہارتوں کو 80% نہیں بلکہ 30-50% تک تربیت دی جا سکتی ہے۔ 10-20 گھنٹے گزارنے کے بعد، آپ متعلقہ شعبوں میں نمایاں طور پر بہتری لائیں گے، ان میں ہونے والے عمل کی کافی سمجھ حاصل کریں گے اور بہت زیادہ خود مختار بن جائیں گے۔

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

اور آخر میں، تربیت ایک سرمایہ کاری ہے، اور سرمایہ کاری میں تنوع اہم ہے۔

کیا سکھانا ہے۔

تو کیا سکھائیں اور کیسے؟ ایک مضبوط کمپنی میں ایک عام ڈویلپر باقاعدگی سے استعمال کرتا ہے:

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

اور عملی طور پر ان میں سے کوئی بھی مہارت کوڈ کے ساتھ کسی بھی طرح سے نہیں ملتی ہے۔ انہیں الگ سے سکھانے اور اپ گریڈ کرنے کی ضرورت ہے، اور اگر ایسا نہیں کیا گیا تو وہ بہت نچلی سطح پر رہیں گے، جو انہیں مؤثر طریقے سے استعمال نہیں ہونے دیتا۔

کن علاقوں میں ترقی کے قابل ہیں؟

1. نرم مہارت وہ سب کچھ ہے جو ایڈیٹر میں بٹن دبانے سے متعلق نہیں ہے۔ اس طرح ہم پیغامات لکھتے ہیں، ملاقاتوں میں ہمارا برتاؤ کیسے ہوتا ہے، ہم ساتھیوں کے ساتھ کیسے بات چیت کرتے ہیں۔ یہ سب واضح چیزیں لگتی ہیں، لیکن اکثر ان کا اندازہ نہیں لگایا جاتا۔

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

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

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

کیا پڑھنا ہے۔

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

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

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

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

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

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

ماخذ: www.habr.com