بہت تھوڑی سی گفتگو

کب تھا؟ پچھلی بار جب آپ نے میٹنگ طے کی تھی اور ان تین افراد کی بجائے آٹھ افراد کو مدعو کیا تھا جنھیں واقعتا there وہاں جانے کی ضرورت اس وجہ سے تھی کہ آپ نہیں چاہتے تھے کہ کسی کو چھوڑ دیا جائے۔

آخری بار آپ نے کب کمپنی بھر میں ای میل بھیجی تھی جس میں کچھ ایسا ہی کہا گیا تھا ، 'ارے ، توجہ کافی پینے والوں: اگر آپ برتن ختم کریں تو ، دوسرا بنائیں!' اگرچہ اصل میں صرف ایک شخص ہے جو اس اصول کی خلاف ورزی کرتا ہے (اور وہ آپ کی شریک بانی ہیں)؟

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

یہ ایک عام بیماری کی علامات ہیں۔ بہت زیادہ مواصلات .

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

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

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

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

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

تنظیموں میں زیادہ کامنیکیشن کی لاگت کا فریڈ بروکس نے 1975 میں اپنی کتاب ، افسانوی انسان مہینہ . بروکس نے آئی بی ایم میں او ایس / 360 پراجیکٹ کو چلانے میں مدد کی ، کمپنی کے مین فریموں کے لئے ایک وشال آپریٹنگ سسٹم تعمیر کیا۔ ان دنوں میں ، کمپیوٹر بڑے ، کمر -ی سائز ، واٹر ٹھنڈک مشینیں تھیں ، بعض اوقات 256،000 بائٹس مین میموری کی ہوتی ہیں۔ OS / 360 شاید اس وقت تک کا سب سے بڑا سوفٹویئر پروجیکٹ تھا۔ اور یہ تھا یادگار طور پر دیر.

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

اس جملے کو دوبارہ پڑھیں ، کیونکہ یہ بدیہی نہیں ہے۔ بروکس نے دریافت کیا کہ لوگوں کو کسی پروجیکٹ میں شامل کرنے سے یہ کام ہوگا شیڈول کے پیچھے مزید .

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

جتنی بڑی ٹیم ، اتنی ہی بدتر ہوتی جاتی ہے۔ جب آپ کے پاس ایک شخص کی ٹیم ہوتی ہے تو ، آپ کو مواصلات کی کوئی ضرورت نہیں ہوتی ہے۔ کوئی نہیں

دوسرا شخص شامل کریں ، اور اب آپ کا ایک جوڑا ہے: آدم اور مریم کو تھوڑی دیر میں ایک بار بات کرنا ہوگی۔

اب ، ایک تیسرا شخص شامل کریں ، کہو ، سرینواس ، اور اچانک ہم ایک تعلق سے تین ہو گئے ، چونکہ سرینواس کو آدم اور مریم سے بات کرنا ہے۔

ایک چوتھا فرد شامل کریں۔ میری مدد کرنے کے لئے میں یہاں ناموں سے باہر چلا آرہا ہوں - ٹھیک ہے: برٹنی۔ اگر ہم اسے شامل کرتے ہیں ، اور اسے ان سب کے ساتھ ہم آہنگی کرنے کی ضرورت ہے تو آپ کو چھ رابطے ملیں گے۔

ریاضی کی طرف مائل ہونے کے لئے ، فارمولا یہ ہے کہ اگر آپ کی ٹیم میں N لوگ موجود ہیں تو ، موجود ہیں (این^دو-ن) / 2 رابطے یہ چارٹ واضح کرتا ہے کہ یہ مسئلہ کیسے بن جاتا ہے:

جیسا کہ آپ دیکھ سکتے ہیں ، مواصلات کے اخراجات اس وقت تک بہت تیزی سے بڑھنا شروع ہوجاتے ہیں ، جب تک کہ بڑی ٹیموں میں ، ہر کسی کو کرنے کا وقت باقی سب کے ساتھ ہم آہنگی کرنا ہوتا ہے - اور کسی کو کوئی کام نہیں ہوتا ہے۔ مائیکرو سافٹ کے ایک سابق پروگرامر ، 2006 میں ، مویشی لیٹ وین نے ایک بلاگ پوسٹ لکھی جس میں اس نے اس سال کی تفصیل بتاتے ہوئے لکھا تھا کہ ونڈوز وسٹا کے ایک مینو میں شامل ہونے والی اشیاء کی فہرست کو مربوط کرنے میں صرف کیا تھا۔ (دیکھیں ونڈوز شٹ ڈاؤن کرپسٹ .) لیٹ وین نے سوچا کہ اس ایک مینو کو ڈیزائن کرنے میں 43 افراد کی آواز ہے۔ تینتالیس! بروکس کے فارمولے کے ذریعہ ، اس کا مطلب ہے 903 رابطوں کا انتظام کرنا۔ لیٹ وین کا کہنا ہے کہ انہوں نے رابطہ کاروں پر اتنا وقت گزارا کہ ، 12 مہینوں میں ، انہوں نے 200 سے کم کوڈ تیار کیا۔

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

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

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

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

جوئل اسلوسکی فوگ کریک سافٹ ویئر کے شریک بانی اور سی ای او اور سافٹ ویئر کے مقبول بلاگ جوئل کے میزبان ہیں۔ اس کے کالموں کے آرکائیو کیلئے ، جائیں www.inc.com/author/joel-spolsky .