آپ کسی پروجیکٹ یا سروس کی فراہمی (engagement) کے دوران ہیں اور کسٹمر کا سربراہ کہتا ہے: “ہمیں اس ورک فلو (workflow) کی ضرورت ہے جو ہمارے تینوں خطوں (regions) کے لیے کام کرے—جن میں سے ہر ایک کے منظوری کے اصول مختلف ہیں—اور اس کا نفاذ پلیٹ فارم کے ذریعے ہونا چاہیے۔” ہو سکتا ہے کہ آپ ڈیپلائمنٹ کے دوران عارضی طور پر کوئی حل (hack) تیار کر لیں، لیکن آپ یہ بھی جانتے ہیں کہ اگلا کسٹمر بھی اسی قسم کی چیز کا مطالبہ کرے گا۔
یہ سبق اس لمحے کی نشاندہی کرنے کے بارے میں ہے جب کسٹمر کی کوئی درخواست محض ایک بار کی ڈیلیوری (one-off task) کے بجائے پروڈکٹ کے بنیادی کام (core product work) کی شکل اختیار کر لیتی ہے، اور پھر یہ واضح کرنے کے بارے میں ہے کہ بطور ‘فارورڈ ڈیپلائڈ انجینئر’ (FDE) آپ کی ذمہ داری کیا رہتی ہے۔ فارورڈ ڈیپلائڈ انجینئر (FDE) وہ انجینئر ہوتا ہے جو کسٹمر کے ماحول میں کام کرتے ہوئے کسٹمر کی ضروریات کو پروڈکٹ اور انجینئرنگ کے کام میں منتقل (translate) کرتا ہے۔
کچھ بھی تعمیر کرنے کا فیصلہ کرنے سے پہلے، آپ یہ طے کرتے ہیں کہ اصل درخواست کیا ہے۔ کیا یہ صرف “اس اکاؤنٹ کے لیے جمعہ تک اسے فعال کرنے” کا معاملہ ہے، یا یہ اس بات کی نشاندہی ہے کہ “ہمارے پاس ایک ایسی صلاحیت (capability) کا فقدان ہے جسے دوبارہ استعمال کیا جا سکے، اور یہ کسٹمر اس ضرورت کا پہلا مضبوط اشارہ ہے”؟
کلائنٹ کی جانب سے کسی مخصوص اور وقتی تبدیلی (one-off change) اور دوبارہ استعمال کے قابل صلاحیت (reusable capability) کے درمیان فرق کا جائزہ لیں۔
کوئی درخواست اس وقت ‘پروڈکٹ اسٹریٹجی’ بن جاتی ہے جب معاملہ صرف اس مخصوص کسٹمر کی کنفیگریشن (ترتیب) تک محدود نہیں رہتا بلکہ پروڈکٹ کی کسی ایسی صلاحیت کی نشاندہی کرنے لگتا ہے جو فی الحال موجود نہیں ہے۔ آپ کو اس کا احساس تب ہوتا ہے جب کسٹمر محض کسی نتیجے (آؤٹ پٹ) کا مطالبہ نہیں کر رہا ہوتا، بلکہ کسی ایسے اصول کا تقاضا کر رہا ہوتا ہے جسے پلیٹ فارم کو خود اپنانا اور برقرار رکھنا چاہیے۔
اس صورتحال پر غور کریں۔ کسٹمر چاہتا ہے کہ خطے کے لحاظ سے مخصوص منظوریوں (region-specific approvals) کا نفاذ پلیٹ فارم کے اندر ہو—نہ کہ کسی اسپریڈ شیٹ میں، نہ دستی عمل کے طور پر، اور نہ ہی کسی ایسے کسٹم اسکرپٹ کے ذریعے جسے صرف آپ کی ٹیم ہی سمجھتی ہو۔ یہ اس بات کا اشارہ ہے کہ وہ کسی ایسی چیز کا مطالبہ کر رہے ہیں جس کے لیے پروڈکٹ ڈیزائن، طویل مدتی سپورٹ، اور اس کے کام کرنے کے طریقہ کار کے بارے میں ایک واضح معاہدے کی ضرورت ہے۔
ان دونوں کے درمیان فرق کرنے کا ایک فوری طریقہ یہ پوچھنا ہے کہ آپ کے جانے کے بعد کیا ہوگا۔ اگر حل کے لیے آپ کو کسی ‘کسٹم برانچ’، ‘پرائیویٹ پیچ’، یا کسی ایسے خصوصی طرزِ عمل کو برقرار رکھنے کی ضرورت پڑے جس کی وضاحت آپ کے نوٹس کے بغیر کوئی نہ کر سکے، تو یہ معاملہ ‘پروڈکٹ’ کے دائرہ کار میں داخل ہو رہا ہے؛ کیونکہ اسے ایک باقاعدہ انٹرفیس اور مستحکم سپورٹ کے نظام کی ضرورت ہے۔
اگر کسی چیز کے لیے سپورٹ درکار ہے، تو اسے ڈیزائن بھی کیا جانا چاہیے جس لمحے کسٹمر یہ توقع کرے کہ کوئی صلاحیت اپ گریڈز اور نئے صارفین کے آنے کے باوجود برقرار رہے گی، تو اسے محض ایک بار کی ڈیلیوری یا عارضی حل کے بجائے ‘پروڈکٹ’ کا حصہ سمجھیں۔
یہاں تک کہ جب کسی کام کو پروڈکٹ کے بنیادی حصے (core product work) کے طور پر کیا جانا چاہیے، تب بھی اس پروجیکٹ یا مصروفیت (engagement) کو آگے بڑھانے کی ذمہ داری آپ ہی پر ہوتی ہے۔ آپ کا کام کسٹمر کے لیے حائل رکاوٹوں کو دور کرنا ہے، لیکن ایسا کرتے ہوئے خاموشی سے پروڈکٹ کے کوڈ یا ساخت کو تبدیل (rewrite) نہیں کرنا۔
اس ذمہ داری کے دو پہلو ہیں۔
اول، آپ ڈیلیوری کے عمل کو جاری رکھتے ہیں۔ آپ کسٹمر کی درخواست کو ایک واضح ضرورت (requirement) میں تبدیل کرتے ہیں، موجودہ ڈیپلائمنٹ میں جو کچھ ممکن ہے اس کی نشاندہی کرتے ہیں، اور ایک ایسا عبوری راستہ تجویز کرتے ہیں جو اس کی حدود کے بارے میں ایماندارانہ ہو۔
دوم، آپ پروڈکٹ کی سالمیت (integrity) کا تحفظ کرتے ہیں۔ پروڈکٹ کی سالمیت کا مطلب ہے کہ پروڈکٹ ایک مربوط اکائی کے طور پر قائم رہے، نہ کہ اکاؤنٹ کے لحاظ سے مخصوص ایسے رویوں کا مجموعہ بن جائے جو وقت کے ساتھ ساتھ ایک دوسرے کے لیے مسائل پیدا کریں یا سسٹم کو خراب کر دیں۔ عملی طور پر، اس کا مطلب ہے کہ آپ ‘فورکس’ (کوڈ کی الگ شاخیں بنانے) سے گریز کرتے ہیں، ایسے پوشیدہ ‘فلیگز’ (flags) سے بچتے ہیں جو صرف ایک کسٹمر استعمال کرتا ہے، اور ایسے وعدے کرنے سے اجتناب کرتے ہیں جو بعد میں انجینئرنگ ٹیم کو مشکل صورتحال میں ڈال دیں۔
منظوریوں (approvals) کی ہماری مثال میں، آپ ایک ایسا عارضی عمل نافذ کر سکتے ہیں جو آڈٹ کی ضرورت کو پورا کرے، جبکہ ساتھ ہی آپ بنیادی صلاحیت (core capability) کے لیے شواہد اکٹھے کر رہے ہوں۔ آپ درخواست کو مسترد نہیں کر رہے، بلکہ اس کے نفاذ کی ترتیب (sequencing) طے کر رہے ہیں۔
پیچیدہ بات یہ ہے کہ ناکامی کی ہر صورت بظاہر “فوری ردعمل دینے” (being responsive) جیسا تاثر دے سکتی ہے۔ اس کی قیمت (یا نقصان) بعد میں ادا کرنی پڑتی ہے، عام طور پر تب جب آپ کسی دوسرے کسٹمر کے ساتھ کام کر رہے ہوتے ہیں۔
آئیے کچھ ایسی چھوٹی مثالیں دیکھتے ہیں جن سے ظاہر ہوتا ہے کہ یہ ناکامیاں کس طرح بعد میں اضافی اخراجات یا مسائل کا باعث بنتی ہیں۔