ਪੇਸ਼ੇਵਰ ਬਰਨਆਉਟ ਨੂੰ ਰੋਕਣ ਲਈ ਅਸੀਂ "ਹਮੇਸ਼ਾ ਚਾਲੂ" ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਬਦਲਿਆ ਹੈ

ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੋਰਸ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ "DevOps ਅਭਿਆਸ ਅਤੇ ਸਾਧਨ".

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

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

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

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

ਇੰਟਰਕਾਮ ਵਿੱਚ "ਹਮੇਸ਼ਾ ਜੁੜਿਆ" ਸਥਿਤੀ ਦਾ ਇਤਿਹਾਸ

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

ਕਿਸੇ ਵੀ ਸਮੇਂ "ਕਾਲ 'ਤੇ" ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸਨ।

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

ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਅਸੀਂ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਸੀ ਜਿੱਥੇ ਸਾਡੇ ਕੋਲ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਮਕੈਨਿਕ ਸਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਸਾਨੂੰ ਮਾਣ ਨਹੀਂ ਸੀ, ਅਤੇ ਕਈ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਹੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਜਿਵੇਂ ਕਿ:

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

ਸਹੀ "ਹਮੇਸ਼ਾ ਚਾਲੂ" ਸਥਿਤੀ ਨੂੰ ਲੱਭਣਾ

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

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੀ ਸਹਾਇਤਾ ਟੀਮ 30 ਲੋਕਾਂ ਤੋਂ ਘਟ ਕੇ ਸਿਰਫ਼ 6 ਜਾਂ 7 ਰਹਿ ਗਈ।

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

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

ਜੋ ਅਸੀਂ ਸਿੱਖਿਆ ਹੈ

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

ਘੰਟੇ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਪ੍ਰਤੀ ਮਹੀਨਾ 10 ਤੋਂ ਘੱਟ ਹੋ ਗਈ ਹੈ।

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

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

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

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

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

ਸਰੋਤ: www.habr.com