ਇੱਕ IT ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਇੱਕ ਟੀਮ ਵਿੱਚ ਵਰਕਫਲੋ ਦਾ ਸੰਗਠਨ

ਹੈਲੋ ਦੋਸਤੋ. ਅਕਸਰ, ਖਾਸ ਕਰਕੇ ਆਊਟਸੋਰਸਿੰਗ ਵਿੱਚ, ਮੈਂ ਉਹੀ ਤਸਵੀਰ ਵੇਖਦਾ ਹਾਂ. ਵੱਖ-ਵੱਖ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਟੀਮਾਂ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਵਰਕਫਲੋ ਦੀ ਘਾਟ.

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

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

ਇੱਕ ਸਮੇਂ, ਮੈਂ ਇੱਕ ਅਜਿਹੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਗਿਆ, ਜਿੱਥੇ ਇਹ ਸਾਰੀਆਂ ਖੁਸ਼ੀਆਂ ਸਨ.

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

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

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

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

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

ਪ੍ਰੋਜੈਕਟ "ਮੇਰਾ ਮਨਪਸੰਦ ਪ੍ਰੋਜੈਕਟ" 'ਤੇ ਟੀਮ ਦੇ ਕੰਮ ਦੀ ਪ੍ਰਕਿਰਿਆ

a) ਇੱਕ ਟੀਮ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ (ਡਿਵੈਲਪਰਾਂ ਵਿਚਕਾਰ)

• ਸਾਰੇ ਕਾਰਜ ਜੀਰਾ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਣਾਏ ਜਾਂਦੇ ਹਨ
• ਹਰੇਕ ਕੰਮ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਵਰਣਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਖਤੀ ਨਾਲ ਇੱਕ ਕਾਰਵਾਈ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
• ਕੋਈ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ, ਜੇ ਇਹ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹੈ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਕੰਮਾਂ ਵਿੱਚ ਵੰਡੀ ਜਾਂਦੀ ਹੈ
• ਟੀਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਇੱਕ ਸਿੰਗਲ ਟਾਸਕ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਪਹਿਲਾਂ, ਅਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਇਕੱਠੇ ਕਰਦੇ ਹਾਂ, ਇਸਨੂੰ ਟੈਸਟਿੰਗ ਲਈ ਦਿੰਦੇ ਹਾਂ, ਫਿਰ ਅਗਲੀ ਨੂੰ ਲੈਂਦੇ ਹਾਂ।
• ਹਰੇਕ ਕੰਮ ਨੂੰ ਬੈਕਐਂਡ ਜਾਂ ਫਰੰਟਐਂਡ ਲਈ ਲੇਬਲ ਕੀਤਾ ਗਿਆ ਹੈ
• ਕੰਮ ਅਤੇ ਬੱਗ ਦੀਆਂ ਕਿਸਮਾਂ ਹਨ। ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਕੰਮ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਸਨੂੰ ਕੋਡ ਸਮੀਖਿਆ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ (ਇਸਦੇ ਸਹਿਯੋਗੀ ਲਈ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ)
• ਜਿਸ ਨੇ ਕੰਮ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ ਉਹ ਤੁਰੰਤ ਇਸ ਕੰਮ ਲਈ ਆਪਣੇ ਸਮੇਂ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ
• ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, PR ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ, ਜਿਸ ਨੇ ਇਸ ਕੰਮ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੀਤਾ ਹੈ, ਉਹ ਇਸਨੂੰ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਮਿਲਾਉਂਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਆਪਣੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਕੇ dev ਸਰਵਰ ਲਈ ਤੈਨਾਤ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ ਜਾਂਦਾ ਹੈ।
• dev ਸਰਵਰ 'ਤੇ ਤੈਨਾਤ ਕੀਤੇ ਜਾਣ ਲਈ ਤਿਆਰ ਸਾਰੇ ਕੰਮ ਟੀਮ ਲੀਡਰ (ਉਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਖੇਤਰ), ਕਈ ਵਾਰ ਟੀਮ ਦੇ ਮੈਂਬਰ ਦੁਆਰਾ ਤੈਨਾਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੇ ਕੁਝ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ, ਤੈਨਾਤੀ ਲਈ ਤਿਆਰ ਤੋਂ ਲੈ ਕੇ dev ਤੱਕ ਸਾਰੇ ਕਾਰਜ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦੇ ਹਨ - dev 'ਤੇ ਜਾਂਚ ਲਈ ਤਿਆਰ
• ਸਾਰੇ ਕੰਮ ਗਾਹਕ ਦੁਆਰਾ ਟੈਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
• ਜਦੋਂ ਗਾਹਕ ਨੇ dev 'ਤੇ ਕੰਮ ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਉਤਪਾਦਨ ਲਈ ਤੈਨਾਤੀ ਲਈ ਤਿਆਰ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦਾ ਹੈ।
• ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤੀ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਵੱਖਰੀ ਸ਼ਾਖਾ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਤੈਨਾਤੀ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਮਾਸਟਰ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਾਂ
• ਜੇਕਰ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਗਾਹਕ ਨੂੰ ਬੱਗ ਮਿਲਦੇ ਹਨ, ਤਾਂ ਉਹ ਸੰਸ਼ੋਧਨ ਲਈ ਕੰਮ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਸੰਸ਼ੋਧਨ ਲਈ ਵਾਪਸ ਕੀਤੀ ਸਥਿਤੀ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਨਵੇਂ ਕੰਮਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ।
• ਨਤੀਜੇ ਵਜੋਂ, ਸਾਰੇ ਕਾਰਜ ਰਚਨਾ ਤੋਂ ਮੁਕੰਮਲ ਹੋਣ ਤੱਕ ਜਾਂਦੇ ਹਨ: ਕਰਨ ਲਈ → ਵਿਕਾਸ ਵਿੱਚ → ਕੋਡ ਸਮੀਖਿਆ → dev 'ਤੇ ਤਿਆਰ → QA on dev → (dev 'ਤੇ ਵਾਪਸ ਜਾਓ) → ਉਤਪਾਦ ਲਈ ਤਿਆਰ → ਉਤਪਾਦ 'ਤੇ QA → ਹੋ ਗਿਆ
• ਹਰੇਕ ਡਿਵੈਲਪਰ ਆਪਣੇ ਕੋਡ ਦੀ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਾਈਟ ਦੇ ਉਪਭੋਗਤਾ ਵਜੋਂ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਕਿਸੇ ਬ੍ਰਾਂਚ ਨੂੰ ਮੁੱਖ ਬ੍ਰਾਂਚ ਨਾਲ ਮਿਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੋਡ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਹਰ ਕੰਮ ਦੀਆਂ ਤਰਜੀਹਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਤਰਜੀਹਾਂ ਜਾਂ ਤਾਂ ਗਾਹਕ ਜਾਂ ਟੀਮ ਲੀਡਰ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਤਰਜੀਹੀ ਕੰਮ ਕਰਦੇ ਹਨ।
• ਡਿਵੈਲਪਰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕੰਮ ਸੌਂਪ ਸਕਦੇ ਹਨ ਜੇਕਰ ਸਿਸਟਮ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਬੱਗ ਪਾਏ ਜਾਂਦੇ ਹਨ ਜਾਂ ਇੱਕ ਕੰਮ ਵਿੱਚ ਕਈ ਮਾਹਰਾਂ ਦਾ ਕੰਮ ਹੁੰਦਾ ਹੈ।
• ਗਾਹਕ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਸਾਰੇ ਕੰਮ ਟੀਮ ਲੀਡਰ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਉਹਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਅਤੇ ਜਾਂ ਤਾਂ ਗਾਹਕ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਲਈ ਕਹਿੰਦਾ ਹੈ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਟੀਮ ਦੇ ਕਿਸੇ ਇੱਕ ਮੈਂਬਰ ਨੂੰ ਸੌਂਪਦਾ ਹੈ।
• ਸਾਰੇ ਕੰਮ ਜੋ dev ਜਾਂ prod ਲਈ ਤੈਨਾਤ ਕੀਤੇ ਜਾਣ ਲਈ ਤਿਆਰ ਹਨ, ਟੀਮ ਲੀਡਰ ਨੂੰ ਵੀ ਮਿਲਦੇ ਹਨ, ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ ਤੈਨਾਤ ਕਰਨਾ ਹੈ। ਹਰੇਕ ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ, ਟੀਮ ਲੀਡਰ (ਜਾਂ ਟੀਮ ਮੈਂਬਰ) ਨੂੰ ਇਸ ਬਾਰੇ ਗਾਹਕ ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ dev/prod 'ਤੇ ਟੈਸਟਿੰਗ ਲਈ ਤਿਆਰ ਕੰਮਾਂ ਲਈ ਸਥਿਤੀਆਂ ਨੂੰ ਵੀ ਬਦਲੋ।
• ਹਰ ਰੋਜ਼ ਉਸੇ ਸਮੇਂ (ਸਾਡੇ ਕੋਲ ਇਹ 12.00 ਵਜੇ ਹੁੰਦਾ ਹੈ) ਅਸੀਂ ਸਾਰੇ ਟੀਮ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਇੱਕ ਰੈਲੀ ਕਰਦੇ ਹਾਂ
• ਰੈਲੀ ਵਿਚ ਟੀਮ ਲੀਡਰ ਸਮੇਤ ਹਰ ਕੋਈ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਉਸਨੇ ਕੱਲ ਕੀ ਕੀਤਾ, ਅੱਜ ਉਹ ਕੀ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਹੈ। ਕੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਕਿਉਂ। ਇਸ ਤਰ੍ਹਾਂ, ਪੂਰੀ ਟੀਮ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਕਿਸ ਪੜਾਅ 'ਤੇ ਹੈ। ਇਹ ਸਾਨੂੰ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਅਤੇ ਅਨੁਕੂਲਿਤ ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦਾ ਹੈ, ਜੇ ਲੋੜ ਹੋਵੇ, ਸਾਡੇ ਅਨੁਮਾਨਾਂ ਅਤੇ ਸਮਾਂ ਸੀਮਾਵਾਂ।
• ਮੀਟਿੰਗ ਵਿੱਚ, ਟੀਮ ਲੀਡਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਾਰੇ ਬਦਲਾਅ ਅਤੇ ਮੌਜੂਦਾ ਬੱਗ ਦੇ ਪੱਧਰ ਦੀ ਘੋਸ਼ਣਾ ਕਰਦਾ ਹੈ ਜੋ ਗਾਹਕ ਦੁਆਰਾ ਨਹੀਂ ਲੱਭੇ ਗਏ ਸਨ। ਸਾਰੇ ਬੱਗਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਹਰੇਕ ਟੀਮ ਦੇ ਮੈਂਬਰ ਨੂੰ ਸੌਂਪਿਆ ਜਾਂਦਾ ਹੈ।
• ਰੈਲੀ ਵਿੱਚ, ਟੀਮ ਲੀਡਰ ਡਿਵੈਲਪਰਾਂ ਦੇ ਮੌਜੂਦਾ ਕੰਮ ਦੇ ਬੋਝ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਉਹਨਾਂ ਦੇ ਪੇਸ਼ੇਵਰ ਸਿਖਲਾਈ ਦੇ ਪੱਧਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਤੇ ਇੱਕ ਖਾਸ ਕੰਮ ਦੀ ਨੇੜਤਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਹਰੇਕ ਲਈ ਕਾਰਜ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜੋ ਡਿਵੈਲਪਰ ਵਰਤਮਾਨ ਵਿੱਚ ਕਰ ਰਿਹਾ ਹੈ।
• ਮੀਟਿੰਗ ਵਿੱਚ, ਟੀਮ ਲੀਡਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਲਈ ਇੱਕ ਆਮ ਰਣਨੀਤੀ ਵਿਕਸਿਤ ਕਰਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ, ਪੂਰੀ ਟੀਮ ਇਸ 'ਤੇ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਕਰਦੀ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਵਿਵਸਥਾ ਕਰਨੀ ਹੈ ਜਾਂ ਇਸ ਰਣਨੀਤੀ ਨੂੰ ਅਪਣਾਉਣਾ ਹੈ।
• ਹਰੇਕ ਡਿਵੈਲਪਰ ਕੋਡ ਲਿਖਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਦੇ ਅੰਦਰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਐਲਗੋਰਿਦਮ ਬਣਾਉਂਦਾ ਹੈ। ਹਰ ਕੋਈ ਲਾਗੂ ਕਰਨ ਦੇ ਆਪਣੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੂੰ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਕਿਸੇ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਹੋਰ ਨਹੀਂ। ਹਰ ਫੈਸਲਾ ਜਾਇਜ਼ ਹੈ। ਜੇ ਇੱਕ ਬਿਹਤਰ ਹੱਲ ਹੈ, ਪਰ ਹੁਣ ਇਸਦੇ ਲਈ ਕੋਈ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੋਡ ਦੇ ਇੱਕ ਖਾਸ ਹਿੱਸੇ ਦੇ ਭਵਿੱਖ ਵਿੱਚ ਰੀਫੈਕਟਰਿੰਗ ਲਈ, ਚਰਬੀ ਵਿੱਚ ਇੱਕ ਕੰਮ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ.
• ਜਦੋਂ ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ ਕੰਮ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਵਿਕਾਸ ਸਥਿਤੀ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ। ਗਾਹਕ ਦੇ ਨਾਲ ਕੰਮ ਦੇ ਸਪਸ਼ਟੀਕਰਨ ਸੰਬੰਧੀ ਸਾਰੇ ਸੰਚਾਰ ਡਿਵੈਲਪਰ ਦੇ ਮੋਢੇ 'ਤੇ ਆਉਂਦੇ ਹਨ. ਟੀਮ ਲੀਡਰ ਜਾਂ ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਤਕਨੀਕੀ ਸਵਾਲ ਪੁੱਛੇ ਜਾ ਸਕਦੇ ਹਨ।
• ਜੇ ਡਿਵੈਲਪਰ ਕੰਮ ਦੇ ਸਾਰ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ, ਅਤੇ ਗਾਹਕ ਸਮਝਦਾਰੀ ਨਾਲ ਇਸ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਅਗਲੇ ਕੰਮ ਲਈ ਅੱਗੇ ਵਧਦਾ ਹੈ. ਅਤੇ ਟੀਮ ਲੀਡਰ ਮੌਜੂਦਾ ਨੂੰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਗਾਹਕ ਨਾਲ ਇਸ ਬਾਰੇ ਚਰਚਾ ਕਰਦਾ ਹੈ।
• ਹਰ ਰੋਜ਼, ਡਿਵੈਲਪਰ ਨੂੰ ਕਲਾਇੰਟ ਦੀ ਚੈਟ ਵਿੱਚ ਇਹ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਸਨੇ ਕੱਲ੍ਹ ਕਿਹੜੇ ਕੰਮਾਂ 'ਤੇ ਕੰਮ ਕੀਤਾ ਸੀ ਅਤੇ ਉਹ ਅੱਜ ਕਿਹੜੇ ਕੰਮਾਂ 'ਤੇ ਕੰਮ ਕਰੇਗਾ।
• ਵਰਕਫਲੋ ਸਕ੍ਰਮ 'ਤੇ ਅਧਾਰਤ ਹੈ। ਹਰ ਚੀਜ਼ ਨੂੰ ਸਪ੍ਰਿੰਟਸ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ. ਹਰ ਸਪ੍ਰਿੰਟ ਦੋ ਹਫ਼ਤੇ ਚੱਲਦਾ ਹੈ।
• ਟੀਮ ਲੀਡਰ ਦੁਆਰਾ ਸਪ੍ਰਿੰਟ ਬਣਾਏ, ਭਰੇ ਅਤੇ ਬੰਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
• ਜੇ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਸਖਤ ਸਮਾਂ ਸੀਮਾਵਾਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਸਾਰੇ ਕੰਮਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ. ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਤੋਂ ਇੱਕ ਸਪ੍ਰਿੰਟ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ. ਜੇਕਰ ਗਾਹਕ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਹੋਰ ਕੰਮ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਤਰਜੀਹਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਕੁਝ ਹੋਰ ਕਾਰਜਾਂ ਨੂੰ ਅਗਲੇ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਾਂ।

b) ਗਾਹਕ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ

• ਹਰੇਕ ਡਿਵੈਲਪਰ ਗਾਹਕ ਨਾਲ ਸੰਚਾਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
• ਤੁਸੀਂ ਗਾਹਕ ਨੂੰ ਖੇਡ ਦੇ ਆਪਣੇ ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਗਾਹਕ ਨੂੰ ਇਹ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਇੱਕ ਨਿਮਰ ਅਤੇ ਦੋਸਤਾਨਾ ਢੰਗ ਨਾਲ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਖੇਤਰ ਵਿੱਚ ਮਾਹਰ ਹਾਂ, ਅਤੇ ਕੇਵਲ ਸਾਨੂੰ ਕੰਮ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਣਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਗਾਹਕ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਇਹ ਜ਼ਰੂਰੀ ਹੈ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਕਿਸੇ ਵੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ (ਵਰਕਫਲੋ) ਲਈ ਸਮੁੱਚੀ ਲਾਜ਼ੀਕਲ ਪ੍ਰਕਿਰਿਆ ਦਾ ਫਲੋਚਾਰਟ ਬਣਾਉਣਾ। ਅਤੇ ਪੁਸ਼ਟੀ ਲਈ ਗਾਹਕ ਨੂੰ ਭੇਜੋ. ਇਹ ਸਿਰਫ ਗੁੰਝਲਦਾਰ ਅਤੇ ਸਪੱਸ਼ਟ ਕਾਰਜਕੁਸ਼ਲਤਾ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ, ਇੱਕ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀ, ਆਦਿ। ਇਹ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਸਟੀਕਤਾ ਨਾਲ ਸਮਝਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ ਕਿ ਗਾਹਕ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ, ਅਤੇ ਇਸ ਤੱਥ ਦੇ ਵਿਰੁੱਧ ਆਪਣੇ ਆਪ ਦਾ ਬੀਮਾ ਵੀ ਕਰੋ ਕਿ ਗਾਹਕ ਭਵਿੱਖ ਵਿੱਚ ਕਹਿ ਸਕਦਾ ਹੈ ਕਿ ਅਸੀਂ ਉਹ ਨਹੀਂ ਕੀਤਾ ਜੋ ਉਸਨੇ ਕਿਹਾ ਹੈ।
• ਸਾਰੇ ਚਿੱਤਰ/ਫਲੋਚਾਰਟ/ਤਰਕ ਆਦਿ। ਅਸੀਂ ਕਨਫਲੂਏਂਸ/ਫੈਟ ਵਿੱਚ ਬਚਤ ਕਰਦੇ ਹਾਂ, ਜਿੱਥੇ ਅਸੀਂ ਗਾਹਕ ਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਭਵਿੱਖ ਦੇ ਲਾਗੂ ਕਰਨ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ।
• ਅਸੀਂ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਨਾਲ ਗਾਹਕ 'ਤੇ ਬੋਝ ਨਾ ਪਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਗਾਹਕ ਕਿਵੇਂ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਫਲੋਚਾਰਟ ਦੇ ਰੂਪ ਵਿੱਚ ਮੁੱਢਲੇ ਐਲਗੋਰਿਦਮ ਖਿੱਚਦੇ ਹਾਂ ਜਿਸ ਨੂੰ ਗਾਹਕ ਸਮਝ ਸਕਦਾ ਹੈ ਅਤੇ ਖੁਦ ਹਰ ਚੀਜ਼ ਨੂੰ ਠੀਕ / ਸੋਧ ਸਕਦਾ ਹੈ।
• ਜੇ ਗਾਹਕ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕੋਈ ਬੱਗ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਤੁਹਾਨੂੰ ਫੈਟ ਵਿੱਚ ਇਸ ਨੂੰ ਬਹੁਤ ਵਿਸਥਾਰ ਵਿੱਚ ਵਰਣਨ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ। ਇਹ ਕਿਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਹੋਇਆ, ਕਦੋਂ, ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਗਾਹਕ ਦੁਆਰਾ ਕਾਰਵਾਈਆਂ ਦਾ ਕੀ ਕ੍ਰਮ ਕੀਤਾ ਗਿਆ ਸੀ। ਕਿਰਪਾ ਕਰਕੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨੱਥੀ ਕਰੋ।
• ਅਸੀਂ ਹਰ ਦਿਨ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਵੱਧ ਤੋਂ ਵੱਧ ਹਰ ਦੂਜੇ ਦਿਨ, dev ਸਰਵਰ 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ। ਗਾਹਕ ਫਿਰ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨਿਸ਼ਕਿਰਿਆ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਇਹ ਗਾਹਕ ਲਈ ਇੱਕ ਮਾਰਕਰ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਪੂਰੇ ਵਿਕਾਸ ਵਿੱਚ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਉਸਨੂੰ ਪਰੀ ਕਹਾਣੀਆਂ ਨਹੀਂ ਦੱਸ ਰਿਹਾ ਹੈ.
• ਇਹ ਅਕਸਰ ਹੁੰਦਾ ਹੈ ਕਿ ਗਾਹਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦਾ ਕਿ ਉਸਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ. ਕਿਉਂਕਿ ਉਹ ਆਪਣੇ ਲਈ ਇੱਕ ਨਵਾਂ ਕਾਰੋਬਾਰ ਬਣਾਉਂਦਾ ਹੈ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਨਾਲ ਜੋ ਅਜੇ ਤੱਕ ਡੀਬੱਗ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਇਸ ਲਈ, ਇੱਕ ਬਹੁਤ ਹੀ ਆਮ ਮਾਮਲਾ ਹੈ ਜਦੋਂ ਅਸੀਂ ਕੋਡ ਦੇ ਪੂਰੇ ਟੁਕੜਿਆਂ ਨੂੰ ਰੱਦੀ ਵਿੱਚ ਸੁੱਟ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਨੂੰ ਮੁੜ ਆਕਾਰ ਦਿੰਦੇ ਹਾਂ। ਇਸ ਤੋਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਟੈਸਟਾਂ ਨਾਲ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਵਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ. ਟੈਸਟਾਂ ਨਾਲ, ਅਤੇ ਫਿਰ ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਦੇ ਨਾਲ ਸਿਰਫ ਨਾਜ਼ੁਕ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਕਵਰ ਕਰਨਾ ਸਮਝਦਾਰੀ ਰੱਖਦਾ ਹੈ।
• ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਟੀਮ ਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਮਾਂ ਸੀਮਾ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ। ਫਿਰ ਅਸੀਂ ਕਾਰਜਾਂ ਦਾ ਤੁਰੰਤ ਆਡਿਟ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਤੁਰੰਤ ਗਾਹਕ ਨੂੰ ਇਸ ਬਾਰੇ ਸੂਚਿਤ ਕਰਦੇ ਹਾਂ। ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦੇ ਤਰੀਕੇ ਵਜੋਂ, ਅਸੀਂ ਸਮੇਂ ਸਿਰ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਨਾਜ਼ੁਕ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ, ਅਤੇ ਬਾਕੀ ਨੂੰ ਪੋਸਟ-ਰਿਲੀਜ਼ ਲਈ ਛੱਡਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦੇ ਹਾਂ।
• ਜੇ ਗਾਹਕ ਆਪਣੇ ਸਿਰ ਤੋਂ ਵੱਖੋ-ਵੱਖਰੇ ਕੰਮਾਂ ਨਾਲ ਆਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਆਪਣੀਆਂ ਉਂਗਲਾਂ 'ਤੇ ਕਲਪਨਾ ਕਰਨਾ ਅਤੇ ਵਿਆਖਿਆ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਉਸਨੂੰ ਇੱਕ ਪੰਨਾ ਲੇਆਉਟ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਤਰਕ ਨਾਲ ਪ੍ਰਵਾਹ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ ਜੋ ਪੂਰੇ ਖਾਕੇ ਅਤੇ ਇਸਦੇ ਤੱਤਾਂ ਦੇ ਵਿਵਹਾਰ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਕੋਈ ਵੀ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਸਾਡੇ ਸਮਝੌਤੇ / ਇਕਰਾਰਨਾਮੇ ਦੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਸੀ। ਜੇਕਰ ਇਹ ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਸਾਡੇ ਸ਼ੁਰੂਆਤੀ ਸਮਝੌਤਿਆਂ ਤੋਂ ਪਰੇ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਚਾਹੀਦਾ ਹੈ (ਲਗਭਗ ਲੀਡ ਟਾਈਮ + 30%) x 2) ਅਤੇ ਗਾਹਕ ਨੂੰ ਇਹ ਸੰਕੇਤ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਸਾਨੂੰ ਇੰਨਾ ਸਮਾਂ ਲੱਗੇਗਾ, ਨਾਲ ਹੀ ਅੰਤਮ ਤਾਰੀਖ ਨੂੰ ਦੋ ਨਾਲ ਗੁਣਾ ਕਰਕੇ ਅਨੁਮਾਨਿਤ ਸਮੇਂ ਨਾਲ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ। ਆਓ ਕੰਮ ਨੂੰ ਤੇਜ਼ ਕਰੀਏ - ਬਹੁਤ ਵਧੀਆ, ਹਰ ਕੋਈ ਇਸ ਤੋਂ ਲਾਭ ਉਠਾਏਗਾ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਅਸੀਂ ਬੀਮਾਯੁਕਤ ਹਾਂ।

c) ਅਸੀਂ ਟੀਮ ਵਿੱਚ ਕੀ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦੇ:

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

ਅਤੇ ਕਈ ਸਵਾਲ / ਥੀਸਸ ਜੋ ਮੈਂ ਕਈ ਵਾਰ ਆਪਣੇ ਗਾਹਕ ਨੂੰ ਸਾਰੀਆਂ ਗਲਤਫਹਿਮੀਆਂ ਦੂਰ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹਾਂ:

1. ਤੁਹਾਡੇ ਗੁਣਵੱਤਾ ਦੇ ਮਾਪਦੰਡ ਕੀ ਹਨ?
2. ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ ਕਿ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜਾਂ ਨਹੀਂ?
3. ਸਿਸਟਮ ਨੂੰ ਬਦਲਣ/ਸੁਧਾਰ ਕਰਨ ਬਾਰੇ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਅਤੇ ਸਲਾਹਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹੋਏ, ਸਾਰੇ ਜੋਖਮ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸਹਿਣ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
4. ਕੋਈ ਵੀ ਵੱਡੀ ਪ੍ਰੋਜੈਕਟ ਤਬਦੀਲੀਆਂ (ਉਦਾਹਰਨ ਲਈ, ਹਰ ਕਿਸਮ ਦੇ ਵਾਧੂ ਵਹਾਅ) ਬੱਗਾਂ ਦੀ ਸੰਭਾਵਤ ਦਿੱਖ ਵੱਲ ਲੈ ਜਾਣਗੇ (ਜਿਸ ਨੂੰ ਅਸੀਂ, ਬੇਸ਼ਕ, ਠੀਕ ਕਰਾਂਗੇ)
5. ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਆਈ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੀ ਵੱਧ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ
6. ਅਸੀਂ ਇੱਕ ਖਾਸ ਉਤਪਾਦ ਪ੍ਰਵਾਹ (Zhira ਵਿੱਚ ਕੰਮ - ਵਿਕਾਸ - ਟੈਸਟਿੰਗ - ਤੈਨਾਤ) 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਚੈਟ ਵਿੱਚ ਬੇਨਤੀਆਂ ਅਤੇ ਸ਼ਿਕਾਇਤਾਂ ਦੇ ਪੂਰੇ ਪ੍ਰਵਾਹ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ ਹਾਂ।
7. ਪ੍ਰੋਗਰਾਮਰ ਸਿਰਫ਼ ਪ੍ਰੋਗਰਾਮਰ ਹਨ, ਪੇਸ਼ੇਵਰ ਟੈਸਟਰ ਨਹੀਂ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਟੈਸਟਿੰਗ ਦੀ ਸਹੀ ਗੁਣਵੱਤਾ ਨੂੰ ਯਕੀਨੀ ਨਹੀਂ ਬਣਾ ਸਕਦੇ
8. ਵਿਕਰੀ 'ਤੇ ਅੰਤਿਮ ਜਾਂਚ ਅਤੇ ਕਾਰਜਾਂ ਦੀ ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ 'ਤੇ ਹੈ
9. ਜੇਕਰ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੋਈ ਕੰਮ ਲੈ ਲਿਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਤੁਰੰਤ ਹੋਰਾਂ 'ਤੇ ਸਵਿਚ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਮੌਜੂਦਾ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦੇ (ਨਹੀਂ ਤਾਂ ਇਸ ਨਾਲ ਹੋਰ ਵੀ ਬੱਗ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵਿਕਾਸ ਦੇ ਸਮੇਂ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ)
10. ਟੀਮ ਵਿੱਚ ਘੱਟ ਲੋਕ ਹਨ (ਛੁੱਟੀਆਂ ਜਾਂ ਬੀਮਾਰੀਆਂ ਕਾਰਨ), ਅਤੇ ਕੰਮ ਜ਼ਿਆਦਾ ਹੈ ਅਤੇ ਸਾਡੇ ਕੋਲ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਹਰ ਚੀਜ਼ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ।
11. ਤੁਹਾਨੂੰ dev 'ਤੇ ਟੈਸਟ ਕੀਤੇ ਕੰਮਾਂ ਤੋਂ ਬਿਨਾਂ ਉਤਪਾਦਨ 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ ਕਹਿਣਾ ਸਿਰਫ ਤੁਹਾਡਾ ਜੋਖਮ ਹੈ, ਨਾ ਕਿ ਵਿਕਾਸਕਾਰ ਦਾ
12. ਜਦੋਂ ਤੁਸੀਂ ਅਸਪਸ਼ਟ ਕਾਰਜਾਂ ਨੂੰ, ਸਹੀ ਪ੍ਰਵਾਹ ਦੇ ਬਿਨਾਂ, ਡਿਜ਼ਾਈਨ ਲੇਆਉਟ ਦੇ ਬਿਨਾਂ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸ ਲਈ ਸਾਡੇ ਤੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਿਹਨਤ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੇ ਸਮੇਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਤੁਹਾਡੀ ਬਜਾਏ ਵਾਧੂ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
13. ਬੱਗ 'ਤੇ ਕੋਈ ਵੀ ਕੰਮ, ਉਹਨਾਂ ਦੀ ਮੌਜੂਦਗੀ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ੌਟਸ ਦੇ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਤੋਂ ਬਿਨਾਂ, ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਦਾ ਮੌਕਾ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਕੀ ਗਲਤ ਹੋਇਆ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸ ਬੱਗ ਨੂੰ ਕਿਵੇਂ ਬਾਹਰ ਕੱਢ ਸਕਦੇ ਹਾਂ।
14. ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਨਿਰੰਤਰ ਸੁਧਾਰ ਅਤੇ ਸੁਧਾਰਾਂ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਲਈ, ਟੀਮ ਆਪਣਾ ਕੁਝ ਸਮਾਂ ਇਹਨਾਂ ਸੁਧਾਰਾਂ 'ਤੇ ਖਰਚ ਕਰਦੀ ਹੈ।
15. ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਸਾਡੇ ਕੋਲ ਓਵਰਟਾਈਮ ਘੰਟੇ (ਜ਼ਰੂਰੀ ਫਿਕਸ) ਹਨ, ਸਾਨੂੰ ਦੂਜੇ ਦਿਨਾਂ ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਮੁਆਵਜ਼ਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ

ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਗਾਹਕ ਤੁਰੰਤ ਸਮਝ ਲੈਂਦਾ ਹੈ ਕਿ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਵਿੱਚ ਸਭ ਕੁਝ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਕੱਲੀ ਇੱਛਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ.

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

PS ਮੈਂ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਸਾਡੇ ਪਾਸੇ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ ਨਹੀਂ ਹੈ। ਇਹ ਗਾਹਕ ਦੇ ਪਾਸੇ ਹੈ. ਬਿਲਕੁਲ ਵੀ ਤਕਨੀਕੀ ਨਹੀਂ। ਯੂਰਪੀਅਨ ਪ੍ਰੋਜੈਕਟ. ਸਾਰਾ ਸੰਚਾਰ ਕੇਵਲ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਹੈ।

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

ਮੇਰੇ ਵਿੱਚ ਸਰੋਤ ਬਲਾੱਗ ਪੋਸਟ.

ਸਰੋਤ: www.habr.com