SOP ਤੋਂ ਸਾਫਟਵੇਅਰ: ਪਹਿਲੀ ਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

ਪਹਿਲੀ ਰਚਨਾ ਵਿੱਚ SOP ਕਿਉਂ ਫੇਲ ਹੁੰਦੇ ਹਨ

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

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

ਛੁਪੇ ਹੋਏ ਐਕਸਪਸ਼ਨ ਇੱਕ ਆਮ ਕਾਰਨ ਹਨ ਕਿ ਗਲਤ ਹੁੰਦਾ ਹੈ। ਇੱਕ SOP ਕਹਿ ਸਕਦਾ ਹੈ, "ਮੈਨੇਜਰ $1,000 ਤੋਂ ਵੱਧ ਦੀਆਂ ਬੇਨਤੀਆਂ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ," ਪਰ ਜੇ ਮੈਨੇਜਰ ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ, ਰਕਮ ਦੋ ਬੇਨਤੀਆਂ ਵਿੱਚ ਵੰਡੇ ਗਈ ਹੋਵੇ, ਜਾਂ ਗਾਹਕ ਨੂੰ ਇੱਕੋ ਦਿਨ ਜਵਾਬ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਇੱਥੇ ਛੋਟੇ ਕੇਸ ਸਮੂਹੀ ਵਰਕਫਲੋ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ।

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

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

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

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

ਮਕਸਦ SOP ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਕਾਪੀ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਉਸ ਦੇ ਪਿੱਛੇ ਦੀ ਅਸਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ ਹੈ।

ਦਸਤਾਵੇਜ਼ ਵਿੱਚੋਂ ਪਹਿਲਾਂ ਕੀ ਖਿੱਚਣਾ ਹੈ

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

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

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

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

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

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

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

SOP ਨੂੰ ਵਰਕਫਲੋ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ

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

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

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

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

ਭਾਸ਼ਾ ਸਧਾਰਤ ਰੱਖੋ। ਹਰ ਕਦਮ ਲਈ ਇੱਕ ਨਿਯਮ ਲਿਖੋ। "ਸੇਲਜ਼ ਗਾਹਕ ਦਾ ਨਾਮ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ", "ਇੰਟੇਕ ਦੌਰਾਨ ਕਲਾਇਂਟ ਡੇਟਾ ਕੈਪਚਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ" ਦੀ ਥਾਂ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਸਪਸ਼ਟ ਸ਼ਬਦ ਵਰਤੋਂ ਨਾਲ ਜਦੋਂ ਤੁਸੀਂ process mapping for apps ਤੋਂ ਅਸਲ ਬਿਲਡ ਵੱਲ ਜਾਓਗੇ ਤਾਂ ਗਲਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।

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

ਕਿਸੇ ਨੇ ਵੀ ਬਿਲਡ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸਲ ਦਿਨ-प्रतਿ-दਿਨ ਕੰਮ ਕਰਨ ਵਾਲਿਆਂ ਨਾਲ ਡਰਾਫਟ 'ਤੇ ਚੱਲੋ। ਪੁੱਛੋ ਕਿ ਕਿੱਥੇ ਦੇਰੀ ਹੁੰਦੀ ਹੈ, ਕੀ ਛੱਡਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਦ SOP ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਤਾਂ ਕੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਵਿਸਥਾਰ ਪੋਲਿਸ਼ ਕੀਤੇ ਗਏ ਲਫ਼ਜ਼ਾਂ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਕ ਹੁੰਦੇ ਹਨ।

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

ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਵੇਂ ਕੈਪਚਰ ਕਰਨਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਕਿਰਿਆ ਦਸਤਾਵੇਜ਼ ਖੁਸ਼ ਰਸਤਾ ਦਿਖਾਉਂਦੇ ਹਨ। ਅਸਲ ਕੰਮ ਕਦੇ ਵੀ ਬਹੁਤ ਦੇਰ ਤੱਕ ਉਥੇ ਨਹੀਂ ਰਹਿੰਦਾ।

ਜੇ ਤੁਸੀਂ ਪਹਿਲੀ ਰਚਨਾ ਨੂੰ ਦੈਨੀਕ ਓਪਰੇਸ਼ਨ ਨਾਲ ਮੈਚ ਕਰਵਾਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਹਰ ਕਦਮ 'ਤੇ ਇਹ ਸਵਾਲ ਪੁੱਛੋ: ਜਦ ਇਹ ਯੋਜਨਾ ਅਨੁਸਾਰ ਨਹੀਂ ਚਲਦੀ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਇੱਥੇ ਹੀ ਜ਼ਿਆਦਾਤਰ ਦੁਬਾਰਾ ਕੰਮ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ।

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

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

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

ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਖੋਜਣ ਦਾ ਸਧਾਰਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਕਦਮ 'ਤੇ ਇਹਨਾਂ ਚਾਰ ਸਵਾਲਾਂ ਨੂੰ ਪੁੱਛੋ:

• ਜੇ ਲੋੜੀਂਦਾ ਜਾਣਕਾਰੀ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
• ਕੀ ਚੀਜ਼ ਇਸਨੂੰ ਤੁਰੰਤ ਬਣਾਉਂਦੀ ਹੈ?
• ਕਦੋਂ ਕੋਈ ਇਨਸਾਨ ਇਸ ਕਦਮ ਨੂੰ ਛੱਡ ਜਾਂ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦਾ ਹੈ?
• ਕੀ ਕਾਰਨਾਂ ਕਾਰਨ ਕੰਮ ਨਕਾਰਿਆ, ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਜਾਂ ਫਸਿਆ ਰਹਿੰਦਾ ਹੈ?

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

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

ਮਨਜ਼ੂਰੀਆਂ, ਮਾਲਕ ਅਤੇ ਹੈਂਡਅਫ਼ਜ਼

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

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

ਜੇ ਤੁਸੀਂ approval flow design ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਢਿੱਲੀ ਭਾਸ਼ਾ ਖਰਾਬ ਬਿਲਡ ਦਾ ਕਾਰਣ ਬਣਦੀ ਹੈ। "ਮੈਨੇਜਰ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ" ਜਾਂ "ਟੀਮ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ" ਵਰਗੇ ਵਾਕ ਸਾਫਟਵੇਅਰ ਲਈ ਜ਼ਿਆਦਾ ਢਿੱਲੇ ਹੁੰਦੇ ਹਨ। ਐਪ ਨੂੰ ਠੀਕ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ: ਕਿਸ ਭੂਮਿਕਾ ਨੂੰ ਟਾਸਕ ਦਿਖਾਈ ਦੇਵੇਗੀ, ਉਹਨਾਂ ਨੂੰ ਕਿਹੜੇ ਬਟਨ ਮਿਲਣਗੇ, ਅਤੇ ਹਰ ਚੋਣ ਤੋਂ ਬਾਅਦ ਕੀ ਹੋਵੇਗਾ।

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

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

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

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

ਉਹ ਡਾਟਾ ਫੀਲਡ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ

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

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

ਮੁੱਢਲੇ-ਲੋੜੀਂਦੇ ਫੀਲਡਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਫੀਲਡਾਂ ਨੂੰ ਦੋ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡੋ: must-have ਅਤੇ nice-to-have। Must-have ਫੀਲਡ ਉਹ ਹਨ ਜੋ ਨਾਂ ਹੋਣ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਰੁਕ ਜਾਂਦੀ ਹੈ। Nice-to-have ਫੀਲਡ ਭਵਿੱਖ ਦੀ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਸਹਾਇਕ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਪਹਿਲੇ ਰਿਲੀਜ਼ ਨੂੰ ਰੋਕਣ ਵਾਲੀਆਂ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

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

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

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

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

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

ਇੱਕ SOP ਤੋਂ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ

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

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

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

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

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

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

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

ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਹੌਲਾ ਕਰਨ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ

ਅਨੇਕ ਟੀਮਾਂ ਪਹਿਲੇ ਵਰਜਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਮਾਂ ਖੋ ਦਿੰਦੀਆਂ ਹਨ। ਸਮੱਸਿਆ ਆਮ ਤੌਰ 'ਤੇ SOP ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਲੋਕ ਉਸਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਦੇ, ਵਿਆਖਿਆ ਕਰਦੇ ਅਤੇ ਬਿਲਡ ਵਿੱਚ ਬਦਲਦੇ ਹਨ।

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

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

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

ਘਰੜੇ ਤੇ ਕੇਵਲ ਤਰਕ ਨਹੀਂ; friction ਵੇਖੋ

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

ਕੁਝ ਸਾਦੇ ਸਵਾਲ ਮਦਦਗਾਰ ਹਨ: ਕਿਹੜੇ ਫੀਲਡਾਂ ਨਾਲ ਕਾਰਵਾਈ ਜਾਂ ਮਨਜ਼ੂਰੀ ਟ੍ਰਿਗਰ ਹੁੰਦੀ ਹੈ, ਕਿਹੜੇ ਫੀਲਡ ਸਿਰਫ਼ ਉਦੋਂ-ਬਾਦ ਲਈ ਹਨ, ਲੋਕ ਅਜੇ ਵੀ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਈਮੇਲ ਜਾਂ ਚੈਟ ਰਾਹੀਂ ਭੇਜਦੇ ਹਨ, ਅਤੇ ਅੱਜ ਹੈਂਡਅਫ਼ਜ਼ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦੇ ਹਨ?

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

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

ਪਹਿਲੀ ਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਜਾਂਚ

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

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

ਕਿਸੇ ਨੇ ਵੀ ਬਿਲਡ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੰਜ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਚੈੱਕ ਕਰੋ:

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

ਮਾਲਕੀ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਣ ਹੈ। "ਫਾਇਨੈਂਸ ਇਸਨੂੰ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ" ਕਾਫੀ ਨਹੀਂ ਜੇ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਉਹ ਸਮੀਖਿਆ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਅਸਲ ਭੂਮਿਕਾ ਦਾ ਨਾਮ ਦਿਓ ਜੋ ਕਾਰਵਾਈ ਕਰਦੀ, ਮਨਜ਼ੂਰ ਕਰਦੀ ਜਾਂ ਵਾਪਸ ਭੇਜਦੀ ਹੈ।

ਨਕਾਰ ਅਤੇ ਰੀਵਰਕ ਪਾਥਾਂ ਨੂੰ ਵੀ ਖੁਸ਼ ਰਸਤੇ ਵਾਂਗ ਹੀ ਵਿਸਥਾਰ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਇੱਕ ਬੇਨਤੀ ਅਧੂਰੀ ਹੈ, ਕੌਣ ਉਸਨੂੰ ਠੀਕ ਕਰੇਗਾ, ਕੀ ਬਦਲੇਗਾ, ਅਤੇ ਇਹ ਕਿੱਥੇ ਵਾਪਸ ਆਵੇਗੀ? ਬਹੁਤ ਸਾਰੇ ਪਹਿਲੇ ਬਿਲਡ ਉਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ صرف ਆਦਰਸ਼ ਮਾਮਲੇ ਨੂੰ ਮਾਡਲ ਕਰਦੇ ਹਨ।

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

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

ਵਰਜਨ ਇੱਕ ਲਈ ਅਗਲੇ ਕਦਮ

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

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

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

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

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

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

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

ਇਹੀ ਵਰਜਨ ਇੱਕ ਲਈ ਸਹੀ ਫਿਨਿਸ਼ ਲਾਈਨ ਹੈ: ਸਪਸ਼ਟ ਕਦਮ, ਸਪਸ਼ਟ ਮਾਲਕ, ਸਹੀ ਫੀਲਡ ਅਤੇ ਉਸ ਟੀਮ ਲਈ ਕਾਫੀ ਢਾਂਚਾ ਕਿ ਉਹ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ।