ਤੁਸੀਂ ਤਕਨੀਕੀ ਅਤੇ ਗ਼ੈਰ-ਤਕਨੀਕੀ ਟੀਮਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਬਿਹਤਰ ਸਮਝਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਮੁੱਖ ਸਮੱਸਿਆ ਬੁੱਧੀ ਨਹੀਂ, ਸਗੋਂ **ਵੱਖ-ਵੱਖ ਸ਼ਬਦਾਵਲੀਆਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਟੀਚੇ** ਹਨ। Engineers ਸਿਸਟਮਾਂ, ਪਾਬੰਦੀਆਂ, ਅਤੇ edge cases ਵਿੱਚ ਸੋਚਦੇ ਹਨ; Sales, Marketing, ਅਤੇ Support ਗਾਹਕਾਂ, deals, ਅਤੇ ਨਤੀਜਿਆਂ ਵਿੱਚ ਸੋਚਦੇ ਹਨ। Tech Lead ਵਜੋਂ ਮੇਰਾ ਕੰਮ ਇੱਕ ਅਨੁਵਾਦਕ ਬਣਨਾ ਅਤੇ ਉਹ ਆਦਤਾਂ ਬਣਾਉਣਾ ਹੈ ਜੋ ਸਮੇਂ ਨਾਲ ਅਨੁਵਾਦ ਦੀ ਲੋੜ ਘਟਾਉਂਦੀਆਂ ਹਨ।

## ਮੈਂ ਅਮਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹਾਂ

- **Jargon ਨੂੰ ਦੋਵੇਂ ਪਾਸੇ ਅਨੁਵਾਦ ਕਰੋ।** ਮੈਂ cross-functional meetings ਵਿੱਚ acronyms 'ਤੇ ਪਾਬੰਦੀ ਲਾਉਂਦਾ ਹਾਂ ਅਤੇ ਤਕਨੀਕੀ ਸੰਕਲਪਾਂ ਨੂੰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਭਾਵ ਵਜੋਂ ਮੁੜ-ਪੇਸ਼ ਕਰਦਾ ਹਾਂ: ਨਾ ਕਿ "queue backed up ਹੈ" ਸਗੋਂ "orders ਨੂੰ confirm ਹੋਣ ਵਿੱਚ 10 ਮਿੰਟ ਲੱਗ ਰਹੇ ਹਨ, ਜਿਸ ਕਾਰਨ Support ਨੂੰ ਸ਼ਿਕਾਇਤਾਂ ਮਿਲ ਰਹੀਆਂ ਹਨ।"
- **ਸਾਂਝੇ artifacts ਨਾਲ ਜੋੜੋ।** Demos documents ਨੂੰ ਹਰਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਕੰਮ ਕਰਦਾ prototype, ਇੱਕ dashboard, ਜਾਂ ਇੱਕ customer journey diagram ਦੋਵਾਂ ਪਾਸਿਆਂ ਨੂੰ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਇੱਕੋ ਠੋਸ ਚੀਜ਼ ਦਿੰਦਾ ਹੈ।
- **ਅਨੁਭਵ ਰਾਹੀਂ ਹਮਦਰਦੀ ਬਣਾਓ।** ਮੈਂ engineers ਨੂੰ ਕਦੇ-ਕਦੇ ਇੱਕ Sales call ਜਾਂ ਇੱਕ Support shift ਵਿੱਚ ਬਿਠਾਉਂਦਾ ਹਾਂ। ਇੱਕ ਅਸਲ ਗਾਹਕ ਨੂੰ ਸੰਘਰਸ਼ ਕਰਦੇ ਸੁਣਨਾ ਕਿਸੇ ਵੀ spec ਤੋਂ ਜ਼ਿਆਦਾ ਕਰਦਾ ਹੈ। ਇਸ ਦੇ ਉਲਟ, ਮੈਂ ਗ਼ੈਰ-ਤਕਨੀਕੀ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਸਰਲ architecture walkthrough ਵਿੱਚ ਸੱਦਦਾ ਹਾਂ।
- **ਅਮੂਰਤਤਾ ਦੀ ਬਜਾਏ ਉਪਮਾਵਾਂ ਵਰਤੋ।** ਇੱਕ migration ਦੀ ਤੁਲਨਾ "ਘਰ ਦੀ ਮੁਰੰਮਤ ਕਰਨ ਨਾਲ ਜਦੋਂ ਲੋਕ ਅਜੇ ਵੀ ਇਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ" ਨਾਲ ਕਰਨਾ ਇੱਕ ਗ਼ੈਰ-ਤਕਨੀਕੀ ਸਰੋਤੇ ਨਾਲ ਤੁਰੰਤ ਟਿਕ ਜਾਂਦਾ ਹੈ।
- **status ਲਈ ਸੱਚਾਈ ਦਾ ਇੱਕੋ ਸਰੋਤ ਬਣਾਓ।** ਇੱਕ ਸਾਂਝਾ, ਸਾਫ਼-ਭਾਸ਼ਾ roadmap ਜਾਂ status board ਉਸ telephone ਖੇਡ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਅਵਿਸ਼ਵਾਸ ਪੈਦਾ ਕਰਦੀ ਹੈ।

## ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ framework

1. ਮੰਗ ਦੇ ਹੇਠਾਂ ਅਸਲ ਚਿੰਤਾ ਲਈ **ਸੁਣੋ** ("ਕੀ ਤੁਸੀਂ ਇੱਕ button ਜੋੜ ਸਕਦੇ ਹੋ?" ਦਾ ਅਕਸਰ ਮਤਲਬ ਹੁੰਦਾ ਹੈ "ਇੱਕ ਗਾਹਕ block ਹੋਇਆ ਹੈ")।
2. ਇਸ ਨੂੰ ਦੂਜੇ ਪਾਸੇ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ **ਮੁੜ-ਪੇਸ਼ ਕਰੋ**।
3. ਇਸ ਨੂੰ ਵਾਪਸ ਚਲਾ ਕੇ ਸਮਝ ਦੀ **ਪੁਸ਼ਟੀ ਕਰੋ**।
4. ਸਾਂਝੇ ਫ਼ੈਸਲੇ ਨੂੰ **document ਕਰੋ** ਤਾਂ ਜੋ ਇਹ meeting ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕ ਸਕੇ।

## ਬਚਣ ਵਾਲੀਆਂ ਗ਼ਲਤੀਆਂ

- **ਨੀਚ-ਭਾਵ।** ਗ਼ੈਰ-ਤਕਨੀਕੀ ਦਾ ਮਤਲਬ ਬੁੱਧੀਹੀਣ ਨਹੀਂ; ਜ਼ਿਆਦਾ-ਸਰਲ ਬਣਾਉਣਾ ਲੋਕਾਂ ਦਾ ਅਪਮਾਨ ਕਰਦਾ ਹੈ।
- ਨਾਂਹ ਕਹਿਣ ਤੋਂ ਬਚਣ ਲਈ **ਗੁੰਝਲਤਾ ਪਿੱਛੇ ਛੁਪਣਾ।** "ਇਹ ਗੁੰਝਲਦਾਰ ਹੈ" ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਹੈ।
- **ਇੱਕ-ਪਾਸੀ ਅਨੁਵਾਦ।** Engineers ਨੂੰ ਵੀ ਕਾਰੋਬਾਰੀ context ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਸ ਤੋਂ ਢਾਲੇ ਜਾਣ ਦੀ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

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

ਮੈਂ ਅਮਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹਾਂ

ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ framework

ਬਚਣ ਵਾਲੀਆਂ ਗ਼ਲਤੀਆਂ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ