08 ਮਾਰਚ 2026·8 ਮਿੰਟ
ਗੱਲ-ਬਾਤ ਰਾਹੀਂ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਸਾਫਟਵੇਅਰ ਬਣਾਓ
ਗੱਲ-ਬਾਤ ਨੂੰ ਸਮੱਸਿਆ ਬਿਆਨਾਂ, ਯੂਜ਼ਰ ਭੂਮਿਕਾਵਾਂ, ਸੈਂਪਲ ਰਿਕਾਰਡ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਪਹਿਲੇ ਡਰਾਫਟ ਵਿੱਚ ਬਦਲ ਕੇ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਸਾਫਟਵੇਅਰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਸਿੱਖੋ।
ਗੱਲ-ਬਾਤ ਨੂੰ ਸਮੱਸਿਆ ਬਿਆਨਾਂ, ਯੂਜ਼ਰ ਭੂਮਿਕਾਵਾਂ, ਸੈਂਪਲ ਰਿਕਾਰਡ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਪਹਿਲੇ ਡਰਾਫਟ ਵਿੱਚ ਬਦਲ ਕੇ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਸਾਫਟਵੇਅਰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਸਿੱਖੋ।
ਵਾਇਰਫਰੇਮ ਲੋਕਾਂ ਨੂੰ ਕੁਝ ਮੈਦਾਨੀ ਦੇ ਦਿੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਉਹ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਥੇ ਨਾ ਹੋਣ ਤੇ ਇੱਕ ਛੋਟੀ ਸੋਚ ਪੰਜ ਵੱਖ-ਵੱਖ ਬੇਨਕਾਬ ਤਸਵੀਰਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।
ਕਹੋ ਕਿਸੇ ਨੇ ਕਸਟਮਰ ਪੋਰਟਲ ਮੰਗਿਆ। ਇੱਕ ਵਿਅਕਤੀ ਸੋਚਦਾ ਹੈ ਸਧਾਰਣ ਲੋਗਿਨ ਅਤੇ ਅਕਾਊਂਟ ਪੇਜ। ਦੂਜਾ ਵਿਅਕਤੀ ਸੋਚਦਾ ਹੈ ਅਪਰੋਵਲ, ਰਿਪੋਰਟ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਐਡਮਿਨ ਟੂਲ। ਦੋਹਾਂ ਸਹੀ ਲਗ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਹਨ।
ਇਸ ਲਈ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਵਿੱਚ ਅਕਸਰ ਗੁੰਝਲਦਾਰ ਲੱਗਦਾ ਹੈ। ਸਮੱਸਿਆ ਸਿਰਫ ਸਕ੍ਰੀਨਾਂ ਦੀ ਕਮੀ ਨਹੀਂ ਹੈ — ਇਹ ਪਹਿਲਾਂ ਸਾਂਝੀ ਸਮਝ ਦੀ ਕਮੀ ਹੈ ਕਿ ਉਤਪਾਦ ਨੂੰ ਪਹਿਲਾਂ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਇਹ ਯੋਜ਼ਨਾ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਮ੍ਹਾਗਤ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਅਸਲ ਸਮੱਸਿਆ 'ਤੇ ਰਾਜ਼ੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੀਚਰਾਂ ਦੇ ਨਾਮ ਰੱਖਦੇ ਹਨ। ਉਹ ਡੈਸ਼ਬੋਰਡ, ਫਿਲਟਰ, ਮੋਬਾਇਲ ਐਕਸੈਸ, ਅਤੇ ਸੈਟਿੰਗਾਂ ਮੰਗਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਬੁਨਿਆਦੀ ਲੋੜ ਨੂੰ ਸਪਸ਼ਟ ਕੀਤੇ, ਜਿਵੇਂ ਕਿ: ਫੀਲਡ ਸਟਾਫ਼ ਨੂੰ ਦਫ਼ਤਰ ਨੂੰ ਫ਼ੋਨ ਕੀਤੇ ਬਿਨਾਂ ਸਰਵਿਸ ਰਿਕਵੈਸਟ ਜਮ੍ਹਾਂ ਕਰਨੇ ਹੋਣ।
ਖਾਲੀ ਸਥਾਨ ਵੀ ਸਮੀਖਿਆ ਲਈ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਜੇ ਕੋਈ ਸਕੇਚ, ਨਮੂਨਾ ਡੇਟਾ, ਜਾਂ ਯੂਜ਼ਰ ਸਟੋਰੀ ਨਹੀਂ ਹੈ ਤਾਂ ਫੀਡਬੈਕ ਜਲਦੀ ਅਜਿਹਾ ਹੋ ਜਾਂਦਾ ਹੈ: “ਇਹ ਸਧਾਰਣ ਲੱਗਣਾ ਚਾਹੀਦਾ ਹੈ” ਜਾਂ “ਸਾਨੂੰ ਕੁਝ ਲਚਕੀਲਾ ਚਾਹੀਦਾ ਹੈ।” ਇਹ ਟਿੱਪਣੀਆਂ ਉਪਯੋਗੀ ਲੱਗ ਸਕਦੀਆਂ ਹਨ ਪਰ ਬਿਲਡਰ ਨੂੰ ਜ਼ਿਆਦਾ ਮਦਦ ਨਹੀਂ ਦਿੰਦੀਆਂ।
ਸ਼ੁਰੂਆਤੀ ਅਨੁਮਾਨ ਮਹਿੰਗੇ ਸਾਬਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇ ਟੀਮ ਮਨ ਲੈ ਲਵੇ ਕਿ ਐਪ ਨੂੰ ਤਿੰਨ ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗੇ ਕਿ ਅਸਲ ਵਿੱਚ ਛੇ ਵੱਖ-ਵੱਖ अनुमਤੀਆਂ ਵਾਲੀਆਂ ਕਿਸਮਾਂ ਹਨ, ਤਾਂ ਇਹ ਤਬਦੀਲੀ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਕਾਫ਼ੀ ਆਗੇ ਪ੍ਰਭਾਵ ਪਾਏਗੀ — ਫਾਰਮ, ਮਨਜ਼ੂਰੀ, ਰਿਪੋਰਟ, ਅਤੇ ਡਾਟਾ ਢਾਂਚੇ ਤੱਕ।
ਛੋਟਾ ਉਦਾਹਰਨ ਮਸਲਾ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਸੋਚੋ ਇਕ ਮੁਰੰਮਤ ਕਾਰੋਬਾਰ "ਜੌਬ ਮੈਨੇਜ ਕਰਨ ਵਾਲੀ ਐਪ" ਮੰਗਦਾ ਹੈ। ਇੱਕ ਲਈ ਇੱਕ ਸਦਿਆ ਸੂਚੀਬੰਧਨ ਦੀ ਲੋੜ ਹੈ; ਦੂਜੇ ਲਈ ਬਿੱਲਿੰਗ; ਮਾਲਿਕ ਲਈ ਜੌਬ ਸਟੇਟਸ ਅਤੇ ਗਾਹਕ ਅਪਡੇਟ। ਤਿੰਨੋ ਵਾਜਿਬ ਹਨ — ਪਰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਹਨ।
ਗੱਲ-ਬਾਤ-ਆਧਾਰਿਤ ਸਾਫਟਵੇਅਰ ਡਿਜ਼ਾਇਨ ਤਦ ਹੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਗੱਲ-ਬਾਤ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਵਿਸ਼ੇਸ਼ ਹੋ ਜਾਏ। ਸਕ੍ਰੀਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਨਾਮ ਦਿਓ, ਅਤੇ ਕੁਝ ਅਸਲੀ ਰਿਕਾਰਡ ਦਰਸਾਓ। Koder.ai ਜਿਹੀ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਇਹ ਕਿਸਮ ਦਾ ਇਨਪੁਟ ਬਿਲਡਰ ਨੂੰ ਕਾਫ਼ੀ ਸੰਦਰਭ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਕੋਈ ਖਰਾਬ ਮਾਕਅਪ ਨਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਇੱਕ ਉਪਯੋਗੀ ਪਹਿਲਾ ਡਰਾਫਟ ਬਣ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਬਣਾਉਣੇ ਹੋ, ਤਾਂ ਪਹਿਲਾ ਉਪਯੋਗੀ ਆਈਟਮ ਸਕੈਚ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇਕ ਸਿੱਧਾ ਇੱਕ ਵਾਕ ਹੁੰਦਾ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਗਲਤ ਹੈ, ਕੌਣ ਇਸਨੂੰ ਮਹਿਸੂਸ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਹ ਕਿਸ ਨਤੀਜੇ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।
ਜੇ ਉਹ ਵਾਕ ਧੁੰਦਲਾ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਆਮਤੌਰ 'ਤੇ ਫੀਚਰ ਦੀ ਢੇਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਡੈਸ਼ਬੋਰਡ, ਅਲਰਟ ਅਤੇ ਰਿਪੋਰਟ ਲਈ ਕਹਿੰਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਨੇ ਅਸਲ ਕੰਮ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਹੋਵੇ ਜੋ ਐਪ ਨੂੰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਸਮੱਸਿਆ ਬਿਆਨ ਇਸ ਤਰ੍ਹਾਂ ਸੁਨਾਈ ਦੇ ਸਕਦਾ ਹੈ:
"ਫੀਲਡ ਤਕਨੀਸ਼ੀਅਨ ਦਫ਼ਤਰ ਨੂੰ ਜੌਬ ਵੇਰਵਾ ਲਈ ਫ਼ੋਨ ਕਰਕੇ ਸਮਾਂ ਖਰਚ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਥਾਂ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਨਿਰਧਾਰਿਤ ਕੰਮ ਵੇਖਣ, ਸਟੇਟਸ ਅਪਡੇਟ ਕਰਨ ਅਤੇ ਮੈਦਾਨ ਤੋਂ ਫੋਟੋ ਅਪਲੋਡ ਕਰਨ ਦੀ ਵਿਆਸਥਾ ਹੋਵੇ।"
ਇਹ ਇਸ ਲਈ ਚੰਗਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਿਡਰਤਾ ਨਾਲ ਸਮੱਸਿਆ ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਹੈ ਬਜਾਏ ਜਵਾਬ ਤੇ ਛਾਲ ਮਾਰਨ ਦੇ। ਇਹ ਯੂਜ਼ਰ ਨੂੰ ਨਾਂਮ ਦਿੰਦਾ, ਦਰਸਾਉਂਦਾ ਕਿ ਕੀ ਰੁਕਾਵਟ ਹੈ, ਅਤੇ ਉਹ ਨਤੀਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
ਪਹਿਲੇ ਡਰਾਫਟ ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ:
ਨੋਟ ਕਰੋ ਕਿ ਕੀ ਲਾਪਤਾ ਹੈ: ਲੰਬੀ ਫੀਚਰ ਸੂਚੀ। "ਚੈਟ, ਮੈਪ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਐਡਮਿਨ ਸੈਟਿੰਗਾਂ ਵਾਲੀ ਐਪ ਬਣਾਓ" ਸਮੱਸਿਆ ਦਾ ਬਿਆਨ ਨਹੀਂ, ਇਹ ਜਵਾਬ ਬਾਰੇ ਅਨੁਮਾਨ ਹੈ।
ਇੱਕ ਵਧੀਆ ਪ੍ਰਸ਼ਨ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਜੇ ਸਾਫਟਵੇਅਰ ਅੱਜ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਦਰਦਨਾਕ ਪਲ ਹੱਲ ਕਰੇ, ਤਾਂ ਉਹ ਕਿਹੜਾ ਹੋਵੇਗਾ? ਉੱਥੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਵਰਜਨ ਇੱਕ ਨੂੰ ਇੱਕ ਕੰਮ ਚੰਗਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਉਤਪਾਦ ਬਾਅਦ ਵਿੱਚ ਵਧੇ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਕਲਿਨਿਕ ਕਹਿ ਸਕਦੀ ਹੈ, "ਰਿਸੈਪਸ਼ਨ ਕਰਮਚਾਰੀ ਰੱਦ ਹੋਏ ਨਿਯੁਕਤੀਆਂ ਨੂੰ ਭਰਣ ਦੇ ਮੌਕੇ ਗਵਾ ਦੇਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਖੁੱਲ੍ਹੇ ਸਲਾਟ ਤੇਜ਼ੀ ਨਾਲ ਵੇਖਣ ਅਤੇ ਵੈਟਿੰਗ ਗਾਹਕਾਂ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।" ਇਹ "ਸਕੈਡਿਊਲਿੰਗ ਸਾਫਟਵੇਅਰ ਚਾਹੀਦਾ" ਕਹਿਣ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਦਿਸ਼ਾ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਆਧਾਰਿਤ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਵਾਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨੀਂਹ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਹਿਲੇ ਡਰਾਫਟ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਲਕੜੀ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ।
ਇਕ ਸਧਾਰਨ ਟੈਸਟ ਮਦਦਗਾਰ ਹੈ: ਕੀ ਕੋਈ ਨਵਾਂ ਟੀਮ ਮੈਂਬਰ 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਸਮੱਸਿਆ ਸਮਝ ਜਾਏਗਾ? ਜੇ ਨਹੀਂ ਤਾਂ ਵਾਕ ਨੂੰ ਤਿੱਖਾ ਕਰੋ ਜਦ ਤੱਕ ਉਹ ਸਮਝ ਨਾ ਜਾਂਦਾ।
ਕਿਸੇ ਨੇ ਵੀ ਪੇਜਾਂ, ਬਟਨਾਂ ਜਾਂ ਮੇਨੂਜ਼ ਬਾਰੇ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿਓ: ਇਹ ਕਿਸ ਲਈ ਹੈ ਅਤੇ ਉਹ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ?
ਭੂਮਿਕਾਵਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਢਾਂਚਾ ਦਿੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਲੇਬਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕ ਕੰਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਹਨ: ਗਾਹਕ, ਮੈਨੇਜਰ, ਡਿਸਪੈਚਰ, ਤਕਨੀਸ਼ੀਅਨ, ਅਕਾਉਂਟੈਂਟ, ਐਡਮਿਨ। ਜੇ ਕੋਈ ਭੂਮਿਕਾ ਧੁੰਦਲੀ ਲੱਗਦੀ ਹੈ ਤਾਂ ਉਹ ਆਮਤੌਰ 'ਤੇ ਧੁੰਦਲੀ ਹੁੰਦੀ ਹੈ। "ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ" ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਨਹੀਂ। "ਸਪੋਰਟ ਏਜੰਟ ਜੋ ਟਿਕਟ ਅਪਡੇਟ ਕਰਦਾ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ" ਬਹੁਤ ਵਧੀਆ ਹੈ।
ਹਰ ਭੂਮਿਕਾ ਲਈ ਲਿਖੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਕੁਝ ਕੀ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹ ਸਭ ਤੋਂ ਵੱਧ ਕੀ ਬਣਾਉਣ ਜਾਂ ਅਪਡੇਟ ਕਰਨਗੇ। ਵਹ ਅਮਲੀ ਹੋਵੇ। ਇੱਕ ਮੈਨੇਜਰ ਨੂੰ ਖੁਲ੍ਹੇ ਕੰਮ, ਓਵਰਡਿਊ ਆਈਟਮ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਦਾ ਸਾਰ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਤਕਨੀਸ਼ੀਅਨ ਨੂੰ ਸਿਰਫ਼ ਨਿਰਧਾਰਿਤ ਜੌਬ, ਗਾਹਕ ਵੇਰਵੇ, ਅਤੇ ਕੰਮ ਪੂਰਾ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸੇ ਕਾਰਨ ਭੂਮਿਕਾਵਾਂ ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਦੋ ਲੋਕ ਇੱਕੋ ਐਪ ਵਰਤ ਸਕਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਦ੍ਰਿਸ਼ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਕਦਮ ਛੱਡ ਦਿਓ ਤਾਂ ਅਕਸਰ ਤੁਹਾਡੇ ਕੋਲ ਭਰੇ ਹੋਏ ਸਕ੍ਰੀਨਾਂ ਵਾਲਾ ਨਤੀਜਾ ਆਉਂਦਾ ਹੈ ਜਿਸ 'ਚ ਉਹ ਖੇਤਰ ਅਤੇ ਕਾਰਵਾਈਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਕੁਝ ਯੂਜ਼ਰਾਂ ਲਈ ਅਹਮ ਹੁੰਦੀਆਂ ਹਨ।
ਲੰਮਾ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ। ਹਰ ਭੂਮਿਕਾ ਲਈ ਇੱਕ ਛੋਟੀ ਨੋਟ ਕਾਫ਼ੀ ਹੈ:
ਆਮ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਐਡਜ ਕੇਸ ਤੋਂ ਵੱਖ ਰੱਖਣਾ ਵੀ ਮਦਦਗਾਰ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਐਪਸ ਵਿੱਚ ਦੋ ਤੋਂ ਚਾਰ ਮੁੱਖ ਭੂਮਿਕਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਡਿਜ਼ਾਇਨ ਦਿਆਂ ਮੁੱਖ ਨਿਰਣਾਇਕ ਹੁੰਦੇ ਹਨ। ਕਿਰਪਾ ਦੇ ਕੇ ਵਿਲੱਖਣ ਕੇਸ, ਜਿਵੇਂ ਬਾਹਰੀ ਡੀਟਰ ਜਾਂ ਅਸਥਾਈ ਸਮੀਖਿਆਕਾਰ, ਨੂੰ ਨੋਟ ਕਰੋ ਪਰ ਉਹ ਪੂਰੇ ਉਤਪਾਦ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਾ ਕਰਨ।
ਇੱਕ ਸਰਵਿਸ ਰਿਕੁਐਸਟ ਐਪ ਲਵੋ। ਰਿਕੁਐਸਟਰ ਟਿਕਟ ਬਣਾਉਂਦਾ ਅਤੇ ਸਥਿਤੀ ਜਾਂਚਦਾ ਹੈ। ਕੋਆਰਡਿਨੇਟਰ ਜੌਬ ਨਿਰਧਾਰਤ ਕਰਦਾ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਬਦਲਦਾ ਹੈ। ਤਕਨੀਸ਼ੀਅਨ ਨੋਟਸ ਅਪਡੇਟ ਕਰਦਾ ਅਤੇ ਕੰਮ ਪੂਰਾ ਮਾਰਕ ਕਰਦਾ ਹੈ। ਮੈਨੇਜਰ ਰੁਝਾਨ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਅਤੇ ਛੋਟ-ਮੋਟ ਛੂਟਾਂ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਫਲੋ ਦਾ ਖਾਕਾ ਬਣਾਉਂਦਾ ਹੈ ਭਾਵੇਂ ਮਾਕਅਪ ਨਾ ਹੋਵਣ।
ਜਦੋਂ ਵਾਇਰਫਰੇਮ ਨਹੀਂ ਹੁੰਦੇ, ਤਾਂ ਸੈਂਪਲ ਰਿਕਾਰਡ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਮਾਕਅਪਸ ਕਰਦੇ ਹਨ। ਉਹ abstract ਸੋਚ ਨੂੰ ਠੋਸ ਡੇਟਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਦਰਸ਼ਾਉਂਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਐਪ ਨੂੰ ਕੀ ਸਟੋਰ, ਦਿਖਾਉਣਾ ਅਤੇ ਕਾਰਵਾਈ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਅੱਛੀ ਸ਼ੁਰੂਆਤ ਲਈ ਪੰਜ ਤੋਂ ਦਸ ਹਕੀਕਤੀ ਰਿਕਾਰਡ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਇਹ ਆਮਤੌਰ 'ਤੇ ਪੈਟਰਨਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਵਾਧੂ ਕੰਮ ਬਣਾਏ। ਜੇ ਹਰ ਰਿਕਾਰਡ ਸਾਫ਼ ਅਤੇ ਇੱਕੋ-ਸਰਹੀ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਐਡਜ ਕੇਸਾਂ ਮਿਸ ਕਰ ਦੋਂਗੇ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਲੋੜੀਂਦੇ ਫੀਲਡ ਉਹੀ ਨਾਮ ਰੱਖੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਆਵਾਜ਼ ਨਾਲ ਕਹਿੰਦੇ ਹਨ। ਜੇ ਟੀਮ "ਕਲੀਜ਼ੇਂਟ ਨਾਂ" ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ "ਅਕਾਊਂਟ ਐਂਟੀਟੀ" ਵਿੱਚ ਨਹੀਂ ਬਦਲੋ। ਜਾਣੂ ਲੇਬਲ ਗੱਲ-ਬਾਤ ਤੇਜ਼ ਕਰਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਘਟਾਉਂਦੇ ਹਨ।
ਹਰ ਸੈਂਪਲ ਵਿੱਚ ਉਹ ਫੀਲਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਇੱਕ ਅਸਲ ਵਿਅਕਤੀ ਭਰਨ ਜਾਂ ਪੜ੍ਹਨ ਦੀ ਉਮੀਦ ਰੱਖਦਾ ਹੈ। ਭਰੋਸੇਯੋਗ ਰੱਖੋ:
ਉਹ ਗੁੰਝਲਦਾਰ ਰਿਕਾਰਡ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਅਹਿਮ ਸਮਝਦੀ ਹੈ। ਅਸਲ ਡੇਟਾ ਕਦੇ ਵੀ ਸਾਫ਼ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਰਿਕਾਰਡ ਵਿੱਚ ਫੋਨ ਨੰਬਰ ਗੈਰ ਮੌਜੂਦ ਹੋ ਸਕਦਾ ਹੈ, ਵਰਣਨ ਢੁੱਲਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਸ਼੍ਰੇਣੀ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਪਹਿਲਾ ਡਰਾਫਟ ਉਸ ਕੇਸ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਤਾਂ ਉਹ ਅਸਲ ਵਰਤੋਂ ਦੇ ਨੇੜੇ ਹੋਵੇਗਾ।
ਸੋਚੋ ਇੱਕ ਮੁਰੰਮਤ ਰਿਕਾਰਡ ਐਪ। ਇੱਕ ਸਾਫ਼ ਰਿਕਾਰਡ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ: ਬੇਨਤੀ ਕਿਸਮ, ਗਾਹਕ ਨਾਮ, ਪਤਾ, ਸਮੱਸਿਆ, ਪ੍ਰਾਥਮਿਕਤਾ, ਨਿਰਧਾਰਿਤ ਤਕਨੀਸ਼ੀਅਨ, ਅਤੇ ਸਟੇਟਸ। ਇੱਕ ਹੋਰ ਬਹੁਤ ਉਪਯੋਗ ਸੈੱਟ ਵਿੱਚ ਇਕ ਬੇਨਤੀ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ ਅਪਾਰਟਮੈਂਟ ਨੰਬਰ ਨਹੀਂ, ਇੱਕ ਤੁਰੰਤ ਸੁਰੱਖਿਆ ਮੁੱਦਾ, ਜਾਂ ਇੱਕ ਨਕਲ ਦਾਖਲ। ਇਹ ਵੇਰਵੇ ਅਗਲੇ ਕਦਮ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਫੀਲਡਾਂ ਨੂੰ ਵਧੇਰੇ ਧਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਟੇਟਸ, ਪ੍ਰਾਥਮਿਕਤਾ, ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ, ਭੁਗਤਾਨ ਮਿਲਿਆ, ਅਤੇ ਡਿਊ ਡੇਟ ਆਮਤੌਰ 'ਤੇ ਕਾਰਵਾਈਆਂ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ ਜਾਂ ਦੇਖਣ ਵਾਲੇ ਨੂੰ ਬਦਲਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਚਿੰਨ੍ਹਤ ਕਰੋ ਤਾਂ ਜੋ ਐਪ ਲਾਜਿਕ ਬਾਅਦ ਵਿੱਚ ਅਨੁਮਾਨ ਨਾ ਹੋਵੇ।
ਸਪੇਸ਼ਲ ਕਰਕੇ ਚੈਟ ਪ੍ਰਾਂਪਟਾਂ ਤੋਂ ਬਣਨ ਵਾਲੇ ਟੂਲਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਸੈਂਪਲ ਰਿਕਾਰਡ ਬਹੁਤ ਮਦਦਗਾਰ ਹਨ। ਉਹ ਸਿਸਟਮ ਨੂੰ ਕੁਝ ਠੋਸ ਮਾਡਲ ਦੇਂਦੇ ਹਨ ਜਿਸ ਨਾਲ ਉਹ ਕੰਮ ਕਰੇ, ਨਾ ਕਿ ਲੰਮੀ ਠਹਿਰਾਅਵਾਦ ਵਰਣਨਾ ਨੂੰ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ।
ਇੱਕ ਖਰਾਬ ਸਥਿਤੀ ਸਿਰਫ਼ ਇਹ ਗੱਲ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ, ਪਰ ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਅਗੇ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੇਗਾ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਕ ਕਾਰਵਾਈਆਂ ਲਈ ਸਧਾਰਨ if-then ਨਿਯਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਇੱਕ ਬੇਨਤੀ ਇੱਕ ਨਿਰਧਾਰਤ ਰਕਮ ਤੋਂ ਘੱਟ ਹੈ, ਇਹ ਆਪਣੇ ਆਪ ਮਨਜ਼ੂਰ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਇਹ ਉਸ ਰਕਮ ਤੋਂ ਉਪਰ ਹੈ, ਤਾਂ ਇਹ ਮੈਨੇਜਰ ਕੋਲ ਚੱਲ ਜਾਂਦੀ ਹੈ। ਜੇ ਫਾਰਮ urgent ਮਾਰਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਤੇਜ਼ ਡੈਡਲਾਈਨ ਅਤੇ ਵੱਖਰਾ ਅਲਰਟ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇਹ ਨਿਯਮ ਤਕਨੀਕੀ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ। ਸਧੇ ਸੈਕਟੈਂਸ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨਾਲ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਐਪ ਵਰਤਣਗੇ।
ਹਰ ਮਹੱਤਵਪੂਰਕ ਕਦਮ ਲਈ ਕੁਝ ਮੁੱਢਲੇ ਬਿੰਦੂ ਲਿਖੋ:
ਹਥਾਫ਼ੇਜ਼ ਸਕ੍ਰੀਨਾਂ ਜਿੰਨਾ ਮਹੱਤਵਪੂਰਕ ਹਨ, ਉਹਨਾ ਹੀ ਮਹੱਤਵਪੂਰਕ ਹਨ। ਇਕ ਬੇਨਤੀ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀ ਹੈ ਇਕ ਸਟਾਫ਼ ਮੈਂਬਰ ਨਾਲ, ਟੀਮ ਲੀਡ ਕੋਲ ਜਾਵੇ, ਫਿਰ ਫਾਇਨੈਂਸ ਕੋਲ, ਅਤੇ ਫਿਰ ਮੁੜ ਮੁਢਲੇ ਵਿਅਕਤੀ ਕੋਲ ਜੇ ਕੋਈ ਚੀਜ਼ ਗੁੰਮ ਹੋਵੇ। ਜੇ ਉਹ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਛੱਡ ਦਿਤੀਆਂ ਜਾਣ ਤਾਂ ਐਪ ਡੈਮੋ ਵਿੱਚ ਠੀਕ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਵਿੱਚ ਟੁੱਟ ਸਕਦੀ ਹੈ।
ਅਗਰ ਨੋਟ ਕਰੋ ਕਿ ਅਪਵਾਦ ਕੀ ਹਨ। ਜੇ ਕੋਈ ਲੋੜੀ ਫੀਲਡ ਘੱਟ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ? ਜੇ ਗਾਹਕ ID ਗਲਤ ਹੋਵੇ ਤਾਂ? ਜੇ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਆਫ਼ਿਸ ਤੋਂ ਬਾਹਰ ਹੋਵੇ? ਜੇ ਡਿਊ ਡੇਟ ਬੀਤ ਜਾਵੇ ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਾ ਆਏ?
ਇੱਕ ਸਹੀ ਨਿਯਮ-of-thumb ਇਹ ਹੈ ਕਿ ਬੁਰਾ ਡੇਟਾ ਅਤੇ ਰੁਕੀ ਹੋਈ ਕਾਰਵਾਈ ਲਈ ਵਿਹਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਹੀ ਸਬਮਿਸ਼ਨ ਲਈ। ਇਸ ਵਿੱਚ ਰੋਕੀਆਂ ਕਾਰਵਾਈਆਂ, ਯਾਦ ਦਿਲਾਉਣ ਦੀ ਸਮਾਂ-ਸੂਚੀ, ਬੈਕਅਪ ਮਾਲਕ, ਅਤੇ ਸਾਫ਼ ਐਰਰ ਸੁਨੇਹੇ ਸ਼ਾਮਲ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
If X happens, then Y changes, Z person is notified, and A person becomes responsible.
ਉਸ ਪੱਧਰ ਦੀ ਵਿਸਥਾਰ ਆਮਤੌਰ 'ਤੇ ਗੱਲ-ਬਾਤ ਨੂੰ ਕੰਮ ਕਰਣ ਵਾਲੀ ਐਪ ਲਾਜਿਕ ਵਿੱਚ ਬਦਲਣ ਲਈ ਕਾਫੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਡਰਾਫਟ ਸਕ੍ਰੀਨਾਂ ਨਾਲ ਨਹੀਂ ਸ਼ੁਰੂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਸਮੱਸਿਆ, ਸ਼ਾਮਲ ਲੋਕ, ਅਤੇ ਉਹ ਕੰਮ ਜੋ ਐਪ ਨੂੰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।
ਇਕ ਛੋਟੇ ਸਮੱਸਿਆ ਬਿਆਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਯੂਜ਼ਰ ਭੂਮਿਕਾਵਾਂ ਨਾਮ ਦਿਓ। ਉਦਾਹਰਨ ਲਈ: ਇੱਕ ਸਰਵਿਸ ਕੰਪਨੀ ਨੂੰ ਸਧਾਰਣ ਐਪ ਚਾਹੀਦਾ ਹੈ ਜੋ ਗਾਹਕ ਦੀਆਂ ਬੇਨਤੀਆਂ ਲੌਗ ਕਰੇ, ਇੱਕ ਤਕਨੀਸ਼ੀਅਨ ਨਿਰਧਾਰਿਤ ਕਰੇ, ਅਤੇ ਜ ਬੰਨ੍ਹੇ ਤੱਕ ਜੌਬ ਟ੍ਰੈਕ ਕਰੇ। ਭੂਮਿਕਾਵਾਂ ਹਨ: ਡਿਸਪੈਚਰ, ਤਕਨੀਸ਼ੀਅਨ, ਅਤੇ ਮੈਨੇਜਰ। ਇਹ "ਮੈਨੇਜਮੇਟ ਐਪ ਚਾਹੀਦਾ" ਕਹਿਣ ਨਾਲੋਂ ਕਾਫ਼ੀ ਵਧੇਰੇ ਮਦਦਗਾਰ ਹੈ।
ਫਿਰ ਕੁਝ ਸੈਂਪਲ ਰਿਕਾਰਡ ਸ਼ਾਮਲ ਕਰੋ। ਅਸਲੀ ਉਦਾਹਰਨ ਡਰਾਫਟ ਨੂੰ ਜ਼ਿਆਦਾ ਸਹੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਐਪ ਨੂੰ ਕਿਹੜਾ ਡੇਟਾ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸੈਂਪਲ ਸਰਵਿਸ ਰਿਕਾਰਡ ਵਿੱਚ ਗਾਹਕ ਨਾਮ, ਪਤਾ, ਮੁੱਦਾ ਦੀ ਕਿਸਮ, ਪ੍ਰਾਥਮਿਕਤਾ, ਨਿਰਧਾਰਿਤ ਤਕਨੀਸ਼ੀਅਨ, ਦੌਰੇ ਦੀ ਤਾਰੀਖ, ਅਤੇ ਸਟੇਟਸ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। ਜਦ ਇਹ ਉਦਾਹਰਨ ਹੋਂਦ ਵਿੱਚ ਹਨ ਤਾਂ ਗੁੰਝਲਦਾਰ ਖੇਤਰ ਅਤੇ ਵਿਵਰਨ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਛੋਟਾ ਯੂਜ਼ੇਬਲ ਵਰਜਨ ਪਹਿਲਾਂ ਮੰਗੋ। ਇਹ ਇੱਕ ਵਰਕਫਲੋ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ, ਸਿਰਫ਼ ਪੂਰੇ ਬਿਜ਼ਨਸ ਨੂੰ ਨਹੀਂ। ਸਰਵਿਸ ਰਿਕਾਰਡ ਮੁਦਰਾ ਵਿੱਚ ਵਰਜਨ ਇੱਕ ਹੋ ਸਕਦਾ ਹੈ: ਬੇਨਤੀ ਬਣਾਉਣਾ, ਤਕਨੀਸ਼ੀਅਨ ਨਿਰਧਾਰਿਤ ਕਰਨਾ, ਸਟੇਟਸ ਅਪਡੇਟ ਕਰਨਾ, ਜੌਬ ਬੰਦ ਕਰਨਾ। ਰਿਪੋਰਟ, ਬਿਲਿੰਗ, ਅਤੇ ਅਡਵਾਂਸPermissions ਬਾਅਦ ਲਈ ਛੱਡੋ।
ਛੋਟੀ ਭਾਸ਼ਾਈ ਤਬਦੀਲੀਆਂ ਬਹੁਤ ਸਾਰਾ ਬੈਕ-ਅਤੇ-ਫੋਰਥ ਬਚਾਉਂਦੀਆਂ ਹਨ:
ਪਹਿਲੇ ਡਰਾਫਟ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ-ਇੱਕ ਵਰਕਫਲੋ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਇੱਕ ਅਸਲੀ ਯੂਜ਼ਰ ਵਾਂਗ ਚੱਲੋ। ਡਿਸਪੈਚਰ ਕੀ ਦਰਜ ਕਰਦਾ ਹੈ? ਤਕਨੀਸ਼ੀਅਨ ਨੂੰ ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਮੈਨੇਜਰ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ? ਉਸ ਰਸਤੇ ਨੂੰ ਠੀਕ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਹੋਰ ਸਕ੍ਰੀਨਾਂ ਜਾਂ ਵਿਜ਼ੂਅਲ ਸੁਧਾਰਾਂ ਨੂੰ ਮੰਗੋ।
ਸਰਵਿਸ ਰਿਕਾਰਡ ਐਪ ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ ਕਿਉਂਕਿ ਵਰਕਫਲੋ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰਵਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਜੌਬ ਨੂੰ ਜਦੋਂ ਇਹ ਆਉਂਦੀ ਹੈ ਤੋਂ ਲੈ ਕੇ ਬੰਦ ਹੋਣ ਤੱਕ ਇੱਕ ਹੀ ਕੰਮ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਹ ਪਹਿਲੇ ਵਰਜਨ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਤਿੰਨ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਮੈਨੇਜਰ ਆ ਰਿਕਾਰਡ ਲੌਗ ਕਰਦਾ, ਇੱਕ ਤਕਨੀਸ਼ੀਅਨ ਮੈਦਾਨ ਵਿੱਚ ਜੌਬ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਐਡਮਿਨ ਆਖਰੀ ਲਾਗਤ ਦੀ ਜਾਂਚ ਕਰ ਔਰ ਬੰਦ ਕਰਦਾ। ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਈਨ ਤੋਂ ਬਿਨਾਂ ਵੀ ਇਹ ਭੂਮਿਕਾਵਾਂ ਪਤਾ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਹਰ ਵਿਅਕਤੀ ਲਈ ਐਪ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਕ ਛੋਟੇ ਦਫ਼ਤਰ ਵਿੱਚ ਟੁੱਟੀਆਂ ਏਅਰ ਕੰਡੀਸ਼ਨਰ ਦੀ ਬੇਨਤੀ ਸੋਚੋ। ਮੈਨੇਜਰ ਇੱਕ ਨਵਾਂ ਜੌਬ ਬਣਾਉਂਦਾ ਅਤੇ ਮੁੱਖ ਵੇਰਵੇ ਜੋੜਦਾ:
ਉਹ ਸੈਂਪਲ ਰਿਕਾਰਡ ਡਾਟਾਬੇਸ ਭਰਨ ਤੋਂ ਇਲਾਵਾ ਬਹੁਤ ਕੁਝ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਘੱਟ ਹੈ। ਕੀ ਤਕਨੀਸ਼ੀਅਨ ਨੂੰ ਫੋਟੋ ਅਪਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਕੀ ਉਹ "ਇਨ ਪ੍ਰੋਗ੍ਰੈਸ" ਦੀ ਬਜਾਏ "ਪਾਰਟਸ ਦੀ ਉਡੀਕ" ਮਾਰਕ ਕਰ ਸਕਦੇ ਹਨ? ਕੀ ਐਡਮਿਨ ਨੂੰ ਜੌਬ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗਾਹਕ ਦੀ ਮਨਜ਼ੂਰੀ ਚਾਹੀਦੀ ਹੈ?
ਜਦ ਤੁਸੀਂ ਇੱਕ ਅਸਲੀ ਬੇਨਤੀ ਦੇ ਰਾਹੀਂ ਵੱਖ-ਵੱਖ ਸਟੇਟਸ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਉਹ ਵੀ ਬਹੁਤ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਮੈਨੇਜਰ ਜੌਬ ਖੋਲਦਾ। ਤਕਨੀਸ਼ੀਅਨ ਇਸਨੂੰ "ਨਿਰਧਾਰਤ" ਤੋਂ "ਸਾਈਟ ਤੇ" ਵਿੱਚ ਬਦਲਦਾ, ਦੌਰੇ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰਦਾ, ਅਤੇ ਵਰਤੀ ਗਈ ਪਾਰਟਸ ਦਰਜ ਕਰਦਾ। ਬਾਅਦ ਵਿੱਚ, ਐਡਮਿਨ ਕੁੱਲ ਲਾਗਤ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ, ਜਾਂਚਦਾ ਕਿ ਕੰਮ ਮੁਕੰਮਲ ਹੈ, ਅਤੇ ਰਿਕਾਰਡ ਬੰਦ ਕਰਦਾ।
ਇਹ ਸਧਾਰਣ ਕਹਾਣੀ ਅਕਸਰ ਉਹ ਵਾਧੂ ਕਦਮ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਲੋਕ ਪਹਿਲਾਂ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਮੈਨੇਜਰ ਕੋਲ ਕੋਈ ਤਰੀਕਾ ਹੋਵੇ ਜੌਬ ਮੁੜ-ਨਿਰਧਾਰਿਤ ਕਰਨ ਦਾ ਜੇ ਤਕਨੀਸ਼ੀਅਨ ਬਿਮਾਰ ਹੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤਕਨੀਸ਼ੀਅਨ ਨੂੰ ਮੈਦਾਨ ਤੋਂ ਆਫਲਾਈਨ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਐਡਮਿਨ ਨੂੰ ਜੌਬ ਰੱਦ ਕਰਨ 'ਤੇ ਇੱਕ ਕਾਰਨ ਕੋਡ ਦੀ ਲੋੜ ਹੋਵੇ।
ਕੀ ਦਿਲਚਸਪ ਹੈ ਕਿ ਵਰਜਨ ਇੱਕ ਛੋਟਾ ਰੱਖੋ। ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਬਿਨਾਂ ਰੁਕਾਵਟ ਮਿਲਣ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਜੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਸਲ ਬੁਨਿਆਦ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡੀ ਦੇਰ ਆਮ ਤੌਰ ਤੇ ਬਹੁਤ ਜਲਦੀ ਅਨੁਮਾਨ ਲਗਾਉਣ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਕੰਮ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਅਧਿਕਾਰੀ ਸਕ੍ਰੀਨਾਂ ਦੁਬਾਰਾ ਲਿਖਦੇ, ਫੀਲਡ ਬਦਲਦੇ, ਅਤੇ ਐਡਜ ਕੇਸਾਂ 'ਤੇ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਕਰਦੇ ਹੋਏ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਆਮ ਗਲਤੀ ਹੈ ਕਿ ਵਰਕਫਲੋ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸਮਝ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲੇਆਉਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਦਿਤਾ ਜਾਵੇ। ਇੱਕ ਨਿਰਮਲ ਸਕ੍ਰੀਨ ਮਦਦ ਨਹੀਂ ਕਰਦੀ ਜੇ ਕੋਈ ਵੀ ਸਹਿਮਤ ਨਾ ਹੋ ਕਿ ਪਹਿਲਾਂ ਕੀ ਹੁੰਦਾ, ਫਿਰ ਕੀ ਹੁੰਦਾ, ਅਤੇ ਕਿਸ ਨੂੰ ਮੁਕੰਮਲ ਹੋਣਾ ਗਿਣਿਆ ਜਾਵੇ।
ਦੂਜੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਨਮੂਨਾ ਡੇਟਾ ਬਹੁਤ ਪرفੈਕਟ ਹੋਵੇ। ਅਸਲ ਕਾਰੋਬਾਰ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਹੈ। ਨਾਮ ਗਲਤ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਰਿਕਾਰਡ ਅਧੂਰੇ ਹੁੰਦੇ ਹਨ, ਤਾਰੀਆਂ ਗੈਰ ਮੌਜੂਦ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਦੋ ਲੋਕ ਇੱਕੋ ਹੀ ਮੁੱਦੇ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਉਦਾਹਰਨ ਬਹੁਤ ਸਾਫ਼ ਹਨ ਤਾਂ ਐਪ ਡੈਮੋ 'ਚ ਠੀਕ لگ ਸਕਦਾ ਹੈ ਪਰ ਅਸਲ ਵਰਤੇ ਜਾਣ 'ਤੇ FAIL ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਰਵਿਸ ਐਪ ਇਸ gall ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਜੇ ਹਰ ਟੈਸਟ ਰਿਕਾਰਡ "ਤੁਰੰਤ ਪਲੰਬਿੰਗ ਮੁੱਦਾ" ਨਾਲ ਪੂਰਾ ਪਤਾ ਅਤੇ ਫੋਨ ਨੰਬਰ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਸਧਾਰਨ ਲੱਗੇਗੀ। ਅਸਲ ਬੇਨਤੀਆਂ "ਸਿੰਕ ਟੁੱਟਿਆ" ਲਿਖ ਸਕਦੀਆਂ ਹਨ, ਕੋਈ ਅਪਾਰਟਮੈਂਟ ਨੰਬਰ ਨਾ ਹੋਵੇ, ਅਤੇ ਭੇਜਣ ਵਾਲਾ ਟੇਨੈਂਟ ਹੋ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਮਲਿਕ। ਇਹ ਖੇਤਰ, ਨਿਯਮ ਅਤੇ ਫਾਲੋ-ਅਪ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਟੀਮਾਂ ਅਕਸਰ ਵਰਜਨ ਇੱਕ ਅਤੇ ਭਵਿੱਖ ਨੂੰ ਮਿਲਾ ਦਿੰਦੀਆਂ ਹਨ। ਉਹ ਇੱਕ ਸਧਾਰਣ ਰਿਕਾਰਡ ਟਰੈਕਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਫਿਰ ਰਿਪੋਰਟਿੰਗ, ਬਿਲਿੰਗ, ਮੋਬਾਇਲ ਅਲਰਟ, ਮਨਜ਼ੂਰੀਆਂ, ਅਤੇ ਗਾਹਕ ਚੈਟ ਸ਼ਾਮਲ ਕਰ ਲੈਂਦੇ ਹਨ, ਜਦ ਕਿ ਮੂਲ ਵਰਕਫਲੋ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਵਰਜਨ ਇੱਕ ਨੂੰ ਇੱਕ ਸਾਫ ਸਮੱਸਿਆ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਬਾਕੀ ਬਾਅਦ ਲਈ ਰੱਖੋ।
ਮਾਲਕਾਨਾ (Ownership) ਵੀ ਇੱਕ ਆਮ ਖ਼ਾਲੀਪੰਨ ਹੈ। ਹਰ ਕਦਮ ਨਾਲ ਇੱਕ ਵਿਅਕਤੀ ਜਾਂ ਭੂਮਿਕਾ ਜੁੜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਰਿਕਾਰਡ ਕੌਣ ਬਣਾਉਂਦਾ? ਕੌਣ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ? ਸਬਮਿਸ਼ਨ ਤੋਂ ਬਾਅਦ ਕੌਣ ਸੋਧ ਸਕਦਾ? ਕੌਣ ਬੰਦ ਕਰਦਾ? ਜੇ ਇਹ ਜਵਾਬ ਧੁੰਦਲੇ ਹਨ, ਤਾਂ ਐਪ ਅਜਿਹੇ ਅਨਦੇਖੇPermissions ਅਤੇ ਹਥਾਫ਼ੇਜ਼ ਨਾਲ ਖਰਾਬ ਹੋ ਜਾਵੇਗੀ।
ਦੂਜਾ ਨੁਕਸ ਆਮ ਤੌਰ ਤੇ ਕਿਸੇ ਹੋਰ ਐਪ ਦੀ ਨਕਲ ਕਰਨਾ ਹੈ। ਮੱਤਲਬ-ਹੁਣ-ਵਾਲਾ ਉਤਪਾਦ ਜੇ ਤੁਹਾਡੇ ਲੋੜਾਂ ਨਾਲ ਮੈਚ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਦਿਨਾਂ ਬਰਬਾਦ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਮਦਦ ਕਰੇ ਤਾਂ ਪੈਟਰਨ ਲਓ, ਪਰ ਪਹਿਲਾਂ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕਰੋ।
ਇਕ ਸਧਾਰਨ ਟੈਸਟ ਉੱਥੇ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ ਨੂੰ ਇੱਕ ਅਸਲੀ ਉਦਾਹਰਨ, ਕੁਝ ਗੁੰਝਲਦਾਰ ਰਿਕਾਰਡ, ਅਤੇ ਸਪਸ਼ਟ ਯੂਜ਼ਰ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਸਮਝਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਹੋ। ਨਹੀਂ ਤਾਂ, ਹੋਰ ਸਕ੍ਰੀਨਾਂ ਜ਼ਿਆਦਾ ਨਹੀਂ ਠੀਕ ਕਰਨਗੀਆਂ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਗੱਲ-ਬਾਤ ਰੀਅਲ ਕੰਮ ਲਈ ਕਾਫ਼ੀ ਵਿਸ਼ੇਸ਼ ਹੈ ਕਿ ਨਹੀਂ। ਜੇ ਇਨਪੁਟ ਧੁੰਦਲੇ ਹਨ ਤਾਂ ਪਹਿਲਾ ਡਰਾਫਟ ਵੀ ਧੁੰਦਲਾ ਹੋਵੇਗਾ।
ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਟੈਸਟ ਵਜੋਂ ਵਰਤੋ:
ਜੇ ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕੋਈ ਪੁਆਇੰਟ ਅਸਪਸ਼ਟ ਹੈ ਤਾਂ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਇੱਕ ਹੋਰ ਸਵਾਲ ਪੁੱਛੋ, ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ ਜੋੜੋ, ਜਾਂ ਸਮੱਸਿਆ ਬਿਆਨ ਨੂੰ ਤਿੱਖਾ ਕਰੋ।
ਜਦੋਂ ਐਪ ਗੱਲ-ਬਾਤ ਰਾਹੀਂ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਮਾਕਅਪਸ ਦੀ ਥਾਂ, ਤਾਂ ਇਹ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਇਨਪੁਟ ਵਧੀਆ ਹੋਣ ਤਾ ਜੋ ਪਹਿਲਾ ਬਿਲਡ ਵਧੀਆ ਆਏ।
ਜਦੋਂ ਤੁਹਾਡੇ ਨੋਟਸ ਚੈਟ, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਵਾਇਸ ਮੈਮੋ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਛੋਟੇ ਬਿਲਡ ਬ੍ਰੀਫ ਵਿੱਚ ਬਦਲੋ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ: ਸਮੱਸਿਆ, ਕੌਣ ਐਪ ਵਰਤੇਗਾ, 3-5 ਮੁੱਖ ਕਾਰਵਾਈਆਂ, ਕੁਝ ਸੈਂਪਲ ਰਿਕਾਰਡ, ਅਤੇ ਕੋਈ ਅਹੰਕਾਰ ਨਿਯਮ ਜੋ ਭੰਗ ਨਹੀਂ ਹੋਣੇ।
ਇਸ ਪੜਾਅ 'ਚ ਕਈ ਟੀਮ ਖ਼ੁਦ ਨੂੰ ਮੰਦ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਜਦ ਉਹ ਹਰ ਸਕ੍ਰੀਨ ਪਹਿਲਾਂ ਹੀ ਮੰਗਣ ਲੱਗਦੇ ਹਨ। ਇੱਕ ਵਧੀਆ ਕਦਮ ਇਹ ਹੈ ਕਿ ਸਿਰਫ਼ ਕੋਰ ਫਲੋ ਦਾ ਪਹਿਲਾ ਵੈੱਬ ਜਾਂ ਮੋਬਾਇਲ ਡਰਾਫਟ ਮੰਗਿਆ ਜਾਵੇ। ਜੇ ਐਪ ਸਰਵਿਸ ਰਿਕਾਰਡ ਲਈ ਹੈ, ਤਾਂ ਇਹਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ: ਰਿਕਾਰਡ ਜਮ੍ਹਾਂ ਕਰੋ, ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਸਟੇਟਸ ਅਪਡੇਟ ਕਰੋ, ਅਤੇ ਇਤਿਹਾਸ ਵੇਖੋ। ਤੁਹਾਨੁੰ ਦਿਨ ਪਹਿਲਾਂ ਪੂਰਾ ਪ੍ਰੋਡਕਟ ਮੈਪ ਨਹੀਂ ਚਾਹੀਦਾ।
ਇੱਕ ਉਪਯੋਗ ਬ੍ਰੀਫ ਆਮਤੌਰ 'ਤੇ ਇੱਕ ਪੰਨਾ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ:
ਪਹਿਲੇ ਡਰਾਫਟ ਤੋਂ ਬਾਅਦ, ਇਸ ਨੂੰ placeholder ਟੈਕਸਟ ਨਹੀਂ ਬਲਕਿ ਅਸਲੀ ਸੈਂਪਲ ਡੇਟਾ ਨਾਲ ਸਮੀਖਿਆ ਕਰੋ। ਨਾਮ, ਤਾਰਿਖਾਂ, ਸਟੇਟਸ, ਕੀਮਤਾਂ, ਮਨਜ਼ੂਰ ਕਦਮ ਅਤੇ ਐਡਜ ਕੇਸ ਜਲਦੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬੇਨਕਾਬ ਕਰਦੇ ਹਨ। ਇਕ ਡੈਸ਼ਬੋਰਡ ਫੇਕ ਨੰਬਰਾਂ ਨਾਲ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਓਵਰਡਿਊ ਰਿਕਾਰਡ, ਘੱਟ ਫੀਲਡ, ਜਾਂ ਨਕਲਾਂ ਨਾਲ ਟੈਸਟ ਕਰਨ 'ਤੇ ਟੁੱਟ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ planning mode ਬ੍ਰੀਫ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ snapshots ਤੁਹਾਨੂੰ ਬਚਤ ਦਾ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ ਤਾਕਿ ਤੁਸੀਂ ਤਬਦੀਲੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ ਜਾਂ ਵਾਪਸੀ ਕਰ ਸਕੋ ਜੇ ਕੋਈ ਨਵਾਂ ਪ੍ਰੰਪਟ ਬਿਲਡ ਨੂੰ ਗਲਤ ਦਿਸ਼ਾ ਵੱਲ ਲੈ ਜਾਏ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਟੀਮਾਂ ਸ਼ੁਰੂ ਵਿੱਚ ਪੂਰਨਤਾ ਦੀ ਪਿੱਛੇ ਨਹੀਂ ਦੌੜਦੀਆਂ। ਉਹ ਬ੍ਰੀਫ ਲੌਕ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ ਉਪਯੋਗ ਫਲੋ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਸਲੀ ਡੇਟਾ ਨਾਲ ਟੈਸਟ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਕਦਮ-ਦਰ-कਦਮ ਸੁਧਾਰ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਆਮਤੌਰ 'ਤੇ ਵਾਇਰਫਰੇਮ ਬਿਨਾਂ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਲਈ ਅਤੇ ਫਿਰ ਵੀ ਕੁਝ ਸਪਸ਼ਟ, ਉਪਯੋਗੀ ਅਤੇ ਸੁਧਾਰ ਜੋਗ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਹਾਂ। ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਸਮੱਸਿਆ ਬਿਆਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਮੁੱਖ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨਾਮ ਦਿਓ, ਅਤੇ ਇੱਕ ਅਸਲੀ ਵਰਕਫਲੋ ਦੀ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਵਰਣਨਾ ਕਰੋ। ਇਸ ਨਾਲ ਮਾਕਅਪਸ ਦੇ ਬਿਨਾਂ ਵੀ ਇੱਕ ਉਪਯੋਗੀ ਪਹਿਲਾ ਡਰਾਫਟ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਵਿਅਕਤੀ ਨੂੰ ਸਮੱਸਿਆ ਹੈ, ਕੀ ਉਹਨਾਂ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਹ ਕਿਹੜਾ ਨਤੀਜਾ ਚਾਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਵਾਕ ਅਸਪਸ਼ਟ ਹੈ ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਆਮ ਤੌਰ 'ਤੇ ਬੇਤਰਤੀਬ ਫੀਚਰ ਰਿਕਵੈਸਟਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਸਿੱਧਾ ਅਤੇ ਵਰਤੋਂਯੋਗ ਰੱਖੋ। ਅਸਲ ਨੌਕਰੀ ਦੇ ਸਿਰਲੇਖ ਜਾਂ ਫੰਕਸ਼ਨ ਵਰਤੋ, ਫਿਰ ਲਿਖੋ ਕਿ ਉਹ ਵਿਅਕਤੀ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀ ਦੇਖਣਾ ਅਤੇ ਬਦਲਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਪਹਿਲੇ ਵਰਜਨ ਲਈ ਆਮਤੌਰ 'ਤੇ ਦੋ ਤੋਂ ਚਾਰ ਮੁੱਖ ਭੂਮਿਕਾਵਾਂ ਕਾਫ਼ੀ ਹੁੰਦੀਆਂ ਹਨ।
ਆਮ ਤੌਰ 'ਤੇ ਪੰਜ ਤੋਂ ਦਸ ਸੈਂਪਲ ਰਿਕਾਰਡ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਇਹ ਕਾਫੀ ਵੈਰੀਐਸ਼ਨ ਦਿਖਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਘੱਟ ਰਹਿ ਗਏ ਖੇਤਰ, ਸਟੇਟਸ ਬਦਲਾਅ, ਅਤੇ ਅਜਿਹੇ ਕਦਮ ਜੋ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ, ਸਾਹਮਣੇ ਆ ਜਾਣ। ਘੱਟੋ-ਘੱਟ ਇੱਕ ਗੁੰਝਲਦਾਰ ਉਦਾਹਰਨ ਸ਼ਾਮਲ ਕਰੋ, ਸਿਰਫ਼ ਸਾਫ਼ ਰਿਕਾਰਡ ਨਹੀਂ।
ਉਹ ਮੈਦਾਨ ਜੋ ਅਸਲ ਕੰਮ ਵਿੱਚ ਲੋਕ ਵਰਤਦੇ ਹਨ—ਜਿਵੇਂ ਨਾਮ, ਤਾਰਿਖਾਂ, ਸਟੇਟਸ, ਮਾਲਕ, ਨੋਟਸ, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਮਨਜ਼ੂਰੀ ਜਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ। ਮਕਸਦ ਐਪ ਲਾਜਿਕ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਨਾ ਹੈ, ਬੇਦਾਗ ਟੈਸਟ ਡੇਟਾ ਬਣਾਉਣਾ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਸਮੱਸਿਆ ਤੇ, ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਵਰਕਫਲੋ 'ਤੇ ਸਹਿਮਤ ਹੋ ਜਾਵੋ ਤਾਂ ਸਕ्रीनਾਂ ਬਾਰੇ ਸੋਚੋ। ਬਹੁਤ ਪਹਿਲਾਂ ਸਕ੍ਰੀਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਨਾਲ ਅਕਸਰ ਗੁੰਝਲ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਫਲੋ ਦਾ ਅਰਥ ਸਪਸ਼ਟ ਹੋਵੇ, ਤਾਂ ਲੇਆਉਟ ਬਣਾੳ਼ਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਮੁੱਖ ਕੰਮ ਚੁਣੋ ਅਤੇ ਪਹਿਲੇ ਵਰਜਨ ਨੂੰ ਉਸ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਜੇ ਸਾਫਟਵੇਅਰ ਇੱਕ ਦਰਦਨਾਕ ਮੋੜ ਨੂੰ ਅੱਜ ਹੀ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਸ ਹੈ। ਰਿਪੋਰਟਿੰਗ, ਬਿਲਿੰਗ, ਵਧੀਆPermissions ਵਗੈਰਾ ਬਾਅਦ ਲਈ ਰੱਖੋ।
ਉਹ ਸਧਾਰਨ ਨਿਯਮ ਲਿਖੋ ਜੋ ਅਗਲਾ ਕਦਮ ਤੈਅ ਕਰਦੇ ਹਨ। ਆਮ طور 'ਤੇ ਇਸਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ: ਸਟੇਟਸ ਗ੍ਰਹਿਣ, ਮਨਜ਼ੂਰੀਆਂ, ਸੁਚੇਤਾਂ, ਮਿਆਦਾਂ, ਘੱਟ ਹੋਏ ਫੀਲਡ, ਰੁਕੀ ਹੋਈ ਕਾਰਵਾਈ ਅਤੇ ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਕਿਸ ਦੀ ਜੁ਼ਮੇਵਾਰੀ ਹੈ। ਆਮ if-then ਵਾਕਾਂ ਹੀ ਕਾਫ਼ੀ ਹਨ।
ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਸੱਚੇ ਚੀਜ਼ 'ਤੇ ਪ੍ਰਤਿਕਿਰਿਆ ਕਰਨ ਲਈ ਕਹੋ। ਇੱਕ ਸੈਂਪਲ ਰਿਕਾਰਡ, ਇੱਕ ਵਰਕਫਲੋ ਜਾਂ ਇੱਕ ਸਕ੍ਰੀਨ ਸਟੇਟ ਵਿਖਾਓ ਅਤੇ ਪੁੱਛੋ ਕਿ ਅਗਲੇ ਕਦਮ ਕੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਲੋਕ ਜ਼ਿਆਦਾ ਬਿਹਤਰ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਕਿਸੇ ਅਸਲ ਉਦਾਹਰਨ ਤੇ ਰਸਪਾਂਡ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਖਾਲੀ ਵਿਚਾਰ ਤੇ।
planning mode ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਬਿਲਡ ਬ੍ਰੀਫ ਬਣਾਓ: ਸਮੱਸਿਆ, ਭੂਮਿਕਾਵਾਂ, ਮੁੱਖ ਕਾਰਵਾਈਆਂ, ਸੈਂਪਲ ਰਿਕਾਰਡ ਅਤੇ ਕੋਈ ਅਹੰਕਾਰ ਨਿਯਮ। ਫਿਰ ਕੋਰ ਫਲੋ ਦਾ ਪਹਿਲਾ ਡਰਾਫਟ ਬਨਵਾਓ, ਅਸਲੀ ਡੇਟਾ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਜੇ ਨਵਾਂ ਪ੍ਰੰਪਟ ਰਸਤਾ ਭਟਕਾਏ ਤਾਂ snapshots ਨਾਲ ਵਾਪਸੀ ਕਰੋ।