𝗪𝗲 𝗕𝘂𝗶𝗹𝘁 𝗧𝗵𝗲 𝗪𝗿𝗼𝗻𝗴 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗙𝗼𝗿 𝟲 𝗪𝗲𝗲𝗸𝘀
మేము ఆరు వారాల పాటు తప్పు వస్తువును తయారు చేశాము. క్లయింట్ ఎప్పుడూ ఫిర్యాదు చేయలేదు. అదే సమస్య.
ఇది టూల్స్ లేదా ప్రొడక్టివిటీ హ్యాక్స్ గురించి కాదు. ఇది ఒక చేదు నిజం గురించి.
ఒక హెల్త్కేర్ క్లయింట్ మమ్మల్ని పేషెంట్ బుకింగ్ సిస్టమ్ కావాలని అడిగారు. మేము ప్రశ్నలు అడిగాము. తల ఊపాము. తయారు చేయడం ప్రారంభించాము.
ఆరో వారంలో, మేము వారికి డెమో చూపించాము. క్లయింట్ నిశ్శబ్దంగా ఉండిపోయారు.
వారు ఇలా అన్నారు: "ఇది బాగుంది. కానీ నర్సులు అపాయింట్మెంట్లు బుక్ చేయరు. ఇన్సూరెన్స్ కోఆర్డినేటర్లే చేస్తారు. వారి వర్క్ఫ్లో వేరుగా ఉంటుంది."
ఎవరూ అబద్ధం చెప్పలేదు. ఎవరూ తప్పుగా కమ్యూనికేట్ చేయలేదు. సాఫ్ట్వేర్ను ప్రతిరోజూ ఎవరు ఉపయోగిస్తారో అడగడంలో మేము విఫలమయ్యాము.
అత్యంత ఖరీదైన కోడ్ తప్పు సమస్యను పరిష్కరిస్తుంది. క్రాష్ అయ్యే కోడ్ అత్యంత చెత్త కోడ్ కాదు. అది పర్ఫెక్ట్గా పనిచేస్తూ కూడా దేనినీ పరిష్కరించని కోడ్.
మా అతిపెద్ద తప్పులు ఇక్కడ ఉన్నాయి:
- యూజర్ పర్సోనాను (user persona) విస్మరించడం. మేము యూజర్ కోసం కాకుండా, నిర్ణయం తీసుకునే వ్యక్తి (decision maker) కోసం తయారు చేశాము.
- అప్రూవల్ను (approval) కరెక్ట్నెస్తో (correctness) కన్ఫ్యూజ్ చేయడం. క్లయింట్ "అవును" అన్నంత మాత్రాన ఉత్పత్తి సరైనదని అర్థం కాదు.
- అప్రూవల్ను రక్షణగా ఉపయోగించడం. మీరు గౌరవించే వ్యక్తికి మీ పనిని చూపించలేనప్పుడు, క్లయింట్ అప్రూవల్ను ఒక కవచంగా ఉపయోగించకండి.
- డిప్లాయ్మెంట్ను (deployment) ముగింపు రేఖగా భావించడం. విజయం లాంచ్ తర్వాత వస్తుంది.
దీన్ని ఎలా సరిదిద్దాలి:
మీరు విభేదించినప్పుడు స్పష్టంగా ఉండండి. క్లయింట్తో ఇలా చెప్పండి: "మీరు అడిగారు కాబట్టి మేము దీనిని తయారు చేస్తాము. కానీ X వల్ల Y జరుగుతుందని మేము నమ్ముతున్నాము. దీనిని మేము లిఖితపూర్వకంగా నమోదు చేసుకుందాం."
ఈ వాక్యం తర్వాత వచ్చే నిందలను ఆపుతుంది.
డిప్లాయ్మెంట్ను ముగింపుగా చూడటం ఆపండి. మీకు ఎర్రర్ ట్రాకింగ్ (error tracking), అప్టైమ్ అలర్ట్స్ (uptime alerts), మరియు ఎర్రర్ రేట్లు మరియు లేటెన్సీ (latency) కోసం ఒకే ఒక డ్యాష్బోర్డ్ అవసరం. అలాగే మీ భవిష్యత్తు అవసరాల కోసం డాక్యుమెంటేషన్ కూడా అవసరం.
మీ టీమ్ ఏ తప్పును పదేపదే చేస్తోంది?