ਵਿਕਾਸ ਟੀਮ ਵਿੱਚ "ਯੂਨੀਵਰਸਲ": ਲਾਭ ਜਾਂ ਨੁਕਸਾਨ?

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

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

ਉਹ ਕੌਣ ਹੈ, ਸਾਡੀਆਂ ਉਮੀਦਾਂ ਦਾ ਮੋਹਰੀ?

ਸ਼ਬਦ "ਜਨਰਲਿਸਟ" ਆਮ ਤੌਰ 'ਤੇ ਟੀਮ ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਇੱਕ ਤੋਂ ਵੱਧ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਡਿਵੈਲਪਰ-ਵਿਸ਼ਲੇਸ਼ਕ।

ਟੀਮ ਦੀ ਆਪਸੀ ਤਾਲਮੇਲ ਅਤੇ ਇਸਦੇ ਕੰਮ ਦਾ ਨਤੀਜਾ ਭਾਗੀਦਾਰਾਂ ਦੇ ਪੇਸ਼ੇਵਰ ਅਤੇ ਨਿੱਜੀ ਗੁਣਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

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

1. "ਸਰਬ-ਸ਼ਕਤੀਮਾਨ"

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

ਉਹ ਕਿਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​​​ਹਨ:

• ਗੁੰਝਲਦਾਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹਨ;
• ਸਮੱਸਿਆ ਵਿੱਚ ਡੂੰਘਾਈ ਨਾਲ ਡੁੱਬੋ, "ਖੋਦੋ" ਅਤੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰੋ;
• ਇੱਕ ਖੋਜੀ ਮਨ ਹੈ.

ਪਰ:

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

2. "ਯੂਨੀਵਰਸਲ - ਮੈਂ ਇਸਦਾ ਪਤਾ ਲਗਾਵਾਂਗਾ ਅਤੇ ਕਰਾਂਗਾ"

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

ਉਹ ਕਿਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​​​ਹਨ:

• ਸੁਤੰਤਰ;
• ਤਣਾਅ-ਰੋਧਕ;
• ਬਹੁਤ ਸਾਰੇ ਮੁੱਦਿਆਂ ਵਿੱਚ ਸਮਰੱਥ;
• erudite - ਉਹਨਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਲਈ ਹਮੇਸ਼ਾ ਕੁਝ ਹੁੰਦਾ ਹੈ.

ਪਰ:

• ਅਕਸਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹਨ;
• ਹਰ ਚੀਜ਼ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਣ ਦਾ ਰੁਝਾਨ: ਭਾਗਾਂ ਦੁਆਰਾ ਏਕੀਕ੍ਰਿਤ ਕਰਕੇ ਗੁਣਾ ਸਾਰਣੀ ਨੂੰ ਹੱਲ ਕਰੋ;
• ਕੰਮ ਦੀ ਗੁਣਵੱਤਾ ਘੱਟ ਹੈ, ਹਰ ਚੀਜ਼ 2-3 ਵਾਰ ਕੰਮ ਕਰਦੀ ਹੈ;
• ਉਹ ਲਗਾਤਾਰ ਸਮਾਂ ਸੀਮਾ ਬਦਲਦੇ ਹਨ, ਕਿਉਂਕਿ ਅਸਲ ਵਿੱਚ ਸਭ ਕੁਝ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੁੰਦਾ ਹੈ.

3. "ਯੂਨੀਵਰਸਲ - ਠੀਕ ਹੈ, ਮੈਨੂੰ ਇਹ ਕਰਨ ਦਿਓ, ਕਿਉਂਕਿ ਇੱਥੇ ਕੋਈ ਹੋਰ ਨਹੀਂ ਹੈ"

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

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

ਉਹ ਕਿਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​​​ਹਨ:

• ਜ਼ਿੰਮੇਵਾਰ;
• ਨਤੀਜਾ-ਮੁਖੀ;
• ਸ਼ਾਂਤ
• ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯੰਤਰਿਤ.

ਪਰ:

• ਯੋਗਤਾਵਾਂ ਦੇ ਘੱਟ ਪੱਧਰ ਦੇ ਕਾਰਨ ਔਸਤ ਨਤੀਜੇ ਦਿਖਾਓ;
• ਗੁੰਝਲਦਾਰ ਅਤੇ ਅਮੂਰਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ।

4. "ਇੱਕ ਆਲਰਾਊਂਡਰ ਆਪਣੀ ਕਲਾ ਦਾ ਮਾਸਟਰ ਹੁੰਦਾ ਹੈ"

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

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

ਉਹ ਕਿਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​​​ਹਨ:

• ਕੰਮ ਦੀ ਉੱਚ ਗੁਣਵੱਤਾ ਦਿਖਾਉਣ;
• ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਸਮਰੱਥ;
• ਬਹੁਤ ਕੁਸ਼ਲ.

ਪਰ:

• ਦੂਜਿਆਂ ਦੇ ਵਿਚਾਰਾਂ ਪ੍ਰਤੀ ਅਸਹਿਣਸ਼ੀਲ;
• ਅਧਿਕਤਮਵਾਦੀ ਉਹ ਸਭ ਕੁਝ ਸਹੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਵਿਕਾਸ ਦੇ ਸਮੇਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ.

ਅਭਿਆਸ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਕੀ ਹੈ?

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

ਯੋਗਤਾਵਾਂ ਨੂੰ ਜੋੜਨ/ਮਿਲਾਉਣ/ਸੰਯੋਗ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਮ ਵਿਕਲਪ ਵਿਕਾਸਕਾਰ-ਵਿਸ਼ਲੇਸ਼ਕ ਹੈ। ਟੈਸਟਿੰਗ ਵਿਸ਼ਲੇਸ਼ਕ ਅਤੇ "ਇੱਕ ਵਿੱਚ ਤਿੰਨ" ਵੀ ਬਹੁਤ ਆਮ ਹਨ।

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

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

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

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

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

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

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

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

ਅਸੀਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਦੇ ਹਾਂ?

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

1. ਮੁਸ਼ਕਲਾਂ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਕੰਮ ਲਈ, ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਯੂਨੀਫਾਈਡ ਫਾਰਮ ਭਰਨ ਲਈ ਕਹਿੰਦਾ ਹਾਂ: ਇੱਕ ਗਲਤੀ ਦਾ ਨਕਸ਼ਾ, ਜੋ ਤੁਹਾਨੂੰ ਉਸ ਪੜਾਅ ਦੀ ਪਛਾਣ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜਿਸ 'ਤੇ "ਡਰਾਅਡਾਊਨ" ਹੋਇਆ ਸੀ:

2. ਰੁਕਾਵਟਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਮੱਸਿਆ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਕਰਮਚਾਰੀ ਨਾਲ ਇੱਕ ਬ੍ਰੇਨਸਟਾਰਮਿੰਗ ਸੈਸ਼ਨ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: "ਕੀ ਬਦਲਣਾ ਹੈ?" (ਅਸੀਂ ਪਿਛੋਕੜ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਦੇ), ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਖਾਸ ਕਿਰਿਆਵਾਂ (ਹਰੇਕ ਸ਼ਖਸੀਅਤ ਦੀ ਕਿਸਮ ਲਈ ਖਾਸ) ਸਮਾਂ-ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ।

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

4. ਹਰ ਪੜਾਅ 'ਤੇ ਨਿਯੰਤਰਣ ਕੀਤਾ ਜਾਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ (ਅਤੀਤ ਵਿੱਚ ਸਮੱਸਿਆ ਵਾਲੇ ਪੜਾਵਾਂ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ) ਅਤੇ ਆਪਣੇ ਆਪ ਅਗਲੇ ਕੰਮ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਅਧਾਰ ਤੇ.

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

ਆਖਰ ਕੀ ਹੋਇਆ?

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

ਸਿੱਟਾ

ਜਨਰਲਿਸਟ ਕਰਮਚਾਰੀਆਂ ਦੇ ਆਪਣੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ.

ਪਲੱਸ:

• ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਸਮੇਂ ਸਗਿੰਗ ਟਾਸਕ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਜ਼ਰੂਰੀ ਬੱਗ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ;
• ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਪਹੁੰਚ: ਕਲਾਕਾਰ ਇਸ ਨੂੰ ਸਾਰੀਆਂ ਭੂਮਿਕਾਵਾਂ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਦੇਖਦਾ ਹੈ;
• ਜਨਰਲਿਸਟ ਲਗਭਗ ਸਭ ਕੁਝ ਬਰਾਬਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰ ਸਕਦੇ ਹਨ।

ਨੁਕਸਾਨ:

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

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

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

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

ਮੈਂ ਹਰ ਕਿਸੇ ਨੂੰ "ਉਨ੍ਹਾਂ ਦੇ ਸ਼ਿਲਪਕਾਰੀ ਦੇ ਯੂਨੀਵਰਸਲ ਮਾਸਟਰਾਂ" ਦੀ ਇੱਕ ਸਵੈ-ਸੰਗਠਿਤ ਟੀਮ ਦੀ ਕਾਮਨਾ ਕਰਦਾ ਹਾਂ!

ਸਰੋਤ: www.habr.com