ہم نے 6 ہفتوں تک غلط پروڈکٹ بنائی
ہم نے چھ ہفتوں تک غلط چیز بنائی۔ کلائنٹ نے کبھی شکایت نہیں کی۔ یہی مسئلہ تھا۔
یہ ٹولز یا پروڈکٹیوٹی ہیکس (productivity hacks) کے بارے میں نہیں ہے۔ یہ ایک تلخ حقیقت کے بارے میں ہے۔
ایک ہیلتھ کیئر کلائنٹ نے ہم سے مریضوں کی بکنگ کا سسٹم مانگا۔ ہم نے سوالات کیے۔ ہم نے سر ہلایا۔ ہم نے بنانا شروع کر دیا۔
چھٹے ہفتے میں، ہم نے انہیں ایک ڈیمو دکھایا۔ کلائنٹ خاموش ہو گیا۔
انہوں نے کہا: "یہ بہت اچھا ہے۔ لیکن نرسیں اپائنٹمنٹ بک نہیں کرتیں۔ انشورنس کوآرڈینیٹرز کرتے ہیں۔ ان کا ورک فلو (workflow) مختلف ہے۔"
کسی نے جھوٹ نہیں بولا۔ کسی نے غلط پیغام رسانی نہیں کی۔ ہم بس یہ پوچھنے میں ناکام رہے کہ اس سافٹ ویئر کو روزانہ کون استعمال کرے گا۔
سب سے مہنگا کوڈ وہ ہے جو غلط مسئلے کو حل کرتا ہے۔ بدترین کوڈ وہ نہیں ہے جو کریش (crash) ہو جائے۔ بلکہ وہ کوڈ ہے جو بالکل ٹھیک کام کرتا ہے لیکن کچھ حل نہیں کرتا۔
ہماری سب سے بڑی غلطیاں یہ ہیں:
- یوزر پرسونا (user persona) کو نظر انداز کرنا۔ ہم نے صارف کے بجائے فیصلہ ساز کے لیے بنایا۔
- منظوری کو درستی سمجھ لینا۔ کلائنٹ کا "ہاں" کہنا اس بات کی ضمانت نہیں کہ پروڈکٹ درست ہے۔
- منظوری کو دفاع کے طور پر استعمال کرنا۔ اگر آپ اپنا کام کسی ایسے شخص کو نہیں دکھائیں گے جس کی آپ عزت کرتے ہیں، تو کلائنٹ کی منظوری کو ڈھال کے طور پر استعمال نہ کریں۔
- ڈیپلائمنٹ (deployment) کو فنش لائن سمجھنا۔ کامیابی لانچ کے بعد ہوتی ہے۔
اسے کیسے ٹھیک کریں:
جب آپ اختلاف کریں تو واضح رہیں۔ کلائنٹ سے کہیں: "ہم یہ بنائیں گے کیونکہ آپ نے کہا ہے۔ لیکن ہمارا خیال ہے کہ X کی وجہ سے Y ہوگا۔ آئیے اسے تحریری طور پر نوٹ کر لیں۔"
یہ جملہ بعد میں ہونے والے الزامات سے بچاتا ہے۔
ڈیپلائمنٹ کو اختتام سمجھنا بند کریں۔ آپ کو ایرر ٹریکنگ (error tracking)، اپ ٹائم الرٹس (uptime alerts)، اور ایرر ریٹس اور لیٹنسی (latency) کے لیے ایک سنگل ڈیش بورڈ کی ضرورت ہے۔ آپ کو اپنے مستقبل کے لیے دستاویزات (documentation) کی بھی ضرورت ہے۔
آپ کی ٹیم کون سی غلطی بار بار کرتی ہے؟