03 ਮਾਰਚ 2026·8 ਮਿੰਟ
ਐਪ ਬਣਾਉਂਦੇ ਸਮੇਂ ਹਕੀਕਤੀ ਅਸਧਾਰਣ ਹਾਲਤਾਂ ਨਾਲ ਨਿਪਟਣਾ
ਹਕੀਕਤੀ ਅਸਧਾਰਣ ਹਾਲਤਾਂ ਨੂੰ ਸਮਝਣਾ ਅਸਲੀ ਉਦਾਹਰਨਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਪੇੜ-ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੀਆਂ ਮਨਜ਼ੂਰੀਆਂ, ਗੁੰਮ ਡੇਟਾ ਅਤੇ ਖਾਸ ਮਾਮਲਿਆਂ ਨੂੰ ਐਪ ਲੌਜਿਕ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕੱਠੇ ਕਰੋ।
ਸਾਫ਼ ਐਪ ਫਲੋ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਕਿਉਂ ਫੇਲ ਹੁੰਦੇ ਹਨ
ਇੱਕ ਸਾਫ਼ ਫਲੋਚਾਰਟ ਅਚਛਾ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ فرض ਕਰਦਾ ਹੈ ਕਿ ਲੋਕ ਸਭ ਕੁਝ ਠੀਕ ਕ੍ਰਮ ਵਿਚ, ਸਹੀ ਡੇਟਾ ਨਾਲ, ਉਚਿਤ ਸਮੇਂ 'ਤੇ ਕਰਨਗੇ। ਅਸਲ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਐਦਾ ਨਹੀਂ ਹੋਦਾ। ਕੋਈ ਫਾਰਮ ਦੇਰ ਨਾਲ ਭੇਜਦਾ ਹੈ, ਮੈਨੇਜਰ ਬਿਮਾਰ ਹੈ, ਗਾਹਕ ਕੋਈ ਮੁੱਖ ਜਾਣਕਾਰੀ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਭੁਗਤਾਨ ਨੂੰ ਐਸੀ ਖਾਸ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋਵੇ ਜੋ ਸ਼ੁਰੂ 'ਚ ਕਹੀ ਨਾ ਗਈ ਹੋਵੇ।
ਇਸੇ ਲਈ ਪਹਿਲੀ ਵਰਜਨ ਡੈਮੋ 'ਚ ਪੂਰੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਜਦ ਅਸਲ ਲੋਕ ਵਰਤਣ ਲਗਦੇ ਹਨ ਤਾਂ ਟੁੱਟਣ ਲੱਗਦੀ ਹੈ। ਸੁਖੀ ਰਾਹ (happy path) ਕੰਮ ਕਰਦਾ ਹੈ—ਪਰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਜ਼ਿਆਦਾ ਸਮੇਂ ਸੁਖੀ ਰਾਹ 'ਤੇ ਨਹੀਂ ਰਹਿੰਦਾ।
ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ ਇਹ ਮੰਨ ਕੇ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਸੁੰਦਰ ਸੰસ્કਰਣ ਅਧੂਰਾ ਹੈ। ਛੋਟੀ ਜਿਹੀ ਗਲਤ ਵਸਤੂ ਹੀ ਰਿਕਵੈਸਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਸਕਦੀ ਹੈ। ਇੱਕ ਗੁੰਮ ਫੀਲਡ, ਇੱਕ ਅਜੀਬ ਗਾਹਕ ਜਾਂ ਇੱਕ ਦੇਰ ਨਾਲ ਆਈ ਮਨਜ਼ੂਰੀ ਸਾਰੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਅਗਲਾ ਕਦਮ ਪਤਾ ਨਹੀਂ ਰਹਿੰਦਾ।
ਆਮ ਤੋੜ-ਤੋਪ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ:
- ਇੱਕ ਰਿਕਵੈਸਟ ਅੱਗੇ ਵੱਧਦੀ ਹੈ, ਫਿਰ ਫਸ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਅਨੁਮੋਦਕ ਮੌਜੂਦ ਨਹੀਂ।
- ਇੱਕ ਰਿਕਾਰਡ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਕੋਈ ਲਾਜ਼ਮੀ ਜਾਣਕਾਰੀ ਹਜੇ ਪਤਾ ਨਹੀਂ।
- ਇੱਕ ਖਾਸ ਮਾਮਲਾ ਆਮ ਮਾਮਲੇ ਵਾਂਗ ਕੰਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਗਰੋਂ ਹੱਥੀਂ ਠੀਕ ਕੀਤਾ ਜਾਣਾ ਪੈਂਦਾ ਹੈ।
ਇਹ ਸਿਰਫ਼ ਇਕ ਛੋਟੀ ਤਕਲੀਫ਼ ਨਹੀਂ ਹੈ। ਇੱਕ ਅਜੀਬ ਮਾਮਲਾ ਪਿੱਛੇ ਖੜੇ ਸਭ ਕੁਝ ਰੋਕ ਸਕਦਾ ਹੈ। ਸਟਾਫ਼ ਚੈਟ, ਸਪੀਡਸ਼ੀਟ ਜਾਂ ਈਮੇਲ ਵਿੱਚ ਵਰਕਅਰਾਊਂਡ ਵਰਤਣ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਐਪ ਇਕੱਲੀ ਥਾਂ ਹੋਣ ਦਾ ਕੰਮ ਖੋ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਚੰਗਾ ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਧਾਰਣ ਮਾਮਲੇ ਇਕੱਠੇ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਡੇਟਾ ਗੁੰਮ ਹੋਣ ਤੇ, ਸਮਾਂ ਠੀਕ ਨਾ ਹੋਣ ਤੇ, ਜਾਂ ਜਦ ਰਿਕਵੈਸਟ ਸਧਾਰਨ ਰਾਹ 'ਚ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਗੰਦੇ ਉਦਾਹਰਨ ਸਾਈਡ ਡੀਟੇਲ ਨਹੀਂ—ਇਹ ਹੀ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਐਪ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਕੰਮ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ।
ਪਹਿਲਾਂ ਕਿਹੜੀਆਂ ਅਸਧਾਰਣ ਹਾਲਤਾਂ ਲੱਭਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ
ਪਹਿਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਕਦੇ ਵੀ ਰੇਅਰ ਐਜ ਕੇਸ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਉਹ ਗੰਦੇ ਘਟਨਾ ਹਨ ਜੋ ਹਰ ਹਫ਼ਤੇ ਹੁੰਦੀ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਸੁਥਰੀ ਵਰਕਫਲੋ ਨੂੰ ਖਾਮੋਸ਼ੀ ਨਾਲ ਟੁੱਟਾ ਦੇਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਸੰਸਕਾਰ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਜੀਹਨਾਂ ਥਾਵਾਂ ਨੂੰ ਦਿਖੋ ਜਿੱਥੇ ਕੰਮ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਬਲਾਕ ਹੁੰਦਾ ਹੈ ਜਾਂ ਸਿਸਟਮ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਤੇ ਮਨੁੱਖ ਨੂੰ ਸੌਂਪ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਸੂਚੀ ਵਿੱਚ ਉੱਪਰ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਮੈਨੇਜਰ ਰਿਕਵੈਸਟ ਨੂੰ ਡੇਡਲਾਈਨ ਤੋਂ ਬਾਅਦ, ਪੇਰੋਲ ਕਲੋਜ਼ ਹੋਣ ਤੋਂ ਬਾਅਦ ਜਾਂ ਸਟਾਕ ਝਾੜਨ ਤੋਂ ਬਾਅਦ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ। ਐਪ ਨੂੰ ਉਸ ਪਲ ਲਈ ਨਿਯਮ ਲੋੜੀਦਾ ਹੈ। ਕੀ ਇਹ ਰਿਕਵੈਸਟ ਦੁਬਾਰਾ ਖੋਲ੍ਹੇ, ਨਵਾਂ ਬਣਾਏ, ਫਾਇਨੈਂਸ ਨੂੰ ਸੂਚਿਤ ਕਰੇ, ਜਾਂ ਵਰਤੋਂ ਕਰਦਿਆਂ ਵੇਖੇ ਕਿ ਮਨਜ਼ੂਰੀ ਸਮੇਂ 'ਤੇ ਆਈ ਸੀ—ਝੋਠ ਨਾ ਜਾਪੇ?
ਗੁੰਮ ਡੇਟਾ ਵੀ ਇੱਕ ਆਮ ਰੋਕ ਹੈ। ਇੱਕ ਫਾਰਮ ਟੈਕਸ ID, ਰਸੀਦ, ਡਿਲਿਵਰੀ ਤਾਰੀਖ ਜਾਂ ਗਾਹਕ ਸੰਪਰਕ ਦੇ ਬਿਨਾਂ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਅਗਲਾ ਕਦਮ ਉਸ ਫੀਲਡ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ ਤਾਂ ਫਲੋ ਮੈਟ੍ਰਿਕਸ ਦੀ ਤਰ੍ਹਾਂ ਐਰਰ ਨਾ ਦੇਵੇ। ਇਸਨੂੰ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਗੁੰਮ ਹੈ, ਅਤੇ ਠੀਕ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਖਾਸ ਮਾਮਲੇ ਮਹੱਤਵਪੂਰਣ ਹਨ ਕਿਉਂਕਿ ਉਹ ਆਮ ਰਾਹ ਦੀਆਂ ਹੱਦਾਂ ਨੂੰ ਬਿਆਨ ਕਰਦੇ ਹਨ। ਸ਼ਾਇਦ ਬਹੁਤ ਸਾਰੇ ਰੀਫੰਡ ਸਧਾਰਨ ਹਨ, ਪਰ ਖਾਸ ਰਕਮ ਤੋਂ ਵੱਧ ਰੀਫੰਡ ਲਈ ਵਾਧੂ ਸਬੂਤ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਸ਼ਾਇਦ ਇੱਕ ਵਿਭਾਗ ਵੱਖਰੀ ਮਨਜ਼ੂਰੀ ਨੀਤੀ ਮਾਨਦਾ ਹੋਵੇ। ਇਹ ਮਾਮਲੇ ਪੂਰੀ ਨਵੀਂ ਐਪ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰੱਖਦੇ, ਪਰ ਉਹ ਸਾਫ਼ ਸ਼ਾਖਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਹਨ।
ਇੱਕ ਲਾਭਦਾਇਕ ਪਹਿਲਾ ਪਾਸ ਉਹਨਾਂ ਵਿੱਚੋਂ ਚਾਰ ਪੈਟਰਨ ਵੇਖਣਾ ਹੈ: ਮਨਜ਼ੂਰੀਆਂ ਜੋ ਅਸਲ ਰਾਹ ਨੂੰ ਫਾਲੋ ਕਰਨ ਲਈ ਬਹੁਤ ਦੇਰ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ, ਗੁੰਮ ਵਿਵਰਣ ਜੋ ਅਗਲੇ ਕਦਮ ਨੂੰ ਰੋਕਦੇ ਹਨ, ਅਸਧਾਰਣ ਰਿਕਵੈਸਟ ਜੋ ਵੱਖਰਾ ਨਿਯਮ ਮੰਗਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਪਲ ਜਦ ਸਿਸਟਮ ਨੂੰ ਰੁਕ ਕੇ ਕਿਸੇ ਮਨੁੱਖ ਨੂੰ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ।
ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਫੇਲ੍ਹ ਹੋਣਾ ਨਹੀਂ—ਅਕਸਰ ਜਦ ਸਿਸਟਮ ਟਕਰਾਉਂਦੇ ਡੇਟਾ ਨੂੰ ਵੇਖਦਾ ਹੈ, ਨੀਤੀ ਅਪਵਾਦ ਹੋਵੇ ਜਾਂ ਉੱਚ-ਲਾਗਤ ਕ੍ਰਿਆ ਹੋਵੇ ਤਾਂ ਇਹ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੁੰਦੀ ਹੈ। ਰੁਕੀ ਹੋਈ ਰਿਵਿਊ ਕਿਊ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਖ਼ਾਮੋਸ਼ ਗਲਤੀ ਨਾਲੋਂ ਵਧੀਆ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਅਸਧਾਰਣ ਹਾਲਤਾਂ ਸਵੇਰੇ ਹੀ ਲੱਭ ਲੈਓ ਤਾਂ ਪਹਿਲੀ ਵਰਜਨ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹਕੀਕਤੀ ਅਤੇ ਘੱਟ ਨਰਮ ਹੋਵੇਗੀ।
ਅਸਲ ਉਦਾਹਰਨ ਕਿੱਥੇ ਇਕੱਠੇ ਕਰਣੇ ਚਾਹੀਦੇ ਹਨ
ਗਲਤ ਅਸਧਾਰਣ ਹਾਲਤ ਨੂੰ ਮਿਸ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ਾ ਤਰੀਕਾ ਸਿਰਫ ਉਸ ਮੈਨੇਜਰ ਨੂੰ ਪੁੱਛਣਾ ਹੈ ਜਿਸ ਨੇ ਪ੍ਰਕਿਰਿਆ ਡਿਜ਼ਾਈਨ ਕੀਤੀ। ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਉਸਨਾਂ ਲੋਕਾਂ ਕੋਲ ਰਹਿੰਦੀਆਂ ਹਨ ਜੋ ਹਰ ਰੋਜ਼ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਕਦਮ ਛੱਡੇ ਜਾਂਦੇ ਹਨ, ਕਿਹੜੇ ਫੀਲਡ ਅਕਸਰ ਖਾਲੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਦੇਰ ਨਾਲ, ਕ੍ਰਮ ਬਾਹਰ ਜਾਂ ਸਿਸਟਮ ਦੇ ਬਾਹਰ ਹੁੰਦੀਆਂ ਹਨ।
ਛੋਟੀਆਂ ਗੱਲਬਾਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਆਮ ਕੇਸ ਬਿਆਨ ਕਰਨ ਲਈ ਕਹੋ, ਫਿਰ ਪੁੱਛੋ ਜਦ ਮੁੱਦੇ ਹੋਏ ਤਾਂ ਓਹ ਕੀ ਹੋਇਆ ਸੀ। ਵਿਸ਼ਾਲ ਰਾਏ ਨਾ ਪੁੱਛੋ—ਸੱਚੀਆਂ ਕਹਾਣੀਆਂ ਮੰਗੋ: ਕੀ ਹੋਇਆ, ਕੀ ਗੁੰਮ ਸੀ, ਕਿਸ ਨੇ ਠੀਕ ਕੀਤਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਹੱਥੋਂ ਕੀ ਕੀਤਾ।
ਪੁਰਾਣਾ ਕੰਮ ਵੀ ਇੱਕ ਵਧੀਆ ਸੋਰਸ ਹੈ। ਪਿਛਲੇ ਈਮੇਲ, ਸਪੋਰਟ ਟਿਕਟ, ਚੈਟ ਸੰਦੇਸ਼ ਅਤੇ ਹੈਂਡਆਫ਼ ਨੋਟ ਅਕਸਰ ਉਹ ਸਹੀ ਪਲ ਦਿਖਾਉਂਦੇ ਹਨ ਜਦ ਇੱਕ ਸੁਥਰੀ ਫਲੋ ਟੁੱਟੀ ਸੀ। ਇਹ ਰਿਕਾਰਡ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਸ ਭਾਸ਼ਾ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਜੋ ਲੋਕ ਗਲਤ ਹੋਣ 'ਤੇ ਵਰਤਦੇ ਹਨ, ਨਾ ਕਿ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ ਦਾ ਪੋਲਿਸ਼ ਕੀਤਾ ਹੋਇਆ ਵਰਜਨ।
ਲੋਕਾਂ ਦੇ ਸਾਇਡ ਟੂਲ ਵੀ ਦੇਖੋ। ਜੇ ਕੋਈ ਸਪੀਡਸ਼ੀਟ, ਚਿਪਕਣ ਵਾਲੀਆਂ ਨੋਟਾਂ ਜਾਂ ਨਿੱਜੀ ਦਸਤਾਵੇਜ਼ ਰੱਖਦਾ ਹੈ ਤਾਂ ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਸਿਗਨਲ ਹੈ। ਵਰਕਅਰਾਊਂਡ ਕਿਸੇ ਕਾਰਨ ਲਈ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ—ਉਹ ਅਕਸਰ ਉਹ ਨਿਯਮ ਬਿਆਨ ਕਰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਦਿਨ ਇੱਕ ਤੋਂ ਲੋੜ ਹੋਣਗੇ।
ਸਭ ਤੋਂ ਵਧੀਆ ਸਰੋਤ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੈਡੋ ਸਿਸਟਮ ਹਨ—ਸਪੀਡਸ਼ੀਟ ਅਤੇ ਨਿੱਜੀ ਚੈੱਕਲਿਸਟ, ਈਮੇਲ ਥ੍ਰੈਡ ਜਿੱਥੇ ਲੋਕ ਗੁੰਮ ਵੇਰਵੇ ਜਾਂ ਮੈਨੂਅਲ ਮਨਜ਼ੂਰੀ ਲਈ ਪੁੱਛਦੇ ਹਨ, ਚੈਟ ਗੱਲਬਾਤ ਜਿੱਥੇ ਤੁਰੰਤ ਠੀਕ ਕਰਨ ਦੀ ਚਰਚਾ ਹੁੰਦੀ ਹੈ, ਸਪੋਰਟ ਟਿਕਟ ਜੋ ਦੇਰ ਜਾਂ ਰੀਜੈਕਟ ਬਾਰੇ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਪਿਛਲੇ ਕੁਝ ਕੇਸ ਜਿਹੜੇ ਗਲਤ ਹੋਏ ਸਨ ਦੀ ਪੂਰੀ ਟਾਈਮਲਾਈਨ।
ਖਾਸ ਕਰਕੇ ਤਾਜ਼ਾ ਫੇਲ ਹੋਏ ਕੇਸ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਉਹ ਪਿਛਲੇ ਸੰਖੇਪਾਂ ਤੋਂ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਘਟਨਾ ਦੀ ਸਹੀ ਕੜੀ ਦਿਖਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪੈਟਰਨ ਲੱਭ ਸਕਦੇ ਹੋ—ਮਨਜ਼ੂਰੀ ਡੇਡਲਾਈਨ ਤੋਂ ਬਾਅਦ ਆਈ, ਗਾਹਕ ਨੇ ਲਾਜ਼ਮੀ ਫ਼ਾਇਲ ਨਹੀਂ ਭੇਜੀ, ਜਾਂ ਕਿਸੇ ਨੇ ਇੱਕ ਖਾਸ ਨਿਯਮ ਵਰਤਿਆ ਜੋ ਕਿਸੇ ਨੇ ਡੌਕਯੂਮੈਂਟ ਨਹੀਂ ਕੀਤਾ।
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰ ਵਿੱਚ ਇੱਕ ਪਹਿਲਾ ਸੰਸਕਾਰ ਸਕੇਚ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਨਿਯਮ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਉਦਾਹਰਨ ਇਕੱਠੀਆਂ ਕਰੋ। ਗੰਦੇ ਕੇਸ ਜਲਦੀ ਹੀ ਦਿਖਾਈ ਦੇਣ 'ਤੇ ਸੁਰੱਖਿਅਤ ਫਲੋ ਬਣਾਉਣਾ ਅਸਾਨ ਹੁੰਦਾ ਹੈ।
ਗੰਦੀ ਕਹਾਣੀਆਂ ਨੂੰ ਐਪ ਲੌਜਿਕ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ
ਇੱਕ ਅਸਲੀ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਨਾਂ ਕਿ ਸਿਧਾਂਤ ਨਾਲ। ਇਸਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖੋ ਜਿਸ ਤਰ੍ਹਾਂ ਕੋਈ ਵਿਅਕਤੀ ਆਪਣੀ ਟੀਮ-ਮੇਟ ਨੂੰ ਸਮਝਾਉਂਦਾ: ਉਹ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸਨ, ਕੀ ਗਲਤ ਹੋਇਆ, ਕਿਸ ਨੇ ਹੱਸਿਆ, ਅਤੇ ਅਖੀਰ ਨੂੰ ਕੀ ਹੋਇਆ।
ਇੱਕ ਗੰਦੀ ਕਹਾਣੀ ਜਿਵੇਂ "ਬੇਨਤੀ ਫਸ ਗਈ ਕਿਉਂਕਿ ਮੈਨੇਜਰ ਛੁੱਟੀ 'ਤੇ ਸੀ, ਫਿਰ ਫਾਇਨੈਂਸ ਨੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਫੀਲਡ ਗੁੰਮ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ" ਇੱਕ ਸਾਫ਼ ਫਲੋਚਾਰਟ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੈ। ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਉਨ੍ਹਾਂ ਬਿੰਦੂਆਂ ਨੂੰ ਜਿੱਥੇ ਐਪ ਆਮਤੌਰ 'ਤੇ ਟੁੱਟਦਾ ਹੈ।
ਕਹਾਣੀ ਤੋਂ ਨਿਯਮ ਤੱਕ
ਹਰ ਕੇਸ ਲਈ ਚਾਰ ਤੱਥ ਕੱਢੋ: ਕੀ ਹੋਇਆ, ਕਿਸ ਨੇ ਫੈਸਲਾ ਲਿਆ, ਉਨ੍ਹਾਂ ਨੇ ਇਹ ਫੈਸਲਾ ਕਿਉਂ ਕੀਤਾ, ਅਤੇ ਐਪ ਅਗਲੇ ਵਿੱਚ ਕੀ ਕਰੇ।
ਇਸ ਨਾਲ ਧਿਆਨ ਬਿਹੇਵਿਯਰ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਸਿਰਫ਼ ਸਕਰੀਨਾਂ 'ਤੇ ਨਹੀਂ। ਮਕਸਦ ਹਰ ਅਜੇਬ ਕੇਸ ਨੂੰ ਪਹਿਲੇ ਦਿਨ 'ਤੇ ਕਵਰ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਮੁੜ ਆਉਣ ਵਾਲੇ ਪੈਟਰਨਾਂ ਨੂੰ ਪਛਾਣਨਾ ਹੈ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਕਹਾਣੀਆਂ ਹੋ ਜਾਨ, ਉਹਨਾਂ ਨੂੰ ਸਮਾਨ ਸਮਝ ਆਉਣ ਵਾਲੀਆਂ ਵਾਲੀਆਂ ਗੁਲ਼ੀਆਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ। ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਬਕੇਟ ਆਪਣਾ ਆਪ ਨਿਕਲ ਆਉਂਦੇ ਹਨ: ਦੇਰ ਨਾਲ ਆਈ ਮਨਜ਼ੂਰੀ, ਗੁੰਮ ਜਾਣਕਾਰੀ, ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਪੁੱਛਿਆ ਗਿਆ, ਡੁਪਲਿਕੇਟ ਰਿਕਵੈਸਟ, ਜਾਂ ਇੱਕ ਨਿਯਮ ਜੋ ਇਕ ਨਿਰਧਾਰਿਤ ਸੀਮਾ ਤੋਂ ਉੱਪਰ ਖਾਸ ਮਨਜ਼ੂਰੀ ਮੰਗਦਾ ਹੈ।
ਫਿਰ ਹਰ ਬਕੇਟ ਨੂੰ ਉਹਨਾਂ ਦਾ ਸਭ ਤੋਂ ਹਲਕਾ ਨਿਯਮ ਦਿਓ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਹ ਨਿਯਮ ਹਰ ਵੇਲੇ ਪੂਰਨ ਆਟੋਮੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ। ਕਈ ਵਾਰ ਸਭ ਤੋਂ ਚੰਗਾ ਨਿਯਮ ਇੱਕ ਚੇਤਾਵਨੀ, ਇੱਕ ਰੋਕ ਜਾਂ ਇੱਕ ਮੈਨੂਅਲ ਰਿਵਿਊ ਕਦਮ ਹੁੰਦਾ ਹੈ।
ਉਦਾਹਰਣ ਲਈ, ਜੇ ਮਨਜ਼ੂਰੀ ਦੇਰ ਨਾਲ ਇਸ ਲਈ ਆ ਰਹੀ ਹੈ ਕਿਉਂਕਿ ਅਨੁਮੋਦਕ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਤਾਂ ਐਪ 24 ਘੰਟਿਆਂ ਬਾਅਦ ਇੱਕ ਰਿਮਾਈਂਡਰ ਭੇਜ ਸਕਦੀ ਹੈ, 48 ਘੰਟਿਆਂ ਬਾਅਦ ਦੁਬਾਰਾ ਅਸਾਈਨ ਕਰ ਸਕਦੀ ਹੈ, ਜਾਂ ਕਿਸੇ ਬੈਕਅੱਪ ਅਨੁਮੋਦਕ ਨੂੰ ਰਿਵਿਊ ਲਈ ਪੁਠਾ ਸਕਦੀ ਹੈ। ਜੇ ਕੋਈ ਜਰੂਰੀ ਫੀਲਡ ਗੁੰਮ ਹੈ ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਸਕੇਚ-ਅਤੇ-ਵਾਪਸ (save-and-return draft) ਹੋ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਕਠੋਰ ਰੋਕ। ਇਸ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਅੱਗੇ ਵੱਧਦੀ ਰਹਿੰਦੀ ਹੈ ਬਿਨਾਂ ਸਮੱਸਿਆ ਨੂੰ ਛੁਪਾਉਣ ਦੇ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲ ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਸਧਾਰਨ-ਭਾਸ਼ਾ ਕੇਸ ਬਹੁਤ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ। ਉਹ ਸਿਸਟਮ ਨੂੰ ਕੁਝ ਠੋਸ ਦੇਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਪਹਿਲੀ ਵਰਕਫਲੋ ਅਸਲ ਫੈਸਲਿਆਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ ਨਾ ਕਿ ਇੱਕ ਸੁਥਰੀ ਪਰ ਅਅਸਲੀ ਅਨੁਮਾਨ 'ਤੇ।
ਅਸਲ ਕੇਸਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ
ਲੌਜਿਕ ਨੂੰ ਲਾਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਦੋ-ਤਿੰਨ ਅਸਲ ਕਹਾਣੀਆਂ ਇਸ 'ਤੇ ਚਲਾਓ। ਕੁਝ ਬੁਨਿਆਦੀ ਸਵਾਲ ਪੁੱਛੋ। ਕੀ ਫਲੋ ਉਹੀ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ ਜੋ ਅਸਲ ਕੇਸ ਨੇ ਦਿੱਤਾ? ਕੀ ਇਹ ਗੁੰਮ ਜਾਣਕਾਰੀ ਹੋਣ 'ਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ? ਕੀ ਇਹ ਜਾਣਦਾ ਹੈ ਕਿ ਕਦੋਂ ਰੋਕਣਾ ਹੈ ਅਤੇ ਕਿਸੇ ਮਨੁੱਖ ਨੂੰ ਪੁੱਛਣਾ ਹੈ?
ਜੇ ਜਵਾਬ ਨਾ ਹੋਵੇ, ਤਾਂ ਤੁਰੰਤ ਜਟਿਲਤਾ ਨਾ ਜੋੜੋ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖੋ। ਸਾਫ਼ ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨਿਯਮਾਂ ਨਾਲੋਂ ਵਧੀਆ ਵਰਕਫਲੋ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ ਜੋ ਕੋਈ ਵੀ ਸਮਝ ਨਾ ਸਕੇ।
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ: ਖਰਚ ਮਨਜ਼ੂਰੀ
Ship and host in one place
ਚੈਟ ਵਿੱਚ ਆਪਣੀ ਐਪ ਬਣਾਓ, ਫਿਰ Koder.ai 'ਤੇ ਡਿਪਲੌਏ ਅਤੇ ਹੋਸਟ ਕਰੋ।
ਸਾਫ਼ ਵਰਜਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਕਰਮਚਾਰੀ $42 ਦੀ ਟੈਕਸੀ ਖਰਚੀ ਦਾਖਲ ਕਰਦਾ ਹੈ। ਉਹ ਤਾਰੀਖ, ਰਕਮ, ਪ੍ਰੋਜੈਕਟ ਦਾ ਨਾਮ ਅਤੇ ਰਸੀਦ ਜੁੜਦਾ ਹੈ। ਉਸ ਦਾ ਮੈਨੇਜਰ ਪੇਰੋਲ ਕਟਆਫ਼ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਾਇਨੈਂਸ ਉਸ ਨੂੰ ਅਗਲੇ ਰੀਅੰਬਰਸਮੈਂਟ ਦੌੜ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰ ਲੈਂਦਾ ਹੈ।
ਉਹ ਰਾਹ ਆਸਾਨੀ ਨਾਲ ਮਾਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਸਾਰੀ ਨੌਕਰੀ ਨਹੀਂ ਹੈ।
ਹੁਣ ਪਹਿਲਾ ਅਸਧਾਰਣ ਜੋੜੋ। ਕਰਮਚਾਰੀ ਸਮੇਂ 'ਤੇ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਪਰ ਮੈਨੇਜਰ ਪੇਰੋਲ ਬੰਦ ਹੋਣ ਤੋਂ ਇੱਕ ਦਿਨ ਬਾਅਦ ਮਨਜ਼ੂਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਐਪ ਨੂੰ ਇਸ ਨੂੰ ਬੇਸੁਰਾ ਤਰੀਕੇ ਨਾਲ ਆਗੇ ਧੱਕਣਾ ਨਹੀਂ ਚਾਹੀਦਾ ਤੇ ਨਾ ਹੀ ਇਸਨੂੰ ਸਹੀ ਨਹੀਂ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਵਧੀਆ ਜਵਾਬ ਹੈ ਕਿ ਰਿਕਵੈਸਟ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਸਥਿਤੀ ਵਿੱਚ ਰੱਖੋ ਜਿਵੇਂ "cutoff ਤੋਂ ਬਾਅਦ ਮਨਜ਼ੂਰ"। ਉਥੋਂ, ਐਪ ਭੁਗਤਾਨ ਨੂੰ ਅਗਲੇ ਪੇਰੋਲ ਚੱਕ ਲਈ ਰੋਕ ਸਕਦੀ ਹੈ, ਕਰਮਚਾਰੀ ਨੂੰ ਨਵੇਂ ਭੁਗਤਾਨ ਦੀ ਤਾਰੀਖ ਬਾਰੇ ਸੂਚਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਕੇਵਲ ਉਸੇ ਹਾਲਤ ਵਿੱਚ ਕੇਸ ਨੂੰ ਫਾਇਨੈਂਸ ਨੂੰ ਰੂਟ ਕਰੇ ਜੇ ਕੰਪਨੀ ਨੀਤੀ ਮੈਨੂਅਲ ਬਾਹਰਲੇ ਭੁਗਤਾਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪ ਨੂੰ ਇੱਕ ਤੋਂ ਵੱਧ ਤਾਰੀਖਾਂ ਸਟੋਰ ਕਰਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸਨੂੰ ਇਹ ਟਰੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਖਰਚ ਕਦੋਂ ਜਮ੍ਹਾਂ ਹੋਇਆ, ਕਦੋਂ ਮਨਜ਼ੂਰ ਹੋਇਆ, ਅਤੇ ਕਿਸ ਕਟਆਫ਼ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ।
ਹੁਣ ਦੂਜਾ ਅਸਧਾਰਣ ਜੋੜੋ। ਕਰਮਚਾਰੀ ਰਸੀਦ ਭੁੱਲ ਗਿਆ, ਇਸ ਲਈ ਮੈਨੇਜਰ ਸਿਰਫ ਵਿਆਖਿਆ ਦੇ ਆਧਾਰ 'ਤੇ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦਾ ਹੈ। ਦੋ ਦਿਨ ਬਾਅਦ ਰਸੀਦ ਆ ਜਾਂਦੀ ਹੈ।
ਜੇ ਐਪ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਣੀ ਹੈ, ਤਾਂ ਕੇਸ ਗਾਇਬ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜਾਂ ਸਫ਼ੇਰੋ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਹ "ਰਸੀਦ ਦੀ ਉਡੀਕ" ਹਾਲਤ ਵਿੱਚ ਚੱਲ ਜਾਵੇ, ਯਾਦ ਦਿਉਂਦਾ ਰਹੇ, ਅਤੇ ਖੁਲਿਆ ਰਹੇ। ਜਦ ਰਸੀਦ ਬਾਅਦ ਵਿੱਚ ਅਪਲੋਡ ਹੁੰਦੀ ਹੈ, ਐਪ ਕੇਸ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹੇ ਅਤੇ ਕੇਵਲ ਉਸ ਕਦਮ ਨੂੰ ਭੇਜੇ ਜਿਸਨੂੰ ਹੋਰ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਫਲੋ ਕੁਝ ਸਧਾਰਨ ਸਥਿਤੀਆਂ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦਾ ਹੈ: submitted, waiting for manager approval, approved after cutoff, on hold for missing receipt, ਅਤੇ reopened for finance review.
ਇਹੀ ਅਸਲ ਅਸਧਾਰਣ ਹੱਲਾਂ ਦਾ ਅਭਿਆਸ ਹੈ। ਐਪ ਸਿਰਫ਼ ਹਾਂ ਜਾਂ ਨਾ ਨਹੀਂ ਫੈਸਲਾ ਕਰ ਰਿਹਾ—ਇਹ ਫੈਸਲਾ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਰੋਕਣਾ, ਰੂਟ ਕਰਨਾ ਜਾਂ ਕੇਸ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਨਾ ਹੈ ਬਿਨਾਂ ਸੰਦਰਭ, ਤਾਰੀਖਾਂ ਜਾਂ ਜਿੰਮੇਵਾਰੀ ਗੁਆਉਣ ਦੇ।
ਗੁੰਮ ਡੇਟਾ ਨੂੰ ਬਿਨਾਂ ਫਲੋ ਟੁੱਟੇ ਕਿਵੇਂ ਸਾਂਭਣਾ
ਗੁੰਮ ਜਾਣਕਾਰੀ ਆਮ ਗੱਲ ਹੈ, ਰੇਅਰ ਐਜ ਕੇਸ ਨਹੀਂ। ਜੇ ਤੁਹਾਡੀ ਐਪ فرض ਕਰਦੀ ਹੈ ਕਿ ਹਰ ਫਾਰਮ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਪੂਰਾ ਹੋਵੇਗਾ, ਤਾਂ ਜਦ ਅਸਲ ਯੂਜ਼ਰ ਖਾਲੀ ਜਗ੍ਹਾ ਮਿਲੇਗਾ ਤਾਂ ਫਲੋ ਰੁਕ ਜਾਵੇਗਾ। ਇੱਕ ਬਿਹਤਰ ਨਿਯਮ ਸਧਾਰਨ ਹੈ: ਸਿਰਫ਼ ਉਸੇ ਚੀਜ਼ ਦੀ ਲੋੜ ਰੱਖੋ ਜੋ ਅਗਲੇ ਕਦਮ ਲਈ ਲਾਜ਼ਮੀ ਹੈ।
ਇਸ ਨੂੰ ਕਦਮ ਦਰ ਕਦਮ ਯੋਜਨਾ ਬਣਾਓ। ਪੁੱਛੋ ਕਿ ਐਪ ਨੂੰ ਹੁਣ ਕੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੀ ਬਾਅਦ 'ਤੇ ਠਹਿਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਖਰਚ ਬੇਨਤੀ ਲਈ ਰਕਮ ਅਤੇ ਕਰਮਚਾਰੀ ਦਾ ਨਾਮ ਜਮ੍ਹਾਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਜ਼ਮੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਅਖੀਰਲੀ ਰਸੀਦ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਚਾਹੀਦੀ ਹੋਵੇ। ਇਸ ਨਾਲ ਕੰਮ ਚੱਲਦਾ ਰਹੇ ਬਿਨਾਂ ਨਿਯੰਤਰਣ ਘਟਾਉਣ ਦੇ।
ਅਧੂਰੇ ਕੰਮ ਨੂੰ ਦਿੱਖਯੋਗ ਬਣਾਓ
ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੁਝ ਵੇਰਵਾ ਗੁੰਮ ਹੋਣ 'ਤੇ ਵੀ ਪ੍ਰਗਤੀ ਸੇਵ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਡ੍ਰਾਫਟ ਜੋ ਦੁਬਾਰਾ کھੋਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਸ ਫਾਰਮ ਨਾਲੋਂ ਬਹੁਤ ਖ਼ੁਸ਼ਗਵਾਰ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਮੁੜ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਜਦ ਗੁੰਮ ਜਾਣਕਾਰੀ ਕਿਸੇ ਹੋਰ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ, ਜਿਵੇਂ ਮੈਨੇਜਰ, ਵੀੰਡਰ ਜਾਂ ਫਾਇਨੈਂਸ ਟੀਮ।
ਸਪਸ਼ਟ ਸਥਿਤੀਆਂ ਸਭ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਆਸਾਨ ਸਕੈਨ ਕਰਨ ਯੋਗ ਰੱਖੋ: waiting for info, blocked by missing document, needs review, ready for approval, sent back for update.
ਇਹ ਲੇਬਲ ਦੁਇ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਿਖਾਉਂਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਹੈ।
ਹਰ ਗੁੰਮ ਆਈਟਮ ਲਈ ਇੱਕ ਮਾਲਿਕ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਟੈਕਸ ID ਗੁੰਮ ਹੈ, ਤਾਂ ਕੌਣ ਇਸਨੂੰ ਜੋੜੇਗਾ? ਜੇ ਰਸੀਦ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਕੌਣ ਉਸਨੂੰ ਬਦਲੇਗਾ? ਜਦ ਕੋਈ ਮਨਜ਼ੂਰੀ ਨੋਟ ਮੌਜੂਦ ਨਹੀਂ, ਤਾਂ ਕੌਣ ਉਸਨੂੰ ਦੇ ਸਕਦਾ ਹੈ? ਜਦ ਤੱਕ ਕੋਈ ਮਾਲਿਕ ਨਹੀਂ ਹੁੰਦਾ, ਰਿਕਾਰਡ ਲਟਕਦੇ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ ਇਸਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਕਰਮਚਾਰੀ ਇੱਕ ਯਾਤਰਾ ਖਰਚ ਜਮ੍ਹਾਂ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਰਸੀਦ ਦੇ ਕਿਉਂਕਿ ਹੋਟਲ ਨੇ ਹਾਲੇ ਭੇਜੀ ਨਹੀਂ। ਐਪ ਨੂੰ ਫਿਰ ਵੀ ਉਹਨਾਂ ਨੂੰ ਸੇਵ ਅਤੇ ਜਮ੍ਹਾਂ ਕਰਨ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਇੱਕ ਸਥਿਤੀ ਨਾਲ ਜਿਵੇਂ "receipt ਦੀ ਉਡੀਕ"। ਫਾਇਨੈਂਸ ਬਾਕੀ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੀ ਹੈ, ਕਰਮਚਾਰੀ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਕੀ ਗੁੰਮ ਹੈ, ਅਤੇ ਰਿਕਵੈਸਟ ਇੱਕ ਖ਼ਾਮੋਸ਼ ਗਲਤੀ ਵਿੱਚ ਵਿਆਪਨ ਨਾ ਹੋ ਜੇ।
ਕਦੋਂ ਆਟੋਮੇਟ ਕਰੋ ਅਤੇ ਕਦੋਂ ਮਨੁੱਖ ਨੂੰ ਪੂਝੋ
Keep your options open
ਹੋਰਨ ਤੇਜ਼ ਬਣੋ ਅਤੇ ਜਦ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।
ਆਟੋਮੇਸ਼ਨ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਕੋ ਜਿਹਾ ਇਨਪੁਟ ਹਰ ਵਾਰੀ ਲਗਭਗ ਇਕੋ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ। ਜੇ ਰਿਕਵੈਸਟ ਇੱਕ ਸਾਫ਼ ਪੈਟਰਨ ਫਾਲੋ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਨਿਯਮ ਦਿਓ। ਜੇ ਜਵਾਬ ਗੁੰਮ ਸੰਦਰਭ, ਅਜੀਬ ਸਮਾਂ ਜਾਂ ਫੈਸਲੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਮਨੁੱਖ ਨੂੰ ਭੇਜੋ।
ਉਹ ਵੰਡ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਇੱਕ ਚੰਗੀ ਐਪ ਹੁਣ ਆਮ ਕੇਸਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵੱਲ ਵਧੇਗੀ ਅਤੇ ਅਸਪਸ਼ਟ ਕੇਸਾਂ 'ਤੇ ਰੁਕ ਜਾਵੇਗੀ। ਗਲਤ ਆਟੋਮੈਟਿਕ ਫੈਸਲਾ ਛੋਟੀ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਤੋਂ ਵੱਧ ਕੰਮ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਮਦਦਗਾਰ ਹੈ: ਕੀ ਦੋ ਵੱਖ-ਵੱਖ ਟੀਮ ਮੈਂਬਰ ਇਕੋ ਡੇਟਾ ਤੋਂ ਇਕੋ ਫੈਸਲਾ ਬਣਾਉਂਦੇ? ਜੇ ਹਾਂ, ਤਾਂ ਆਟੋਮੈਟ ਕਰੋ। ਜੇ ਨਹੀਂ, ਤਾਂ ਮਨੁੱਖੀ ਹਿੱਸਾ ਰੱਖੋ।
ਚੰਗੇ ਉਮੀਦਵਾਰ ਆਟੋਮੇਸ਼ਨ ਲਈ ਪੂਰੇ ਫਾਰਮ, ਨੀਤੀ ਸੀਮਾਵਾਂ ਨਾਲ ਮਿਲਦੇ ਰਿਕਵੈਸਟ, ਸਪੱਸ਼ਟ ਡੈੱਡਲਾਈਨ ਵਾਲੀਆਂ ਦੁਹਰਾਈਆਂ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਉਹ ਮਨਜ਼ੂਰੀਆਂ ਜੋ ਹਮੇਸ਼ਾ ਇਕੋ ਰਾਹ ਫਾਲੋ ਕਰਦੀਆਂ ਹਨ।
ਕੁਝ ਸਥਿਤੀਆਂ ਨੂੰ ਬਿਲਕੁਲ ਅਨੁਮਾਨ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ: ਜਰੂਰੀ ਵੇਰਵੇ ਗੁੰਮ ਹਨ, ਰਿਕਵੈਸਟ ਆਮ ਪੈਟਰਨ ਤੋੰ ਭੇਦ ਕਰਦੀ ਹੈ, ਦੋ ਨਿਯਮ ਟਕਰਾਂਦੇ ਹਨ, ਖ਼ਰਚ ਜਾਂ ਖਤਰਾ ਵੱਡਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਨੂੰ ਅਪਵਾਦ ਸਮਝਾਉਣਾ ਪੈਂਦਾ ਹੈ।
ਇੱਕ ਯਾਤਰਾ ਰਿਕਵੈਸਟ ਸੋਚੋ ਜਿਸ ਵਿੱਚ ਮਾਂਜ਼ਿਲ ਨਹੀ, ਇਕ ਤਤਕਾਲੀ ਤਾਰੀਖ ਹੈ, ਅਤੇ ਰਕਮ ਆਮ ਸੀਮਾ ਤੋਂ ਵੱਧ। ਐਪ ਨੂੰ ਚਤੁਰ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ—ਇਸਨੂੰ ਕੇਸ ਨੂੰ ਠੱਠਾ ਕਰਕੇ ਸਹੀ ਵਿਅਕਤੀ ਕੋਲ ਰੂਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇੋ ਹੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਹਰ ਅਪਵਾਦ ਦਾ ਕਾਰਨ ਦਿਖਾਈ ਦੇਵੇ। ਦਿਖਾਓ ਕਿ ਐਪ ਕਿਉਂ ਰੁਕਿਆ, ਕਿਹੜਾ ਨਿਯਮ ਟ੍ਰਿਗਰ ਹੋਇਆ, ਅਤੇ ਕੀ ਜਾਣਕਾਰੀ ਗੁੰਮ ਹੈ। ਇਸ ਨਾਲ ਸਮੀਖਿਆ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਟੀਮ ਭਵਿੱਖ ਵਿੱਚ ਵਰਕਫਲੋ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੀ ਹੈ।
ਆਮ ਗਲਤੀਆਂ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ
ਬਹੁਤ ਸਾਰੀ ਐਪ ਪ੍ਰੋਜੈਕਟ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਟੀਮ ਇੱਕ ਸਾਫ਼ ਰਾਹ ਡਰਾਫਟ ਕਰਦੀ ਹੈ, فرض ਕਰਦੀ ਹੈ ਕਿ ਲੋਕ ਇਸਨੂੰ ਮੰਨਣਗੇ, ਅਤੇ ਹਰ ਹਫ਼ਤੇ ਹੋਣ ਵਾਲੀਆਂ ਅਜੀਬ ਗੱਲਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹੀ ਢੰਗ ਹੈ ਕਿ ਸਧਾਰਨ ਵਰਕਫਲੋ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਹੱਥੋ-ਹੱਥ ਠੀਕ ਕਰਨ ਅਤੇ ਉਲਝਣ ਵਾਲੇ ਯੂਜ਼ਰ ਬਣ ਜਾਂਦੇ ਹਨ।
ਪਹਿਲੀ ਗਲਤੀ ਅਨੁਮਾਨਾਂ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਮਨਜ਼ੂਰੀਆਂ, ਗੁੰਮ ਫੀਲਡ ਜਾਂ ਅਪਵਾਦਾਂ ਬਾਰੇ ਅਨੁਮਾਨ ਕਰੋਗੇ ਤਾਂ ਤੁਸੀਂ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਕੇਸਾਂ ਨੂੰ ਮਿਸ ਕਰ ਦੇਵੋਗੇ। ਇੱਕ ਮੈਨੇਜਰ ਦੇਰ ਨਾਲ ਮਨਜ਼ੂਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਇੱਕ ਗਾਹਕ ਰਿਕਾਰਡ ਅਧੂਰਾ ਆਉਂਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਭੁਗਤਾਨ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਰਿਵਿਊ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਰਕਮ ਅਸਧਾਰਣ ਹੈ।
ਦੂਜੀ ਗਲਤੀ ਬਹੁਤ ਸਾਰਿਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਇੱਕ ਧੁੰਦਲੇ ਨਿਯਮ ਵਿੱਚ ਲੁਕਾਉਣਾ ਹੈ। "ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਐਡਮਿਨ ਨੂੰ ਭੇਜੋ" ਵਰਗਾ ਨਿਯਮ ਲਚਕੀਲਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਐਡਮਿਨ ਕੌਣ ਹੈ? ਕੀ ਗਲਤ ਗਿਣਿਆ ਜਾਵੇ? ਜੇ ਕੋਈ ਦੋ ਦਿਨ ਤੱਕ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
ਇਹ ਉਸ ਵਕਤ ਵੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ ਜਦ ਐਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇੱਕ ਅਨੁਮੋਦਕ ਕਦਮ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਲੋਕਾਂ ਨੂੰ ਹਰ ਚੀਜ਼ ਮੁੜ ਦਰਜ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਚੰਗਾ ਫਲੋ ਪ੍ਰਗਤੀ ਸੇਵ ਕਰਦਾ, ਮੁੱਦੇ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ, ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕੇਵਲ ਬਲਾਕਡ ਹਿੱਸਾ ਠੀਕ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਅਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦੂਰੀਵੇਂ ਮਾਲੀਨੇ ਜਾਣ ਲੱਗਦੀਆਂ ਹਨ: ਸਮਾਂ, ਮਲਕੀਅਤ ਅਤੇ ਇਤਿਹਾਸ। ਇਹ ਸੈਕੰਡਰੀ ਨਹੀਂ ਹਨ। ਜੇ ਮਨਜ਼ੂਰੀ ਡੇਡਲਾਈਨ ਤੋਂ ਬਾਅਦ ਆਉਂਦੀ ਹੈ ਤਾਂ ਐਪ ਨੂੰ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ, ਇਸਨੂੰ ਐਸਕਲੇਟ ਕਰਨਾ ਹੈ, ਜਾਂ ਦੇ ਰਿਕਵੈਸਟ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣਾ ਹੈ। ਜੇ ਕੇਸ ਰੁਕਿਆ ਹੈ, ਤਾਂ ਕਿਸੇ ਨੂੰ ਅਗਲਾ ਕਦਮ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਸਥਿਤੀ ਬਦਲਦੀ ਹੈ ਤਾਂ ਲੋਕਾਂ ਨੂੰ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਅਤੇ ਕਿਉਂ ਬਦਲਿਆ।
ਆਡੀਟ ਇਤਿਹਾਸ ਸਿਧੇ ਕਾਰਨਾਂ ਲਈ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਜਾਣਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਕਿਸ ਮੁੱਲ ਨੂੰ ਬਦਲਿਆ, ਕਿਸਨੇ ਅਪਵਾਦ ਮਨਜ਼ੂਰ ਕੀਤਾ, ਅਤੇ ਕਦੋਂ ਸਥਿਤੀ ਬਦਲੀ।
ਲੌਜਿਕ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈਕ
Iterate without losing progress
ਜਦ ਨਿਯਮ ਬਦਲਦੇ ਹਨ ਤਾਂ ਆਪਣੀ ਐਪ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਕਿਸੇ ਵਰਕਫਲੋ ਨੂੰ ਨਿਯਮ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਅਤੇ ਚੈੱਕ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਇਨਪੁੱਟ ਅਸਲ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਸਾਫ਼ ਡਾਇਗ੍ਰਾਮ ਅਕਸਰ ਉਹ ਅਜੀਬ ਕੇਸ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਦੇਰ, ਉਲਝਣ, ਜਾਂ ਮੈਨੂਅਲ ਠੀਕ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ।
ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ ਮਦਦ ਕਰਦੀ ਹੈ:
- ਅਨੁਮਾਨਾਂ ਨਹੀਂ, ਅਸਲ ਉਦਾਹਰਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
- ਹਰ ਅਪਵਾਦ ਨੂੰ ਇੱਕ ਛੋਟੀ ਵਾਕ ਵਿੱਚ ਨਾਮ ਦਿਓ।
- ਰੁਕੇ ਹੋਏ ਕੇਸਾਂ ਦਾ ਮਾਲਿਕ ਨਿਰਧਾਰਤ ਕਰੋ।
- ਯੂਜ਼ਰ ਕਿਵੇਂ ਗੁੰਮ ਜਾਣਕਾਰੀ ਤੋਂ ਮੁਕਤ ਹੋ ਸਕਦੇ ਹਨ, ਇਹ ਚੈਕ ਕਰੋ।
- ਇੱਕ ਵਿਅਵਹਾਰਕ ਦ੍ਰਿਸ਼ ਭਰ ਤੋਂ ਅੰਤ ਤੱਕ ਟੈਸਟ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਕੇਸ ਅਕਸਰ ਕਮਜ਼ੋਰ ਲੌਜਿਕ ਨੂੰ ਬਾਹਰ ਲਿਆਉਂਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਇੱਕ ਖਰੀਦ ਰਿਕਵੈਸਟ ਸਪਲਾਇਰ ਨਾਮ ਦੇ ਬਿਨਾਂ ਜਮ੍ਹਾਂ ਕੀਤਾ ਗਿਆ, ਫਿਰ ਡੀਪਾਰਟਮੈਂਟ ਲੀਡ ਨੇ ਦੇਰ ਨਾਲ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ। ਕੀ ਬੇਨਤੀਕਾਰ ਗੁੰਮ ਫੀਲਡ ਸਹੀ ਕਰ ਸਕਦਾ ਹੈ? ਕੀ ਐਪ ਜਾਣਦਾ ਹੈ ਕਿ ਰਿਕਵੈਸਟ ਮੁੜ ਖੋਲ੍ਹਨੀ ਹੈ, ਜਾਰੀ ਰੱਖਣੀ ਹੈ, ਜਾਂ ਫਾਇਨੈਂਸ ਨੂੰ ਰਿਵਿਊ ਲਈ ਦੇਣੀ ਹੈ?
ਇਹੋ ਵੀਹ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਲੌਜਿਕ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਹੁੰਦੇ ਹੋ। ਛੋਟੀਆਂ, ਅਸਲ ਕਹਾਣੀਆਂ ਸੁਰੱਖਿਅਤ ਪਹਿਲੀਆਂ ਵਰਜਨਾਂ ਅਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ ਲਈ ਮਦਦਗਾਰ ਹੁੰਦੀਆਂ ਹਨ।
ਸੁਰੱਖਿਅਤ ਪਹਿਲੀ ਵਰਜਨ ਲਈ ਅਗਲੇ ਕਦਮ
ਛੋਟੇ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਵਰਕਫਲੋ ਚੁਣੋ, ਪੂਰੇ ਬਿਜਨਸ ਨੂੰ ਨਹੀਂ। ਫਿਰ ਉਹਨਾਂ ਲੋਕਾਂ ਕੋਲੋਂ ਪੰਜ ਅਸਲ ਅਪਵਾਦ ਕੇਸ ਇਕੱਠੇ ਕਰੋ ਜੋ ਹਰ ਰੋਜ਼ ਕੰਮ ਕਰਦੇ ਹਨ—ਜਿਵੇਂ ਦੇਰ ਨਾਲ ਆਈ ਮਨਜ਼ੂਰੀ, ਗੁੰਮ ਰਸੀਦ, ਮੈਨੇਜਰ ਛੁੱਟੀ 'ਤੇ ਹੋਣਾ, ਡੁਪਲਿਕੇਟ ਰਿਕਵੈਸਟ, ਜਾਂ ਇਕ ਕੇਸ ਜਿਸਨੂੰ ਫਾਇਨੈਂਸ ਦੇ ਦਖਲ ਦੀ ਲੋੜ ਪਈ।
ਉਸ ਨਿਯਮ ਅਤੇ ਪੰਜ ਕੇਸਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਪਹਿਲਾ ਸੰਸਕਾਰ ਬਣਾਓ। ਨਿਯਮ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਰੱਖੋ। ਜੇ ਰਿਕਵੈਸਟ ਅਧੂਰਾ ਹੈ ਤਾਂ ਦਿਖਾਓ ਕਿ ਕੀ ਗੁੰਮ ਹੈ। ਜੇ ਮਨਜ਼ੂਰੀ ਦੇਰ ਨਾਲ ਆਈ ਹੈ ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਦੋਂ ਯਾਦ ਦਿਵਾਈਏ, ਕਦੋਂ ਐਸਕਲੇਟ ਕਰੀਏ, ਅਤੇ ਕਦੋਂ ਰੋਕਣਾ ਹੈ। ਜੇ ਕੇਸ ਆਮ ਰਾਹ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ ਤਾਂ ਸਾਫ਼ ਦਿਖਾਓ ਕਿ ਕੌਣ ਸਮੀਖਿਆ ਕਰੇਗਾ।
ਫਿਰ ਇਸਨੂੰ ਉਹਨਾਂ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜੋ ਸ਼ਾਮਿਲ ਹਨ: ਰਿਕਵੈਸਟ ਦੇਣ ਵਾਲਾ, ਪਹਿਲਾ ਅਨੁਮੋਦਕ, ਉਹ ਵਿਅਕਤੀ ਜੋ ਅਪਵਾਦ ਠੀਕ ਕਰਦਾ, ਐਸਕਲੇਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਮੈਨੇਜਰ, ਅਤੇ ਜੋ ਵੀ ਅੰਤਿਮ ਨਤੀਜਾ ਵੇਖਦਾ ਹੈ।
ਘੁਰਦੇ ਕਰੋ ਕਿ ਓਥੇ ਕਿੱਥੇ ਉਹ ਰੁਕਦੇ ਹਨ, ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੇ ਹਨ, ਜਾਂ ਮਦਦ ਮੰਗਦੇ ਹਨ। ਇਹ ਲਮ੍ਹੇ ਸੁਚਾਰੂ ਕੰਮ ਕਰਨ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੇ ਹਨ। ਜੇ ਤਿੰਨ ਲੋਕ ਇੱਕੋ ਹੀ ਕਦਮ 'ਤੇ ਫਸੀ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਨਿਯਮ ਜਾਂ ਸਕਰੀਨ ਨੂੰ ਬਦਲਣਾ ਲੋੜੀਂਦਾ ਹੈ।
ਇੱਕ ਖਰਚ ਐਪ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਟੈਕਸੀ ਰਸੀਦ ਪ੍ਰੋਜੈਕਟ ਕੋਡ ਦੇ ਬਿਨਾਂ ਜਮ੍ਹਾਂ ਨਾ ਕਰੇ ਜਾਂ ਮਹੀਨਾਵਾਰ ਕਟਆਫ਼ ਤੋਂ ਬਾਅਦ ਨਾ ਭੇਜੇ। ਤੁਹਾਡੀ ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਹਰ ਦਰ ਜਾਂ ਘੱਟ ਹੀ ਕੇਸਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ—ਇਸਨੂੰ ਆਮ ਅਪਵਾਦ ਪਕੜਨੇ, ਅਗਲਾ ਕਦਮ ਸਮਝਾਉਣੇ ਅਤੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਈ ਸਾਫ ਰਾਹ ਛੱਡਣੀ ਚਾਹੀਦੀ ਹੈ।
ਫਿਰ ਨਿਯਮਾਂ ਨੂੰ ਛੋਟੇ ਰਾਊਂਡਾਂ ਵਿੱਚ ਬਦਲੋ। ਉਹ ਕਦਮ ਹਟਾਓ ਜੋ ਉਲਝਨ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਕੇਵਲ ਉਹ ਫੀਲਡ ਜੋ ਵਾਰ-ਵਾਰ ਦੀ ਸਮੱਸਿਆ ਰੋਕਦੇ ਹਨ, ਜੋੜੋ। ਜੇ ਯਾਦ ਦਿਓਂ ਵਾਲਾ ਸਮਾਂ ਬਹੁਤ ਜਲਦੀ ਜਾਂ ਜ਼ਿਆਦਾ ਦੇਰ ਹੈ ਤਾਂ ਸਮਾਂ ਬਦਲੋ। ਅਸਲ ਟੈਸਟਿੰਗ ਤੋਂ ਬਾਅਦ ਹੋਏ ਛੋਟੇ ਸੁਧਾਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਜਟਿਲ ਖਾਸ-ਮਾਮਲਾ ਲੌਜਿਕ ਨੂੰ ਜਲਦ ਸ਼ਾਮਿਲ ਕਰਨ ਨਾਲੋਂ ਵਧੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ ਪਰੋਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ Koder.ai ਵਰਗਾ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਇਹ ਅਸਲ ਉਦਾਹਰਨ ਲੈ ਕੇ ਕਦਮ-ਦਰ-ਕਦਮ ਇੱਕ ਕੰਮ ਕਰਨ ਯੋਗ ਐਪ ਬਣਾ ਸਕੇ। ਕੁੰਜੀ ਇਹੀ ਹੈ: ਪਹਿਲਾਂ ਗੰਦੇ ਕੇਸਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਨ੍ਹਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਯਮ ਬਣਾਓ।