ਅਸਲ ਯੂਜ਼ਰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਜਨਰੇਟਿਡ ਐਡਮਿਨ ਪੈਨਲ ਦੀਆਂ ਖਾਮੀਆਂ

ਡੈਮੋ ਚੰਮਕਣ ਦੇ ਬਾਵਜੂਦ ਕੰਮ ਜਲਦੀ ਮੁਕੰਮਲ ਕਿਉਂ ਨਹੀਂ ਲੱਗਦਾ

ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਐਡਮਿਨ ਪੈਨਲ ਅਕਸਰ ਰੀਅਲ ਵਰਕ ਲਈ ਤਿਆਰ ਹੋਣ ਤੋਂ ਕਾਫ਼ੀ ਪਹਿਲਾਂ ਹੀ "ਮੁਕੰਮਲ" ਦਿਸ ਸਕਦਾ ਹੈ।

ਡੈਮੋ ਵਿੱਚ ਕੋਈ ਇੱਕ ਰਿਕਾਰਡ ਖੋਲ੍ਹਦਾ ਹੈ, ਇੱਕ ਫੀਲਡ ਬਦਲਦਾ ਹੈ, ਸੇਵ ਕਰਦਾ ਹੈ — ਤੇ ਸਭ ਕੁਝ ਨਰਮ ਲੱਗਦਾ ਹੈ। ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਟੀਮਾਂ ਇੰਝ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ। ਉਹ ਇਕੋ ਵਾਰ 20 ਰਿਕਾਰਡ ਸਹੀ ਕਰਦੀਆਂ ਹਨ, ਲੰਚ ਤੋਂ ਪਹਿਲਾਂ ਕਿਊ ਦੁਬਾਰਾ ਅਸਾਈਨ ਕਰਦੇ ਹਨ, ਫਾਇਨੈਂਸ ਲਈ ਰਿਪੋਰਟ ਏਕਸਪੋਰਟ ਕਰਦੇ ਹਨ ਅਤੇ ਦੇਖਦੇ ਹਨ ਕਿਸਨੇ ਕਲ ਗਾਹਕ ਦੀ ਸਥਿਤੀ badਲੀ ਸੀ।

ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਖਾਮੀ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਇੱਕ ਸਕਰੀਨ ਚਲਦੀ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਕੰਮ ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ।

ਮੁੱਦਾ ਬੁਰੇ ਡਿਜ਼ਾਈਨ ਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਮਸਲਾ ਇਹ ਹੈ ਕਿ ਡੈਮੋ ਵਿਖਾਈ ਦੇਣ ਵਾਲੀ ਪ੍ਰਗਟੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਦੈਨੀਕ ਕੰਮ ਦੁਹਰਾਈ, ਗਤੀ ਅਤੇ ਭਰੋਸੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਯੂਜ਼ਰ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀ ਕਰਦੇ ਕਿ ਟੇਬਲ ਲੋਡ ਹੁੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ; ਉਹ ਇਸ ਗੱਲ ਦੀਆਂ ਫਿਕਰਾਂ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਬਿਨਾਂ ਵਾਧੂ ਕਲਿੱਕਾਂ, ਨੋਟਸ ਜਾਂ ਇੰਜਨੀਅਰਿੰਗ ਦੀ ਮਦਦ ਤੋਂ ਆਪਣੇ ਰੁਟੀਨ ਟਾਸਕ ਖ਼ਤਮ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।

ਛੋਟੀ ਖਾਮੀਆਂ ਵੱਡੇ ਖ਼ਰਚੇ ਪੈਦਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਜੇ ਕਰਮਚਾਰੀ ਜ਼ਿਆਦਾ ਆਈਟਮ ਇੱਕ ਵਾਰ ਵਿੱਚ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਉਹ ਹੱਥੋਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਜੇ ਫਿਲਟਰ ਕਮਜ਼ੋਰ ਹਨ ਤਾਂ ਉਹ ਟੇਬਲ ਵਿੱਚ ਵਕਫ਼ ਲੱਭਦੇ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਏਕਸਪੋਰਟ ਗੜਬੜ ਹਨ ਤਾਂ ਹਫਤੇ ਡਾਟਾ ਸਾਫ਼ ਕਰਨ ਲਈ ਕੋਈ ਨੌਕਰ ਰਹਿ ਜਾਂਦਾ ਹੈ। ਜੇ ਕੋਈ ਇਤਿਹਾਸ ਨਹੀਂ ਹੈ ਤਾਂ ਹਰ ਗਲਤੀ ਇੱਕ ਜਾਂਚ ਬਣ ਜਾਂਦੀ ਹੈ।

ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਏ ਗਏ ਟੂਲਾਂ ਵਿੱਚ ਆਮ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ ਬਣਾਇਆ ਗਿਆ ਐਡਮਿਨ ਪੈਨਲ। ਗਤੀ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਹੈ, ਪਰ ਇਹ ਖੁਸ਼ ਰਸਤਾ ਜ਼ਿਆਦਾ ਮੁਕੰਮਲ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਚਲਦੀ ਸਕਰੀਨ ਕੰਮ ਕਰ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦੀ।

ਉਹ ਪਹਿਲੀਆਂ ਚਾਰ ਖਾਮੀਆਂ ਜੋ ਯੂਜ਼ਰ ਨੋਟਿਸ ਕਰਦੇ ਹਨ

ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਜ਼ਿਆਦਾਤਰ ਸ਼ਿਕਾਇਤਾਂ ਉਹੀ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ।

ਯੂਜ਼ਰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਇੱਕ-ਇੱਕ ਰਿਕਾਰਡ ਨਿਭਾਉਂਦੇ ਨਹੀਂ। ਉਹ ਬੈਚਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ, ਹਰ ਰੋਜ਼ ਉਹੀ ਕਿਊਜ਼ ਦੋਹਰਾਉਂਦੇ, ਹੋਰ ਟੀਮਾਂ ਨਾਲ ਡਾਟਾ ਸਾਂਝਾ ਕਰਦੇ ਅਤੇ ਦੇਖਣ ਲਈ ਸਬੂਤ ਚਾਹੀਦੇ। ਇਸ ਲਈ ਪਹਿਲੀਆਂ ਮੰਗਾਂ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਚੀਜ਼ਾਂ ਦੇ ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ: ਬਲਕ ਐਕਸ਼ਨ, ਫਿਲਟਰ, ਏਕਸਪੋਰਟ ਅਤੇ ਆਡੀਟ ਹਿਸਟਰੀ।

ਬਲਕ ਐਕਸ਼ਨ

ਸਭ ਤੋਂ ਪਹਿਲਾ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਕੀ ਮੈਂ ਇਹ ਸਾਰਾ ਇੱਕ ਵਾਰ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?

ਇਸਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਸਥਿਤੀ ਬਦਲਣਾ, ਮਾਲਕ ਅਸਾਈਨ ਕਰਨਾ, ਰਿਕਾਰਡਾਂ 'ਤੇ ਟੈਗ ਲਗਾਉਣਾ ਜਾਂ ਪੁਰਾਣੀਆਂ ਐਨਟਰੀਆਂ ਨੂੰ ਆਰਕੀਵ ਕਰਨਾ। ਬਿਨਾਂ ਬਲਕ ਐਕਸ਼ਨਾਂ ਦੇ ਉਹ ਕੰਮ ਜੋ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਹੋ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਹ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਕਲਿੱਕਾਂ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਹ ਸੁਸਤ, ਨਿਰਸ ਅਤੇ ਗਲਤ ਹੋਣਾ ਆਸਾਨ ਹੈ।

ਫਿਲਟਰ ਅਤੇ ਸੇਵਡ ਵਿਊਜ਼

ਵੱਡੀ ਟੇਬਲ ਤਦ ਹੀ ਲਾਭਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਉਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਸਕਦੇ ਹਨ। ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਫਿਲਟਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ ਕਿ ਸਥਿਤੀ, ਮਾਲਕ, ਤਾਰੀਖ ਰੇਂਜ, ਖੇਤਰ ਜਾਂ ਪ੍ਰਾਇਰਿਟੀ। ਉਹਨਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਉਹੀ ਸੈਟਅਪ ਵਾਪਸ ਲੈਣ ਦੀ ਭੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। "ਅੱਜ ਜਵਾਬ ਦੀ ਲੋੜ" ਜਾਂ "ਇਹ ਹਫਤਾ ਲਈ ਪੈਂਡਿੰਗ ਆਰਡਰ" ਵਰਗਾ ਸੇਵਡ ਵਿਊਜ਼ ਇੱਕ ਹੋਰ ਡੈਸ਼ਬੋਰਡ ਵਿਜ਼ੈੱਟ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ।

ਏਕਸਪੋਰਟ

ਡਾਟਾ ਜਦੋਂ ਵੀ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ, ਲੋਕ ਫਿਰ ਵੀ ਉਸਨੂੰ ਬਾਹਰ ਲਿਜਾਣ ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਫਾਇਨੈਂਸ ਇੱਕ CSV ਚਾਹੁੰਦਾ ਹੈ। ਸਪੋਰਟ ਗਾਹਕਾਂ ਨੂੰ ਰਿਪੋਰਟ ਭੇਜਦਾ ਹੈ। ਓਪਰੇਸ਼ਨਜ਼ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਿੱਚ ਰਿਕਾਰਡ ਰਿਵਿਊ ਕਰਦਾ ਹੈ। ਜੇ ਏਕਸਪੋਰਟ ਮੌਜੂਦ ਨਹੀਂ ਜਾਂ ਗੜਬੜ ਹੈ, ਯੂਜ਼ਰ ਹੱਥ ਨਾਲ ਕਾਪੀ-पੇਸਟ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ।

ਆਡੀਟ ਹਿਸਟਰੀ

ਜਿਵੇਂ ਹੀ ਕੁਝ ਗਲਤ ਲੱਗਦਾ ਹੈ, ਲੋਕ ਦੋ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ: ਇਹ ਕਿਸਨੇ ਬਦਲਿਆ ਅਤੇ ਕਦੋਂ?

ਆਡੀਟ ਹਿਸਟਰੀ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਟੀਮਾਂ ਨੂੰ ਗਲਤੀਆਂ ਪਿਛੇ ਲੈ ਜਾਣ, ਫੈਸਲਿਆਂ ਨੂੰ ਸਮਝਾਉਣ ਅਤੇ ਸਪੋਰਟ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਬਿਨਾਂ ਡਿਵੈਲਪਰ ਨੂੰ ਕਾਲ ਕੀਤੇ।

ਇਹ ਚਾਰ ਖਾਮੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਇਹ ਡੈਮੋ ਕੰਮ ਨਹੀਂ ਪਰ ਅਸਲ ਕੰਮ ਦਰਸਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਸੁਥਰੀ ਟੇਬਲ ਅਤੇ ਇੱਕ ਸੰਪਾਦਨ ਫਾਰਮ ਸਿਰਫ ਸ਼ੁਰੂਆਤ ਹਨ।

ਸਕਰੀਨ ਤੋਂ ਪਹਿਲਾਂ ਕੰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਨੂੰ ਇਕ ਪਾਸੇ ਰੱਖ ਕੇ ਪਿੱਛੇ ਖਰੇ ਕੰਮ ਨੂੰ ਦੇਖੋ।

ਲੋਕ ਹਰ ਰੋਜ਼ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ? ਹੁਣ ਉਹਨਾਂ ਨੂੰ ਕੀ ਰੋਕਦਾ ਹੈ? ਕਿਹੜੇ ਕਾਰਜ ਕਦੇ-ਕਦੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਹਰ ਸਵੇਰੇ ਬਿਨਾਂ ਫੇਲ ਹੋਏ ਹੁੰਦੇ ਹਨ?

ਕੌਂਕਰੀਟ ਟਾਸਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਧੁੰਦਲੇ ਲਕਸ਼ਾਂ ਨਾਲ ਨਹੀਂ। "ਰਿਫੰਡ ਦੀ ਮਨਜ਼ੂਰੀ" ਵਰਗਾ ਟਾਸਕ ਵਰਤੋਂਯੋਗ ਹੈ। "ਡਾਟਾ ਸੁਧਾਰੋ" ਨਹੀਂ। "ਫਾਇਨੈਂਸ ਲਈ ਹਫਤੇਵਾਰ ਰਿਪੋਰਟ ਏਕਸਪੋਰਟ ਕਰੋ" ਵਰਗਾ ਟੀਚਾ ਵਧੀਆ ਹੈ।

ਫਿਰ ਉਹਨਾਂ ਟਾਸਕਾਂ ਨੂੰ ਦੋ ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡੋ: ਇੱਕ-ਇੱਕ ਵਾਲਾ ਕੰਮ ਅਤੇ ਬੈਚ ਕੰਮ। ਜੇ ਕੋਈ ਹਰ ਸਵੇਰੇ ਦਸ ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਦਸ ਵੱਖ-ਵੱਖ ਸੰਪਾਦਨ ਦੀ ਲੋੜ ਨਹੀਂ — ਉਨ੍ਹਾਂ ਨੂੰ ਬਲਕ ਐਕਸ਼ਨ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਕੋਈ ਹੋਰ ਟਾਸਕ ਕਦੇ-ਕਦੇ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ ਤਾਂ ਇੱਕ ਇਕੱਲਾ ਰਿਕਾਰਡ ਫਲੋ ਪਰਯਾਪਤ ਹੋ ਸਕਦਾ ਹੈ।

ਫਿਰ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਲੋਕਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੀ ਲੱਭਣਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਐਡਮਿਨ ਪੀਰਦਾਨਕਾਁਜ਼ਾਨ ਦੀ ਪੀੜ ਹੈ ਖਰਾਬ ਸਰਚ ਅਤੇ ਗੈਰ ਮੌਜੂਦ ਫਿਲਟਰਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਪੁੱਛੋ ਕਿ ਯੂਜ਼ਰ ਕਿਹੜੇ ਫੀਲਡਾਂ 'ਤੇ ਖੋਜ ਕਰਦੇ ਹਨ, ਕਿਹੜੀਆਂ ਸਥਿਤੀਆਂ ਉਹਨਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਕਿਹੜੀ ਤਾਰੀਖ ਰੇਂਜ ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਵਿਊਜ਼ ਉਹ ਹਰ ਰੋਜ਼ ਦੁਹਰਾਉਂਦੇ ਹਨ।

ਇੱਕ ਛੋਟਾ ਯੋਜਨਾਬੱਧ ਚੈੱਕ ਸਹਾਇਕ ਹੈ:

• ਹਰ ਹਫਤੇ ਸਭ ਤੋਂ ਆਮ ਐਡਮਿਨ ਟਾਸਕ ਕੀ ਹਨ?
• ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਬੈਚ ਵਿੱਚ ਹੁੰਦੇ ਹਨ?
• ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਿਹੜੇ ਡਾਟਾ ਨੂੰ ਖੋਜਨਾ, ਫਿਲਟਰ ਕਰਨਾ ਅਤੇ ਏਕਸਪੋਰਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ?
• ਕਿਹੜੇ ਕਾਰਜਾਂ ਲਈ ਇੱਕ ਦਿੱਖ ਵਹੀਵਟ ਹਿਸਟਰੀ ਚਾਹੀਦੀ ਹੈ?

ਆਡੀਟ ਹਿਸਟਰੀ ਨੂੰ ਇੱਕ ਬੋਨੱਸ ਫੀਚਰ ਸਮਝਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਪੈਸਾ, ਐਕਸੈੱਸ, ਗਾਹਕ ਦੀ ਸਥਿਤੀ ਜਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਲੋਕਨੂੰ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਸਾਫ਼ ਟਰੇਲ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

ਇੱਕ ਹੋਰ ਅਹੰਕਾਰਪੂਰਣ ਕਦਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਟਾਸਕ ਲਿਸਟ ਨੂੰ ਕਿਸੇ ਅਸਲ ਓਪਰੇਟਰ ਨਾਲ ਰਿਵਿਊ ਕਰੋ। ਨਾ ਕਿ ਮੈਨੇਜਰ ਜੋ ਯਾਦ ਤੋਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ, ਨਾ ਹੀ ਫਾਊਂਡਰ ਜੋ ਹਰ ਸ਼ਾਰਟਕੱਟ ਜਾਣਦਾ ਹੈ। ਉਹ ਓਪਰੇਟਰ ਜੋ ਘੰਟਿਆਂ ਪੈਨਲ ਵਿੱਚ ਬਿਤਾਂਉਂਦਾ ਹੈ, ਉਹ ਹੀ ਉਹ ਘਟਕਾ ਵੇਖੇਗਾ ਜੋ ਡੈਮੋ ਛੁਪਾ ਰਿਹਾ ਹੈ।

ਬਲਕ ਐਕਸ਼ਨ ਅਸਲ ਆਦਤਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਚਾਹੀਦੇ ਹਨ

ਇੱਕ ਚੰਗਾ ਬਲਕ ਐਕਸ਼ਨ ਸਿਰਫ ਇੱਕ ਚेकਲਿਸਟ ਫੀਚਰ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਉਹੀ ਕੰਮ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਟੀਮ ਵਾਸਤਵ ਵਿੱਚ ਕਰਦੀ ਹੈ।

ਸਪੋਰਟ ਟੀਮਾਂ ਟਿਕਟਾਂ ਨੂੰ ਬੈਚਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਅਸਾਈਨ ਕਰਦੀਆਂ ਹਨ। ਓਪਰੇਸ਼ਨਜ਼ ਹਰ ਸ਼ੁੱਕਰਵਾਰ ਪੁਰਾਣੀਆਂ ਮੰਗਾਂ ਨੂੰ ਬੰਦ ਕਰਦਾ ਹੈ। ਸੇਲਜ਼ ਓਪਸ ਟੇਰਿਟਰੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਮਾਲਕ ਫੀਲਡ ਅਪਡੇਟ ਕਰਦੇ ਹਨ। ਜੇ ਪੈਨਲ ਉਹਨਾਂ ਸਹੀ ਫ਼ਲੋਅਜ਼ ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਲਾਭਦਾਇਕ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।

ਸਭ ਤੋਂ ਆਮ ਬਲਕ ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਆਮਤੌਰ 'ਤੇ ਇਹ ਹਨ:

• ਚੁਣੀਆਂ ਹੋਈਆਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਟੀਮ ਦੇ ਕਿਸੇ ਮੈਂਬਰ ਨੂੰ ਅਸਾਈਨ ਕਰੋ
• ਬਹੁਤ ਸਾਰੀਆਂ ਆਈਟਮਾਂ ਲਈ ਸਥਿਤੀ ਬਦਲੋ
• ਐਕਟਿਵ ਨਾ ਰਹਿਣ ਵਾਲੇ ਰਿਕਾਰਡ ਆਰਕਾਈਵ ਕਰੋ
• ਹਟਾਉਣ (ਡਿਲੀਟ) ਸਿਰਫ਼ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀਕਰਨ ਨਾਲ

ਆਖਰੀ ਗੱਲ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਬਲਕ ਬਦਲਾਅ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਘਬਰਾ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਨਤੀਜਾ ਉਲਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਖਤਰਨਾਕ ਕਾਰਜ ਦਿਖਾਉਣੇ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿੰਨੇ ਰੋਜ਼ ਚੁਣੇ ਗਏ ਹਨ ਅਤੇ ਬਿਲਕੁਲ ਕੀ ਬਦਲੇਗਾ। "48 ਆਰਡਰ ਆਰਕਾਈਵ ਕਰੋ" ਇੱਕ ਬਟਨ ਲੇਬਲ "ਅੱਪਡੇਟ" ਤੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੈ।

ਜੇ ਕਾਰਵਾਈ ਨਾਸ਼ਕ ਹੈ ਤਾਂ ਪੁਸ਼ਟੀ ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਛੋਟੀ ਊਨਡੂ ਵਿੰਡੋ ਜਾਂ ਕਾਇਮਨਾਮੇ (soft) ਵਿਕਲਪ ਦਿਓ ਜਿਵੇਂ ਕਿ ਸਥਾਈ ਹਟਾਉਣ ਦੀ ਥਾਂ ਆਰਕਾਈਵ।

ਉਦੇਸ਼ ਹਰ ਸੰਭਵ ਬੜੀ ਸੰਪਾਦਨਾ ਨੂੰ ਸਹਾਇਕ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਮਨੋਰਥ ਇਹ ਹੈ ਕਿ ਕੁਝ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਟਾਸਕਾਂ ਨੂੰ ਕਵਰ ਕੀਤਾ ਜਾਏ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣਯੋਗ ਅਤੇ ਠੀਕ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਐਪ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਸਮੇਂ ਉਹਨਾਂ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਲੋਕ ਆਹਿਸਤਾ ਵਰਜਨ ਨੂੰ ਆਦਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੈਟ ਕਰਨਾ ਅਸਾਨ ਹੁੰਦਾ ਹੈ।

ਫਿਲਟਰ, ਸਰਚ ਅਤੇ ਸੇਵਡ ਵਿਊਜ਼ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦਾ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਨਿਭਾਉਂਦੇ ਹਨ

ਬਹੁਤ ਸਾਰੇ ਐਡਮਿਨ ਪੈਨਲ ਲਿਸਟ ਪੇਜ਼ 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।

ਡਾਟਾ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਫਿਰ ਵੀ ਸਧਾਰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਸਕਦੇ। "ਮੈਨੂੰ ਐਲੈਕਸ ਦੇ ਨਜਦੀਕੀ ਓਵਰਡਿਊ ਟਾਸਕ ਦਿਖਾਓ۔" "ਪਿਛਲੇ ਸ਼ੁੱਕਰਵਾਰ ਬਣਾਏ ਆਰਡਰ ਲੱਭੋ।" "ਉਹ ਆਈਟਮ ਖੋਲ੍ਹੋ ਜੋ ਮੈਂ ਹਰ ਰੋਜ਼ ਰਿਵਿਊ ਕਰਦਾ ਹਾਂ।" ਜੇ ਪੇਜ਼ ਇਨ੍ਹਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਕੁਝ ਕਲਿੱਕਾਂ ਵਿੱਚ ਸਹਾਰਾ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਇਸਨੂੰ ਅਧੂਰਾ ਮਹਿਸੂਸ ਕੀਤਾ ਜਾਵੇਗਾ, ਭਾਵੇਂ ਇਹ ਸੋਹਣਾ ਦਿਸੇ।

ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਫਿਲਟਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਕਈ ਟੀਮਾਂ ਵਿੱਚ ਇਹਦਾ ਮਤਲਬ ਹੈ ਸਥਿਤੀ, ਮਾਲਕ, ਤਾਰੀਖ ਰੇਂਜ ਅਤੇ ਪ੍ਰਾਇਰਿਟੀ। ਇਹ ਸਪੱਸ਼ਟ ਅਤੇ ਆਸਾਨ ਰੀਸੈੱਟ ਕਰਨ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਲੋਕਾਂ ਨੂੰ ਟੇਬਲ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਲਈ ਮੀਨੂਜ਼ ਵਿੱਚ ਖੋਜਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਸਰਚ ਵੀ ਬੇਹੱਦ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਇਸਨੂੰ ਸੁਝਾ, ਖੁਲਾ ਅਤੇ ਆਸਾਨ ਰੱਖੋ ਅਤੇ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਇਹ ਕੀ ਖੋਜਦਾ ਹੈ। ਨਾਮਾਂ, ਆਈਡੀਜ਼, ਈਮੇਲ ਪਤੇ ਜਾਂ ਸਿਰਲੇਖਾਂ 'ਤੇ ਚੱਲਣ ਵਾਲੀ ਇੱਕ ਸਧਾਰਨ ਸਰਚ ਅਕਸਰ ਇੱਕ ਕਠੋਰ ਅਤੇ ਭੁੱਲ ਜਾਂਦੀ ਚੋਣਾਂ ਨਾਲ ਭਰੇ ਸ਼ੁਰੂਆਤੀ ਸਰਚ ਪੈਨਲ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ।

ਸੇਵਡ ਵਿਊਜ਼ ਦੁਹਰਾਏ ਕੰਮ ਨੂੰ ਕਾਫੀ ਹੱਦ ਤੱਕ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਸਪੋਰਟ ਲੀਡ "ਇਸ ਹਫਤੇ ਉੱਚ ਪ੍ਰਾਇਰਿਟੀ ਟਿਕਟ" ਕਾਇਮ ਰੱਖ ਸਕਦਾ ਹੈ। ਇੱਕ ਓਪਰੇਸ਼ਨਜ਼ ਮੈਨੇਜਰ "ਸੈਮ ਨੂੰ ਅਸਾਈਨ ਕੀਤੇ ਪੈਂਡਿੰਗ ਆਰਡਰ" ਰੱਖ ਸਕਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਇੱਕ ਵਾਰੀ ਇਹ ਸੇਵ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਇੱਕ ਕਲਿੱਕ ਵਿੱਚ ਵਾਪਸ ਆ ਸਕਦੇ ਹਨ ਤਾਂ ਐਡਮਿਨ ਪੈਨਲ ਅਦਤਾਂ ਨੂੰ ਸਹੈਤਾ ਦੇਣ ਲੱਗਦਾ ਹੈ ਨਾ ਕਿ ਹਰ ਰੋਜ਼ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਸੇਵਡ ਵਿਊਜ਼ ਆਮਤੌਰ 'ਤੇ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਯਾਦ ਰੱਖਣ 'ਤੇ ਚੰਗੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:

• ਚੁਣੇ ਹੋਏ ਫਿਲਟਰ
• ਸੋਰਟ ਆਰਡਰ
• ਦਿੱਖਣ ਵਾਲੇ ਕਾਲਮ
• ਤਾਰੀਖ ਰੇਂਜ

ਉਹੋ ਹੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਕਰੀਨ ਸਰਗਰਮ ਫਿਲਟਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਏ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਦੇ ਵੀ ਹੈਰਾਨ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਕਿ ਉਹ 12 ਨਤੀਜੇ ਕਿਉਂ ਦੇਖ ਰਹੇ ਹਨ ਨਾ ਕਿ 200। ਇੱਕ ਛੋਟੀ ਸੰਖੇਪ, ਦਿਖਣਯੋਗ ਫਿਲਟਰ ਚਿਪਸ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਰੀਸੈੱਟ ਕਾਰਵਾਈ ਕਾਫ਼ੀ ਉਲਝਣਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ।

ਏਕਸਪੋਰਟ ਐਪ ਤੋਂ ਬਾਹਰ ਵੀ ਵਰਕ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ

ਏਕਸਪੋਰਟ ਆਮ ਤੌਰ 'ਤੇ ਡੈਮੋ ਵਿੱਚ ਠੀਕ ਲੱਗਦੇ ਹਨ ਪਰ ਜਿਵੇਂ ਹੀ ਫਾਇਲ ਖੁੱਲਦੀ ਹੈ ਲੋਕ ਨਿਰਾਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ।

ਮਸਲਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਏਕਸਪੋਰਟ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਮਸਲਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਫਾਇਲ ਵਰਤਣ ਯੋਗ ਨਹੀਂ। ਕਾਲਮ ਨਾਮ ਧੁੰਦਲੇ ਹਨ। ਤਾਰੀਆਂ ਅਸਮਰਥਿਤ ਰੂਪ ਵਿੱਚ ਹਨ। ਸਥਿਤੀਆਂ ਅੰਦਰੂਨੀ ਲੇਬਲ ਵਰਤਦੀਆਂ ਹਨ। ਜ਼ਰੂਰੀ ਫੀਲਡ ਮੌਜੂਦ ਨਹੀਂ। ਨਤੀਜਾ ਇੱਕ ਐਸਾ CSV ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਵੀ ਅਸਲ ਕੰਮ ਲਈ ਹੱਥੋਂ ਸਾਫ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਵਧੀਆ ਏਕਸਪੋਰਟ ਉਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਭੀੜੀ ਪੜ੍ਹਾਈ ਦੇ ਬਿਨਾਂ ਵੀ ਅਰਥ ਰੱਖੇ। ਸਥਾਪਤ ਕਾਲਮ ਨਾਮ, ਪੜ੍ਹੇ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਤਾਰੀਖਾਂ, ਸਾਦੇ ਲੇਬਲ ਅਤੇ ਉਹ ਫੀਲਡ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਚਾਹੁੰਦੇ ਹਨ। ਫਾਇਨੈਂਸ, ਸਪੋਰਟ ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਇੱਕੋ ਸੋਰਸ ਟੇਬਲ ਵਰਤ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਏਕਸਪੋਰਟ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਅਚ্ছে ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ: ਫਾਇਲ ਖੋਲ੍ਹੋ ਅਤੇ ਪੁੱਛੋ, ਕੀ ਕੋਈ ਵਿਅਕਤੀ ਬਿਨਾਂ ਵਾਧੂ ਸੰਦਰਭ ਦੇ ਇਸਨੂੰ ਸਮਝ ਸਕਦਾ ਹੈ? ਜੇ ਨਹੀਂ, ਤਾਂ ਏਕਸਪੋਰਟ ਨੂੰ ਹੋਰ ਕੰਮ ਦੀ ਲੋੜ ਹੈ।

ਉਹ ਫੀਲਡਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਅਸਲ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। ਉਹ ਕਾਲਮ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਲਨਾ ਕਰਦੀਆਂ ਹਨ। ਨਾਮ, ਈਮੇਲ, ਟੋਟਲ ਅਤੇ ਸਥਿਤੀਆਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਰੱਖੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਫਿਲਟਰ ਏਕਸਪੋਰਟ ਵਿੱਚ ਲੱਗੇ ਰਹਿੰਦੇ ਹਨ ਤਾਂ ਲੋਕ ਫਾਇਲ ਨੂੰ ਹੱਥੋਂ ਸਾਫ਼ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਨਾ ਹੋਣ।

ਯੂਜ਼ਰ ਜੇ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਹੀ ਏਕਸਪੋਰਟ ਮੰਗਦੇ ਹਨ, ਤਾਂ ਉਹ ਕਿਸੇ ਅਲਿਸ਼ਾਨ ਫੀਚਰ ਵਾਸਤੇ ਨਹੀਂ ਮੰਗ ਰਹੇ। ਉਹ ਤੁਹਾਨੂੰ ਦੱਸ ਰਹੇ ਹਨ ਕਿ ਉਤਪਾਦ ਕਿੱਥੇ ਅਸਹਾਇਕ ਹੋ ਰਿਹਾ ਹੈ।

ਆਡੀਟ ਹਿਸਟਰੀ ਸਪੋਰਟ ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਸੰਭਾਲ ਕੇ ਰੱਖਦੀ ਹੈ

ਜਦੋਂ ਕੁਝ ਅਣਉਮੀਦ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ, ਟੀਮਾਂ ਨੂੰ ਫਟਾਫਟ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ।

ਉਪਯੋਗੀ ਆਡੀਟ ਹਿਸਟਰੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਸਨੇ ਬਦਲਿਆ, ਕਦੋਂ ਹੋਇਆ, ਕੀ ਬਦਲਿਆ ਅਤੇ ਪਛਲਾ ਮੁੱਲ ਕੀ ਸੀ। ਇਹ ਗੁੰਝਲਦਾਰ ਡਾਟਾਬੇਸ ਐਕਸੈਸ, ਅਨੁਮਾਨ ਜਾਂ ਗੱਲਬਾਤ ਨੂੰ ਨਹੀਂ ਮੰਗਦੀ।

ਹਿਸਟਰੀ ਨੂੰ ਸਕੈਨ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਕਟਰ, ਟਾਈਮਸਟੈਮਪ, ਕਾਰਵਾਈ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡਾਂ ਲਈ ਪਹਿਲਾਂ-ਅਤੇ-ਬਾਅਦ ਵਾਲੇ ਮੁੱਲ ਦਿੱਖਾਓ। ਜੇ ਕਿਸੇ ਨੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ active ਤੋਂ paused ਕੀਤਾ ਜਾਂ ਸ਼ਿਪਿੰਗ ਪਤਾ ਸੰਪਾਦਿਤ ਕੀਤਾ, ਤਾਂ ਇੱਕ ਨਜ਼ਰ ਨਾਲ ਪੁਸ਼ਟੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇਸ ਨੂੰ ਸੀਮਿਤਤਾ ਦੀ ਵੀ ਲੋੜ ਹੈ। ਹਰ ਚੀਜ਼ ਨੂੰ ਲਾਗਿੰਗ ਕਰਨ ਨਾਲ ਸ਼ੋਰ ਬਣ ਜਾਵੇਗਾ। ਜੇ ਪੇਜ਼ ਪਿਛੋਕੜ ਘਟਨਾਵਾਂ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਕੋਈ ਮਹੱਤਤਾ ਨਹੀਂ, ਤਾਂ ਅਹੰਕਾਰਕ ਬਦਲਾਅ ਗੁਮ ਹੋ ਜਾਂਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਸੰਪਾਦਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਖਾਸ ਕਰਕੇ ਉਹ ਜਿਹੜੇ ਸਪੋਰਟ, ਬਿਲਿੰਗ, ਅਧਿਕਾਰਾਂ ਜਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਸਮੱਗਰੀ ਨਾਲ ਜੁੜੇ ਹਨ।

ਛੋਟੀਆਂ ਟੀਮਾਂ ਇਹ ਘਪਲਾ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ। ਕੋਈ ਗਾਹਕ ਕਹਿੰਦਾ ਹੈ, "ਮੇਰੇ ਆਰਡਰ ਦੀ ਸਥਿਤੀ ਕੱਲ੍ਹ ਬਦਲੀ ਸੀ।" ਇੱਕ ਸਪੋਰਟ ਸਹਿ-ਕਰਮੀ ਨੂੰ ਰਿਕਾਰਡ ਖੋਲ੍ਹ ਕੇ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਿਨਾਂ ਇਸ ਹਿਸਟਰੀ ਦੇ ਟੀਮ ਅਜ਼ਮਾਇਸ਼ਾਂ 'ਤੇ ਉਪਹੁਂਚਣ ਲੱਗ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਛੋਟੀ ਟੀਮ ਦਾ ਸਧਾਰਣ ਉਦਾਹਰਨ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਛੋਟੀ ਕੰਪਨੀ ਗਾਹਕ ਪੋਰਟਲ ਲਾਂਚ ਕਰ ਰਹੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇਕ ਬੁਨਿਆਦੀ ਸਪੋਰਟ ਡੈਸ਼ਬੋਰਡ ਹੈ।

ਡੈਮੋ ਵਧੀਆ ਦਿਸਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਟਿਕਟ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ, ਉਸਦੀ ਸਥਿਤੀ ਬਦਲ ਸਕਦੇ ਹੋ ਅਤੇ ਨਾਮ ਨਾਲ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਤਾਂ ਮੁਕੰਮਲ ਦਿਸਦਾ ਹੈ ਜਦ ਤੱਕ ਪਹਿਲਾ ਬਿਜੀ ਹਫ਼ਤਾ ਨਹੀਂ ਆਉਂਦਾ।

ਸੋਮਵਾਰ ਨੂੰ, ਸਪੋਰਟ ਲੀਡ ਪਾਉਂਦਾ ਹੈ ਕਿ 40 ਖੁਲੇ ਟਿਕਟ ਇਕ ਸਹਿ-ਕਰਮੀ ਨੂੰ ਅਸਾਈਨ ਹਨ ਜੋ ਬਿਮਾਰ ਹੈ। ਇੱਕ-ਇੱਕ ਕਰਕੇ ਰੀਅਸਾਈਨ ਕਰਨਾ ਸੁਸਤ ਅਤੇ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਜਿਹੜੀ ਚੀਜ਼ ਉਨ੍ਹਾਂ ਨੂੰ ਚਾਹੀਦੀ ਹੈ ਉਹ ਸਧਾਰਨ ਹੈ: ਸਹੀ ਕਿਊ ਫਿਲਟਰ ਕਰੋ, ਰਿਕਾਰਡ ਚੁਣੋ ਅਤੇ ਇੱਕ ਕਦਮ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਮੋਵ ਕਰੋ।

ਉਸ ਹਫ਼ਤੇ ਦੇ ਅੰਤ ਵਿੱਚ, ਫਾਇਨੈਂਸ ਮਹੀਨੇ ਦੀ ਰਿਫੰਡ ਕੀਤੀਆਂ ਆਰਡਰਾਂ ਦੀ ਏਕਸਪੋਰਟ ਮੰਗਦਾ ਹੈ। ਉਹ ਸਿਸਟਮ ਦੇ ਹਰ ਆਰਡਰ ਨੂੰ ਨਹੀਂ ਚਾਹੁੰਦਾ ਅਤੇ ਨਾ ਹੀ ਇੱਕ ਰਾਵ ਡੈਟਾਬੇਸ ਡੰਪ। ਉਹ ਇੱਕ ਸਾਫ਼ ਫਾਇਲ ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਤਾਰੀਖ ਰੇਂਜ, ਭੁਗਤਾਨ ਸਥਿਤੀ ਅਤੇ ਖੇਤਰ ਨਾਲ ਫਿਲਟਰ ਕੀਤੀ ਹੋਈ ਹੋਵੇ।

ਫਿਰ ਇੱਕ ਮੈਨੇਜਰ ਨੋਟਿਸ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਗਾਹਕ ਨੂੰ ਅਣ-ਸਰਗਰਮ ਕੀਤਾ ਗਿਆ ਹੈ ਜਦੋਂਕਿ ਖਾਤਾ ਫਿਰ ਵੀ ਖੁੱਲਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਸੀ। ਅਗਲਾ ਸਵਾਲ ਸਪੇਸ਼ਲ ਹੈ: ਕਿਸਨੇ ਇਹ ਬਦਲਾਅ ਕੀਤਾ ਤੇ ਕਦੋਂ?

ਇਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਰਹਿੰਦੀਆਂ ਹਨ ਤਾਂ ਲੋਕ ਪ੍ਰੋਡਕਟ ਦੇ ਬਜਾਏ ਸਿਸਟਮ ਦੇ ਆਸ-ਪਾਸ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹ ਸਾਈਡ ਸਪੀਡਸ਼ੀਟ ਰੱਖਦੇ, ਇੱਕ-ਵਾਰ ਦੀਆਂ ਏਕਸਪੋਰਟ ਲਈ ਡਿਵੈਲਪਰ ਨੂੰ ਪੁੱਛਦੇ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਸਮਝਾਉਣ ਲਈ ਚੇਟ ਤੇ ਨਿਰਭਰ ਕਰਦੇ। ਪ੍ਰਣਾਲੀ ਹਾਜ਼ਰ ਹੈ, ਪਰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਘੱਟ ਹੋ ਜਾਣ ਲੱਗਦਾ ਹੈ।

ਡੈਮੋ ਵਿੱਚ ਇਹ ਕੋਈ ਨਾਟਕੀ ਚੀਜ਼ ਨਹੀਂ ਲੱਗਦੀ। ਪਰ ਇੱਕ ਛੋਟੀ ਟੀਮ ਲਈ, ਇਹ ਮਾਮੂਲੀ ਕੰਮ ਹਨ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਦੁਬਾਰਾ ਕੰਮ ਪੈਦਾ ਕਰਨੀਆਂ ਹਨ

ਅਧਿਕਤਰ ਐਡਮਿਨ ਪੈਨਲ ਰੀਬਿਲਡ ਇੱਕ ਗਿਣਤੀਯੋਗ ਗਲਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ।

ਪਹਿਲੀ ਗਲਤੀ ਹੈ ਕੇਵਲ ਬਣਾਉਣ ਅਤੇ ਸੰਪਾਦਨ ਸਕਰੀਨਾਂ 'ਤੇ ਰੁਕ ਜਾਣਾ। ਇਹ ਵਾਕਥ੍ਰੂ ਲਈ ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਦਿਨ-ਭਰ ਕਰਨ ਵਾਲੇ ਯੂਜ਼ਰਾਂ ਲਈ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ। ਦੈਨਿਕ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਕਸਰ ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਮਨਜ਼ੂਰ ਕਰਨ, ਮਾਲਕ ਬੈਚਾਂ ਵਿੱਚ ਅਸਾਈਨ ਕਰਨ, ਪੁਰਾਣੀਆਂ ਐਨਟਰੀਆਂ ਆਰਕਾਈਵ ਕਰਨ ਅਤੇ ਉਹੀ ਫਿਲਟਰਡ ਕਿਊਜ਼ਾਂ ਮੁੜ ਮਿਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਕ ਹੋਰ ਗਲਤੀ ਫਿਲਟਰਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਕਲਿੱਕਾਂ ਦੇ ਪਿੱਛੇ ਲੁਕਾਉਣਾ ਹੈ। ਐਡਮਿਨ ਟੂਲ ਲੋਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਉਹ ਤਾਰੀਖ, ਸਥਿਤੀ, ਮਾਲਕ ਜਾਂ ਗਾਹਕ ਦੁਆਰਾ ਜਲਦੀ ਫਿਲਟਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਪੈਨਲ ਸੁਸਤ ਮਹਿਸੂਸ ਹੋਵੇਗਾ ਚਾਹੇ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਤੇਜ਼ ਹੋਵੇ।

ਏਕਸਪੋਰਟ ਦੁਬਾਰਾ ਕੰਮ ਤਦ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਉਹਨਾਂ ਨੂੰ ਰਾਵ ਡੰਪ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ। ਇੱਕ ਫਾਇਲ ਜਿਸ ਵਿਚ ਅਸਪਸ਼ਟ ਕਾਲਮ ਅਤੇ ਮਸ਼ੀਨ-ਮਿੱਤਰ ਮੁੱਲ ਹਨ, ਅਸਲ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਨਹੀਂ ਹੈ। ਹਰ ਹਫਤੇ ਕਿਸੇ ਨੂੰ ਫਾਇਲ ਸਾਫ਼ ਕਰਨੀ ਪਏਗੀ।

ਆਡੀਟ ਹਿਸਟਰੀ ਦੀ ਗੈਰਮੌਜੂਦਗੀ ਇਕ ਹੋਰ ਕਿਸਮ ਦਾ ਖ਼ਰਚ ਬਣਾਉਂਦੀ ਹੈ। ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਲੰਬੀਆਂ ਜਾਂਚਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਕਿ ਕੀ ਬਦਲਿਆ।

ਟੈਸਟਿੰਗ ਵੀ ਅਕਸਰ ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਹੈ। ਫਾਊਂਡਰ ਅਤੇ ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ ਆਮ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਨੂੰ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹਨ। ਉਹ ਅਸਾਨੀ ਨਾਲ ਅਜਿਹੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਚੁੱਪ ਕਰ ਸਕਦੇ ਹਨ। ਬਿਹਤਰ ਟੈਸਟਰ ਉਹ ਹਨ ਜੋ ਰੋਜ਼ਾਨਾ ਪੈਨਲ ਵਰਤਣਗੇ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਈ ਰਿਹਾ/ਰਿਹਾ ਹੋ, ਤਾਂ ਇਹ ਓਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪਲੈਨਿੰਗ ਮੋਡ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਵਰਤ ਕੇ ਪਹਿਲਾਂ ਅਸਲ ਐਡਮਿਨ ਟਾਸਕ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਵਰਕਫਲੋਜ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਜਨਰੇਟ ਕਰੋ ਨਾਂ ਕਿ ਇੱਕ ਆਮ CRUD ਸੈਟਅੱਪ ਦੇ ਆਸਪਾਸ।

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਸ

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਸ ਕਾਰਜਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ।

ਕਿਸੇ ਨੂੰ ਇੱਕ ਅਸਲੀ ਬੈਚ ਜੌਬ ਕਰਨ ਲਈ ਕਿਹਾ ਅਤੇ ਟਾਈਮਰ ਚਲਾਓ। ਜੇ ਰਿਕਾਰਡ ਚੁਣਨਾ, ਸਥਿਤੀ ਬਦਲਣਾ, ਮਾਲਕ ਅਸਾਈਨ ਕਰਨਾ ਜਾਂ ਆਰਕਾਈਵਿੰਗ ਦੇ ਲਈ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਫਲੋਅ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਚੈੱਕ ਕਰੋ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਇੱਕ ਲੰਬੀ ਟੇਬਲ ਨੂੰ ਕੁਝ ਕਲਿੱਕਾਂ ਵਿੱਚ ਕਿੰਨਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਸਕਦਾ ਹੈ। ਚੰਗੇ ਫਿਲਟਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਸਰਚ ਉਹ ਸ਼ਬਦ ਸੰਭਾਲੇ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ।

ਏਕਸਪੋਰਟ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਐਪ ਤੋਂ ਬਾਹਰ ਖੋਲ੍ਹੋ। ਜੇ ਫਾਇਲ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਫ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਅੱਧ-ਮੁਕੰਮਲ ਹੈ।

ਫਿਰ ਇੱਕ ਸਪੋਰਟ ਪ੍ਰਸ਼ਨ ਟੈਸਟ ਕਰੋ: ਕੀ ਕੋਈ ਬੇਠਕ ਬਦਲਾਅ ਨੂੰ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਟ੍ਰੇਸ ਕਰ ਸਕਦਾ ਹੈ? ਉਹਨੂੰ ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ, ਕਿਸਨੇ ਬਦਲਿਆ, ਕਦੋਂ ਬਦਲਿਆ ਅਤੇ ਪੁਰਾਣਾ ਮੁੱਲ ਕੀ ਸੀ।

ਇੱਕ ਹੋਰ ਟੈਸਟ ਨਵੇਂ ਸਹਿ-ਕਰਮੀ ਨਾਲ ਕਰਨਯੋਗ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਸਕਰੀਨ ਬਿਨਾਂ ਗਾਈਡਡ ਟੂਰ ਦੇ ਦਿਓ ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ। ਉਹਨੂੰ ਸਮਝ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਟੇਬਲ ਕੀ ਦਿਖਾ ਰਹੀ ਹੈ, ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਕਿਹੜੇ ਬਦਲਾਅ ਖਤਰਨਾਕ ਹਨ।

ਇੱਕ ਛੋਟਾ ਪ੍ਰੀ-ਲਾਂਚ ਚੈਕਲਿਸਟ ਆਮਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:

• ਇੱਕ ਆਮ ਬੈਚ ਟਾਸਕ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰਾ ਕਰੋ
• ਕੁਝ ਕਲਿੱਕਾਂ ਵਿੱਚ ਇੱਕ ਲੰਬੀ ਸੂਚੀ ਘਟਾਓ
• ਏਕਸਪੋਰਟ ਡਾਟਾ ਜੋ ਬਿਨਾਂ ਸਾਫ਼ ਕੀਤੇ ਵਰਤ ਯੋਗ ਹੋਵੇ
• ਇੰਜਨੀਅਰਿੰਗ ਦੀ ਮਦਦ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਖ਼ਰਾਬ ਬਦਲਾਅ ਨੂੰ ਟ੍ਰੇਸ ਕਰੋ
• ਪਹਿਲੀ ਵਾਰ ਵਰਤਣ 'ਤੇ ਪੇਜ਼ ਸਮਝ ਆਵੇ

ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਚੈਕ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਯੂਜ਼ਰ ਇਸ ਖਾਮੀ ਨੂੰ ਜ਼ਲਦੀ ਖੋਜ ਲੈਣਗੇ।

ਅਗਲਾ ਕਦਮ

ਇੱਕ ਐਡਮਿਨ پੈਨਲ ਇਸ ਸਮੇਂ ਤੱਕ ਮੁਕੰਮਲ ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤੱਕ ਸਕਰੀਨਾਂ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ नਹੀਂ। ਇਹ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਮੁਕੰਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਹਰ ਦਿਨ ਇਸਤੇਮਾਲ ਕਰਦੇ ਹਨ ਅਤੇ ਬਿਨਾਂ ਹੈਕਸ, ਵਾਧੂ ਸਪੀਡਸ਼ੀਟਾਂ ਜਾਂ ਕਿਸੇ ਹੋਰ ਦੀ ਬਾਰ-ਬਾਰ ਮਦਦ ਤੋਂ ਆਪਣੇ ਕੰਮ ਨੂੰ ਖ਼ਤਮ ਕਰ ਸਕਦੇ ਹਨ।

ਅਗਲਾ ਕਦਮ ਸਧਾਰਨ ਹੈ: ਗੈਰ-ਮੌਜੂਦ ਟਾਸਕਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲੋ। "ਬਿਹਤਰ ਯੂਜ਼ਬਿਲਿਟੀ" ਨਾ ਲਿਖੋ। ਅਸਲ ਕੰਮ ਲਿਖੋ। 50 ਰਿਕਾਰਡ ਇੱਕ ਵਾਰ ਆਰਕਾਈਵ ਕਰੋ। ਸਥਿਤੀ ਅਤੇ ਤਾਰੀਖ ਨਾਲ ਫਿਲਟਰ ਕਰੋ। ਫਾਈਨੈਂਸ ਲਈ ਸਾਫ਼ CSV ਏਕਸਪੋਰਟ ਕਰੋ। ਕੀਮਤ ਬਦਲਣ ਵਾਲਾ ਬਦਲਾਅ ਕਿਸ ਨੇ ਤੇ ਕਦੋਂ ਕੀਤਾ—ਇਹ ਚੈੱਕ ਕਰੋ।

ਜੇ ਕੋਈ ਟਾਸਕ ਹਰ ਰੋਜ਼ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹੋਰ ਪੇਜਾਂ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨੂੰ ਠੀਕ ਕਰੋ। ਇੱਕ ਮਜ਼ਬੂਤ ਬਲਕ ਐਕਸ਼ਨ ਕਈ ਨਵੇਂ ਸਕਰੀਨਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਚਾ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ ਫਿਲਟਰ, ਸੇਵਡ ਵਿਊਜ਼, ਏਕਸਪੋਰਟ ਅਤੇ ਆਡੀਟ ਹਿਸਟਰੀ ਵੀ ਵਧੇਰੇ ਕਦਰ ਵਾਲੇ ਹਨ।

ਛੋਟੇ ਰੰਨੀਡ ਵਿੱਚ ਟੈਸਟ ਕਰਨ ਨਾਲ ਵੀ ਮਦਦ ਮਿਲਦੀ ਹੈ। Koder.ai ਵਿੱਚ ਪਲੈਨਿੰਗ ਮੋਡ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਇਹ ਐਡਮਿਨ ਫਲੋਜ਼ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਪਹਿਲਾਂ, ਫਿਰ ਅਗਲੀ ਵਰਜਨ ਜੈਨਰੇਟ ਕਰੋ। ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਜ਼ਿਂਦਾ ਵਰਕਫਲੋ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਸਮੇਂ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।

ਜੇ ਇਸ ਹਫਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਕ ਗੱਲ ਕਰੋ, ਤਾਂ ਰੋਜ਼ਾਨਾ ਐਡਮਿਨ ਕੰਮ ਨੂੰ ਅਸਾਨ, ਦੁਹਰਾਓ ਜੋਗ ਅਤੇ ਵਰਿਫ਼ਾਈ ਕਰਨ ਯੋਗ ਬਣਾ ਦਿਓ। ਯੂਜ਼ਰ ਸਾਦਾ ਇੰਟਰਫੇਸ ਨੂੰ ਮਾਫ ਕਰ ਦੇਣਗੇ। ਪਰ ਉਹ ਹਰ ਰੋਜ਼ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਕੰਮਾਂ 'ਤੇ ਵਾਧੂ ਕਲਿੱਕਾਂ ਨੂੰ ਮਾਫ਼ ਨਹੀਂ ਕਰਨਗੇ।