ਅਸੀਂ 6 ਹਫ਼ਤਿਆਂ ਤੱਕ ਗਲਤ ਉਤਪਾਦ ਬਣਾਇਆ
ਅਸੀਂ ਛੇ ਹਫ਼ਤਿਆਂ ਤੱਕ ਗਲਤ ਚੀਜ਼ ਬਣਾਈ। ਕਲਾਇੰਟ ਨੇ ਕਦੇ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕੀਤੀ। ਇਹੀ ਸਮੱਸਿਆ ਸੀ।
ਇਹ ਟੂਲਸ ਜਾਂ ਪ੍ਰੋਡਕਟੀਵਿਟੀ ਹੈਕਸ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਕੌੜੇ ਸੱਚ ਬਾਰੇ ਹੈ।
ਇੱਕ ਹੈਲਥਕੇਅਰ ਕਲਾਇੰਟ ਨੇ ਸਾਡੇ ਕੋਲੋਂ ਮਰੀਜ਼ਾਂ ਦੀ ਬੁਕਿੰਗ ਲਈ ਇੱਕ ਸਿਸਟਮ ਮੰਗਿਆ। ਅਸੀਂ ਸਵਾਲ ਪੁੱਛੇ। ਅਸੀਂ ਹਾਂ ਵਿੱਚ ਸਿਰ ਹਿਲਾਇਆ। ਅਸੀਂ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।
ਛੇਵੇਂ ਹਫ਼ਤੇ ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਡੈਮੋ ਦਿਖਾਇਆ। ਕਲਾਇੰਟ ਚੁੱਪ ਹੋ ਗਿਆ।
ਉਹਨਾਂ ਨੇ ਕਿਹਾ: "ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਪਰ ਨਰਸਾਂ ਅਪੌਇੰਟਮੈਂਟ ਬੁੱਕ ਨਹੀਂ ਕਰਦੀਆਂ। ਬੀਮਾ ਕੋਆਰਡੀਨੇਟਰ (Insurance coordinators) ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਦਾ ਵਰਕਫਲੋ (workflow) ਵੱਖਰਾ ਹੈ।"
ਕਿਸੇ ਨੇ ਝੂਠ ਨਹੀਂ ਬੋਲਿਆ। ਕਿਸੇ ਨੇ ਗਲਤ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੱਤੀ। ਅਸੀਂ ਸਿਰਫ਼ ਇਹ ਪੁੱਛਣ ਵਿੱਚ ਅਸਫਲ ਰਹੇ ਕਿ ਰੋਜ਼ਾਨਾ ਇਸ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕੌਣ ਕਰੇਗਾ।
ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਕੋਡ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਗਲਤ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ। ਸਭ ਤੋਂ ਮਾੜਾ ਕੋਡ ਉਹ ਨਹੀਂ ਹੈ ਜੋ ਕ੍ਰੈਸ਼ (crash) ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਹ ਕੋਡ ਹੈ ਜੋ ਬਿਲਕੁਲ ਸਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਦਾ।
ਇੱਥੇ ਸਾਡੀਆਂ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਗਲਤੀਆਂ ਹਨ:
- ਯੂਜ਼ਰ ਪਰਸੋਨਾ (user persona) ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ। ਅਸੀਂ ਯੂਜ਼ਰ ਦੀ ਬਜਾਏ ਫੈਸਲਾ ਲੈਣ ਵਾਲੇ (decision maker) ਲਈ ਬਣਾਇਆ।
- ਮਨਜ਼ੂਰੀ ਨੂੰ ਸਹੀ ਹੋਣ ਨਾਲ ਮਿਲਾ ਦੇਣਾ। ਕਲਾਇੰਟ ਦਾ "ਹਾਂ" ਕਹਿਣਾ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਉਤਪਾਦ ਸਹੀ ਹੈ।
- ਮਨਜ਼ੂਰੀ ਨੂੰ ਬਚਾਅ ਵਜੋਂ ਵਰਤਣਾ। ਜੇਕਰ ਤੁਸੀਂ ਆਪਣਾ ਕੰਮ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦੇ ਜਿਸਦਾ ਤੁਸੀਂ ਸਤਿਕਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਲਾਇੰਟ ਦੀ ਮਨਜ਼ੂਰੀ ਨੂੰ ਢਾਲ ਵਜੋਂ ਨਾ ਵਰਤੋ।
- ਡਿਪਲਾਈਮੈਂਟ (deployment) ਨੂੰ ਫਿਨਿਸ਼ ਲਾਈਨ ਮੰਨਣਾ। ਸਫਲਤਾ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਮਿਲਦੀ ਹੈ।
ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਜਾਵੇ:
ਜਦੋਂ ਤੁਸੀਂ ਅਸਹਿਮਤ ਹੋਵੋ ਤਾਂ ਸਪੱਸ਼ਟ ਹੋਵੋ। ਕਲਾਇੰਟ ਨੂੰ ਕਹੋ: "ਅਸੀਂ ਇਹ ਇਸ ਲਈ ਬਣਾਵਾਂਗੇ ਕਿਉਂਕਿ ਤੁਸੀਂ ਮੰਗਿਆ ਹੈ। ਪਰ ਸਾਡਾ ਮੰਨਣਾ ਹੈ ਕਿ X ਕਾਰਨ Y ਹੋਵੇਗਾ। ਆਓ ਅਸੀਂ ਇਸਨੂੰ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰ ਲਈਏ।"
ਇਹ ਵਾਕ ਬਾਅਦ ਵਿੱਚ ਦੋਸ਼ ਲਗਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਡਿਪਲਾਈਮੈਂਟ ਨੂੰ ਅੰਤ ਮੰਨਣਾ ਬੰਦ ਕਰੋ। ਤੁਹਾਨੂੰ ਐਰਰ ਟ੍ਰੈਕਿੰਗ (error tracking), ਅਪਟਾਈਮ ਅਲਰਟ (uptime alerts), ਅਤੇ ਐਰ ਰੇਟ ਅਤੇ ਲੇਟੈਂਸੀ (latency) ਲਈ ਇੱਕ ਸਿੰਗਲ ਡੈਸ਼ਬੋਰਡ ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਆਪਣੇ ਭਵਿੱਖ ਦੇ ਆਪ ਲਈ ਦਸਤਾਵੇਜ਼ (documentation) ਦੀ ਵੀ ਲੋੜ ਹੈ।
ਤੁਹਾਡੀ ਟੀਮ ਕਿਹੜੀ ਗਲਤੀ ਵਾਰ-ਵਾਰ ਕਰਦੀ ਹੈ?