ਇੱਕ ਟੀਮ ਵਿੱਚ ਟਕਰਾਅ ਪ੍ਰਬੰਧਨ - ਇੱਕ ਸੰਤੁਲਨ ਕਾਰਜ ਜਾਂ ਇੱਕ ਜ਼ਰੂਰੀ ਲੋੜ?

ਐਪੀਗ੍ਰਾਫ:
ਇੱਕ ਵਾਰ, ਹੇਜਹੌਗ ਅਤੇ ਛੋਟੇ ਰਿੱਛ ਜੰਗਲ ਵਿੱਚ ਮਿਲੇ ਸਨ.
- ਹੈਲੋ, ਹੇਜਹੌਗ!
- ਹੈਲੋ, ਛੋਟੇ ਰਿੱਛ!
ਇਸ ਲਈ, ਸ਼ਬਦ ਦੁਆਰਾ ਸ਼ਬਦ, ਮਜ਼ਾਕ ਦੁਆਰਾ ਮਜ਼ਾਕ, ਹੇਜਹੌਗ ਛੋਟੇ ਰਿੱਛ ਦੁਆਰਾ ਚਿਹਰੇ 'ਤੇ ਮਾਰਿਆ ਗਿਆ ...

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

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

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

ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਆਮ ਕੀ ਹੈ ਜਿਸ ਨੂੰ ਕੰਮ ਦੇ ਟਕਰਾਅ ਦੀ ਸਥਿਤੀ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?



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

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

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

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

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

ਟਕਰਾਅ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦੀਆਂ ਕੁਝ ਉਦਾਹਰਣਾਂ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਿਆਂ ਨੂੰ ਵੇਖੀਏ ਜੋ ਸਾਰੇ ਵਿਵਾਦਾਂ ਲਈ ਸਾਂਝੇ ਹਨ।

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

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

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

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

ਇਸ ਅਨੁਸਾਰ, ਕਿਸੇ ਟਕਰਾਅ (ਨਾਲ ਹੀ ਕਿਸੇ ਹੋਰ ਮੁੱਦੇ) ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ, ਇੱਕ ਪ੍ਰਬੰਧਕ ਨੂੰ ਤਿੰਨ ਦ੍ਰਿਸ਼ਟੀਕੋਣਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ: ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ - ਇੱਥੇ ਅਤੇ ਹੁਣ ਮੁੱਦੇ/ਅਪਵਾਦ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਮੱਧਮ-ਮਿਆਦ - ਇੱਕ ਹੋਰ ਵਿਵਾਦ ਪੈਦਾ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ। ਇਸੇ ਕਾਰਨ ਕਰਕੇ, ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ - ਟੀਮ ਵਿਅਕਤੀ ਵਿੱਚ ਇੱਕ ਬਾਲਗ ਸੱਭਿਆਚਾਰ ਪੈਦਾ ਕਰਨ ਲਈ.

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

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

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

ਆਉ ਸਧਾਰਨ ਤੋਂ ਗੁੰਝਲਦਾਰ ਤੱਕ, ਕਈ ਆਮ ਸੰਘਰਸ਼ ਸਥਿਤੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ:

ਮਤਭੇਦ ਕੰਮ ਦੇ ਮੁੱਦਿਆਂ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ

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

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

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

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

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

ਇੱਕ ਟੀਮ ਸੱਭਿਆਚਾਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਇੱਕ ਪਰਿਪੱਕ ਸੱਭਿਆਚਾਰ ਵਾਲੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਲੋਕ ਟੀਮ ਅਤੇ ਸਹਿਕਰਮੀਆਂ ਦਾ ਆਦਰ ਕਰਦੇ ਹਨ ਅਤੇ ਜਾਣਦੇ ਹਨ ਕਿ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਮੁੱਦਿਆਂ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਜਿਹੇ ਮਤਭੇਦਾਂ ਨੂੰ ਉਹਨਾਂ ਟੀਮਾਂ ਵਿੱਚ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ (ਅਕਸਰ ਆਪਣੇ ਆਪ) ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਉੱਚ ਪੱਧਰ ਦਾ ਭਰੋਸਾ ਹੁੰਦਾ ਹੈ, ਲੋਕਾਂ ਨੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਇਕੱਠੇ ਕੰਮ ਕੀਤਾ ਹੈ ਅਤੇ/ਜਾਂ ਕੰਮ ਤੋਂ ਬਾਹਰ ਅਕਸਰ ਸੰਚਾਰ ਕਰਦੇ ਹਨ।

ਕੰਮ ਦੇ ਮੁੱਦਿਆਂ ਨਾਲ ਸਬੰਧਤ ਵਿਵਾਦ:

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

ਮੈਂ ਇੱਥੇ ਦੋ ਆਮ ਕੇਸਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰਾਂਗਾ:

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

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

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

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

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

ਸਾਡੀ ਚਰਚਾ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੱਤੀ (ਬਹੁਤ ਹੀ ਯੋਜਨਾਬੱਧ, ਬੇਸ਼ਕ, ਗੱਲਬਾਤ ਅੱਧੇ ਘੰਟੇ ਤੱਕ ਚੱਲੀ):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਸਰੋਤ: www.habr.com