ਟਿਮ ਲਿਸਟਰ - ਕਿਤਾਬਾਂ ਦਾ ਸਹਿ-ਲੇਖਕ

• "ਮਨੁੱਖੀ ਕਾਰਕ. ਸਫਲ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਟੀਮਾਂ" (ਮੂਲ ਕਿਤਾਬ ਨੂੰ "ਪੀਪਲਵੇਅਰ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ)
• "ਰੱਛਿਆਂ ਨਾਲ ਵਾਲਟਜ਼ਿੰਗ: ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਜੋਖਮ ਦਾ ਪ੍ਰਬੰਧਨ"
• “ਐਡਰੇਨਾਲੀਨ-ਪਾਗਲ ਅਤੇ ਪੈਟਰਨਾਂ ਦੁਆਰਾ ਜ਼ੋਂਬੀਫਾਈਡ। ਪ੍ਰੋਜੈਕਟ ਟੀਮਾਂ ਦੇ ਵਿਵਹਾਰ ਦੇ ਨਮੂਨੇ"

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

ਟਿਮ ਦੇ ਕੋਲ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਵਿੱਚ 40 ਸਾਲਾਂ ਦਾ ਤਜਰਬਾ ਹੈ; 1975 ਵਿੱਚ (ਇਸ ਹੈਬਰਾਪੋਸਟ ਨੂੰ ਲਿਖਣ ਵਾਲਿਆਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਸ ਸਾਲ ਪੈਦਾ ਨਹੀਂ ਹੋਇਆ ਸੀ), ਟਿਮ ਪਹਿਲਾਂ ਹੀ Yourdon Inc ਦਾ ਕਾਰਜਕਾਰੀ ਉਪ ਪ੍ਰਧਾਨ ਸੀ। ਉਹ ਹੁਣ ਆਪਣਾ ਸਮਾਂ ਸਲਾਹ-ਮਸ਼ਵਰੇ, ਪੜ੍ਹਾਉਣ ਅਤੇ ਲਿਖਣ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ, ਕਦੇ-ਕਦਾਈਂ ਮੁਲਾਕਾਤਾਂ ਨਾਲ ਰਿਪੋਰਟਾਂ ਦੇ ਨਾਲ ਸੰਸਾਰ ਭਰ ਵਿੱਚ ਕਾਨਫਰੰਸ.

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

ਮਾਈਕਲ: ਕੀ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਕਹਿ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਹੁਣ ਕਰ ਰਹੇ ਹੋ?

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

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

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

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

ਮਾਈਕਲ: ਭਾਵ, ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਲਾਂਚ ਕਰਦੇ ਹੋ, ਕਿਸੇ ਕਿਸਮ ਦਾ ਕਿੱਕਆਫ ਕਰਦੇ ਹੋ ਅਤੇ ਜਾਂਚ ਕਰਦੇ ਹੋ ਕਿ ਰੇਲ ਸਹੀ ਦਿਸ਼ਾ ਵੱਲ ਜਾ ਰਹੀ ਹੈ?

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

ਚੁਸਤ ਦੇ 19 ਸਾਲ

ਮਾਈਕਲ: ਚੁਸਤ ਵਿੱਚ, ਲੋਕ ਅਕਸਰ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਪਰ ਜਿੰਨੀ ਦੇਰ ਹੋ ਸਕੇ ਫੈਸਲੇ ਲੈਣ ਲਈ, ਕਹਿੰਦੇ ਹਨ: ਅਸੀਂ ਬਹੁਤ ਵੱਡੇ ਹਾਂ, ਮੈਂ ਸਮੁੱਚੇ ਢਾਂਚੇ ਬਾਰੇ ਨਹੀਂ ਸੋਚਾਂਗਾ। ਮੈਂ ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਝੁੰਡ ਬਾਰੇ ਨਹੀਂ ਸੋਚਾਂਗਾ; ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਕੁਝ ਅਜਿਹਾ ਪ੍ਰਦਾਨ ਕਰਾਂਗਾ ਜੋ ਇਸ ਸਮੇਂ ਗਾਹਕ ਨੂੰ ਕੰਮ ਕਰਦਾ ਹੈ।

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

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

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

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

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

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

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

ਲੋਕਵੇਅਰ: 30 ਸਾਲ ਬਾਅਦ

ਓਲੇਗ: ਕੀ ਪੀਪਲਵੇਅਰ ਇੱਕ ਇਨਕਲਾਬ ਦੇ ਨਾਲ-ਨਾਲ ਮੈਨੀਫੈਸਟੋ ਵੀ ਸੀ?

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

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

ਮਾਈਕਲ: ਕੀ ਕਿਤਾਬ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਿਛਲੇ 30 ਸਾਲਾਂ ਵਿੱਚ ਕੁਝ ਬਦਲਿਆ ਹੈ?

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

ਅਸੀਂ ਸਾਰੇ DevOps ਵਿੱਚ ਰਹਿੰਦੇ ਹਾਂ

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

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

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

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

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

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

ਪੈਟਰਨ ਅਤੇ ਵਿਰੋਧੀ ਪੈਟਰਨ

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

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

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

ਮਾਈਕਲ: ਦਰਅਸਲ, ਅਸੀਂ ਅਗਲੀ ਸਿਲਵਰ ਬੁਲੇਟ ਬਾਰੇ ਕਿੰਨੀ ਵਾਰ ਸੁਣਿਆ ਹੈ?

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

ਮਾਈਕਲ: ਹਾਂ, ਮੁੱਖ "ਜੀਵਨ, ਬ੍ਰਹਿਮੰਡ ਅਤੇ ਹਰ ਚੀਜ਼ ਦਾ ਸਵਾਲ": ਕੀ ਇਹ ਤਕਨਾਲੋਜੀ ਜਾਂ ਪਹੁੰਚ ਤੁਹਾਡੀ ਸਥਿਤੀ ਲਈ ਢੁਕਵੀਂ ਹੈ ਜਾਂ ਨਹੀਂ?

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

ਮਿਥਿਹਾਸਕ "ਡਿਪੋਪ ਇੰਜੀਨੀਅਰ"

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

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

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

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

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

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

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

"ਹਰ ਚੀਜ਼ ਦੇ ਮਾਹਰ"

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

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

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

ਜੋਖਮ ਅਤੇ ਅਨਿਸ਼ਚਿਤਤਾ

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

ਓਲੇਗ: ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਤੋੜੋ!

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

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

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

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

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

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

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

ਬਾਲਗ ਇੰਜੀਨੀਅਰਿੰਗ ਸੋਚ

ਮਾਈਕਲ: ਬੱਚਿਆਂ ਨਾਲ ਮਿਸਾਲ ਚੰਗੀ ਹੈ। ਜੇ ਮੈਂ ਸਾਧਾਰਨ ਇੰਜੀਨੀਅਰ ਹਾਂ, ਤਾਂ ਮੈਂ ਬੱਚਾ ਹੋਣ ਦੀ ਖੁਸ਼ੀ ਵਿਚ ਹਾਂ. ਪਰ ਤੁਸੀਂ ਵਧੇਰੇ ਬਾਲਗ ਸੋਚ ਵੱਲ ਕਿਵੇਂ ਵਧਦੇ ਹੋ?

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

ਓਲੇਗ: ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਬੋਲਦੇ ਹੋਏ, ਜੇਕਰ ਤੁਸੀਂ ਕਨਬਨ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹੋ, ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਟੈਸਟਿੰਗ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਮਾਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉੱਥੇ ਕੀ ਕਰ ਰਹੇ ਸੀ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਗਰਾਮਿੰਗ) ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ ਅਤੇ ਟੈਸਟਰਾਂ ਦੀ ਮਦਦ ਲਈ ਜਾ ਸਕਦੇ ਹੋ।

ਟਿਮ: ਬਿਲਕੁਲ। ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਤਕਨੀਕੀ, ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਨੇੜਿਓਂ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਉਹ ਆਪਣੇ ਖੁਦ ਦੇ ਪ੍ਰਬੰਧਕ ਹਨ। ਮੈਂ ਇਸਨੂੰ ਕਿਵੇਂ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹਾਂ ...

ਓਲੇਗ: ਤੁਹਾਡਾ ਜੀਵਨ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਜਿਸਦਾ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ।

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

ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਕਿਵੇਂ ਸ਼ਾਮਲ ਹੋਣਾ ਹੈ

ਓਲੇਗ: ਕੀ ਇਸ ਖੇਤਰ ਵਿੱਚ ਕੋਈ ਰਸਮੀ ਗਿਆਨ ਢਾਂਚਾ ਹੈ? ਉਦਾਹਰਨ ਲਈ, ਮੈਂ ਇੱਕ Java ਡਿਵੈਲਪਰ ਹਾਂ ਅਤੇ ਸਿੱਖਿਆ ਦੁਆਰਾ ਇੱਕ ਅਸਲੀ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ ਬਣਨ ਤੋਂ ਬਿਨਾਂ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਮਝਣਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਮੈਂ ਸ਼ਾਇਦ ਪਹਿਲਾਂ McConnell ਦਾ "How Much Does a Software Project Cost" ਪੜ੍ਹਾਂਗਾ, ਅਤੇ ਫਿਰ ਕੀ? ਪਹਿਲੇ ਕਦਮ ਕੀ ਹਨ?

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

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

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

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

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

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

ਸੰਚਾਰ ਦੀ ਕੀਮਤ

ਓਲੇਗ: ਕੀ ਅਜਿਹੇ ਆਊਟਗੋਇੰਗ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਕਰਕੇ ਰੁਜ਼ਗਾਰ ਦੇਣਾ ਮਹਿੰਗਾ ਨਹੀਂ ਹੈ? ਆਖ਼ਰਕਾਰ, ਉਹ ਕੰਮ ਕਰਨ ਦੀ ਬਜਾਏ ਲਗਾਤਾਰ ਗੱਲਬਾਤ ਕਰ ਰਹੇ ਹਨ!

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

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

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

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

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

ਮਾਈਕਲ: ਜਾਓ ਕੁਝ ਕੋਡ ਲਿਖੋ!

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

ਓਲੇਗ: ਮੀਸ਼ਾ, ਤੁਸੀਂ ਕੁਝ ਸੋਚ ਰਹੇ ਹੋ।

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

ਤਨਖਾਹਾਂ ਤੋਂ ਬਿਨਾਂ ਜ਼ਿੰਦਗੀ

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

ਓਲੇਗ: ਤਰੀਕੇ ਨਾਲ, ਤੁਹਾਡੀ ਕਿਤਾਬ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਨੋਟਾਂ ਦਾ ਇੱਕ ਝੁੰਡ ਹੈ ਕਿ ਕੀ ਚੰਗਾ ਹੈ ਅਤੇ ਕੀ ਮਾੜਾ ਹੈ. ਕੀ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੀ ਵਰਤੋਂ ਆਪਣੇ ਆਪ ਕਰਦੇ ਹੋ? ਮੁਕਾਬਲਤਨ ਤੌਰ 'ਤੇ, ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਕੰਪਨੀ ਹੈ, ਅਤੇ ਇੱਕ ਜੋ ਕਿ ਇੱਕ ਬਹੁਤ ਹੀ ਗੈਰ-ਰਵਾਇਤੀ ਤਰੀਕੇ ਨਾਲ ਬਣਤਰ ਹੈ ...

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

ਵਧੀਆ ਸਲਾਹ

ਮਾਈਕਲ: "ਸਭ ਤੋਂ ਵਧੀਆ ਸਲਾਹ" 'ਤੇ ਵਾਪਸ ਜਾਣਾ, ਕੀ ਕੁਝ ਅਜਿਹਾ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਗਾਹਕਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਦੱਸਦੇ ਹੋ? 80/20 ਬਾਰੇ ਇੱਕ ਵਿਚਾਰ ਹੈ, ਅਤੇ ਕੁਝ ਸਲਾਹ ਸ਼ਾਇਦ ਜ਼ਿਆਦਾ ਵਾਰ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ।

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

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

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

ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਦਾ ਅਭਿਆਸ ਕਰੋ!

ਮਾਈਕਲ: ਤੁਹਾਡੀ ਰਾਏ ਵਿੱਚ, ਕਿੰਨੀਆਂ ਸੰਸਥਾਵਾਂ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ?

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

ਮਾਈਕਲ: ਅਤੇ ਫਿਰ ਵੀ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿੰਨੀਆਂ ਕੰਪਨੀਆਂ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ, ਪੰਜ ਪ੍ਰਤੀਸ਼ਤ?

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

ਹਾਂ, ਮੈਂ ਅਕਸਰ ਸੁਣਦਾ ਹਾਂ, "ਜਿਵੇਂ ਹੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਣਗੀਆਂ ਅਸੀਂ ਹੱਲ ਕਰਾਂਗੇ।" ਯਕੀਨਨ ਅਸੀਂ ਕਰਾਂਗੇ? ਕੀ ਅਸੀਂ ਸੱਚਮੁੱਚ ਫੈਸਲਾ ਕਰਾਂਗੇ?

ਓਲੇਗ: ਤੁਸੀਂ ਇਸਨੂੰ ਨਿਰਪੱਖਤਾ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਚਾਰਟਰ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਇਨਵੈਰੀਐਂਟ ਲਿਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇਕਰ ਇਨਵੈਰੀਐਂਟ ਟੁੱਟ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ। ਇਹ ਬਾਹਰ ਕਾਮੁਕ ਬਹੁਤ piembucky.

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

ਟਿਮ: ਚਲੋ ਰੀਸੈਟ ਬਟਨ ਦਬਾਓ! ਨਹੀਂ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।

DevOops 2019 'ਤੇ ਮੁੱਖ ਭਾਸ਼ਣ

ਮਾਈਕਲ: ਅਸੀਂ ਇਸ ਇੰਟਰਵਿਊ ਦੇ ਆਖਰੀ ਸਵਾਲ 'ਤੇ ਆਉਂਦੇ ਹਾਂ। ਤੁਸੀਂ ਇੱਕ ਮੁੱਖ ਭਾਸ਼ਣ ਦੇ ਨਾਲ ਅਗਲੇ DevOops ਵਿੱਚ ਆ ਰਹੇ ਹੋ, ਕੀ ਤੁਸੀਂ ਉਸ ਬਾਰੇ ਗੁਪਤਤਾ ਦਾ ਪਰਦਾ ਚੁੱਕ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਦੱਸਣ ਜਾ ਰਹੇ ਹੋ?

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

ਮਾਈਕਲ: ਮੈਂ ਵੀ ਸਾਲਾਂ ਤੋਂ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹੋ।

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

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

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

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

ਸਰੋਤ: www.habr.com